The audit question that has changed in the last three years is not the one about your perimeter. It is the one about your vendors.

Auditors used to stop at the edge of your environment. They would inspect your controls, your evidence, your incident logs, your access reviews. If you used a cloud platform, they would ask for the platform's SOC 2 report, glance at it, and move on. The platform's compliance was the platform's problem.

That model is being retired across multiple regulatory regimes at the same time. Today, when an auditor reviews your environment and sees a vendor in your data path, they do not stop. They walk past your perimeter into the vendor's, and they ask you to prove that you govern that vendor. They ask for evidence the controls described in the data processing agreement are operational, not aspirational. They ask for the subprocessor change log. They ask whether your incident-response posture can absorb the breach notification window your vendor is contractually bound to give you. If the answer is "we have their SOC 2 report on file", the audit finding is yours, not theirs.

This article walks through how the regulators got here, what the major frameworks now expect, and what an architecture that survives this kind of scrutiny actually looks like.

The shift from contract clauses to demonstrated governance

The old vendor-management posture was contract-centric. Sign a data processing agreement, file it, name a vendor manager, run an annual recertification questionnaire if you were diligent, attach the vendor's most recent SOC 2 report when audit time arrived. The model assumed that contracts plus paperwork equalled governance. For a decade, it largely worked.

It stopped working because two things happened in parallel. Regulators noticed that the largest data exposures of the last decade were vendor-driven (the 2020 SolarWinds compromise, the 2023 MOVEit incident, the dozens of smaller ones in between), and started writing language that pushed responsibility for vendor outcomes back onto the customer. And auditors, increasingly armed with frameworks that explicitly required continuous oversight of suppliers, stopped accepting "we have a DPA" as the answer to "show me how you govern them".

The new model is governance-centric. Contracts are necessary but not sufficient. The auditor wants to see the ongoing operational evidence of governance: the access reviews you ran on the vendor's behalf, the subprocessor change log you maintain, the incident notifications the vendor sent you, the artefacts the vendor produced on demand when you asked for them. Vendor compliance is now your output, not the vendor's.

What the major frameworks now expect

The pattern is consistent across geographies, with different vocabulary but the same direction.

GDPR Article 28 (European Union). Article 28 is the most prescriptive vendor-governance language in any major framework. A written data processing agreement is required for every controller-processor relationship without exception; using a cloud service, an email platform, or an IT contractor without a DPA is a direct violation regardless of data volume. The processor may only act on documented instructions from the controller. Engaging a subprocessor requires the controller's specific or general written authorisation, and the same data-protection obligations must be imposed on the subprocessor by contract. The liability chain is explicit: if a subprocessor fails to fulfil its obligations, the initial processor remains fully liable to the controller. There is no contractual mechanism that lets the platform vendor offload subprocessor risk back to the customer. The Court of Justice's December 2025 Russmedia ruling reinforced that a processor who independently decides on the purposes and means of processing is automatically reclassified as a controller and becomes directly liable, a reclassification that often surfaces vendor-governance failures the customer thought they had outsourced.

ISO 27001:2022 (international). The 2022 revision split supplier governance across five organisational controls (A.5.19 through A.5.23) and added Control A.5.21 specifically for the ICT supply chain. The control is unusually direct about scope: it extends beyond direct suppliers to the ICT supply chain as a whole, with thirteen specific guidance points the organisation is expected to address. Due diligence on potential ICT suppliers must include certification review and secure-development-lifecycle evaluation. Specific security requirements must be incorporated into legally binding contracts. Primary suppliers must flow down security requirements to their own subcontractors. A.5.22 closes the loop with explicit expectations for monitoring, review, and change management of supplier services. An ISO 27001 audit that finds a static supplier list, an annual questionnaire, and no operational evidence will mark A.5.21 as a major nonconformity in 2026.

SOC 2 CC9.2 (United States, AICPA). CC9.2 requires the entity to assess and manage risks associated with vendors and business partners, with an emphasis on the management process rather than the document collection. The auditor expectation is explicit: a point-in-time vendor assessment will not satisfy the control. The auditor wants a continuous oversight process with documented evidence at multiple points in the assessment period. The AICPA does not require obtaining a SOC 2 report from every vendor; what it requires is establishing a documented risk-assessment process, assigning accountability, and producing evidence that the assessment ran. Vendors with access to customer data, code, or production infrastructure are in scope by default. "We collected their SOC 2 report" is no longer the answer the auditor is looking for; it is one piece of evidence among several.

NIS2 directive (European Union). Article 21 explicitly names supply chain security as a mandatory measure for essential and important entities. The directive expects organisations to manage supply chain cyber risk including the security aspects of their relationships with direct suppliers and service providers. Concretely: a formal supply chain security policy, supplier selection criteria, evaluation of suppliers' cybersecurity practices, and analysis of the resilience of the products and services provided. Binding contracts must include incident notification, security audits, and data-handling rules. High-risk suppliers (ICT services, hosting, managed security) get closer scrutiny: granular review of identity and access controls, system configuration, and data protection. The directive treats this as a board-level competency, not a procurement-team competency, and member state implementations are increasingly issuing reporting obligations tied to "relevant supplier" definitions.

FINMA (Switzerland). Circular 2018/3 on outsourcing requires regulated institutions to ensure the possibility of restructuring or resolving the company in Switzerland when outsourcing a significant business area. The practical implication is that the information required for Swiss restructuring must be accessible in Switzerland at all times, not only from Switzerland. Translated into vendor-governance language: it is not enough for the platform vendor to be cooperative in theory. The Swiss-regulated institution must be able to operate without the vendor's cooperation at a moment when the vendor may not be available. Circular 2023/1 added the critical-data concept on top, with classification and protection obligations that flow into supplier relationships.

