The State of Compliance in 2026: Why More Frameworks Won't Fix the Evidence Problem
Compliance obligations evolve; evidence still needs a clear source, preserved context, and a way to test record integrity across systems.
I spent more than twenty years at Procter & Gamble and The Arnott's Group, shipping physical product through regulated multinational supply chains across the UK, Singapore, and Australia. I now work from Sydney.
Behind each product 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, is described by NIST as intended for voluntary use.
EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 with staggered application dates. Regulation (EU) 2026/1744 sets 2 December 2027 for the Annex III high-risk requirements and 2 August 2028 for the Annex I requirements. The Act assigns different obligations to providers, deployers, and other roles.
DORA, the EU Digital Operational Resilience Act, has applied since 17 January 2025, according to the European Commission.
SEC cybersecurity disclosure rules, adopted in 2023, require domestic registrants to file a Form 8-K within four business days of determining that a cybersecurity incident is material, with annual disclosure about cybersecurity risk management, strategy, and governance.
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.
The evidence question
Different rules. A shared need for checkable records.
Rules vary
Applicable obligations depend on the organization, record, and jurisdiction.
Records move
Files and audit context may pass between systems and reviewers.
Evidence is checked
A reviewer needs the relevant file, issuer context, status, and a way to compare them.
A fingerprint comparison can help check file integrity. It does not establish whether the issuer was authorized or the contents are true.
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.
Under 15 U.S.C. 7001(a) (ESIGN), a signature, contract, or other record relating to a covered transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form. This article does not assess how a disputed signature or record would be treated. E-signature certificates and audit trails can be retained alongside the signed file.
The same question can arise in due diligence. An acquirer may want to confirm that a target's executed agreements were signed by the people named, on the stated dates, and have not been edited since. If an export from an earlier signature platform does not carry the original audit trail, that confirmation takes more work.
What a System Migration Can Do to Evidence Access
FDA’s September 2003 guidance, Part 11, Electronic Records; Electronic Signatures: Scope and Application, describes how FDA interprets the scope of Part 11 for electronic records kept under other FDA recordkeeping requirements or submitted to the agency.
At P&G, when an audit came up, we would pull people off R&D for two to three weeks to chase down documents and prove which versions were current.
A system migration can make that work harder. Archived exports, PDF files, and CSV extracts may preserve a record without preserving the searchable audit trail and links a reviewer used before the move.
The hard part is often not the rules themselves. It is producing evidence an outsider can check, at a moment when the systems that produced it 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 fingerprint match is a file-integrity result; it is not a determination 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. Records that report per-document proof availability, such as the public record ARK-DOC-2Z5WPG, return a per-document inclusion proof from Arkova’s public API; older records may report only a batch-level reference.
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.
Agents can query public records through Arkova’s MCP server and API. Other workflow features should be evaluated against their current product documentation before a buyer relies on them.
Arkova’s public record lookup reports record fields; it 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.
Arkova provides a public record and fingerprint reference that can sit beside existing source systems. Its public records are not scored against current or 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.