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

Why this matters

If you build, buy, or operate a video management system — the software that records and manages many camera streams, called a VMS — retention is where good engineering and the law meet. Keep footage too short and you fail an evidence request or break a sector rule; keep it too long and you breach privacy law and enlarge every breach and every subject-access request. This article is for security integrators, product managers, and smart-building, retail, and city security leads who have to pick a retention number and defend it. It explains the two limits, how to set a window that satisfies both, and what "lawful deletion" actually requires of the storage underneath. It is the privacy cap that sits on top of the operational retention choices covered in how long to keep footage.

Two limits, not one: the floor and the ceiling

Most articles treat retention as a single number — "keep footage for 30 days". That framing hides the actual engineering problem, which has two opposing forces pulling on the same dial.

The first force is a minimum: the shortest time you are allowed to keep footage before you risk being unable to produce evidence. Think of it as a floor you must not fall below. A slip-and-fall claim, a theft investigation, or a sector regulation can all demand footage from weeks ago, and if you have already deleted it, that is your problem, not the claimant's.

The second force is a maximum: the longest time privacy law lets you hold footage of identifiable people. Think of it as a ceiling you must not push through. Every extra day of retention is an extra day that the footage can be stolen in a breach, demanded in a subject-access request, or questioned by a regulator who wants to know why you still have it.

The lawful retention window is the band between the floor and the ceiling. Your job is to find a number inside that band, write it down, and make the system enforce it. The mistake that creates legal exposure is treating the floor as if it were a target — "keep everything as long as we can, just in case" — when privacy law treats the ceiling as the default and makes you justify every day below it.

Retention has a floor (must-keep) and a ceiling (may-keep), with the lawful window between them. Figure 1. Retention has a floor (how long you must keep footage) and a ceiling (how long you may keep it). The lawful window is the band between them.

The floor: how long you must keep footage

The floor is built from three sources, and it is the easier limit to reason about because it usually arrives as a concrete number or a concrete event.

Sector and jurisdiction rules. Some industries and regions set explicit minimums. New York's ATM Safety Act requires banks to preserve camera recordings for at least 45 days. Many US states set minimums for law-enforcement and government cameras — Illinois requires certain footage to be kept at least 90 days (two years if flagged), South Carolina sets a 14-day floor, and Georgia requires 180 days for some body-worn recordings. Private companies in most of the United States have no general legal minimum at all, which surprises people: the floor is often something you choose for operational reasons, not something the law imposes.

Legal hold. This is the floor that overrides everything else. The moment litigation becomes reasonably foreseeable — a serious incident, an injury, an HR complaint, a formal demand letter — a duty to preserve relevant footage is triggered, and a routine deletion that destroys that footage afterward can be treated as destruction of evidence. The practical pattern is to keep routine footage on a short cycle, then lift the specific clips that touch an incident out of the cycle and hold them separately until the matter closes.

Statute of limitations. Claims are not always filed quickly. A personal-injury claim might be brought up to two years after the event, depending on the jurisdiction. You do not keep all footage for two years to cover this; you keep the flagged clips that relate to a known incident. The general buffer and the incident clip are two different retention tracks, and conflating them is how systems end up holding terabytes they should have deleted.

The floor, then, is mostly event-driven. Apart from a few sector minimums, you do not need a long routine retention to satisfy it — you need a short routine retention plus a reliable way to flag and hold the rare clip that matters.

The ceiling: how long privacy law lets you keep it

The ceiling is set by data-protection law, and here the controlling idea is the storage-limitation principle. Under the GDPR, Regulation (EU) 2016/679, Article 5(1)(e), personal data must be kept "in a form which permits identification of data subjects for no longer than is necessary" for the purpose you collected it. Video of an identifiable person is personal data, so the clock applies to ordinary camera footage, not only to face recognition. The deeper treatment of why footage counts as personal data lives in GDPR for video surveillance; here the point is the time limit it creates.

The law does not name a number. Instead, the regulator's guidance fills in what "necessary" means in practice. The European Data Protection Board (EDPB) — the body that issues official GDPR interpretation — says in its Guidelines 3/2019 on video devices that, taking the data-minimisation and storage-limitation principles together, footage "should be erased after a few days in most cases", for example where the purpose is detecting vandalism. The longer you set the window, the heavier the justification you must carry: regulators treat anything beyond about 72 hours as needing a documented reason, and beyond 30 to 90 days as exceptional and purpose-specific.

The UK Information Commissioner's Office (ICO) frames it the same way for closed-circuit television (CCTV): there is no fixed period, you must set one based on your purpose, and you must be able to justify it. The shape of the rule is identical across the EU and UK — a short default, lengthened only by a reason you can defend.

Biometric data carries a stricter, more explicit ceiling. Illinois's Biometric Information Privacy Act (BIPA), 740 ILCS 14/15(a), requires any private entity holding biometric identifiers — a face template, for instance — to publish a written retention schedule and to destroy that data when the purpose for collecting it is satisfied, or within three years of the person's last interaction, whichever comes first. That is a hard statutory cap, not a guideline, and Illinois lets individuals sue over it. If your cameras run face recognition, the retention rule for the face templates is tighter and more enforceable than the rule for the plain video — the legal gate before that capability is covered in BIPA and US biometric privacy law.

The United States adds a procedural ceiling even where it sets no time limit. California's Consumer Privacy Act, as amended by the California Privacy Rights Act, requires a business to disclose how long it keeps each category of personal information, or the criteria it uses to decide — and a generic "as long as necessary" is treated as insufficient (Cal. Civ. Code §1798.100(a)(3)). The number can be yours, but you have to state it and stand behind it.

When the floor is higher than the ceiling

Sometimes the two limits collide: an evidence or sector rule wants footage kept longer than the privacy ceiling would normally allow. This is not an unsolvable contradiction; it is a documentation problem.

The resolution is to treat the long-retention case as a named exception, not as the default. Privacy law anticipates this. The GDPR's right-to-erasure article (Article 17) carries explicit carve-outs in Article 17(3): you may keep personal data that would otherwise be deleted where retention is necessary to comply with a legal obligation (17(3)(b)) or for the establishment, exercise, or defence of legal claims (17(3)(e)). A legal hold is exactly that second case.

So the pattern is: set the routine ceiling low, and when a specific clip needs to survive longer, move it into a separate, access-controlled hold with its own justification and its own end date. The 50,000 routine clips still expire on the short schedule; the one clip tied to an incident is retained under a documented exception. What you must never do is raise the routine ceiling for everything because a handful of clips occasionally need to live longer — that converts a narrow, defensible exception into a system-wide breach of the storage-limitation rule.

Setting a retention window you can defend

Putting the floor and the ceiling together gives a method, not a magic number. Work it in this order.

First, state the purpose of each camera or zone in one sentence — "detect and investigate theft at the loading dock", "monitor the lobby for after-hours intrusion". The purpose is what makes a retention period "necessary" or not.

Second, find the floor for that purpose: any sector minimum, the realistic window in which an incident would surface, and your legal-hold process for the exceptions.

Third, find the ceiling: the storage-limitation default for your jurisdiction (a few days to a few weeks for ordinary footage), and any hard biometric cap if analytics are running.

Fourth, pick a number inside the band and write it down, per camera group, with the reason. A loading dock with a real theft pattern might justify 30 days; a quiet corridor might need 72 hours. Different zones can and should have different windows.

Fifth, make the system enforce it automatically, so retention is a setting, not a person's monthly chore.

Decision flow: purpose sets the limits, pick a number between, document it, auto-enforce; legal hold is the exception. Figure 2. Setting a defensible window: purpose sets the floor and ceiling, you pick a number between them, document it, and let the recorder enforce it — with legal hold as the named exception.

