The State of Compliance in 2026: Why More Frameworks Won't Fix the Evidence Problem

I started my career as a Project Manager at Procter & Gamble in R&D, working on cosmetics and personal-care launches out of Europe. Twenty years on, after roles that took me through New York, Hong Kong, Singapore, and now Sydney, the pattern I watched at P&G has repeated in every market I've touched.

Behind every launch was a paper trail, and behind every paper trail were auditors: state health departments, internal SOX teams, Big Four reviewers, EU regulators when a product crossed a border, and GxP inspectors any time a formula carried a health claim. The lesson I learned then is the lesson compliance teams everywhere are now learning. The rule set has roughly tripled in scope. The evidence layer beneath it, the actual proof you produce when an auditor asks "show me what happened on March 15th", has not improved in two decades.

In 2026 that gap has become the bottleneck. There are more compliance frameworks than at any point in modern business history, more granular audit demands, and more regulators looking. What is missing is a verification layer that scales with the compliance burden. At most large organizations the basic act of producing audit evidence still relies on the same tools and workflows that worked twenty years ago, even though the obligations on top of them are not the same.

The Compliance Surface Has Multiplied

Five years ago a typical regulated enterprise was operating against SOX, HIPAA or FERPA depending on industry, GDPR if it had EU exposure, ESIGN and UETA for signed records, and a handful of state-level statutes. That set was already burdensome, and it was more or less stable.

Since 2020 the surface has multiplied:

NIST AI Risk Management Framework, released in early 2023, is now a baseline expectation for any organization deploying AI in regulated workflows.

EU AI Act entered into force on 1 August 2024 and phases in through 2 August 2027, with prohibitions on unacceptable-risk systems already applicable since February 2025 and General-Purpose AI obligations since August 2025.

DORA, the EU Digital Operational Resilience Act, became applicable on 17 January 2025 for around 20 categories of financial entities, with penalties up to 2% of annual worldwide turnover for non-compliance.

SEC cybersecurity disclosure rule, adopted on 26 July 2023, requires public companies to disclose material cyber incidents within four business days and report annually on board-level oversight of cyber risk.

As of January 2026, 19 US states have comprehensive consumer privacy laws on the books, with Indiana, Kentucky, and Rhode Island the most recent to take effect. Most large multinationals also map against LGPD (Brazil), DPDP (India), PDPA (Singapore), POPIA (South Africa), and APP (Australia).

For a multinational with US, EU, and APAC operations, the practical compliance footprint has gone from five or six core frameworks in 2018 to closer to twenty today. Each one carries its own evidence requirements, scorecard, and audit cadence.

Each New Framework Reuses the Same Broken Substrate

Every new regulation gets layered on the same primitives. System audit logs, manual exports, e-signature certificates, screenshots emailed between compliance and legal. The substrate has not been redesigned. It has just been asked to do more.

That substrate has a real weakness. It does not actually prove anything. When an auditor asks for evidence that a control was operating on a specific date, what they receive is some combination of vendor-system exports, PDFs, screenshots, and email threads. Every one of those artifacts was produced by the same party being audited. The vendor's audit log can be edited from inside the vendor's system, the PDF is whatever the compliance team chose to render, and the email thread is selectable evidence.

The cleanest illustration is contract evidence. ESIGN and UETA make electronic signatures legally equivalent to wet ink, but only if you can authenticate them. When an e-signed contract is challenged, courts look for a clear audit trail showing who signed, when, that the signer had notice of the terms, and that they intended to sign. That trail typically lives inside whichever signature platform was used. If the platform changes, gets acquired, sunsets a feature, or becomes too expensive to keep on a legacy contract, the proof you relied on becomes harder to produce in the form a court will accept. The contract is still valid. The evidence behind it is harder to assemble.

This is also why mid-deal due diligence so often turns into archaeology. Acquirers want to confirm that a target's executed agreements were signed by the people the documents claim, on the dates the documents claim, with terms that have not been edited since. They are routinely told the export format from the previous signature platform no longer reconstructs the original audit trail.

GxP Is Stricter. The Substrate Underneath Is Not.

GxP regulation in pharma and FMCG R&D, Good Laboratory Practice, Good Manufacturing Practice, Good Clinical Practice, is genuinely strict. Every result, every batch test, every formula change carries chain-of-custody requirements. The 21 CFR Part 11 rules on electronic records and signatures are detailed enough to occupy entire teams of validation specialists.

Even there, even inside a regime designed to be the gold standard for auditable evidence, the technology was vendor-dependent. We trusted the LIMS, the eQMS, the document management system, because there was no alternative. The audit trail lived inside a database that the vendor controlled.

Then we did a system migration from one platform to another. Historical batch records were preserved in archive form, exports, PDF dumps, CSV, but they were no longer trivially auditable. We could find a record if we needed to. The searchable, hyperlinked, audit-trail-rich format that satisfied a real-time auditor request was gone. The compliance burden did not go away. The access to evidence did.

“The compliance burden never goes away. The evidence access does. Every time you change a system, every time a vendor sunsets a feature, every time an export reformat breaks an old timestamp.”

That experience shaped my view of every audit since. The hardest part of compliance is rarely the rules themselves. It is producing evidence an outsider can verify, at a moment when the systems you originally produced it in may no longer exist in the same form.

Three Failure Modes of Vendor-Centric Evidence

The pattern repeats across industries and frameworks.

1. Lock-in. When evidence lives inside a vendor's system, leaving the vendor breaks the audit chain. Old timestamps may not survive the round-trip. Cross-references between records get rewritten. The audit history becomes harder to verify, even if the underlying records still exist.

2. Migration. Internal system migrations create the same problem without changing vendors. A new HRIS, a new e-signature platform, a new GRC tool. Every transition is a moment where chain-of-custody can quietly degrade.

3. Self-attestation. The vendor is attesting to itself. The party producing the evidence also controls the storage system, the audit log, and the export format. Auditors are not naive about this. They accept it because there is no commonly available alternative.

GRC platforms like Vanta, Drata, Secureframe, and Workiva solve real problems around evidence aggregation and control mapping. They do not solve this one. They aggregate evidence. They do not produce evidence that can be verified independently of the system that stored it.

What the Evidence Layer Should Actually Look Like

The evidence layer should have three properties.

Vendor-independent. It should not depend on any single company, including the company that produced the document and the company providing the verification service.

Mathematically verifiable. Anyone, anywhere, should be able to verify a record's existence and integrity using nothing more than the document, a public ledger, and a checksum tool.

Jurisdiction-aware. The same record should be mappable to the specific controls of any framework that applies, ESIGN, UETA, FCRA, GDPR, DORA, EU AI Act, and whatever lands next.

This layer is not a replacement for existing systems. Your DocuSign tenant, SharePoint instance, HRIS, and document management platform keep doing what they already do. The evidence layer sits next to them. Documents stay where they are. Only a cryptographic fingerprint, a 64-character SHA-256 hash that cannot be reversed to recover the original document, goes anywhere external.

How Arkova Is Building It

Arkova is in beta. We are working with pilot customers today and we are deliberately publishing what is shipping rather than what is on a slide. The layer breaks into three pieces.

1. Client-side fingerprinting. When you anchor a document, the cryptographic hash is generated entirely inside your browser. The file itself never leaves your device. This is not a privacy nicety. It is the architectural property that lets HIPAA, FERPA, and GDPR scopes shrink dramatically. Our servers cannot leak documents they never receive.

2. Anchoring to an immutable public ledger. The hash is written to a public, append-only ledger. Once written it cannot be edited, deleted, or forged. Anyone with the original document can recompute the hash and verify it matches what was anchored. The proof does not depend on Arkova staying in business. Verification is doable with shasum and a public ledger lookup.

3. AI tooling around the anchor. Around the cryptographic core we are building a layer of internal tooling on Google's Gemini models. The metadata-extraction service, which classifies anchored records into credential type, issuer, dates, jurisdiction, and the field labels an auditor needs to find a record, is running with our beta customers today. We are extending the same architecture in four directions:

• Fraud-pattern detection across anchored documents (issuer mismatches, anomalous date sequences, suspicious template reuse).

• Automated template creation for repeated document types so an issuer can anchor a hundred records as easily as one.

• Organizational layouts that group related anchors into reviewable bundles, mapped to the framework controls they evidence.

• Agent-accessible workflows through our MCP server, so an enterprise's own AI agents can query the verification surface directly rather than scraping a UI.

Nessie, our regulation-specific compliance engine, is being trained right now. The plan is for it to score anchored documents against specific framework controls and cite the exact statute subsection, running on the same PII-stripped metadata so the model never touches raw documents. It is not yet in front of customers. The beta product today is the verification API, the anchoring surface, and the metadata-extraction layer.

Together these layers will produce something the traditional evidence stack cannot: a record whose existence and integrity can be proven independently, whose lifecycle can be queried, and whose compliance posture can be scored against the specific frameworks an auditor cares about, without requiring trust in any single vendor.

What This Means for Audit Cost

Look at the published numbers.

Those are external invoices. Internal preparation cost sits on top of them, benchmarked by Thomson Reuters at thousands of dollars per employee per year inside large financial institutions.

Behind the invoice is duration. Large enterprises typically need six to twelve months to prepare and test for SOX compliance. For Fortune 500 companies, the audit cycle dominates a meaningful share of the compliance team's calendar every year.

The four phases that consume the most internal time, discovery, verification, chain-of-custody documentation, and report assembly, all collapse when the underlying records are independently verifiable. Discovery becomes an API call. Verification becomes a checksum. Chain-of-custody is the public ledger itself. Report assembly becomes a list of links and timestamps the auditor can verify themselves. Whether that translates to a meaningful percentage off the audit budget or a transformative one will vary by organization, and we want to learn the answer from real customer baselines, not from our marketing slide.

The Strategic Picture

None of this is stabilizing. Frameworks I have not named in this piece, DORA revisions, the next round of SEC disclosure rules, post-quantum cryptography mandates, and a wave of sectoral AI rules, are already in committee drafts I have read parts of. The compliance footprint a global enterprise carries in 2028 will be wider than the one it carries today, and most of the new obligations will plug into the same vendor-controlled audit logs that already creak under the existing stack.

You cannot solve a verification problem by adding more frameworks. You solve it by fixing what evidence actually means.

“You cannot solve a verification problem by adding more frameworks. You solve it by fixing what evidence actually means.”

That is the work we are doing at Arkova. Two decades watching audit chains break taught me that the only durable answer is an evidence layer that does not need to be rebuilt every time the compliance landscape changes. Documents stay in the systems where they live today. Cryptographic proof lives somewhere that no vendor, including us, controls. And the same record can be scored against whichever framework lands next.

The Bottom Line

After twenty years inside compliance-heavy organizations, the pattern I see in every enterprise team I talk to is the same one. People are exhausted from rebuilding evidence packages every quarter on top of fragile vendor logs. The compliance burden is not what is breaking them. The substrate is.

Fix the substrate and the rest of the system gets simpler. Audit prep stops being a quarterly archaeology project. Vendor transitions stop quietly degrading the audit history. Counterparty verification requests turn into one click. The compliance posture stops being a snapshot and starts being a continuous, queryable property of the records themselves.

That is not a technology pitch. It is the only response I have found, after a long career inside the problem, that does not break the next time the framework list grows.