Security controls
Safeguards can prevent, detect, correct, or compensate for a problem.
The idea
A control is a measure intended to change security risk. Technical controls include access rules and monitoring. Administrative controls include approvals, procedures, and training. Physical controls include locks and controlled facilities. Controls can also be grouped by their purpose: preventive, detective, corrective, or compensating. Their value comes from working in the actual environment, so teams need evidence that a control is deployed, maintained, and effective.
In practice
A restricted server room is a physical control. Login monitoring is a detective control. Restoring a service from a verified backup is corrective.
A common misunderstanding
A written policy is not proof that a control operates. You need records of implementation and checks over time.
Check your understanding
How could you test a login-alert control?
Think it through: Generate an approved test event, verify that the expected alert reaches the responsible person, and document the result.
Translate a measure into an expected outcome
A fictional retailer requires independent approval for refunds above a threshold. Calling this an administrative control describes its broad form, but not whether it works. The team needs to know which transactions require approval, who can approve them, whether the system enforces the rule, and what evidence shows the rule operated.
Controls often cross categories. A written approval policy may be supported by technical workflow restrictions and detective review of exceptions. Treating these as unrelated items can hide a gap between intention and implementation. The business outcome is that one person cannot quietly issue an unapproved high-value refund.
Effectiveness depends on context. A control can be correctly configured but cover only one sales channel while another channel bypasses it. It can also become ineffective after a role change or software update. Define coverage, ownership, frequency of review, and expected exception handling.
Assemble evidence for one control
For the refund example, prepare dummy transactions below and above the threshold. Check that an ordinary operator can process the first and must obtain appropriate approval for the second. Confirm that the requester cannot approve their own transaction under the intended policy. Inspect the recorded outcome without using real customer information.
Then distinguish design evidence from operating evidence. A workflow diagram explains how the control should work; observed transactions and review records help show that it actually did. Neither should be exaggerated into a guarantee of zero fraud. Controls change risk under stated assumptions, and a useful assessment makes those assumptions and practical limits visible. This helps owners repair weak coverage rather than simply adding another policy document to an evidence folder.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: An Introduction to Information SecurityNIST SP 800-53 Rev. 5: Security and Privacy Controls