There is a clause in almost every regulated cloud platform contract that exists to be exercised but almost never is. It is the right-to-audit clause, and procurement teams in 2026 are starting to notice that the version sitting in their signed contracts is not the version any regulator would expect them to have negotiated.
The clause matters because every major framework now expects the buyer to retain genuine, exercisable audit rights over the vendor. GDPR Article 28(3)(h) requires processors to allow for and contribute to audits conducted by the controller or "another auditor mandated by the controller". DORA Article 30(3)(e)(i), effective from 17 January 2025, requires "unrestricted rights of access, inspection and audit by the financial entity, or an appointed third party, and by the competent authority", with the explicit qualification that those rights must not be "impeded or limited by other contractual arrangements or implementation policies". FINMA Circular 2018/3 requires the outsourcing institution, its regulatory auditor, and FINMA itself to have a contractual right to inspect and audit at any time and without restriction. Each is the kind of clause that, if missing from a vendor contract, surfaces as a finding the moment a regulator looks at what the buyer actually signed.
The companion article on vendor compliance becoming your audit finding covers the broader audit-side picture. This piece is about the specific contract clause. Why the softening patterns vendors offer fail under modern audit, what each major framework actually expects the clause to contain, and why the architectural answer is to make audit access a property of the platform rather than a clause that has to be negotiated and defended.
The clause that exists to be exercised but never is
The standard right-to-audit clause in a 2026 cloud platform contract typically reads something like this: "Vendor will make available its most recent SOC 2 Type II report under non-disclosure, upon request, no more than once annually. Such report constitutes the sole audit deliverable hereunder. Customer may, at Customer's expense and upon sixty days' notice, conduct an additional audit subject to Vendor's reasonable security policies and conducted by a mutually agreed independent third party. Audits shall not extend to Vendor's other customers or shared infrastructure."
Read against the framework requirements above, each phrase is doing work. "Sole audit deliverable" substitutes the vendor's audit (scoped, timed, written by an auditor the vendor pays) for the customer's audit. "No more than once annually" eliminates the ad-hoc audits that NIS2 and the HIPAA NPRM expect after significant incidents. "Sixty days' notice" gives the vendor preparation time, reducing the audit to a rehearsal. "Mutually agreed independent third party" vetoes the customer's chosen auditor; EDPB Opinion 22/2024 addresses this directly, holding that the final decision must rest with the controller. "Subject to Vendor's reasonable security policies" lets the vendor define scope under the word "reasonable", which is undefined. "Not extend to other customers or shared infrastructure" carves out the multi-tenant boundary, which is the highest-risk area in any cloud platform architecture and the area regulators are most interested in.
Stacked together, the clauses produce a right that is theoretically present and practically unexercisable. Industry surveys consistently find that negotiated audit rights are almost never exercised. The risk surfaces during regulatory inquiry, where a supervisor asks "show me you verified your vendor's controls" and the buyer has only the vendor's SOC 2 report, the same one every other customer of that vendor received. The contract preserved the clause; the clause preserved nothing.
The DORA Article 30 wording was a direct legislative response to this pattern. The phrase "not impeded or limited by other contractual arrangements" is targeted at exactly the softening clauses above. The regulator's view is now explicit: a contract that nominally contains a right-to-audit clause but layers conditions that make the right unexercisable is non-compliant on its face.
The eight softening patterns and why they fail
The softening patterns vendors use are catalogued enough by now that procurement teams should be able to spot them at a glance and price them into negotiation. Eight patterns recur.
First, "annual SOC 2 report shall satisfy this requirement". This substitutes a vendor-controlled audit for a customer-controlled audit. The SOC 2 was scoped by the vendor, written by an auditor the vendor pays, and reports on what the vendor chose to include. It breaks GDPR Article 28(3)(h) "auditor mandated by the controller" and DORA Article 30(3)(e)(i) "not impeded".
Second, "on request, customer may receive a summary report". No raw access. The vendor controls what the summary contains, which means the vendor controls what the customer can verify. This breaks Article 28's "all information necessary to demonstrate compliance".
Third, "audits no more than once per year". This eliminates ad-hoc audits after significant incidents. NIS2 Article 21 expects ad-hoc verification after reportable incidents. The HIPAA 2024 NPRM, with comments closed in March 2025 and a final rule expected in 2026, proposes annual SME-supported verification with the right to re-verify on demand.
Fourth, "audits at customer's expense". This is the financial deterrent. Standard and generally acceptable as a single clause, but combined with the others it becomes prohibitive.
Fifth, "subject to vendor's reasonable security policies". The vendor controls scope under an undefined term. This permits last-minute scope cuts and is the clause most vendors are reluctant to drop.
Sixth, "sixty or ninety days' notice required". This gives the vendor preparation time, which reduces audit to a rehearsal. For incident-driven audits the notice period itself is a non-compliance.
Seventh, "mutually agreed independent third party". This vetoes the customer's chosen auditor. EDPB Opinion 22/2024, adopted in October 2024, addressed the question explicitly: the processor may suggest an auditor, but the final choice must be left to the controller.
Eighth, "audits shall not extend to vendor's other customers or shared infrastructure". This is the most consequential carve-out, because it removes from scope exactly the area where a regulated buyer needs assurance: the multi-tenant boundary, the shared services, the operational practices that put one customer's data adjacent to another's. The companion article on multi-entity compliance covers why this boundary matters.
A contract with any one of these patterns may still be compliant if the others are absent. A contract with three or four stacked is producing a right-to-audit clause that exists on paper and nowhere else.
What the major frameworks now expect
The pattern is consistent across jurisdictions. The vocabulary differs. The direction does not.
GDPR Article 28(3)(h) (European Union). The processor "makes available to the controller all information necessary to demonstrate compliance" and "allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller". EDPB Guidelines 07/2020 and EDPB Opinion 22/2024 interpret "contribute to" actively: the processor must provide premises access, documentation, personnel for interview, and reasonable cooperation, not merely hand over a SOC 2 report. The processor may suggest an auditor, but the final choice is the controller's. Opinion 22/2024 also tightened the controller's verification obligation across the entire sub-processor chain: the controller must have the identity (name, address, contact) of all processors and sub-processors readily available at all times, with Article 28 flowing down to every sub-processor.
DORA Article 30(3)(e)(i) (European Union, financial). Effective from 17 January 2025. Mandates "unrestricted rights of access, inspection and audit by the financial entity, or an appointed third party, and by the competent authority, and the right to take copies of relevant documentation on-site if they are critical to the operations of the ICT third-party service provider, the effective exercise of which is not impeded or limited by other contractual arrangements or implementation policies". The "not impeded or limited" qualifier is targeted at the contractual softening patterns above. Pooled-audit arrangements (multiple financial entities appointing one independent auditor at shared cost) are the regulator's pragmatic compromise for hyperscaler relationships where individual customer audits do not scale; the right itself, however, must exist contractually.
NIS2 Article 21(2)(d) (European Union). Essential and important entities must adopt "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". The directive expects the entity to verify rather than trust. ISO 27001 certificates, SOC 2 Type II, and CSA STAR Level 2 can substitute for direct on-site audits for non-critical suppliers, but the audit right itself must exist contractually, and ad-hoc audits after significant incidents are within scope. Member State transpositions (Germany's NIS2UmsuCG, Italy's D.Lgs. 138/2024, Belgium's law of 26 April 2024) preserve Article 21 verbatim and add national vendor-assurance templates that include explicit on-site audit clauses.
ISO 27001:2022 (international). Annex A.5.19 requires a topic-specific policy on supplier relationships. A.5.20 requires that security obligations be legally binding and unambiguous, and explicitly calls out either the legal right to audit or a contractual requirement to provide independent audit reports. A.5.21 extends both down the ICT supply chain to sub-suppliers; this control is new in 2022 with no equivalent in the 2013 version. A.5.22 specifies monitoring, review, and change management of supplier services, including the evidence the contract should require. The October 2025 transition deadline means certified organisations must now demonstrate operational evidence of A.5.21 supplier-chain mapping, not just a topic-specific policy.
SOC 2 CC9.2 (United States, AICPA). The entity "assesses and manages risks associated with vendors and business partners". The 2022 revised points of focus formalised vendor-relationship risk identification and continuous evaluation rather than annual checkbox review. Auditors look for contract terms that include the right to receive SOC 2 or SOC 3 reports on a defined cadence, the right to request additional information or perform additional audit on identification of risk, breach notification obligations with defined timelines (typically 24 to 72 hours), the right to terminate for material security failure, and the vendor's own obligation to maintain a vendor-risk-management programme that flows down. Vendor reassessments after SOC 2 reports change scope or issue qualifications are explicit expectations in 2024 and 2026 audit cycles.
PCI DSS 4.0.1 (international, payments). Requirement 12.8.2 requires written agreements that include the third-party service provider's acknowledgement of responsibility for security of account data. Requirement 12.8.5 requires the entity to maintain information about which PCI DSS requirements are managed by each third-party service provider, which are managed by the entity, and which are shared, in a documented responsibility matrix. Requirement 12.9 (service-provider side) obligates the third-party service provider to acknowledge in writing to customers their responsibility for the security of cardholder data and to provide, on request, information that supports the customer's 12.8.5 due diligence. The v4.0.1 update of June 2024 clarified the third-party service provider applicability notes and reinforced that the Attestation of Compliance alone is not sufficient; the responsibility matrix is part of the deliverable.
NIST SP 800-53 Rev 5 (United States, federal). The Supply Chain Risk Management (SR) family is new in Rev 5 with no equivalent in Rev 4. SR-3 requires a supply-chain risk management process; SR-6 requires supplier assessments and reviews at organisation-defined frequency, with the assessment considering security practices, foreign ownership and control, and the supplier's ability to assess its own subordinate tiers; SR-9 requires tamper-resistance and detection programmes. NIST SP 800-161 Rev 1 provides implementation guidance. FedRAMP Rev 5 baselines, now standard, inherit the SR family.
HIPAA Business Associate Agreements (United States, healthcare). Current BAAs must obligate the business associate to comply with the Security Rule, report breaches and security incidents, ensure subcontractors agree to the same restrictions, and make books and records available to HHS. The December 2024 NPRM proposes converting the BAA from an attestation document into a continuous-assurance arrangement: covered entities must verify in writing at least every twelve months that the business associate has implemented the required technical safeguards, with the verification supported by a subject-matter expert's analysis and written certification. The proposed compliance window is 180 days after the final rule publishes; comments closed in March 2025.
FINMA Circular 2018/3 (Switzerland). The outsourcing institution, its regulatory auditor, and FINMA must have a contractual right to inspect and audit all information relating to the outsourced function at any time and without restriction. Outsourcing essential functions to a foreign jurisdiction is permissible only if the institution can guarantee that all three (institution, regulatory auditor, FINMA) can exercise and enforce inspection rights, with the explicit qualification that where local foreign law would impede this, the outsourcing is not permissible. The institution must retain "effective control" over the outsourced function. Audit can be delegated to the provider's audit firm if adequately qualified, but in that case the audit reports must be provided to FINMA on request.
ADHICS V2 (United Arab Emirates). Healthcare entities and their third-party service providers must comply with ADHICS controls. The expanded V2 scope includes third-party risk management, cloud security, and medical-device cybersecurity. Third-party providers handling healthcare data must contractually comply with ADHICS, and contracts must require permission for Customer, the Department of Health, and the certified audit firm to inspect provider premises and records relevant to ADHICS compliance. Patient data cannot be stored or processed outside the UAE; cross-border transfer requires explicit DoH approval obtained by the customer.
SAMA (Saudi Arabia). The Cyber Security Framework Domain 5 and the Rules on Outsourcing require contractual right-to-audit, incident notification, business continuity, and exit-strategy clauses. SAMA's own supervisory inspection rights flow through to vendor contracts: contracts with cloud providers handling Saudi-licensed institutions' data must explicitly grant SAMA inspection rights and prohibit unilateral data movement. In-Kingdom hosting is mandatory for sensitive customer data, transaction records, and operationally critical data; SAMA pre-approval is required before using cloud services.
The subprocessor-list problem
Adjacent to the right-to-audit clause is the subprocessor-list problem. GDPR Article 28(2) requires prior specific or general written authorisation of subprocessors, and under general authorisation the processor must inform the controller of any intended changes (addition or replacement) and give the controller an opportunity to object. EDPB Opinion 22/2024 sharpens this: controllers should have the identity (name, address, contact person) of all processors and sub-processors readily available at all times.
What most vendors offer in 2026 is a static page on their trust portal listing current subprocessors, with no version history, no notification subscription, and a one-line disclaimer that the list may be updated periodically. This fails the "opportunity to object" test by design: the controller learns of changes only by polling the page, and there is no mechanism to register an objection that the vendor's contract recognises.
What the regulation actually expects is a versioned subprocessor manifest per controller, push notification on every addition or replacement (typically thirty days' advance notice), the customer's right to object, and a documented procedure if the objection cannot be resolved (usually a termination right for the affected scope). The companion article on vendor compliance covers why this matters for audit findings. A subprocessor manifest exposed as a first-class platform artefact rather than a marketing page is the architectural answer; a webhook or email notification on every change converts Article 28(2) compliance from a PDF refresh into an event stream the controller can subscribe to.
The questions a procurement team should now ask
A short, uncomfortable checklist for any team negotiating a regulated cloud platform contract in 2026.
- Does the right-to-audit clause give the customer or its chosen auditor on-site inspection rights? Not "review of the SOC 2 report". Not "summary on request". Specifically: can the customer's auditor enter the vendor's premises, review documentation, interview personnel, and produce findings?
- Can the customer commission an ad-hoc audit after a significant incident, without waiting for the annual window? The frameworks above all expect this; most vendor templates prevent it.
- Does the right-to-audit clause carve out shared infrastructure or other customers? If yes, it has carved out the most relevant area. Negotiate the carve-out or price the residual risk.
- Is the subprocessor list a versioned, push-notification-driven manifest, or a static page on a trust portal? EDPB Opinion 22/2024 requires the former.
- Does the contract include the DORA-style "not impeded or limited by other contractual arrangements" qualifier? If your buyer is a financial entity in the EU, this is now mandatory. If not, it is the clause most likely to defeat a future vendor softening attempt.
A vendor that answers each of these by pointing at an architectural artefact (an audit log the customer can export, a subprocessor manifest the customer can subscribe to, a tenant-isolated storage boundary the customer can inspect directly) is making the right exercisable. A vendor that answers by pointing at a clause is making the right negotiable, and the framework expectation is that negotiation alone is insufficient.
The architectural answer
A right-to-audit clause that has to be exercised through contract negotiation, vendor cooperation, and the vendor's own choice of auditor is a right that survives almost nothing. The architectural answer is to make audit access a property of the platform, not a clause that has to be defended. This is the design Novantra was built around.
Novantra's BYO Storage is the foundation. When the customer's data lives in the customer's own bucket (S3, GCS, Azure) under credentials the customer issues and can revoke, the customer can directly inspect their own data at any time without the vendor's cooperation. The right to audit is replaced by the right to query, which is structurally stronger because it does not depend on vendor goodwill. The companion article on data residency as a deployment decision covers the architecture in detail.
Novantra's customer-controlled encryption keys close the cooperation loop on the data plane. Even if the bytes were accessible, the vendor cannot read them without calling out to a key service the customer operates. The customer holds a cryptographic veto and a usage log the vendor cannot edit. The companion article on customer-controlled encryption keys covers the architecture.
Novantra's hash-chained, exportable audit logs replace the "annual SOC 2 report" answer with continuous evidence the customer can verify independently. The companion articles on continuous evidence and tamper-proof audit trails cover the integrity layer.
Novantra publishes a per-customer versioned subprocessor manifest, with webhook or email notification on every change and a documented objection window, converting GDPR Article 28(2) from a PDF refresh into an event stream. Real-time access logs surface vendor personnel access into the customer's audit stream, with justification and ticket reference, in near-real time rather than three months later through a SOC 2 report.
Novantra's database-per-organisation isolation eliminates the "we cannot audit shared infrastructure" carve-out by giving each customer a separately auditable footprint. The companion article on multi-entity compliance covers the model in detail. For customers whose contract terms would never permit any shared infrastructure at all, 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 contract clause that has been narrowed to the point of uselessness in the standard cloud platform template. A regulated buyer who reads vendor contracts assuming a regulator will eventually inspect what they signed should prefer platforms where audit access is a property of the architecture rather than a clause that has to be negotiated, exercised, and defended against the eight softening patterns. The frameworks have already made the regulatory expectation clear. The architecture either matches it, or the contract becomes the audit finding.