Compliance Artifacts

The SOC 2 management assertion, explained (with example)

The SOC 2 management assertion is the formal written statement — Section II of your SOC 2 report — in which management declares that the system description is accurate and that controls were suitably designed and, for a Type II, operating effectively. The auditor examines — and opines on — the same claims the assertion makes. Here’s what it must say, who signs it, and a skeleton you can adapt.

Talk to a Compliance Engineer

Last updated July 26, 2026

Where the assertion sits in a SOC 2 report

In most SOC 2 reports the structure repeats: Section I is the independent service auditor’s report — the opinion — and Section II is management’s assertion, usually one to two pages on your letterhead. It’s where your company formally states that the Section III system description is accurate and the controls it describes were suitably designed — and, in a Type II examination, operated effectively.

The assertion isn’t ceremony bolted onto the report; it’s the legal architecture of the whole exercise. SOC 2 is an attestation engagement: management makes claims, and the auditor examines and opines on those claims. No assertion, no opinion — audit firms won’t release a report until a signed assertion is in hand, and the attestation standards treat a refusal as a stopped engagement.

The three claims you’re actually making

Strip the boilerplate and a management assertion makes three claims. First, the system description is fairly presented: it describes the system that actually exists, measured against the AICPA’s description criteria, without material omissions or embellishment. Second, the controls described were suitably designed — if they operate as written, they would achieve the service commitments and system requirements you’ve made, per the applicable trust services criteria. Third, Type II only: those controls operated effectively across the entire observation period, not merely on the day someone checked.

Two supporting statements ride along. If you carve out subservice organizations — your cloud provider, almost always — the assertion acknowledges that the description excludes their controls and assumes complementary subservice organization controls (CSOCs) on their side of the line. And where certain criteria can only be met if customers do their part, the assertion points to the complementary user entity controls (CUECs) listed in the description. Both sentences matter because they mark exactly where your accountability ends.

A realistic skeleton you can adapt

Example management assertion (Type II)

[Company Letterhead]

Assertion of [Company, Inc.] Management

We have prepared the accompanying description of the [Platform Name] system of [Company, Inc.] for the period [January 1, 2026] through [December 31, 2026] (the “description”), based on the criteria for a description of a service organization’s system set forth in the AICPA Description Criteria (the “description criteria”).

The description indicates that [Company, Inc.] uses [Cloud Provider] as a subservice organization for infrastructure hosting. The description presents the types of complementary subservice organization controls assumed in the design of our controls; it does not disclose the actual controls at the subservice organization.

The description also indicates that certain applicable trust services criteria can be achieved only if complementary user entity controls assumed in the design of our controls are suitably designed and operating effectively, along with our own controls.

We confirm, to the best of our knowledge and belief, that: (a) the description fairly presents the [Platform Name] system that was designed and implemented throughout the specified period; (b) the controls stated in the description were suitably designed throughout the specified period to provide reasonable assurance that our service commitments and system requirements would be achieved, based on the applicable trust services criteria for [security, availability, and confidentiality]; and (c) the controls stated in the description operated effectively throughout the specified period.

[Name]
[Title — e.g., Chief Executive Officer]
[Company, Inc.]
[Date of the auditor’s report]

What a complete assertion includes

Auditors reconcile every line against the description and the opinion letter — mismatches come back as review notes.

The exact system name and the exact period (or, for a Type I, the point-in-time date) — matching Section I and Section III to the day.
A statement that the description is fairly presented, based on the AICPA description criteria.
A statement that controls were suitably designed to meet your service commitments and system requirements under the applicable trust services criteria.
For a Type II: the operating-effectiveness claim across the whole period — the sentence that separates the two report types.
The trust services categories in scope — security at minimum, plus whichever of availability, confidentiality, processing integrity, and privacy you’ve added.
Carve-out language naming each subservice organization, with the complementary subservice organization controls assumption.
A pointer to complementary user entity controls where criteria depend on your customers.
A signature from an officer with genuine authority over the system, dated to the report’s issuance.

Who signs it — and who actually drafts it

The signer should be the most senior person with real knowledge of the system: the CEO or CTO at a startup, the CISO or a compliance officer at a larger company. Auditors care less about the title than the authority — the assertion is your company speaking, so the name on it must be someone who can genuinely bind the company to its claims.

Drafting is more collaborative than the formality suggests. Most audit firms hand over a template keyed to their opinion letter, and whoever owns the system description adapts it. That’s normal; what’s not is treating it as the auditor’s document. Independence rules prevent the firm from authoring management’s claims for management — you adopt the language, verify every date, system name, and scope statement, and own the result.

The recurring review notes are all mismatches: a period off by a day from the opinion letter, last year’s dates surviving in this year’s template, a trust services category added to the audit but missing from the assertion, or a subservice organization the description names that the assertion forgot. None are fatal; each costs a redraft during the week you most want the report out the door.

Management assertion vs bridge letter

The two get conflated because both are management statements about your controls, unsigned by any auditor. The difference is placement and purpose. The assertion lives inside the SOC 2 report, speaks to the audited period, and is the prerequisite the auditor formally opines on. A bridge letter is issued after the report, outside it, to cover the months between the period’s end and today — the auditor is never involved. One is the foundation of the attestation; the other is a courtesy that keeps a finished report useful while the next one is in flight.

How Agency handles the assertion

For companies whose SOC 2 programs Agency operates, the assertion and the system description are drafted as a matched pair — same system name, same boundaries, same period, same subservice organizations — then reconciled against the auditor’s opinion letter before anything is signed. Your executive signs a document that has already survived the cross-checks, usually in a single pass.

Earlier in the journey? Start with the SOC 2 framework overview, or see what an operated program takes off your plate on the SOC 2 end-to-end page.

Frequently asked questions

Who writes the management assertion — us or the auditor?

You do, though nearly every audit firm provides a template aligned to its opinion letter. Management adapts it, verifies the system name, period, categories, and subservice organizations, and signs. The firm can supply the skeleton but cannot author your claims — the entire engagement is the auditor examining what management asserts.

Can a SOC 2 report be issued without a management assertion?

No. Attestation standards require a written assertion before the auditor can opine, and a refusal to provide one halts the engagement. If you’ve received a draft report, the assertion request is arriving with it — the two documents are finalized together.

How does the assertion differ between Type I and Type II?

A Type I assertion speaks to a single date: the description is fairly presented and controls were suitably designed as of that day. A Type II assertion adds the claim that controls operated effectively across the whole observation period — more weight, more exposure, and a good reason for the signer to read the auditor’s exception list first.

When in the audit do we actually sign it?

At the end. The assertion carries the report’s issuance date and is signed once fieldwork is complete and the description has stabilized. Signing earlier buys nothing — any late change to scope, period, or the description forces a re-issue.

Can we sign the assertion if the auditor found exceptions?

Usually, yes. Isolated exceptions appear in the auditor’s test results without falsifying the overall claims, and management can add a response in the report’s final section. What changes the calculus is pervasive failure: if key controls materially didn’t operate, the honest path is discussing a modified assertion or a qualified opinion with your auditor — not signing and hoping.

Keep going

SOC 2 Framework Audited Compliance SOC 2 Readiness Checklist Glossary: Evidence Collection

Sign an assertion that’s already been checked

Agency drafts the assertion and system description as a matched pair and reconciles both against your auditor’s opinion letter before anyone signs. Top-ranked Vanta & Drata partner · 1,000+ companies served since 2021 · 4.9/5 on G2.