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 each launch was a paper trail: records from source systems, reviewers, and regulators. When a record moved to a new system, the context needed to explain it could become harder to retrieve.

In 2026, teams face new AI and operational-resilience rules alongside long-standing recordkeeping obligations. The number and effect of those rules depend on industry and geography. Producing historical evidence can still require reconciling several systems.

The Compliance Surface Has Multiplied

A regulated enterprise may need to address financial, privacy, health, education, or electronic-record rules, depending on its activities. Those requirements have different scopes and are not interchangeable.

Recent examples show why the evidence inventory needs to be current:

NIST AI Risk Management Framework, released in 2023, offers a voluntary framework for managing AI risks; it is not a universal legal requirement.

EU AI Act entered into force in 2024. Selected provisions have applied since 2025 and 2026; the 2026 amendment moves Annex III high-risk rules to 2 December 2027 and Annex I product rules to 2 August 2028. Which duties apply depends on the system and the organization’s role.

DORA, the EU Digital Operational Resilience Act, has applied since 17 January 2025 to covered financial entities and ICT third-party arrangements. It does not approve any particular proof system.

SEC cybersecurity disclosure rules, adopted in 2023, require covered domestic public companies to file material incident disclosures within four business days after determining materiality, with annual risk-management and governance disclosure.

US state privacy and international data-protection laws also affect some organizations. Coverage and effective dates vary by location and processing activity; a deployment needs its own law-and-data-flow map.

For a multinational, the practical challenge is connecting each applicable requirement to the records and controls that answer it. A framework count is meaningful only when its scope and method are defined.

Different Rules Can Depend on the Same Source Records

Different obligations can call for the same source records, but the required context differs. Logs, exports, signing certificates, and screenshots may all be useful if their provenance and limits are clear.

Exports, screenshots, logs, and certificates can be useful audit evidence. The question is what each artifact proves, who created it, and whether its history and integrity survive a system migration. Some platforms include tamper-evident controls; others require additional preservation work.

ESIGN prevents a signature or record from being denied effect solely because it is electronic; it does not decide whether a disputed signer was authorized or whether a particular copy is authentic. E-signature certificates and audit trails should be retained and assessed in context.

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.

What a System Migration Can Do to Evidence Access

Good-practice and electronic-record requirements depend on the activity and record. FDA’s Part 11 guidance explains how its rules apply to electronic records maintained under applicable FDA recordkeeping requirements or submitted to the agency. Teams need to identify which records are covered and preserve the context required by those rules.

In the system I used, we relied on vendor-controlled tools to retrieve the audit trail. A migration made that retrieval harder.

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. Evidence kept in one vendor’s format can become harder to retrieve after a migration. Preserve exports, provenance, and access plans before changing systems.

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. Provenance. An auditor needs to know what a log or certificate actually attests to, how it was protected, and whether changes can be detected. A vendor-produced artifact can be useful evidence without answering every independent-verification question.

GRC platforms such as Vanta, Drata, Secureframe, and Workiva help collect or manage evidence and may include integrity controls. A separate public-network reference serves a different purpose: an external checkpoint for a recorded value, if the mapping and proof data are available.

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.

Checkable. Someone with a file and its recorded fingerprint can test whether they match. Checking a network anchor for that record also requires sufficient mapping and inclusion data; a ledger address and checksum alone do not establish every document-to-anchor link.

Context-aware. Keep the issuer, lifecycle status, source system, and applicable control separate from the fingerprint. A matching file does not establish legal compliance under ESIGN, GDPR, DORA, or the AI Act.

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. Direct uploads stay on the user's device; selected connected-source documents are fingerprinted in server memory and discarded. Arkova retains the resulting fingerprint and limited metadata, not the original file.

How Arkova Is Building It

Arkova’s public record lookup and fingerprinting service are live. This section describes the pieces of an evidence workflow, including what a recipient still needs to check independently.

1. Fingerprinting. For a direct upload, the cryptographic fingerprint is generated in your browser and the file stays on your device. For a document selected from a connected source, Arkova computes the fingerprint in server memory and discards the file. The Privacy Policy describes both processing paths.

2. Anchoring reference. Arkova links a record to a public-network receipt with a network-observed time. A file fingerprint can be compared with a copy of the document when the recorded value is available. The public sample exposes a receipt, but not a complete per-document offline inclusion proof.

3. Metadata and workflow. Record metadata can help a reviewer find the reported issuer label, dates, and status. AI-assisted extraction is a separate processing path that needs field-level privacy and accuracy checks; classification is not proof that the source document is true.

Potential extensions include reviewed anomaly signals, reusable templates, grouped records, control mapping, and agent-accessible queries. Those features need product-specific documentation before a buyer relies on them.

A proposed compliance-mapping layer would connect records to specific controls. It remains roadmap work; the current lookup does not score legal compliance or certify a framework outcome.

Together, a retained source file, its recorded fingerprint, an anchor reference, and issuer/lifecycle evidence can give a reviewer a more traceable package. Each element supports a different conclusion, and the completeness of the network proof must be checked per record.

What This Means for Audit Cost

Look at the published numbers.

Those are external invoices. Internal preparation also takes staff time, but that cost needs a separate baseline for each organization and audit cycle.

Preparation can span many months in complex organizations, but there is no single SOX timetable that fits every filer. Audit preparation costs should be measured against a team’s own baseline before promising savings.

A well-linked evidence package can make file-version checks and record retrieval easier. It cannot turn every control test into a checksum or replace the auditor’s judgment about authorization, completeness, and operating effectiveness. We need customer baselines to quantify savings.

The Strategic Picture

Rules will change, but this article does not predict a particular 2028 framework count or claim that an unverified draft will take effect. The durable task is to keep source, version, approval, and retrieval context attached to a record as requirements evolve.

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.”

Arkova is working on a public record and fingerprint reference that can sit beside existing source systems. A proposed framework-mapping layer remains roadmap work; current records should not be described as already scored against future rules.

The Bottom Line

The recurring problem is practical: teams can lose context when source records, approvals, and exports live in different systems. That problem deserves a baseline before anyone claims a universal savings rate.

Better record links could make some audit requests easier to answer and reduce the risk of losing a file-version trail during migration. Each team should test that outcome against its own request and retrieval data.

An evidence workflow should be tested for retrieval, continuity, and reviewer usefulness as requirements change.