Corrections firstExisting camerasEarlier awarenessFaster responseStructured proofSafety Intelligence Corrections firstExisting camerasEarlier awarenessFaster responseStructured proofSafety Intelligence

General operational and educational information for corrections professionals. Not legal, medical, or compliance advice, and not a certification of compliance with any law or standard. Policies and standards vary by agency and jurisdiction; follow your facility's policy and your own legal, medical, and professional advisors.

// Library / Start here

Start Here: Safety Intelligence for IT and Security Teams

A monitoring layer on a jail camera estate is a normal system-integration problem with an abnormal data class. The questions are the usual ones about network, access, logging, and failure behaviour. The difference is that correctional video is sensitive, discoverable, and governed by policy, so the answers need to be in writing before anything is connected.

// What you are actually integrating with

The realistic starting position at a county jail is a mixed camera estate accumulated over a decade. Some modern IP cameras, some analog behind encoders, a recorder that may or may not be current, and documentation that is incomplete.

The first technical task is therefore an inventory: what exists, what it actually sees, what protocols it speaks, and which cameras are working. Facilities are routinely surprised by how many cameras are recording something other than what the site map says.

Expect the honest answer on some cameras to be that they cannot be integrated or that the image is unusable. A vendor that claims every camera in a mixed estate will work is not describing the estate you have.

// Settle these before connecting anything

Network placement. Which VLAN the camera estate lives on, whether outbound connectivity is permitted from it, and what is required at the firewall.

Processing location. Whether analysis happens on premises or off, and what data classes leave the building if any.

Access control, specified separately for live view, recorded view, and export. Export rights are the item most often left undefined, and an export without an audit trail is a future problem.

Authentication and whether it federates with county identity, plus the offboarding process for departed users.

Logging: what is logged, where logs live, retention, and whether export actions are captured.

Failure behaviour. If the link drops or a service stops, the existing camera and recording system must continue operating as it does today, and staff procedures must not depend on the added layer being up. Get this in writing.

// Security review items

Where a deployment touches systems in scope for criminal justice information policy, the applicable requirements are set by your state control agency and your local policy. That determination is theirs, not a vendor's, and no general vendor certification substitutes for it.

Ask for architecture and data-flow documentation at a level your reviewer can actually evaluate, not a marketing diagram.

Ask for patch cadence, who initiates, the maintenance window, and whether an update can change behaviour the agency depends on.

Ask for the incident response commitment in writing: notification timeline, named contact, and what the vendor will and will not do during an investigation.

Ask about physical security for any on-premises appliance, and about end of contract: who holds what data, in what format it is returned, and the deletion commitment.

Ask whether personnel screening is required for anyone with access, including vendor personnel, and what that process is.

// Where Safety Intelligence fits

Virtual Patrol is designed to consume existing camera streams and add a review and record layer, with a person reviewing every raised event before any action. No facial recognition is used, which removes a set of consent and civil rights questions that would otherwise belong in your review.

It supports documentation, discipline, review, and proof. It does not make any agency compliant with any security or correctional standard and does not certify compliance.

Specific architecture, hosting, data flow, and control details should be provided in writing for your security reviewer and evaluated against your own requirements. Ask for that documentation early rather than at contract signature.

The security posture page and privacy by design cover the design principles. Route the specifics through your normal review.

// Frequently asked

Do we need to replace our cameras?

Usually not. Individual cameras with unusable image quality or unsupported protocols may not be integrable, and that should surface during inventory rather than after contract.

Does this meet CJIS requirements?

No vendor can answer that for your agency. Requirements are applied by your state control agency and your local policy. Route the documentation through your normal security review.

What is the most commonly underspecified item?

Export rights and offboarding. Agencies define view access carefully and leave export and departed-user removal undefined.

What happens if the service goes down?

Your existing camera and recording system should continue operating as it does today. Confirm the specific failover behaviour for your deployment in writing.

Is facial recognition used?

No.

What happens to our data at end of contract?

Get the return format, the deletion commitment, and the timeline into the contract rather than into a conversation.

Request a Safety Intelligence Audit   Back to the Library
// Related
Security posture in correctional deployments → Privacy by design → Working with existing cameras → The platform → Transparency → Start Here: Safety Intelligence for Jailers → Start Here: Safety Intelligence for Sheriffs → Start Here: Safety Intelligence for County Judges and Exec →