Lawful deletion: what "delete" actually means

Here is the part most retention policies get wrong, because it is an engineering fact, not a legal one: pressing delete usually does not destroy the footage.

When software "deletes" a file, it normally just removes the directory entry — the pointer that says where the recording lives on disk. The bytes themselves stay on the drive until something else writes over them. Until that overwrite happens, ordinary recovery tools can bring the footage back. For surveillance, where the whole point of deletion is that the footage is gone, that gap matters.

The good news is that a well-built VMS already deletes the right way for routine footage, through a mechanism called circular or ring-buffer recording. The recorder treats its storage like a fixed-length tape loop: when footage reaches the end of the retention window — or when the disk fills — the oldest recording is overwritten by the newest. Deletion is not a separate action somebody remembers to run; it is the natural result of new video landing on top of old. Set the loop to your retention window and the system enforces the ceiling for you, overwriting as it goes.

For the cases where you must prove footage is unrecoverable — decommissioning a drive, honouring an erasure request, retiring a cloud bucket — the reference standard is the US National Institute of Standards and Technology (NIST) Special Publication 800-88, Guidelines for Media Sanitization. It defines three levels. Clear overwrites the data with new values, which defeats normal recovery and is enough for most reuse. Purge uses stronger methods — a firmware block-erase, or cryptographic erasure — that defeat even laboratory recovery. Destroy physically shreds or degausses the media so it can never be read.

Cryptographic erasure (crypto-shredding) deserves a special mention because it is how deletion works on modern flash storage and in the cloud, where you cannot reliably overwrite a specific physical location. You encrypt the footage at rest, and to "delete" it you destroy the encryption key. Without the key, the encrypted bytes are noise. This is fast and certain, and it is the practical way to erase data that is spread across solid-state drives and replicated cloud objects.

A routine delete removes the file pointer; Clear, Purge and Destroy sanitise; backups, replicas and exports survive. Figure 3. "Delete" has levels. Removing the index entry leaves recoverable bytes; overwrite (Clear), crypto-erase (Purge), and physical destruction (Destroy) actually sanitise. Backups, exports, and replicas are the copies a routine delete misses.

The hardest part of real deletion is the copies. The footage you want gone may also sit in a nightly backup, a disaster-recovery replica in another region, a clip an operator exported to a USB drive for an investigation, and a frame attached to an alarm email. A "delete" that clears the primary recorder but leaves these copies has not erased the data in any sense the law recognises. Lawful deletion means tracking every place a recording can travel and either bringing those copies inside the same retention clock or having a documented schedule that expires them too.

The right to erasure: deleting one person on request

Routine expiry handles the general case. A different obligation handles the specific one: an individual asking you to delete their data. Under GDPR Article 17, a person can request erasure of personal data concerning them, and the controller must comply without undue delay where one of the listed grounds applies — most commonly, that the data is no longer necessary for its purpose. California gives an equivalent right to delete under Civil Code §1798.105, which since 2026 also requires you to pass the deletion instruction on to service providers and third parties who received the data.

For continuous surveillance footage, this right runs into a physical reality. You usually cannot surgically cut one person out of a rolling recording that already overwrites itself every few days — and in many cases you do not need to, because the short retention window means their footage will self-delete almost immediately. Where erasure does bite is the derived and exported copies: a face template in an analytics database, a clip saved into a case file, a watchlist entry. Those are findable and deletable by subject, and they are where an erasure request actually lands.

Two practical constraints shape the response. The first is the deadline: GDPR Article 12(3) requires you to respond within one month of the request, extendable by two further months only for genuinely complex cases and only if you tell the person within the first month. "Respond" means tell them the outcome — done, or refused with reasons — not merely acknowledge receipt. The second is the exceptions already mentioned: Article 17(3) lets you refuse erasure where you need the data for a legal claim or a legal obligation. If a clip is on legal hold, you can decline to erase it, but you must say so and say why.

