SOC 2 CC3.1: COSO Principle 6: Specifies Suitable Objectives
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.
Work through the SOC 2 assessment, record supporting evidence and review the gaps in your answers.
Requirement summary
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.
Check the source wording and scope in AICPA SOC resources and Trust Services Criteria. The guidance below explains how to approach a review.
In Plain Language
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 to review
- 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 | ISO 27001 A.5.1: Policies for information security | Related |
| nist-csf | nist-csf GV.RM-01 | Related |
| nist-csf | nist-csf GV.RM-02 | Partial overlap |
Frequently Asked Questions
What is the difference between service commitments and system requirements?
How specific do security objectives need to be?
How often should objectives be reviewed?
Related Articles
Compliance Costs: Budgeting for DIY, Consulting and Software
Compare staff time, audit fees, consulting, software and remediation without treating different services as interchangeable.
Read article →SOC 2 for Startups: When You Need It and How to Get Started
A practical guide for startup founders and CTOs on SOC 2 compliance - when it's actually required, Type 1 vs Type 2, realistic costs, and a readiness checklist.
Read article →Track SOC 2 compliance in one place
Work through the SOC 2 assessment, record supporting evidence and review the gaps in your answers.
Start Free AssessmentStart without an account · Sign up only to save