Control procedures are the documented, step-by-step actions that implement a specific security control. They're also the primary evidence that auditors examine when assessing whether a control is actually operating and not just written down.
The term is functionally synonymous with "control activity." Both describe the operational implementation layer below a control: if the control requires encrypting data in transit, the control procedure specifies how TLS is enabled, which versions and cipher suites are permitted, how certificates are provisioned and renewed and who verifies that encryption is active during deployment and ongoing monitoring.
What makes a control procedure auditable is specificity. A usable procedure names the actual systems it applies to, identifies the specific role responsible for each step, states when the activity occurs (on change, daily, quarterly) and references the evidence that confirms each step happened (e.g., a log entry, a ticket number, a signed checklist, etc.). An assessor should be able to walk through the procedure and then observe the stated evidence in the environment.
Generic procedures fail under assessment scrutiny. A procedure that describes a hypothetical process rather than your organization's actual workflow, references tools you don't use, or omits the evidence artifacts that confirm execution, which are consistent findings in NIST 800-171, CMMC and ISO 27001 assessments. They're also entirely preventable.
The cost of missing procedures is higher than most organizations anticipate. Controls without supporting procedures force auditors to treat them as unevidenced, which typically results in findings even when the control is technically implemented. A technically solid security posture with undocumented procedures consistently produces more audit findings than a moderately implemented posture with well-documented procedures.
