Security status

Chirp Security Status: Preparing for Pilot

Chirp is preparing to launch a limited pilot program with a small cohort of law enforcement agencies. Our security program is actively implemented and validated ahead of that launch. Some controls described on this page are operational today; others are scoped to complete before pilot onboarding begins.

We distinguish clearly between what’s operational now, what’s in progress, and what’s planned. We will not claim a certification or independent validation we have not actually obtained.

“Operational” reflects the environment used for the Chirp pilot program. Some controls achieve Operational status upon our planned migration to AWS, completed ahead of pilot onboarding.

Status legend
Operational

Live and enforced today.

In Progress

Actively being implemented.

Planned

Scoped to complete before pilot onboarding.

Independently Validated

Confirmed by an independent third party.

Last updated: October 13, 2026

Overview

Landing overview

Security is part of the product, not an afterthought.

Chirp is built for public-safety organizations, where communications may involve sensitive operational information. Security, accountability, and controlled access are foundational requirements of the product, not features layered on after launch.

We take a defense-in-depth approach spanning application security, infrastructure, identity, data protection, monitoring, and operational controls.

Chirp is currently preparing for a limited pilot program and continues active security and compliance development ahead of that launch. We do not represent that Chirp has completed independent SOC 2 Type II examination or CJIS certification. Our current posture and roadmap are described in full below.

Capabilities

Security capabilities

Encryption

  • TLS for all data in transit

    Operational

  • Encryption at rest for customer data

    Operational

  • Managed key infrastructure (customer-held keys)

    Operational

  • Encryption of integration credentials and webhook secrets

    (operational today, independent of AWS)

    Operational

  • Secrets never stored in source control

    Operational

Identity

  • Passkey-based, phishing-resistant authentication required for every named account

    Operational

  • Role-based access control across both agency and platform tiers

    Operational

  • Session timebox and freshness enforcement, not just a login check

    Operational

  • Administrative access controls, enforced at multiple independent layers

    Operational

Application security

  • Tenant isolation

    Operational

  • Authorization enforcement

    Operational

  • Protection against injection-style attacks, enforced uniformly across all database access

    Operational

  • General input validation

    In Progress

  • File upload restrictions

    Operational

  • Dependency and library updates on a semi-annual cadence, vulnerabilities patched by severity

    Operational

  • Code review / protected branches

    Planned

Monitoring

  • Security event logging, authentication event logging, audit trail

    Operational

  • Administrative activity logging

    In Progress

  • Alerting for security-relevant events

    Operational
Data protection

How Chirp Protects Data

What Chirp stores

  • User account and profile information
  • Agency information
  • Incident channel metadata
  • Messages
  • Attachments (images, PDF documents, and voice memos)
  • Tactical documents, where created by the customer, for tracking subjects, vehicles, and related investigative details
  • ALPR alert data from a customer’s own existing vendor integration, including any vendor-supplied alert image, where that customer uses the feature
  • Audit and security event records

Chirp is not an ALPR vendor. Chirp does not operate cameras or any detection infrastructure, and has no independent capability to generate plate reads of its own. Alert data only ever enters Chirp from a customer agency’s own, separately-held vendor contract, never the reverse, Chirp never writes hotlist entries, plate data, or any other information back to a vendor. Data from one agency’s vendor integration is never shared with another agency, or combined into any broader network, except where two specific agencies explicitly, mutually opt in to cross-agency visibility for active incident coordination. There is no default sharing and no data-broker relationship of any kind.

Who can access it

Access within an agency follows the roles that agency’s own administrators configure, named users see the incidents and information relevant to their role, anonymous participants see only the single incident they were invited into, nothing else.

Can Chirp employees access customer data? Does Chirp have access to customer messages?

No.Tenant isolation is enforced at the database level through Row Level Security, not application logic alone, and verified by an automated isolation test suite run on every build. Chirp staff, at every support tier, are structurally restricted from ever accessing message content, tactical document content, or participant identity, this is enforced by what the underlying system is permitted to return, not a policy employees are trusted to follow. This boundary applies identically across every tier of platform access, including the most senior. It has also been directly, adversarially tested against our own staff access model and confirmed to hold.

Retention and deletion

Customer agencies control how long their own data is retained, within the bounds of applicable law. Closed incidents become eligible for deletion on a defined schedule, and an agency can request deletion of specific records before that schedule completes. Deletion actions are logged.

Data lifecycle

Data Lifecycle

  1. 1

    Create

    Incident data is created by named users and invited participants within a controlled, single-incident workspace. Each incident is isolated to the agency and people involved in it.

  2. 2

    Transmit

    Data moving between a user’s device and Chirp’s servers is protected using encrypted communications.

  3. 3

    Store

    Data is stored using encryption-at-rest capabilities provided by our infrastructure.

  4. 4

    Access

    Access is restricted through authentication and authorization controls, enforced at the database level, not just the application. What an individual can see is governed by their role, within their agency, within a specific incident.

  5. 5

    Audit

    Security-relevant activity, including access, changes, and administrative actions, is recorded in an append-only audit log.

  6. 6

    Retain

    Data is retained consistent with 28 CFR Part 23 and applicable records-retention requirements, for a defined period following an incident’s closure. An incident cannot be purged while still active, closure always comes first.

  7. 7

    Delete

    At the end of the retention period, data is deleted automatically.

    Before that point, an agency can request deletion of specific records manually:

    • During an active incident — by anyone with edit rights.
    • After an incident closes — by the incident’s creator or an agency administrator, with a documented reason recorded for each deletion made after closure.

    Every deletion is logged.