A right-to-erasure request reaches active footage, exports, templates and backups, then erases or invokes an exception. Figure 4. An erasure request has to reach every copy — active footage, exports, analytics templates, and backups — and resolve within one month, unless a legal-claims exception applies.

The design lesson is that erasure is feasible only if you know where personal data lands. A system that lets operators export clips freely, with no record of where they went, cannot honour an erasure request for those clips — it does not know they exist. Minimising what you derive and keep, and logging what you export, is what makes the right to erasure operable. The redaction techniques that let you release or retain footage while protecting bystanders are covered in face masking, redaction, and privacy-preserving analytics.

How storage tiers must honour the retention clock

Retention is not only a recorder setting; it has to survive the journey footage takes across storage. As recordings age, a cost-efficient system moves them from fast, expensive "hot" storage to cheaper "warm", "cold", and "archive" tiers — the economics of which are covered in storage tiers: hot, warm, cold, and archive. The retention rule has to travel with the data through every one of those moves.

The failure mode is the archive that never forgets. Footage migrates to cheap cold storage or a cloud archive bucket "to save money", the lifecycle rule that should delete it never gets attached, and years later you discover you are holding footage far beyond both your policy and the privacy ceiling — now sitting in the least-monitored, least-access-controlled part of your estate. Every tier, including the archive, must carry the original deletion date, and the lifecycle policy that moves data between tiers must also be the one that expires it. A clip that was due to delete on day 30 deletes on day 30 whether it is hot, cold, or archived.

Storage tiers from hot to archive each carry the same deletion date; the lifecycle rule deletes on schedule. Figure 5. The deletion date must travel with the footage across every tier. The lifecycle rule that ages data down should be the same one that expires it; an archive that loses its delete date is the classic over-retention trap.

This is why retention and storage architecture cannot be designed separately. The retention window decides the cost (more days means more terabytes), and the storage tiering decides whether deletion actually happens at the end of the window. Cloud object stores make this easy if you use them — lifecycle rules that delete or crypto-shred objects on a fixed age are exactly the mechanism the ceiling needs — and dangerous if you do not.

A worked example: the window and the math

Take a 40-camera retail site. Suppose analysis of the purpose — investigating theft and slip-and-fall claims that typically surface within three to four weeks — sets a routine window of 30 days, comfortably inside a defensible ceiling and above the practical floor. Each camera records H.265 video at about 4 Mbit/s.

Daily storage per camera is bitrate × seconds per day:

4 Mbit/s ÷ 8 = 0.5 MB/s
0.5 MB/s × 86,400 s/day = 43,200 MB/day ≈ 43.2 GB/day per camera

Across 40 cameras for the 30-day window:

43.2 GB/day × 40 cameras × 30 days ≈ 51,840 GB ≈ 51.8 TB

That ~52 TB is the steady-state footprint, and the ring buffer holds it flat: on day 31 the day-1 footage is overwritten by day-31 footage, so storage never grows past the window. The fuller bandwidth-and-storage derivation lives in the surveillance storage and retention math; the point here is that the retention number is the single biggest lever on that 52 TB. Doubling the window to 60 days "to be safe" doubles the storage to ~104 TB and doubles the privacy exposure, for footage you will almost never look at. The disciplined move is the opposite: keep the routine window at 30 days, and when one slip-and-fall clip needs to live longer, lift that single clip onto legal hold. You pay for one clip, not for 40 cameras' worth of extra weeks.

Common mistakes that create exposure

The recurring errors in retention and deletion are predictable, and each one is avoidable.

The first is treating the floor as the target — keeping footage "as long as we can" because storage is cheap, which inverts the legal default and turns the storage-limitation ceiling into a standing breach. The second is assuming delete means destroyed, when a routine delete only drops the file pointer and leaves the footage recoverable until overwritten. The third is forgetting the copies: clearing the primary recorder while backups, replicas, and exported clips quietly retain the data. The fourth is the immortal archive, where footage tiered to cold or cloud storage loses its deletion date and outlives every policy. The fifth is no legal-hold lane, so a system either deletes evidence it had a duty to preserve or, fearing that, keeps everything forever. A retention design that names the window, automates expiry, includes the copies, and carves out holds avoids all five.

