The Third-Party Service Security Standard: Clear, Conditional, or Block

A security review that ends in an unweighted questionnaire is not a decision. This standard is the definition of done for one narrow job: deciding whether a third-party service or API clears your security bar before you connect it to production systems or let it touch customer data. It is written for engineering managers, technical founders, and reviewers who must reach a defensible ruling from evidence they can gather without waiting on a vendor's sales team. Follow it and two reviewers grading the same service arrive at the same verdict: Clear, Conditional, or Block.

Other guides cover the end-to-end vetting process and lock-in scoring. This one does not. It states a pass or fail security bar and the checklist to verify it, so a review produces a consistent verdict instead of a folder of PDFs.

What "Clear, Conditional, or Block" means

The three verdicts are a definition of done, not a mood. Clear means every gate passed on obtainable evidence and the service may connect. Conditional means one or more gates are met only partially and named compensating conditions must hold before or during connection. Block means at least one gate failed in a way that touches your data, and no condition fixes it without new evidence from the vendor.

The point of naming three verdicts is repeatability. If a reviewer can slide a case up or down at will, the standard has failed. Each verdict must be pinned to the specific gate that set the ceiling. A service is not "mostly fine"; it is Conditional because its SOC 2 scope covers Security but not Confidentiality, and it may become Clear when the vendor produces a report with Confidentiality in scope.

The gates, in the order this standard applies them, are: freshness of the attestation, opinion and exceptions, Trust Services Criteria scope, access blast radius, and framework coverage. Any single gate can force a Block. The lowest gate sets the verdict. A vendor with a spotless SOC 2 and an over-broad, non-revocable OAuth grant is Block on blast radius, no matter how clean the report reads.

The evidence you can collect without vendor cooperation

Start with what you can gather before anyone at the vendor picks up the phone, because a review that stalls waiting on sales is a review that never ends. Several artifacts are public and machine-collectable, and each proves something narrow. The value of this standard is that it grades from obtainable evidence first and treats vendor-supplied documents as a second, dependent layer.

Know exactly what each artifact proves, and what it looks like when it lies. A security.txt file, defined by RFC 9116, resides at /.well-known/security.txt on a public webserver, served over HTTPS as plain text with no authentication. It proves a vulnerability disclosure channel exists. It proves nothing about control quality, and its presence taken as evidence of a mature program is a false positive: the file can exist with no real triage behind it.

A public CSA STAR listing proves that either a self-assessment or an audited attestation exists. The listing shows the organisation name, the level, the assessment type, the date, and the status. For Level 1 the completed CAIQ questionnaire is downloadable. For Level 2 the listing confirms a certification or attestation but does not publish the full audit report. The trap here is level confusion: a Level 1 self-assessment credited as if it were audited third-party assurance.

Trust pages, subprocessor lists, status-page history, and breach disclosures are all collectable. The specific "what each proves" mapping for these is not formalised in a single authoritative source, so treat their evidentiary weight as not publicly established and reason from first principles: a subprocessor list proves who else touches the data, a status page proves an incident-communication habit, a breach disclosure proves how the vendor behaved under fire. None proves control effectiveness on its own.

Reading the SOC 2 report: freshness, opinion, and scope

Three things in a SOC 2 Type II report decide most verdicts: how old it is, what the auditor's opinion says, and what the criteria scope actually covers. Reviewers who skip to the logo miss all three.

Freshness

There is no formal expiry stamped on a SOC 2 report. The market convention treats a report as current for 12 months from the end of the audit period, after which reviewers and GRC platforms flag it as outdated. Be honest about where that number comes from: the AICPA restricts use of the official SOC 2 logo to 12 months after the issuance date, and the whole freshness convention rests on that marketing restriction, not an audit rule. For sensitive or high-value engagements the bar is tighter, with clients and bank partners requiring a period end within the last 6 to 9 months.

The two dates are not the same. Report issuance typically lags the period end by 4 to 10 weeks. A report can sit under 12 months from issuance while covering a period that ended 15 months ago. Grade on the period end date. A bridge letter can cover the gap between the period end and today, but it is management-issued, not auditor-issued, so it is a statement of no material change, not new assurance.

Opinion and exceptions

SOC 2 opinions are unqualified, qualified, adverse, or disclaimer. They are not pass or fail, and you cannot count findings. If a single control within a criterion such as CC6.1 fails, that is an exception and the other controls in that criterion still hold. If every control within a criterion fails, it stops being an exception and becomes a qualification, which the auditor names directly in the opinion.

That distinction is already codified in how opinions are written, and it is what lets two reviewers reach the same verdict. A qualified opinion names the matter and confines it to specific criteria, so you can carve out whether it touches your data. An adverse opinion offers no such boundary, because the failures were pervasive enough that the system as described did not achieve its criteria. Read Section IV, the description of tests and results, against Section I, the scope. Map each exception to isolated-remediated or systemic before you weigh it.

Scope

Security is the silent failure. Only the Security category, the nine Common Criteria CC1 through CC9, is mandatory in every SOC 2 audit. Availability, Processing Integrity, Confidentiality, and Privacy are optional, selected based on the commitments in customer contracts and SLAs, under the 2017 Trust Services Criteria with Revised Points of Focus 2022. A report scoped to Security alone proves nothing about uptime, data confidentiality, or privacy handling.

If your integration handles confidential customer data, confirm Confidentiality is in scope. If your product depends on the vendor's uptime, confirm Availability. The gate is reading the scope page, not the opinion. Crediting a Security-only report as if it proved confidentiality is the most common way a genuine report leads to a wrong verdict.

Grading access blast radius over the badge

