What is a control?

What a good control looks like

A control is written as something a person or system does, often enough that an auditor can check it. “Access is managed” is an aim. “The engineering lead reviews production access every quarter and removes anything the role does not need” is a control: it has an owner, a frequency, a scope and a result that leaves a record.

Controls can be technical, such as encryption settings or MFA enforced by the identity provider, or procedural, such as a change approval or an onboarding checklist. Most programmes need both, because a technical setting still needs someone to check that it stays on.

• Preventive. Stops the problem happening, such as blocking logins without MFA.
• Detective. Finds the problem after it happens, such as an alert when a log source stops sending.
• Corrective. Limits the damage and restores normal running, such as restoring from a tested backup.

How frameworks use controls

ISO 27001:2022 lists 93 reference controls in Annex A. You choose the ones your risks call for and record each decision in the Statement of Applicability. NIST SP 800-171 sets 110 requirements that a defence contractor handling CUI must meet. SOC 2 works the other way round: the Trust Services Criteria describe what must be achieved, and each company writes its own controls to meet them.

That difference matters when you run more than one framework. A single well-written control, such as the quarterly access review, can satisfy requirements in several frameworks at once. That is the idea behind control mapping.

How auditors test a control

Auditors look at two things. Design asks whether the control, as described, would reduce the risk if it ran. Operating effectiveness asks whether it actually ran, every time it should have, across the period. A SOC 2 Type I report covers design on a single date; a Type II report also covers operation over an observation period.

To test operation, the auditor asks for the full population, such as every leaver in the period, and picks a sample to check against the evidence. A control that runs but leaves no record gives the auditor nothing to test, and will usually be counted as not having run.

When a control cannot be run as a framework describes, a compensating control can sometimes stand in, provided the reason is documented and the risk owner accepts it.

Related terms

Control mapping

Linking one control to every framework requirement it satisfies, so the same control and its evidence count towards SOC 2, ISO 27001 and other frameworks at once.

Evidence

Any record that shows a control operated: a configuration export, a ticket, a signed policy, an access review. Auditors sample evidence across the period they are reporting on.

Compensating control

An alternative safeguard used when a required control cannot be implemented as written, documented with the reason and accepted by the risk owner.

Annex A

The list of 93 reference controls in ISO 27001:2022, grouped into organisational, people, physical and technological themes. You select from it and justify every exclusion in the Statement of Applicability.

Risk register

The list of identified risks with an owner, likelihood, impact, treatment and review date, linked to the controls that treat each one. Usually the first document an auditor asks to see.