Where Fora Soft fits in

Fora Soft has built video systems — surveillance, streaming, conferencing, and computer vision — since 2005, across 625+ projects, and retention is one of the first architecture decisions on a surveillance build, not a setting bolted on at the end. In practice we design the retention window into the recording and storage layer so expiry is automatic and provable: ring-buffer recording on the primary tier, lifecycle rules that delete or crypto-shred footage as it ages out of every tier including archive and backups, a separate legal-hold lane for the clips that must survive, and erasure tooling that can find a subject's derived data within the legal deadline. The framing we hold to is accuracy-vs-performance: a deletion you cannot prove happened is not deletion, and a retention number you cannot defend is a liability dressed up as a feature. We build the system so the honest answer to "is it really gone, and can you show it?" is yes.

What to read next

Call to action

References

  1. GDPR — Regulation (EU) 2016/679, Article 5(1)(e), storage limitation. European Union (consolidated text). https://gdpr-info.eu/art-5-gdpr/ — Personal data kept no longer than necessary for the purpose; the legal basis for the retention ceiling. Tier 1, read directly.
  2. GDPR — Article 17, right to erasure ('right to be forgotten'), incl. 17(2) and 17(3) exceptions. European Union. https://gdpr-info.eu/art-17-gdpr/ — The erasure obligation, the duty to inform other controllers, and the legal-obligation (17(3)(b)) and legal-claims (17(3)(e)) carve-outs. Tier 1, read directly.
  3. GDPR — Article 12(3), time limits for responding to data-subject requests. European Union. https://gdpr-info.eu/art-12-gdpr/ — One month to respond, extendable by two months for complex requests with notice. Tier 1, read directly.
  4. EDPB Guidelines 3/2019 on processing of personal data through video devices (v2.0, 2020), §8 storage periods and obligation to erasure. European Data Protection Board. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en — Footage should be erased "after a few days in most cases"; the official interpretation of storage limitation for cameras. Tier 1, read directly.
  5. Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14/15(a). Illinois General Assembly. https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004&ChapterID=57 — Written, public retention schedule and destruction of biometric data when purpose satisfied or within three years of last interaction, whichever first. Tier 1.
  6. California Consumer Privacy Act, as amended by the CPRA — Cal. Civ. Code §1798.105 (right to delete) and §1798.100(a)(3) (retention disclosure). California Privacy Protection Agency. https://cppa.ca.gov/regulations/pdf/ccpa_statute_eff_20260101.pdf — Right to delete with third-party notification, and the duty to disclose retention period or criteria per category. Statute effective 1 Jan 2026. Tier 1.
  7. NIST Special Publication 800-88 Rev. 1, Guidelines for Media Sanitization. US National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/88/r1/final — The Clear / Purge / Destroy model and cryptographic erasure; the reference for proving footage is unrecoverable. Tier 1, read directly.
  8. CCTV and video surveillance — storage limitation and complying with the data-protection principles. UK Information Commissioner's Office (ICO). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/cctv-and-video-surveillance/ — Regulator guidance that there is no fixed period, retention must be purpose-based and justifiable. Tier 1 (regulator guidance), read directly.
  9. Video surveillance retention minimums and the duty to preserve evidence (orientation). Sector summaries: New York ATM Safety Act (45 days); state law-enforcement minimums (Illinois 90 days, South Carolina 14 days, Georgia 180 days for some body-worn). https://ecam.com/security-blog/what-you-need-to-know-about-video-surveillance-retention-requirements — Orientation for the floor; named statutes are the tier-1 primary sources. Tier 5 aggregator over tier-1 statutes.