Audit-proof archiving: what this means in practice

THE MOST IMPORTANT POINTS IN BRIEF Audit-proof archiving means that stored data is complete, unalterable, retrievable and readable for the entire legal retention period - even without the original software with which it was created. The four core requirements for audit-proof production data: Immutability (no overwriting without proof), completeness (all prescribed data is available), findability (targeted retrieval without specialist IT knowledge) and readability (open format that can still be interpreted in 15-25 years' time). At least four legal frameworks apply simultaneously in production: IATF 16949 (at least 15 years of quality data), GoBD (10 years of tax-relevant data), ISO 9001 (contractually defined) and EU Product Liability Directive 2024 (up to 25 years for latent damage). The most common mistake: production data is stored in a proprietary database that cannot be read without the original software. After a system replacement, the data is available - but no longer accessible. Audit security is not a software property. It is an architectural decision: Which format, which structure, which access control and which integrity protection are built in from the outset?

BRIEFLY SUMMARIZED 'Audit-proof' and 'archived' are not the same thing. Archived means: stored. Audit-proof means: verifiable, unalterable, retrievable and permanently readable. The most important question is not "Do we have the data?" but "Can an auditor access a specific component file in 10 years' time without IT assistance? GoBD, IATF 16949, ISO 9001 and the EU Product Liability Directive 2024 have different requirements - but all demand the same core principle: protection against manipulation and retrievability over the entire period. Audit-proof databases in production need four building blocks: Audit trail, timestamp synchronization, open export formats and role-based access control. → Download the whitepaper for free: Standard requirements, format comparison and audit-proof archiving checklist

CONTENT OF THIS ARTICLE Definition: What audit-proof archiving really means Which standards and laws apply - and what they specifically require Which production data must be archived in an audit-proof manner The 4 technical building blocks of an audit-proof database Audit-proof formats: What is suitable and what is not The 5 most common gaps in practice - and how to close them Practical test: Is your archiving audit-proof? Frequently asked questions

 

Standard/law	Data category	Deadline	Archive format	Sanction for non-compliance
IATF 16949:2016	Quality data: Test results, approvals, batch data, production parameters, audit logs	At least 15 years after last delivery (OEM requirements may be longer)	Auditable, structured retrievable - format not explicitly prescribed	Certificate withdrawal, OEM list risk
GoBD (BMF 2019)	Tax-relevant records: Bookings, receipts, relevant business letters	10 years (Section 147 AO), from the end of the calendar year	Automatically analyzable, unalterable, readable at any time - GOBD-compliant format	Additional tax payments, fines, criminal proceedings in the event of intent
ISO 9001:2015	Records of quality processes, management assessments, supplier qualification	Depending on customer requirements - typically 5-15 years	Legible, structured, traceable and retrievable	Certificate withdrawal, contractual penalties per customer agreement
EU Product Liability Directive 2024/2853/EU	Production data as exculpatory evidence: component-specific process data, test results	Up to 25 years for latent damage (from placing on the market)	It must be possible to reconstruct component-specific allocation - structured data archiving	Unlimited product liability without proof of exoneration, reversal of burden of proof
GDPR (EU 2016/679)	Personal data: Worker IDs, user logs, biometric access controls	Only as long as processing purpose exists - deletion obligation thereafter	Verifiable deletion with log	Fines of up to 4% of global annual turnover

Data category	Examples	Archiving obligation	Max. Period	Audit compliance required?
Test results & proof of quality	Measurement reports, SPC data, release decisions, use of test equipment	IATF 16949, ISO 9001, EU product liability	25 years (EU product liability)	Yes - mandatory
Batch data & traceability data	Lot numbers, serial numbers, material batch allocation, supplier data	IATF 16949, EU product liability	25 years	Yes - mandatory
Production parameters & process data	Torque curves, temperature profiles, machine configurations	EU product liability (proof of discharge), IATF 16949	25 years	Yes - for safety-relevant processes
Calibration & test equipment data	Calibration protocols, measuring equipment IDs, validity periods	IATF 16949 §7.1.5	15 years	Yes
Audit logs & system accesses	Who changed what and when, system accesses, change histories	GoBD, IATF 16949 (record integrity)	10 years	Yes - this is the audit trail itself
Tax-relevant production data	Production costs, post-calculation, material write-offs	GoBD § 147 AO	10 years	Yes - GoBS-compliant
Personal user logs	Worker IDs, shift logs with personal identification	DSGVO - obligation to delete!	Max. Processing purpose	Pseudonymization recommended
Internal work instructions & procedures	Current and historical versions of work instructions	ISO 9001 §7.5 (Documented information)	Per customer requirement	Proof of versioning required

 

The 4 technical building blocks of an audit-proof database in production

Revision security is not a function that can simply be activated in an existing database. It is the result of four technical architectural decisions that must be made from the outset - or that can be implemented subsequently through targeted expansion.

 

Building block 1: Audit trail - seamless change history

An audit trail (change log) documents every write operation on a data record: who changed what and when - with user ID, time stamp and old and new value. It is the technical basis for proving immutability.

In an audit-proof database for production data, this means that every change to a test result, every subsequent release and every parameter correction is recorded in the audit trail and cannot be deleted retroactively. The original entry is always retained - visible and traceable.

 

REQUIREMENTS FOR THE AUDIT TRAIL IN PRODUCTION

Timestamp: UTC-based, synchronized with external time server (NTP) - no local system time

User ID: Personal or uniquely assignable identifier - no group accounts

Change type: What was changed (insert, change, delete) and in which field

Old and new value: Both values must be retained - not just the current one

Immutability of the audit trail itself: The log must not be editable

 

Building block 2: Timestamp integrity - synchronized and tamper-proof

Timestamps in production data fulfill a dual function: they prove the exact time at which a data record was recorded - and thus its assignment to a specific production process. A timestamp that originates from the local system time of a non-synchronized computer is worthless as proof.

Audit-proof time stamps fulfill three requirements: They are UTC-based and synchronized with an external time server (NTP), they are frozen when recorded (cannot be subsequently changed), and they are cryptographically secured or protected against manipulation in a blockchain-like structure.

 

Module 3: Role-based access control with dual control principle

In an audit-proof archiving structure, not everyone is authorized to do everything. Read access, write access and delete access to archived production data are strictly separated - with logged proof of every access operation.

The dual control principle is particularly mandatory for security-relevant changes to archived data: a subsequent correction of a test result (e.g. after the discovery of a measurement error) may only be made with a second, independent approval - and must be fully documented in the audit trail.

 

Building block 4: Integrity through checksums and cryptographic signatures

Checksums (hashes) ensure the integrity of archived files: A hash value (SHA-256 or better) is calculated for each archived file or data record at the time of archiving. If the content of the file is subsequently changed - including through bit red on the storage hardware - the new hash calculation results in a different value. The manipulation or damage is immediately recognizable.

Cryptographic signatures go one step further: they link the content of a file not only to a point in time, but also to a person or a system. A digitally signed component file not only proves that it has not been changed, but also who released it and when.

 

 

Audit-proof formats: What is suitable for production data - and what is not

The archive format is the most frequently underestimated archiving decision. It determines whether data can still be read in 15 or 25 years' time - without the original software, which may no longer exist.

Practical recommendation: The operational production database runs in a relational database with a complete audit trail. For long-term archiving, data is exported periodically (daily, weekly) in audit-proof formats: Reports and logs as PDF/A, raw data as CSV with schema documentation. All export files are given SHA-256 checksums.

 

The 5 most common gaps in practice - and how to close them

In practice, we find these five gaps in manufacturing companies that are considered to be well documented in terms of auditing - but on closer inspection do not have audit-proof archiving.

 

Gap 1: Database without audit trail

The most common problem: The production database stores measured values and test results - but there is no audit trail. If a test result is subsequently changed (for whatever reason), the change is not logged. The current value is in the system. The original value is gone.

This is a critical finding in an IATF audit. In product liability proceedings, it is an evidentiary disadvantage: if changes are possible without proof, then the judge cannot rule out the possibility that relevant data has been subsequently adjusted.

Solution: Activate the audit trail - in most common database systems (PostgreSQL, SQL Server, Oracle) this is a configuration decision, not a new development. Subsequent activation protects from the time of activation - historical data without an audit trail remains a risk.

 

Gap 2: Archiving in the operational database

Many companies do not archive at all - they simply leave the data in the operational database. This is not an archive. An operational database is optimized for access performance, not for long-term stability. Database migrations, software updates and system reinstallations can change or render inaccessible operational databases.

Solution: Structured archiving process with a separate archive system: Operational data is periodically transferred to a separate, long-term stable archive system. The archive system is read-only - no write operations after the archiving time.

 

Gap 3: Missing component binding in archived test logs

Test reports are archived as PDFs - but without a clear component reference. The report contains the date, the batch and the measured values. However, there is no link to the specific serial number of the component. In the audit, it is not possible to prove to which specific component the report belongs.

This is not a format problem - it is a database structure problem. The component reference must be entered as a mandatory field during data entry, not during the archiving export.

Solution: All archived test documents must contain the unique component key (serial number or batch number) as a structured metadata field - not only in the file name, but also in the document content and in the archive database as a searchable index field.

 

Gap 4: Time stamps not synchronized between systems

Machine control, MES and QMS record time stamps with different local system clocks. If these clocks are not synchronized, time deviations of seconds to minutes occur between data records that document the same production process. A causal link is therefore no longer clearly possible.

Solution: Cross-system NTP synchronization. All systems that record production data synchronize their system time with the same NTP server. Time deviation < 1 second as standard. Documented and regularly checked.

 

Gap 5: Archive periods without data category differentiation

The company has an archiving policy - 'all data is stored for 10 years'. This blanket rule is sufficient for GoBD, but not for IATF 16949 (15 years) or EU product liability (25 years for latent damage). If data is deleted after 10 years, IATF-relevant quality data is no longer available.

Solution: Retention periods are defined per data category, not across the board for all data. The database architecture supports category-specific deletion locks: quality data is not deleted before the category-specific deadline has expired.

 

Practical test: Is your archiving audit-proof?

This test simulates the three situations in which audit-proof archiving is put to the test in practice: IATF audit, product liability case and official inquiry. Answer the questions for your actual archiving infrastructure - not for the desired one.

Can an auditor access a component file without IT assistance?

Imagine an IATF auditor sitting in front of your archive and asking for the complete component file for serial number XY-2021-003847 from the year 2022. Without your IT, without your database administrator.

Is there a structured index system that enables a targeted search by serial number or batch number?
✓ YES: The auditor finds the component file in under 3 minutes. Audit-proof archiving fulfilled.
✗ NO: IT escalation necessary. A yellow mark in the audit. A considerable risk in a legal dispute.

Are all documents in the component file saved in PDF/A format or as a structured CSV/XML export?
✓ YES: Format is future-proof and tamper-proof. All documents in a readable viewer.
✗ NO: Proprietary formats or Excel files. May no longer be readable in 10 years.

Does the archive contain a verifiable timestamp and a user ID of the archiving person for each entry?
✓ YES: Complete proof: Who archived what and when. Complete auditability.
✗ NO: No user IDs, no timestamps. No way to prove that data was not created retrospectively.

Can you provide proof of exoneration in a product liability case?

A court requires proof that component XY-2021-003847 fulfilled all test requirements at the time of delivery. The testing process took place four years ago.

Are the process parameters of the manufacturing process (torque, temperature, machine configuration) archived with component accuracy?
✓ YES: Proof of discharge possible: The component was demonstrably in order at the time of delivery.
NO: No process parameters archived. Proof of discharge cannot be provided. Liability risk.

Does the archive have an unalterable audit trail that demonstrably excludes subsequent manipulation?
✓ YES: Data is demonstrably original. No accusation of manipulation tenable.
NO: No audit trail. A court cannot rule out the possibility that data has been subsequently adjusted.

 

Frequently asked questions about audit-proof archiving in production