Record Retention Policy

This topic is part of the SG Systems Global Guides library for regulated manufacturing teams evaluating eBMR, MES, and QMS controls.

Updated December 2025 • record retention policy, data integrity, archival, retrieval, audit readiness, eBMR/QMS records, adverse event retention, backups, decommissioning • Dietary Supplements (USA)

Record retention policy defines what records you must keep, how long you must keep them, how you ensure they remain authentic and retrievable, and how you prove they weren’t altered. In dietary supplement manufacturing, retention is not a back-office IT setting. It’s a compliance control. The fastest way to fail an inspection is not “missing one SOP.” It’s being unable to retrieve complete, trustworthy records for a lot, a complaint, an adverse event, a deviation, or a label revision—years after the work occurred.

Buyers who search for record retention policy are usually reacting to a real trigger: a customer audit request, an internal investigation, a platform migration, a ransomware scare, or the realization that their “records” live across shared drives, email, and tribal knowledge. A mature retention policy turns records into durable evidence: controlled, searchable, exportable, and preserved in a way that supports GDP and ALCOA+ principles. For supplement operations context, see Dietary Supplements Manufacturing.

“If you can’t retrieve it, you don’t have it. If you can’t prove it’s authentic, it doesn’t count.”

1) What buyers mean by record retention policy

Buyers mean: “Tell me what we must keep, how long, where, and how we prove it.” They also mean: “How do we retrieve it quickly?” In regulated manufacturing, retention is a performance requirement. The “correct” record exists only if it can be retrieved, interpreted, and defended under scrutiny.

A retention policy is also a boundary policy. It defines what belongs in the QMS/eBMR system vs what belongs in ERP vs what can remain in shared drives. It defines who can see what. It defines how long sensitive data (like adverse event narratives) is retained and how it is protected. It defines how records survive system changes—because a system that is replaced every 5–10 years must still preserve evidence for longer periods.

2) Why retention fails (and why “we keep everything” is not a solution)

Retention fails because teams confuse storage with evidence. “We keep everything” is a storage strategy. It is not a retention policy. It does not define authenticity, indexing, access control, legal holds, or destruction governance. It also creates real risk: sensitive data is spread widely, records are duplicated in uncontrolled locations, and the organization cannot prove what is the authoritative record.

Common retention failure modes:

• Fragmentation. Batch records in one system, lab results in spreadsheets, deviations in email, label approvals in Slack.
• Uncontrolled copies. PDFs emailed around become the “record,” even if the system record differs.
• Broken indexing. You have the file, but you can’t find it without guessing the folder name.
• System migrations without evidence mapping. Old records are “archived” as a zip file with no searchable index.
• Backups not tested. You assume you can restore, but you’ve never proven it.
• Over-permissioned access. Everyone can see everything, including sensitive records.
• Destruction without proof. Old records are deleted or lost without an audit trail.

3) Retention as data integrity: ALCOA+ and GDP requirements

Retention is an extension of Good Documentation Practices. If GDP is how you create credible records, retention is how you preserve their credibility over time.

ALCOA+ applied to retention:

• Attributable: the retained record still shows who did what and who approved it.
• Legible: the record remains readable; file formats don’t become obsolete.
• Contemporaneous: timestamps remain intact; late entries are flagged, not erased.
• Original: originals and audit trails remain preserved, not replaced by summaries.
• Accurate: the record is protected against silent alteration; integrity checks exist.
• Complete/Consistent/Enduring/Available: the record remains whole, consistent with other linked records, durable, and retrievable.

In digital systems, the biggest risk is silent changes after the fact. That’s why retention must include audit trails, reason-for-change controls, and exportable evidence. If your archive is a PDF snapshot with no audit trail, you’ve preserved appearance, not evidence.

4) Record inventory: what records exist in a supplement operation

Retention starts with inventory. If you don’t know what records exist, you can’t assign retention periods or retrieval requirements. In dietary supplements, a practical record inventory includes:

Once record classes are defined, assign each: owner, system of record, retention period, access profile, and retrieval expectations.

5) Retention periods: how to define “how long” without guessing

Retention periods should be derived from three drivers:

• Regulatory requirements (e.g., certain adverse event records have defined retention expectations).
• Business risk (chargebacks, lawsuits, customer audits, brand risk horizon).
• Operational usefulness (how long records are needed for trending and continuous improvement).

Practically, you define retention periods per record class and product risk tier. You also define a “minimum floor” and a “maximum cap” based on cost and sensitivity. Then you add an override: legal hold or investigation hold can extend retention beyond normal periods.

For example, serious adverse event case files and associated communications are typically retained for defined multi-year periods (commonly six years under the statutory framework for dietary supplement AE recordkeeping).

6) Retention triggers: what date starts the clock

“Keep records for X years” is meaningless unless you define what starts the clock. Common triggers:

• Manufacture date (when lot was produced)
• Release date (when lot was dispositioned/released)
• Expiry/BB date (product shelf-life end)
• Last distribution date (when the last unit left your control)
• Case closure date (complaint/AE case closed)
• Submission date (SAER filed)

A defensible policy assigns triggers per record class. Example: batch and lot records may be retained through a period tied to the lot lifecycle; complaint and AE records may be retained tied to case closure or statutory requirements; label/claims records may be retained tied to the last lot using that label revision. The key is consistency and system enforceability.

7) Formats and authenticity: native records, exports, PDFs, and evidentiary risk

Retention is not only duration—it’s format. A record can be “retained” and still be unusable if the format can’t be read, isn’t authentic, or lacks context. Practical format categories:

• Native system record (database-backed record with audit trails and metadata).
• Controlled export (PDF/CSV/XML export generated by system with version stamp and integrity protection).
• Uncontrolled copy (screen capture, emailed PDF, edited spreadsheet) — high evidentiary risk.

Key principle: your retention policy should specify the system of record and treat exports as “evidence copies” rather than replacements—unless your decommissioning plan requires an export-based archive (in which case the export must preserve audit trail context and indexing).

Where teams get burned: they archive PDFs of batch records but lose audit trail history and correction history. That’s not a record; that’s a snapshot. If you need export archives, export audit trails and metadata with the record and preserve linkages (lot, product, dates, signatures).

8) Indexing and retrieval: how to make records searchable years later

Retrieval is the point of the policy. If retrieval is slow, your policy is theoretical. Indexing should be designed around how people search during audits and crises:

• Lot number / batch number
• SKU/product name
• Date ranges (manufacture, release, shipment)
• Supplier lot and supplier name
• Complaint/AE case ID
• Label revision / artwork ID
• CAPA/deviation IDs

Practical retention indexing rules:

• Canonical IDs. Every record class has a unique ID; cross-links use those IDs.
• Stable naming conventions. Exports include IDs in filenames and inside metadata.
• Searchable metadata. Store metadata in a searchable index, not only in folder names.
• Cross-link preservation. Case records link to lots, lots link to shipments, shipments link to customers.

If you rely on folder trees alone, retrieval will degrade as the organization grows. A retention system must behave like a database, even if exports are stored as files.

9) Access controls and privacy: RBAC, redaction, and sensitive record classes

Retention must incorporate access control. “Who can see what” is part of the evidence posture. Sensitive record classes include:

• Adverse event and SAER records (health-related personal data)
• Personnel training records (PII)
• Security and access provisioning logs
• Legal correspondence and investigation notes

Practical controls:

• Role-based access to restrict sensitive records (RBAC).
• Field-level separation for AE/SAER (contact info vs medical narrative vs internal assessment).
• Redacted export capability for sharing with customers/partners without exposing personal identifiers.
• Access audit for high-risk records (who accessed what, when).

A retention policy that ignores access becomes a privacy risk. A retention policy that over-restricts access becomes an operational bottleneck. The correct design is least privilege + controlled export paths.

10) Audit trails and corrections: preserving history, not overwriting it

Audit trails are part of the retained record, not optional metadata. If your system supports corrections, late entries, overrides, and approvals, the retention system must preserve the full change history. Otherwise, you can’t defend record authenticity.

Retention requirements for audit trails:

• Before/after values preserved
• User identity and timestamps preserved
• Reason-for-change preserved
• Approval chain preserved (e-signature meaning)
• Exportability for audits without vendor intervention

If you decommission a system, ensure audit trails are exported and indexed alongside the records. Do not treat “PDF of final record” as sufficient where audit trails matter.

11) Backups, disaster recovery, and restore testing as compliance controls

A retention policy without backup and restore testing is wishful thinking. In regulated operations, you must be able to prove you can recover records after a system failure or cyber event.

Practical backup/DR elements:

• Backup frequency aligned to data criticality (e.g., daily minimum; more for high-transaction systems).
• Immutable backups to resist ransomware.
• Offsite redundancy in a separate trust zone.
• Restore testing on a defined cadence with documented results.
• Recovery time objective (RTO) and recovery point objective (RPO) defined for critical systems.

Restore testing is often the missing piece. Teams assume backups work. Then they discover they can’t restore the database, or they can’t interpret the restored records because the app version is gone. A mature policy treats restore tests as audit evidence: you can prove that records are enduring and available.

12) Legal holds and investigation holds: how retention changes under pressure

Legal and investigation events override normal retention schedules. A retention policy must define:

• Legal hold triggers (lawsuit threat, attorney notice, regulator inquiry, serious event escalation).
• Hold scope (which records, which time window, which products/lots/cases).
• Hold enforcement (prevent deletion/destruction even if retention period ends).
• Hold release (who can lift it and how it’s documented).

Investigation holds are similar: if a CAPA or SAER is active, you may need to prevent destruction of related records, retains, and return samples. Tie this to your complaint/AE workflows and to your returned product handling program.

13) Destruction and disposition: proving compliant deletion

Destruction is part of retention. If you keep everything forever, you create cost and privacy risk. If you destroy without evidence, you create compliance risk. A balanced program:

• Defines which records are eligible for destruction when retention ends
• Requires approval for destruction of sensitive or high-value record classes
• Produces destruction evidence logs (what, when, by whom, method)
• Ensures destroyed records are not still present in uncontrolled copies

For physical records (paper batch records, retained samples), destruction should be documented with certificates or logs. For digital records, destruction should include deletion from primary storage and, where required, governance around backup retention cycles.

14) System decommissioning and migration: keeping records across platforms

Most companies eventually replace systems. Your retention policy must include a decommissioning plan, or you will lose evidence during migration. A defensible decommissioning plan includes:

• Record mapping: which records exist in the old system, and where they will live after decommissioning.
• Export strategy: how to export records and audit trails in a readable format.
• Index strategy: how exported records remain searchable by lot, date, SKU, case ID.
• Integrity verification: checksums/hashes, sample retrieval tests to prove exports match originals.
• Access model: who can access the archive and how privacy is preserved.
• Restore strategy: ability to render old records even if the old app is gone.

Decommissioning is where “we saved PDFs” collapses. PDFs without audit trail and metadata do not preserve the evidence chain. Plan for evidence, not files.

15) KPIs: retention program health metrics

Other useful metrics:

• Archive indexing completeness (records with searchable metadata)
• Audit trail export completeness (records where audit trail is preserved)
• Legal hold compliance (holds applied correctly; no deletions during hold)
• Destruction compliance (on-time destruction with evidence; no premature deletion)

16) Copy/paste demo script and selection scorecard

Use this demo script to verify retention is operational, not theoretical.

17) Selection pitfalls (how retention becomes a liability)

• “Keep everything forever.” Creates privacy risk, uncontrolled copies, and retrieval chaos.
• PDF-only archives. Lose audit trail and metadata; evidence becomes a snapshot, not a record.
• No restore testing. Backups exist but aren’t proven; recovery is uncertain when needed.
• Unowned record classes. No owner means records drift into email and shared drives.
• Broken indexing. Files exist but cannot be found quickly; audits become scavenger hunts.
• Over-permissioned access. Sensitive data exposure becomes inevitable.
• Decommissioning without archive design. Old systems shut down; records become unreadable or unsearchable.

18) How this maps to V5 by SG Systems Global

V5 supports retention policy execution by linking controlled records, audit trails, and traceability into an exportable, searchable evidence set—so retention is operational, not theoretical.

• Governance: V5 QMS supports controlled records, approvals, audit trails, and case/event retention across quality workflows.
• Traceability: V5 WMS supports lot genealogy and shipment linkage needed to retrieve complete record packs.
• Execution evidence: V5 MES supports eBMR evidence capture with audit-ready history.
• Integration: V5 Connect API supports structured exports, external archive integration, and migration support.
• Industry fit: Dietary Supplements Manufacturing.
• Platform view: V5 solution overview.

19) Extended FAQ

Q1. Why isn’t “keep everything in Google Drive” a record retention policy?
Because it doesn’t define authenticity, audit trails, indexing, access control, legal holds, destruction evidence, or system decommissioning. Storage is not evidence.

Q2. What’s the most important retention requirement in practice?
Retrievability: the ability to produce a complete, authentic record pack for a lot/case quickly, with audit trails and metadata.

Q3. Do we need to retain audit trails?
Yes, for any controlled record where edits, corrections, approvals, or overrides affect evidence. A PDF snapshot without audit trail is weaker evidence.

Q4. How do legal holds affect retention?
Legal holds override normal retention schedules. Records within hold scope must not be destroyed until hold is released with documented approvals.

Q5. What’s the biggest retention risk during system migration?
Losing searchability and audit history. Decommissioning plans must preserve metadata, audit trails, and cross-links so records remain usable years later.

Related Reading
• Supplements Industry: Dietary Supplements Manufacturing
• Core Guides: Good Documentation Practices | Audit Trail Software | Electronic Signatures (Part 11) | eBMR for Supplements | Complaint Management | Adverse Event Records | SAER
• Glossary: Record Retention & Archival | Data Integrity | Audit Trail (GxP) | Document Control | Revision Control
• V5 Products: V5 Solution Overview | V5 MES | V5 QMS | V5 WMS | V5 Connect API