Framework

SOC 2 Trust Services Criteria: the clauses behind the split

The Trust Services Criteria a SOC 2 report is written against. The criteria for vendor management, logical access and change sit behind the areas they cover.

Shown when ticked. The framework on the compliance library.

Control areas it anchors

Area	Clause
Governance and policy	SOC 2 CC1.3
Identity and access	SOC 2 CC6.2
Data classification and handling	SOC 2 C1.1
Network security	SOC 2 CC6.6
Logging and monitoring	SOC 2 CC7.2
Vulnerability and patch management	SOC 2 CC7.1
Configuration and hardening	SOC 2 CC8.1
Application security	SOC 2 CC8.1
Incident response	SOC 2 CC7.4
Business continuity and backup	SOC 2 A1.2
Physical and environmental	SOC 2 CC6.4
Supplier and subservice	SOC 2 CC9.2
AI use and data retention	SOC 2 P4.2

Every clause cited, quoted

12 of the 61 held

The requirement text is our statement of each clause, read against the copy we hold and cited to it; it is not the instrument verbatim.

SOC 2 A1.2 Environmental protections, data backups, and recovery infrastructure support availability

Authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives

What an assessor asks to see:

Evidence of environmental protections at the facilities in scope, covering fire detection and suppression, power continuity, cooling and water detection, with testing and maintenance records
The backup configuration showing scope, frequency and retention against the recovery point objective
Evidence of protection of backup data, including encryption, access restriction and an immutable or offline copy
Evidence of the recovery infrastructure, including alternative processing capability and its readiness
Evidence these are authorised, approved, maintained and monitored, including who approved the design

Where it usually falls short:

Backups configured with failures reported and never investigated, so gaps in the backup set are unknown
Backups reachable using production credentials, so a single compromise destroys both
Environmental protections at the primary site only, with the recovery site unassessed
Reliance on a cloud provider's environmental controls with no review of their assurance report or of the complementary controls it assumes

Source: SOC 2 Trust Services Criteria

SOC 2 C1.1 Confidential information is identified and protected during receipt, processing, storage

Identifies and maintains confidential information to meet the entity's objectives related to confidentiality

What an assessor asks to see:

The definition of confidential information for the entity, including information designated confidential by customers or by contract
Evidence confidential information is identified across the system, covering where it is received, processed, stored and transmitted
The protections applied, such as access restriction, encryption and handling rules, tied to the identification
Evidence of the retention period applied to confidential information and of its basis
Evidence customers are informed of and agree the confidentiality commitments the entity makes

Where it usually falls short:

Confidentiality commitments made in contracts that were never translated into an internal definition anyone operates against
Confidential information identified in the primary system while copies in analytics, support tooling and non production environments are unidentified
Retention undefined, so confidential information is held indefinitely with no basis
Protection applied uniformly with no relation to the identification, so the identification step adds nothing

Source: SOC 2 Trust Services Criteria

SOC 2 CC1.3 COSO principle 3: Management establishes structures, reporting lines, and authorities

Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives

What an assessor asks to see:

Organisational charts showing structures and reporting lines in the period, with evidence of board oversight of that structure
Documented authorities and responsibilities, including delegation of authority limits and who may approve what
Job descriptions for roles with internal control or security responsibility
Evidence of review of the structure after change, such as reorganisation, acquisition or significant growth
Evidence responsibilities for outsourced functions are defined and assigned to an internal owner

Where it usually falls short:

Organisation chart current for the audit while the period contained an unrecorded restructure
Delegation of authority undocumented, so approvals cannot be tested against a defined limit
Outsourced functions treated as the vendor's responsibility with no named internal owner
Security responsibility assigned to a role that has no authority over the systems concerned

Source: SOC 2 Trust Services Criteria

SOC 2 CC6.2 Prior to granting access, registration and authorization processes are established

Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by

What an assessor asks to see:

