CC5: Control Activities — Policies and Procedures

What Is CC5?

CC5 maps to the COSO Control Activities component. It requires the organization to select and develop control activities that contribute to the mitigation of risks to the achievement of objectives. It has three sub-criteria: CC5.1 (selects and develops control activities), CC5.2 (selects and develops technology general controls), and CC5.3 (deploys controls through policies and procedures).

The link between CC3 (risk assessment) and CC5 (control activities) is critical. Auditors want to see that your controls were chosen because they address identified risks — not just because they seemed like a good idea. A risk register that lists "unauthorized access to production" as a risk should lead to CC5 controls like MFA, least-privilege access, and access reviews.

CC5.1: Controls Selected to Mitigate Identified Risks

CC5.1 requires control activities to address the risks identified in the risk assessment. For each risk in your register, there should be one or more controls that mitigate it. This mapping — from risk to control — is what auditors trace when evaluating CC5.1.

A control library with a risk-to-control mapping table satisfies CC5.1. GRC tools like AuditPath, Vanta, and Drata provide pre-built control libraries that map to SOC 2 criteria and allow you to link controls to risks.

Consider the balance between preventive and detective controls. Preventive controls stop bad things from happening (MFA, least-privilege). Detective controls identify when bad things have occurred (SIEM alerts, access log reviews). Auditors expect a mix of both.

CC5.2: Technology General Controls

CC5.2 specifically addresses controls over technology infrastructure, which is essentially everything: change management, access controls for systems and data, and computer operations. These are sometimes called IT General Controls (ITGCs).

Key technology general controls for SaaS companies: (1) Change management — code changes go through peer review and CI/CD pipelines before production. (2) Access to programs — production access is limited to named individuals with business need, using MFA. (3) Computer operations — automated monitoring of production systems with alerts for anomalies.

Technology controls that are automated and enforced by the system (IAM policies that prevent privilege escalation, branch protection rules that require approvals) are stronger evidence than manual controls that rely on human compliance.

CC5.3: Deploying Controls Through Policies and Procedures

CC5.3 requires that control activities be deployed through policies and procedures that specify what is required and who is responsible. A control that exists in practice but isn't documented in policy is not fully satisfying CC5.3.

Your information security policy should reference specific control activities: "Production database access requires MFA and is limited to the DBA team, reviewed quarterly." The procedure should describe how access is requested, approved, and granted.

Auditors verify CC5.3 by tracing from the policy statement to the actual control operation — they will pull a sample of access grant events and verify they followed the documented procedure.

Segregation of Duties

Segregation of duties (SoD) is a key CC5 principle. The idea is that no single person should have end-to-end control over a critical process, because that creates both error and fraud risk.

For SaaS companies, the most important SoD controls are: developers cannot deploy to production without a second reviewer, engineers cannot approve their own access requests, finance personnel cannot both create and approve vendor payments.

Small companies often struggle with SoD because there aren't enough people. The AICPA acknowledges this — compensating controls like intensive monitoring (reviewing all production deployments in a log) can substitute for strict SoD if the company is too small for full separation.

CC5 Evidence Checklist

(1) Risk-to-control mapping table showing each CC3 risk has mitigating controls. (2) Control library with control owner, description, and frequency. (3) Change management records — pull requests with approvals, CI/CD pipeline logs. (4) Access provisioning records showing approvals were obtained. (5) Information security policy and procedures referencing specific controls. (6) Evidence that SoD is enforced — GitHub branch protection rules, approval workflows in AWS IAM.