Judge the integration by effective privilege, not by whether a user clicked "Allow." A clean certification does not offset an over-broad, non-revocable grant. This gate is decisive: current guidance is to weigh OAuth scopes, token duration, and revocation path above the badge, because those determine what an attacker gets if the vendor is compromised.

The evidence for treating blast radius as a first-class gate is concrete. The Salesloft-Drift OAuth incident propagated to more than 700 organizations because interconnected scopes let tokens ride between apps. A certified vendor requesting full-mailbox or admin scope with no revocation path is a bigger risk than an uncertified vendor with read-only, short-lived access.

There is a binding constraint before you can even run this gate: 85% of organisations report lacking full visibility into the third-party vendors connected via OAuth apps. If you cannot enumerate the grants, you cannot grade them, and the gate fails before it starts. So step one of this gate is inventory. Enumerate the requested scopes or IAM permissions, record the token time-to-live, and confirm a revocation path exists and that you know how to trigger it.

Mapping to named frameworks

Anchor the review to established control frameworks so the ruling is defensible outside your team. Three matter here, and each contributes a checkable requirement rather than a philosophy.

NIST SP 800-53 SA-9 mandates three actions: specify and document in contracts the security and privacy controls the external provider must implement, define who oversees the external service, and establish processes to monitor compliance on an ongoing basis. Responsibility for managing the risk stays with the authorizing official, which in your case is whoever owns the connection. SA-9 applies across the LOW, MODERATE, HIGH, and PRIVACY baselines, so it scales to how sensitive the connection is.

ISO 27001:2022 gives you the supplier framework in Annex A controls 5.19 through 5.22: information security in supplier relationships, security requirements in agreements, ICT supply-chain security, and ongoing monitoring and change management. A.5.21 is new in the 2022 revision and requires managing risk in the ICT supply chain including the security practices of suppliers' own suppliers. That closes the sub-processor blind spot, where the reviewer grades the vendor but not the parties one hop away who also touch the data.

CSA STAR gives you a public signal. Level 1 is a free self-assessment via the CAIQ, a standardized questionnaire; CAIQ v4 contains more than 140 questions across the Cloud Controls Matrix's 16 domains. Level 2 requires a third-party audit conducted by a CSA-certified assessor. Read the level before you credit the listing.

Specialist review capacity is scarce, and that shapes how this standard should be used. In Refolk's index of professional profiles, only 174 US and 63 UK people hold dedicated third-party or vendor-risk analyst-to-manager titles, and they cluster in banks including Wells Fargo, Bank of America, Citi, and HSBC. Most engineering teams will never have one on staff, which is precisely why the bar has to be self-serve and gradeable from public evidence.

The wider skill pool is larger: Refolk's index shows roughly 10,240 US professionals whose profiles pair Vendor Risk Management with SOC 2 skills, with top employers including Airbyte and health-care analytics firms. But the dedicated-title population is tiny, so treat this standard as the thing that lets a generalist engineer produce a specialist-grade ruling. If you need to find and staff that review, Refolk lets you ask for those people in plain English and get them back.

The procedure

Run the gates in order. Earlier gates are cheaper to check and can force a Block before you spend time on later ones. The whole review is roughly a day of focused work for a service touching production data.

Record the verdict in a fixed shape so any reader can reconstruct the reasoning. Use the same skeleton every time, which is what makes two rulings comparable.

Service:
Data classes touched:
Production access (Y/N):
Report type / period end / age:
Opinion + material exceptions:
TSC in scope vs needed:
Effective privilege (scopes / token TTL / revocation):
Framework coverage (SA-9 / ISO A.5.19-22):
Verdict: Clear | Conditional | Block
Ceiling gate (the one that set the verdict):
Conditions (if Conditional):
Reviewer 1 / Reviewer 2:

How this goes wrong

Most wrong verdicts come from a small set of predictable errors, not from missing evidence. Each has a tell and a check. This is the part of the standard worth rereading before every review.

Two more deserve their own weight. The sub-processor blind spot puts the risk one hop away: you grade the vendor and miss the parties it depends on. ISO A.5.21 exists precisely to force supply-chain and sub-processor visibility, so use the vendor's subprocessor list as the input to a second, shorter pass. And bridge-letter overreliance treats a gap letter as equal to an audit. A bridge letter is management-issued, not auditor-issued, so it asserts no material change over unaudited months; accept it only to cover the 4-to-10-week issuance lag, never a longer gap.

The lowest gate sets the verdict, and a badge never buys back an over-broad, non-revocable grant.

Also treat security.txt for exactly what it is. Its presence advertises a disclosure channel under RFC 9116 and nothing more. It is a weak positive, not proof of a mature program, and reading it as maturity is its own false positive.

Before you call the job done

Run this checklist before recording any verdict. If any item is unchecked, the review is not finished, and a Conditional or Block that skips items is not defensible.

Keeping the standard current

A standard decays when its inputs move and nobody notices. Two mechanisms will shift under you, so re-check them rather than memorising a value. The freshness convention is anchored to an AICPA logo-use policy; if that policy changes, the 12-month figure moves with it, so confirm the logo-use window when you set team policy. The ISO 27001:2022 controls, including the new A.5.21 sub-processor requirement, carried a transition deadline that has now passed, so treat a report still mapped to the older revision as a freshness flag in its own right.

Finally, adopt this as written team policy, not a personal habit. The value is that two reviewers grade the same case the same way, and that only holds when the gates, their order, and the verdict record are shared. When capacity allows, pull a named specialist in to pressure-test your Conditional rulings; the pool exists, it is just small and bank-concentrated, and a generalist running this standard is the default case it was built for.