What is the SOC 2 Management Assertion Letter?
Before your CPA firm can issue a SOC 2 report, management must sign a formal document called the Management Assertion. This is not optional, and it is not a formality. The assertion letter becomes Section 2 of your final SOC 2 report — the section that appears before the auditor’s opinion and before the system description.
Most SaaS founders only hear about the management assertion weeks before their audit closes. By then, they’re scrambling. The reality is that the assertion letter should be drafted and reviewed at the start of your audit preparation process — because drafting it forces you to articulate exactly what your system is, what controls you claim to have, and what trust service categories you’re covering. If you can’t write a clean assertion, you’re not ready for the audit.
What AICPA AT-C §205 Requires
SOC 2 reports are governed by AICPA attestation standards, specifically AT-C §205 (Examination Engagements). This standard requires that management provide a written assertion that is included in the report. Specifically, management must assert:
- The description of the system is fairly presented — that the system description (Section 3 of the SOC 2 report) accurately describes the system as designed and implemented.
- The controls stated in the description were suitably designed — that the controls described were designed appropriately to achieve the relevant control objectives as at the specified date (Type I) or throughout the period (Type II).
- The controls stated in the description operated effectively (Type II only) — that the controls operated effectively throughout the examination period to provide reasonable assurance that the applicable criteria were met.
For a Type I report, you only make assertions 1 and 2. For Type II, all three are required. Bridge letters (issued between annual audits) typically assert that no significant changes have occurred since the last report.
The Three Assertions Explained
Assertion 1: Fair Presentation of the System Description
This assertion says your system description accurately represents reality. The system description covers: the services you provide, the components of the system (infrastructure, software, people, processes, data), how data flows through the system, and the boundaries of the audit scope.
Common failure mode: The system description in the SOC 2 report was drafted at the start of the audit period. By the time the report is issued, the system has changed — you migrated databases, added a new cloud region, or onboarded a major sub-processor. Management asserts a description that is now inaccurate. Auditors will flag this as a misrepresentation if discovered during fieldwork.
Fix: Treat the system description as a living document. Review it at the end of the audit period before signing the assertion. Ensure any significant changes during the period are noted in the description or in a subsequent events note.
Assertion 2: Suitable Design of Controls
This says the controls you describe are designed to achieve the relevant Trust Services Criteria. “Suitably designed” means that if the controls operated as described, they would be capable of preventing or detecting material misstatements or security failures that would prevent the service commitments from being met.
Common failure mode: Management describes controls at a high level in the assertion (“we have MFA”) but the auditor finds during testing that MFA is only enforced for 60% of admin accounts. The control as designed is sufficient; the control as operating is not. This creates a Type I assertion gap.
Fix: Be specific in what you assert. Vague assertions (“we implement access controls”) are hard to test and easy to misrepresent. Specific assertions (“MFA is enforced via [Identity Provider] for all accounts with access to production systems”) are testable and accurate.
Assertion 3: Operating Effectiveness (Type II Only)
This is the assertion that gets founders most nervous — and for good reason. You are asserting that the controls actually operated throughout the entire examination period (typically 3, 6, or 12 months). Not just at the point-in-time assessment date. Throughout.
Common failure mode: A control was implemented midway through the audit period. Management asserts it operated “throughout the period” when in fact it only operated for the last four months. The auditor samples evidence from the full period and finds gaps in the first two months. This creates an exception in the audit opinion.
Fix: Either extend your audit period to start after all controls are implemented, or be explicit in the assertion about when specific controls were implemented. Your auditor should help you scope this correctly.
What Goes in the Management Assertion Letter
A complete management assertion letter contains the following elements:
| Element | What to Include | Common Mistake |
|---|---|---|
| Addressee | The CPA firm conducting the audit | Leaving blank or using generic “To Whom It May Concern” |
| Company identification | Full legal name, registered address, system name | Using trading name instead of legal entity name |
| Audit type and period | Type I / Type II, exact dates (period start and as-of/end date) | Leaving dates vague (“the period ending December 2025” without specifying start) |
| Trust service categories in scope | Security (CC) always + any additional (A, C, PI, P) | Including P (Privacy) without having a proper privacy programme |
| Assertion 1: System description | Formal assertion language re: fair presentation | Wording that hedges (“we believe” instead of asserting) |
| Assertion 2: Control design | Formal assertion language re: suitability of design | Missing specific reference to the applicable criteria (TSC) |
| Assertion 3: Operating effectiveness (Type II) | Formal assertion language re: effective operation throughout the period | Including this assertion in a Type I report (not appropriate) |
| Controls enumeration | Key controls management is asserting (can reference system description) | Being too vague to be testable |
| Complementary User Entity Controls | If applicable: controls users must implement for the system to be secure | Omitting CUECs when the system requires customer-side controls |
| Subservice organisations | If applicable: list of cloud providers/sub-processors and carve-in vs carve-out approach | Using carve-in without obtaining SOC 2 reports from subservice organisations |
| Signature block | CEO/CTO/CISO name, title, date. Some auditors require two signatories. | Signing before the audit period ends |
Carve-In vs Carve-Out for Subservice Organisations
If you use AWS, GCP, or Azure (you almost certainly do), you need to decide whether to use the carve-in or carve-out approach for these subservice organisations:
- Carve-out (most common): Your SOC 2 report excludes the controls at AWS/GCP/Azure. Your assertion says that the system is hosted on [Cloud Provider] and that controls at the cloud provider level are carved out. Readers are expected to review the cloud provider’s own SOC 2 report. This is the simplest approach.
- Carve-in: Your report includes the relevant controls at the cloud provider. You obtain their SOC 2 report and include complementary controls. This is more complex and less common for SaaS companies. Your assertion must explicitly state which subservice organisation controls are included and how they’re evidenced.
Most early-stage SaaS companies use the carve-out approach and include a note in the assertion that “the following subservice organisations provide services that are used by the system: [AWS/GCP/Azure]. Controls at these subservice organisations have been carved out of this examination.”
Bridge Letters
If your annual SOC 2 report covers January 1 to December 31, 2025, but a customer or prospect asks for assurance that controls are still in place in April 2026 (before the 2026 audit is complete), you issue a bridge letter.
A bridge letter is a management assertion that:
- References the most recent completed SOC 2 report (including the report date and period)
- Asserts that management is not aware of any significant changes to controls since the last report
- Specifies the date range the bridge letter covers (e.g. January 1 to April 15, 2026)
Bridge letters are not audited by your CPA firm — they are management’s own assertion. They are commonly requested by enterprise customers and procurement teams during the gap between annual audits. Some CPA firms will issue a comfort letter alongside the bridge letter, but this is optional and not required by AICPA standards.
Important: A bridge letter is only as credible as the controls programme it references. If your controls have materially changed, or if there was a significant security incident, the bridge letter must disclose this. Issuing a bridge letter that fails to disclose a material control failure is a misrepresentation.
SOC 2 Management Assertion: What Auditors Scrutinise
When your CPA firm reviews your management assertion, here’s what they pay attention to:
- Consistency with the system description: Do the controls you assert in the letter match the controls described in Section 3? Inconsistencies are flagged and create re-work.
- Scope accuracy: Does the system description accurately represent the in-scope system? Missing cloud regions, newly added sub-processors, or system components that were added during the period are common issues.
- Appropriate assertion language: Hedging language (“management believes controls are generally adequate”) is replaced by auditors with AICPA-required precise language. Save yourself the revision cycle by using the correct language upfront.
- Signature authority: The signatories must be authorised by the organisation to make these assertions. Typically CEO and CISO, or CEO and CTO for earlier-stage companies.
- Date accuracy: The assertion must be dated after the period end date but typically no more than 60 days later (to avoid the assertion being stale by report issuance).
Practical Timeline
| Stage | Timing | Management Assertion Action |
|---|---|---|
| Pre-audit preparation | 3–6 months before period start | Draft initial assertion; identify system components; confirm scope with auditor |
| Audit period start | Day 1 of examination period | Confirm all asserted controls are in place; document any controls implemented during the period |
| Mid-period review | Halfway through examination period | Review for system changes; update system description if needed; flag any control gaps to auditor |
| Period end | Last day of examination period | Final review of assertion; confirm all three assertions remain accurate |
| Fieldwork | 4–8 weeks after period end | Provide evidence to auditor; respond to management letter questions |
| Draft report review | 2–4 weeks after fieldwork | Review draft assertion in report; confirm accuracy; approve or request corrections |
| Report issuance | Final sign-off | Sign assertion letter; confirm date is appropriate |
Generate Your SOC 2 Management Assertion Letter
Use the SOC 2 Management Assertion Letter Generator to create a complete, properly-structured assertion letter for your Type I or Type II audit. Covers all three required assertions, trust service category scope, system component inventory, controls summary, subservice organisation treatment, and signature blocks.
Related generators: SOC 2 Gap Assessment, SOC 2 Evidence Pack, Information Security Policy, Incident Response Plan, Change Management Policy.
Related reading: SOC 2 Gap Analysis Guide, SOC 2 Evidence Collection Guide, SOC 2 CC8.1 Change Management Evidence Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or compliance advice. SOC 2 management assertions are formal legal documents. Always work with your CPA firm and legal counsel to review and finalise your assertion letter before signing.