The registration and authorisation procedure that must complete before credentials are issued, for internal and external users
Authorisation records for users provisioned in the period, showing the requester, the approver and the access requested
Evidence credentials were issued only after authorisation, with dates supporting the sequence
Evidence of removal of access when access is no longer authorised, with the interval between the trigger and the removal
Evidence covering users whose access is administered by the entity on behalf of a customer, where that applies

Where it usually falls short:

Access granted first and approved retrospectively, which reverses the order the criterion requires
Approval by the requester's peer or by the person implementing the change, so no independent authorisation exists
External and customer administered users provisioned through a different route with no equivalent authorisation record
Removal triggered by a manual notification that is sometimes not sent, so leavers retain credentials

Source: SOC 2 Trust Services Criteria

SOC 2 CC6.4 Restricts physical access to facilities and protected information assets (for example, data center facilities, back-up media storage, and other sensitive locations) to authorized personnel to meet the entity's objectives

Restricts physical access to facilities and protected information assets (for example, data center facilities, back-up media storage, and other sensitive locations) to authorized personnel to meet the entity's objectives

What an assessor asks to see:

List of facilities and protected information assets in scope, including data centre space, back-up media storage and other sensitive locations
Authorisation records showing who is permitted physical access to each location and on what basis
Access control system configuration and badge listings for those locations, reconciled against the authorisation records
Records of periodic review of physical access rights and of removals made as a result
Visitor and third party access records for the same locations, including escort evidence

Where it usually falls short:

Primary data centre well controlled while back-up media storage and offsite locations rely on a provider attestation with no entity level review
Physical access rights reviewed less often than logical access, so leavers keep badge access after their accounts are disabled
Sensitive locations such as network rooms and media handling areas omitted from the scope list entirely

Source: SOC 2 Trust Services Criteria

SOC 2 CC6.6 Measures against threats outside system boundaries are implemented

Implements logical access security measures to protect against threats from sources outside its system boundaries

What an assessor asks to see:

Identification of the system boundaries and of the points at which external access is possible
Configuration of boundary protections, such as firewalls, intrusion prevention, denial of service protection and web application firewalls
Evidence of controls over remote access, including multi factor authentication and restriction of the routes available
Evidence of encryption or other protection of credentials and data crossing the boundary
Evidence of monitoring for and response to external attack attempts

Where it usually falls short:

Multi factor authentication enforced on the main access route while legacy access paths and application programming interfaces bypass it
Boundary defined by network only, missing identity based access from anywhere as the actual boundary
Rules permitting broad external access retained from an earlier configuration with no review
Attack attempts logged with no monitoring and no response defined

Source: SOC 2 Trust Services Criteria

SOC 2 CC7.1 Detection and monitoring procedures for security events are in place

To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities

What an assessor asks to see:

Defined configuration standards or baselines and evidence of monitoring for changes that introduce new vulnerabilities
Vulnerability scanning results for the period, including scope, frequency and whether scanning is authenticated
Evidence of monitoring for newly discovered vulnerabilities affecting the technologies in use
Records of deviations detected, the assessment of them and the remediation taken
Evidence the monitoring covers infrastructure, applications and cloud configuration

Where it usually falls short:

Configuration monitored at build only, so drift introduced afterwards is never detected
Scanning performed quarterly against an environment that changes daily
Newly published vulnerabilities tracked for operating systems while application and library exposure is unmonitored
Detected deviations recorded with no remediation timeline and no follow up

Source: SOC 2 Trust Services Criteria

SOC 2 CC7.2 Monitors system components for anomalies indicating malicious acts

Monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine

What an assessor asks to see:

The monitoring design for system components and their operation, showing what constitutes anomalous behaviour
Detection rules or analytics deployed, and evidence of the tuning applied over time
Evidence of the sources monitored, covering infrastructure, applications, identity and, where applicable, physical and environmental conditions
Records of anomalies detected during the period and of the analysis performed to determine whether they represent a security event
Evidence of the coverage of the monitoring against the components in the system description

Where it usually falls short:

