# SOC 2 Readiness Assessment: [System name]

> Readiness assessment for a first or expanded SOC 2 examination. It
> records why the organisation needs a report, the proposed scope and
> system boundary, the readiness of the system description against the
> AICPA 2018 Description Criteria (DC 200, with revised implementation
> guidance, 2022), a criterion-by-criterion gap rating against the AICPA
> 2017 Trust Services Criteria (with revised points of focus, 2022), a
> remediation roadmap, and the Type 1 and Type 2 plan with dates and
> decisions for management. Criterion identifiers are used with short
> original paraphrases; the criteria text is AICPA material and is not
> reproduced. Replace every `[bracketed]` value and every row marked
> *Example*. This is a documentation format, not audit or legal advice;
> the service auditor decides what evidence is sufficient.

<!--
Guidance: How to use this template
- Run this assessment before engaging the service auditor for the
  examination, or use it as the internal record of a readiness
  engagement performed by an adviser. It answers one question: can we
  start a Type 1 or Type 2 period on the planned date, and what must
  change first?
- Fill section 1 (drivers) and section 2 (scope) with the people who
  sell and run the system. Then rate every in-scope criterion in
  section 5, find the gaps in section 6 and plan in sections 7 and 8.
- Keep the full control mapping in the SOC 2 Control Mapping workbook
  (`compliance/soc2-controls`). This assessment summarises readiness;
  the workbook holds controls, evidence and owners per criterion.
- The worked example is fictional: Tallowfern Systems Inc., a
  business-to-business staff scheduling service hosted on a public
  cloud, preparing for its first report after three enterprise
  prospects asked for one. Delete it before use.
- Related documents: SOC 2 Control Mapping (`compliance/soc2-controls`),
  Risk Register (`compliance/risk-register`), Information Security
  Policy (`compliance/information-security-policy`), Supplier Security
  Assessment (`compliance/supplier-security-assessment`), Incident
  Response Plan (`compliance/incident-response-plan`), Access Review
  (`ops/access-review`), Change Request (`ops/change-request`), Backup
  and Restore Procedure (`ops/backup-restore-procedure`), Disaster
  Recovery Plan (`ops/disaster-recovery-plan`), Internal Audit Program
  (`compliance/internal-audit-program`).
-->

## Document control

<!-- Guidance: The assessment is a point-in-time view. Date it, and re-rate before the period starts if more than three months pass. -->

| Field | Value |
|---|---|
| Document ID | [DOC-SOC2-RA-001] |
| Version | [0.1] |
| Status | [Draft / Rated / Management decision / Superseded] |
| Owner | [@security-lead] |
| Approvers/reviewers | [@cto], [@ceo], [@head-of-sales] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Service organisation | [Legal entity] |
| System assessed | [System name] |
| Assessment date | YYYY-MM-DD |
| Assessor | [Internal team / readiness adviser] |
| Criteria edition | 2017 Trust Services Criteria (revised points of focus, 2022) |
| Description criteria edition | DC 200, 2018 Description Criteria (revised implementation guidance, 2022) |
| Target report | [Type 1 as of YYYY-MM-DD / Type 2 for YYYY-MM-DD to YYYY-MM-DD] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Assessment lead | [@security-lead] | [Prepared] | YYYY-MM-DD |
| Executive sponsor | [@cto] | [Approved roadmap and budget] | YYYY-MM-DD |
| Chief executive | [@ceo] | [Approved target report and date] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@security-lead] | Scope and drivers drafted |
| 0.2 | YYYY-MM-DD | [@security-lead] | Criteria rated, gap register and roadmap |
| 1.0 | YYYY-MM-DD | [@security-lead] | Management decision recorded |

## Contents

<!-- Guidance: Sections 1 to 4 set up the assessment, 5 and 6 are the findings, 7 to 10 are the plan and the decisions. -->

1. Drivers and decisions sought
2. Scope and system boundary
3. System description readiness (DC 200)
4. Assessment method
5. Criteria readiness ratings
6. Gap register
7. Remediation roadmap
8. Type 1 and Type 2 plan
9. Evidence and tooling readiness
10. Risks, assumptions and decisions
11. Glossary and references

## 1. Drivers and decisions sought

<!-- Guidance: Questions to answer: who asked for a report, by when, for which service, and what will happen if it is late? Pitfall: starting a SOC 2 programme because competitors have one, with no customer date to plan against. -->

| Driver ID | Source | Request | Needed by | Commercial weight |
|---|---|---|---|---|
| DRV-01 *(Example)* | Enterprise prospect, healthcare staffing group | SOC 2 Type 2 report, Security and Availability, before contract renewal | 2028-03-31 | High |
| DRV-02 *(Example)* | Enterprise prospect, retail chain | Any SOC 2 report, or a completed security questionnaire meanwhile | 2027-09-30 | Medium |
| DRV-03 *(Example)* | Existing customer security review | Confidentiality commitments for customer staff data | Next annual review | Medium |
| [DRV-NN] | [source] | [request] | YYYY-MM-DD | [High / Medium / Low] |

Decisions sought from management in this document:

1. Approve the scope in section 2 (system, categories, subservice
   organisation method).
2. Approve the roadmap and the resources in section 7.
3. Choose the report path in section 8 (Type 1 first, or straight to
   a Type 2 period) and the period start date.
4. Approve the selection process for the service auditor.

## 2. Scope and system boundary

<!-- Guidance: The system is the set of infrastructure, software, people, procedures and data that delivers the service named in customer commitments. Draw the boundary around that, not around the whole company. Pitfall: including internal tools that never touch customer data, which adds criteria testing without customer value. -->

### 2.1 Service and boundary

| Item | In scope | Out of scope |
|---|---|---|
| Service | [Staff scheduling web and mobile application, public API] *(Example)* | [Marketing website, internal finance system] *(Example)* |
| Environments | Production, and the build pipeline that deploys to it | Development sandboxes holding synthetic data only |
| Locations | [Cloud regions], [offices with staff who operate the system] | [Locations with no system access] |
| People | Engineering, site reliability, support, security, people operations | Sales, except where they handle customer data |
| Data | Customer staff rosters, contact details, availability, audit logs | Prospect lists in the sales CRM |

```mermaid
flowchart LR
  CUST["Customer administrators and staff"] --> APP["Scheduling application and API"]
  APP --> DB["Customer data stores"]
  APP --> MSG["Notification service (subservice, carve-out)"]
  DB --> BK["Encrypted backups in second region"]
  CI["Build and deploy pipeline"] --> APP
  ENG["Engineering and support staff"] --> CI
  ENG --> APP
  HOST["Cloud provider (subservice, carve-out)"] --- APP
  HOST --- DB
```

### 2.2 Trust services categories

| Category | Criteria | Proposed | Reason |
|---|---|---|---|
| Security | CC1.1 to CC9.2 (33) | Yes, required | Every SOC 2 examination includes it |
| Availability | A1.1 to A1.3 (3) | Yes *(Example)* | Contracts commit to 99.9 percent monthly uptime |
| Confidentiality | C1.1 to C1.2 (2) | Yes *(Example)* | Customers send staff data under confidentiality terms |
| Processing Integrity | PI1.1 to PI1.5 (5) | No *(Example)* | The system does not compute pay or invoices |
| Privacy | P1.1 to P8.1 (18) | No *(Example)* | Customers collect the data from their staff; privacy obligations are handled through the data processing agreement |

In the example, 38 criteria are in scope: 33 common criteria plus 3
for Availability and 2 for Confidentiality.

### 2.3 Subservice organisations

| Subservice organisation | Service | Proposed method | Their report available? | Complementary subservice organisation controls (CSOCs) we rely on |
|---|---|---|---|---|
| [Cloud provider] *(Example)* | Infrastructure hosting | Carve-out | SOC 2 Type 2, current | Physical security, environmental protection, hardware disposal |
| [Messaging provider] *(Example)* | SMS and email delivery | Carve-out | SOC 2 Type 2, current | Logical access to message content in its platform |
| [Name] | [service] | [Inclusive / Carve-out] | [Yes, type and period / No] | [controls] |

With the carve-out method, the subservice organisation's controls are
excluded from the description and testing, and the description names
the controls you expect it to operate. The inclusive method brings them
into scope and requires its cooperation and management assertion. Most
first reports use carve-out for hyperscale cloud providers.

## 3. System description readiness (DC 200)

<!-- Guidance: Management writes the system description and the auditor opines on whether it is fairly presented. Rate each description criterion: Ready (content exists and is accurate), Partial, or Missing. Pitfall: copying sales material, which overstates controls and becomes a description misstatement. -->

| DC | Disclosure (short paraphrase) | Source material today | Readiness | Action |
|---|---|---|---|---|
| DC1 | Types of services provided | Product overview, contract schedule | Ready *(Example)* | Rewrite in neutral language |
| DC2 | Principal service commitments and system requirements | Master agreement, SLA, security addendum | Partial *(Example)* | List each commitment and the internal requirement behind it |
| DC3 | Components: infrastructure, software, people, procedures, data | Architecture diagrams, asset list | Partial *(Example)* | Reconcile asset list with infrastructure as code |
| DC4 | Incidents that affected commitments | Incident tracker | Missing *(Example)* | Define "significant" incident threshold and review the last 12 months |
| DC5 | Applicable criteria and related controls | None | Missing *(Example)* | Produced from `compliance/soc2-controls` after remediation |
| DC6 | Complementary user entity controls (CUECs) | Admin guide fragments | Partial *(Example)* | Draft CUEC list, publish in admin guide |
| DC7 | Subservice organisations, method, CSOCs | Supplier list | Partial *(Example)* | Section 2.3 above, confirm with auditor |
| DC8 | Criteria not relevant, with reasons | None | Missing *(Example)* | Document any criterion judged not relevant, for example physical media if none exist |
| DC9 | Significant changes during the period (Type 2) | Change log | Partial *(Example)* | Agree a rule for what counts as significant |

Readiness summary in the example: 1 of 9 Ready, 5 Partial, 3 Missing.

## 4. Assessment method

<!-- Guidance: Use a scale simple enough for owners to apply the same way. Ratings are judgements about evidence, not about policy wording. Pitfall: rating a criterion "designed" because a policy exists when nobody performs the activity. -->

Each in-scope criterion is rated once, by the assessor with the control
owner, after reviewing the evidence that exists today. The scale is
written for this template and is not an AICPA scale.

| Rating | Label | Meaning | Ready for |
|---|---|---|---|
| 0 | Absent | No control activity addresses the criterion | Nothing |
| 1 | Informal | Activity happens, but is undocumented, inconsistent or leaves no evidence | Nothing |
| 2 | Designed | Control is documented, owned and implemented, with at least one instance of evidence | Type 1 |
| 3 | Operating | Control has run consistently with retained evidence for at least three months, or continuously if automated | Type 2 |

Series readiness is the sum of ratings divided by the maximum possible
(3 per criterion), as a percentage. A criterion rated 0 or 1 is a gap
and gets a row in section 6.

Sources reviewed: [policies, tickets, configuration exports, logs,
interviews with named owners]. Interviews held: [n] with [roles].

## 5. Criteria readiness ratings

<!-- Guidance: Rate every in-scope criterion; do not skip criteria that seem obvious. Keep the per-criterion rationale short here and the detailed control mapping in compliance/soc2-controls. The paraphrases are original short labels; read the official criterion and points of focus when rating. -->

### 5.1 Summary by series

