Requirements, controls, and evidence are the three primitives of compliance work. Mixing them up is the single most common root cause of compliance programs that feel chaotic, and of control documents that do not hold up under audit. This article separates the three cleanly and walks through a worked example.
The vocabulary problem
The words 'requirement,' 'control,' and 'evidence' are used loosely in most compliance conversations. In one tool a 'control' is what another tool calls a 'requirement.' In a third tool the word 'evidence' refers to a folder of PDFs that are actually screenshots of configuration pages, which are not quite evidence but not quite controls either. The loose vocabulary does not matter for small programs, but as a program grows and more people touch it, the imprecision accumulates into findings.
Requirement
A requirement is what a regulator, standard body, or internal policy says you must do. It is a statement of obligation, usually written by someone outside your organization. It lives in a source document — a regulation, a framework, or an internal policy. Requirements do not tell you how to satisfy them; they only tell you what has to be true. Example: "Access to systems that process cardholder data must be limited to individuals whose job requires such access."
Control
A control is a specific mechanism your organization puts in place to satisfy one or more requirements. It describes what you actually do. It has an owner, a cadence, and an operational implementation. One control can satisfy multiple requirements, and one requirement can be satisfied by multiple controls. Example: "Access to the payments database is granted only through a time-bound, manager-approved role assignment. The role assignment is reviewed weekly for anomalies and quarterly for ongoing necessity."
Evidence
Evidence is the artifact that demonstrates the control is working. It is produced by the operation of the control and captured on a cadence that matches the control's rhythm. It has a source system, a timestamp, and a scope. Example: "A weekly export from the identity provider showing all active assignments to the payments-db role, together with the manager approval record for each assignment."
Worked example: SOC 2 CC6.1 end-to-end
SOC 2 Common Criteria 6.1 says "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives." That is the requirement. The control might be "production systems require multi-factor authentication for all interactive user access, enforced at the identity provider and monitored for bypass attempts." That is what the organization actually does. The evidence might be "a quarterly export from the identity provider showing MFA enforcement status for all users with production access, together with a monthly export of bypass attempt alerts from the monitoring system." Requirement, control, evidence — three different artifacts, each serving a different purpose.
Why mixing them up is expensive
When requirements and controls are merged into one object, you cannot respond cleanly to a regulatory amendment — because the control is tied to the old text of the requirement and rewriting the requirement rewrites the control. When controls and evidence are merged, evidence becomes a thing that "describes the control" rather than a thing that "demonstrates the control is working," and auditors stop trusting it. The three-layer structure exists for a reason, and the reason is that it lets each layer change independently. A regulator amends a requirement; you update the requirement record and re-evaluate the mapping. A team changes how a control is implemented; you update the control and leave the requirement alone. A new collection method becomes available; you update the evidence rule without touching either.
A rule of thumb
If you can read a sentence in your compliance program and not know whether it is a requirement, a control, or a piece of evidence, you have mixed up the layers. Pull it apart. Your future self will thank you during the next audit.
Key takeaways
- Requirement = what you must do. Control = how you do it. Evidence = proof you are doing it.
- One control can satisfy multiple requirements. One requirement can be satisfied by multiple controls.
- Evidence demonstrates a control is working — it does not describe the control.
- Mixing the three layers makes regulatory amendments and operational changes much more expensive.