Audit-proof archiving and procedural documentation: what an auditor actually asks for
What tamper-evident really means, why no product on its own can be audit-proof, and how to write the document that describes your process: the four parts, how long it should be, and the mistakes that make it worthless.
Two phrases appear in almost every document management proposal and are almost never explained: “audit-proof” and “procedural documentation”. People nod at the first because it sounds reassuring. They assume the vendor will supply the second. Both assumptions are wrong, and both surface at the same moment: when somebody asks you to reconstruct the history of a single document.
This article explains what sits behind the two phrases, who is responsible for what, and how a usable process description looks for a company of ten people.
Note: this is general orientation, not legal or tax advice. The exact requirements depend on your jurisdiction, so check your own case with your accountant or advisor.
”Tamper-proof” does not mean nothing can change
The first misunderstanding is linguistic. Audit-proof does not mean a document can never be touched again. It means every change stays visible. The earlier version must remain identifiable, and it must always be clear who did what, and when.
This is exactly where a shared network folder fails. A file can be overwritten, renamed or deleted with no trace left behind. That in practice nobody does it is not an answer to the requirement. What is asked is that it cannot be done unnoticed.
Around this sit the other properties expected of a digital archive: completeness, meaning no missing document and none captured twice; traceability, meaning a log of who did what; availability and readability for the whole retention period; and protection against loss and unauthorised access.
Why no product alone is audit-proof
This is the sentence you should hear when buying and rarely do: compliance is a property of the procedure, not of the software. A system supplies the technical preconditions, but whether your archive holds up depends just as much on the organisation around it.
One example makes it obvious. The system logs every change, cleanly and completely. But if three people work under the same administrator login, the log only knows that “admin” did something. The technology delivered, the organisation did not.
A second one. Scanning works well and every document reaches the archive. But if nobody has defined who scans, when, and what happens to the paper afterwards, there is no evidence that the digital copy matches the original.
So when a vendor promises a “certified audit-proof” product, they are shortening the story. A certificate covers the capabilities of the software, or one specific installation at one point in time. It does not replace your own process description, nor everyday discipline.
Requirements differ by country, the principles do not
The legal frame changes with the border. Germany works from the GoBD, Italy from the digital administration code and the AgID guidelines, France from the standards on evidential value, and other countries have their own equivalents. The underlying principles, however, are remarkably stable everywhere: integrity, completeness, traceability, availability and protection. The international records management standard ISO 15489 describes the same ideas in vendor-neutral language.
Practical consequence: if you operate in more than one country, build the process once around these principles, then add the local specifics. Doing it the other way round produces one archive per country and a full-time job maintaining them.
If you want the country detail, we have written separate guides for Germany, Italy and France.
What the technology has to contribute
These are the functions to measure a system against. If one is missing, the rest gets hard.
Versioning. When someone edits a document, a new version is created and the previous one stays available. Not “the original gets overwritten, but we do have a backup”.
Activity log. Who did what and when: uploaded, opened, moved, deleted, restored, changed permissions. The log must not be quietly clearable, not even by an administrator.
Recycle bin with restore. A deleted document does not vanish instantly and permanently. It stays recoverable for a defined period.
Named users and permissions. Every person has their own login. Shared accounts make any log worthless.
Secure retention. Regular backups whose restore somebody has actually tested, and separation of data between companies.
Readability over years. Common formats, exportable, with no special software needed to open them again.
The process description: the part that is yours
The document describing how your company handles documents, from arrival to retention, is the part no vendor can write for you. They can supply the technical facts about their system. The rest describes your organisation.
It exists so that a competent outsider, in practice an auditor or inspector, can follow the path of a document without having to ask you. Where it is missing, that alone is a formal defect. How much weight it carries depends on the case, and that is precisely the discussion you do not want to be having during an audit.
The four parts
This structure works even for a ten-person company:
1. General description. What the company does, which document types arise, which systems are in use, who is responsible for what.
2. How people work. Who opens and scans incoming post, and how often. How documents are named and filed. Who approves invoices. What happens to the paper after scanning. This is the part an auditor reads first, and the part that is missing most often.
3. Technical description. Which software and version, where the data lives, how permissions are assigned, how and how often backups run, how long logs are kept. Your vendor supplies these facts.
4. Ongoing controls. How the procedure is checked in daily life: who verifies completeness, who tests a restore, how new staff are trained.
Then there is the element almost everyone forgets: a version history. The description must be dated and numbered, because for every year under review you need the version that applied back then. An undated description covers only the present, while what is needed concerns the past.
How long should it be?
For a small company ten to twenty pages are enough, provided they describe actual behaviour. A fifty-page template downloaded and never adapted is worse than five honest pages. The measure is always the same: could an outsider follow the journey of one of your invoices?
The five most common mistakes
- Shared logins. One account for several people, and the log stops meaning anything.
- The copied template. A sample is a good starting point and a poor submission. What it says has to be true.
- No date, no version. If you cannot show which procedure applied two years ago, for that year you have no documentation.
- The backup nobody restored. A copy whose recovery has never been tested is an assumption, not a guarantee.
- Two archives in parallel. Part of it in the system, part on the network drive. Completeness is gone, and nobody knows which version counts.
The Monday morning checklist
- Does every person have their own login, and has the old shared account been disabled?
- Does the system keep a log that not even an administrator can silently delete?
- Do earlier versions of a document remain available?
- Has a restore been tested in the last twelve months, with the date and result written down?
- Is there a process description, numbered and dated, that reflects what you actually do today?
- Is it defined what happens to paper after scanning?
Six questions. Answer yes to all six and the substance is in place.
What Blina Space covers
On the technical side Blina Space brings the building blocks: named users with roles and permissions, an activity log covering access and changes, earlier versions kept, a recycle bin with restore, virus scanning on every file, automatic backups, a dedicated database for each company instead of mixed data, and hosting in Germany.
What Blina Space does not do, and what nobody can credibly sell you, is write your process description. We can supply the technical facts for part three, so your advisor does not have to guess them. The account of how you work stays yours.
That is not a limitation, it is the point: compliance comes from software and organisation. Buy only one half and you do not have it.