CC3.1 SOC 2

SOC 2 CC3.1: COSO Principle 6: Specifies Suitable Objectives

What This Control Requires

The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. Objectives are defined at all levels and are consistent with the entity's mission, supporting the identification of risks to the achievement of those objectives.

In Plain Language

If you can't clearly articulate what you're protecting and why, your entire risk management programme is built on sand. Auditors look for a direct line between your business goals, your security objectives, and the controls you've chosen - and they'll notice quickly if that line is fuzzy or missing.

In practical terms, you need to define what you're protecting (data, systems, services), how much security is actually required (driven by regulations, contracts, and business context), and what counts as an acceptable versus unacceptable outcome. These objectives should be specific enough to measure, and they need to cover every service commitment and system requirement described in your SOC 2 report.

For the audit itself, assessors will check that you've documented your service commitments (what you promise customers) and system requirements (what the system needs to do), and that these translate into specific, assessable objectives driving your risk assessment and control selection.

How to Implement

Start by documenting your service commitments - the promises you make to customers about security, availability, processing integrity, confidentiality, and privacy. Pull these from your SLAs, terms of service, privacy policies, and even marketing materials.

Turn each service commitment into concrete system requirements. If you promise 99.9% uptime, the system requirement is maintaining that threshold with proper monitoring and redundancy. Be explicit about what the system must actually do to keep each promise.

Define security objectives aligned to each trust services category in scope (security, availability, confidentiality, processing integrity, privacy). Make them measurable. "Ensure all production access requires multi-factor authentication" is useful. "Maintain good security" is not.

Set risk tolerance levels for each objective and get management sign-off. Document these in a risk appetite statement. Not every objective carries the same weight - your tolerance for a customer data breach should be very different from your tolerance for a minor logging gap.

Communicate objectives to everyone who needs to know, and review them regularly. Update when you launch new services, adopt new technology, face new regulations, or learn from incidents.

Build a traceability matrix that maps business objectives to security objectives to specific controls. This is what proves your controls are purposeful rather than arbitrary - and auditors love seeing it.

Evidence Your Auditor Will Request

Documented service commitments from SLAs, terms of service, and customer contracts
System requirements derived from service commitments with measurable criteria
Security objectives aligned with applicable trust services criteria categories
Risk appetite or risk tolerance statement approved by management
Traceability matrix mapping objectives to controls and risk assessment findings

Common Mistakes

Security objectives are vague and not specific enough to be measured or assessed
Service commitments in customer contracts are not translated into concrete system requirements
No documented risk appetite or tolerance levels to guide risk assessment and control selection
Objectives are created once and never reviewed or updated as the business evolves
Disconnect between stated business objectives and the controls actually implemented

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.1	Related
nist-csf	GV.RM-01	Related
nist-csf	GV.RM-02	Partial overlap

Frequently Asked Questions

What is the difference between service commitments and system requirements?

Service commitments are what you promise customers - uptime guarantees, data protection standards, privacy practices, and so on. System requirements are the technical and operational capabilities your system needs in order to actually deliver on those promises. So a commitment of 99.9% uptime translates into system requirements for redundancy, failover, monitoring, and incident response. Think of commitments as the 'what' and requirements as the 'how'.

How specific do security objectives need to be?

Specific enough that you could actually test whether you're meeting them. "Maintain good security" tells you nothing. "All administrative access requires MFA, critical patches applied within 30 days, all employees complete security training annually" - that's something you can measure, assess, and prove to an auditor. The more concrete, the easier the audit.

How often should objectives be reviewed?

At minimum, annually as part of your risk assessment cycle. But you should also revisit them whenever something significant changes - new services, major technology shifts, regulatory updates, or lessons from a security incident. Document every review and any changes that result from it. Auditors want to see that this is a living process, not a one-off exercise.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment