CC5 — Control Activities — is the execution layer of the SOC 2 control environment. Where CC3 identifies risks and CC4 monitors whether controls are working, CC5 is about the specific activities deployed to mitigate those risks. In COSO terms, control activities are “the actions established through policies and procedures that help ensure that management’s directives to mitigate risks to the achievement of objectives are carried out.”
CC5 is broad by design. It covers the full range of control types: preventive controls (MFA, encryption, firewall rules), detective controls (logging, alerting, access reviews), corrective controls (incident response, patch management), and manual controls (approvals, sign-offs, management reviews). The key requirement is not that every possible control is implemented, but that the controls selected are appropriate for the risks identified and are consistently applied.
The Three CC5 Requirements
| CC5 Sub-Requirement | What Auditors Test | Key Evidence |
|---|---|---|
| Controls selected and deployed to address risks | For each risk in the CC3 risk register, there is at least one control that treats it. Controls are implemented, not just described. | Risk-to-control mapping; control implementation evidence (screenshots, configurations, policies) |
| Technology controls operating as designed | Technology controls — firewalls, MFA configurations, encryption settings, access control lists — are configured correctly and consistently applied | Configuration exports; screenshots of system settings; comparison of actual configurations to documented baseline |
| Controls deployed across relevant processes and infrastructure | Controls are not applied selectively — a control that applies to production systems applies to all production systems, not just the primary ones auditors might inspect | Infrastructure inventory; evidence of control coverage across all in-scope systems |
Policies and Procedures as Control Activities
A significant component of CC5 is the formal documentation of policies and procedures. Auditors will review these documents and test whether they are reflected in actual practice. A policy that says “access reviews are performed quarterly” is a CC5 control activity — but it satisfies CC5 only if access reviews are actually performed quarterly and documented. The policy is necessary but not sufficient.
The core policies required for CC5 coverage include the information security policy, access control policy, change management policy, incident response policy, vendor management policy, and acceptable use policy. Each policy should specify: the control objective, the specific controls deployed, the frequency or triggers for each control, and the person or role responsible. Generic template policies that have not been tailored to the organization’s actual practices are a common readiness finding.
| IMPORTANT | Auditors compare policy language to operational evidence. If your access control policy says “access reviews are performed quarterly by the system owner,” auditors will request evidence of four quarterly access reviews during a 12-month observation period, signed off by the system owner. If the evidence shows reviews were annual, or performed by a different role, that discrepancy is a finding — even if the underlying security practice was adequate. |
Technology Controls: Configuration as Evidence
For technology controls, CC5 testing is largely configuration-based. Auditors will request exports of security settings from cloud consoles, identity providers, and security tools. They will compare these configurations to the documented baselines in your policies. Common technology control evidence requests include: MFA enforcement settings from the identity provider (Okta, Azure AD, Google Workspace), firewall rule sets or network security group configurations, encryption settings for storage and data in transit, and backup configuration and retention settings.
| BITLION INSIGHT | Configuration drift is the silent enemy of CC5 compliance. A control that was correctly configured at the start of the observation period but drifted — an MFA exception added for a contractor, a firewall rule opened for a temporary test that was never closed — can generate a CC5 exception. Automated configuration compliance tools (AWS Config, Azure Policy, Wiz, Orca) that alert on drift from the security baseline are the most efficient way to prevent this. |