A policy states intent. A control changes what people or systems can do. Many security programs have a full policy set and call it a control environment. The gap between the two is where risk sits, and where audits and attackers both find their results.
Two sentences, one gap
Take a common policy line: privileged access must be reviewed regularly. Now take the control that would make it true: a named owner reviews a system-generated list of privileged accounts every quarter, records a keep-or-remove decision for each, and removals are completed and recorded within a set time.
Everything that matters in control design sits between those two sentences. Who. What list. How often. What counts as done. What proves it.
Where the gap opens
Hypothetical example. A company’s policy says every production change needs approval and testing. The change tickets show approvals. But engineers can deploy from the build pipeline using a service token that skips the approval step. An auditor sampling tickets finds the policy followed. An attacker who steals the token finds nothing in the way.
Both outcomes come from the same flaw. The policy describes the intended path. The control environment allows another one.
From requirement to operating control
| Layer | Question it answers | Example |
|---|---|---|
| Requirement | What must be true? | Remote access to company systems must be strongly authenticated. |
| Policy | What do we commit to? | All remote access requires multi-factor authentication. |
| Standard | What does good look like here? | Phishing-resistant methods for administrators; approved methods for others; no exceptions without sign-off. |
| Control | What happens, who owns it, and what enforces it? | The identity provider blocks any remote sign-in without an approved second factor. The identity team reviews exception reports monthly. |
| Evidence | How do we know it operated? | Provider configuration export, sign-in logs, and dated exception reviews. |
Most programs are strong on the first three rows. The last two decide whether risk drops.
Five tests for a control
-
Specific. One owner, one trigger, one frequency. “Reviewed regularly” fails this test.
-
Enforced. Prefer controls that make the wrong action hard. Next best are controls that catch it fast and automatically. Human review comes last, though some risks, such as supplier approval, need it.
-
Observable. Operating the control produces the evidence. Nobody has to reconstruct it later.
-
Tied to a risk. You can name the scenario it reduces. If you cannot, ask why it exists.
-
Tested. Someone checks that it works, not just that it exists.
Design is not operation
Assurance practice separates two questions. Is the control suitably designed to meet its objective? And did it operate effectively over the period? A SOC 2 Type 1 report speaks to design at a point in time. A Type 2 report speaks to operation over a period.
A control can fail either way. A well-designed review that nobody performs has a design pass and an operating failure. A review performed every quarter on the wrong list of accounts has an operating pass and a design failure. Teams that only check for existence miss both.
Frameworks give outcomes, not designs
ISO/IEC 27001 Annex A groups 93 controls into four themes. NIST SP 800-53 Rev. 5 offers a much larger catalog. Both tell you what outcome to reach. Neither tells you how to reach it in your environment, with your identity provider, your pipelines and your suppliers.
Treat a catalog as a menu. The requirement sets the objective. Your architecture, your people and your risks set the design. A control copied from a template, without that step, tends to be described well and operated poorly.
Policies still matter
Policies set authority and accountability. They give regulators, auditors and staff a clear statement of what the organization expects. They are necessary. They are not sufficient, and they should not be reported as risk reduction.
What to do next
-
Pick the ten policy statements tied to your highest risks.
-
For each, name the control that enforces it, its owner, and its evidence.
-
Mark every statement where the honest answer is “people are told”. Those are your gaps.
-
Rank the gaps by risk, not by how easy they are to close.
-
Fix in this order: remove the ability to do the wrong thing, automate the check, then require evidence.
Sources
-
National Institute of Standards and Technology. Special Publication 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations. csrc.nist.gov
-
International Organization for Standardization. ISO/IEC 27001, Information security management systems — Requirements, Annex A. iso.org
-
American Institute of Certified Public Accountants. SOC 2 examinations: Type 1 and Type 2 reports and the Trust Services Criteria. aicpa-cima.com
-
National Institute of Standards and Technology. Cybersecurity Framework 2.0, Govern function. csrc.nist.gov
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionSecure & ComplyTurn regulatory duties into controls that hold up.See how we work →Related service
Control Design & Implementation
Use this to turn requirements into operating controls.