| Series | Criteria | Rated 0 | Rated 1 | Rated 2 | Rated 3 | Score | Readiness |
|---|---|---|---|---|---|---|---|
| CC1 Control environment *(Example)* | 5 | 0 | 2 | 3 | 0 | 8 of 15 | 53% |
| CC2 Communication and information *(Example)* | 3 | 0 | 1 | 2 | 0 | 5 of 9 | 56% |
| CC3 Risk assessment *(Example)* | 4 | 1 | 3 | 0 | 0 | 3 of 12 | 25% |
| CC4 Monitoring activities *(Example)* | 2 | 1 | 1 | 0 | 0 | 1 of 6 | 17% |
| CC5 Control activities *(Example)* | 3 | 0 | 1 | 2 | 0 | 5 of 9 | 56% |
| CC6 Logical and physical access *(Example)* | 8 | 0 | 0 | 5 | 3 | 19 of 24 | 79% |
| CC7 System operations *(Example)* | 5 | 0 | 3 | 2 | 0 | 7 of 15 | 47% |
| CC8 Change management *(Example)* | 1 | 0 | 0 | 1 | 0 | 2 of 3 | 67% |
| CC9 Risk mitigation *(Example)* | 2 | 1 | 1 | 0 | 0 | 1 of 6 | 17% |
| A1 Availability *(Example)* | 3 | 1 | 1 | 1 | 0 | 3 of 9 | 33% |
| C1 Confidentiality *(Example)* | 2 | 0 | 1 | 1 | 0 | 3 of 6 | 50% |
| **Total** *(Example)* | **38** | **4** | **14** | **17** | **3** | **57 of 114** | **50%** |

The example shows a familiar pattern: technical access controls (CC6)
are close to ready, while the governance criteria (CC3 risk assessment,
CC4 monitoring and CC9 vendor risk) lag. Common criteria alone score 51
of 99 (51.5 percent). 18 criteria are gaps (rated 0 or 1), and only 3
are ready for a Type 2 period today.

### 5.2 Ratings by criterion

| Criterion | Short paraphrase | Rating | Rationale | Gap ID |
|---|---|---|---|---|
| CC1.1 | Integrity and ethical values | 2 | Code of conduct acknowledged at hire, no yearly refresh | |
| CC1.2 | Board oversight of internal control | 2 | Board minutes cover security quarterly | |
| CC1.3 | Structure, reporting lines and authorities | 2 | Org chart and role descriptions current | |
| CC1.4 | Competence of people | 1 | No security training records | GAP-05 |
| CC1.5 | Accountability for control duties | 1 | Control owners not named | GAP-05 |
| CC2.1 | Quality information for internal control | 2 | Asset and logging inventories exist | |
| CC2.2 | Internal communication of responsibilities | 2 | Policies published on intranet with read receipts | |
| CC2.3 | External communication | 1 | No published channel for customers to report security issues | GAP-07 |
| CC3.1 | Objectives clear enough to assess risk | 1 | Security objectives not written down | GAP-01 |
| CC3.2 | Risk identification and analysis | 1 | Spreadsheet of risks, not reviewed in a year | GAP-01 |
| CC3.3 | Fraud risk considered | 0 | Not considered | GAP-01 |
| CC3.4 | Significant change assessed | 1 | Discussed informally in architecture reviews | GAP-01 |
| CC4.1 | Ongoing or separate evaluations | 1 | Ad hoc checks, no plan | GAP-02 |
| CC4.2 | Deficiencies communicated and corrected | 0 | No deficiency tracking | GAP-02 |
| CC5.1 | Control activities selected to reduce risk | 2 | Controls follow the cloud security baseline | |
| CC5.2 | General controls over technology | 2 | Infrastructure as code with review | |
| CC5.3 | Policies and procedures deploy controls | 1 | Several procedures missing owners and review dates | GAP-05 |
| CC6.1 | Logical access architecture | 3 | SSO with MFA, encryption at rest, network segmentation, all automated | |
| CC6.2 | Registering and removing users | 2 | Ticketed joiners; leavers removed but not always same day | |
| CC6.3 | Role-based changes, least privilege | 2 | Roles defined, first quarterly review completed | |
| CC6.4 | Physical access | 3 | Carve-out to cloud provider; office has no production access | |
| CC6.5 | Disposal of assets | 2 | Laptop wipe procedure, one instance recorded | |
| CC6.6 | Threats from outside the boundary | 3 | Web application firewall, managed edge rules, alerts | |
| CC6.7 | Restricting movement of information | 2 | TLS everywhere, data loss rules on email not yet in place | |
| CC6.8 | Malicious software | 2 | Endpoint protection deployed, coverage report monthly | |
| CC7.1 | Detecting vulnerabilities and configuration drift | 1 | Dependency scanning only; no image or cloud configuration scanning | GAP-03 |
| CC7.2 | Monitoring for anomalies | 2 | Central logging and alert rules | |
| CC7.3 | Evaluating security events | 2 | On-call triage with runbooks | |
| CC7.4 | Responding to incidents | 1 | Response plan not tested | GAP-04 |
| CC7.5 | Recovering from incidents | 1 | No post-incident review records | GAP-04 |
| CC8.1 | Change management | 2 | Pull requests reviewed and checked; emergency change rule missing | |
| CC9.1 | Business disruption risk | 1 | Continuity thinking exists in runbooks only | GAP-06 |
| CC9.2 | Vendor and partner risk | 0 | No supplier review process | GAP-08 |
| A1.1 | Capacity planning | 1 | Autoscaling, no capacity review record | GAP-06 |
| A1.2 | Environmental protections, backups and recovery infrastructure | 2 | Daily encrypted backups to a second region | |
| A1.3 | Recovery testing | 0 | No restore test performed | GAP-06 |
| C1.1 | Identifying and protecting confidential information | 2 | Data classification standard applied to customer data | |
| C1.2 | Disposing of confidential information | 1 | Deletion on contract end is manual and unrecorded | GAP-07 |

