What management's assertion in a SOC 2 report must say
Management's assertion is management's written claim that the system description is fairly presented under DC 200 and that the controls described are suitably designed, with operating effectiveness added for a Type 2 report. Management signs the assertion, not the auditor. It is one of four parts of the AICPA's illustrative Type 2 report, alongside the description of the system, the service auditor's report and the tests of controls and results. The auditor's opinion is a separate document that the CPA issues after testing. If your team cannot yet say in writing that the description is accurate and the controls operate as described, the assertion is not ready, and neither is fieldwork.
A SOC 2 is an assertion-based examination under AT-C section 205 of the AICPA attestation standards, so the assertion is the anchor the auditor tests against. DC 200 sets nine description criteria, DC1 to DC9, covering the services provided, principal service commitments and system requirements, system components, significant incidents, the applicable criteria and related controls, complementary user entity controls, subservice organizations, criteria not relevant to the system, and significant changes during the period. Before signing, the assertion's owner should check that each of the nine has a named source and an owner who can confirm it. Confirm with your CPA firm whether it expects the assertion to follow the illustrative wording exactly or to be adapted to your system, and get that answer in writing before the period closes.
The organization owns the controls and the assertion. An implementation partner can help prepare the system description, the control matrix and the evidence that supports each statement, but it cannot sign the assertion, issue the report or give an opinion on it. Ask any partner to state its role in writing, and make sure the people who sign can explain every claim without relying on the partner. Where the description relies on a cloud provider or other subservice organization, confirm which of that provider's controls your management is asserting about and whether the provider's own SOC report covers them.
How the assertion is drafted and signed
The assertion is written last in practice but reviewed first by the auditor, so it only stands up when the scope, the system description, the criteria and the period all line up before management signs. The sequence below produces a reviewed draft and then a signed document that the service auditor can rely on.
Confirm scope and trust services categories
Management, usually the executive sponsor with the security and compliance leads, fixes which system is in scope, which locations and components it includes, and which categories beyond security apply, such as availability or confidentiality. The output is a written scope statement that names the system and categories exactly, because every later sentence in the assertion refers back to it. Done when the executive owner has approved the scope in writing and the auditor has no open questions about its boundaries.
Draft the system description against DC1 to DC9
The control owners write the description of the system, working through the nine description criteria in DC 200: types of services, principal service commitments and system requirements, system components, significant incidents, the applicable criteria and related controls, complementary user entity controls, subservice organizations, criteria not relevant to the system, and significant changes. DC 200 does not prescribe a format, so the team chooses a layout and checks each criterion against it. Done when every DC item has a matching section and a named owner has confirmed the facts in their area.
State the criteria and related controls
The compliance lead lists the trust services criteria in scope and the controls that address each one, drawing from the control matrix so the description and the matrix say the same thing. Points of focus are used as guidance, not as a checklist that must each be addressed. Done when every in-scope criterion maps to at least one control in the description and no control is described that the matrix does not contain.
Align the assertion to the period and description
Management drafts the assertion itself, which states that the description is fairly presented under the description criteria and that the controls were suitably designed. For a Type 1 report the assertion refers to a specified date. For a Type 2 report it refers to a specified period and also states that the controls operated effectively throughout that period. The wording is checked against the description so that the system name, categories, dates and carve-outs match word for word. Done when the draft assertion and the system description have been read side by side and every name, date and boundary agrees.
Get the draft reviewed by the auditor
The draft assertion and system description go to the service auditor, who reviews them for consistency with the engagement, the criteria and the evidence they have gathered so far. Comments are logged, and management resolves each one by revising the wording or the underlying description, not by changing the auditor's testing plan. Done when the auditor has returned no open comments on the assertion and the team has a version both sides accept as the final draft.
Obtain internal sign-off from accountable executives
Before signature, the draft is approved internally by the people who answer for the system: typically the chief executive or another officer with authority to bind the organization, plus the owners of security, operations and any function whose controls appear in the description. Their approval confirms that the statements about their areas are accurate as of the assertion date or period. Done when each named approver has confirmed in writing that the statements in their area are accurate and no description content has changed since the auditor's review.
Deliver the signed assertion with the representation letter
An authorized officer signs the assertion, and management delivers it to the service auditor together with the written representations required under the attestation standards, which the representation letter covers in detail. The auditor uses the signed assertion as the basis for the report, and the report's opinions refer back to it. Done when the signed assertion and the signed representation letter are in the auditor's file, dated consistently with the assertion date or period, and the team confirms that the final report will include the same assertion text.
Three claims in the assertion: description, design and operating effectiveness
Management states that the description of the system is fairly presented in line with the AICPA's 2018 SOC 2 description criteria, DC 200. This claim applies to every SOC 2 report, Type 1 and Type 2 alike. The description covers the types of services, principal service commitments and system requirements, system components, significant incidents, the criteria in scope, related controls, complementary user entity controls, subservice organizations, criteria not relevant to the system, and significant changes during the period. DC 200 is not specific about format, so the organization can present these items in whatever structure is clearest, but every required item must be present.
- Completeness against DC 1 to DC 9: The auditor checks that each description criterion is addressed, including significant system incidents and significant changes during the period, even where the answer is that nothing material occurred.
- Accuracy of components: The auditor compares the listed infrastructure, software, people, data and procedures against what actually exists, often by reviewing configuration exports and architecture records.
- Consistency with commitments: Stated service commitments and system requirements should match the contracts, trust pages and security documentation customers already read.
- Scope of the description: The auditor confirms that excluded criteria and carved-out subservice providers are disclosed clearly, not hidden.
Before signing, confirm that every DC 200 item has a named owner and a source document that supports it.
Management states that the controls described in the report were suitably designed to meet the applicable trust services criteria. Design is a question of whether, if the control operates as described, it would address the risk it targets. The claim is made as of a specified date in a Type 1 report, and in a Type 2 report it is made for the whole period alongside operating effectiveness. A control that is well designed on paper can still fail in practice, but a poorly designed control cannot pass a design test however carefully it is run.
- Mapping to criteria: The auditor checks that each applicable criterion, including the points of focus that apply, has at least one control that addresses it, and that the control matches the risk described.
- Walkthroughs: The auditor traces a transaction or request end to end, such as a new hire receiving access, to confirm the control exists as written.
- Policy and procedure review: Written policies, approval rules and job responsibilities are read to confirm they describe what the control does.
- Gaps and compensating controls: Where a design gap exists, management must disclose it in the description or accept a modified opinion.
Before signing, check that each control in the matrix has an owner, a frequency and a documented design that a new reviewer can follow.
In a Type 2 report, management also states that the controls operated effectively throughout the observation period. This claim is the reason the Type 2 period exists: it asks whether controls worked consistently over time, not only on the day they were examined. The auditor tests this by selecting samples from across the period and checking evidence that each control ran as designed. The period length and sampling approach are agreed with the CPA at the start of the engagement, and management should ask the CPA to confirm both in writing.
- Population and sampling: The auditor defines the population of occurrences, such as access requests or production changes, and draws samples across the period rather than from a single month.
- Testing methods: Inquiry alone is not enough. Auditors combine inquiry with observation, inspection of records and reperformance of the control.
- Exceptions: Any control failure in a sample is an exception that the auditor evaluates and that management must explain in the report, along with the corrective action taken.
- Recurring evidence: Access reviews, change approvals, vulnerability scans and monitoring alerts should be generated on schedule, with timestamps that show they happened during the period.
Before signing, confirm that the evidence for every control exists for the full period and that management has reviewed any exceptions.
The three claims are signed together in one assertion and then support one auditor's opinion. The auditor gives an opinion on whether the description is fairly presented and whether the controls were suitably designed, and in Type 2 reports, whether they operated effectively. In both report types the description opinion stands alongside the control opinions. If the description omits a significant incident or a major change, the auditor may conclude the description is not fairly presented even when every control tested cleanly. Management's assertion is the basis for the auditor's work, so the assertion cannot be stronger than the evidence behind it.
- Shared scope: The system described in the assertion must be the system the auditor examines, with the same boundaries, locations and subservice organizations.
- Sequence of sign-off: Management usually signs the assertion after the description and controls are finalized and before the auditor issues the report, and the representation letter follows the same timeline.
- Opinion versus assertion: The assertion is management's statement, while the opinion is the CPA's independent conclusion. Neither replaces the other.
- Changes after signing: Material changes discovered after the assertion date require a conversation with the CPA before the report is issued.
Confirm with the CPA which dates the assertion must cover and how any changes during fieldwork will be handled.
How DC 200 shapes the description claim
The description claim in management's assertion is judged against the AICPA's 2018 SOC 2 description criteria, known as DC 200. DC 200 sets out nine description criteria, DC1 to DC9, and management has to be able to show that each element of its system description is accurate. The nine cover the types of services provided, the principal service commitments and system requirements, the system components, significant system incidents, the applicable trust services criteria and related controls, complementary user entity controls, subservice organizations and their complementary controls, criteria not relevant to the system, and significant changes during the period. Before the assertion is signed, the team should walk through each of the nine and name the person who can prove that element is correct, whether that is the product owner for services, the platform lead for components or the operations lead for incidents and changes.
DC 200 does not prescribe a format, so the layout of the description is a choice. The practical reference point is the AICPA's illustrative SOC 2 report with an illustrative system description, which shows how a description aligned with DC 200 can be organized. Use it to check that nothing has been left out, not to copy its wording or structure. A useful test is to ask whether each statement in the description could be traced to a system-generated record, a configuration, a ticket or a signed document that the auditor can inspect. Statements about significant incidents and significant changes are the ones most often left vague, so confirm with the operations and engineering leads that the period's events are complete before management relies on them.
The description and the assertion stand or fall together, because the auditor opines on whether the description is fairly presented and then tests the controls it describes. A component or subservice organization that appears in the description but not in the control testing, or a control that is described but never operated during the period, will surface during fieldwork. Ask the auditor early which format they expect, confirm how they will test each DC 200 element, and keep a written record of who verified each one. Where the description relies on a vendor's own SOC report or a carve-out, confirm that the wording in the description matches what that report actually covers.
Where management's assertion goes wrong and how to fix it
Most assertion problems are not legal wording problems. They come from a mismatch between what management says, what the system description shows and what the control matrix actually contains. Each card below names one failure pattern, the fix and the person who should own it.
Period or date mismatch
The assertion must cover the same point in time (Type 1) or the same observation period (Type 2) as the system description and the auditor's opinion. A Type 2 assertion that refers to a different window, or a Type 1 that says "as of" a date different from the description, forces the auditor to rewrite the wording or qualify the report. Before signing, read the assertion, the description header and the report cover side by side and confirm the dates match exactly. Owner: the compliance lead, with the CPA firm checking the final draft.
Control claims missing from the matrix
An assertion that says controls are designed or operating effectively is only as good as the control matrix behind it. If the assertion or description names a control, such as quarterly access reviews or backup restore testing, that does not appear in the matrix with an owner and a frequency, the auditor has nothing to test. Walk each control sentence in the description back to a matrix row, and remove any row that no one actually performs. Owner: the control owners, reviewed by the compliance lead.
Subservice and CUEC treatment left out
Cloud hosting providers, payment processors and other subservice organizations either fall outside the description under the carve-out method or appear within it under the inclusive method. An assertion that does not state which method was used, or that relies on vendor controls without naming them, leaves customers unsure what is covered. The same applies to complementary user entity controls that the service organization expects customers to run. Confirm each subservice organization and each listed CUEC appears consistently in the description and the assertion. Owner: the vendor management lead, with legal reviewing contract references.
Aspirational system description
DC 200 asks management to describe the system as it operates, including components, incidents and significant changes during the period. A description written from the target architecture, or one that omits a legacy service still in production, makes the assertion inaccurate on its face. Compare each component named in the description against the current asset inventory and the change log for the period, and record any significant incident the description should disclose. Owner: the platform engineering lead, with security signing off on incidents.
Operating effectiveness claims in Type 1
A Type 1 report covers the design of controls at a point in time, not whether they worked over a period. Assertion language that says controls "operated effectively" in a Type 1 engagement claims something the examination does not test. Keep Type 1 wording to design and suitability, and reserve operating effectiveness language for Type 2 assertions tied to a defined observation period. Owner: the compliance lead, confirmed against the engagement letter with the CPA firm.
Template assertions signed without review
Assertion wording copied from another company's report or a generic template often names the wrong system, services, categories or subservice providers. Each sentence should reflect the organization's own system boundary, the criteria in scope and the people who sign. Read every noun in the assertion, from the service name to the trust services categories, and confirm it matches the engagement letter. Ask the CPA firm to flag any wording it has not seen in your own environment. Owner: the executive signatory, after a line-by-line review by the compliance lead.
How the assertion lines up with the auditor's opinion
The CPA's opinion tests management's assertion, and the assertion is management's own claim. In both Type 1 and Type 2 reports, the service auditor gives an opinion on whether management's description of the system is fairly presented, alongside opinions on whether the controls are suitably designed and, for Type 2, operated effectively over the period. The assertion is the statement that sets those three claims side by side, so the auditor reads it as the thing being examined, not as a summary the auditor wrote. The auditor does not draft the assertion, and it cannot rewrite management's claims into its own wording. If management's view is that a control operated, the auditor tests that view against evidence. It does not adopt a more favorable version of it.
The illustrative Type 2 report in the AICPA's guide has four parts: management's assertion, the description of the system, the service auditor's report, and the tests of controls and results. Read together, they should agree. If the assertion says a control was in place for the whole period, but the description omits it, or the test results show exceptions the description does not mention, the auditor has a conflict to resolve. An unresolved inconsistency between the assertion, the description and the test results is a reason the opinion may be modified. Before fieldwork closes, have someone outside the control owners compare each statement in the assertion against the matching description section and test result. A mismatch found by that reader is cheaper to fix than one the auditor raises.
Only the independent CPA firm issues the SOC 2 report and its opinion. The organization signs the assertion and owns the controls it describes. A DeployOpen engagement, or any implementation partner's, can help prepare the system description, control evidence and draft wording for management's review, but it does not sign the assertion, issue an opinion or certify compliance. Confirm with the CPA firm early which draft wording and evidence it will accept, and keep a record of every change made to the assertion during the engagement, because the auditor will ask why each version changed.
Who signs the assertion and who prepares it
A SOC 2 assertion is signed by the organization, not by the people who helped build the evidence. Each role below has a distinct job, and the signing role is the organization's decision to confirm with its CPA firm before fieldwork starts.
Accountable executive who signs
A senior officer with authority over the service, usually the CEO, CTO or CISO, signs the assertion on behalf of management. The signer is attesting that the system description is fairly presented and that the controls are suitably designed, and for Type 2 that they operated effectively over the period. Before signing, confirm with the CPA firm who it will accept as the signatory and whether the same person signs the representation letter.
Compliance lead who drafts
The compliance lead owns the drafting of the assertion and the system description, and keeps the document consistent with the control matrix and the auditor's requests. This person checks that every system component, commitment and subservice organization named in the description matches what engineering actually runs. Drafts should be dated and version-controlled so the signed version can be traced to the evidence period.
Control owners who confirm
Each control owner confirms in writing that the control described for their area exists, operated as stated, and that exceptions were known and handled. Control owners in engineering, HR and facilities are the people who can say whether a quarterly access review actually happened. Their confirmations become the basis for the management claims the signer makes.
Legal and contracts review
Legal or contracts staff review the assertion for consistency with customer commitments, the stated principal service commitments and any restrictions on who may use the report. They also check that the description does not promise more than the contracts or the trust page say. Ask counsel to confirm how the report may be shared, since use of a SOC 2 report is generally restricted.
Implementation partner who prepares
An implementation partner can prepare the system description drafts, configure the platform controls, and assemble the evidence the auditor will request. The partner does not sign the assertion, does not represent management, and does not issue any report or opinion. Confirm in the written scope exactly which drafts and evidence the partner produces and which decisions remain with the organization.
Independent CPA who examines
The independent CPA firm performs the examination, tests the controls, and issues the opinion in the service auditor's report. The CPA gives its opinion separately from management's assertion, and it must be independent of the organization. Ask the firm to confirm in writing which draft documents it will review, and when, so that its opinion is formed on the signed assertion and not a moving target.
How the assertion relates to the representation letter
The management's assertion and the representation letter are two separate documents, and the auditor needs both. AT-C section 205 requires the service auditor to obtain written representations from management, and a SOC 2 is an assertion-based examination, so the assertion is the formal statement that management makes about the system description and the controls. The representation letter is the wider set of written statements management gives the CPA at the end of fieldwork. Keeping them distinct matters because the assertion is attached to the report and shared with the examination, while the letter stays with the auditor's working papers and supports the opinion behind it.
The letter contains further representations that the auditor relies on, including statements about matters that the assertion does not cover in detail, such as known instances of noncompliance, communications with regulators, and the completeness of information provided during fieldwork. Your team should not treat the assertion as the only sign-off. Read the AICPA's illustrative Type 1 and Type 2 letters against your own draft assertion, and check that every factual claim in the assertion has a matching representation or supporting record. The detail of those representations belongs in the SOC 2 management representation letter topic, so start there rather than rebuilding the list from this page.
Proposed revisions to the AICPA's baseline attestation standards were exposed in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029, so the wording and representations you sign in your first engagements may fall under the current standards. Confirm with your CPA which version applies to your engagement period, and ask whether any change to representations would affect the assertion wording before you draft it. The Journal of Accountancy's coverage of the February 2026 proposal is a useful starting point for that conversation.
Questions buyers ask about the SOC 2 management assertion
Who must sign the management assertion in a SOC 2 report?
Management of the service organization signs it, not the CPA firm. The assertion is a written statement by the people who run the system, typically a senior executive such as the CEO, CTO or CISO, who answer for the description and the controls. The auditor then reports on that statement. Ask your engagement letter and your auditor which titles they expect to see on the signature block, because the wording and the signatory can differ by firm. Signing carries personal accountability, so the signatory should have reviewed the description and the control evidence before signing.
Can the auditor draft the management assertion for us?
The auditor can explain what the assertion must cover, but drafting it is management's responsibility. Independence rules restrict what an attest client's auditor may prepare on the client's behalf, and the assertion is management's own statement. Many firms will review a draft and comment on wording, which is a normal part of fieldwork. Ask the auditor in writing which parts of the assertion they will review, what they will not write for you, and how comments are handled. The scope of those services belongs in the engagement letter.
Can a consultant or implementation partner prepare the assertion?
A consultant or partner can prepare a draft, assemble supporting material and check that the description matches the system, but management must own the final text and sign it. Preparation support usually covers the system description, control mapping, evidence index and a review against the criteria. The partner does not issue the assertion or the opinion. Confirm in the statement of work exactly which documents the partner drafts, which reviews management performs, and who keeps version control, so the signed version matches what the auditor tested.
What changes in the management assertion between a Type 1 and a Type 2 report?
A Type 1 assertion speaks as of a specific date: it says the description is fairly presented and the controls were suitably designed at that point. A Type 2 assertion covers a period of time and adds a statement that the controls operated effectively throughout that period. The Type 2 assertion therefore depends on operating evidence across the whole observation window, not a snapshot. The AICPA's illustrative management representation letters show the additional representations expected for Type 2. Check the current letter with your auditor before drafting.
Is the management assertion shared with customers?
The assertion is included in the SOC 2 report itself, usually as the first part, so customers who receive the report also receive it. It is not usually distributed separately. Customers reading a report should check that the assertion covers the same system, categories and period as the description and opinion. Use restricted distribution for the full report, and consider a SOC 3 report if you need a general use document for public sharing, since that report contains less detail.
What happens if the system description changes during the audit period?
If the system changes during the period, management must describe significant changes in the description and reflect them in the assertion. The assertion must not describe a system that differs from what was operating during the period. Significant changes, such as a new hosting platform, a changed subservice organization or a new product, can affect scope and the sampling plan. Raise any change with your auditor early, because an undisclosed change discovered during fieldwork can lead to exceptions or a qualified opinion. Document the change, its date and the controls affected.
How much effort does the management assertion add to a SOC 2 engagement?
The assertion itself is short, but the work behind it is not. Effort depends on how current the system description is, how many subservice organizations and carve-outs apply, how many control owners must confirm their areas, and how much evidence management reviews before signing. Expect the work to be front-loaded in the first examination, then lighter when the description and control records are maintained. Ask any consultant or auditor for a written estimate of management review time, and confirm the timeline in your engagement letter.
How DeployOpen prepares the system description and evidence behind the assertion
DeployOpen works on the material management relies on when it signs the assertion: the system description, the control set and the evidence behind each claim. We prepare these inside your own infrastructure, while your leadership owns every statement and an independent CPA firm performs the examination and issues the report.
How we scope
- Engagements are fixed-scope, with the systems, locations and trust services categories agreed in writing before work starts.
- We confirm which system components, boundaries and services the description will cover, so the assertion matches what the auditor will test.
- The written scope lists which parts are handled by subservice organizations and which are expected from your customers as user entity controls.
How we build
- We draft a system description structure that follows the description criteria, with each required element mapped to a source document or system owner.
- We configure self-hosted open-source platforms so the controls named in the description run and produce records in your environment.
- We test each stated control internally against the evidence it should generate, so gaps surface before the CPA firm begins fieldwork.
How we hand over
- You receive the system description, control documentation and evidence mapping in editable form, with an owner named for each statement.
- We provide a review checklist that lets management confirm each sentence of the assertion against the underlying records before signing.
- Runbooks and configuration records are handed over so your team can explain controls and produce evidence without us in the room.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so the description stays accurate through the examination period.
- We can help your team update the system description when platforms, components or subservice providers change during the period.
- Questions from the CPA firm about the description or evidence can be routed to the team that built the controls, with the records to answer them.
Sources and further reading
- AICPA Guide: SOC 2 Reporting on an Examination of Controls at a Service Organization ↗
- AICPA 2018 SOC 2 Description Criteria (revised implementation guidance, 2022) ↗
- AICPA Illustrative SOC 2 Report with Illustrative System Description ↗
- AICPA Illustrative Management Representation Letter: SOC 2 Type 2 ↗
- Journal of Accountancy (AICPA): Auditing Standards Board proposes changes to attestation standards (February 2026) ↗
