STA-03 — SSRM Guidance

Every framework that asks this

Answer STA-03 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.

Full provenance and NIST 800-53 mappings: the framework crosswalk.

What the reviewer is really checking

The reviewer is establishing whether your vendors extend or dilute the security they're buying from you. Every subprocessor that stores, processes, or can access customer data inherits some of your trust, and the buyer can't assess a party they can't see, so the first thing they test is whether you even maintain an inventory of who those parties are and what data or access each holds. Then they probe the lifecycle around it: how you vet a vendor before onboarding (security review, evidence such as their SOC 2, risk tiering by data sensitivity), how you monitor them over time rather than at signing only, and whether your security and data-protection obligations flow down to critical suppliers by contract (DPA, security addendum, breach-notification pass-through). They also look for transparency mechanics: is the subprocessor list published or available, and do customers get advance notice and a right to object before you add a new one, a standard DPA expectation. Frameworks make this a first-class domain: NIST CSF 2.0 elevated supply chain to a governance function (GV.SC), NIST SP 800-53 has the SR family, SOC 2 CC9.2 tests vendor risk management, and ISO 27001 A.5.19 to A.5.23 cover supplier relationships. The reviewer is checking the buyer's fourth-party exposure is actually governed, not assumed.

What a truthful, defensible answer contains

A defensible answer starts by confirming you maintain a subprocessor and vendor inventory and describes what it records: the vendor, the data or access involved, and a risk tier. It describes the vetting you perform before onboarding: a security review, the evidence you require (for example the vendor's SOC 2 or ISO certificate), and how sensitivity determines the depth of review. It describes ongoing monitoring, meaning periodic reassessment and watching for lapsed certifications or incidents, rather than a one-time check at signing. It states how obligations flow down to critical suppliers: that security requirements, data-protection terms, and breach-notification duties are imposed contractually through a DPA or security addendum. And it addresses transparency: whether the subprocessor list is available to customers and whether they receive advance notice and a right to object before a new subprocessor is added. Where practices differ by vendor tier, a truthful answer says so and states the threshold. It maps to the referenced control (CCM STA, NIST CSF GV.SC, SOC 2 CC9.2, ISO 27001 A.5.19–A.5.23) without overstating. The buyer wants to see a governed program with an inventory at its center, not a claim that all vendors are 'fully vetted.'

Make it traceable

Point each claim at a maintained artifact. 'We keep an inventory' resolves to the subprocessor register or the public subprocessor page, with its URL; 'we vet vendors' resolves to your third-party risk management policy and a sample completed assessment; 'obligations flow down' resolves to the standard DPA or security addendum clause you impose (§X); and 'customers get notice' resolves to the notification and right-to-object term in your DPA. If a SOC 2 report tests vendor management, cite CC9.2 and the report date. The strongest answer links the live subprocessor list rather than describing it, because a published, dated list is self-proving and stays current after the deal. Every assertion should trace to a document under change control, a register you update or a contract template you actually use, so the reviewer sees governance in force rather than a description written for this response.

Answer patterns that hold up

• Inventory first (confirm it exists and what it records) before any vetting or monitoring claim.
• Vetting described as review step, then required evidence, then risk-tiering, each concrete.
• Flow-down stated as which obligations (security, data-protection, breach-notice) are imposed and via which contract instrument (DPA/addendum §X).
• Transparency stated as list availability, then advance notice, then right to object, mapped to the DPA term.
• A tier threshold stated where vetting depth or monitoring cadence varies by vendor criticality.

Evidence that backs the answer

Red flags reviewers catch

• No subprocessor inventory, so the buyer can't see who touches their data at all.
• 'All vendors are vetted' with no tiering, no required evidence, and no monitoring after signing.
• Vendor review described as one-time at onboarding with no periodic reassessment.
• No statement that security or breach-notification obligations flow down to suppliers by contract.
• No customer notice or right to object before new subprocessors are added.

Sources

• CSA Cloud Controls Matrix (CCM) v4 — STA domain
• NIST Cybersecurity Framework (CSF) 2.0 — GV.SC (Cybersecurity Supply Chain Risk Management)
• AICPA Trust Services Criteria (SOC 2) — CC9.2 Vendor and business partner risk
• ISO/IEC 27001:2022 — A.5.19–A.5.23 Supplier relationships

Other Supply Chain Management, Transparency, and Accountability controls