Count check: 38 rows, ratings match the summary in 5.1.

## 6. Gap register

<!-- Guidance: Group related criteria into one gap when one remediation fixes them. Size each gap so the roadmap is realistic. Pitfall: gaps owned by "security" with no named person. -->

| Gap ID | Criteria | Gap | Remediation | Owner | Effort (person-days) | Priority |
|---|---|---|---|---|---|---|
| GAP-01 *(Example)* | CC3.1, CC3.2, CC3.3, CC3.4 | No current risk assessment covering objectives, fraud and change | Write security objectives, run a risk assessment with fraud scenarios, add a change trigger | [@security-lead] | 5 | 1 |
| GAP-02 *(Example)* | CC4.1, CC4.2 | No monitoring plan or deficiency tracking | Quarterly control self-checks and a deficiency log reported to leadership | [@security-lead] | 8 | 1 |
| GAP-03 *(Example)* | CC7.1 | No container image or cloud configuration scanning | Add image scanning to CI and weekly cloud posture scan, with triage service levels | [@sre-lead] | 4 | 1 |
| GAP-04 *(Example)* | CC7.4, CC7.5 | Incident response untested, no post-incident reviews | Tabletop exercise, review template, link to the incident plan | [@sre-lead] | 6 | 2 |
| GAP-05 *(Example)* | CC1.4, CC1.5, CC5.3 | No training records, control owners unnamed, procedures unowned | Security awareness training with records, owner per control, review dates | [@people-lead] | 10 | 2 |
| GAP-06 *(Example)* | CC9.1, A1.1, A1.3 | No continuity plan, capacity review or restore test | Business continuity plan, quarterly capacity review, full restore test | [@sre-lead] | 3 | 1 |
| GAP-07 *(Example)* | CC2.3, C1.2 | No external security contact; customer data deletion unrecorded | Publish a security contact page; automate and log deletion at contract end | [@eng-lead] | 6 | 2 |
| GAP-08 *(Example)* | CC9.2 | No supplier security review | Supplier inventory, risk tiering, annual review of critical suppliers' reports | [@procurement-lead] | 4 | 1 |
| **Total** *(Example)* | 18 criteria | | | | **46** | |

The 3 person-days for GAP-06 cover planning only; the restore test
itself depends on engineering time agreed in section 7.

## 7. Remediation roadmap

<!-- Guidance: Sequence priority 1 gaps first, and finish design of all gaps before the Type 1 date. Leave the control running for a while before a Type 2 period starts, so the first months of the period are not full of exceptions. -->

