Something quiet but significant is happening across major regulatory regimes. The question auditors arrive with has changed. It used to be "show us the policy". Today, increasingly, it is "show us the policy working".
This shift has many names. Healthcare regulators in Abu Dhabi call it capability-based assurance. Trust services auditors in the United States call it continuous monitoring. The Swiss financial supervisor calls it operational resilience. The framework families differ; the direction does not. Across geographies, industries, and frameworks, the move is from periodic validation of documentation toward continuous demonstration of working controls in real-world conditions.
For any platform vendor serving regulated industries, this is not a stylistic update. It is a structural change in what passes audit, and an opportunity for the platforms that anticipated it.
What capability-based assurance actually means
The compliance-driven model that dominated the last decade asked a recognisable set of questions. Does the policy exist? Is it documented? Is there an owner? Was the training completed? Most of the work happened in advance of an audit window: a small team assembled evidence, polished documents, took screenshots, and presented the package to an external assessor who confirmed the artefacts existed.
The capability-based model asks a different question. Did the control work the last time it was needed? Will it work when needed next? Can you demonstrate that today, in production, without preparation?
The Abu Dhabi Department of Health is unusually explicit about this. The updated ADHICS V2 standard, which became the operative reference in late 2024 and whose remediation window runs through 2026, states the shift directly. Auditors no longer evaluate whether policies exist; they evaluate how effectively the policies operate in practice. Has incident response been regularly tested, or does it only exist on paper? Are access management controls actually applied across staff roles? Do employees follow data-protection procedures in their day-to-day work, not just acknowledge them on a training slide? The audit framework now examines how people, processes, and technology interact in actual situations.
The framing is unusually direct. The intent is not.
The same trend, four other frameworks
The pattern repeats with different vocabulary in every major framework worth tracking.
SOC 2 has been moving in this direction for years. The Trust Services Criteria's CC4 ("Monitoring Activities") asks how an organisation monitors the effectiveness of its controls on an ongoing basis. For SOC 2 Type II reports the auditor evaluates operating effectiveness over a window of months, not a snapshot. The 2026 updates to the criteria push further toward continuous compliance and explicitly cover AI governance, dynamic authorisation, and encryption across multi-cloud environments. The audit is shifting from "the controls existed during the observation period" to "the controls were continuously working, and you can show the evidence stream that proves it".
ISO 27001:2022 consolidated the previous 114 controls into 93, organised across four broader groups (organisational, people, physical, technological), and added eleven controls for modern risk surfaces such as cloud configuration, web filtering, and threat intelligence. The consolidation matters less than the message: an information-security management system is supposed to be a working system, not a documentation effort. The 2022 revision pulls the standard closer to a posture in which the controls selected must demonstrably address the organisation's risk profile, not satisfy a checklist of headings from a 2013 catalogue.
NIST CSF 2.0 is the most explicit on the outcomes-not-prescriptions principle. The framework states its purpose plainly: it offers a taxonomy of high-level cybersecurity outcomes, and does not prescribe how those outcomes should be achieved. Maturity is measured through Implementation Tiers (Partial, Risk Informed, Repeatable, Adaptive), and the framework now expects assessments to be maintained continuously to inform decision-making. Key performance indicators such as patch speed, phishing-simulation success rate, and incident response time are the assessment, not the policy library.
FINMA, the Swiss financial supervisor, made the shift unambiguous with Guidance 05/2025, which carries a hard supervisory date of 1 January 2026. Every bank, securities firm, and financial market infrastructure under FINMA's supervision must now demonstrate, regardless of size or category, that it can withstand and recover from disruptions to the critical functions its clients depend on. The framework is principles-based; each institution interprets it for its own context. What FINMA inspects is the demonstrated resilience, not the resilience plan. The supervisor's own analysis of 267 institutions shows significant gaps in actually defining what their critical functions are and what disruption tolerances apply, which is precisely the kind of gap a documentation-led audit would never have surfaced.
Five frameworks, three industries, four jurisdictions. One direction.
What this changes about platforms
For platform vendors and the teams that buy them, the shift has practical architectural consequences.
The dominant operating model for the last decade was what we might call the evidence binder. A dedicated team, often called GRC or Compliance, sat next to the product team. Their job was to maintain documents, gather screenshots, run quarterly access reviews on spreadsheets, and translate the product's operations into artefacts a third-party auditor could read. The product itself was not built to produce that evidence. Someone manufactured it on the side.
That model continues to function for narrow point-in-time attestations. It collapses under continuous assurance. There is no human team large enough to produce, every day, the evidence a continuous-monitoring regime asks for.
The model that replaces it is what we will call audit by default. The platform itself emits evidence continuously. Every approval is captured in a tamper-evident stream the moment it happens. Every access change carries a timestamp, an actor, a reason, and a hash that links it to the prior state. Every key rotation, every backup validation, every regulator submission package leaves a trail the platform produced as a side effect of the work. When the auditor arrives, they read the platform, not a binder.
These are different pieces of software, built around different assumptions, by teams with different priorities. A platform retrofitted from the evidence-binder model rarely converts cleanly to audit-by-default. The hash-chain has to go everywhere, not just on the records the compliance team noticed last quarter. Isolation has to be a deployment fact, not a column in a multi-tenant table. Key control has to be exercisable by the customer, not promised in a contract.
How to know which side of the shift you are on
The honest test is not what your compliance documentation says. It is what you can produce in five minutes if someone serious asks for it. A short, uncomfortable list:
- Can your platform produce a complete evidence package for any single control, on demand, with no preparation? Not a policy document, not a sample. The actual record of every time that control engaged in the last quarter.
- Is your audit log tamper-evident, or merely append-only? Append-only means nothing can be added out of order; tamper-evident means no row can be modified after the fact without that modification being detectable. Modern frameworks expect the second.
- When was the last time you tested incident response in production, and what evidence did the test leave behind? "We have a runbook" is a 2018 answer.
- Can you demonstrate that an access policy was followed, not just that it exists? The first is auditable; the second is rhetorical.
- If a regulator asked you to prove that customer data was encrypted under the customer's key and not yours, what would you produce? If the honest answer is "we would explain that our key management is very secure", the platform is still on the wrong side of this shift.
There is no single threshold that separates the two models. There is, however, a recognisable feeling on each side. Teams on the evidence-binder side describe audit week as something they survive. Teams on the audit-by-default side describe it as a meeting on a Wednesday.
The architectural answer
The shift toward capability-based assurance is, more than anything, a question about where the burden of proof sits. The frameworks above are all moving the burden onto the platform itself. They expect the platform to be the witness, continuously, of its own operation.
This is the design principle behind Novantra. Novantra's database-per-organisation isolation is something an auditor can inspect at the storage layer, not a query-middleware assertion that has to be trusted. Novantra's hash-chained audit stream captures every approval and every key use, not a log file that someone could overwrite. Novantra's customer-controlled encryption keys mean the customer can prove cryptographic separation, not assume it. Novantra's Sovereign deployment lets the customer run the entire platform inside their own infrastructure when residency, jurisdiction, or trust posture demands it. Each of these is not a feature. Each is a continuous evidence output, designed in from the start. The companion piece on audit-grade evidence as a continuous output covers why this matters at the operational level.
The frameworks are converging. The platforms that anticipated the convergence will spend the next decade making audit a Wednesday meeting. The platforms that did not will spend it surviving quarterly fire drills, with a regulatory floor that keeps rising under them.
The choice was made earlier than the regulators arrived. It is being revealed now.