Three vendors, three presentations, and the phrase “audit-proof” appearing three times on the first slide. Add to that certificate logos, lists of references, and the promise to meet all legal requirements. This is what a typical selection process for audit-proof archiving software looks like. And this is exactly where the problem begins.
After all, “audit-proof” is not a protected product feature. No law defines which software is allowed to bear this label, and no government agency issues a certification for it. The GoBD explicitly makes the compliance of electronic record retention contingent on the interaction between software, configuration, processes, and procedural documentation. Software can enable audit-proof archiving. It cannot guarantee it.
In selection projects involving IT managers and compliance officers from manufacturing, medical technology, and mechanical engineering, the same pattern emerges time and again: Decisions are made based on certification logos and license prices. The questions that actually matter during an audit or in the event of liability claims do not even appear in the requirements specification. Who will be able to read the data in 15 years when the manufacturer discontinues support? Can the business department access the data without an IT ticket? Can the legacy system truly be shut down after migration?
This article provides a checklist for selection: 12 criteria against which software for audit-proof archiving must be evaluated, the 5 most common selection mistakes, and an honest assessment of the costs.
THE MOST IMPORTANT POINTS AT A GLANCE
|
IN A NUTSHELL
|
Why Software Alone Cannot Guarantee Audit-Traceable Archiving
The market suggests that audit compliance can be bought, installed, and checked off the list. Legally, that doesn’t work, and anyone who bases the selection process on this assumption is looking at the wrong things.
The GoBD guidelines are decisive, as specified in the BMF letter dated November 28, 2019. They link the compliance of electronic storage not to a specific product, but to the overall process: How is the data generated, how is it indexed, stored, protected against alteration, and retrieved throughout the entire retention period? This is precisely what the procedural documentation must describe in a comprehensible manner, in accordance with GoBD Marginal Note 151 et seq. If this documentation is missing or outdated, the accounting records may be formally challenged, regardless of how good the software used is.
Software certifications in accordance with IDW PS 880 are common: An auditor certifies that a product can meet the requirements when used properly. This is a useful indicator in the selection process, but it is not a free pass. The certification evaluates the product in its default state, not your configuration, your processes, or your documentation.
| Evidence | What it verifies | What it does not prove |
|---|---|---|
| Software Certification (IDW PS 880) | The product can meet the requirements when used properly | That your specific operations, configuration, and processes are in order |
| Manufacturer’s claim: “audit-proof” | A marketing claim without a legally defined basis | Anything. The term is not protected and is not officially granted |
| Procedural documentation (GoBD Margin No. 151 et seq.) | The traceable end-to-end process from data creation to retrieval | It must be maintained. Outdated documentation is almost as critical during an audit as missing documentation |
In tax audits, the procedural documentation is regularly requested first, not the certificate. And the retention periods set the standard for software selection: Tax-relevant data must be retained for ten years under §147 of the German Fiscal Code (AO), payroll records for up to 30 years depending on the category, and quality data in the automotive industry for at least 15 years under IATF 16949 Section 7.5. Your archiving software must support a process that survives multiple generations of hardware, system changes, and likely one or two vendor changes as well.
When making your selection, this means: Don’t just check whether a provider uses the term “audit-proof.” Check whether the software can support the process that you are required to document.
Software for Audit-Traceable Archiving: The 12 Selection Criteria
A robust set of specifications distinguishes between three levels: legal criteria that determine auditability, technical criteria that determine usability in everyday operations and long-term readability, and economic criteria that determine total costs. The following matrix contains the key questions for each criterion that you should ask every vendor in writing.
| No. / Criterion | Why it is crucial | Question to Ask the Provider |
|---|---|---|
| 1 · Immutability (legal) | GoBD and HGB §257 require that archived data cannot be altered or deleted without being noticed | How is immutability technically enforced, and can this protection be circumvented administratively? |
| 2 · Complete Logging (legal) | Without an audit trail, it is not possible to prove integrity in the event of an audit | Is every operation logged with the user, timestamp, and content, and is the log itself tamper-proof? |
| 3 · Retention periods and proof of deletion (legal) | GDPR Articles 5 and 17 require the deletion of personal data once the purpose no longer applies, including proof of deletion. Violations can result in fines of up to 4% of annual revenue or 20 million euros | Can retention and deletion rules be defined for each data category, and does the deletion process generate verifiable proof? |
| 4 · Completeness and Analyzability (Legal) | The GoBD requires complete and machine-readable storage, not just filing | How is the completeness of the transfer verified, and does the data remain structured and analyzable? |
| 5 · Open, documented archive format (technical) | Retention periods of 10 to 30 years outlast software products. Proprietary formats render data unreadable once support ends | Is the archived data fully readable without your software, and is the format disclosed? |
| 6 · Vendor independence (technical) | Source systems change. Archiving must not be tied to a specific database or ERP system | Which source systems are supported: Oracle, SAP, MS SQL, cloud, on-premise? |
| 7 · Searching without an IT ticket (technical) | If every access request goes through IT, the archive won’t be used in day-to-day operations and will become a bottleneck during audits | Can business departments perform searches independently and based on their roles? |
| 8 · Scalability and Performance (technical) | Studies show that over 80% of the data in production databases is inactive. The archive must be able to accommodate this volume on an ongoing basis | How does search speed hold up as the archive grows over the years? |
| 9 · Interfaces and Automation (Technical) | Archiving must be rule-based, not a manual ad-hoc process | What interfaces are available, and can archiving runs be automated based on rules? |
| 10 · Application Retirement (Business) | Legacy systems that remain in operation solely for data access incur costs for licenses, maintenance, and security | Can the entire data set of a legacy system be migrated so that the system can be decommissioned? |
| 11 · Migration Effort and Project Duration (Economic) | An archiving project that ties up IT resources for months eats into the savings | How long does a typical project take, and what internal resources are required? |
| 12 · Operating Costs and Maintenance (Economic) | The solution will run for decades. Ongoing costs outweigh any one-time cost savings | What costs are incurred during operation: maintenance, storage, administration, updates? |
The rule of thumb for weighting: Criterion 5 is the deal-breaker. If the archived data can only be read using the provider’s software, you’re simply trading dependence on the legacy system for dependence on the archive vendor. That’s not a solution—it’s just a shift.
WHEN SOFTWARE CAN BE OPERATED IN AN AUDIT-PROOF MANNER
|
The 5 Most Common Mistakes When Selecting Archiving Software
Most mistakes aren’t related to the technology itself, but rather to the selection process. Five common patterns keep cropping up in practice.
Mistake 1: The Certificate Replaces the Requirements Specification
A vendor submits a certificate, and the individual criteria are not reviewed. As shown above, a certificate issued in accordance with IDW PS 880 certifies the product, not your company. It replaces neither the 12 evaluation questions nor the procedural documentation. Treat the certificate as a ticket to the selection round, not as the outcome of that round.
Mistake 2: Confusing backup with archiving
The classic mistake: There is a functioning data backup, so the issue seems to be resolved. A backup is intended for recovery after data loss and is typically overwritten after 30 to 90 days. It is modifiable, not logged, and not designed for targeted individual access over a 10-year period. The article on the costs of non-archiving details exactly how much this difference costs in the event of a liability claim.
Mistake 3: Proprietary archive format
This is the most expensive mistake because its consequences only become apparent years later. The data is properly archived, but the manufacturer discontinues the product, is acquired by another company, or changes its licensing model. After a retention period of 10 to 25 years, there is a high probability that at least one of these events will occur. Without an open format, you will then face a second migration—under time pressure and with no alternative.
Mistake 4: The business department is not involved in the selection process
IT makes the selection, but the work is done in Quality Assurance, Controlling, and Purchasing. If no one there can conduct independent research, every regulatory inquiry, every audit preparation, and every complaint will end up as an IT ticket in the future. This wastes time in both departments and turns the archive into an unwelcome exception in day-to-day operations.
Mistake 5: Application retirement is not taken into account
Many archiving projects are launched because of a specific legacy system, but they only address the data issue and allow the system to continue running for compliance reasons. As a result, licensing, maintenance, and infrastructure costs persist, along with the security risk posed by unpatched software. Those who define system decommissioning as a project goal from the outset will leverage the greatest cost-saving potential of the entire investment.
The Cost of Software for Audit-Compliant Archiving
There are no standard flat rates, as costs depend on data volume, the number of source systems, and the scope of the migration. What can always be specified, however, is the structure: three cost categories on one side, three cost-saving measures on the other.
On the cost side are the implementation project (analysis, migration, testing, procedural documentation), the license, and ongoing operations (maintenance, storage, administration). With CHRONOS, project implementation typically takes 6 to 12 weeks, depending on the scope of the system, and the existing infrastructure generally does not need to be modified.
COMMONLY UNDERESTIMATED COST FACTORS
|
Three factors drive cost savings. First: Smaller production databases. Since over 80% of the data in typical databases is inactive, storage costs and recovery times decrease noticeably after offloading. Second: Decommissioned legacy systems completely eliminate license, maintenance, and infrastructure costs. Third: The IT department is relieved of the burden because business departments can conduct their own research. In CHRONOS customer projects, these effects add up to an ROI of over 300%, which is usually achieved after just a few months.
So the honest calculation isn’t “How much does the license cost?” but rather “How much does the current situation cost per year, and how much of that will be eliminated after the project?” For companies with active legacy systems, this calculation almost always favors archiving.
CHRONOS: Audit-compliant archiving in the Manufacturing OS
How are these 12 criteria implemented in a specific product? CHRONOS is the archiving module in the Manufacturing OS from CSP Intelligence GmbH. The Manufacturing OS also bundles the IPM module for process data management, the PG module for operator guidance, and the QST module for tool inspection; within this system, CHRONOS handles audit-proof long-term archiving and the decommissioning of legacy systems.
CHRONOS identifies inactive data based on rules, converts it into an open, long-term-secure format, and transfers it to storage systems. This makes the production databases smaller and faster. Application Retirement allows the entire database of a legacy system to be migrated, enabling the application to be completely decommissioned. Business departments can perform role-based searches without an IT ticket, regardless of whether the source was Oracle, SAP, or MS SQL, and whether the environment runs in the cloud or on-premises.
PRACTICAL TIP FROM CHRONOS
|
An example from the medical technology sector: The KLS Martin Group, a manufacturer of surgical instruments and implant systems, was faced with a fragmented archiving landscape and growing data volumes following several corporate mergers. Since 2021, the company has been using CHRONOS for archiving: Data from legacy systems is available in an open format in an audit-compliant manner, the software landscape has been consolidated, and all legal requirements are fully met.
“Our collaboration with CSP is going exceptionally well. Deadlines are met, and everything runs smoothly.”
— Wojciech Wypior, Head of Business Applications, KLS Martin Group
Frequently Asked Questions About Software for Audit-Traceable Archiving
What software is suitable for audit-compliant archiving?
Suitable software is that which technically enforces data immutability, comprehensively logs every operation, manages retention and deletion periods for each data category, and stores data in an open, documented format. It is also crucial that archived data remains readable without the manufacturer’s software and without the source system. Audit compliance is achieved only through the interaction of software, configuration, and procedural documentation in accordance with GoBD. A product name or a certificate alone is not sufficient proof.
Is there an official certification for audit-compliant archiving software?
No. No government agency issues a legal seal of approval for audit compliance, and the term is not legally protected. Software certifications in accordance with IDW PS 880 are common: an auditor certifies that a product can meet the requirements when used properly. This certification evaluates the product itself, not its specific implementation within the company. For the purposes of providing evidence during an audit, the procedural documentation in accordance with GoBD Marginal Note 151 et seq. remains decisive.
Is a document management system automatically audit-proof?
No. A document management system organizes documents and workflows, but does not automatically guarantee immutability, complete logging, and long-term readability over 10 to 30 years. Many systems can be configured to be audit-proof, but they are not in their default state. Furthermore, they often do not cover structured data from databases and legacy systems. Specialized archiving software is required for database archiving and application retirement.
Does a backup meet the requirements for audit-proof archiving?
No. A backup is intended for recovery after data loss and is typically overwritten after 30 to 90 days. It is modifiable, not logged, and not designed for targeted individual access beyond the statutory retention periods of 6 to 10 years. The GoBD requires storage that is unalterable, complete, and machine-readable. Structurally, a backup does not meet these requirements, regardless of its technical quality.
How much does software for audit-compliant archiving cost?
The costs depend on the data volume, the number of source systems, and the scope of migration; there are no reliable flat rates. In addition to the license fee, there are costs for the implementation project, process documentation, and ongoing operation. These costs are offset by savings: smaller production databases, lower storage costs, and legacy systems that can be completely decommissioned. In CHRONOS customer projects, the ROI exceeds 300%, and project implementation typically takes 6 to 12 weeks.
Can legacy systems be completely decommissioned using archiving software?
Yes, if the software supports Application Retirement. In this process, the entire data set of a legacy system is converted to an open format, archived in an audit-proof manner, and kept searchable. The legacy system can then be taken out of service, and license, maintenance, and infrastructure costs are eliminated entirely. A prerequisite is that all data subject to retention requirements—including context and metadata—is transferred and that the retrieval process is documented.