```mermaid
gantt
  title Example roadmap to a first SOC 2 Type 2 report
  dateFormat YYYY-MM-DD
  section Readiness
  Readiness assessment and decision :ra, 2027-01-04, 2027-01-29
  section Remediation
  Priority 1 gaps GAP-01 02 03 06 08 :p1, 2027-02-01, 2027-04-16
  Priority 2 gaps GAP-04 05 07 :p2, 2027-03-01, 2027-05-28
  System description draft :sd, 2027-04-05, 2027-05-28
  section Examination
  Type 1 as of date :milestone, t1, 2027-06-30, 0d
  Type 2 observation period :t2, 2027-07-01, 2027-12-31
  Fieldwork and report :fw, 2028-01-10, 2028-02-25
```

| Milestone | Target date | Exit criteria |
|---|---|---|
| M1 Readiness decision *(Example)* | 2027-01-29 | Scope, roadmap and report path approved |
| M2 Priority 1 gaps closed *(Example)* | 2027-04-16 | All priority 1 criteria rated 2 or higher |
| M3 All gaps designed, description drafted *(Example)* | 2027-05-28 | No criterion below 2; DC1 to DC9 drafted |
| M4 Type 1 as of date *(Example)* | 2027-06-30 | Auditor walkthroughs complete |
| M5 Type 2 period *(Example)* | 2027-07-01 to 2027-12-31 | Controls operating with evidence for six months |
| M6 Type 2 report issued *(Example)* | 2028-02-25 | Meets DRV-01 date of 2028-03-31 with five weeks of margin |

## 8. Type 1 and Type 2 plan

<!-- Guidance: A Type 1 opines on the description and the suitability of design as of a date; a Type 2 adds operating effectiveness over a period. Record the choice and the reasons customers will accept. Pitfall: a Type 2 period that starts before controls are operating, which turns readiness gaps into reported exceptions. -->

### 8.1 Options

| Option | What customers get, and when | Advantages | Drawbacks |
|---|---|---|---|
| A. Type 1, then Type 2 *(Example, recommended)* | Type 1 report in about Q3 2027, Type 2 in Q1 2028 | Early evidence for DRV-02; rehearsal for the Type 2 | Two examinations to fund and support |
| B. Type 2 directly | Type 2 report in Q1 2028 only | One examination | Nothing to show DRV-02 before then |
| C. Type 2 with a three-month first period | Type 2 in about Q4 2027 | Earlier Type 2 | Some customers question a short period |

Decision: [Option], approved by [@ceo] on YYYY-MM-DD. Reasons:
[reasons].

### 8.2 Service auditor selection

| Criterion | Questions |
|---|---|
| Licensing and independence | Is the firm a licensed CPA firm able to issue SOC 2 reports? Has it performed readiness or consulting work for us that could impair independence? |
| Sector experience | Does it examine software services of our size and architecture? |
| Approach | How does it sample, which evidence formats does it accept, and does it use our compliance tooling? |
| Timing | Can it meet the Type 1 date and the post-period fieldwork window? |
| Acceptance by customers | Do the customers in section 1 accept reports from this firm? |

### 8.3 Criteria edition

In October 2026 the AICPA Assurance Services Executive Committee
published exposure drafts of proposed 2027 SOC 2 Trust Services
Criteria and Description Criteria. The AICPA announcement of 28
October 2026 gives a comment deadline of 15 January 2027 and says that,
if approved, the 2027 criteria would apply to engagements beginning on
or after 31 December 2027, with early adoption permitted. Before the
period starts, confirm with the service auditor which edition applies
to the planned engagement, and re-run section 5 if the final criteria
change identifiers or add criteria.

### 8.4 After the first report

Plan the next period so it starts the day after the previous one ends.
For gaps between periods, management may issue a bridge letter
describing any material changes; it is a management statement, not
auditor assurance.

## 9. Evidence and tooling readiness

