An EDMS retention plan must preserve the required record and its meaning until every applicable obligation is satisfied. Start with record classes and retention triggers, then prove that an authorized person can retrieve the complete record after the original system, supplier or employee is gone. A folder marked “Archive” does not establish either result.
This guide helps life-sciences records owners, quality teams and IT plan retention and a possible supplier exit together. It provides a retention-register structure, an archive acceptance packet and a worked disposition decision. The regulatory examples are deliberately scoped; there is no single retention period for every pharmaceutical document.
Primary sources were checked on October 6, 2026. The sample policy and dates below are fictional design examples, not a complete legal retention schedule for a particular organization.
Make five decisions before choosing archive storage
The storage choice follows the record requirement. A low-cost object store may preserve files but still need an index, authorization service, viewers and procedures. Keeping a legacy EDMS available may retain useful context but introduce license, security and support dependencies.
| Decision | Input needed | Result to approve |
|---|---|---|
| What must survive? | Record classes, authoritative versions and related evidence | Defined archive package for each class |
| How long, and from which event? | Applicable rules, obligations and verified event dates | Controlled retention rule and calculated review date |
| Who controls the record? | Owner, custodian, permitted users and transfer arrangements | Responsibilities during operation and after exit |
| How will it remain usable? | Formats, metadata, relationships, viewers and access method | Tested retrieval and preservation approach |
| When may it be disposed of? | Completed retention, current holds and authorized decision | Recorded disposal approval and evidence |
Assign an accountable records owner before delegating technical work. IT can operate storage, but a migration script should not decide that a clinical file and a manufacturing SOP share the same retention rule because both are PDFs.
Define the boundaries of this project: legal entity, sites, countries, product/program, process and record classes. Include external partners that hold authoritative records or necessary evidence. Identify who resolves uncertainties about jurisdiction, trigger events or conflicting obligations.
Separate active use, archive, backup and disposal
An active controlled document supports a current process. A superseded revision may no longer be available for routine operational use while still being retained as evidence. An archive preserves the required record set for future authorized retrieval. A backup supports recovery from loss or disruption according to a separate recovery design.
Those functions can share infrastructure, but one does not automatically prove another. A rolling backup may expire before a record's retention period. An archive might retrieve one record well while providing no timely recovery of an entire service. Verify both against their own intended outcomes.
Disposal is a further decision. Moving a file to cold storage, disabling a user account or cancelling an EDMS subscription is not disposal approval. Similarly, a document's “obsolete” status does not establish that its retention clock has expired.
Draw the lifecycle for each record class: creation and approval, operational use, supersession or closure, retention trigger, archive custody, eligibility review and authorized disposition. Some stages overlap. The record might enter an archive before the retention-trigger event has occurred; in that case, its final eligibility date remains unresolved.
Choose rules by record class and responsible party
These examples show why a shared “retain everything for X years” setting is inadequate. They are starting points for an applicability assessment, not an exhaustive list of recordkeeping obligations.
| Example record context | Rule to evaluate | Important boundary |
|---|---|---|
| US finished-drug batch production, control or distribution records required by Part 211 | Section 211.180(a) generally specifies at least one year after batch expiration | Certain expiration-exempt OTC products have a different distribution-based period |
| US IND sponsor records and reports required by Part 312 | Section 312.57(c) links retention to marketing approval or the specified investigational-distribution discontinuation and FDA-notification conditions | Study closeout alone is not the stated trigger |
| US IND investigator records required by Part 312 | Section 312.62(c) uses indication-specific approval or the specified discontinuation/notification alternative | Investigator and sponsor wording must not be collapsed into one rule |
| Clinical trial master file under EU Regulation 536/2014 | Article 58 generally requires at least 25 years after trial end, unless other Union law requires longer | Subjects' medical files follow national law; this is not a rule for every EDMS document |
For the first row, 21 CFR 211.180(a)–(d) also distinguishes component/container/closure/labeling records and requires inspection availability during retention. Evaluate the specific paragraph and records involved rather than transferring the batch rule to every SOP or development document.
For IND sponsor records, the alternative in 21 CFR 312.57(c) concerns two years after investigational shipment and delivery are discontinued and FDA has been notified when an application is not approved. For investigators, 21 CFR 312.62(c) addresses approval for the investigated indication and its own alternative conditions. Record the responsible party and evidence for the applicable event; a generic project-status field may not establish it.
The EU example comes from Regulation 536/2014, Article 58. Its archive provisions also address accessibility, documented ownership transfer, completeness, legibility and traceable alteration. Do not infer from a shared storage location that manufacturing, clinical and subject medical records have identical requirements.
Where several obligations apply, retain the individually assessed requirements and their rationale. The approved schedule must satisfy all applicable constraints, including any properly established hold. “Use the largest number” is insufficient when the periods begin on different events or an event has not occurred.
For illustration, suppose an approved local schedule gives the same fictional record two constraints: retain through five years after closure and through two years after a later transfer. Closure occurred September 30, 2021; transfer occurred December 31, 2025. Under a policy that retains through each anniversary, the dates are September 30, 2026 and December 31, 2027. The two-year constraint finishes later even though its duration is shorter. Earliest review under that policy is January 1, 2028, subject to holds and all other requirements. If the transfer event is unverified, the combined result is Unknown rather than the earlier known date. These are invented policy inputs, not additional pharmaceutical retention rules.
Build one controlled retention register
Use the organization's approved rule registry as the source of truth. The EDMS configuration, archive job and disposal report should refer to its rule identity and version. Copying durations into several independent spreadsheets creates a foreseeable divergence when the rule changes.
The following fields form a practical starting register. They are a proposed operating design, not a regulatory schema.
| Field | What to record |
|---|---|
| Record-class identity | Controlled class, entity, process and geographic scope |
| Required record package | Content, versions and contextual evidence that must remain together |
| Authority and rationale | Applicable source, provision, current revision and reviewed interpretation |
| Rule identity/version | Approved policy reference consumed by the EDMS/archive |
| Trigger definition | Exact event and responsible party, including compound conditions |
| Trigger evidence | Actual event date, source record and person verifying it |
| Retention calculation | Each applicable period and resulting earliest review date |
| Hold state | Active, clear or unresolved, with authority and affected scope |
| Custody and retrieval | Accountable owner, archive location, index and access procedure |
| Preservation dependencies | Required format/viewer, keys, services and migration triggers |
| Disposition decision | Reviewer, decision date, approved scope and execution evidence |
Represent an unknown trigger explicitly. Do not populate it with import time, study closeout or the current date merely because the software requires a value. Change the configuration or route that record class to a controlled exception until the input can be established.
A date field also needs defined semantics. If the rule is based on a calendar date, specify how your approved procedure handles the last retained day and the earliest disposal review. If timestamps are involved, retain the time zone and source event. Avoid letting a server's local time silently shorten the intended interval.
Define the archive package before exporting
Begin with one representative record and reconstruct what a future reader must understand. The file may need its authoritative identifier, revision, status, attachments, approval/signature information, relevant history and relationships. Determine the required package from the record's use and applicable obligations; do not assume every ancillary application log must be retained with every document.
Separate original content from any preservation rendition. A PDF can be useful for reading but may not carry all the behavior or context of a native record. If both are required, retain their relationship and explain which is authoritative for which purpose. An OCR layer supports search; it should not silently replace the visible source as the approved content.
Create a package inventory containing record/version IDs, file identities, expected relationships and integrity-check information. A checksum helps detect a byte-level difference from the recorded baseline. It does not establish that the baseline was the right revision, the record was complete or its scientific content was correct.
For computerized systems supporting GMP activities within its scope, current Annex 11, sections 7 and 17 address stored/archived data and continuing accessibility, readability and integrity, including retrieval after relevant changes. This guide uses the January 2011 revision listed in the Commission's current EudraLex index, in the human-medicines GMP context. It does not treat a proposed revision as operative.
Prove retrieval without the original user's knowledge
Choose a tester who did not prepare the export. Give them a realistic request such as “retrieve SOP R-210 revision 3 and establish its approval and effective status on the specified date.” Supply the approved archive procedure and authorized access, not a private shortcut known only to the migration engineer.
Capture the request, record class, archive release/configuration, identity, start/end times, retrieved identities, completeness checks, evidence location and observed result. Set the accepted retrieval requirement from the applicable obligation and intended use before the exercise. Do not claim that every regulator allows the same number of hours.
Challenge the archive with these cases:
- Two records share a title but have different identifiers or organizations. The result must preserve the requested scope.
- The newest revision is not the historical revision requested. Retrieval must identify the correct version.
- An attachment is missing while the main file opens. Completeness must fail for a package that requires that attachment.
- The original author has left. Authorized retrieval must not depend on that person's active account.
- A viewer, encryption key or linked service is unavailable. Record the failed dependency rather than marking the archive readable because the bytes exist.
- An unauthorized account requests a direct object URL. Availability for authorized users must not become universal exposure.
Record Pass, Fail, Unknown or justified Not applicable for each required outcome. Unknown is not a pass. Use the evidence in the system's validation and change process, including relevant checks after format, platform or access changes.
Work through a trigger, hold and disposal example
Fictional company Meridian has record package RP-17 in its EDMS. Its records owner has already approved a local rule requiring retention through the fifth anniversary of a verified closure date. This five-year rule is solely an example, not a pharmaceutical regulatory requirement.
The verified closure date is September 30, 2021. Meridian's procedure retains the package through September 30, 2026; October 1, 2026 is the earliest date it can enter disposal review. The archive contains the approved document, required attachment and supporting history, and its retrieval test passes.
On September 29, the date condition is not satisfied. On October 1, the date condition is satisfied, but the system may only propose review. The authorized reviewer still checks all applicable rules, holds, ownership and package dependencies before approving disposal.
Now change one condition: a hold applies to RP-17. The record remains retained even though the calendar condition is met. Removing that hold later does not automatically execute an old deletion request; the current eligibility and approval decision must be established again under the procedure.
Change a second condition: closure is recorded as “Q3 2021” without the required exact event evidence. Meridian cannot silently choose July 1 or September 30 to make the calculation work. Classification is Unknown; the owner must resolve the event and update the controlled record before disposal review can pass.
Finally, suppose the package inventory says two attachments but retrieval returns one. That is an archive completeness failure. Keep the affected source and preservation route available, investigate the mismatch and retest after correction. A passed date calculation cannot compensate for lost record context.
Put exit obligations into the supplier agreement early
An exit plan should describe the usable result the organization receives, not just “data export available.” Identify the export content, formats, metadata/history coverage, delivery mechanism, fees or dependencies, notice period, assistance and permitted overlap between services. Unquoted costs remain unresolved commercial inputs rather than assumed free services.
Assign who verifies the package, operates the replacement archive, retains retrieval instructions and answers requests after termination. Include transfer of ownership or custody where relevant, without assuming that a contract removes the regulated party's responsibilities.
Use an acceptance packet with the agreed scope, source inventory, export inventory, reconciled exceptions, executed retrieval results, access evidence, preservation dependencies and authorized transfer decision. Keep the source available for the necessary transition until that evidence supports retirement. A successful file-count comparison alone is insufficient.
Plan what happens to residual supplier copies and backups according to the applicable agreement, obligations and disposal policy. Distinguish removal from active service from later backup expiry. Require evidence appropriate to the promised action; avoid a blanket statement that every copy disappears immediately when an account is closed.
Start with one consequential record class and execute its retrieval exercise before expanding the schedule. Our document-control guide covers the preceding lifecycle. If you are evaluating Assyro for a regulatory-document workflow, bring your record-package and exit requirements so the offered scope and evidence can be assessed against your actual needs.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.

