Learn · SOC Reports
The Management Assertion
in a SOC 2 Report
Section 2 is the shortest substantive section of a SOC 2 report and the only one you sign — management's written statement that the description of the system meets the description criteria, that the controls stated in it were suitably designed, and, in a Type 2, that they operated effectively throughout the period.
It is your statement, not the auditor’s. A SOC 2 is an assertion-based examination under AT-C section 205, and the written assertion is a practical precondition for the engagement rather than a formality inside it.
Plain-English explainer · AT-C 205 · DC section 200 · Last reviewed August 2026
The management assertion is a signed statement from the service organisation confirming three things: that the description of the system is presented in accordance with the description criteria, that the controls stated in it were suitably designed, and — in a Type 2 — that those controls operated effectively throughout the stated period. It is the only part of the report your organisation writes and signs, and it is why the report exists. AT-C section 205 — retitled Assertion-Based Examination Engagements by SSAE No. 21 — requires the practitioner to request a written assertion from the responsible party (.10). Where the engaging party is also the responsible party, refusal obliges the practitioner to withdraw where that is possible under applicable law (.84) and to disclaim an opinion where it is not (.85). No assertion, no opinion, no report.
Authorship
The one section you write and sign
A SOC 2 report reads as one document in one voice, which is why buyers and vendors alike misattribute it. It has two authors and one shared section.
| Section | Authored by | What that means |
|---|---|---|
| Section 1Independent Service Auditor’s Report | The CPA firm | The only assurance in the document. Signed by the firm, not an individual. |
| Section 2Management’s Assertion | Service-organisation management | Requested under AT-C 205 .10 and reproduced in the report. The firm may supply template wording; it cannot own the assertion or sign it, and the assertion cannot rest on the auditor’s procedures. |
| Section 3Description of the System | Management, against DC section 200 | Your prose. The auditor tests whether it meets the description criteria. |
| Section 4Criteria, Controls & Tests | Controls by management; tests by the auditor | Split authorship. The control text is still your statement, carried by your assertion. |
| Section 5Other Information (optional) | Management — unaudited | Outside the opinion, and outside your assertion. |
| Not in the reportManagement Representation Letter | Management, to the auditor | Required by AT-C 205 .51. Repeats the assertion, adds completeness, access, fraud and subsequent-events representations. |
The split is structural. AT-C section 105 makes it a precondition of any attestation engagement that the responsible party is someone other than the practitioner and takes responsibility for the underlying subject matter (.27a), and AT-C 205 .A12 is blunt: whatever procedures the practitioner performs, the responsible party must accept responsibility for its assertion, and an assertion based solely on the practitioner’s procedures is not a reasonable basis. Paragraph .A11 is equally clear the other way — a practitioner may be engaged to assist the responsible party in measuring or evaluating the subject matter against the criteria in connection with providing that assertion. Drafting help is permitted; ownership is not transferable. That is the honest limit of what a readiness partner can do, ours included. Tranquility Cybersecurity runs readiness and coordinates the examination through independent licensed CPA firms — and your own officer still signs, on your own processes.
Clause by clause
An annotated model assertion
Assertions are far more standardised than descriptions, which is why deviation is informative. Below is an illustrative assertion for the six-month Type 2 used as the worked example later on — Security and Confidentiality, period 1 April to 30 September 2026, carve-out method — followed by the same document annotated clause by clause.
Illustrative only — your CPA firm supplies engagement-specific wording. Do not paste this.
Management’s Assertion Regarding the Description of [Service Organisation, Inc.]’s [System Name] Throughout the Period 1 April 2026 to 30 September 2026, and the Suitability of the Design and Operating Effectiveness of Controls Relevant to Security and Confidentiality
We have prepared the accompanying description of [Service Organisation, Inc.]’s [System Name] (the description) throughout the period 1 April 2026 to 30 September 2026, based on the criteria for a description of a service organisation’s system set out in DC section 200, 2018 Description Criteria for a Description of a Service Organization’s System in a SOC 2 Report (With Revised Implementation Guidance — 2022) (the description criteria). The description is intended to provide report users with information about the system that may be useful when assessing the risks arising from interactions with it, particularly information about the controls we designed, implemented and operated to provide reasonable assurance that our service commitments and system requirements were achieved based on the trust services criteria relevant to security and confidentiality (the applicable trust services criteria) set out in TSP section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022).
We use [Cloud Infrastructure Provider] (the subservice organisation) for hosting services. The description indicates that complementary subservice organisation controls that are suitably designed and operating effectively are necessary, along with the controls at [Service Organisation, Inc.], to achieve our service commitments and system requirements based on the applicable trust services criteria. The description presents our controls, the applicable trust services criteria, and the types of complementary subservice organisation controls assumed in the design of our controls. The description does not disclose the actual controls at the subservice organisation.
The description also indicates that complementary user entity controls that are suitably designed and operating effectively are necessary, along with the controls at [Service Organisation, Inc.], to achieve our service commitments and system requirements based on the applicable trust services criteria. The description presents the types of complementary user entity controls assumed in the design of our controls; it does not disclose the actual controls at user entities.
We confirm, to the best of our knowledge and belief, that:
a.the description presents the system that was designed and implemented throughout the period 1 April 2026 to 30 September 2026 in accordance with the description criteria;
b.the controls stated in the description were suitably designed throughout the period 1 April 2026 to 30 September 2026 to provide reasonable assurance that our service commitments and system requirements would be achieved based on the applicable trust services criteria, if the controls operated effectively throughout that period, and if the subservice organisation and user entities applied the complementary controls assumed in their design; and
c.the controls stated in the description operated effectively throughout the period 1 April 2026 to 30 September 2026 to provide reasonable assurance that our service commitments and system requirements were achieved based on the applicable trust services criteria, if the complementary subservice organisation controls and complementary user entity controls assumed in the design of our controls operated effectively throughout that period.
[Signature]
[Name], Chief Technology Officer
[Service Organisation, Inc.]
12 November 2026
The modified variant — confirmation (c) when management excepts a matter
c. the controls stated in the description operated effectively throughout the period 1 April 2026 to 30 September 2026 to provide reasonable assurance that our service commitments and system requirements were achieved based on the applicable trust services criteria, with the exception of four changes deployed to the production environment between 11 and 14 June 2026, for which the approval required by the control stated in the description did not precede deployment and was recorded retrospectively on 17 June 2026. Other than the matter described above, the controls stated in the description operated effectively throughout the period, if the complementary subservice organisation controls and complementary user entity controls assumed in the design of our controls operated effectively throughout that period.
Confirmations (a) and (b) are unchanged, because the description was corrected before issue and the control remained suitably designed. Only operating effectiveness is excepted, and the excepted matter is stated in the same terms Section 4 uses to report it.
Nine clauses carry the whole document, and each one commits you to something specific. Pasting in language that does not match your actual scope is the commonest drafting failure we see, so the annotation below is a reading aid for checking your own draft — not a template.
Preparation and ownership
“We have prepared the accompanying description of [Entity]’s [System] …”
Commits you to. You wrote the description — not your consultant, platform or auditor — and its accuracy stays yours.
Named legal entity and system
The exact registered name, any “doing business as”, and the system’s name.
Commits you to. Binds the assurance to one entity and one system. If customers contract with another group company, the report does not reach it.
The period, or the as-of date
“… throughout the period 1 April 2026 to 30 September 2026 …”
Commits you to. Fixes the window. Every clause below is bounded by it; nothing after the end date is asserted.
The description criteria
A reference to DC section 200, the 2018 description criteria for a SOC 2 report (with revised implementation guidance, 2022).
Commits you to. You measured the description against published criteria. DC 200 is SOC 2-only; SOC 1 runs on AT-C 320 instead.
Applicable trust services criteria
The categories in scope — Security always, plus any of Availability, Processing Integrity, Confidentiality, Privacy — citing TSP section 100.
Commits you to. Names what was examined. Asserting a category you did not scope is a misstatement, and the easiest mismatch to catch against Section 1.
Subservice organisations and method
That subservice organisations are used and their complementary controls are necessary alongside yours.
Commits you to. Discloses what you are not covering. Under carve-out you also state the description omits the subservice organisation’s actual controls.
Complementary user entity controls
That CUECs are necessary, with your controls, to achieve the service commitments.
Commits you to. Records that part of the control environment sits at your customers. Each CUEC named claims you designed around it and communicated it.
The confirmations
“We confirm, to the best of our knowledge and belief, that: (1) the description presents the system …; (2) the controls were suitably designed …; (3) they operated effectively …”
Commits you to. The substance — three in a Type 2, two in a Type 1. The conditional tail states a dependency on complementary controls, not an escape hatch.
Signature and date
Entity, signing officer, title, and a date — in practice the same date as the auditor’s report.
Commits you to. Fixes who is responsible, and as of when. AT-C 205 .55 fixes the report date for the representation letter; firms carry the same date onto the assertion so the two agree. An assertion dated before fieldwork closed covers work the signatory had not seen.
Type 1 vs Type 2
How the wording tracks the report type
Moving from a Type 1 to a Type 2 changes what you confirm and, more consequentially, what you must evidence.
| Dimension | Type 1 assertion | Type 2 assertion |
|---|---|---|
| The sentence itself | “… the controls stated in the description were suitably designed as of 30 September 2026 to provide reasonable assurance that our service commitments and system requirements would be achieved …” | “… the controls stated in the description operated effectively throughout the period 1 April 2026 to 30 September 2026 to provide reasonable assurance that our service commitments and system requirements were achieved …” |
| Confirmations | Two: the description meets the description criteria; the controls were suitably designed. | Three: the same two, plus operating effectiveness across the period. |
| What the signer must have looked at first | A point-in-time walkthrough pack — each control existing and configured on the date, evidenced once. | Six or twelve months of agreed populations and their reconciliations, plus every exception raised in fieldwork. |
| Can a bridge letter extend it | No — there is no period to extend. A bridge letter after an as-of date says almost nothing. | Partially. It covers the gap between period end and today with management’s own unexamined statement. No procedures, no opinion. |
| What procurement does with it in year two | Commonly accepted only for a first report, and often on condition a Type 2 follows. Market practice, not a rule. | Expected annually, with the new period starting where the last one ended. Buyers who diff period dates find the gaps. |
| If the period is shortened mid-engagement | Not applicable — the as-of date moves, and design evidence moves with it. | The assertion, the opinion and every population definition move together. A shortened period cannot be papered over by editing the assertion alone. |
An assertion saying “throughout the period” against an opinion saying “as of” a date is a drafting error worth catching before issue. A SOC 1 assertion does the same job against control objectives under AT-C section 320, so SOC 1 wording pasted into a SOC 2 assertion cites the wrong criteria.
The precondition
Why there is no opinion without it
An examination needs something to examine, and in an assertion-based engagement that something is management’s own evaluation of the subject matter against the criteria. Where a different party engages the firm — a customer, a regulator — and the responsible party refuses, .86 lets the practitioner report on the subject matter but requires the refusal to be disclosed and the report restricted to the engaging party. In ordinary SOC 2 practice you are both parties, so the withdraw-or-disclaim branch is the live one.
A precision note on the word precondition. AT-C section 105 sets out the formal preconditions for an attestation engagement — independence, and a responsible party other than the practitioner who takes responsibility for the underlying subject matter (.26–.27) — and the written assertion is not one of them. It is a .10 requirement whose refusal, under .84 and .85, ends the engagement. That is why it functions as a precondition in practice even though the standard does not classify it as one.
What you are confirming the controls against also has a name. The design and operating- effectiveness confirmations are made against the applicable trust services criteria in TSP section 100, the 2017 criteria with revised points of focus (2022). Security — the common criteria, CC1 through CC9 — is always in scope; Availability, Processing Integrity, Confidentiality and Privacy are elected. An assertion that names a category whose criteria never appear in the Section 4 test matrix is asserting something that was not examined.
One precision point, because the shorthand travels badly. People say the auditor opines “on your assertion”. AT-C 205 .67 permits reporting on a written assertion or directly on the subject matter, and requires the latter whenever the opinion is modified for a material misstatement — even where the assertion acknowledges it. SOC 2 opinions are worded on the subject matter: Section 1 opines that the description presents the system, that controls were suitably designed, and that they operated effectively. Your assertion anchors the examination; the opinion reaches the same propositions independently.
The standards underneath move without disturbing this. SSAE No. 21 split the old examination section into assertion-based (AT-C 205) and direct (AT-C 206) engagements; SOC 1 and SOC 2 stayed assertion-based. SSAE No. 23 aligns the attestation standards with the AICPA’s quality management standards for engagements beginning on or after 15 December 2025 — changing how firms run engagements, not what management asserts. See SSAE 18 vs SSAE 21.
The other document
The letter you sign that nobody sees
The assertion has a private twin. AT-C 205 .51 requires written representations from the responsible party in a letter to the practitioner. It is never published and it is broader: it includes the assertion itself, and adds that all relevant matters are reflected in the evaluation; that everything known to contradict it — including regulator communications received between the end of the asserted period and the report date — has been disclosed; that you accept responsibility for the subject matter, the assertion and the choice of criteria; that known control deficiencies and any actual, suspected or alleged fraud or noncompliance have been disclosed; and that you provided all relevant information and access.
Paragraph .55 requires those representations to be dated as of the report date and to address the periods the opinion covers. Because they already include an assertion, a separate one is unnecessary unless circumstances call for it — in SOC 2 they always do, since it is published as Section 2, so you sign twice and the two must agree. Where representations are not provided, .56 requires the practitioner to discuss the matter, reassess the reliability of the representations and of evidence generally, and determine the possible effect on the opinion; if sufficient appropriate evidence cannot be obtained, .48 makes it a scope limitation. This letter is where late-breaking bad news gets locked down.
Signature
Who signs, and what the signature means
No AICPA requirement names a job title. The closest anchor is AT-C 205’s application guidance: the person from whom written representations are requested is ordinarily a member of senior management or those charged with governance. In practice that is a CEO, CTO, CISO, COO or CFO, and the test has two limbs — authority to bind the entity, and enough knowledge of the system to have a reasonable basis. A signatory with the first and not the second is a governance problem; with the second and not the first, a legal one.
The signature does not mean you personally verified every control; the assertion is made to the best of management’s knowledge and belief, resting on control ownership, monitoring and review. It does mean “the auditor said so” is unavailable afterwards, because on these propositions the auditor did not say it first. Where the assertion later matters contractually, ask your counsel; this page is an explainer, not legal advice.
One objection deserves a direct answer. An officer who joined mid-period often argues they cannot assert for months they were not present for. The guidance rejects that: not having been in place does not diminish the current responsible party’s responsibility for the subject matter as a whole, and the requirement to request an assertion covering the entire relevant period still applies. What changes is the work needed to have a basis — predecessor records, monitoring output, and a look back before signing.
Timing
When it lands on your desk
First-time signers usually meet the assertion twice: once as draft wording nobody reads, and once as a signature request on the day the report is due. The elapsed times below are market practice and vary by firm and scope — but the sequence does not.
Kickoff
Before or early in the period
The CPA firm issues draft assertion wording with the scope memo. This is the moment for the signing officer to read the three confirmations, not November. Every boundary decision — entity, system, categories, carve-out or inclusive — is cheap to change here and expensive later.
Period end
Day 0
Nothing after this date is asserted. Populations close; the export that defines each population should be taken now, with its metadata, rather than reconstructed in fieldwork.
Fieldwork
Typically 2–6 weeks
Populations are agreed, samples drawn, exceptions raised. Where an exception is going to force a modification, that becomes clear here — which is when assertion wording gets revisited.
Draft report to management
End of fieldwork
Section 1, 3 and 4 arrive together. Read the assertion against the opinion at this point: entity, system, period, categories, subservice method.
Management review
Typically 5–10 business days
Description corrections land here. A correction to Section 3 almost always implies a re-read of the assertion, because the assertion says the description meets the criteria.
Signature
Report date
Assertion and representation letter are signed the same day, carrying the report date. AT-C 205 .55 fixes that date for the representations, and firms align the assertion to it.
Issue
Same day
The firm cannot date and release the report before the signed documents are in hand. The assertion signature is the last gate before issue, and a common cause of a slipped issue date.
Worked example
One period, one exception, three documents
An illustration: a six-month Type 2 over Security and Confidentiality, observation period 1 April to 30 September 2026, fieldwork in October, report dated 12 November 2026.
1 Apr – 30 Sep 2026
The described control
Section 3 states every production change is approved by a second engineer before deployment. The control is mapped to CC8.1, the change-management criterion. The agreed population is 312 change tickets.
11 – 14 Jun 2026
What happened
During an outage, four changes deploy under an emergency path — approved verbally, ticketed on 17 June, described nowhere. Because they were ticketed, they sit inside the 312.
28 Oct 2026
The auditor samples
Twenty-five changes are drawn from 312. One of the four emergency deployments falls in the sample. Reconciling the population against the CI deployment log — ticket timestamps postdating deployment timestamps — surfaces the other three. The exception is reported against CC8.1 in Section 4.
29 Oct 2026
Two problems, not one
A description problem — Section 3 omitted a path that genuinely operated. And an operating-effectiveness problem — approval did not precede deployment four times.
3 Nov 2026
The description is corrected
Section 3 now describes the emergency path and the retrospective-approval rule, repairing the first confirmation.
12 Nov 2026
The assertion is modified
Management excepts the four changes from the operating-effectiveness confirmation, in the wording shown above; the auditor qualifies on the same matter. Assertion and representation letter are signed by the CTO that day, carrying the report date.
The alternative was worse: sign an unmodified assertion while Section 4 records two tested exceptions and Section 1 carries a qualification. Section 2 would contradict Section 4 inside one PDF, and any reviewer reading both sees it in a minute.
Evidence
What the CPA firm actually asks for
Requests fall into three buckets: evidence you are entitled to make the claim, evidence the description is accurate, and evidence the controls did what it says. The first two are where assertions come unstuck.
| Request | A clean artefact | What gets rejected |
|---|---|---|
| The signed assertion | Letterhead, exact registered entity name, dated the day of the auditor’s report. | Undated; an entity name a word off from the opinion; no printed name or title. |
| Signing authority | Board resolution, delegation-of-authority matrix, or officer appointment. | Signed by a compliance manager, an external consultant, or the platform administrator. |
| Representation letter | Letter covering the matters in AT-C 205 .51, dated as of the report date. | Dated before fieldwork closed; representations contradicting evidence in the file. |
| Subservice population (CC9.2) | Every subservice organisation used in the period, contracts, the carve-out or inclusive decision, their SOC reports. | A list omitting a vendor visible in your own architecture diagram. |
| Changes during the period (CC8.1) | Full change export showing query parameters, date range, record count and who generated it. | A screenshot with the filter cropped out; a count that will not reconcile. |
| Incidents during the period | The incident register, including system-generated evidence behind a nil return. | “We had no incidents,” said verbally or by email. |
| Joiners and leavers (CC6.1–CC6.3) | HR export with hire and termination dates, reconciled to the access-review population. | A hand-kept spreadsheet, or leaver dates that disagree with the identity provider. |
| The CUEC list | Each CUEC named in the description, with the document communicating it to customers. | CUECs from a template that no contract or onboarding material mentions. |
Behind nearly every rejection sits one rule: AT-C 205 .36 requires the practitioner, when using information produced by the entity, to evaluate whether it is sufficiently reliable — including obtaining evidence about its accuracy and completeness. That is why a cropped screenshot fails where the same data exported with visible filter criteria, a record count and a generation timestamp passes. Population comes first: until the firm agrees your 312 changes are all the changes, nothing sampled from them proves anything.
Defining the population
“Population comes first” is easy to say and rarely specified. Using the change control from the worked example — approval before deployment, mapped to CC8.1 — here is what agreeing a population actually involves before anyone draws a sample.
Choose the system of record, and say why
The population is drawn from the change-management queue in the ticketing system, not from the deployment log — because the approval field the control depends on exists only on the ticket. The deployment log is the completeness check, not the population itself. Naming the wrong system of record is the most common way a population fails before a single item is tested.
State the date boundary, with a timezone
Every change whose production deployment timestamp falls between 1 April 2026 00:00 and 30 September 2026 23:59 UTC. A change opened on 28 March and deployed on 2 April is in. A change approved on 29 September and deployed on 3 October is out, and belongs to the next period. Boundary rules stated after the sample is drawn look like they were chosen to suit the result.
Reconcile to something independent
312 change tickets reconciled against 318 production deployments in the CI pipeline log and 340 pull requests merged to the release branch. The six-deployment variance resolves to four rollbacks of changes already counted and two infrastructure-only pipeline runs carrying no ticket. The variance is documented and explained, not rounded away — and this reconciliation is exactly what surfaces changes deployed before they were ticketed.
Supply export metadata, not screenshots
The query text, the filters visible on the face of the export, the record count, who generated it and when. AT-C 205 .36 requires the practitioner to obtain evidence about accuracy and completeness of information produced by the entity, and a cropped screenshot supplies neither. Expect the same export to be re-run at issue date to confirm nothing moved underneath it.
Agree it in writing before a sample is drawn
The control owner and the engagement manager sign off the population — count, source, boundary, reconciliation — before selection. Redrawing a population after an exception appears restarts the test and raises a question the file will carry.
This is not sampling pedantry, and it ties straight back to what you signed. The third confirmation says the controls operated effectively throughout the period. If the population is incomplete, a clean sample result says nothing about the items that were never in scope to be selected — so the confirmation is unsupportable no matter how well the sample tested. That is why firms agree populations before samples, and why the reconciliation, not the sample, is where most exceptions are actually found.
Control frequency
Population over 12 months (business days where applicable)
Typical sample size
Annual
1 occurrence
1
Quarterly
4 occurrences
2
Monthly
12 occurrences
2–4
Weekly
52 occurrences
5–9
Daily
~250 occurrences
15–40 (25 is common)
Many times per day
Hundreds to thousands
25–60
Market practice, not a rule. The AICPA publishes no sample-size table for SOC 2; these ranges reflect firm methodologies adapted from attribute-sampling guidance and move with assessed risk. A shorter observation period shrinks the population and, with it, the expected sample — the six-month example above runs against roughly half the annual counts shown here. Sizes also move with the length of the observation period. Ask your firm for its expected sizes at kickoff.
Before an officer signs
Twelve checks that take ten minutes
Almost every corrected SOC 2 report we see was corrected for something on this list. Run it against the draft assertion with Sections 1, 3 and 4 open alongside.
| Check | What a failure looks like |
|---|---|
| 01Registered entity name matches Section 1 character for character | “Inc.” in the assertion, “Incorporated” in the opinion; a trading name where the registered name belongs. |
| 02System name matches Section 3 | The assertion names the commercial product; Section 3 describes a platform under a different internal name. |
| 03Period start and end match the opinion exactly | The assertion says “throughout the period”; the opinion says “as of” a date. One of the two is wrong. |
| 04Trust services categories match Section 1 and Section 4 | Confidentiality asserted, but no C-series criteria appear in the Section 4 test matrix. |
| 05Carve-out or inclusive method stated, and consistent | The assertion states the description omits the subservice organisation’s controls, and Section 3 describes them anyway. |
| 06Every CUEC named appears in Section 3 and in a customer-facing document | Template CUECs that no contract, onboarding pack or shared-responsibility page mentions. |
| 07Assertion date equals the auditor’s report date | Signed at fieldwork close, weeks before the report — covering work the signatory had not seen. |
| 08Exception language matches the Section 4 exceptions word for word | The assertion excepts three items; Section 4 records four. The gap is the first thing a reviewer finds. |
| 09The word “certification” appears nowhere | “We certify …” in a document that certifies nothing. SOC 2 is an attestation; no certificate exists. |
| 10Signing authority is evidenced | No board resolution, delegation-of-authority matrix or officer appointment covering the signer. |
| 11Assertion and representation letter do not contradict each other | A clean assertion alongside a representation letter disclosing a control deficiency in the same period. |
| 12Subsequent events through the report date have been disclosed | An October incident, in a period ending 30 September, mentioned to nobody. It sits outside the period and inside your representations. |
Checks 1 to 5 are boundary checks and account for most corrected reports. Checks 7, 8 and 11 are consistency checks between documents that different people drafted at different times, which is exactly why they diverge.
Where this gets contested
The awkward cases
Two legal entities, one product
The assertion names one service organisation. If customers contract with a different group entity, the report does not reach that contract — a boundary decision, not a signature one.
The inclusive method
A subservice organisation presented inclusively provides its own signed assertion and its own representation letter, and its management is a responsible party in its own right. The AICPA guide illustrates the two assertions presented together in Section 2. Reluctance to sign anything at all is why most engagements fall back to carve-out.
An assertion inherited from a template
Prior-year files carry forward last year’s categories, period or subservice method. The description gets reviewed because it is long; the assertion is waved through because it is short.
A gap between consecutive observation periods
A period ending 30 September 2026 followed by one starting 1 January 2027 leaves three months covered by no assertion and no opinion. A bridge letter does not reach them either — it is management’s own unexamined statement about the gap, not an extension of the asserted period. The fix is a contiguous next period, decided before the gap opens. bridge letters.
A trust services category added mid-cycle
Adding Availability in month four of a six-month period does not make it assertable for the period. The assertion can only reach that category from the date its controls were in place and operating, which in practice means the category waits for the next period rather than being asserted for part of this one. Asserting a full period for controls that started in July is a misstatement. choosing categories.
Events between period end and report date
A breach on 20 October in a period ending 30 September sits outside the period and squarely inside your representation obligations, which run to the report date under AT-C 205 .55.
The signing officer resigns before issue
The CTO who ran the period leaves in October; the report is dated November. The successor signs. AT-C 205 .A9 addresses this directly: not having been in place during some or all of the period does not diminish the current responsible party’s responsibility for the subject matter as a whole, and the requirement to request an assertion covering the entire period still applies. What changes is the work needed to have a basis — predecessor records, monitoring output, and a deliberate look back before signing.
The Statement of Applicability is not an assertion
ISO 27001’s SoA is a scoping and justification record — which Annex A controls apply, which are excluded and why — reviewed by a certification body against a management-system standard. It makes no confirmation about whether controls operated effectively over a period, and it carries no CPA opinion. Buyers who ask for “your assertion” after reading an ISO certificate are usually asking for the SoA, or for something that does not exist. ISO 27001.
A SOC 3 carries an assertion too
A SOC 3 includes management’s assertion, the auditor’s opinion and an abbreviated system description — but no detailed description and no Section 4 test results. The assertion is therefore the only substantive management statement a general-use reader sees, which is why its boundary wording carries more weight there than in a SOC 2, not less. SOC 3.
From the buyer’s side
What a security reviewer pushes back on
“Section 2 is boilerplate — we skip it.”
Its standardisation is why deviation is informative. Four fields carry information: legal entity, system name, period, categories. Two minutes there catches boundary problems Section 4 never will.
“Your assertion is clean but the opinion is qualified.”
Management asserted without exception and the auditor disagreed. Not automatically bad faith — materiality judgements differ — but worth asking about directly.
“The complementary-controls conditional is a get-out.”
It states a dependency, and the identical conditional sits in the auditor’s opinion. What it tells you is that the CUEC list is load-bearing.
“We want your auditor to make this statement, not you.”
Not how attestation works. The auditor must be independent of the subject matter; one who authored the assertion could not examine it. Section 1 is their statement.
“Can your compliance consultant sign it instead?”
No. AT-C 205 .A12 is explicit: whatever procedures the practitioner performs, the responsible party must accept responsibility for its assertion, and an assertion based solely on the practitioner’s procedures is not a reasonable basis. The same reasoning covers a readiness firm or a compliance platform.
“Send us an assertion covering the last four months.”
What exists for that gap is a bridge letter, carrying no auditor procedures. Beyond a quarter or so, the honest answer is the date the next report lands.
The two-minute check
Reading Section 1 against Section 2
Two parties, the same three propositions — a free consistency check before anything else in the report anatomy.
Section 2 assertion
Section 1 opinion
What the pairing tells you
Unmodified
Unmodified
The ordinary case. Check entity, system, period, categories and subservice method match Section 1 word for word.
Modified — management excepts a matter
Qualified, same matter
Management self-identified. What a control environment that reports its own failures looks like on the page.
Unmodified
Qualified or adverse
Management asserted without exception and the auditor disagreed. The one pairing that earns a direct question.
Unmodified
Disclaimer of opinion
The auditor could not obtain sufficient evidence. The assertion stands unexamined — treat the report as unassured.
Period, entity or categories differ from the opinion
Any
A drafting failure on the point in dispute — the boundary. Ask for a corrected report.
The assertion tells you what the organisation would put its name to; the opinion and its exceptions tell you what an independent firm concluded about the same ground.
The SOC 2 Management Assertion — Common Questions
Who signs it, what it commits you to, and how it relates to the rest of the report.
What is the management assertion in a SOC 2 report?
Management’s written statement, published as Section 2, confirming that the description of the system is presented in accordance with the description criteria in DC section 200, that the controls stated in it were suitably designed to achieve the service commitments and system requirements based on the applicable trust services criteria, and — in a Type 2 — that they operated effectively throughout the stated period. It names the entity, system, period and categories in scope, and is signed and dated.
Who signs the SOC 2 management assertion?
An authorised officer of the service organisation. No AICPA rule names a title; AT-C 205’s application guidance says the person providing written representations is ordinarily a member of senior management or those charged with governance. In practice that means a CEO, CTO, CISO, COO or CFO. The test has two parts: authority to bind the entity, and enough knowledge of the system to have a reasonable basis. Firms commonly ask for evidence of that authority.
Is the assertion the same as the management representation letter?
No, though they overlap and you sign both. The assertion is published as Section 2 and covers the description, the suitability of design and — in a Type 2 — operating effectiveness over the period. The representation letter goes privately to the CPA firm and is never published. AT-C 205 .51 makes it broader: it repeats the assertion and adds that all relevant matters are reflected in the evaluation; that everything known to contradict it has been disclosed, including communications from regulators received between the end of the asserted period and the report date; that you accept responsibility for the subject matter and for selecting the criteria; that known control deficiencies and any actual, suspected or alleged fraud or noncompliance have been disclosed; and that you provided all relevant information and access. Paragraph .55 dates it as of the report date. The two documents must not contradict each other.
Can our auditor or consultant write the assertion for us?
They can help draft the language; they cannot be the basis for it. AT-C 205’s application guidance states that whatever procedures the practitioner performs, the responsible party must accept responsibility for its assertion and the subject matter, and that an assertion based solely on the practitioner’s procedures is not a reasonable basis. The same reasoning covers a readiness firm or a compliance platform. Satisfy yourself every clause is true before an officer signs.
What happens if management refuses to provide the assertion?
The examination cannot produce an opinion. AT-C 205 .10 requires the practitioner to request a written assertion from the responsible party. Where the engaging party is also the responsible party — the ordinary SOC 2 arrangement — .84 requires the practitioner to withdraw from the engagement where withdrawal is possible under applicable law or regulation, and .85 requires a disclaimer of opinion where it is not. Where a different party engaged the firm, .86 lets the practitioner report on the subject matter but requires the refusal to be disclosed in the report and the report’s use restricted to the engaging party. In practice, refusal almost never reflects bad faith. It is usually an assertion nobody could honestly sign because the description overclaims what the controls do — and correcting the description, not renegotiating the assertion, is what resolves it.
How does the assertion differ between a Type 1 and a Type 2?
A Type 1 assertion speaks as of a single date and makes two confirmations: the description presents the system designed and implemented at that date, and the controls were suitably designed. A Type 2 speaks throughout a stated period and adds a third — that the controls operated effectively across it. That third confirmation depends on complete populations for the whole period, which is why organisations moving to a Type 2 find record-keeping, not controls, is the constraint.
What if we cannot assert that a control operated effectively?
You do not assert it. Two routes exist. First, check whether it is really a description problem — if the description overstates what the control does, correcting the description is the fix rather than a qualification. Second, where a control genuinely failed, management excepts the matter in its own assertion and describes it, and the auditor modifies the opinion consistently. What is never available is an unmodified assertion that Section 4 contradicts.
Does the auditor’s opinion cover the assertion itself?
Not directly, in modern practice. AT-C 205 .67 permits a practitioner to report on a written assertion or directly on the subject matter, and requires reporting directly on the subject matter whenever the opinion is modified because of a material misstatement — even where the assertion itself acknowledges that misstatement. SOC 2 opinions are worded on the subject matter: that the description presents the system in accordance with the description criteria, that the controls were suitably designed, and, in a Type 2, that they operated effectively throughout the period. The assertion is therefore the precondition and anchor of the examination rather than the object of the opinion. The practical consequence for a reader is that a clean assertion earns nothing on its own — the two parties reach the same three propositions independently, and it is the pairing that carries information.
What date should the assertion carry, and can it be signed electronically?
The same date as the auditor’s report, and never earlier. AT-C 205 .55 fixes the report date for the written representations, and firms carry that same date onto the published assertion so the two documents agree; an assertion dated at fieldwork close would cover work the signatory had not yet seen. On mechanics, company letterhead and a printed name and job title alongside the signature are market practice rather than AICPA requirements, and notarisation is not required. Most firms accept electronic signatures, subject to their own evidence and retention policies. Confirm the acceptable format at kickoff rather than on issue day — a signature-format objection discovered on the report date is a common and entirely avoidable cause of a slipped issue.
Does the assertion cover a subsidiary or product we acquired mid-period?
Only if the acquired entity and its system sit inside the boundary the assertion names. Three things have to line up: Section 3 must describe the acquired system, the populations behind every control must include it from the acquisition date forward, and the legal entity named in the assertion must be the one your customers actually contract with. If the acquisition closed in month four of a six-month period, you cannot assert that its controls operated throughout the period, because they were not within your system throughout it. The usual resolutions are to redraw the boundary so the acquired system sits outside this cycle, or to reset the period so it begins after the acquisition closed. Asserting across it is a misstatement.
Related reading: how to read a SOC 2 report, scope and system boundary, CUECs and CSOCs, carve-out vs inclusive method, bridge letters, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
Anatomy of a SOC 2 Report
An interactive, annotated Type II example — click every element to see what it means.
Read moreWriting the System Description (Section 3)
The omit-or-distort standard, writing at the right altitude, and an honest CUEC section.
Read moreSOC 2 Opinions & Exceptions
Unmodified, qualified, adverse, disclaimer — and why exceptions are not qualification.
Read moreHow to Read a SOC 2 Report
All five sections annotated, an 8-step reviewer checklist, and the red flags.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreSOC 2 Auditor Independence
Why the firm that designs your controls cannot attest to them, and where the line actually falls.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours