Incident Video Management for Security Companies — A Practical Guide

Incident video management is the workflow of pulling a clip out of a VMS (Milestone, Genetec, Avigilon, Hanwha, Exacq, Eagle Eye, or similar), packaging it as evidence, and delivering it to a customer, a police agency, or an insurance adjuster — with controls over who can see it and for how long. For security monitoring companies, this workflow runs through cameras 24/7 — and the tooling that surrounds it usually doesn't. This guide walks through what the workflow actually looks like, where it breaks, and what to look for in a tool that fixes it.

If you'd rather skip to the product side, Incident Clips is built specifically for this workflow.

The standard workflow (and why it's painful)

A typical incident response looks like this:

1. A customer emails after an incident — usually with a rough time window and a request like "send me everything from the back parking lot Tuesday night."
2. An operator logs into the VMS, scrubs the relevant cameras around the time window, and exports the clip(s) using the VMS's native export tool.
3. The clip lands on a workstation, often as a proprietary format (.cam, .dav, .mkv, .exe-wrapped players from older systems) or as an MP4 if the exporter supports it.
4. The operator opens an editor (frequently free tools like VLC, ShotCut, or the VMS's built-in trimmer) to cut the relevant portion and convert it to something the customer can actually open.
5. The operator uploads the result to Google Drive, Dropbox, WeTransfer, or attaches it to an email — and types out a description of what's in it.
6. The customer asks for a different angle, or a longer clip, or a still frame for an insurance form. Steps 2–5 repeat.

Multiply that by a few customer sites and a few requests per week, and you have a workflow that costs hours per incident and produces files no one knows the provenance of after the fact.

Where this workflow breaks

A few specific failure modes show up consistently:

• Inbox archeology. Three weeks later, when an insurance adjuster asks for "the clip you sent us in March," nobody remembers which clip, which email, or which Drive folder.
• Permission sprawl. Files shared as "anyone with the link" on Drive or Dropbox often outlive their useful life. A clip shared for an active investigation becomes an indefinite public link.
• Re-exports. Customers ask for slight variants — a longer window, a different camera angle, a still frame — and each one is a fresh round-trip through the VMS.
• Format incompatibility. A .dav from a Dahua-based recorder won't play on a tablet at the responding officer's car. The codec / container conversation alone burns time on every request.
• Chain of custody. When footage ends up in a deposition or a subrogation claim, the lack of access logging becomes a real problem — see our guide to chain of custody.

What "incident video management" actually means

A purpose-built tool sits next to your VMS (not in place of it), and owns the part of the workflow that starts after the export and ends when the recipient has what they need. At minimum it should handle:

• Ingestion of exported footage as standard MP4/MOV/MKV — transcoded once to a streaming-friendly format (HLS with H.264 is the default for compatibility; H.265 where storage matters and the playback client supports it).
• Clip and still-frame generation from the ingested file, without re-exporting from the VMS.
• Packaging clips, stills, and notes into a single shareable case file with an access code, an expiry, and an audit log.
• A customer-facing portal so customers can request and access their own clips without your operator becoming the bottleneck.

What to look for when evaluating

If you're evaluating whether to build this workflow on top of existing file-sharing tools (Drive, Dropbox, WeTransfer) or move to a purpose-built tool, here are the questions that matter most. We've written full comparisons for each common alternative — see Incident Clips vs Google Drive, vs Dropbox, and vs WeTransfer.

| Capability | Why it matters | | --- | --- | | Per-recipient access codes | Drive/Dropbox links typically don't gate on a code; once leaked, the link is open. | | Time-boxed access (expiry, view-count caps) | Investigative footage shouldn't outlive the investigation. | | Per-customer isolation | One operator should not be able to send Customer A's footage to Customer B's portal. | | Audit log of opens | Required for any deposition or subrogation work. | | Native clip + still generation | Avoids round-trips through the VMS for every variant. | | Branded customer portal | If you're white-labeling for your customers, the viewer needs to match. | | HLS / adaptive streaming | A police officer on a tablet over LTE will not download a 4 GB MP4. | | Encryption in transit + at rest | Table stakes; verify both. |

A note on chain of custody

The phrase "chain of custody" gets used loosely, but it has a specific meaning when footage ends up in court: a continuous, documented record of who had access to the original and any derivatives, when, and what they did with it. Email and shared drives can't produce that record after the fact. Any tool you adopt should produce it as a byproduct of normal use — see our chain of custody guide for what that record needs to contain.

When the email + Drive workflow is fine

To be honest about it: if your operation handles a single-digit number of clip requests per month and your customers are technically savvy, the email + Drive workflow is workable. It starts to fall apart somewhere around 25 customer sites or a few clip requests per week — that's the point at which the lack of structure starts costing real operator hours and creating real audit gaps.

Getting started with Incident Clips

Incident Clips is built for the workflow above, designed for security monitoring companies running between 25 and several hundred customer sites. The pricing page has full details; the contact form is the fastest way to get a tailored walkthrough.