Before you can assess risks, you need to define what you are trying to protect. This criterion asks whether your security objectives are written down clearly enough that risk identification is possible. A security objective like 'protect customer data' is too vague. The auditor wants to see that your objectives are specific enough that when something threatens them, you would know it.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Documented security objectives aligned to services and data in scope
Implementation Steps
Define security objectives in your Information Security Policy or a dedicated Risk Assessment Policy, objectives must be specific enough to be testable (e.g., 'maintain 99.9% availability of the production API' or 'prevent unauthorized access to customer PII')
Map your security objectives to your SOC 2 scope: what systems, data types, and services are in scope, and what properties (security, availability, confidentiality) must be maintained
Establish a formal risk assessment schedule: annual minimum, with ad-hoc assessments triggered by material changes to the environment
Use the system description in your SOC 2 report to define the boundary around which objectives apply, this document serves dual purpose as objective definition and audit evidence
Tools / Systems
Information Security PolicyRisk Assessment and Treatment PolicyConfluence / Notion (policy documentation)GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Typical Control Documented security objectives aligned to services and data in scope
Evidence Artifacts
Information Security Policy or Risk Assessment Policy containing documented security objectives
SOC 2 system description defining the scope boundary and relevant Trust Services Criteria
Asset inventory showing systems in scope and their data classifications
📅Annual policy review; system description updated when scope changes
Cross-framework mappings coming in v1.1
When we add ISO 42001 and ISO 27001, you'll see which controls map to this criterion.
ISO
ISO 42001
AI Management Systems
ISO
ISO 27001
Information Security
Mapping data will appear here automatically when the frameworks are published.
CC3.2
Identifies and analyzes risks to achievement of objectives
Risk Assessment
3 evidence1 control
CC3.3
Considers potential for fraud in assessing risks
Risk Assessment
3 evidence1 control
CC3.4
Identifies and assesses significant changes
Risk Assessment
3 evidence1 control
CC4.1
Selects, develops, and performs ongoing and separate evaluations
Monitoring Activities
6 evidence2 controls
CC4.2
Evaluates and communicates internal control deficiencies
Monitoring Activities
3 evidence1 control
CC5.1
Selects and develops control activities that mitigate risks
Control Activities
3 evidence1 control
CC5.2
Selects and develops general controls over technology
Control Activities
6 evidence2 controls
CC5.3
Deploys control activities through policies and procedures
Control Activities
3 evidence1 control
CC6.1
Logical access security infrastructure
Logical and Physical Access Controls
11 evidence3 controls
CC6.2
Registration and authorization prior to issuing credentials
Logical and Physical Access Controls
6 evidence2 controls
CC6.3
Role-based access management
Logical and Physical Access Controls
6 evidence2 controls
CC6.4
Physical access restrictions
Logical and Physical Access Controls
3 evidence1 control
CC6.5
Disposal and destruction of information assets
Logical and Physical Access Controls
3 evidence1 control
CC6.6
Controls against threats from outside system boundaries
Logical and Physical Access Controls
8 evidence2 controls
CC6.7
Restricts transmission and movement of information
Logical and Physical Access Controls
7 evidence2 controls
CC6.8
Controls to prevent or detect unauthorized software
Logical and Physical Access Controls
6 evidence2 controls
CC7.1
Detection and monitoring for vulnerabilities
System Operations
8 evidence2 controls
CC7.2
Monitoring for anomalies and security events
System Operations
4 evidence1 control
CC7.3
Evaluation of security events as security incidents
System Operations
4 evidence1 control
CC7.4
Incident response program
System Operations
4 evidence1 control
CC7.5
Recovery from security incidents
System Operations
4 evidence1 control
CC8.1
Authorized change management process
Change Management
8 evidence2 controls
CC9.1
Risk mitigation for business disruptions
Risk Mitigation
4 evidence1 control
CC9.2
Vendor and business partner risk management
Risk Mitigation
4 evidence1 control
Help us build what matters.
Vote for the next framework, subscribe for updates, and let us know if you'd contribute.
What should we add next?
Vote for the framework you need most.
0
ISO 42001
0
ISO 27001
0
CMMC
0
CPCSC
Stay Updated
Get notified when new frameworks and features are added.
On-premises implementation and evidence
Documented security objectives aligned to services and data in scope
Implementation steps
Document the security objectives for your system in a risk assessment policy that names specific systems, data classifications, and the security properties required
Create an asset inventory that maps each asset to its data classification and the security objectives that apply to it
Review and update objectives at least annually to confirm they still reflect the business context and system scope
Tools / systems
Risk Assessment and Treatment Policy
Asset inventory spreadsheet
Wazuh (asset visibility)
GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Evidence artifacts
Risk Assessment Policy with security objectives and scope definition
Asset inventory with data classification and applicable security objectives
Annual policy review sign-off by management
Evidence frequency: Annual; updated on material scope changes