<!-- Guidance: The auditor tests populations and samples. Confirm now that each population can be produced completely from a system of record. Pitfall: evidence that lives in chat messages or personal drives. -->

| Area | Population source | Complete list available? | Retention | Readiness |
|---|---|---|---|---|
| New user accounts *(Example)* | Identity provider audit log | Yes | 13 months | Ready |
| Terminations *(Example)* | HR system leaver report | Yes, but needs matching to identity log | 7 years | Partial |
| Production changes *(Example)* | Source control merged pull requests | Yes | Indefinite | Ready |
| Security incidents *(Example)* | Incident tracker | Only since last quarter | Unknown | Partial |
| Vendor reviews *(Example)* | None | No | Not defined | Missing |
| [Area] | [source] | [Yes / No] | [period] | [readiness] |

Tooling decision: [Manual evidence folders / compliance automation
platform / both], with reasons and owner.

## 10. Risks, assumptions and decisions

<!-- Guidance: Keep this list short and specific; review it at each milestone. -->

| ID | Type | Statement | Owner | Response |
|---|---|---|---|---|
| R-01 *(Example)* | Risk | Engineering roadmap pressure delays GAP-03 and GAP-07 | [@cto] | Reserve two engineers for remediation in February and March |
| R-02 *(Example)* | Risk | 2027 criteria finalised with new identifiers before the period | [@security-lead] | Re-rate in section 5 within two weeks of publication |
| A-01 *(Example)* | Assumption | The cloud and messaging providers keep current SOC 2 reports | [@procurement-lead] | Check report dates each quarter |
| D-01 *(Example)* | Decision | Processing Integrity and Privacy excluded from the first report | [@ceo] | Revisit after first report |
| [ID] | [Risk / Assumption / Decision] | [statement] | [@owner] | [response] |

## 11. Glossary and references

<!-- Guidance: Cite editions exactly and check for updates before each period. -->

### 11.1 Glossary

| Term | Meaning in this template |
|---|---|
| Service organisation | The organisation whose system is examined |
| User entity | A customer that uses the service and reads the report |
| Service auditor | The licensed CPA firm that examines and reports |
| Carve-out method | Subservice organisation controls are excluded from the description and testing |
| Inclusive method | Subservice organisation controls are included in the description and testing |
| CUEC | Complementary user entity control: a control the customer is expected to operate |
| CSOC | Complementary subservice organisation control: a control a subservice organisation is expected to operate |
| Bridge letter | A management statement covering the time between report periods |

### 11.2 References

| Reference | Edition or date | Use |
|---|---|---|
| AICPA, TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022) | Current as checked 2026-10-30 | Criterion identifiers and categories |
| AICPA, DC Section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (with revised implementation guidance, 2022) | Current as checked 2026-10-30 | Section 3 |
| AICPA Exposure Drafts: Proposed 2027 SOC 2 Trust Services Criteria and Description Criteria | Posted 26 October 2026, comments to 15 January 2027, proposals only | Section 8.3 |
| AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization | Check the current edition | Examination practice |
| COSO, Internal Control: Integrated Framework | 2013 | Basis of CC1 to CC5 |

## Standard and licence note

Structure aligned with the AICPA 2017 Trust Services Criteria (with
revised points of focus, 2022) and the 2018 Description Criteria for a
SOC 2 system description (with revised implementation guidance, 2022).
Only criterion identifiers, category names and description criteria
numbers are used; the short paraphrases, rating scale, examples and
guidance are original wording and are not AICPA text. The criteria and
points of focus are copyrighted by the AICPA. Official text: AICPA and
CIMA, free download with registration:
https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
(description criteria:
https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report;
2027 exposure drafts:
https://www.aicpa-cima.com/resources/download/aicpa-exposure-drafts-proposed-2027-soc-2-trust-services-criteria-and-description-criteria).
Check the AICPA pages for the final 2027 criteria and their effective
date before each report period. SOC 2 is a registered mark of the
AICPA. The organisation, people, ratings and dates in the example are
fictional. This is a documentation format, not audit or legal advice.
Template licence: MIT.