SOC 2 criteria, one by one
What each criterion asks for in plain words, what an auditor tests, the exceptions that come up most, and how it maps to ISO 27001 and NIST CSF.
38 criteria
CC1 · Control environment
The tone, structure and people behind every other control.
- CC1.1 Commitment to integrity and ethical values
- CC1.1 asks whether leadership sets and enforces standards of integrity and ethical conduct, usually through a code of conduct people acknowledge.
- CC1.2 Independent oversight by the board
- CC1.2 asks whether a board or equivalent body, independent of management, oversees how internal control is designed and run.
- CC1.3 Structure, reporting lines and authority
- CC1.3 asks whether management has set up an organisational structure, reporting lines and responsibilities that let the security programme work.
- CC1.4 Attracting, developing and keeping competent people
- CC1.4 asks whether you hire, train and retain people competent for their roles, including background checks where policy requires them.
- CC1.5 Holding people accountable
- CC1.5 asks whether people are held accountable for their internal control responsibilities, through reviews, incentives and a disciplinary process.
CC2 · Information and communication
Getting the right information to the people who run and rely on controls.
- CC2.1 Quality information to support controls
- CC2.1 asks whether you produce and use relevant, good-quality information so internal control works, from monitoring data to system reports.
- CC2.2 Communicating internally about control
- CC2.2 asks whether you tell staff what they need to know about security objectives and their responsibilities, through policies, training and channels.
- CC2.3 Communicating with customers and other parties
- CC2.3 asks whether you communicate with customers, vendors and others about commitments, system changes, outages and incidents that affect them.
CC3 · Risk assessment
Finding, analysing and revisiting the risks to your service commitments.
- CC3.1 Setting objectives clear enough to assess risk
- CC3.1 asks whether your objectives are specific enough to identify and assess the risks to them, starting with the commitments you make to customers.
- CC3.2 Identifying and analysing risk
- CC3.2 asks whether you identify risks to your objectives across the whole system, analyse them, and decide how each one will be managed.
- CC3.3 Considering the risk of fraud
- CC3.3 asks whether your risk assessment considers fraud, including incentives, opportunity and how someone could override or bypass controls.
- CC3.4 Assessing the impact of significant change
- CC3.4 asks whether you identify and assess changes that could significantly affect internal control, such as new products, vendors, leadership or regulation.
CC4 · Monitoring activities
Checking that controls keep working, and acting on what you find.
- CC4.1 Ongoing and separate evaluations of controls
- CC4.1 asks whether you check that controls are present and working, through continuous monitoring, internal reviews and independent tests like pen tests.
- CC4.2 Communicating and fixing control deficiencies
- CC4.2 asks whether control deficiencies are reported to the people who can fix them, including leadership, and tracked until they are resolved.
CC5 · Control activities
Choosing controls for the risks, and writing them down as policy.
- CC5.1 Selecting controls that mitigate risk
- CC5.1 asks whether you choose and build control activities that bring the risks from your risk assessment down to acceptable levels.
- CC5.2 General controls over technology
- CC5.2 asks whether you select and build general controls over technology, such as access, change and operations, that support your objectives.
- CC5.3 Policies and procedures that put controls into action
- CC5.3 asks whether controls are written down as policies saying what is expected, and procedures that put those policies into practice.
CC6 · Logical and physical access
Who can reach systems and data, how they prove it, and how access ends.
- CC6.1 Logical access security over systems and data
- CC6.1 asks whether you protect information assets with logical access controls: inventory, identity, authentication, encryption and segmentation.
- CC6.2 Registering and authorising users
- CC6.2 asks whether new users are registered and authorised before they get access, and whether access is removed when it is no longer needed.
- CC6.3 Role-based access and least privilege
- CC6.3 asks whether access is granted, changed and removed based on role and least privilege, with segregation of duties and periodic review.
- CC6.4 Physical access to facilities and assets
- CC6.4 asks whether physical access to facilities, data centres and sensitive equipment is restricted to authorised people and reviewed.
- CC6.5 Disposing of data and assets securely
- CC6.5 asks whether you remove the ability to read data from assets you retire, through secure deletion or destruction of media and devices.
- CC6.6 Protecting the system boundary
- CC6.6 asks whether you protect against threats from outside the system boundary, with controls like firewalls, MFA for remote access and filtering.
- CC6.7 Restricting how data moves and is transmitted
- CC6.7 asks whether you restrict and protect the movement of data, encrypting it in transit and controlling removable media and transfers.
- CC6.8 Preventing and detecting malicious software
- CC6.8 asks whether you prevent or detect unauthorised or malicious software, through endpoint protection, hardened baselines and change control.
CC7 · System operations
Detecting problems, responding to incidents and recovering from them.
- CC7.1 Detecting vulnerabilities and configuration drift
- CC7.1 asks whether you detect changes and vulnerabilities that could open the system to attack, through scanning, configuration monitoring and patching.
- CC7.2 Monitoring for anomalies and attacks
- CC7.2 asks whether you monitor systems for anomalies that could indicate attacks, failures or errors, and analyse what you find.
- CC7.3 Evaluating security events
- CC7.3 asks whether you evaluate security events to decide if they are incidents, and act on those that could stop you meeting your objectives.
- CC7.4 Responding to security incidents
- CC7.4 asks whether you respond to identified security incidents with a defined plan: contain, remediate, communicate and learn.
- CC7.5 Recovering from security incidents
- CC7.5 asks whether you can restore operations after an incident, with recovery plans, backups that work and lessons fed back into controls.
CC8 · Change management
How changes to systems get authorised, tested and released.
- CC8.1 Managing changes to systems
- CC8.1 asks whether changes to infrastructure, data and software are authorised, designed, tested, approved and documented before they reach production.
CC9 · Risk mitigation
Business disruption risk and the risk that comes from vendors.
- CC9.1 Mitigating business disruption risk
- CC9.1 asks whether you identify and plan for risks of business disruption, through continuity planning, resilience measures and insurance.
- CC9.2 Managing vendor and business partner risk
- CC9.2 asks whether you assess and manage risk from vendors and business partners, from due diligence before onboarding to periodic review.
A1 · Availability
Capacity, backups and recovery for the uptime you promise.
- A1.1 Managing capacity
- A1.1 asks whether you monitor and manage capacity so the system can meet its availability commitments, and plan for demand you can foresee.
- A1.2 Backups and recovery infrastructure
- A1.2 asks whether the environmental protections, backups and recovery infrastructure behind your availability commitments are in place and monitored.
- A1.3 Testing recovery
- A1.3 asks whether you test recovery plans, including restoring from backup, so you know you can meet your availability commitments after a failure.
C1 · Confidentiality
Identifying confidential information, protecting it and disposing of it.
- C1.1 Identifying and protecting confidential information
- C1.1 asks whether you identify confidential information and protect it from creation to retention, in line with your confidentiality commitments.
- C1.2 Disposing of confidential information
- C1.2 asks whether you dispose of confidential information when it reaches the end of its retention period or the customer asks for deletion.
Trust, settled.
Noru maps every criterion to your own controls and collects the evidence as it happens.