System Description & Boundary Template

How to use this template

Decide what the report is for. Draw the boundary around the service your customers rely on. Make the controls work and leave records before the period starts. Tell customers plainly what the report covers and what it does not.

A SOC 2 report is built around management's description of one system. The CPA firm examines that description and the controls it describes, and gives an opinion. You write the description. This template gives you its shape: twelve sections, DS-01 to DS-12, which together carry the nine topics the AICPA's description criteria set. The other documents of the SOC 2 Report Readiness pack cite the sections by those numbers.

What this template is. A set of headings, prompts, tables and worked passages for the description. You keep it, adapt it and write your own text in it. It is a draft aid. The CPA firm tells you what it needs in the final document, and the final wording is yours.

What it is not. It is not the AICPA's text, and it does not say that a description written with it will be accepted. It does not draft management's assertion, which is a separate statement that the CPA firm will ask for. A SOC 2 report is an attestation by a licensed CPA firm, not a certificate. Nobody is “SOC 2 certified”, and no document in this pack says that you are or will be.

Legal note. This document helps an organisation get ready for a SOC 2 examination by a licensed CPA firm. It is not legal advice and not advice on an audit or attestation engagement. A SOC 2 report is the CPA firm's opinion on management's description of a system and on its controls. It is an attestation, not a certificate. This document does not say that you will receive any particular opinion, that any control meets a criterion, or that holding ISO/IEC 27001 or any other report equals or replaces a SOC 2 report. What the criteria require of you, how exceptions are described in the report and whether they affect the opinion are for the CPA firm to decide. Which customers accept which report is for them.

Management owns the description

SR-02 Management owns the description of the system and the assertion about it. The CPA firm examines both and forms its own opinion. A tool, a consultant or the auditor does not write the description in place of management.

In practice this means four things. Management writes the description, or approves every word of one that a colleague drafted. The people who operate the system read it against how it really works. Someone outside the writing team checks it against the records (see the consistency check below). And the executive sponsor, who will sign management's assertion, approves it.

A consultant, a software tool or the CPA firm may advise on structure. None of them should write the description in your place, and the CPA firm in particular should not, because it must examine what management says (SR-02, SR-24). If you find that nobody in the company can explain a sentence of the description, the sentence is not management's yet.

Who does what

• Examination owner runs the readiness work and the calendar, is the CPA firm's day-to-day contact, keeps the description, and reports the position in counts and words.
• Executive sponsor backs the examination with time and money, signs management's assertion with the examination owner, and decides scope questions that cost money.
• Head of Engineering owns change management, hosting, monitoring and the technical description of the system.
• Head of Information Security owns the security controls, the risk assessment and the incident process; does not test their own controls (P20 CA-10).
• Legal reviews customer contracts and commitments, the engagement letter, the bridge letter and what is shared under a confidentiality agreement.
• Control owner performs the control as written, keeps the record it leaves, and answers the auditor's requests for that evidence.

The rules the template puts into practice

SR-02 Management owns the description of the system and the assertion about it. The CPA firm examines both and forms its own opinion. A tool, a consultant or the auditor does not write the description in place of management.

SR-04 Draw the boundary around the one service customers rely on, with its infrastructure, software, people, procedures and data, and state what is outside it. A boundary drawn to leave out the awkward part is not a boundary.

SR-06 Decide the carve-out or the inclusive method separately for each subservice organisation, before the description is written. A carve-out leaves you with a list of controls you assume the provider operates, and a duty to watch that they do (P06 TP-09).

SR-07 Write the complementary user entity controls from your contracts and your customers' real duties. A control you assume customers operate must be one they can operate.

SR-08 Re-scope when the service, the boundary, a major provider or a customer commitment changes, and before each new period. Write down why the scope is what it is.

SR-18 Record significant changes to the system or its controls in the period, with the date and the before and after (DC-9), and tell the CPA firm. Do not freeze the business to protect the period.

SR-19 Record incidents of the period (P09 A09) and tell the CPA firm which ones affected a commitment (DC-4). Decisions about notifying anyone follow P09 and P18, unchanged.

The nine topics and the twelve sections

These nine topics are the ones the AICPA's description criteria (DC section 200) set. The nine criteria were read in the AICPA's own DC section 200 (2018, with revised implementation guidance, 2022) on 20 October 2026; the titles are this pack's own short labels for them. DC 9, significant changes, applies to a description that covers a period (a Type 2 report), and the other eight apply to both report types (DC 4 reads as of the date of the description for a Type 1 report and during the period for a Type 2). The exact wording of each criterion, and which topics your report type reads, are for the CPA firm to confirm.

The table shows the nine topics with this pack's labels, what each asks of you, whether secondary sources read it for both report types, and the template section that carries it. Every topic is carried by at least one section.

Filling in the template

• Work in order, but do not wait to finish one section to start the next. The boundary, the providers and the commitments depend on each other. Expect to go round twice.
• In each section, read the guidance box first, then fill the table, then write the passage. The EXAMPLE passage under each table shows the level of detail, not the words to use.
• Write in the present tense about the system as it runs now. Record changes in the section for changes.
• Name roles, not people, wherever you can. Where a person is needed, say so in the document control table, not in the description.
• Do not paste secrets, internal addresses or anything that would help an attacker. The description goes to customers under a confidentiality agreement, but it can travel.
• Delete the guidance boxes and the EXAMPLE passages from the version you give to the CPA firm. Keep the section numbers in your file so that your records still point to the right place.

Type 1 or Type 2: which sections speak of a date and which of a period

A Type 1 report gives an opinion on the description and on the design of the controls as of one date. A Type 2 report gives an opinion on the description and on the design and operating effectiveness of the controls throughout a period. The description therefore speaks of a date in a Type 1 report and of a period in a Type 2 report. The SOC 2 Report Readiness pack treats a Type 2 report as the default (SR-05).

Secondary sources read the topic of significant changes (DC-9) as about the period only, and the other eight as applying to both report types. The AICPA's description criteria were not available to this pack, and the titles here are the pack's own labels. The CPA firm confirms which topics your report type reads and how it wants a Type 1 description to treat DS-12.

The twelve sections

Each section has the same layout: the topics it carries, the prompt, a guidance box that says what to write and what to avoid, a table to fill in, and a short passage for the EXAMPLE. Add rows as you need them. If a table is too small, attach the list and write its location in the table.

DS-01 About this description

Covers: No description topic of its own. It frames the rest..

Prompt: The service organisation, the system, the type of report, the categories in scope and the period or date. State that management is responsible for the description.

EXAMPLE passage (Ledgerline). This is management's description of the Ledgerline system of Acme Corp (EXAMPLE), for the period 1 January 2027 to 30 June 2027. It is a Type 2 report. The categories in scope are Security, Availability and Confidentiality. Management is responsible for this description and for the controls it describes.

DS-02 The services provided

Covers: DC-1 Types of services provided.

Prompt: What each service in scope does for customers and who the customers are. Where Privacy is in scope, your role over personal information.

EXAMPLE passage (Ledgerline). Ledgerline is a hosted invoicing and approvals service for finance teams. It has a web application, a programming interface (API) and an email notification service. Its customers are finance departments of mid-sized businesses (EXAMPLE).

DS-03 Principal service commitments and system requirements

Covers: DC-2 Principal service commitments and system requirements.

Prompt: The commitments in contracts, service levels and published policies, and the system requirements that follow from them, in the principal ones only.

EXAMPLE passage (Ledgerline). Ledgerline commits to 99.9% monthly availability of the web application and API, as the service level in the customer contract states it. It commits that customer data is encrypted in transit and at rest, and that customer data is deleted within 60 days of the end of the contract on request. These are the principal commitments. The system requirements that follow include redundant hosting, monitoring with an on-call rota, encryption settings that can be shown, and a deletion procedure with a record.

A bridge from the description to what customers are told: P26-A09 Standard Security Commitments Schedule holds the commitments you give customers as a standard schedule. The description should agree with it.

The five components: DS-04 to DS-08

DS-04 to DS-08 are the five components of the system: infrastructure, software, people, procedures and data. Write all five. A description that covers three of them is incomplete, and the readiness assessment (Readiness Assessment Procedure) will find it.

DS-04 Infrastructure

Covers: DC-3 Components of the system.

Prompt: Hosting, networks, servers and platform services that provide the service.

EXAMPLE passage (Ledgerline). The service runs on cloud infrastructure provided by the hosting provider, which is carved out (see DS-11). Acme configures the virtual networks, firewalls, servers and managed databases on that infrastructure, and owns the configuration. The office network is outside the boundary because no customer data or production access goes through it (EXAMPLE).

DS-05 Software

Covers: DC-3 Components of the system.

Prompt: The applications, systems software and tools that provide the service and support the controls.

