SOC 2 CC5.1: Selecting and Developing Control Activities

SOC 2 CC5.1 requires an organization to select and develop control activities that reduce its risks to an acceptable level, choosing each control from the risks the organization actually faces rather than from a generic template. It opens the CC5 series (Control Activities) and turns the risk assessment performed under the CC3 series into a concrete set of preventive and detective controls tied to real business processes.

What does SOC 2 CC5.1 require?

In plain terms, CC5.1 is where risk becomes control. The CC3 risk assessment series identifies what could go wrong and how significant each risk is; CC5.1 requires the organization to choose and build the specific control activities that respond to those risks and bring them down to a level the organization is willing to accept. A control activity is any action a policy or procedure puts in place to address a risk, from enforced multi-factor authentication to a quarterly access review to an automated configuration check.

CC5.1 maps to COSO Principle 10. Its central expectation is a traceable line from a risk in the risk register to the control activity selected to treat it. An auditor reading the risk assessment should be able to follow each significant risk to a control, and each control should exist because a risk called for it, not because it appeared on a vendor checklist.

CC5.1 also expects deliberate choices about how controls are built. That means weighing manual against automated controls and preventive against detective ones, deciding at what level in the organization each control operates, and addressing segregation of duties where one person holding conflicting responsibilities would create risk. Where segregation of duties is impractical, which is common in small teams, CC5.1 expects compensating controls in its place.

What are the CC5.1 points of focus?

The AICPA defines 6 points of focus for CC5.1. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Integrates with the risk assessment. Control activities are selected to carry out the risk responses decided during the CC3 risk assessment, so each control traces back to a specific identified risk.
• Considers entity-specific factors. Control selection accounts for the organization's environment, complexity, nature, and scope, rather than applying a one-size template.
• Determines relevant business processes. The organization identifies which business processes need control activities so coverage follows where the risk sits.
• Evaluates a mix of control activity types. Selection weighs manual and automated controls and preventive and detective controls, choosing a combination suited to the risk.
• Considers at what level activities are applied. Controls are placed at the appropriate level of the organization, from entity-wide down to a specific process or system.
• Addresses segregation of duties. Conflicting duties are separated where practical, and where separation is not feasible, alternative or compensating controls are put in place.

How do you meet CC5.1 in cloud environments?

Cloud environments meet CC5.1 by mapping identified risks to the platform and application controls that treat them, and recording the reasoning:

• Risk-to-control mapping in the risk register. Each risk in the register carries a documented treatment decision and the specific control activity selected to address it, so the selection is traceable rather than assumed.
• Automated preventive controls. Guardrails such as service control policies, IAM permission boundaries, encryption-by-default, and infrastructure-as-code policy checks (for example Config rules or Azure Policy) prevent misconfiguration for the risks that warrant automation.
• Detective controls where prevention is not enough. GuardDuty, Security Hub, Defender for Cloud, and log-based alerting provide the detective half of the mix for risks that cannot be fully prevented.
• Segregation of duties in the identity model. Role separation between developers, deployers, and approvers is enforced through IAM roles and pipeline approvals, with compensating controls (such as peer review and audit logging) where a small team cannot fully separate duties.
• Documented rationale for entity-specific scope. The control set reflects the organization's actual architecture and services in use, with a written note where a common control does not apply because the risk it addresses is not present.

How do you meet CC5.1 on-prem?

On-prem environments apply the same risk-to-control discipline where the controls are configuration, network, and manual process rather than cloud service features:

• Risk register with treatment decisions. Risks to on-prem systems are logged with the selected control activity and the reason it was chosen, giving the same traceable line from risk to control.
• Preventive controls in configuration and network design. Hardened baselines, network segmentation, endpoint protection, and access controls are selected against the specific risks each addresses.
• Detective controls in monitoring. Internal vulnerability scanning, log review, and intrusion detection provide detection for risks that preventive controls do not fully cover.
• Segregation of duties in roles and approvals. Duties such as change requests, approvals, and implementation are separated across people, with documented compensating controls where headcount forces one person to hold more than one role.
• Process controls with named owners. Manual control activities such as access reviews and change approvals are assigned to specific roles so the control operates consistently rather than by memory.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC5.1?

How does CC5.1 map to ISO 27001:2022?

The overlap sits at the risk-treatment clause rather than an Annex A control, because CC5.1 is about how controls are selected, which ISO 27001 handles in Clause 6.1.3 in the main body of the standard. The ISO Statement of Applicability, which records the Annex A controls chosen and the justification for each, is ISO-specific and net-new with no direct SOC 2 equivalent, though the underlying risk-to-control reasoning is the same. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC5.1 opens the CC5 Control Activities series and is followed by CC5.2, which narrows control selection to general controls over technology, and CC5.3, which deploys the selected controls through policies and procedures. The controls CC5.1 selects respond to risks identified in the CC3 risk assessment series, and deficiencies in those controls are evaluated and communicated under CC4.2. Together the three CC5 criteria move from choosing controls, to the technology controls that support them, to the documents that put them into operation.

Frequently Asked Questions

What does SOC 2 CC5.1 mean?

SOC 2 CC5.1 requires an organization to select and develop control activities that reduce its risks to an acceptable level. Each control activity should respond to a risk identified in the risk assessment, cover the business processes where the risk sits, use an appropriate mix of preventive, detective, manual, and automated controls, and address segregation of duties. It is the first criterion in the CC5 Control Activities series and maps to COSO Principle 10.

What evidence satisfies CC5.1?

The core evidence is a risk register with documented treatment decisions, a risk-to-control mapping that traces each significant risk to a specific control activity, a control matrix showing the selected mix of control types, segregation-of-duties or access-role documentation, and notes explaining any control excluded because it does not apply to the organization. Together these show controls were chosen in response to real risks rather than adopted from a template.

How is CC5.1 different from CC5.2 and CC5.3?

CC5.1 covers selecting and developing control activities in general, driven by the risk assessment. CC5.2 narrows the focus to general controls over technology, such as access management and change control over systems. CC5.3 covers deploying the selected controls through policies that state what is expected and procedures that put them into action. CC5.1 chooses the controls, and CC5.2 and CC5.3 refine and operationalize them.

Can we use a template to select our SOC 2 controls?

A template can be a starting point, but CC5.1 expects control activities selected from the organization's own risks and matched to its environment and processes. A control set copied wholesale often includes obligations that do not apply and misses risks specific to the organization. The safer approach is to run the risk assessment first, then select each control because a documented risk calls for it, keeping the traceable line an auditor looks for.

How does CC5.1 handle segregation of duties in a small team?

CC5.1 addresses segregation of duties and expects conflicting duties to be separated where practical. In a small team where full separation is not feasible, the criterion allows alternative or compensating controls in its place, such as peer review, management approval, and detailed audit logging. The key is to document that the conflict was recognized and that a compensating control was deliberately chosen.