Retention Policy: How Long to Keep Footage, and Why

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Our companion article turned retention days into terabytes of storage; this article is about the days themselves — how to choose them, defend them, and enforce them. It is for the security integrator, product manager, operations lead, or compliance owner who has to answer a deceptively simple question — "how long do we keep the video?" — and discovers the answer is neither one number nor a free choice. Get the period too short and you fail an investigation, a chargeback, or a regulator's minimum; too long and you breach privacy law, carry needless storage cost, and turn an archive into a liability that an attacker or a subpoena can reach. No legal background is needed: every rule is explained in plain language and tied to the named law, and every period is grounded in a real operational or regulatory reason. The aim is a policy you can write down, encode in the system, and stand behind.

The one idea: retention is a decision, not a disk size

Ask most surveillance systems how long they keep footage and the honest answer is "until the disk is full." A recorder writes camera streams to its drives, and when the drives fill, it overwrites the oldest recording to make room for the newest — a first-in, first-out loop. The retention period that results is whatever the disk capacity divided by the daily write rate happens to be. It is a number nobody chose.

Work that out with the figures from our retention-math article. Take 40 cameras at 2 Mbps, recording continuously. Each camera writes about 21.6 GB per day, so the site writes roughly 0.864 TB per day. On a 26 TB array:

26 TB ÷ 0.864 TB/day ≈ 30 days before the loop wraps

So the system "retains 30 days" — but only because the array happens to be 26 TB. Add cameras, raise the resolution, or switch on a second site, and the same array now retains 18 days. Swap in bigger drives and it retains 60. The keep-period drifts with the hardware, which is exactly what a policy is supposed to prevent. If the law says you must keep 90 days, this system silently loses a month of required footage. If privacy law says you should keep only a few days, this system over-retains for weeks. Either way, the period is an accident.

A retention policy replaces that accident with a decision: footage of a given type is kept for a stated period, for a stated reason, and is then deliberately deleted — regardless of how much disk is free. The rest of this article is about how to make that decision and, harder, how to make the system actually obey it.

Figure 1. Retention lives between two limits: a minimum set by operational need and legal or sector rules (how long you must keep), and a maximum set by privacy law (how long you may). The policy is the window between them.

Two limits, pulling in opposite directions

The reason retention feels confusing is that two different forces set it, and they pull opposite ways. Keeping them separate is the whole trick.

The first force is the minimum — the floor below which the footage is useless or non-compliant. It comes from two places. One is plain operational need: an incident is often not reported the day it happens, so footage has to outlive the gap between an event and someone asking for it. A slip-and-fall claim, a disputed transaction, an employee complaint, or a theft discovered at the next stock-take can surface weeks later. The other is a legal or sector requirement: some industries are told, in regulation, the minimum number of days they must retain specific footage. Below the minimum, the system has failed at its job.

The second force is the maximum — the ceiling above which keeping footage becomes a liability rather than an asset. This comes from privacy law, which treats recorded video of identifiable people as personal data and says, in essence, that you may not keep personal data longer than you actually need it. Above the maximum, every extra day is unnecessary risk: more to secure, more exposed to a breach, more discoverable in litigation, and — in the jurisdictions that enforce it — a standing violation.

A retention period is any number that sits between those two limits. The minimum says "no shorter than this"; the maximum says "no longer than this." When the minimum exceeds the maximum — when a sector rule demands more than privacy law would otherwise allow — the specific legal obligation generally wins for that footage, and the longer period is itself the lawful basis for keeping it. The job of a policy is to find the right point in that window for each kind of footage, write it down, and delete on time.

The minimum: how long you must keep footage

Start with the floor, because it is the easier of the two to reason about and the one most teams get backwards by guessing.

Operationally, the question is: what is the longest plausible gap between something happening on camera and someone needing the footage? For a quiet office lobby that might be a week. For a retail store with chargeback disputes, it is the card-scheme dispute window, which can run 60 to 120 days. For a workplace where a harassment or injury claim might be filed, it can be longer still. The honest method is to list the incident types the cameras exist to cover, find the slowest one to surface, and set the minimum to outlast it — not to pick a round number because it sounds safe.

On top of operational need sit sector minimums written into regulation, and these are specific, citable, and easy to get wrong. A few real examples as of 2026:

Sector	Typical minimum	Source / note
Casino / gaming (Nevada)	7 days routine; ≥ 60 days flagged	Nevada Gaming Control Board Regulation 5 surveillance standards — routine coverage 7 days, recordings of suspicious or disputed activity at least 60 days
Cannabis (varies by state)	30–90 days	State cannabis programs set their own period — e.g. ~90 days common, 45 days in some localities, 30 days in Nevada
Banking / financial	~90 days to 6 months	Driven by fraud-investigation and dispute windows and bank policy, not a single federal video mandate
Retail	30–90 days	Operational: theft is often found at the next stock-take; chargeback windows run 60–120 days
Public CCTV (UK guidance)	~31 days, purpose-driven	UK ICO / Surveillance Camera Code sets no fixed period — keep only as long as the purpose needs

The pattern to notice: there is no universal number. "How long should we keep footage?" has no answer without naming the sector, the jurisdiction, and the camera's purpose. A casino floor camera, a dispensary vault camera, and a back-office lobby camera in the same building can have three different lawful minimums.

Common mistake: "PCI DSS requires 90 days of video." This is one of the most repeated myths in surveillance. The Payment Card Industry Data Security Standard governs how cardholder data is protected; it expects physical access controls and, in its access-logging requirement, that records be retained — but it sets no video-footage retention period at all. The "90 days" figure is borrowed from an unrelated log-retention line and pasted onto cameras. If your only stated reason for keeping 90 days of video is "PCI requires it," you have no actual basis — find the real operational or sector reason, or shorten the period.

The maximum: how long you may keep footage

Now the ceiling, which is where surveillance teams most often drift into quiet non-compliance — because cheap storage makes "keep it all, forever" feel free, and privacy law says the opposite.

The controlling principle in the EU is storage limitation, set out in the General Data Protection Regulation (GDPR, Regulation (EU) 2016/679), Article 5(1)(e). It says personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." Recorded video of identifiable people is personal data, so the clock is not optional: once the footage is no longer needed for the purpose that justified recording it, it must go.

How short is "no longer than necessary" for video? The body that interprets GDPR for cameras — the European Data Protection Board (EDPB) — answers this directly in its Guidelines 3/2019 on processing of personal data through video devices. Its position, restated in the EDPB's own April 2026 awareness summary of those guidelines, is blunt: because damage or an incident "can be detected within one or two days," a storage period of "a few days" is often sufficient, and footage should be erased — ideally automatically — once it is no longer necessary. The guidelines give a worked example (paragraph 119): an organisation that auto-deletes footage after two days simply cannot supply that footage to anyone afterward, because it no longer exists. The guidance leaves room for longer where a member state sets a specific period or where a real need justifies it, but the default expectation is short.

This is the mirror image of the minimum, and the tension is real. A card-dispute window might argue for 90 days; the privacy default argues for a few. The resolution is not to split the difference but to tie each period to a named, defensible purpose: the 90-day POS camera is kept 90 days because of the documented dispute window, and the lobby camera with no such need is kept a few days. A period you cannot justify by purpose is a period that is too long.

Common mistake: keeping everything forever because storage is cheap. The cost that matters is not the disk — it is the liability. Every extra day of retained footage is more personal data to secure, more to lose in a breach, more that a subpoena or a data-subject access request can reach, and, in the EU, a standing storage-limitation violation. An archive you cannot justify is not an asset; it is a stockpile of risk that grows every day the deletion job does not run. The cheap-storage instinct (see our storage-tiers article, where a $1/TB archive class tempts exactly this) is the thing the maximum exists to stop.

The sharper ceiling: biometric footage

One category carries a much harder maximum: footage processed for biometrics — face recognition, or any analytic that turns a face into a searchable template. Under GDPR this is special-category data (Art. 9) with a higher bar; under US law it triggers state biometric statutes. Illinois' Biometric Information Privacy Act (BIPA, 740 ILCS 14/15(a)) requires any private entity holding biometric identifiers to publish a written retention schedule and to permanently destroy the data when the purpose is satisfied or within three years of the person's last interaction, whichever comes first. That is a statutory deletion deadline with a private right of action behind it. If your system runs face recognition, the face templates have their own retention clock, separate from and stricter than the video they came from — a point our face-recognition article flags and the BIPA article covers in full. Treat biometric data as its own retention class, always.

Figure 2. There is no universal retention number. Sector minimums (casino, cannabis, banking) set a floor for specific cameras; the GDPR storage-limitation principle pulls the default toward days, not months. Each camera's period follows its purpose.

Setting the policy: one system, many clocks

