The difference between a control and a control statement
Last year I wrote about requirements and controls: requirements describe the "what", controls are the "how". This article is about a confusion one level deeper, and the most common one I see in our field: mistaking the description of a control for the control.
Here is an entry from the NIST SP 800-53 control catalog:
AC-11 Device Lock.
a. Prevent further access to the system by [Selection (one or more): initiating a device lock after [Assignment: organization-defined time period] of inactivity; requiring the user to initiate a device lock before leaving the system unattended]; and
b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.
Many people believe this is a control. It is not. It is a control statement — a description of a control. The difference is the difference between a picture of a car and a car: you can put the picture in a brochure and point at it, but you cannot drive it. The same goes for the text above. It describes a control; it does not do what a control does. It stops no one, and there is nothing in it an auditor could test.
What a control is
ISO/IEC 27002:2022 defines a control as a "measure that maintains and/or modifies risk" (3.1.8). Note 1 lists what qualifies: "any process, policy, device, practice or other conditions and/or actions which maintain and/or modify risk." Read that list as a list of things in the world.
A device: the lock on the server-room door. The camera over the loading dock. The screen that goes dark after ten minutes and asks for a password. You can point at a device, photograph it, watch it work.
A process: something that happens. ISO defines a process as a set of interrelated activities that turn inputs into a result — activities, plural, performed by someone, leaving traces. The leaver ticket from HR reaches IT and the account is disabled before the weekend. A process is not the procedure document that describes it. It is the thing you can sit in on.
A practice: what people habitually do — screens locked when they stand up, two people at the release button. An action: an access right revoked, a server patched.
The one entry made of text — the policy — is a control only because it is in force: "intentions and direction of an organization, as formally expressed by its top management" (3.1.24), approved, communicated and binding. ISO/IEC 27002 draws the line in its introduction: a policy can maintain risk; compliance with it can modify risk.
What all of these share is that they exist in the present tense. The lock holds the door whether or not anyone wrote it into a spreadsheet. And Note 2 — "Controls may not always exert the intended or assumed modifying effect" — describes something only a real thing can do: fail. The lock can be propped open. A description cannot fail. It can only be inaccurate.
That is the test. A control is something you can touch, observe, or watch happening. If there is nothing to observe, there is no control.
What a control statement is
A control statement is a written description of a control. ISO does not define the term; NIST uses it. Open AC-11 in NIST's online catalog and the text above appears under the heading "Control Statement", followed by a "Discussion" and the related controls. The catalog says it itself: the entry is a statement.
AC-11 shows something most catalogs only imply: the entry cannot be your control, because it has blanks in it. NIST calls them organization-defined parameters and leaves them empty on purpose, because the catalog does not know your organization. A control with a blank in it exists nowhere. It is a form — a drawing of a car with the number plate left empty and a note to insert your own.
Filling in the blanks does not create a lock either. "Initiate a device lock after 15 minutes of inactivity" is still a sentence, only more specific. In NIST's Risk Management Framework this is the Select step. The lock comes into existence in the next step, Implement, and only then can you write the specific statement that goes into the system security plan. Your SSP paragraph is a photograph of your car, plate visible. Both are pictures. Neither is the car. (Annex A and the Statement of Applicability — the word is in the name — are the ISO/IEC 27001 equivalents.)
A lock stops an intruder. A statement in a spreadsheet does not.
AC-11: the control and its statement
The control behind AC-11 is the lock — not the word, the mechanism. In one specific company: every workstation enrolled in an endpoint management platform; a configuration profile that locks the screen after 10 minutes of inactivity and replaces the display with a neutral image (AC-11(1), Pattern-Hiding Displays); a keyboard shortcut people use when they walk away, as the acceptable use policy requires; a lock that releases only against password and MFA; a weekly compliance report listing every device on which the profile is not enforced. Five things — a platform, a profile, a habit, an authentication mechanism, a report — all observable. This is the car. Sit at a workstation, wait ten minutes, and the screen goes dark. NIST's own discussion notes that user-initiated locking is "behavior or policy-based" and requires physical action from the user — half of this control is a practice, not a setting.
The control statement describes exactly that: "All workstations are enrolled in [platform]. The profile Endpoint-Baseline enforces a device lock after 10 minutes of inactivity and conceals screen content. Users must lock their device before leaving it unattended (Acceptable Use Policy). The lock is released only by re-authentication with domain credentials and MFA (IA-11). Compliance is verified weekly through the [platform] configuration report."
Notice the direction. The statement is written from the control, after the control exists. The catalog text is written from nowhere — which is why it has blanks, and why it cannot be your control.
Why the difference decides your audit
NIST SP 800-53A, the assessment companion to the catalog, makes the distinction official. The assessor has three methods — examine, interview, test — and four kinds of assessment objects: specifications (documents such as policies, procedures and system security plans), mechanisms (hardware, software or firmware safeguards), activities (protection-related actions people carry out) and individuals. A control statement is a specification: you examine it. A device lock is a mechanism: you test it — exercise it under specified conditions and, in NIST's words, "compare actual with expected behavior". The profile, the report, the screen that actually locks: that is the evidence, and only real controls can produce it.
The test for your own control statements
Four questions:
Who does what?
How often?
In which system?
Where does the record land?
If you cannot name the system, the owner and the evidence, you have not described a control — you have copied a catalog entry, blanks included. You have a picture and no car.
The bottom line
A control is a measure: a process, a policy, a device, a practice, an action that maintains or modifies risk. A control statement is a description of that measure, precise enough that someone can find it and verify it. Control catalogs, e.g. NIST SP 800-53, ISO/IEC 27002, are resources of control statements, that you compare against or derive your controls from. The statements are then brought into life by turning them into actual controls. Remember - a picture of a car is not a car.
References: NIST SP 800-53 Rev. 5 (AC-11, AC-11(1), IA-11; Chapter 2 on organization-defined parameters); NIST SP 800-53A Rev. 5 (assessment methods and objects); NIST SP 800-37 Rev. 2 (RMF); ISO/IEC 27002:2022 (Introduction, 3.1.8, 3.1.24, 3.1.27); ISO/IEC 27001:2022 (Annex A, 6.1.3).