Get a Demo

Legal

COBRA Product Privacy Notice

The personal data held inside a COBRA deployment, and how it is handled.

Version 1.0 · Effective August 12, 2026

Who this notice covers

COBRA is emergency management software, operated by the institution that licenses it. That institution decides who has access, what is entered, and what COBRA is used for. Dynamis, Inc. builds and hosts COBRA and processes the personal data held in a deployment on the institution's behalf and under its instruction, for no other purpose. In data protection terms, the institution is the controller and Dynamis is the processor.

This notice covers personal data inside a COBRA deployment. It is written for the people whose data that is, and for the security and privacy reviewers assessing COBRA on their behalf. You can appear in a COBRA deployment without ever having used COBRA or visited this website.

If you have a question about your own data, contact the institution operating the deployment first. They hold it, they can action requests directly, and they are the party the law places the obligation on. We support them under our agreement with them.

A separate website privacy statement covers people who browse cobrasoftware.com. It does not describe the product, and this notice does not describe the website.

What personal data COBRA holds

The categories below come from the COBRA data model, so they describe what the platform actually stores rather than what a questionnaire asked about.

Account records

Held for each person granted access to a deployment: name (given, family, display, and suffix), primary email address, and optionally an alternate email address, telephone numbers, a postal address, and employer, department, job title and office. Alongside them sit a directory identifier linking the account to the institution's identity provider, interface and notification preferences, active status, and created and modified timestamps with the acting user for each. Passwords are not among them: authentication is handled by Microsoft Entra External ID, and no password material of any kind is stored in COBRA or its database.

Access and role records

Which roles a user holds in which organization, the role currently selected, and any primary or secondary position assigned to them within an event. These authorize access and attribute actions to a position.

Operational content authored by users

Logbook entries, in-platform chat messages, tasks and task comments, map annotations, event points, status board content, uploaded files and their names, descriptions and notes, and addresses attached to logbook entries and facilities. This is the category an institution's own practice fills, and it is the subject of the next section.

Location data

Map locations recorded against logbook entries, files, resources, facilities and annotations, and, where an institution has enabled it, records from tracking devices. Covered in more detail below.

COBRA AI records

The question a user asked and the answer returned, recorded against the event and the user. Covered in more detail below.

Audit records

An entry for changes made through the application, capturing the acting user, the acting position, the action, the affected record, the tool, the time, and up to four descriptive text values, so an institution can reconstruct who did what during an incident. Notification records and each user's notification subscriptions are held alongside them.

Telemetry

Client IP address, request paths, timing and error information, collected to operate the service and diagnose faults, with retention configurable per deployment. Sign-in and sign-out events, including the originating IP address and the authentication method, are held in the institution's identity tenant under that platform's retention. COBRA uses no advertising or marketing tracking technologies, performs no cross-site tracking, and shares no telemetry with advertising networks.

Free text is the main route by which third parties appear

Institutions control what their staff type, and COBRA does not constrain it. Logbook entries, chat messages, task comments, map labels and uploaded files are free-form, and during an incident they routinely name people and describe their circumstances.

So a COBRA deployment can hold personal data about someone who has never used COBRA: a member of the public named in an incident narrative, a person visible in a photograph attached to a report, a residential address recorded as an incident location, an individual's email address held as a facility contact.

We state this plainly because it is the single most important thing to understand about personal data in COBRA. The platform does not decide what goes into those fields. The institution does, through its own procedures and training.

What COBRA does not collect

COBRA provides no field for any of the following, and does not collect or store them:

Demographic, genetic and biometric attributes are absent from the COBRA data model altogether. There is no such field to populate, and no configuration setting that adds one.

One qualification, which follows from the section above: this describes the fields COBRA provides. Free-text fields accept whatever a user types, so the absence of a field is not a guarantee that nothing of this kind was ever typed into a logbook entry. Institutions govern that through their own procedures.

Location and tracking

COBRA records map locations against logbook entries, uploaded files, resources, facilities and map annotations. These are ordinarily the location of an incident or an asset rather than of a person, though an incident location can be a residential address.