The mistake hiding inside "how long do we keep footage?" is the word we, as if one number governs the whole system. It almost never should. A real retention policy assigns each class of footage its own period, each justified by its own purpose, and lets the system run several clocks at once.

The method is short. First, group cameras (or events) into classes by purpose: general coverage, transaction or point-of-sale, access-controlled or high-value areas, incident-flagged clips, and any biometric output. Second, for each class find the minimum (operational need, plus any sector mandate) and the maximum (the privacy default, unless a specific obligation lifts it). Third, set the period to the shortest value that clears the minimum and stays at or under the maximum — shortest, because storage limitation rewards restraint and every extra day is risk. Fourth, write it down, including the reason for each period, because a regulator, an auditor, or your own future team will ask why.

Here is that method as a worked policy for a mixed retail site:

Footage class	Retention period	Why (the basis)	How it is deleted
General floor / entrance	14 days	Operational: incidents surface within days; privacy default favours short	Auto-delete at age
Point-of-sale lanes	90 days	Card-dispute / chargeback window (60–120 days)	Auto-delete at age
Stockroom / high-value	30 days	Theft found at next stock-take cycle	Auto-delete at age
Incident-flagged clips	1 year (or until case closes)	Active investigation / claim; documented	Manual review, then delete
Face-recognition templates	Per BIPA schedule (≤ 3 yr, purpose-bound)	Statutory biometric deadline (740 ILCS 14)	Scheduled destruction + log

Notice that the same building runs five different clocks, and the shortest defensible period wins in each row. Notice too that only the flagged-incident class is kept long, and only because a specific, documented reason lifts it — which is exactly how the storage-limitation maximum is meant to be cleared: by a named purpose, not by default. The arithmetic from our retention-math article still applies underneath, but now the terabytes follow the policy instead of the policy following the disks.

Figure 3. Setting a retention period per footage class: start from the purpose, apply any legal or sector minimum as the floor, hold flagged or litigation-relevant footage, and otherwise take the shortest period under the privacy-law maximum.

Making deletion actually happen

Choosing periods is the easy half. The hard half — the half that fails audits — is making the system delete on schedule and prove it did. Three things get in the way.

First, the two kinds of "delete" are not the same. Overwriting the oldest footage when the disk fills (the first-in, first-out loop we started with) is capacity-driven deletion: footage disappears when space runs out, at an age that depends on disk size and camera load. Deleting footage when it reaches a stated age is policy-driven deletion: footage disappears on a schedule, regardless of free space. A compliant system needs the second, and most recorders ship configured only for the first. The fix is to set an explicit maximum retention age so that footage is deleted at, say, 14 or 90 days whether or not the disk is full — and to size storage so the policy age is reached before the disk wraps, never after.

The surveillance standards make this enforceable. ONVIF — the common language that lets cameras and recording software from different makers work together — governs recorded video through Profile G (recording and retrieval; current Specification v1.1, October 2025). Its Recording Control Service defines a MaximumRetentionTime on a recording: the device "shall delete any data older than the maximum retention time." Set it to a real number and the standard obliges the recorder to enforce a policy age; set it to zero and retention is limited only by disk space — which is the accidental, capacity-driven mode again. Profile G standardizes the control — how a VMS sets and enforces the retention age across mixed-vendor recorders — but it does not decide the number. Remember the boundary from our ONVIF explainer: the standard guarantees the interface both sides conform to, not the policy you pour into it. For the commercial overview of how the profiles map to real products, Fora Soft's guide to ONVIF profiles in security systems is the companion read.

Second, footage escapes the schedule. The retention clock governs the primary recording, but copies leak out of it constantly: a clip exported for an investigation, a nightly backup, a cloud archive copy (the kind our cloud-and-hybrid-storage article describes), a frame emailed to a manager. Each of those is footage that will outlive the deletion job unless it is tracked. A policy that deletes the primary recording at 14 days but leaves year-old exports in a shared drive has not actually retained for 14 days — it has retained for a year, in the worst possible place to defend. Every export and backup needs its own retention rule and its own deletion, or the policy is fiction.

Third, deletion has to be provable. Privacy law expects accountability (GDPR Art. 5(2)): being able to show, not just assert, that footage was deleted on time. That means logging deletions — what was deleted, when, and under which rule — without logging the footage itself. When a regulator or a data-subject access request asks "do you still have video of me from last month?", the defensible answer is a deletion record showing the footage aged out on schedule, not a shrug. Recording modes interact here too: a system using motion or event recording retains less to begin with, which makes the deletion story simpler.