Public safety

CJIS & Public Safety

Designed for Public Safety

Chirp is built from the ground up for the operational and security requirements of law enforcement and public-safety organizations, not adapted afterward from a general-purpose product.

CJIS

CJIS alignmentIn Progress

Chirp’s security program incorporates requirements relevant to the FBI Criminal Justice Information Services Security Policy. We are continuing to implement and validate the administrative, technical, and physical safeguards necessary to support agencies handling Criminal Justice Information. A CJIS Security Addendum is executed directly between Chirp and each agency, as required, before any live CJI is entered into the system.

Chirp does not represent that it has completed an independent CJIS assessment, certification, or authorization.

No such certification currently exists for any vendor, from any authority.

28 CFR Part 23

In Progress

Chirp’s retention and deletion architecture is built around the requirements of 28 CFR Part 23 for criminal intelligence systems, not retrofitted to accommodate them. See Data Lifecycle, above.

Assurance

SOC 2 & GovRAMP status

Today

SOC 2 Type II
In Progresscontrol environment in development
Plannedformal examination not yet started

We are actively building and operating the control environment a future SOC 2 Type II examination would assess, tenant isolation, access controls, audit logging, encryption, and incident response among them. We have not yet engaged an independent auditor or begun a formal observation period.

GovRAMP

GovRAMP authorizationPlanned

GovRAMP (formerly StateRAMP) is the standardized security verification framework used by state and local government buyers, with a dedicated CJIS-Aligned Overlay specifically for law enforcement technology vendors. Chirp intends to pursue GovRAMP authorization, beginning at the Progressing Security Snapshot stage, following our planned AWS migration. Chirp does not currently hold any GovRAMP status.

Assurance summary

AssuranceStatus
SOC 2 Type II (control environment)In Progress
SOC 2 Type II (formal examination)Planned
SOC 2 Type INot currently pursued
CJIS alignmentIn Progress
GovRAMP authorizationPlanned
Independent penetration testingPlanned
Security programOperational

Last updated: October 13, 2026

Response

Incident Response

Chirp maintains a formal Incident Response Plan, grounded in NIST SP 800-61 and the FBI CJIS Security Policy, designed to identify, contain, investigate, remediate, and communicate security incidents.

Response lifecycle

  1. 1Detection and monitoring
  2. 2Classification, by severity and scope
  3. 3Containment and eradication
  4. 4Investigation and root-cause analysis
  5. 5Recovery
  6. 6Customer and regulatory notification
  7. 7Post-incident review and corrective action

Notification

Where an incident involves unauthorized access to or acquisition of customer data, Chirp notifies the affected agency’s designated security contact without undue delay following confirmation of the incident, consistent with our contractual commitments. Where required, Chirp also notifies the applicable state CJIS Systems Agency within the timeframe required by the CJIS Security Policy.

Status

Incident Response PlanOperational
Formal tabletop testing cadenceIn Progress
FAQ

Security FAQ

Is Chirp CJIS compliant?

Chirp is being developed to support agencies operating under CJIS requirements. Our CJIS-aligned security program is currently under development. Chirp does not currently represent that it has completed an independent CJIS assessment or authorization.

Is Chirp SOC 2 certified?

SOC 2 is an independent examination report, not a certification. Chirp has not yet completed a SOC 2 Type II examination. We are actively building the control environment such an examination would assess.

Where is customer data stored?

Chirp is hosted on AWS Commercial infrastructure. Customer data is stored within Chirp’s dedicated production environment, protected by encryption and access controls.

Can Chirp employees access customer data? Does Chirp have access to customer messages?

No. Tenant isolation is enforced at the database level, not application logic alone, and Chirp staff at every tier are structurally restricted from accessing message content, tactical document content, or participant identity. This boundary has been directly, adversarially tested against our own staff access model and confirmed to hold.

Is customer data used to train AI models?

No. Chirp does not use customer data to train any AI model, and has no AI features planned for the product.

Does Chirp sell customer data?

No. Chirp does not sell or share customer data with third parties.

Has Chirp undergone independent penetration testing?

Not yet. Independent penetration testing is planned, with no date currently set.

Commitments

Security Commitments

  1. 1Customer data belongs to the customer.
  2. 2Access is granted according to role, agency, and demonstrated need, never by default.
  3. 3Security-relevant activity is logged and reviewable.
  4. 4Data is protected in transit and at rest.
  5. 5We collect and retain only what the product requires to function, on a defined, lawful schedule, not indefinitely.
  6. 6We do not use customer data to train AI models, and have no AI features planned.
  7. 7Security incidents are investigated and communicated according to our contractual obligations.
  8. 8We continuously test and improve our security controls, including against our own staff access model.
  9. 9We will not claim a certification or independent validation we have not actually obtained.