Separately, COBRA supports tracking devices, which hold a serial number, a display name, and a time series of position readings with timestamps. Stated plainly: where a device is carried by a person, those readings are a location history for that person.

Tracking is off unless an institution turns it on. It is controlled by a single per-institution setting, and where it has not been enabled, no such records exist.

COBRA AI

COBRA includes an assistant that answers questions about the incident a user is working on.

What is stored. The question asked and the answer returned, recorded against the event and the user in the institution's own database, and written to the audit trail so AI use during an incident is reviewable. Intermediate lookups the assistant performs are not stored.

What it can reach. The request sent to the model is assembled from the current event only. The assistant has a small, fixed set of read-only lookups, each constrained to that event, and it cannot use one the signed-in user's role does not already permit. It cannot write data, and conversation history does not carry from one event into another.

Training. COBRA AI runs on Microsoft Azure OpenAI. Microsoft does not use inputs or outputs to train, retrain or improve any model, shared or otherwise. There is no mechanism by which one institution's content reaches a model used by anyone else.

Provider-side retention. Azure applies content filtering and abuse monitoring by default. Under that configuration Microsoft may retain prompts and responses for a limited period for abuse review, accessible only to authorized Microsoft personnel and only following a flagged policy violation. We state it because it is a real exception to everything staying in the institution's own database. An exemption from abuse monitoring can be applied for.

Turning it off. COBRA AI can be disabled for an entire deployment with a single setting, in which case no request reaches a model at all. It can also be withheld from individual users through the role permission model.

Sub-processors

Dynamis uses these providers to deliver COBRA:

The Azure region a deployment runs in is selected at onboarding. The AI model deployment uses an Azure data zone configuration, which processes requests within a defined geographic data zone rather than a single named region; the applicable zone is confirmed at onboarding.

Retention and deletion

Personal data in a COBRA deployment is retained for the term of the institution's agreement, to support its emergency management operations. Retention and deletion terms are set in that agreement rather than by this notice.

Two things are worth stating plainly.

Deleting a record inside COBRA is a logical operation.Core tables are system-versioned, which preserves prior values rather than only the fact that something changed. Where a user edits or deletes a record, the earlier version remains in the history table for the term of the agreement. That is deliberate, and it is what lets an institution reconstruct an incident afterwards. It also means deletion in the application is not destruction.

Permanent destruction is handled at the deployment level.In the Cloud+ deployment tier, where each institution has its own dedicated Azure subscription, deletion at termination is performed by destroying the dedicated resources: the databases and their system-versioned history, the storage accounts, the identity tenant and the AI resource.

Your rights, and how to exercise them

Users can view and update their own profile information in COBRA at any time.

Everything else goes through the institution. An administrator at the institution operating the deployment can action access, correction and deactivation requests on a user's behalf, and can retrieve the records held about a named individual. This is the right route rather than a redirection: they hold the data, they know their own records, and the obligation sits with them.

Access within a deployment is restricted by role and permission, and is confined to the organization and the event a user is working in.

If you are not sure which institution holds your data, or the institution needs us, write to us and we will help.

Contact

Email support@cobrasoftware.com with any question about this notice or about personal data in COBRA. It is monitored, and privacy enquiries are routed from it.

Dynamis, Inc.
3130 Fairview Park Dr., Suite 300
Falls Church, VA 22042
+1 (703) 465-4400

If you are asking about your own data, please contact the institution operating the COBRA deployment first. We will normally have to refer the request to them.

About this notice

Version 1.0. Effective August 12, 2026.

This notice condenses the COBRA Personal Data Inventory, version 1.0, which is derived from the COBRA data model and is available to customers and their reviewers on request. A COBRA Data Security Information Paper covering hosting, encryption, identity, logging and deletion is available on the same basis.

The address of this page is permanent, and can be cited in vendor questionnaires and agreements. We will update the page when what COBRA stores changes, and raise the version above when we do.