Skip to main content

Security & Evidence Integrity

Sift Evidence is built for criminal-justice evidence. This page explains how Sift Labs protects agency data, preserves source evidence, and supports security review by prosecutor offices and public-sector IT teams.

For how we govern AI use, human review, model limitations, and appropriate use in criminal justice workflows, see our AI Ethics page.

Security posture at a glance

  • Original evidence is preserved; edits happen on working copies.
  • Evidence and customer data are encrypted in transit and at rest.
  • Access is role-based, least-privilege, and limited to authorized users.
  • Security-relevant and evidence-relevant actions are audit logged.
  • Customer production data is hosted in U.S.-based cloud infrastructure.
  • Controls are designed to support CJIS-aligned agency review.

Evidence integrity

Original files are not modified by normal editing workflows. Sift Evidence works from preserved source evidence and generates working copies and exports from recorded user actions and system operations.

  • Source evidence remains separate from working copies and exports.
  • Exports are produced through reviewable user workflows.
  • Edits and exports are attributable to users and timestamps.
  • Audit trails are designed to support a defensible chain of custody.

Encryption and data protection

Evidence, exports, databases, and supporting storage are designed to be encrypted at rest. Traffic to customer-facing services is encrypted in transit. Production data is hosted in U.S.-based cloud infrastructure.

We separate source evidence, working copies, exports, audit records, operational logs, and telemetry so security controls can be applied according to the sensitivity and use of each data type.

Access control

Access to agency data is scoped to authorized users and roles. Sift Labs applies least-privilege principles to administrative access and limits production access to the people and systems that need it to operate, support, secure, or troubleshoot the service.

  • Customer users access agency data through authenticated application workflows.
  • Administrative access is restricted and used for operational purposes.
  • Secrets and credentials are managed outside source code.
  • Access patterns are designed to be reviewable during agency security assessment.

Data isolation

Sift Labs designs customer deployments around clear agency data boundaries. For prosecutor offices, that means separating agency data at the application layer and, where deployment architecture requires it, through dedicated infrastructure boundaries for databases, object storage, network access, and encryption.

The goal is simple: one agency should not be able to see another agency's evidence, and a security or operational issue should have the smallest practical blast radius.

Audit logging

Sift Evidence records security-relevant and evidence-relevant events so agency administrators can understand who acted, what changed, and when it happened. Logs are designed to capture events and attribution, not to duplicate sensitive evidence content unnecessarily.

  • User actions that affect evidence workflows are attributable.
  • System operations that create outputs are recorded.
  • Security events are available for investigation and review.
  • Preserved originals and audit trails work together to support chain-of-custody review.

CJIS-aligned review

The FBI does not issue a general "CJIS certification" badge for software vendors. Criminal justice agencies are audited against CJIS requirements, and vendors support that process through controls, documentation, agreements, and operational practices.

Sift Labs designs Sift Evidence to support CJIS-aligned agency review. We can provide security documentation, data-flow explanations, access-control descriptions, encryption details, incident-response information, and other materials an evaluating agency may require.

Where required by an agency, Sift Labs will work through the appropriate CJIS Security Addendum and agency security review process.

Vendor and AI data controls

Sift Labs reviews vendors and subprocessors based on the type of data they may support. We do not treat all data the same: raw evidence, case data, operational logs, analytics, and marketing-site information have different sensitivity levels and different controls.

Raw evidence video, audio, and frames are not casually sent to uncontrolled general-purpose AI tools. For our broader AI-use commitments, see our AI Ethics page.

Secure development and operations

Security is part of how Sift Labs builds and operates Sift Evidence. Our practices include code review, dependency management, environment separation, secrets management, restricted production access, security-focused testing, monitoring, and incident response planning.

We continue to update our controls as customer requirements, public-sector standards, court expectations, and security research evolve.

Frameworks and standards

Sift Labs tracks recognized public-sector and security guidance, including the FBI CJIS Security Policy, NIST Cybersecurity Framework, and NIST AI Risk Management Framework. These references are not badges or certifications; they are control frameworks we use to shape engineering, deployment, and review.

Accessibility

Sift Evidence is built to meet WCAG 2.2 Level AA. A VPAT / Accessibility Conformance Report is available on request. Learn more.

Questions from your security team?

Connect with us