The same SOC 2 report, reviewed twice: once by hand with a spreadsheet, once with findings linked to the page they came from and a recorded decision. Step by step.
The same report, reviewed twice
A SaaS vendor sends its latest SOC 2 Type II report as part of a renewal. Two reviewers on different teams get the same PDF. Both are experienced, both read the same sections, and both reach the same conclusion: approve, with two follow-ups.
Six months later an internal auditor asks each of them the same question: why was this vendor approved, and what happened to the follow-ups? One answer takes an afternoon of searching. The other is already on the record. The difference is not the reviewer. It is the workflow.
What a SOC 2 review has to cover, whichever way you do it
A SOC 2 report is an independent service auditor's report on a service organisation's controls, measured against the AICPA Trust Services Criteria (security, plus any of availability, processing integrity, confidentiality and privacy the vendor chose to include). A Type I report looks at control design on a single date; a Type II report also tests whether the controls operated over a period. Whatever tool you use, a useful review checks the same things:
- Scope: which systems, services and locations the report covers, and whether the service you buy is one of them.
- Period: the dates the testing covers, and how far the end of that period is from today.
- Subservice organisations: which providers the vendor relies on, and whether they were carved out of the report or included in it.
- Complementary user entity controls (CUECs): the controls the vendor expects you, the customer, to operate.
- Exceptions: the tests that failed in section 4, and management's response to each.
- The opinion and the bridge letter: whether the auditor's opinion is unqualified, and what the vendor states about the gap between the end of the period and now.
Workflow 1: the PDF, the spreadsheet and the email
In the manual workflow the reviewer opens the PDF and works through it section by section. Scope and period go into a row of the vendor tracker. Subservice organisations are copied into a notes column, if there is room. The CUECs are read, and usually left for someone else to pick up. Exceptions are summarised in a sentence each, without the page number, because the page number did not seem important at the time.
The decision is made in a meeting or a message: approve, ask the vendor about exception 3, check that we actually run the access review CUEC. The tracker gets a status of "Approved". The reasoning lives in an email thread, and the follow-ups live in someone's memory.
None of this is careless. It is how most teams work, because the tools they have were built to store a status, not to keep evidence and reasoning together.
Workflow 2: findings linked to the page they came from
In the second workflow the same checks produce findings instead of notes. Each finding records what the gap is, where it was found (the document, the section and the page) and which requirement it relates to: a Trust Services Criterion, a contract clause or a policy of your own.
The reviewer still reads the report and still makes the call. The difference is that the decision is recorded on the finding: accepted, mitigated or sent back to the vendor, with a note on why and who decided. Follow-ups are findings that stay open until someone closes them, not lines in an email.
Step by step: what each workflow leaves behind
- Scope. Manual: "In scope: yes" in a tracker cell. Evidence-linked: a finding if the service you buy is missing from the system description, with the page where the scope is stated.
- Period. Manual: the end date in a column, rarely compared with today. Evidence-linked: a finding when the period ended long before the review, linked to the bridge letter request.
- Subservice organisations. Manual: a list of names in a notes field. Evidence-linked: each carved-out provider becomes a fourth-party item you can track, with the page reference.
- CUECs. Manual: read once, then forgotten. Evidence-linked: each CUEC becomes an action on your side with an owner.
- Exceptions. Manual: a one-line summary without a page number. Evidence-linked: one finding per exception, with the test, the result, management's response and the page.
- Decision. Manual: "Approved" in a dropdown, reasoning in email. Evidence-linked: the decision, the note and the name, kept on each finding.
Why the record matters more than the reading
Regulators and auditors rarely ask whether you read a SOC 2 report. They ask what you concluded and why. Under GDPR Article 28(1), a controller may only use processors that provide sufficient guarantees, and Article 28(3)(h) requires the processor to make available the information needed to demonstrate compliance. If you are in scope of DORA, Article 28 requires you to manage ICT third-party risk as part of your ICT risk management framework and to keep a register of information on your ICT contracts.
A SOC 2 report is often the main piece of evidence behind those conclusions. A review that keeps the finding, the page and the decision together is a review you can show. A review that ends in a status and an email has to be reconstructed every time someone asks.
Questions to test your own SOC 2 workflow
- Can you find, for any approved vendor, the page in its SOC 2 report that supports each open issue?
- Do you know which of your vendors' subservice organisations were carved out of their reports?
- Who on your side owns each CUEC the vendor listed, and is it actually operated?
- When a reviewer accepted an exception, is the reason written down where the next reviewer will see it?
- Do you ask for a bridge letter when the report period ended months before your review?
See the second workflow on demo data
The ProcureCortex demo at procurecortex.com/explore (self-serve: email sign-in link, no sales call) shows vendor reviews where each finding points to the document and clause it came from, labelled against frameworks such as SOC 2, ISO 27001 and GDPR, with decisions traced back to the evidence. All vendors and findings in the demo are sample data. Our earlier post, Read a SOC 2 report in this order, covers the reading sequence in more detail.
Sources
- AICPA, SOC 2: SOC for Service Organizations, Trust Services Criteria: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
- AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022): https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
- Regulation (EU) 2016/679 (GDPR), Article 28: https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Regulation (EU) 2022/2554 (DORA), Article 28: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
Get the vendor review guide
One email a month with a worked example like this one. Nothing else.