SOC 2 CC3.1: Specifying Objectives With Enough Clarity to Assess Risk

SOC 2 CC3.1 requires an entity to state its objectives clearly enough that the risks to those objectives can be identified and assessed. It opens the CC3 series (Risk Assessment), and a frequent finding under it is a company that runs a real risk conversation on a real cadence but never wrote down the objectives or the risk tolerances that conversation is supposed to protect.

What does SOC 2 CC3.1 require?

CC3.1 is the foundation the rest of the risk assessment series stands on. Risk only means something in relation to an objective, so before an entity can identify risks under CC3.2 it has to say what it is trying to achieve and how much variation from that it is willing to accept. The criterion asks for objectives written with enough precision that someone can look at them and name what could go wrong.

For a SOC 2 engagement the objectives that matter most are the security, availability, processing integrity, confidentiality, and privacy commitments the company makes to its customers. CC3.1 expects those to be expressed as sub-objectives that risk assessment can work against, not left implied. A commitment such as keeping customer data confidential turns into a testable objective only when the entity states what confidentiality means for its system and what level of assurance it is committing to.

The criterion also reaches into risk appetite. Objectives that carry an acceptable level of variation give the risk assessment a threshold to measure against, which is what separates a risk that gets accepted from one that gets treated. Without that threshold every risk looks either trivial or catastrophic, and the assessment produces no useful ranking.

What are the CC3.1 points of focus?

The AICPA defines 16 points of focus for CC3.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.

• Operations objectives. Objectives reflect management's choices about structure, industry, and performance; set acceptable levels of variation (risk tolerance); include operations and financial performance goals; and form the basis for committing resources.
• External financial reporting objectives. Reporting complies with applicable accounting standards, considers materiality, and reflects the entity's underlying transactions and events.
• External nonfinancial reporting objectives. Reporting complies with externally established frameworks and standards, considers the required level of precision, and reflects the entity's activities.
• Internal reporting objectives. Internal reporting reflects management's choices, considers the required level of precision, and reflects the entity's activities.
• Compliance objectives. Objectives reflect external laws and regulations that set minimum standards of conduct, and consider acceptable levels of variation.
• Sub-objectives for the trust services criteria (the SOC 2 point of focus). Management identifies sub-objectives for security, availability, processing integrity, confidentiality, or privacy to support risk assessment against the entity's commitments.

Most of the reporting categories carry over from COSO's internal-control-over-financial-reporting origins. For a service organization pursuing SOC 2 on the security categories, the last point of focus is the one auditors weigh most, because it is where the trust commitments become measurable objectives.

How do you meet CC3.1 in cloud environments?

Cloud environments meet CC3.1 by turning provider-shared commitments into stated objectives with clear tolerances:

• Security and confidentiality sub-objectives written against customer commitments. The confidentiality and security promises in the terms of service and trust center become explicit objectives in the risk assessment scope, so risks can be measured against them.
• Availability objectives expressed as targets. Service level objectives, recovery time and recovery point targets, and the acceptable variation around them are documented rather than assumed, giving the risk assessment a threshold.
• Objectives that respect the shared responsibility split. The objectives name what the provider owns and what the entity owns, so risk identification does not double-count inherited controls or miss the parts the customer is responsible for.
• Data residency and regulatory objectives. Where customers or regulators require data to stay in a region, that requirement becomes a stated compliance objective with a defined tolerance.

A GRC platform does not satisfy CC3.1 on its own. It can hold the objectives and risk tolerances once they are written, but the control is management deciding and documenting what the entity is committing to; the platform stores the statement rather than being the statement.

How do you meet CC3.1 on-prem?

On-prem and hybrid environments carry the same requirement across a wider set of objectives, because the entity owns more of the stack. The risk management guide for hybrid and on-prem environments covers the detail; the shape is:

• Availability and recovery objectives the entity owns end to end. Recovery time and recovery point objectives for self-hosted systems are stated with real numbers, since no provider absorbs the outage.
• Physical and environmental objectives. Objectives cover the data center or colocation space, including physical access and environmental resilience, because those risks are the entity's to carry.
• Data residency as a first-class objective. Where data must stay in a named jurisdiction, the objective states the region and the tolerance, and the risk assessment measures against it.
• Documented risk appetite for concentration and key-person risk. Running production from a single facility or depending on a small ops team is a known exposure; stating the acceptable level of variation makes the later acceptance or treatment decision defensible.

Objectives do not have to be elaborate to satisfy CC3.1. A short set of clearly stated commitments with defined tolerances beats a long strategy document that never names what would count as failure.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC3.1?

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

ISO 27001 Clause 6.1.2 requires an organization to set risk acceptance and assessment criteria before it identifies risks, which is the same discipline CC3.1 asks for: define what you are protecting and how much variation you will accept, then assess against it. Organizations pursuing both frameworks can reuse the objectives, risk criteria, and risk assessment report across CC3.1 and Clause 6.1.2. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC3.1 sets the objectives that the rest of the CC3 series assesses risk against. The next criterion, CC3.2, identifies and analyzes the risks to those objectives across the entity. CC3.4 revisits the objectives when the business, its systems, or its environment change enough to affect internal control. Because CC3.1 is where the trust commitments become measurable, it also connects to the availability, confidentiality, and processing integrity category criteria that state what those commitments mean for the system.

Frequently Asked Questions

What does SOC 2 CC3.1 mean?

SOC 2 CC3.1 means an entity must state its objectives clearly enough that risks to those objectives can be identified and assessed. For SOC 2 that centers on security, availability, processing integrity, confidentiality, and privacy sub-objectives tied to customer commitments, each with an acceptable level of variation the risk assessment can measure against.

What evidence satisfies CC3.1?

The core evidence is a risk assessment policy, a documented set of system objectives and trust commitments, a stated risk appetite or tolerance, and a risk register that ties identified risks back to the objectives they threaten. Management or committee minutes show the right people set and reviewed the objectives.

What are objectives and sub-objectives in SOC 2 CC3.1?

Objectives are what the entity is trying to achieve; sub-objectives break those down into the security, availability, processing integrity, confidentiality, or privacy commitments that risk assessment works against. The sub-objectives point of focus is the one added specifically for the trust services criteria, and it is where SOC 2 risk assessment starts.

How is CC3.1 different from CC3.2?

CC3.1 is about specifying objectives with enough clarity and tolerance to make risk assessable. CC3.2 is the next step: identifying the risks to those objectives across the entity and analyzing their significance. CC3.1 defines the target, CC3.2 finds what could hit it.

Does CC3.1 require a documented risk appetite?

CC3.1 expects objectives to include an acceptable level of variation, which in practice means a stated risk appetite or tolerance. It does not have to be elaborate. A short statement of how much variation the entity will accept for each objective gives the risk assessment a threshold, without which every risk looks either trivial or catastrophic.