Proving nothing was removed after the documentation completion date

AS 1215 does not ask a firm to promise its workpapers were not altered. It sets a shape the documentation must hold. The gap this page is about is that almost no firm can demonstrate that shape to an inspector except by pointing at its own system and asking to be believed.

What the standard actually says

Three requirements, quoted from AS 1215:

"A complete and final set of audit documentation should be assembled
for retention (i.e., archived) as of a date not more than 14 days
after the report release date"

"The auditor must retain audit documentation for seven years from the
date the auditor grants permission to use the auditor's report"

"Audit documentation must not be deleted or discarded after the
documentation completion date, however, information may be added."

The third sentence is the interesting one. It is not "do not change the file". It is append-only, stated in plain English a decade before anyone called it that. Deletion is prohibited; addition is expressly permitted. A revised version of AS 1215 takes effect on 15 December 2026, which is why most firms are looking at their documentation controls right now.

The regulator's own warning, before the consequences

The PCAOB does not wait for an alteration to happen and then react. It put out its own warning first, in Staff Audit Practice Alert No. 14, "Improper Alteration of Audit Documentation" (April 21, 2016):

"[I]mproperly altering audit documentation in connection with a PCAOB
inspection or investigation violates PCAOB rules requiring cooperation
with the Board's oversight activities and can result in disciplinary
actions with severe consequences."

"[E]vidence indicates that documents were created shortly in advance
of, or during, an inspection, backdated, and then made available to
PCAOB inspectors without any disclosure of when they were actually
created."

The orders that follow are not a hypothetical risk. They are the Board doing exactly what it said, in writing, it would do.

What it costs to be unable to prove it

The PCAOB publishes its own tally in its enforcement spotlight on improper alteration of audit documentation. As set out there: 33 disciplinary orders for failure to cooperate with an inspection and 28 for failure to cooperate with an investigation, 18 firms whose registration was revoked, and 53 individuals sanctioned, of whom 45 were barred. The Board states that a majority of those orders involved improper document alteration, and describes its own posture as "zero tolerance".

Losing registration is not a fine. A firm without PCAOB registration cannot audit an issuer. There is no larger consequence available in this market, and it has already landed on eighteen firms.

The control most firms rely on has already been defeated

This is not hypothetical, and the sharpest description of it belongs to the Board rather than to us. Announcing sanctions against a firm and three of its partners for attempting to deceive inspection staff, the PCAOB recorded that personnel "took various steps, including changing computer clocks and printing documents to PDF, to conceal the alteration of the workpapers."

Read that again with an inspector's eyes. The evidence a firm normally produces about when a workpaper was finalised is a timestamp, and that timestamp comes from a machine under the control of the people the evidence is about. It was not the documentation system that surfaced the problem. Inspectors found it, during the 2020 and 2022 inspections, after the fact.

An archive lock anchored to an external RFC 3161 timestamp does not care what the local clock says. That is the specific reason ActaSeal anchors it externally rather than trusting the host.

The gap

Every firm's quality manual already says documentation is not altered after the completion date. The manual is not the problem. The problem is what happens when an inspector asks the firm to show it.

What a firm can usually produce is a report from the same system that holds the workpapers, generated by the firm, attesting to the firm's own conduct. That is an assertion. It is only as strong as the trust the inspector extends to the firm and to the firm's software vendor, and eighteen revocations are what happens when that trust is withdrawn.

Why this outlives any one regulator

AS 1215 is a PCAOB standard. Enforcement of it depends on the PCAOB existing, having jurisdiction, and choosing to act. Underneath it, covering the same conduct, sits a federal criminal statute that does not depend on any of that: 18 U.S.C. § 1519:

"Whoever knowingly alters, destroys, mutilates, conceals, covers up,
falsifies, or makes a false entry in any record, document, or tangible
object with the intent to impede, obstruct, or influence the
investigation or proper administration of any matter within the
jurisdiction of any department or agency of the United States or any
case filed under title 11, or in relation to or contemplation of any
such matter or case, shall be fined under this title, imprisoned not
more than 20 years, or both."

A regulator's standard can be amended, its enforcement priorities can shift, and the regulator itself is a creature of statute that Congress could in principle alter. Title 18 does not move with any of that. It is the reason "the workpapers matched our quality manual" was never the actual bar, in any of the cases above.

Two questions to put to whatever you already use

We are not going to tell you what your current documentation vendor does or does not do. We have not audited their product and you should not accept our characterisation of a competitor's controls. Ask them directly. Two questions settle it:

1. Can a PCAOB inspector verify our archive lock without your software, and without taking our word for it? Not a report your system generates. An artifact the inspector checks independently.
2. Is the lock's time anchored to a source outside the machines we control? If the answer is the server or workstation clock, then re-read what the Board recorded above about changing computer clocks.

If you get two clear yeses, you do not need us for this, and we would rather you found that out in an email to your vendor than in a call with us. If you do not, the rest of this page is about closing that.

What ActaSeal does about it

ActaSeal sits behind the archive and turns each of those requirements into a signed record rather than a report. Concretely:

• The archive lock. Assembling an engagement for retention is recorded as an event on a hash-chained, append-only ledger, with the report release date and the resulting documentation completion date bound into what is signed. A later claim about when the engagement was locked is checkable against the chain, not against a database row that can be updated.
• Additions after the completion date, as the standard allows them. There is a dedicated path for this (POST /archive/engagements/{id}/workpapers/{id}/post-archive-addition), so a permitted addition is recorded as an addition, with who made it and when, and never as a modification of what was already there. Deletion has no path at all.
• Clock trust. The lock does not rest on the server's own clock. External RFC 3161 timestamps anchor it, so "this was locked before that date" does not depend on the machine that did the locking being honest about the time.
• Preparer, reviewer and EQR identity per workpaper, recorded at the time rather than reconstructed afterwards.
• Retention and legal hold as configuration, with the seven-year period and any hold that extends it recorded as events.
• A single inspection pack for one engagement, so what is handed to an inspector is one file rather than an export assembled by hand under time pressure.
• An offline verifier the inspector runs. This is the part that changes the conversation. The verifier is published on its own under the Apache License 2.0, every packet embeds the public key needed to check it, and no call to the firm or to us is required. An inspector can verify the chain on their own laptop, years later, having never had any relationship with either of us.

What this does not do

Stated plainly, because a page that only lists strengths is not useful to anyone doing real diligence.

• It does not prevent alteration. Anyone with sufficient access to a system can attempt to change what it holds. ActaSeal makes the attempt evident and provable to a third party. That is a different and more useful property than prevention, but it is not prevention and should not be bought as such.
• It is not endorsed, approved or accepted by the PCAOB, or by any regulator or standard-setter. No such endorsement exists for any product. Whether your documentation satisfies AS 1215 remains your firm's judgment.
• There is no SOC 2 Type II report. If your vendor qualification names one, ActaSeal does not meet that requirement today and we will confirm that in writing rather than offer a substitute.
• No audit firm is running this in production yet. The code, the tests and the standards work are real and checkable. The deployment record is not, because there isn't one. The first firms to deploy get terms that reflect that, set out on the pricing page.

How to check any of this without talking to us

Take a real signed packet and try to break it, in a browser, with nothing installed and nothing sent anywhere: verify.actaseal.com/tamper_demo/. Edit any field and the chain and the signature fail in front of you. The verifier itself, its conformance vectors and its spec-freeze guarantee are public.

For the archive lock specifically: download a sample inspection pack (fully synthetic engagement, real cryptography) plus a copy with one byte changed, and run the offline verifier against both yourself.

sales@actaseal.com