Logs collected without any detection logic applied, so anomalies are only visible in hindsight
Monitoring covers malicious acts and omits natural disaster and error, both of which the criterion names
Alert volume exceeding triage capacity, so alerts are closed without analysis
Components in the system description with no monitoring coverage at all

Source: SOC 2 Trust Services Criteria

SOC 2 CC7.4 Responds to identified security incidents through defined procedures

Executes a defined incident response program once a security incident is identified, with roles and responsibilities assigned, the nature and severity of the incident understood, the active threat contained and mitigated, the underlying vulnerability remediated, operations restored to a state that meets objectives, and the incident and the actions taken communicated to affected parties, with the effectiveness of the response evaluated periodically.

What an assessor asks to see:

Incident response program naming roles, escalation paths and the use of external resources
Incident tickets carrying detection, containment, eradication and recovery timestamps
Severity assessment and containment strategy record for individual incidents
Remediation records tying each incident to closure of the underlying vulnerability
Records of communication to affected parties and, where privacy is in scope, to data subjects and regulators
Periodic evaluation or exercise of the response program with resulting changes

Where it usually falls short:

A response plan exists but no incident record shows it was followed
Containment recorded while the vulnerability that allowed the incident stays open
No evidence that affected parties were told anything
Effectiveness never evaluated, so the same root cause recurs across periods
Roles named in the plan no longer match the people who actually respond

Source: SOC 2 Trust Services Criteria

SOC 2 CC8.1 Change management processes are in place

Authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives

What an assessor asks to see:

The change management process covering infrastructure, data, software and procedures, including the emergency change route
Change records for the period showing design, development or acquisition, configuration, documentation, testing, approval and implementation
Evidence of segregation between those who develop, approve and implement changes
Testing evidence per change proportionate to its risk, including security testing where relevant
Evidence of rollback capability and of post implementation verification

Where it usually falls short:

Emergency changes used routinely, with retrospective approval that is never withheld
Approval and implementation performed by the same person, so the approval is not independent
Automated deployment pipelines outside the documented process, so most changes are untested against it
Infrastructure and configuration change treated as out of scope because the process was written for application code

Source: SOC 2 Trust Services Criteria

SOC 2 CC9.2 Risk mitigation activities include assessment of vendor and business partner controls

Assesses and manages risks associated with vendors and business partners

What an assessor asks to see:

The vendor and business partner inventory, with risk tiering based on data access and criticality
Due diligence records performed before engagement, at the depth the tier requires
Contractual commitments covering confidentiality, security requirements, incident notification and the right to assess
Evidence of ongoing monitoring, such as review of assurance reports with complementary user entity control consideration, and follow up on exceptions noted in them
Evidence of termination handling, including return or deletion of data and revocation of access

Where it usually falls short:

Assurance reports collected and filed with no review of the exceptions or of the complementary user entity controls they assume the entity performs
Inventory covering vendors known to procurement, missing services engaged directly by teams
Due diligence performed at onboarding with no reassessment during a multi year relationship
Subservice organisations engaged by the vendor never identified, so risk stops at the first tier

Source: SOC 2 Trust Services Criteria

SOC 2 P4.2 Personal information is retained for only as long as needed

Retains personal information consistent with the entity's objectives related to privacy

What an assessor asks to see:

The retention schedule for personal information, with the period per data type and its legal or business basis
Evidence of enforcement, such as automated deletion jobs, purge reports or records of manual disposal
Evidence retention covers all copies, including backups, archives, replicas, exports and third party held data
Records of legal holds or other justified exceptions, with approval and expiry
Evidence of monitoring showing personal information beyond its retention period is identified and removed

Where it usually falls short:

Retention schedule documented with no enforcement anywhere, so nothing is deleted
Deletion performed in the production database while backups, data warehouses and exports retain the data
Legal holds applied and never released, becoming permanent retention by default
No monitoring, so overdue data is only discovered during an audit or an incident

Source: SOC 2 Trust Services Criteria