A regulatory agency is inquiring about a case from 2011, for which the retention period still has ten years remaining. No one disputes that the data is stored somewhere. The question is how long it will take for someone to find it, read it, and verify that it has not been altered since then. In many companies, the answer is: days, sometimes weeks.
The difference between merely possessing the data and having reliable proof is the difference between a retention obligation that has been fulfilled and one that has only appeared to be fulfilled.
This article explains the difference between retention obligations and retention periods, the legal frameworks that apply in manufacturing, when retention periods ranging from 15 to 50 years apply, and how you can tell whether an obligation has actually been fulfilled or only on paper.
KEY POINTS AT A GLANCE
|
IN A NUTSHELLRetention requirements oblige companies to store certain documents and data for periods specified by law in such a way that they are retrievable, legible, and verifiably unaltered when needed. In manufacturing, this applies not only to traditional business documents but increasingly also to data from production, testing, and batch tracking—data that can make all the difference in the event of a complaint or during an audit. The obligation is only fulfilled when three things work together: retention, deletion of personal data, and proof of integrity. |
The retention period specifies how long a document or data record must be retained. The retention requirement governs what must be ensured during this time so that the period actually serves its purpose. Anyone who focuses solely on the duration overlooks these requirements.
We have compiled the specific retention periods under the German Commercial Code (HGB), the General Data Protection Regulation (GDPR), and the German Principles of Proper Bookkeeping (GoBD) into a table in a separate article: Retention Periods under the HGB, GDPR, and GoBD. The question here is: What technical and organizational measures must be in place to ensure that the retention period is effective in the event of an emergency?
| Key metric | Value | Source |
|---|---|---|
| Percentage of historical, operationally unused data in production databases | approximately 70 percent | CSP Project Experience 2025 |
| Maximum statutory retention period in security-related industries | up to 50 years | VDI/VDE 2862, industry-specific contracts |
| Search time per audit for records in the legacy system | Days to weeks | CSP project experience 2025 |
| Annual costs for continuing to operate a mainframe for inventory management | 1 to 5 million euros | CSP project experience 2025 |
The retention obligation is often viewed as merely a storage issue. However, three obligations are associated with a dataset at the same time. They are not mutually exclusive, but they do not automatically align with one another either.
Retention means: Commercial law, tax law, and industry-specific laws—such as product liability—prescribe a minimum period during which content must be available in its entirety and unaltered. Deletion means: According to Articles 5 and 17 of the GDPR, personal data may not be stored longer than necessary for the purpose for which it was collected and must be deleted upon request. Verification means: Both obligations are meaningless if compliance with them cannot be documented. An auditor rarely asks whether data has been deleted. Instead, they ask when, by whom, and whether the data record has been altered in the meantime.
Anyone who has the data but cannot locate, read, and verify it within a reasonable amount of time has not fulfilled this obligation.
In many companies, three different departments are responsible for these obligations: IT handles backup and storage, the data protection team manages deletion policies, and the audit department handles data reconstruction when a request is received. As long as these processes remain separate, every audit becomes a special project. Our article on the GDPR-compliant deletion policy for manufacturing companies demonstrates how a comprehensive deletion policy for such businesses combines the requirements of the GDPR with retention obligations.
RETENTION, DELETION, AND VERIFICATION FOR A SINGLE DATA SETThe white paper shows how you can comply with retention obligations without having to continue operating legacy systems indefinitely, and how you can respond to requests from supervisory authorities without launching a special project. |
In manufacturing companies, several families of standards converge. They vary in scope but all rely on the same data set.
| Legal Basis | Regulates | Typical Retention Period |
|---|---|---|
| Section 147 of the German Tax Code | Tax-related documents | 6 to 10 years |
| Section 257 of the German Commercial Code | Business correspondence, accounting documents | 6 to 10 years |
| GoBD | Traceability and immutability of digital books | Linked to the German Commercial Code (HGB) and the German Fiscal Code (AO) |
| GDPR Art. 5, Art. 17 | Obligation to delete personal data | Depends on the purpose; no fixed value |
| Product Liability Act | Proof of product safety | Up to 10 years; in practice, often longer |
| EU Product Liability Directive | Expanded manufacturer documentation | Longer than under previous product liability law |
| IATF 16949 | Traceability in the automotive supply chain | Customized, often exceeding 15 years |
| VDI/VDE 2862 | Documentation for safety-critical components | Up to 30 years |
The specific retention periods for each type of data are detailed in the article linked above regarding retention periods. If your company has expanded documentation requirements due to the new EU regulation, you may also find our article on the EU Product Liability Directive 2026 and manufacturer documentation helpful.
It is important to note that these legal frameworks apply concurrently. A test report may simultaneously fall under product liability law because it contains quality data, under the GoBD because it was created digitally, and under the GDPR because it contains personal data. If you consider only one of these legal bases, you will usually only partially fulfill the retention requirement, even if the specified retention period is formally observed.
A 15-year retention requirement sounds like an exception. In manufacturing, however, it’s actually the rule whenever safety-critical components are involved.
Customer contracts in the automotive supply industry often require 15 years of traceability beyond the end of production. In the aviation and medical technology sectors, retention periods can extend to 30 or 50 years in some cases due to the long service life of the end products. Liability is the underlying reason: A component can remain in use for decades, and in the event of damage, the burden of proof typically lies with the manufacturer, not the injured party.
A system designed for six or ten years of retention is therefore insufficient for safety-critical manufacturing data. Anyone who applies the retention period for standard data to safety-critical components is systematically underestimating their retention obligation.
The retention obligation cannot simply be handed off to IT. Management is legally responsible. It can delegate implementation to IT, quality management, or compliance, but not the liability itself.
This often creates a gap. IT ensures that the data is technically available but does not consider verifiability of content to be its responsibility. Quality management understands the technical requirements for traceability but rarely has access to the archive architecture. Management bears the responsibility but, in day-to-day operations, rarely sees how it is being implemented. This becomes apparent during an audit as soon as no one can provide a quick and complete answer.
Therefore, responsibility for retention obligations requires a designated body capable of making professional and technical assessments. In many companies, quality management assumes this role, working closely with IT leadership and with a clear mandate from senior management that extends beyond individual systems. Without this mandate, no one feels specifically responsible in day-to-day operations until an audit reveals the gap.
Simply having data stored somewhere is not enough. Five common findings repeatedly emerge when auditors and courts determine that a retention obligation has not been met.
Inability to locate data. The data exists, but no one can find it within a reasonable amount of time.
Lack of readability. Formats or systems are outdated, and the content is no longer technically accessible.
Lack of traceability. There is no record of when and by whom a data record was accessed or modified.
Lack of immutability. The data can be manipulated retroactively without anyone noticing.
Lack of procedural documentation. The archiving procedure itself is not documented, even though the GoBD explicitly requires it.
Our article “Maintaining Audit Trails Correctly: What Auditors Really Want to See” describes how auditors review these points and what they look at first.
When it comes to retention requirements, many people first think of invoices and contracts. In manufacturing, however, that’s only part of the picture. Process values, test reports, batch data, and operator acknowledgments are subject to the same requirements as soon as they pertain to safety-critical components or traceability requirements.
Unlike traditional business documents, this data is generated in large volumes and in a structured format. A manufacturing facility produces thousands of measurement values and test results every day. Individually, they may seem insignificant, but in the event of a complaint, they are the only basis for narrowing down the scope of the issue. If the batch reference is missing or is not linked to the component identity, a complaint that could otherwise be contained turns into a blanket recall. Our article on quality traceability—from the raw material batch to the final product—shows how to establish a seamless chain from the raw material batch to the final product.
At first glance, the retention obligation and the obligation to delete appear to contradict each other: one requires that data be retained unchanged, while the other requires that personal data be deleted upon request. Both apply simultaneously and often pertain to the same dataset, such as when an audit log contains the name of a worker.
Deleting the entire data record is rarely practical. What is practical is separating the personal and factual components. The factual portion, which is subject to the retention requirement, remains unchanged, while the personal portion is pseudonymized or removed once the retention period expires. To achieve this, the archiving system must be technically capable of implementing this separation. Simple backups are generally not capable of doing so.
An example: An inspection report records which worker performed a quality inspection on a safety-critical component. The inspection value is subject to traceability requirements and must remain unchanged for years. The worker’s name is personal data and must, in principle, be deletable as soon as the purpose no longer applies. An archiving system that only handles entire data records then leaves only two options: permanently retain the personal data or lose the factual evidence. Neither of these options complies with regulations.
When asked how companies address their retention obligations from an organizational standpoint, you usually hear one of four answers. These answers generally do not solve the problem.
A backup protects against data loss but does not fulfill any of the three obligations outlined in the section above. Backups are not designed to locate specific transactions, and they do not log accesses. Our article “Backup Is Data Protection; Archiving Is Corporate Protection” explains the difference.
Keeping a legacy system running solely because of data subject to retention requirements incurs costs for licenses, maintenance, operation, and increasingly rare specialized knowledge. This often continues for years, even after the system has long since ceased to be needed for operational purposes. The longer this continues, the more difficult it becomes to replace the system later on, because knowledge of the evolving system landscape is lost with every staff change.
A traditional document management system is designed for unstructured documents. When it comes to structured bulk data from production—such as process data and test data—it quickly reaches its limits. Thousands of measurement values per shift cannot be stored in it in a meaningful way, nor can they be searched quickly enough when a batch reference is needed on short notice in the event of a complaint.
An in-house development It permanently locks in internal expertise and must be maintained for decades, even as formats, interfaces, and the legal landscape change. What initially appears to be a tailor-made solution often becomes a legacy system itself within 15 or 30 years. Added to this is the risk that the original developers have long since left the company.
Before you implement a tool for compliance with retention requirements, you should evaluate it against a set of criteria. These eight requirements have proven to be crucial in practice.
| Requirement | Evaluation Question |
|---|---|
| Retention Policy | Can retention periods be set individually for each data type? |
| Immutability | Is subsequent manipulation technically impossible? |
| Access Log | Is every access logged with a timestamp and the user’s name? |
| Separability | Can personal data be separated from factual data? |
| System Independence | Will the data remain readable even after the source system is shut down? |
| Quick Search | Can a single transaction be found in minutes rather than days? |
| Process Documentation | Is the archiving process itself documented in accordance with GoBD? |
| Scalability | Can the solution handle multiple legacy systems and growing volumes? |
Our article “How to Choose Audit-Compliant Archiving Software” explains how to select audit-compliant archiving software based on these criteria.
These costs rarely become apparent immediately; instead, they usually emerge later—and then quite significantly.
First, continuing to operate legacy systems that merely store data often costs money for years on end. Licenses, maintenance, operation, and hardware for a system that is no longer needed for operations add up over the remaining term of the retention period to substantial amounts that are out of proportion to the value of the data.
Second, there are costs that aren’t immediately apparent and that can compromise compliance in the event of an incident. If a request from a regulatory authority or a complaint is received, an investigation across multiple systems and data exports begins—a process that can take days or even weeks instead of minutes. It ties up staff from IT, quality management, and the legal department simultaneously and delays the response, even though authorities and courts typically set tight deadlines for such matters.
Third, there remains the risk of liability if, in the event of a dispute, an obligation is deemed not to have been fulfilled. In manufacturing, there is a fourth effect that is often underestimated: If the scope of a complaint cannot be narrowed down due to a lack of batch references, a limited incident turns into a blanket recall, which costs correspondingly more. Our article on the costs of failing to comply with retention obligations and the associated liability risk provides specific figures regarding these costs.
In Manufacturing OS, multiple components jointly fulfill the retention obligations based on a shared database. CHRONOS handles audit-proof long-term archiving with retention policies, access logs, and data immutability—even after the original source system has been decommissioned. IPM links process data to the component identity from the moment it is captured, ensuring that the origin of every archived value remains traceable. QST generates test records directly within the structure that will later be queried during an audit, so that no one has to search for them retroactively.
Since all components run on the same platform, there is no need for integration between a separate archiving solution and the production systems. This reduces the time from a request to a verifiable response from days to minutes, whether it involves a ten-year-old document or a test value from ongoing production.
Record retention requirements oblige companies to retain certain documents and data for periods prescribed by law in such a way that they remain retrievable, legible, and, if necessary, verifiably unchanged. This obligation arises from several legal sources simultaneously, such as tax law, commercial law, and industry-specific standards.
The retention period specifies the length of time for which data must be retained. The retention obligation additionally requires that this data remain retrievable, legible, and verifiably unaltered throughout the entire period.
In particular, data on safety-critical components in the automotive supply chain, aviation, and medical technology are often subject to retention periods of 15 to 50 years, as the burden of proof in the event of a claim typically lies with the manufacturer.
Yes. Process values, test reports, and batch data are subject to the same retention requirements as traditional business records as soon as they are relevant to traceability or product liability.
No. A backup protects against data loss, but it does not allow for the targeted retrieval of individual transactions, nor does it document an access history that would prove the data’s integrity in the event of a dispute.
Yes, provided that the data subject to retention requirements has been archived independently of the system beforehand and remains retrievable, readable, and verifiably unaltered even without the original source system.
Both obligations apply simultaneously. In practice, the personal and non-personal components of a data record are separated so that the portion subject to retention requirements is preserved, while the personal components can be removed within the prescribed timeframe.
Depending on the legal basis, a violation can result in fines, a burden of proof disadvantage in liability cases, or the non-recognition of documents during tax audits. In manufacturing, there is the added risk of a blanket recall rather than a targeted one.
GET THE DATA GOVERNANCE WHITE PAPERThe white paper shows how you can consolidate retention, deletion, and proof requirements for a single dataset and respond to inquiries from regulatory authorities without launching a special project. We’ll then demonstrate live how CHRONOS implements this with your own datasets. |