Sharing security camera footage with police is straightforward in theory and broken in practice — most of the friction comes from format choices, file size, and the lack of an audit trail when the case turns into a deposition months later. This guide is a practical, step-by-step on how to package and deliver footage to law enforcement so it plays the first time, preserves evidentiary value, and produces a record you can defend later. For the broader workflow context, start with our guide to incident video management.
Step 1 — Confirm what the officer actually needs
Before exporting anything, ask the requesting officer or detective:
- A single clip, or multiple camera angles?
- A specific time window, or "as much context as you have"?
- Still frames as well, for a report or a BOLO?
- The original VMS export, or a viewable MP4?
The answer drives the rest of the workflow. A patrol officer responding the same night usually just wants a playable MP4 of the incident. A detective working a follow-up two weeks later often wants the original export plus contextual angles. Asking up front saves a round of "can you also send..." emails.
Step 2 — Export from the VMS in a portable format
The single biggest cause of "I can't open this file" is proprietary export formats from the VMS:
- Send: MP4 container, H.264 video. Plays everywhere.
- Avoid sending:
.dav,.cam,.bsf,.exe-wrapped self-playing exports, or proprietary player ZIPs. - If the VMS only exports proprietary formats, transcode to MP4 before sharing. Most VMS platforms (Milestone, Genetec, Avigilon, Exacq, Hanwha) support MP4 export natively — check the export dialog.
For deeper detail on format choices and codecs, see our best practices for incident clips.
Step 3 — Preserve timestamps
The timestamp is what turns a clip from "footage" into "evidence." Specifically:
- Keep the burned-in timestamp on the frame, if your VMS supports it.
- Record what time zone the camera is set to. Many systems run on local time; some integrators set everything to UTC.
- If the camera's clock has drifted — replaced battery, NTP misconfiguration — document the actual time versus the recorded time when you hand off the clip.
Don't ever edit the timestamp burn-in to "fix" a drift. Document the drift separately in writing and deliver the original-timestamp clip. Altering the timestamp invalidates the footage as evidence.
Step 4 — Include context on both sides of the incident
A common mistake is trimming too tightly. Aim for:
- 30–60 seconds before the incident — normal conditions, establishing the scene.
- The complete event, with no internal cuts.
- 30–60 seconds after — response, departure, immediate aftermath.
If storage and bandwidth allow, lean toward sending more context rather than less. A clip that's longer than strictly necessary is much easier to deal with than one that arrives missing the moment of interest.
Step 5 — Generate stills from the delivered clip
When the officer asks for a still — for a BOLO, an offense report, or a court exhibit — pull it from the clip you're delivering, not from a separate VMS pull. This keeps the still and the video derivable from the same source.
Practical details:
- Export the highest-resolution single frame your source supports.
- Include the timestamp in the filename, and ideally in a visible burn-in on the image.
- Don't denoise, sharpen, or "enhance." Anything that alters pixels can be challenged.
Step 6 — Share via a code-gated link, not a public URL
Email attachments and "anyone with the link" Drive shares are the two most common ways to deliver footage. Both have the same problem: no expiry and no access log.
A better default:
- A link to a hosted package, gated by an access code.
- An expiry date or view-count limit.
- An audit log of every open.
- The ability to revoke access at any time.
This is what tools like Incident Clips produce by default. If you're using Drive, Dropbox, or WeTransfer instead, see Incident Clips vs Google Drive and vs WeTransfer for what you lose at each step.
Step 7 — Keep a record of every open
The access log produced at delivery time is the start of a chain of custody record. It should capture, at minimum:
- Who created the package, and from what source footage.
- When each access link was issued, and to whom.
- Every open of the package — timestamp, IP, viewer identity if available.
- Whether download was enabled, and any downloads that occurred.
Email and shared drives can't produce this record after the fact. The right time to start it is the moment the clip is exported. Our chain of custody guide goes into more detail on what the record needs to contain.
When email + Drive is actually fine
To be honest about it: if you're sharing one clip a quarter and the responding officer is standing in your lobby asking for a copy, email or a USB stick is fine. The structured workflow above starts to matter when you're handling clips for multiple incidents per month, across multiple customer sites, with an expectation that the footage might surface in a deposition six months later.
Where Incident Clips fits
Incident Clips does the seven steps above as a single workflow — ingest the original export, trim and pull stills inside the tool, package with a description, share via a code-gated portal with a built-in audit log, and keep the original on file in case a re-cut is requested. See pricing or contact us for a walkthrough.