EXAMPLE passage (Ledgerline). The application is a web front end, an API and background workers, with a managed database. Supporting tools inside the boundary are source control, build and deployment, monitoring and alerting, ticketing, the identity provider used for production access, and endpoint management for the laptops of engineers with production access (EXAMPLE).

DS-06 People

Covers: DC-3 Components of the system.

Prompt: The teams and roles that operate the system, including who is outside your employment but works under your direction.

EXAMPLE passage (Ledgerline). Engineering builds and releases the service. Site reliability operates it and answers alerts. The security team owns the security controls and the risk assessment. Customer support has access to a support tool that shows account settings, and no access to customer invoice content. Two contractors work under the direction of engineering and are listed as contractors (EXAMPLE).

DS-07 Procedures

Covers: DC-3 Components of the system.

Prompt: The automated and manual procedures involved in providing the service.

EXAMPLE passage (Ledgerline). A change is released through the build pipeline after review and approval by someone other than the author. Access to production is requested in the ticketing system, approved by the system owner and removed through the leaver procedure. Incidents follow the incident response plan. Backups run daily and a restore is tested on a schedule. Deletion at the end of a contract is a ticketed task with a record (EXAMPLE).

DS-08 Data

Covers: DC-3 Components of the system.

Prompt: The types of data the system uses and keeps, and how it flows in and out.

EXAMPLE passage (Ledgerline). The system keeps customer invoice and approval data, user account data, and usage and audit logs. Customer data is classified Confidential. It enters through the web application, the API and customer imports, and leaves through exports and notification emails. Customer data is kept for the contract term and deleted within 60 days after the end of it on request (EXAMPLE).

DS-09 The boundary

Covers: DC-3 Components of the system.

Prompt: What is inside, what is outside, and the functions a reader might think are inside but are not.

EXAMPLE passage (Ledgerline). Inside the boundary: the Ledgerline production environment, its deployment pipeline, the identity provider used for production access, and the staff and devices with that access. Outside the boundary: the marketing website (it holds no customer data), the internal finance system, and the payment processor for Acme's own subscriptions, because customers' invoice data does not flow through it (EXAMPLE).

DS-10 Risk assessment and the controls

Covers: DC-5 Applicable criteria and related controls; DC-8 Criteria that are not relevant, and why.

Prompt: How you identify and assess risks to the commitments, the controls designed to meet them for each category in scope, and any criterion that does not apply with its reason.

EXAMPLE passage (Ledgerline). Risks to the commitments are assessed once a year and when the system changes materially, by the security team with the heads of engineering and operations, on a scale of likelihood and impact. Treatment decisions have owners and dates. The controls for Security, Availability and Confidentiality are summarised by group and listed in the register of criteria and controls. Criteria that concern the physical protection of data centres are not relevant to Acme's own controls, because it runs no data centre. They are the hosting provider's, and DS-11 lists them as assumed controls (EXAMPLE).

The risk register (P05-A05 Information Security Risk Register) is where the risks live. The description needs the process in two or three paragraphs and a pointer. The register of criteria and controls (Trust Services Criteria Response Register) lists the criteria by number and series title and holds your controls beside them. It makes no claim about which control relates to which criterion.

DS-11 Complementary controls: customers and providers

Covers: DC-6 Complementary user entity controls; DC-7 Subservice organisations and the method used.

Prompt: The controls you assume customers operate. Each subservice organisation, the method used, and the controls assumed of a carved-out provider.

Part one: providers that run part of the system.

Part two: controls you assume customers operate.

EXAMPLE passage (Ledgerline). Acme uses the carve-out method for the hosting provider and the email delivery provider, and holds the hosting provider's SOC 2 report. The payment processor is outside the boundary. Customers are assumed to remove their own leavers, to protect their administrator credentials and single sign-on settings, and to review the approvers in their own approval workflows (EXAMPLE).

EXAMPLE table of providers.

EXAMPLE table of customer controls.

DS-12 Incidents and significant changes

Covers: DC-4 Identified system incidents; DC-9 Significant changes during the period.

Prompt: Identified incidents (as of the date for a Type 1 report, in the period for a Type 2 report) and, for a Type 2 report, significant changes to the system or its controls, each with its date and effect.

Identified incidents of the period.

Significant changes in the period.

EXAMPLE passage (Ledgerline). During the period one incident affected the availability commitment: on 9 March 2027 the API was degraded for about 50 minutes after a failed deployment, and it was resolved by rolling back the change. One significant change was made: the managed database moved to a new cluster on 20 April 2027, with the same controls, tested before and after (EXAMPLE).

EXAMPLE rows.

Providers: carve-out, inclusive or outside the boundary

SR-06 Decide the carve-out or the inclusive method separately for each subservice organisation, before the description is written. A carve-out leaves you with a list of controls you assume the provider operates, and a duty to watch that they do (P06 TP-09).

A provider is not a subservice organisation merely because you pay it. It is one when it runs part of the system and its controls matter to the commitments. Choose the providers from the supplier register (P06-A08 Supplier Security Risk Register), and decide for each one which of three words applies.

Reading a provider's report

P06-A03 Supplier Security Assessment Procedure holds the procedure for assessing and reassessing a provider. For the description, read five things in the provider's SOC 2 report and write down what you find.

• Does its period overlap yours, and is it a Type 1 or a Type 2 report? A Type 1 report says nothing about operation over time.
• Does its system, and its list of categories, match the service you use? A report on another product of the provider is not a report on yours.
• What exceptions does it list, and what did the provider's management say? An exception on a control you assume is a risk to you.
• What does it say customers must do (its complementary user entity controls)? Those are duties of yours. Add each to your own controls, or explain why it does not apply.
• Which of its own providers did it carve out? Their controls are two steps away from you, and the provider's report is the only place that says so.

Boundary checklist

SR-04 Draw the boundary around the one service customers rely on, with its infrastructure, software, people, procedures and data, and state what is outside it. A boundary drawn to leave out the awkward part is not a boundary.

Answer each check Yes, No or Unsure, and write where the evidence is. Anything other than Yes is a gap to close before the description is finalised. The right-hand column gives the rule behind each check.

Consistency check

The description is a set of statements, and every one can be checked against something. Before you give it to the CPA firm, someone other than the writer compares it with the records below and writes one of four results. The CPA firm will read the same records.

The four results are: Agrees, Differs, text fixed, Differs, system or record fixed, Differs, explained in the description. Report the check in counts, for example "ten checks, eight agree, two differ and are fixed". Never as a score.

Roles and responsibilities

The matrix shows who is responsible (R), accountable (A), consulted (C) and informed (I). Columns, in order: Owner for examination owner; Spons for executive sponsor; Eng for Head of Engineering; Sec for Head of Information Security; Legal for Legal; Ctrl for control owner.

Common mistakes

Related documents

Definitions

The EXAMPLE in one place: Acme

EXAMPLE, not part of the template. Acme Corp (EXAMPLE) is a US software-as-a-service provider with about 400 staff, selling to businesses that ask for a SOC 2 report. It is not the organisation used in the earlier packs. Its service, Ledgerline, is a hosted invoicing and approvals service for finance teams. Replace the example with your own service, or delete this section and the EXAMPLE passages before the description goes to the CPA firm.

Adapting this template

Small organisation

Regulated or customer-driven

Outsourced providers

Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: AICPA Trust Services Criteria (TSP section 100, 2017, with revised points of focus, 2022), by number and series title only; the AICPA description criteria (DC section 200, 2018, with revised implementation guidance, 2022), by topic only; ISO/IEC 27001:2022 and NIST CSF 2.0, by number and title; the Journal of Accountancy and the AICPA & CIMA pages named in the references; as published and read on 18 October 2026.

The Trust Services Criteria and the description criteria are published by the AICPA for CPAs who examine a service organisation. Nothing in law makes a SOC 2 report mandatory. A customer's contract, a procurement policy or an investor can ask for one, and the organisation chooses whether to commission an examination. The report is a CPA firm's opinion about the organisation's description and its controls. It is an attestation, not a certificate, and nobody is “SOC 2 certified” or “SOC 2 compliant” by holding one.

The observation period lengths, the three-month limit of a bridge letter, the order of the steps and the sample of questions for a CPA firm are market practice and house defaults. They are not rules of the AICPA, and the CPA firm and your customers decide what they accept.

ISO/IEC 27001 references name the clause or control this document relates to, by number and title only. No text of the standard is reproduced. A reference does not say that holding an ISO/IEC 27001 certificate equals, replaces or shortens a SOC 2 examination.

Criteria are cited by number and series title only. The statements of the criteria are in the Library. Citing a criterion does not say that any document, control or practice meets it.

A reference says what its source describes and which CISO Times document helps with that work. It does not say that a document from this pack meets a criterion, and it does not say that an organisation will receive an unqualified opinion.

This pack does not say which document, record or practice meets a criterion. Each reference says what its source describes and which CISO Times document helps with that work. Using a document does not by itself show that a criterion is met.