Security Control
NIST defines a security control as a safeguard or countermeasure for an information system or organization, intended to protect information and meet defined security requirements. Controls can involve management decisions, operational practices, or technical mechanisms.
Record the requirement so reviewers can distinguish the control’s presence, implementation, and effectiveness. If it is undocumented, recover and confirm the intended objective from policy, design evidence, and responsible people. A mechanism can still provide protection before that documentation is complete, but the assessment must state what it has and has not established.
Four jobs, four kinds of evidence
The evidence needed depends on what the control is intended to do. The following examples separate prevention, detection, response, and recovery so that success in one area is not mistaken for success in another. They are practical assessment examples, not an exhaustive taxonomy.
| Kind | Example | Evidence that it works |
|---|---|---|
| Preventive | An authorization check, a network rule, a requirement that artifacts be signed | Inspect the configured restriction and attempt the forbidden action from relevant attacker positions. Record the scope and limits of the evidence |
| Detective | An alert on unusual export volume; an integrity check on the audit log | Inject the condition and verify detection, analysis, and delivery. Measure human or automated response separately; a detected event can still receive no effective response |
| Responsive | Credential revocation, session termination, isolating a host | Exercise it. How long to revoke everything a compromised identity holds — and is that set even enumerable? |
| Recovery | Restoring from a copy the attacker could not reach or alter | Restore and verify the result on a schedule. Proving copies exist is a different exercise from proving a restore works |
NIST SP 800-53A uses examination, interviews, and tests to assess controls. Select and combine methods according to the control and the risk: review a policy and its enforcement evidence, ask responsible people how exceptions are handled, or exercise a technical restriction. Any of these control types can fail through misconfiguration, missing coverage, or operational breakdown. Presence alone does not prove effectiveness, and absence of a test does not prove ineffectiveness.
NIST CSF 2.0 organizes outcomes under Govern, Identify, Protect, Detect, Respond, and Recover without prescribing how an organization must implement them. Those functions help identify gaps across a program. Detection establishes and analyzes a potentially adverse event; response takes action on it. Either can involve automation, and both need evidence appropriate to their purpose.
Compensating controls, and the word that constrains them
A legacy system may not support a required agent or identity integration. NIST calls an alternative a compensating control when it provides equivalent or comparable protection in place of a recommended control. Document that comparison against the original requirement rather than treating any additional effort as compensation.
An approval recorded only in a ticket cannot enforce a permission boundary if a caller can bypass it. By contrast, a server can refuse execution without valid approval bound to the transaction, with controls against alternate-path bypass and later modification. OWASP’s transaction-authorization guidance describes that kind of enforcement. It can provide protection, but qualification as compensation still depends on the requirement, threats, applicable acceptance process, and residual risk. Faster log review also needs an effective response path; even timely action may be insufficient for harm that occurs before detection.
Record what the substitute protects, its assumptions, evidence of comparable protection, and the authority accepting it. Use appropriate examination, interviews, and tests, and define reassessment triggers. Missing assessment evidence means the protection claim is unverified; it does not establish that the mechanism has no effect.
What to record for each control
An assessable inventory connects each control to its objective, operating assumptions, and evidence. These fields support the decision without replacing the underlying assessment.
- The requirement it serves. Identify the assets and risks addressed. For a technical restriction, show the relevant attack paths. Governance and operational controls may support several paths or organization-wide requirements rather than one directly blocked request.
- What it assumes. That the credential is short-lived, that the caller is interactive, that traffic inside the perimeter is legitimate, that somebody reads the alert. Assumptions are where controls fail while remaining correctly configured.
- How it was assessed, and when. Record examination, interview, or test evidence, the assessed configuration and scope, results, and unresolved limitations. Distinguish observed effectiveness from assumptions that still need verification.
Controls can share failure causes, so a count alone does not establish protection. The discussion of defense in depth examines which barriers remain under particular compromise scenarios. The Control Everyone Passed connects those judgments to assets, boundaries, and paths.
References
- NIST CSRC Glossary — security control
- NIST CSRC Glossary — compensating security control
- NIST, The NIST Cybersecurity Framework (CSF) 2.0
- NIST SP 800-53A Rev. 5 — Assessing Security and Privacy Controls
- OWASP — Transaction Authorization Cheat Sheet
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.