The Security criteria is the mandatory foundation of every SOC 2 audit. Organized into nine Common Criteria categories (CC1-CC9), these controls address how your organization protects information assets from unauthorized access, use, disclosure, modification, or destruction. This comprehensive guide provides detailed implementation guidance for each security control category.
Understanding SOC 2 Security Controls
Security controls under SOC 2 are derived from the AICPA's Trust Services Criteria. They represent a risk-based approach to information security, allowing organizations to tailor specific control activities to their unique environment while addressing common control objectives.
The Nine Common Criteria Categories:
- CC1: Control Environment
- CC2: Communication and Information
- CC3: Risk Assessment
- CC4: Monitoring Activities
- CC5: Control Activities
- CC6: Logical and Physical Access Controls
- CC7: System Operations
- CC8: Change Management
- CC9: Risk Mitigation
Each category contains specific control objectives that must be achieved through documented control activities.
CC1: Control Environment
Objective: Establish a foundation of integrity, ethical values, and competence that supports the achievement of security objectives.
Why It Matters
The control environment is the "tone at the top." Without strong governance, clear accountability, and competent personnel, even the best technical controls will fail. Auditors look for evidence that security is embedded in your organizational culture, not just a technical afterthought.
Key Control Points
1. Board or Equivalent Oversight
What's Required:
- Governing body (board of directors, executive team, or advisory board) that exercises oversight over security
- Regular reporting of security matters to governing body
- Evidence of board engagement and decision-making on security issues
Implementation:
- Quarterly board reports on security posture, incidents, and compliance status
- Annual review and approval of information security strategy
- Board-level security committee (for larger organizations)
Evidence:
- Board meeting minutes reflecting security discussions
- Security reports presented to board
- Board approvals of security policies and budgets
2. Organizational Structure and Accountability
What's Required:
- Clearly defined organizational structure with security roles and responsibilities
- Designated security leadership (CISO, Security Manager, etc.)
- Accountability mechanisms for security performance
Implementation:
- Organization chart showing security function placement
- Job descriptions including security responsibilities
- Performance reviews that include security objectives
Evidence:
- Current organizational chart
- Security-related job descriptions
- Performance review documentation
3. Management Philosophy and Operating Style
What's Required:
- Management commitment to integrity and ethical behavior
- Code of conduct or ethics policy
- Mechanisms for reporting violations
Implementation:
- Written code of conduct distributed to all employees
- Annual code of conduct acknowledgment
- Anonymous reporting mechanism (ethics hotline, email)
- Disciplinary actions for violations
Evidence:
- Code of Conduct document
- Employee acknowledgment records
- Ethics training completion records
- Documentation of reported violations and resolution
4. Competence and Development
What's Required:
- Hiring practices ensure competent individuals in security roles
- Ongoing training and professional development
- Background checks for sensitive positions
Implementation:
- Background checks for all employees (at minimum, criminal check)
- Enhanced background checks for employees with privileged access
- Security-specific training during onboarding
- Annual security awareness training for all employees
- Role-specific technical training for security team
Evidence:
- Background check confirmations
- Training attendance records
- Training curriculum and materials
- Professional certifications (CISSP, CISM, etc.)
CC2: Communication and Information
Objective: Obtain, generate, and communicate relevant quality information to support the functioning of security controls.
Why It Matters
Controls can't function if people don't have the information they need. This includes understanding security policies, knowing how to report incidents, and being aware of their responsibilities.
Key Control Points
1. Internal Communication
What's Required:
- Security policies and procedures communicated to relevant personnel
- Regular security updates and awareness communications
- Channels for employees to ask questions and report issues
Implementation:
- Security policy hub (intranet, wiki, or document management system)
- Security newsletter or regular all-hands updates
- Slack/Teams channel for security questions
- Onboarding includes security policy review
Evidence:
- Security policy distribution records
- Security awareness communications (newsletters, emails)
- Onboarding checklist including policy review
- Records of security training and communications
2. External Communication
What's Required:
- Communication of security commitments to customers and stakeholders
- Vendor and partner communication regarding security requirements
- Incident communication procedures
Implementation:
- Privacy policy and security page on website
- Security requirements in vendor contracts
- Customer security questionnaire response process
- Incident notification procedures and templates
Evidence:
- Published privacy policy and security documentation
- Vendor contracts with security clauses
- Examples of customer security questionnaire responses
- Incident notification templates and procedures
CC3: Risk Assessment
Objective: Identify, assess, and respond to risks related to achieving security objectives.
Why It Matters
You can't protect against risks you haven't identified. A comprehensive risk assessment ensures your security controls are aligned with actual threats to your organization.
Key Control Points
1. Risk Identification
What's Required:
- Regular (at least annual) risk assessment process
- Identification of internal and external threats
- Assessment of fraud risk
- Consideration of technology and business changes
Implementation:
- Annual formal risk assessment
- Risk identification workshop with cross-functional team
- Threat modeling for critical systems
- Regular review of industry threat intelligence
Evidence:
- Risk assessment methodology documentation
- Completed risk assessment with identified risks
- Risk assessment meeting notes
- Threat intelligence sources and reviews
2. Risk Analysis
What's Required:
- Risk likelihood and impact assessment
- Risk prioritization methodology
- Risk register with documented risks
Implementation:
- Risk scoring matrix (e.g., likelihood x impact)
- Risk categorization (e.g., high, medium, low)
- Risk register database or spreadsheet
- Risk owner assignment for each identified risk
Evidence:
- Risk scoring methodology
- Risk register with scored and prioritized risks
- Risk ownership documentation
3. Risk Response
What's Required:
- Risk treatment decisions (accept, mitigate, transfer, avoid)
- Control implementation for high-priority risks
- Executive approval of accepted risks
Implementation:
- Risk treatment plan for each high/medium risk
- Control mapping to risks
- Risk acceptance documentation for accepted risks
- Quarterly risk review meetings
Evidence:
- Risk treatment plans
- Control implementation documentation
- Risk acceptance memos approved by executive team
- Quarterly risk review meeting minutes
CC4: Monitoring Activities
Objective: Monitor the effectiveness of security controls and take corrective action when necessary.
Why It Matters
Controls degrade over time. Monitoring ensures controls remain effective and identifies deficiencies before they lead to incidents.
Key Control Points
1. Ongoing Monitoring
What's Required:
- Real-time or near-real-time monitoring of security events
- Automated alerting for anomalies
- Regular review of monitoring outputs
Implementation:
- SIEM (Security Information and Event Management) or log aggregation tool
- Automated alerts for security events (failed logins, unauthorized access)
- Daily review of security alerts by security team
- Intrusion detection/prevention systems (IDS/IPS)
Evidence:
- SIEM configuration and alert rules
- Security alert logs and review records
- IDS/IPS deployment and configuration
2. Periodic Evaluations
What's Required:
- Regular assessment of control effectiveness
- Internal audits or control self-assessments
- Independent testing (penetration tests, vulnerability assessments)
Implementation:
- Quarterly internal control self-assessments
- Annual internal audit
- Annual third-party penetration testing
- Monthly vulnerability scans
Evidence:
- Internal audit reports
- Control self-assessment results
- Penetration test reports
- Vulnerability scan results
3. Deficiency Remediation
What's Required:
- Process for tracking and remediating identified deficiencies
- Timely communication of deficiencies to responsible parties
- Management review of deficiencies
Implementation:
- Deficiency tracking system (Jira, ServiceNow, etc.)
- Severity-based remediation timelines
- Regular (e.g., weekly) deficiency review meetings
- Escalation process for overdue remediations
Evidence:
- Deficiency tracking reports
- Remediation verification evidence
- Management review meeting minutes
CC5: Control Activities
Objective: Deploy policies and procedures to mitigate risks to security objectives.
Why It Matters
This is where strategy meets execution. Control activities are the specific policies, procedures, and technical controls that protect your systems and data.
Key Control Points
1. Policies and Procedures
What's Required:
- Documented policies establishing security expectations
- Procedures operationalizing policies
- Regular review and update of policies
Implementation:
- Core security policies (see CC2)
- Detailed procedures for critical processes
- Annual policy review and update cycle
- Version control for policies and procedures
Evidence:
- Policy and procedure documents
- Policy approval and effective dates
- Annual review and update records
- Version history
2. Control Selection and Development
What's Required:
- Controls selected based on risk assessment
- General IT controls (change management, access controls, etc.)
- Application-specific controls
Implementation:
- Control library or control catalog
- Mapping of controls to risks
- Implementation documentation for each control
Evidence:
- Control library documentation
- Risk-to-control mapping
- Control implementation guides
CC6: Logical and Physical Access Controls
Objective: Restrict access to information assets to authorized users, programs, and processes.
Why It Matters
Unauthorized access is one of the most common attack vectors. Strong access controls are your first line of defense.
Key Control Points
1. User Access Management
What's Required:
- User provisioning and deprovisioning processes
- Unique user credentials
- Periodic access reviews
- Least privilege principle
Implementation:
- Formal access request and approval workflow
- Automated provisioning via SSO/identity provider
- Termination checklist including access revocation
- Quarterly access reviews by managers
- Role-based access control (RBAC)
Evidence:
- Access request tickets and approvals
- Provisioning/deprovisioning logs
- Termination checklist completion records
- Quarterly access review reports with manager attestations
2. Authentication
What's Required:
- Strong authentication mechanisms
- Multi-factor authentication (MFA) for critical systems
- Password policies
Implementation:
- SSO implementation (Okta, Azure AD, Google Workspace)
- MFA required for:
- Production environment access
- Cloud infrastructure admin consoles
- Code repositories
- Email and productivity tools
- VPN access
- Password policy:
- Minimum 12 characters
- Complexity requirements
- No password reuse
- Password manager encouraged
Evidence:
- SSO configuration screenshots
- MFA enrollment reports
- Password policy documentation and enforcement evidence
3. Privileged Access Management
What's Required:
- Restriction and monitoring of privileged access
- Separation of privileged and standard user accounts
- Logging of privileged activities
Implementation:
- Separate admin accounts for privileged access
- Privileged access management (PAM) tool or just-in-time access
- MFA required for all privileged access
- Logging of all privileged commands and actions
- Quarterly review of privileged users
Evidence:
- List of privileged users and their roles
- PAM tool configuration
- Privileged access logs
- Quarterly privileged user review reports
4. Network Security
What's Required:
- Network segmentation
- Firewall configuration and management
- Intrusion detection and prevention
- Secure remote access
Implementation:
- Network segmentation (production, staging, development, corporate)
- Firewall rules following least privilege
- Annual firewall rule review
- IDS/IPS monitoring network traffic
- VPN required for remote access to production systems
Evidence:
- Network architecture diagram
- Firewall rule documentation
- Annual firewall review reports
- IDS/IPS deployment documentation
- VPN configuration
5. Physical Security
What's Required:
- Physical access controls for facilities and data centers
- Visitor management
- Environmental protections (fire, flood, etc.)
Implementation:
- Badge access system for offices
- Visitor log and escort procedures
- Data center physical security (for on-prem):
- Badge access
- Video surveillance
- Environmental controls (HVAC, fire suppression)
- For cloud-hosted: Rely on cloud provider SOC 2 report
Evidence:
- Badge access logs
- Visitor logs
- Data center SOC 2 report (if using colocation)
- Cloud provider SOC 2 report
CC7: System Operations
Objective: Ensure systems operate as designed to support security and availability objectives.
Key Control Points
1. Capacity and Performance Management
What's Required:
- Monitoring of system capacity and performance
- Capacity planning to meet requirements
- Response to performance issues
Implementation:
- Infrastructure monitoring (CPU, memory, disk, network)
- Application performance monitoring (APM)
- Capacity planning based on growth projections
- Alerting for capacity thresholds
Evidence:
- Monitoring dashboards and alert configurations
- Capacity planning documents
- Performance issue resolution tickets
2. Backup and Recovery
What's Required:
- Regular backups of critical data and systems
- Testing of backup restoration
- Documented recovery procedures
Implementation:
- Automated daily backups of production databases
- Weekly full backups, daily incremental backups
- Backups stored in geographically separate location
- Quarterly backup restoration test
- Documented recovery procedures with RTOs and RPOs
Evidence:
- Backup configuration and schedule
- Backup success/failure logs
- Backup restoration test results
- Recovery procedure documentation
3. Incident Management
What's Required:
- Incident detection and response procedures
- Incident logging and tracking
- Post-incident reviews
Implementation:
- Documented incident response plan
- 24/7 incident response capability (on-call rotation)
- Incident classification and severity levels
- Incident ticketing system
- Post-incident review for major incidents
Evidence:
- Incident response plan
- Incident tickets and resolution documentation
- Post-incident review reports
- On-call schedule
CC8: Change Management
Objective: Manage changes to systems in a controlled and secure manner.
Key Control Points
1. Change Authorization and Testing
What's Required:
- Change request and approval process
- Testing before production deployment
- Documentation of changes
Implementation:
- Change management policy and procedures
- Change request template and workflow
- Approval requirements based on change risk
- Testing in staging environment before production
- Change log/calendar
Evidence:
- Change management policy
- Change request tickets with approvals
- Test results and sign-offs
- Change log
2. Emergency Changes
What's Required:
- Procedures for emergency changes
- Post-implementation review of emergency changes
Implementation:
- Emergency change procedures (reduced approval but increased documentation)
- Post-implementation review within 48 hours
- Retroactive testing and validation
Evidence:
- Emergency change procedures
- Emergency change tickets
- Post-implementation review documentation
CC9: Risk Mitigation
Objective: Implement specific control activities to mitigate identified security risks.
Key Control Points
1. Malware Protection
What's Required:
- Anti-malware software on endpoints
- Regular updates and scans
Implementation:
- Endpoint detection and response (EDR) or antivirus on all devices
- Automated signature updates
- Regular scans (daily or continuous)
- Centralized management and monitoring
Evidence:
- EDR/antivirus deployment records
- Scan results and detections
- Update logs
2. Vulnerability Management
What's Required:
- Regular vulnerability scanning
- Risk-based remediation
- Patch management
Implementation:
- Monthly vulnerability scans (authenticated)
- Severity-based remediation timelines:
- Critical: 15 days
- High: 30 days
- Medium: 60 days
- Low: 90 days
- Automated patch deployment for OS and applications
Evidence:
- Vulnerability scan results
- Remediation tracking and verification
- Patch deployment logs
3. Security Awareness Training
What's Required:
- Regular security training for employees
- Training content relevant to roles
- Tracking of training completion
Implementation:
- Security awareness training during onboarding
- Annual refresher training for all employees
- Role-specific training (e.g., secure coding for developers)
- Phishing simulation exercises
Evidence:
- Training curriculum
- Training completion records
- Phishing simulation results
Evidence Collection and Organization
For each control, you'll need to provide evidence. Best practices:
1. Organize by Control Category
- Create folder structure mirroring CC1-CC9
- Name files clearly (e.g., "CC6_Quarterly_Access_Review_Q1_2025.pdf")
2. Automate Evidence Collection
- Use compliance platforms (Vanta, Drata) to automate screenshots and log collection
- Schedule reports to run automatically
- Set calendar reminders for manual evidence collection
3. Maintain Continuous Evidence
- Don't wait until audit to collect evidence
- Collect as you go throughout the year
- This makes Type II audits much easier
4. Document Control Execution
- For each control, document:
- What the control is
- Who performs it
- How frequently
- What evidence is generated
- Where evidence is stored
Conclusion
Implementing SOC 2 Security controls is a significant undertaking, but it genuinely strengthens your security posture. By systematically addressing each Common Criteria category, documenting your controls, and collecting evidence, you build a robust, auditable security program that not only satisfies auditors but protects your organization and your customers.
Remember: SOC 2 is not about perfection, it's about demonstrating a systematic, risk-based approach to security with effective controls and continuous improvement.