An auditor is sitting across from you. He asks for the test data record for a batch that was shipped seven years ago.
The software that generated this record has long since been replaced by a newer version. The employee who was responsible for the process is no longer with the company. None of your current applications can open the file format used back then.
You have the data. Somewhere. On a network drive, in a deprecated database, in a backup that no one has tested in years.
The auditor’s question is simple. The answer is not.
This is exactly where the true demands of software in medical technology become apparent. The real problem isn’t developing a compliant application, but being able to demonstrate—throughout its entire lifecycle—what it did, when it did it, and with what results. This article explains why verification—rather than functionality—becomes the critical bottleneck, which standards set the framework, and how audit-proof data management turns a compliance risk into a predictable process.
KEY POINTS AT A GLANCE
|
IN A NUTSHELLSoftware in medical technology is not only a development task but, above all, a documentation task. Regulatory requirements mandate that process data, test results, and configuration statuses remain complete, unalterable, and readable over very long periods of time. In practice, audits rarely fail due to an application’s functionality, but rather due to gaps in traceability and data trapped in discontinued systems or outdated formats. Those who decouple data management from the lifecycle of individual software generations significantly reduce their audit risk. Audit-compliant archiving is the central component of this approach. |
What does software mean in medical technology?
“Medical technology software” is an ambiguous term, and both meanings are relevant from a regulatory perspective.
On the one hand, there is software that is itself a medical device or part of one: embedded control systems, diagnostic applications, and Software as a Medical Device (SaMD). On the other hand, there is software that manufactures, tests, and documents medical devices: process data management, operator guidance, quality assurance, and archiving.
Both categories share the same fundamental responsibility. They generate data that serves as evidence. And strict rules apply to this evidence.
Control software used in production is not, strictly speaking, a medical device. However, the test reports it generates are part of the technical documentation. If this documentation is missing, the finished product can no longer be proven to be compliant, regardless of how well the software itself performed.
Software in medical technology is therefore less a question of function than a question of documentation.
Why the traditional development focus falls short
Most organizations focus their attention on development. This is understandable, but it’s not the whole picture.
Validation, verification, risk analysis: These steps focus on the time of release. They answer the question of whether software works correctly today. They do not answer the question of whether this can still be proven ten years from now.
The regulatory lifecycle of a medical device does not end with delivery. That is only where it begins.
| Traditional Focus | Regulatory reality |
|---|---|
| Does the software work today? | Can its functionality be demonstrated over the years? |
| Validation at the time of release | Documentation throughout the entire product lifecycle |
| Documentation as Project Closure | Documentation as an ongoing task |
| Data resides in the live system | Data must survive system changes |
| Responsibility lies with the development team | Responsibility lies with Quality, Regulatory, and Management |
Discontinuities rarely occur at the time of release. They arise later, when systems are discontinued, formats are replaced, and personnel are reassigned—yet the obligation to maintain records continues unchanged.
Software that can no longer document its own history is of no regulatory value—no matter how well it works today.
- Korbinian Hermann, CSP Intelligence GmbH
The Real Bottleneck: Traceability Over the Years
This is the crux of the matter. The crucial question is not whether your software is compliant, but whether you will still be able to demonstrate that compliance in five, ten, or fifteen years.
The MDR requires that technical documentation remain available for an extended period—typically at least ten years after the last product was placed on the market, and at least fifteen years for implantable devices. This timeframe outlasts nearly every software generation, every hardware upgrade, and often even the supplier of the original application.
The real problem is not the generation of the data, but rather its preservation beyond the lifespan of the systems that generated it.
In practice, this means that data must not be trapped within the active system. It must remain readable, complete, and unalterable, independent of the application that originally generated it.
Anyone who fails to implement this separation ties their ability to provide evidence to the lifespan of individual software products—and that lifespan is significantly shorter than any regulatory retention period.
How regulated software documentation works in practice
The framework is established by the interplay of several standards and regulations. None of them stands alone.
| Standard / Regulation | Focus | Relevance to Software and Data |
|---|---|---|
| MDR (EU 2017/745) | Market access for medical devices | Requires technical documentation and its long-term availability |
| IEC 62304 | Software Lifecycle for Medical Devices | Defines processes for development, maintenance, and configuration management |
| ISO 13485 | Quality management for medical devices | Requires controllable, traceable records |
| ISO 14971 | Risk management | Links risks to measures and their verification |
| 21 CFR Part 11 (FDA) | Electronic records and signatures | Standard for audit trails and data integrity (U.S. market) |
Above all individual rules lies a common principle: data integrity. The ALCOA criteria serve as an established standard for this. Data should be attributable, legible, timely, authentic, and accurate. In its expanded form, the criteria also include completeness, consistency, permanence, and availability.
These criteria are not just theory. They are the checklist an auditor uses to review your records.
| Poor Practice | Good practice |
|---|---|
| Data stored in shared folders without an access log | Accesses and changes fully logged |
| Values can be overwritten retroactively | Immutable record with version history |
| Proprietary format with no migration path | Long-term stable, readable formats |
| Backup without a restore test | Verified, documented recoverability |
| Retention linked to system lifespan | Retention organized independently of the system |
Four Phases to Audit-Ready Data Management
Audit readiness is not achieved through a single tool. It is achieved through a structured process.
| Phase | Goal | Result |
|---|---|---|
| 1. Assessment | Identify data sources and record-keeping requirements | Complete overview of data subject to retention requirements |
| 2. Classification | Assigning retention periods, criticality, and formats | Clear rules regarding what is retained, for how long, and in what format |
| 3. Migration | Transferring data to a system-independent archiving solution | Tamper-proof, readable long-term storage |
| 4. Operation and Audit | Ensuring access, integrity, and recovery | A verifiable, auditable data set at all times |
Phase 1 is most often underestimated. Many organizations do not know precisely which data they are actually required to retain and which data they have long since been unable to read.
Phase 3 is the real game-changer. Only when data leaves the system that generated it and is stored in a dedicated archiving system is its auditability decoupled from the software.
Common Mistakes and How to Avoid Them
Most problems aren’t spectacular. They’re structural—and that’s exactly why they’re dangerous.
| Mistakes | What Happens | Risk | Better Approach |
|---|---|---|---|
| Backup is confused with archiving | Data exists, but it is modifiable and unstructured | No reliable evidence available during an audit | Establish an audit-proof, immutable storage system |
| Data remains in the source system | Evidence is lost when the system is discontinued | Data loss during migration or system decommissioning | Early transfer to a system-independent archive |
| Proprietary formats with no migration path | Data becomes unreadable over time | Available, but unusable | Long-term stable formats and verified migration |
| No continuous audit trail | Changes cannot be traced | Breach of data integrity | Seamless logging of all accesses |
| Retention periods not clearly defined | Data is deleted too early or hoarded without oversight | Violation of the obligation to provide evidence | Classification with clearly defined retention periods |
The common thread: Each of these errors merely postpones the problem. It only becomes apparent during the audit—precisely when there is no longer any time left to make corrections.
Case Study: A Mid-Sized Medical Technology Supplier
A mid-sized supplier manufactures components for implantable products. The retention requirement is correspondingly long—fifteen years after the last shipment.
The initial situation was typical of an organically grown environment.
| Area | Initial Situation |
|---|---|
| Test Data | Spread across three systems and multiple network drives |
| Formats | Partly proprietary, generated using discontinued software |
| Retention | Linked to the lifespan of the respective application |
| Audit Trail | Only partially available |
| Recovery | Backups available, but never systematically tested |
During the preparatory audit, the crucial question arose: Who recorded a specific value and when, and has it remained unchanged since then? The supplier could not prove this beyond a doubt.
The data was there. The proof was missing.
After switching to a system-independent, audit-proof archiving solution, the situation changed fundamentally.
| Criterion | Before | After |
|---|---|---|
| Retrievability | Minutes to hours, often unsuccessful | Targeted access in seconds |
| Proof of Integrity | Not consistently verifiable | Seamless audit trail |
| Format Readability | Dependent on legacy software | Long-term stability and independence |
| Retention | Tied to specific systems | Safeguarded across system changes |
| Audit Preparation | Weeks-long special effort | Routine process from existing data |
The most important effect was not the speed. It was the reliability. The audit risk went from being an open question to a controlled process.
The Role of Audit-Compliant Archiving
Audit-compliant archiving is not a storage location. It is a characteristic of how data is handled.
It is defined by three characteristics. First, immutability: Once a record is stored, it cannot be silently altered. Second, traceability: Every access and every version is logged. Third, durability: Data remains readable over long periods of time, regardless of the system that generated it.
For software in medical technology, this is the missing link between creation and verification.
The application generates the data. Quality management determines what must be retained. Archiving ensures that this evidence survives the application.
Without this separation, all data retention remains tied to the lifespan of individual systems—and thus to a time horizon that is simply too short for medical device compliance requirements.
Self-Check: How audit-ready is your data management?
Assess your current situation. Any statement you cannot unequivocally affirm is a potential audit finding.
☐ We know exactly which data must be retained and for how long.
☐ Our data subject to retention requirements is stored in a format that cannot be altered.
☐ Every access and every change is fully logged.
☐ Our data is readable independently of the system that generated it.
☐ We have a verified migration path for proprietary formats.
☐ Our recovery process is regularly tested and documented.
☐ Data retention is not tied to the lifespan of individual applications.
☐ We can verify the origin, date, and integrity of every data record.
☐ An auditor receives requested evidence without any special action.
☐ Responsibility for long-term archiving is clearly assigned.
Evaluation:
- 8 to 10 “Yes” answers: Your data management is robust. Maintain the process through regular reviews.
- 5 to 7 “yes” answers: There are noticeable gaps. Prioritize the outstanding issues before the next audit.
- 0 to 4 “yes” answers: Your ability to provide evidence is at risk. There is an urgent need for action regarding system-independent archiving.
Data integrity throughout the entire lifecycle
This is exactly where CHRONOS comes in. CHRONOS is CSP’s solution for audit-proof, system-independent long-term archiving of process and quality data. Data is stored in a tamper-proof manner, provided with a complete audit trail, and retained in such a way that it remains complete and readable even years later and after the systems that generated it have been replaced.
In this way, CHRONOS decouples your ability to provide evidence from the lifespan of individual applications. What remains is a verifiable data set that complies with the regulatory retention periods for medical technology.
Learn more at CHRONOS Data Archiving.
Frequently Asked Questions
What is medical technology software? Medical technology software refers, on the one hand, to software that is itself a medical device or part of one, and, on the other hand, to software that manufactures, tests, and documents medical devices. Both generate data that serves as evidence and are subject to strict regulatory requirements regarding documentation and retention.
Which standards are relevant for medical device software? Key standards include the MDR (EU 2017/745) for market access, IEC 62304 for the software lifecycle, ISO 13485 for quality management, and ISO 14971 for risk management. For the U.S. market, 21 CFR Part 11 is also a key standard for electronic records.
How long must data be retained in medical technology? Technical documentation must generally remain available for at least ten years after the last product was placed on the market; for implantable products, this period is at least fifteen years. These retention periods span nearly every software generation, making system-independent archiving necessary.
What does audit-proof archiving mean? Audit-proof archiving means that data is stored in a way that is unalterable, traceable, and readable over long periods of time. Every access is logged, and the data remains usable regardless of the system that generated it. This fundamentally distinguishes it from a simple backup.
Is a backup sufficient to meet the obligation to provide evidence? No. A backup protects against data loss but does not ensure immutability, an audit trail, or long-term readability. To meet the obligation to provide evidence in medical technology, audit-proof archiving is required, which guarantees these properties.
What are the ALCOA principles? ALCOA stands for attributable, legible, current, original, and correct—the core criteria for data integrity. In the expanded form, ALCOA+, the criteria “complete,” “consistent,” “durable,” and “available” are added. These criteria form the standard against which records are evaluated during audits.
Why do audits fail more often due to documentation issues than due to software issues? Because a software’s functionality is validated at the time of release, but the obligation to provide evidence continues for years. During this time, systems are replaced, formats become obsolete, and personnel change. Gaps in traceability and unreadable legacy data are the most common findings.
How can software documentation become system-independent? By transferring the data early on from the source system to a dedicated archiving system, in long-term stable, readable formats and with a continuous audit trail. This ensures that the evidence is preserved even if the original application is discontinued.
What should a company do first to become audit-ready? The first step is a comprehensive inventory: Which data is subject to retention requirements, in what formats is it available, and how long must it remain accessible? Only on this basis can classification, migration, and audit-compliant operations be properly implemented.