ADHICS V2 (United Arab Emirates). The Abu Dhabi healthcare standard explicitly extends supplier governance into the technology vendor stack. Cloud service providers and cloud platform vendors handling protected health information must provide evidence that their controls support ADHICS requirements and UAE data residency. Cross-border transfers require explicit Department of Health approval. The audit posture, with annual audits plus quarterly self-assessments, makes vendor-evidence requests routine rather than exceptional. The healthcare entity remains accountable for what its vendors do with PHI, and that accountability is not transferable through a contract.

SAMA (Saudi Arabia). The Cloud Computing Regulatory Framework requires Saudi banks to operate cloud workloads on infrastructure within the Kingdom and to sign vendor contracts that grant SAMA inspection rights and prohibit unilateral data movement. The expectation is structural: a bank cannot delegate its localisation responsibility to a cloud provider. If the provider cannot demonstrate, in writing and on demand, that it operates a certified Saudi region and that the bank's data has not crossed the border, the bank carries the finding.

Six frameworks, four jurisdictions. The expectation is consistent: vendor governance is now a continuous operational practice with auditable evidence, not a contractual posture.

The audit-time mechanics

What an auditor actually does when they walk past your perimeter looks something like this.

They ask for your vendor inventory. Then they ask which of those vendors process regulated data. Then they ask for the data processing agreement with each one. Then they ask for the evidence that the DPA is operational: when was the last access review you conducted of vendor staff, what subprocessor changes were notified to you in the last twelve months, what incidents the vendor reported and how you handled them.

Then the auditor asks for vendor evidence on demand. They want to see what the vendor produces when you ask for it. Specifically:

  • A current subprocessor list with the dates each subprocessor was added or removed.
  • A log of the vendor's actions on your data for a specific record over a specific period.
  • The vendor's incident-response timing for an actual incident, not the contractual SLA in abstract.
  • Evidence that the vendor's controls engaged for your customer specifically, not for the vendor's customer base in aggregate.

If the vendor cannot produce these on the timescale the auditor expects, the audit finding is yours. The framework language is unambiguous on this point. You are accountable for the data; you are accountable for choosing a vendor who can demonstrate accountability for it.

Why platform vendors increasingly fail this test

Most cloud platforms in 2026 can produce a SOC 2 Type II report on demand. Many can produce a current subprocessor list, usually as a static page on their website. A small minority can produce an access log of which vendor staff accessed which customer record over a specific period. Almost none can produce evidence that the customer can revoke the vendor's operational access to their data without contacting the vendor.

The gap is architectural. A platform built around shared multi-tenant infrastructure has a hard time isolating "vendor staff access to customer X data" from "vendor staff access to the platform". The audit log of vendor staff actions is often centralised, hard to slice per-customer, and not exposed to the customer at all. The subprocessor change log exists on the vendor's marketing site, with no notification machinery and no version history. The customer is dependent on the vendor's cooperation for any evidence beyond the boilerplate.

This is exactly the dependency the modern frameworks are trying to surface. NIS2 calls it ICT supply chain risk. ISO 27001 calls it supplier monitoring. GDPR Article 28 calls it controller accountability. The dependency is the finding.

The questions that distinguish governed vendors from compliant vendors

A short, uncomfortable checklist:

  1. Can the vendor produce a per-record audit log of their staff's actions on your data, for a specific time period? "We have logs" is a 2020 answer. "We have a per-customer, per-record, tamper-evident log you can export at any time" is the 2026 answer.
  2. Does the vendor maintain a subprocessor inventory with versioned changes and active notification? A static page on their marketing site does not meet the bar.
  3. Does the vendor's contract include a right-to-audit clause you can actually exercise? Most vendor contracts soften this to "summary report on request". That is not a right-to-audit clause; it is a customer-service promise.
  4. Can you revoke the vendor's operational access to your data without contacting them? If the answer requires a support ticket, the customer does not actually hold the operational keys.
  5. Does the vendor's incident-response architecture report breaches to you at the speed your own regulator demands? GDPR is 72 hours. NIS2 is 24 hours for initial notification. SAMA, ADHICS, and FINMA have their own clocks. The vendor either fits inside those windows or makes you miss them.

A vendor that answers each of these with a verifiable artefact is governable. A vendor that needs time to assemble a custom report is the source of your next audit finding.

The architectural answer

The vendor-governance shift is, more than anything, a shift in where data and key custody live. The historical model put both inside the vendor's perimeter, with the customer's leverage limited to contracts and audits. The model that survives the new regulator expectations puts both back under the customer's direct control, so that vendor cooperation becomes a convenience rather than a dependency.

This is the design principle behind Novantra. Novantra's BYO Storage means the customer's data lives in the customer's bucket from the moment the platform writes it; vendor compliance with vendor obligations does not gate the customer's access to their own data because the customer has it directly. Novantra's customer-controlled encryption keys mean that even if the vendor cooperated with an unauthorised access request, the vendor could not read the data. Novantra's hash-chained audit stream captures every vendor action on customer data, tamper-evident and exportable, ready for the auditor without a support ticket. Novantra exposes the subprocessor list as a versioned artefact on the platform, not a marketing page on the website. The right-to-audit clause is exercisable because Novantra's architecture leaves nothing material that only the vendor can produce. For customers whose threat model or jurisdiction makes even managed cloud untenable, Novantra's Sovereign deployment runs the entire platform inside the customer's own infrastructure.

None of these is a feature. Each is the architectural answer to a question regulators are now asking out loud: when the auditor walks past your perimeter, what do they find inside ours.