SOC 2 (AICPA Trust Services Criteria)

Your own account of the service, its boundaries, the infrastructure behind it and the controls you run — Section III of the report, written by you rather than the auditor.

The written policies staff are held to, which is how service organisations usually evidence that controls are deployed through policy rather than habit.

The behavioural standard everyone signs up to, and what happens when someone departs from it.

Shows the reporting lines and who provides independent oversight of management — usually a board or advisory charter plus an org chart.

How you hire, define what a role needs, and hold people accountable for the control work in their job — including performance and disciplinary routes.

The documented risk process most service organisations use to show they identify risk, consider fraud, and reassess when things change.

Maps each Trust Services criterion to the specific control you run and the evidence that proves it — the working document that drives the whole audit.

How you check your own controls between audits and what happens to a deficiency once someone finds one.

How people are told what their control responsibilities are — onboarding decks, policy acknowledgements, security channel announcements.

How identities are created, what access each role gets, and how access is removed and periodically reviewed.

How offices and any physical assets are protected, and what you inherit from your cloud provider instead.

How devices and storage are wiped or destroyed when they leave, and how that is recorded.

The technical defences at the boundary and on laptops: firewalls, encryption in transit, endpoint protection and anti-malware.

How you detect new vulnerabilities and configuration drift, how you rank them, and the deadlines for fixing each severity.

What is logged, what raises an alert, and how someone decides whether an alert is actually a security event.

Who does what during a security incident, how customers and authorities are told, and how service is restored.

How code and infrastructure changes are reviewed, approved, tested and released, including emergency changes.

How the service survives and recovers from disruption, with the recovery targets you have committed to customers.

How subservice organisations and vendors are assessed before use and monitored afterwards, including reviewing their own reports.

Capacity headroom, redundancy and the recovery objectives behind any uptime commitment you have made.

What counts as confidential customer information, how it is handled, and when it is destroyed.

How you show that processing is complete, accurate and authorised — input validation, reconciliations and error handling.

What you tell individuals about their personal information and how you honour their choices about it.