Figure 4. Deletion in practice: policy-driven deletion at a stated age (enforced via ONVIF Profile G MaximumRetentionTime) versus capacity-driven overwrite, the legal-hold freeze that suspends it, and the exports and backups that must carry their own retention rule.

The exception that overrides everything: legal hold

One event suspends the entire retention policy for specific footage: a legal hold (also called a litigation hold or preservation hold). When an organisation knows, or reasonably should know, that particular footage is relevant to actual or anticipated litigation, investigation, or a regulatory request, a common-law duty to preserve attaches — and scheduled deletion of that footage must stop, even if its retention period has expired.

The stakes are concrete. Under the US Federal Rules of Civil Procedure (Rule 37(e)), destroying electronically stored information that should have been preserved — surveillance video squarely included — can draw sanctions for spoliation, ranging from an adverse-inference instruction (the jury is told to assume the lost footage would have hurt you) up to default judgment. The routine, automatic deletion that keeps you compliant the rest of the time becomes the thing that sinks you if it runs over footage you were obliged to hold.

Two engineering implications follow. The hold must be surgical: it freezes the specific clips, cameras, and time ranges that matter, while the rest of the system keeps deleting on its normal schedule — a hold that freezes everything turns a compliance feature into a storage and privacy problem. And it must be releasable: when the matter resolves, the held footage returns to the normal retention clock and is deleted, rather than living forever because nobody remembered to lift the hold.

Common mistake: a deletion job that destroys footage under hold — or a hold that never lifts. The first is spoliation: the auto-delete runs at 14 days and erases the exact clip a lawsuit needed, because nobody told the system to preserve it. The second is its mirror: a hold is placed, the case settles, and three years later the "temporary" preservation copy is still sitting in storage, now an over-retention violation. A working system can flag footage as held, exempt it from automatic deletion, and — just as importantly — surface holds that are ready to be released. Build the freeze and the thaw together.

Where Fora Soft fits in

Retention is the part of a surveillance system where a clean demo and a defensible deployment diverge, because the demo never runs the deletion job and never gets a subpoena. Fora Soft has built video streaming, real-time video, and computer-vision systems since 2005 — more than 625 shipped projects — and the surveillance work sits where storage, standards, and privacy meet. When we design or integrate a VMS, we set retention as an explicit policy per footage class rather than letting the disk size decide it, enforce the period through the ONVIF Profile G maximum-retention control so mixed-vendor recorders obey one rule, and build the deletion path to reach exports, backups, and cloud copies — not just the primary array. We treat biometric output as its own stricter clock, wire in a surgical, releasable legal-hold mechanism, and log deletions so the system can prove it deleted on time. The accuracy-vs-performance habit applies directly: the policy is judged not on the day it is written but on the day someone asks whether the footage was there when it should have been — and gone when it should have been.

What to read next

• How surveillance storage works: the retention math
• GDPR for video surveillance
• Retention limits and lawful deletion

Download the retention-policy decision guide (PDF) — the two-limits model, the sector-minimum reference table, the per-class policy template (class · period · basis · deletion method), the deletion-mechanics checklist (policy-driven vs capacity-driven, exports and backups, audit log), the legal-hold freeze-and-release steps, and a blank policy worksheet.

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your cctv footage retention period plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Retention Policy Decision Guide — One-page printable guide: the two-limits model (operational/legal minimum vs privacy maximum), a sector-minimum reference table with the PCI '90-day' myth-buster, a per-class policy template (class, period, basis, deletion) that doubles….

References

1. Regulation (EU) 2016/679 (GDPR), Art. 5(1)(e) — storage limitation, European Union. The controlling principle that personal data, including identifiable video footage, must be kept "no longer than is necessary for the purposes for which the personal data are processed" — the legal maximum that caps surveillance retention, distinct from any operational minimum. Tier 1. https://eur-lex.europa.eu/eli/reg/2016/679/oj (accessed 2026-06-09)
2. Regulation (EU) 2016/679 (GDPR), Art. 17 — right to erasure ('right to be forgotten'), European Union. The data-subject right that can compel deletion of footage before its scheduled retention age, and the accountability backdrop (Art. 5(2)) for proving deletion. Tier 1. https://eur-lex.europa.eu/eli/reg/2016/679/oj (accessed 2026-06-09)
3. EDPB Guidelines 3/2019 on processing of personal data through video devices (Version 2.0, 2020; reaffirmed in the EDPB April 2026 awareness summary), European Data Protection Board. The video-specific interpretation of GDPR storage limitation: because incidents are "detected within one or two days," a storage period of "a few days" is often sufficient; footage should be erased, ideally automatically (the paragraph 119 two-day auto-delete example); member states may set specific periods. Tier 2 (issuing-body guidance). https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en (accessed 2026-06-09)
4. ONVIF Profile G (recording and retrieval) and the ONVIF Recording Control Service Specification, ONVIF. The open standard for recording control across vendors; the Recording Control Service defines MaximumRetentionTime, under which "the device shall delete any data older than the maximum retention time," with a value of 0 meaning retention is limited only by storage — the standards mechanism for enforcing a policy retention age. Current Profile G Specification v1.1 (October 2025). Tier 1. https://www.onvif.org/profiles/profile-g/ (accessed 2026-06-09)
5. Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14/15(a), Illinois General Assembly. Requires a private entity holding biometric identifiers to publish a written retention schedule and to permanently destroy the data when the purpose is satisfied or within three years of the individual's last interaction, whichever is first — the statutory deletion deadline for face-recognition templates, backed by a private right of action. Tier 1. https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004 (accessed 2026-06-09)
6. Nevada Gaming Control Board, Regulation 5 — Surveillance Standards for Nonrestricted Licensees, State of Nevada. Sector retention minimums for casino surveillance: routine coverage retained 7 days, recordings of suspicious or disputed activity retained at least 60 days — a concrete example that sector minimums are camera- and event-specific, not a single number. Tier 1 (state regulation). https://gaming.nv.gov/ (accessed 2026-06-09)
7. U.S. Federal Rules of Civil Procedure, Rule 37(e) — failure to preserve electronically stored information, U.S. Courts. The basis for the legal-hold duty and spoliation sanctions: surveillance video that should have been preserved for litigation, if destroyed by routine deletion, can draw adverse-inference instructions up to default judgment — the rule that suspends a retention policy for held footage. Tier 1. https://www.law.cornell.edu/rules/frcp/rule_37 (accessed 2026-06-09)
8. EN IEC 62676-4:2025: Video surveillance systems for use in security applications — Part 4: Application guidelines, IEC / CENELEC. System-level guidance for planning surveillance recording, including retention and the availability and integrity of stored footage — the engineering framework that treats a defined retention period as a design requirement. Tier 1. https://webstore.iec.ch/publication/68479 (accessed 2026-06-09)
9. PCI DSS does not set a video-footage retention period (the "90 days" myth), SCW / industry technical reference. Corrects the widespread claim that PCI DSS mandates 90 days of CCTV: the standard has physical-security and log-retention requirements but no camera-footage retention period — the basis for the PCI pitfall callout. Tier 5 (institutional/technical). https://www.getscw.com/knowledge-base/pci-compliance-doesn-t-need-90-days-of-footage (accessed 2026-06-09)
10. Video surveillance retention requirements by sector (banking, casino, cannabis, retail), ECAM / Mammoth Security / industry references. Corroborated sector retention practice — banking ~90 days to 6 months, casino 30+ days, cannabis 30–90 days, retail 30–90 days — used as the basis for the sector-minimum table; cross-checked against the Nevada Gaming and state-cannabis primary sources where available. Tier 5 (institutional). https://ecam.com/security-blog/what-you-need-to-know-about-video-surveillance-retention-requirements (accessed 2026-06-09)
11. EDPB, "Video devices & data protection: when to act and what to do" (April 2026 awareness summary), European Data Protection Board. A 2026 first-party restatement of Guidelines 3/2019 confirming the storage-limitation expectation ("a retention period of a few days should often be appropriate") and the automatic-erasure recommendation remain current. Tier 2 (issuing-body guidance). https://www.edpb.europa.eu/system/files/2026-04/summary_edpb_guidelines_201903_video_devices_en.pdf (accessed 2026-06-09)

Where sources disagreed, the official law and standard were followed and the controlling fact stated plainly. The most common contested claim — that "PCI DSS requires 90 days of video" — is a myth: the standard sets no footage retention period, so the article follows the standard and flags the misconception explicitly. On the EU side, the EDPB video guidance (Guidelines 3/2019, reaffirmed April 2026) overrides the cheap-storage instinct to keep footage indefinitely; the article follows the guidance toward short default retention and treats any longer period as needing a named, defensible purpose. Sector-minimum figures are stated as examples to verify against the live regulation for the specific jurisdiction, not as universal numbers.