You wrote the thing they graded

A lesson from Surviving the SOC 2 Audit. Play it above, or read it through below.

• The AICPA published criteria. You wrote the controls.

  The common read: The AICPA publishes the list of SOC 2 controls, so the percentage on my readiness meter is my distance from a requirement somebody outside my company set.

  The vendor's library. The AICPA publishes criteria, attaches no controls to them, and the denominator on that meter was written by a product team who have never seen your infrastructure. A criterion states what has to be achieved. It does not name the approver, the queue the request sits in, or the number of business days.

  The sentences that do name them are controls, and they are yours: management prepares the description of the system, states the controls in it, and asserts that those controls achieve the service commitments and system requirements management itself set. The firm then opines on whether the controls STATED IN THE DESCRIPTION were suitably designed and whether they operated. Read that clause the way an auditor reads it. The subject of the opinion is your sentence, and the criteria are the benchmark it is measured against.

  The other thing stuck teams wait for does not exist either. Points of focus look like a checklist under each criterion, and the trust services criteria say that use of the criteria does not require an assessment of whether each point of focus is addressed. There is no list and no mandatory sub-list. What you have is a sentence and the record it emits: a quarterly access review is not a control until it names the completion record in your identity provider and its reviewed-on date field.

  It arrives as "the auditor changed the requirements on us" in week three of fieldwork, filed against the audit firm, and the requirement was a sentence your platform imported from a template that nobody who runs the system had ever read. The cheapest hour of the whole engagement is the one where the people who operate each system read their own control statements out loud and say which artifact, which emitter and which date field answers each one.

• The firm will tell you what they expect to see. The sentence is still yours.

  The common read: Independence bars the audit firm from recommending a control, so waiting for their requirements list is the only compliant move I have.

  A recommendation, and they will make one. The Code permits the practitioner to help management make decisions and develop plans and strategies by advising the client and providing research materials and recommendations, and what impairs independence is designing, implementing or operating the control, or otherwise assuming a management responsibility. So "what would you expect to see for CC6.3" is a question with an answer, and the answer is worth an email. What cannot happen is the answer landing in your description as its own sentence.

  Between the recommendation and the description there is a decision, the decision is management's, and the whole architecture of a readiness engagement exists to keep that decision on your side of the line: it is scoped as a separate nonattest engagement, and management takes responsibility for the work and for the description in writing before it starts. The folklore has a real source, which is why experience does not dislodge it.

  Firms decline advisory work of their own accord and say so publicly, one of them stating on its readiness page that it does not provide advisory, remediation, or implementation services. That is a firm's own policy, stricter than the rule, and a team who has only ever worked with a firm like that has observed the behaviour correctly and drawn the wrong rule out of it. Everything you know about not leaning on your auditor was learned from an auditor who declined, once.

  It arrives as eight weeks of readiness that produced a gap list and no control statements, filed against nobody because nothing failed, and the description that goes to fieldwork still carries the template's sentence about an approver who left in 2024. Ask the question, take the answer, and write the sentence yourself, because the one thing the firm may not do for you is the one thing they are going to test.

• Section III is yours. It is graded against a different document.

  The common read: The trust services criteria are what a SOC 2 report is judged against, so my control matrix is the whole of what gets graded.

  Three, and the first of them is measured against a document most control matrices have never been near. The opinion says the description presents the system in accordance with the description criteria, then that the controls stated in the description were suitably designed, then that they operated effectively. Two documents, three opinions.

  The description criteria are DC section 200, the 2018 description criteria for a description of a service organization's system in a SOC 2 report, carrying revised implementation guidance from 2022, and the trust services criteria are TSP section 100, the 2017 criteria carrying revised points of focus from the same year. The report's own opening paragraph names both in one breath, examined against the criteria for a description in DC section 200 AND against the trust services criteria. Section III is that description.

  Engineering writes it, and it is graded against the first document rather than the second, which is the one every control in your matrix is mapped to. Because the three opinions are separate, the first can be qualified while every control in the other two operated exactly as written. Nothing failed. The description said something the criteria for descriptions do not let it say, or left out something they require, and the report now carries a qualification that no remediation sprint can reach, because there is nothing to remediate.

  It arrives as two pages of auditor comments on Section III in week three of fieldwork, filed against whoever assembled the document, usually somebody who joined last quarter and had the template. Every control it describes ran. Whoever owns Section III should be reading the description criteria before the next window opens, and that is a different document with a different number from the one the matrix is mapped to.

• The page never said which rows were yours. They are on your report anyway.

  The common read: The vendor's controls were tested by the vendor's own auditor, so every control on that surface is somebody else's problem.

  Northbeam did nothing wrong, and neither did its auditor. The section said in the driest sentence available that some of those controls are its own and the rest are yours, and never marked which row was whose. The ones that were yours and that you left are controls with no owner and a criterion pointing at them.

  Both halves live in the description criteria, not in the common criteria. DC6 covers complementary user entity controls: where management assumed, in designing the system, that certain controls would be implemented by user entities, the description has to state them, and it is only in accordance with the criteria if that list is complete, accurately described and relevant.

  The criterion governs what the description states, not how a page is set. DC7 covers subservice organizations, the inclusive method and the carve-out method. Under carve-out the subservice organization's controls are excluded from the auditor's testing, and the report prints that boundary in its own disclaimer. Nobody in that report tested them. It is also why a clean opinion under a carve-out is conditional: the controls were suitably designed IF the subservice organization applied the complementary controls assumed in the design.

  It runs in both directions. Inbound, a vendor's CUEC section is your work list, the most-skipped page in vendor review. Outbound, the CUEC list in your own report is a set of obligations you pushed onto customers, so it has to be true and communicated; a CUEC nobody told the customer about is a hole in your assurance, not theirs. A report can legitimately carry none; an empty list is a design choice.

  It arrives as a customer's questionnaire asking who rotates the API credentials, answered "the vendor" by somebody reading page 3 of a report whose page 61 says otherwise, and nothing is filed because nobody disagreed. Put every CUEC row you accept onto a name in your own matrix, with its artifact and its date field beside it; the CUEC rows you skip do not stop being controls, they stop being anybody's.

• Nobody signed a certificate. Management signed the bridge letter.

  The common read: My report is good for twelve months, so a bridge letter on my own letterhead carries the gap to the customer's year end.

  Put a date on the day your last report stops being usable, then read on. There is not one. There is no certifying body and no certificate: a licensed CPA firm issues a report containing an opinion on the description and the controls stated in it, and the word certificate appears nowhere in the attestation standards for SOC engagements.

  Two facts about twelve months sit next to each other with no arrow between them. The AICPA's logo licence stops twelve months after the report date, and buyers independently treat twelve months as the freshness bar. Most service organizations never register for the logo at all, which is why the licence cannot be the cause of the convention.

  The convention produces the bridge letter. It covers the interval between the report period end and the customer's year end or diligence date, typically three months or less. Management writes and signs it; the service auditor does not. Nobody performed procedures over that interval, so it carries no assurance, and no AICPA guidance covers it. It arrives as a prospect's security reviewer asking for the current certificate, answered with a letter on your letterhead, and the deal slows while somebody hunts for a countersignature that never existed.

  One thing did move recently, and it moved on the audit firms rather than on the mechanics. The AICPA Peer Review Board issued a reviewer alert in May 2026 on SOC engagement risk, naming firms that produce identical reports across different clients: identical risk assessments, control designs, sample sizes and testing procedures make an engagement nonconforming, and reviewers are told to look at several engagements, not one file.

  Structured outreach to the peer review team captains of firms performing SOC 2 work began on 1 June 2026. A report that reads like every other report from the same auditor is a liability now rather than a shortcut, sophisticated customers already reject them, and the profession is checking.