You wrote the thing they graded

A lesson from SOC 2 Type 2: What the Auditor Tests. 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 denominator is the vendor's template 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 that holds the request, 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.

  Points of focus are not a hidden requirements list either. They 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. You have a control statement and the record it produces: a quarterly access review is not a control until it names the completion record in your identity provider and its reviewed-on date field.

  A common failure: in week three of fieldwork a team complains that "the auditor changed the requirements on us" and blames the audit firm, when the requirement was a sentence your platform imported from a template that nobody who runs the system had ever read. The least expensive hour of the whole engagement is 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 you can ask it by email. The firm's answer must not go into your description as a sentence nobody on your side decided on.

  Between the recommendation and the description there is a decision, the decision is management's, and a readiness engagement is structured to keep that decision with management: 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 belief that the firm may not recommend anything has a real source, which is why experience does not correct 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. If your team avoids asking its auditor for advice, that habit probably came from one auditor who declined once.

  A common failure: eight weeks of readiness work produce a gap list and no control statements, nobody files a complaint 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 firm may not write the control statement, and the control statement is what the firm will 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 that most control matrices are never mapped to. 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. That is three opinions against two documents.

  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 with points of focus revised in 2022. The report's own opening paragraph names both in one sentence: 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 as written. No control failed. The description said something the criteria for descriptions do not let it say, or left out something they require, and the report carries a qualification that no remediation sprint can fix, because there is nothing to remediate.

  A common failure: in week three of fieldwork the auditor sends two pages of comments on Section III to whoever assembled the document, usually somebody who joined last quarter and had the template. Every control Section III describes ran. Whoever owns Section III should be reading the description criteria before the next audit period starts, 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 in the vendor's report is somebody else's problem.

  That section falls short of the description criteria, and Northbeam's auditor should have raised it. It said in one plain sentence that some of those controls are Northbeam's own and the rest are yours, and never marked which row was whose, so you had to work out from each sentence who performs the control. The rows that were yours and that you did not claim are still controls, and now nobody owns them.

  The rules for both kinds of handed-back control, user entity controls and subservice organization controls, are in the description criteria, not in the common criteria. DC6 covers complementary user entity controls (CUECs): 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. An accurate description says whose control each row is.

  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. No auditor in that examination tested them. That untested boundary 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.

  The CUEC rule applies 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 failure in your assurance, not the customer's. A report can legitimately carry none; an empty list is a design choice.

  A common failure: a customer's questionnaire asks who rotates the API credentials, somebody reading page 3 of a report whose page 61 says otherwise answers "the vendor", and nothing is filed because nobody disagreed. Assign every CUEC row you accept to a named person 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 having an owner.

• 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.

  Try to name the date your last report stops being usable. No such date exists. 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 involve twelve months, and neither one causes the other. 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 buyers' twelve-month convention is the reason bridge letters exist.

  A bridge letter 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 the letter carries no assurance, and no AICPA guidance covers it. A common failure: a prospect's security reviewer asks for the current certificate, receives a letter on your letterhead, and the deal slows while somebody looks for a countersignature that never existed.

  One thing changed recently, and the change applies to the audit firms rather than to SOC 2 mechanics. The AICPA Peer Review Board issued a reviewer alert in May 2026 on SOC engagement risk, aimed at 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 now creates risk rather than saving time, and the profession is checking.