SOC 2 requirements: what the Trust Services Criteria require

The description must state the types of services the system provides to user entities, in enough detail that a reader understands what the customer actually buys and what the system does for it. Management writes this part, and the CPA firm checks that it matches how the service really runs. An assessor reads it first because every later judgment depends on whether the scope is clear. A vague service statement leads to tests that cover the wrong things. Ask your CPA firm early which services they expect you to describe, so the text reflects the boundary they will test.

Management must describe the commitments it makes to customers about the service, such as uptime, data handling or confidentiality promises, and the system requirements it set to meet them. These are the yardstick for the trust services criteria. An assessor uses them to judge whether the controls address real promises rather than generic ones. If a contract promises a recovery time or a retention period, the description should say so. Commitments that appear only in marketing copy and not in the description create confusion during fieldwork.

The description must identify the components that make up the system: infrastructure, software, people, procedures and data. Infrastructure and software describe the technical stack, people describe the teams and roles that operate it, procedures describe the routines they follow, and data describes what information the system handles and where it lives. An assessor compares this inventory with the systems sampled during testing. If a production database or an administrative tool appears in testing but not in the description, the assessor will question whether the boundary is accurate. Keep the inventory current, because it changes as infrastructure changes.

Yes. For a Type 2 report, management must describe significant system incidents that occurred during the period covered, including their nature and how they were resolved. An assessor reads this section to see whether the organization is candid about failures and whether the controls responded as designed. Omitting a significant incident is a serious problem, because the auditor may find it through other evidence, such as customer complaints or support records. Describing incidents accurately, with the corrective steps taken, usually builds more confidence than a clean-looking history.

Management must identify which trust services categories are in scope, such as security alone or security with availability, and describe the controls that address the applicable criteria. Security always applies through the common criteria CC1 to CC9. Other categories are added only when they are in scope. An assessor compares this section with the control matrix and the tests performed, so every in-scope criterion should map to a described control. Gaps here usually show up as exceptions during testing, so mapping controls to criteria before fieldwork pays off.

Complementary user entity controls are controls that the service organization expects its customers to operate themselves for the overall control objectives to be met, such as managing their own user accounts or reviewing their own reports. The description must state them so customers know their responsibilities. An assessor checks that the list is accurate and that the service organization does not quietly depend on controls it never mentioned. Customers rely on this section when they review the report, so clear wording reduces disputes later.

The description must name significant subservice organizations, such as cloud hosting providers, and explain how they contribute to the system. Management must also state whether the subservice organization is carved out or included, and list any complementary subservice organization controls the service depends on. Cloud providers commonly publish their own SOC reports, which can support this section. An assessor checks that the carve-out or inclusion choice matches how the report is scoped, and that reliance on a provider is stated plainly. Confirm the provider's report coverage and date with the provider before relying on it.

Management must list any applicable trust services criteria that are not relevant to the system and explain why they were excluded. This applies to criteria inside an in-scope category, not to the common criteria, which always apply to security. An assessor tests whether the exclusion is justified by the system's actual design. An unsupported exclusion is a common reason an auditor asks for more information, so the reasoning should be written down and reviewed before the examination begins. Ask your CPA firm to confirm which exclusions they will accept.

For a Type 2 report, management must describe significant changes to the system during the period under examination, such as a new hosting region, a replaced identity platform or a reorganized support team. An assessor uses this to decide whether the tests cover the system as it actually ran, because a control tested before and after a major change may need separate testing. Changes that are not disclosed often produce findings or a qualified opinion. Keep a dated change record so that this section can be written from facts rather than memory.

No. Only the 33 common criteria, CC1.1 to CC9.2, apply to every SOC 2 because they cover the security category. The other 28 criteria belong to availability (A1, 3 criteria), confidentiality (C1, 2), processing integrity (PI1, 5) and privacy (P1 to P8, 18), and they apply only when the organization includes those categories in scope. Scope is set by the services a customer buys and the commitments the organization makes, so a provider that promises uptime may add availability, while one that handles personal data may add privacy. Confirm the category list in the scoping step before any control work starts, because each added category adds criteria the auditor will test.

Often yes, if someone internal owns the program and has time to run it. The criteria are outcome based, so the organization decides how to design and operate its controls, and nothing in the framework requires a consultant. The effort comes from the work around the controls: writing and approving policies, mapping each criterion to a control, configuring systems, collecting recurring evidence, running access reviews, and documenting exceptions. Teams that lack staff with audit experience often find the evidence trail takes longer than the technical fixes. The CPA firm that issues the report must still be independent of the work it tests, so the question is whether your team can run the controls while an outside firm examines them.

The effort depends on the number of systems in scope, how many people hold production access, how mature existing processes are, and whether the review is a Type 1 or a Type 2. Type 2 adds a period of operation during which controls must run and leave evidence every time, so recurring tasks such as access reviews, vulnerability scans, change approvals and training records become a standing cost in staff time. Ask any advisor to break the effort into one-time work (scoping, policy drafting, control design, remediation) and recurring work (evidence collection, reviews, monitoring). Ask also who in your organization will own each recurring task, since unowned tasks are the most common cause of exceptions in the report.

No. Points of focus are characteristics that can help an organization design and evaluate controls against a criterion. The 2017 Trust Services Criteria state that they are not separate requirements and that not every point of focus has to be addressed. What matters is whether the controls, taken together, meet the criterion's objective for the systems in scope. An organization may reasonably omit a point of focus that does not fit its design, but it should be able to explain that choice to the auditor and show that the criterion is still met. Treating the points of focus as a checklist usually produces redundant controls and evidence that nobody reviews.

No. A SOC 2 is an attestation report issued by an independent CPA firm. It contains management's assertion, a description of the system, the service auditor's opinion and, for a Type 2, the tests of controls and results. The report describes what the auditor found as of a date (Type 1) or over a period (Type 2). There is no SOC 2 certificate, and claims of being SOC 2 certified or compliant in a few days should prompt questions about who issued the report. Ask for the signed report itself, check the issuing firm's license, and read the opinion and any exceptions.

The organization owns its controls, its system description and management's assertion, and the decisions behind them. Management signs the assertion and the written representation letter, so those documents cannot be delegated to a consultant. A partner can prepare systems, configuration, documentation drafts, evidence collection routines and remediation work, but it does not issue the report. Only the independent CPA firm performs the examination and issues the opinion. Before engaging anyone, write down which tasks sit with named internal owners, which go to the partner under a written scope, and which belong to the auditor. Ambiguity here is a common source of independence questions and delays.

Consider a readiness partner when your team lacks people who have run an examination, when the systems in scope are complex or spread across cloud accounts, or when the first report is needed for a deadline you cannot move. A partner is most useful before the observation period starts, during scoping, control mapping and gap remediation, when changes are cheapest. Ask for a written scope with deliverables and a timeline before work begins, and confirm that the partner will not sign or influence the auditor's opinion. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure and prepares controls and evidence for the assessment, but the CPA firm you select issues the report. Confirm the scope with us in writing before committing to any part of the program.