← 10-19 Command

10-19 Command Privacy Policy

Last Updated: October 26, 2026

Effective Date: October 26, 2026

Two Things to Know First

Agencies must keep their own official records. 10-19 Command is an operational aid. It is not your system of record. Each Agency should maintain the operational records it is required to keep, and comply with its own local, state, and federal records-retention, open-records, privacy, and public-safety reporting obligations. Export and back up your records on a schedule that fits those obligations. See Section 9.

10-19 Command is not an emergency system. It is administrative and operational software. It is not 911, emergency dispatch, incident command, medical direction, or legal advice. In an emergency, call 911. See the Terms of Service.

The Short Version

This summary is for convenience only. The full policy below controls.

  • Most of the information in 10-19 Command is entered by fire departments and other agencies about their own operations, personnel, equipment, and incidents. We handle that information for the Agency, on the Agency's instructions. The Agency decides what goes in and how long it stays.
  • We also collect a small amount of information for ourselves, such as sign-in security records, support messages, and technical logs.
  • We do not use advertising trackers in 10-19 Command. We count page views with Vercel Web Analytics, which sets no cookies and does not follow you across other websites. We do not sell personal information.
  • The mobile app uses your phone's location only to show your position on the map. Your location stays on your phone and is not sent to us.
  • The Agency's own users can see the Agency's records according to their roles. Hydrant records and pre-incident plans are also visible, read-only, to users of other Agencies on 10-19 Command whose roles include those modules.
  • Our own administrators can access an Agency's Workspace for support and security.
  • Records that contain sensitive personal information may be stored in 10-19 Command if an Agency enters them. Agencies should enter only what they need and are authorized to collect.
  • If you are a member of the public or a member of an Agency and you want to see, correct, or delete information about you, please start with the Agency. See Section 10.

Table of Contents

  1. Scope and Overview
  2. Categories of Information We Collect
  3. Sources of Personal Information
  4. How We Use Information
  5. Our Roles and Legal Bases
  6. How We Share Information
  7. Data Retention and Deletion
  8. Security Practices
  9. Customer and Agency Responsibilities and Public-Records Obligations
  10. Individual Privacy Choices and Rights
  11. Children's Privacy
  12. International Users and Transfers
  13. Third-Party Sites and Services
  14. Policy Updates
  15. Contact Information

1. Scope and Overview

1.1 What this policy covers. This Privacy Policy explains how 10-19 Command LLC ("we," "us," or "our") collects, uses, shares, and protects information in connection with 10-19 Command, including our website at https://1019command.com, the web application, the 10-19 Command mobile app for iPhone and Android, data imports and exports, and our support communications.

1.2 Words we use. Capitalized words such as Customer, Agency, Authorized User, Agency Administrator, Workspace, and Customer Data have the meanings given in our Terms of Service. In short:

  • Customer is the organization that uses 10-19 Command, such as a fire department, fire district, municipality, or county.
  • Agency is the fire department or other public-safety agency whose records are in a Workspace.
  • Authorized User is a person the Agency has allowed to use its Workspace.
  • Customer Data is everything that a Customer, Agency, or Authorized User enters, uploads, imports, or generates in 10-19 Command, including personal information about people in those records.

1.3 Two kinds of information. This policy treats two kinds of information differently:

  • Customer Data. The Agency chooses what to enter and why. We host and process it for the Agency, as its service provider. See Section 5.
  • Our own information. This is information that we collect for our own purposes, such as security records, support messages, and technical logs about how 10-19 Command is used.

1.4 Who this policy is for. It is written for Agency Administrators, Authorized Users, people who contact us, and the people whose information appears in an Agency's records, such as members of the public who are involved in incidents and owners or occupants of properties.

1.5 What it does not cover. This policy does not describe how any Agency uses or discloses its own records. Each Agency has its own policies and legal duties. This policy also does not cover Third-Party Services, which have their own privacy notices. See Section 13.

1.6 What we do not do. Based on our review of the product, 10-19 Command does not:

  • use advertising cookies, cross-site tracking scripts, or session-replay tools (our page-view counter is described in Section 2.5);
  • send Customer Data to artificial-intelligence or machine-learning services; or
  • collect payment card information.

2. Categories of Information We Collect

The information we hold depends on the modules an Agency uses and what its Authorized Users enter. Many fields are optional. Agencies decide which optional fields to use.

2.1 Account and contact information

  • Name, email address, phone number, role, and the department and station that an Authorized User belongs to.
  • A password, which we store only as a one-way cryptographic hash, and sign-in security data, such as failed-attempt counters and lockout times.
  • Password-reset and account-setup tokens, which are stored as hashes and expire after 30 minutes.
  • If we ask you to accept the Terms of Service or this Privacy Policy when you sign in, a record that you accepted a version of it: your account, the document, the version, and the time. The workspace you were signed in to is noted in the audit records, and so is a choice to sign out instead of accepting.
  • For the mobile app: a sign-in refresh token for each phone you sign in on, stored only as a hash, with when it was issued, when it expires, and whether it was revoked.
  • Multi-factor authentication, if you turn it on: your authenticator secret, which is stored encrypted, and ten one-time recovery codes, which are stored only as hashes, with the time of enrollment and of any use or disabling.
  • Dispatch alert settings and devices, if alerts are switched on: see Section 2.9.
  • Messages that you send us, such as support requests, and the contact details in them. Support requests come by email to support@1019command.com and are handled in Google Workspace.

2.2 Agency and user profile information

  • Agency details: name, code, address, telephone, email and website, fire-department and NERIS identifiers, logo, stations, organizational units, fire zones, and neighboring or aid agencies.
  • Member roster details: rank or title, badge number, hire date, certification level, shift, station assignment, and access role. Members can also be added to the roster without an Account.
  • Member profile details, if the Agency enters them: legal name, home address, telephone numbers, date of birth, gender, race, ethnicity, marital status, citizenship, driver's license number, state, class and expiration, Social Security number, training and certification identifiers, and emergency-contact names, relationships, telephone numbers, and addresses.

The emergency contacts are people who have not used 10-19 Command. The Agency, not the contact, provides their information.

2.3 Operational records and agency-entered content

These categories apply only where the related module is in use.

  • Incident reports. Dates and times, incident addresses and coordinates, incident types, narratives, actions taken, command and review notes, units and personnel who responded, names of responding members, injury and fatality counts, property loss, hazardous-materials details, signatures (name and rank), and attachments.
  • People involved in incidents. Where an Agency records them: names, date of birth or age, sex, race, ethnicity, symptoms and injury details, and where a person was taken. A person's record can also note that the person is an injured firefighter or the property owner, and can carry a free-text note. Incident reports also have emergency-medical-services (EMS) fields, such as level of service, patient count, patient status and disposition, patient-care evaluation, and provider impression. These are health-related details about members of the public.
  • Training and certifications. Training events, instructors and locations, attendance and hours, and certifications with their expiration dates.
  • Apparatus, assets, equipment, and inventory. Apparatus records, which may include vehicle identification and license-plate numbers, assigned crew, and notes; equipment and inventory records; and equipment test records, including respirator fit tests for individual members (such as facepiece make, model and size, test method, and fit factor).
  • Operations checks. Truck-check and medication-check reports, including unit, date, shift, the name of the person who did the check, crew names, item results, and free-text notes, and stored PDF copies of those reports.
  • Scheduling. Availability, shift assignments, special events, and time-off requests, including free-text reasons and any attached documents. These reasons and documents may include personal or medical details that a person chooses to provide.
  • Pre-incident plans. Site and occupancy names, addresses, hazard summaries and tactical notes, access details such as gate codes and key-box information, map annotations, revision history, and the name of the user who submitted the plan. A plan can list contacts for the property, such as owners, managers, and key holders, with their names, titles, companies, telephone numbers, email addresses, and notes. The property look-up can return owner names from county parcel data, which a user can add to the plan. Pre-incident plans are shared with other Agencies as described in Section 6.2.
  • Hydrants and GIS data. Hydrant records, including owner names, address points, road centerlines, and boundary data, including data that an Agency imports from shapefiles.
  • Reports and analytics. Reports built from the records above, such as response-time and incident-trend analyses.
  • Legacy NFIRS imports. Historical incident files that an Agency imports. These can include persons involved, property-owner names and addresses, casualties, personnel names, and EMS details, and they are visible to users who have incident access across the Agency's Workspace.
  • Dispatch records. Calls received from a county 911 center's dispatch system, as described in Section 2.9.
  • Export records. Records of incident files prepared for export or sent to an outside reporting system, including the content that was sent and the response or error that came back.

2.3.1 Sensitive information. Agency-entered records may include sensitive categories of information, such as government identification numbers, dates of birth, race and ethnicity, health-related details, and the addresses of incidents and properties. We do not ask for this information ourselves. We store it because an Agency chooses to enter it. We do not use it to infer other facts about people.

2.3.2 Storage of sensitive fields. Member profile details, including Social Security numbers, are stored in our database with the rest of the Customer Data and are protected by the measures in Section 8. They are not separately encrypted field by field. Agencies should enter a Social Security number only if they need it.

2.4 Uploaded files, images, attachments, and documents

Authorized Users with the right permissions can upload files, including:

  • incident attachments (images, PDF, text, and Word documents);
  • member documents and time-off attachments (PDF and images);
  • equipment-test certificates (PDF and images); and
  • the Agency's logo (which may be an image or SVG file).

Files are stored in our database, together with other Customer Data. Files may contain embedded information, such as the location or device used to take a photo, and we do not remove it. We check the type of each file when it is uploaded, but we do not scan files for malware. Some import files, such as CSV files, shapefiles, and legacy NFIRS files, are read and converted into records, and the file itself is not kept.

An Agency's logo is served at an address that does not require a sign-in, so anyone who has the address can retrieve it. Treat a logo as public.

2.5 Device, browser, log, diagnostic, and usage information

  • Network, device, and page-view information. When you use 10-19 Command, your IP address, browser type, and request details are processed by our hosting and network providers. On our Vercel deployments, Vercel Web Analytics also counts page views. For each one, Vercel records the page path, the referring site, an approximate location (country, region, and city), and the browser, operating system, and device type. It sets no cookies and, according to Vercel, tells visitors apart with a hash of the request that it discards after 24 hours. Our code removes query strings and fragments, such as password-reset tokens, from the addresses it sends. The mobile app does not include analytics or crash-reporting tools.
  • Sign-in throttling. To slow down password guessing, we store a one-way hash of the email address and IP address used in a sign-in attempt. We do not store the raw IP address for this purpose.
  • Audit records. 10-19 Command records many actions, such as signing in and out, switching workspaces, creating, changing, approving, or exporting records, and changing roles. Each entry shows who did what, when, and a short summary, and summaries can include names, file names, and review comments. An Agency Administrator can view these entries for the Agency's Workspace. Reading records and downloading files are generally not recorded. The IP address is stored only for password-reset requests.
  • Error and diagnostic logs. When something fails, the system may write an error message to its server logs. A failed email delivery may log the recipient's email address, and database error messages can include details of the failed request. Our hosting provider keeps these logs for a limited time under its standard settings.
  • Email. Our emails include an image hosted on our own domain, so our hosting provider may log when an email is opened. We do not use our email provider's open or click tracking.
  • Data-exchange messages. If an outside system, such as ImageTrend Elite, is set up to send data to us, we store what we receive, including the sender's IP address and all request headers except Authorization, Cookie, and X-API-Key, so that an administrator can review it.

2.6 Location and mapping information

  • Your device's location. The website does not read your device's location or ask your browser for location permission. The mobile app asks for permission to use your location while the app is open, and only if you choose to show your position on the Dispatch map. It uses your location on the phone to draw your position and the distance to a call. The app does not send your location to us, and we do not store it. You can turn the permission off at any time in your phone's settings.
  • Agencies enter or import addresses and coordinates for incidents, stations, hydrants, pre-incident plans, address points, and boundaries. These are Customer Data.
  • To look up addresses and show maps, we and your browser send addresses, coordinates, and map requests to mapping and address providers, listed in Section 6.3. When your browser loads map tiles directly from a provider, the provider receives your IP address, the map area you are viewing, and the address of our site. The mobile app draws its maps with Apple Maps on iPhone and Google Maps on Android. Apple or Google receives your phone's IP address and the map area you are viewing, and, if you show your position, the map service on your phone handles your location under Apple's or Google's own terms.

2.7 Cookies, local storage, and session data

We use only the cookies and browser storage that 10-19 Command needs in order to work. We do not use cookies for advertising or tracking.

Name What it does How long it lasts
command_session Keeps you signed in. It is an HttpOnly cookie, and it is sent only over secure connections in production. Up to 30 days
command_preferred_membership Remembers which Workspace to open when you sign in next. 90 days
command_sign_in_email Holds the email address you typed on the sign-in page while you complete sign-in. 5 minutes
command_mfa_challenge Holds your place between entering your password and entering your multi-factor code. 5 minutes
command_mfa_recovery_reveal Shows your new multi-factor recovery codes once, right after you create them. 2 minutes
cad_feed_secret, display_link Show an administrator a newly created dispatch-feed key or station-screen link once, without putting it in the page address. 5 minutes and 2 minutes
app-shell.sidebar-collapsed (local storage) Remembers whether you collapsed the navigation menu. Until you clear browser data
responder-basemap, responder-hydrants, responder-preplans (local storage) Remember which map style and layers you chose on the Dispatch map. Until you clear browser data
incident-draft:... (local storage) Auto-saves an incident report that you are drafting, so that you do not lose work. It may include people involved and EMS details. It is stored only on your device, for your account. Removed when you use the Sign out button or submit the report, and removed when a draft older than 7 days is next loaded. Otherwise it stays until you clear your browser data

Because incident drafts can hold sensitive information, use a device and browser profile that only you control, and always use Sign out on shared computers.

The mobile app keeps your sign-in tokens and your Dispatch map choices in your phone's secure storage (the iOS Keychain or the Android Keystore). Signing out of the app removes the tokens.

10-19 Command does not currently show a cookie-consent banner because it does not use non-essential cookies.

2.8 Payment information

10-19 Command does not currently process payments or store payment card or bank account information. If we add billing, we will update this section before it starts.

2.9 Dispatch and alert information

These categories apply only to Agencies that use the Dispatch module, and the alert categories only to Agencies and people who use dispatch alerts.

  • Calls from the 911 center. A county 911 center's computer-aided dispatch (CAD) system sends us call records, by email report or by a data feed, for the Agencies that the center has set up. We read only an allowed list of fields: the call number, the center's call type and code, priority, the address, coordinates and cross streets of the call, fire and EMS district, the times the call was received, dispatched and closed, the units dispatched with their times, determinant codes where sent, and dispatcher notes. We ignore caller identity and law-enforcement fields even if the center sends them, and 10-19 Command has no field to store them. The location and call type can still be personal information about the people at a scene, and dispatcher notes can hold free text that a dispatcher typed.
  • Raw messages. The original message and any attached report are stored as received, so until they are removed (see Section 7.3) they can contain fields that we do not read, including any that the center sends beyond the allowed list. We also keep the sender, the subject, and the request headers, except that the Authorization, Cookie, X-API-Key and API-key headers and the feed's own key header are replaced with "[redacted]".
  • Calls for Agencies that are not on 10-19 Command. For a call that no Agency on 10-19 Command is dispatched to, we keep only the call number, department codes and call type, for a short time.
  • Alert devices and browsers. For each phone, the push token, the platform, the phone's name as a label (for example, "Pat's iPhone"), the app version, whether notification permission was granted, and when it was last seen. For each browser that you allow notifications in, the push service's address for that browser, its encryption keys, an optional label, and the browser's user-agent string.
  • Alert settings. Your alert on/off switch, quiet hours, whether the lock screen shows the call's address and nature, and, for each Agency, whether you are subscribed and which categories you have muted.
  • Alert delivery records. For each call and person, whether an alert was sent or why not (for example muted, quiet hours or no device), and for each push attempt, when it was queued, accepted, received and opened, and any error. A push can show the call's type, address and cross streets on the lock screen unless you turn lock-screen detail off, and it shows the newest dispatcher note (shortened) only if your Agency has turned that on.
  • Shared station screens. A station screen signs in with a link that acts like a password. We store only a hash of it, with the screen's name, volume and tones, and when it was last seen.
  • Text messages. 10-19 Command does not send text messages today. We will update this section before it does.

3. Sources of Personal Information

  • From you. When you sign in, use 10-19 Command, or contact us.
  • From Agencies and their Authorized Users. Most personal information in 10-19 Command is entered by an Agency Administrator or another Authorized User, including information about other people, such as members, emergency contacts, patients, and property owners or occupants.
  • From files and imports. From CSV, shapefile, and legacy NFIRS files that an Agency uploads.
  • From your browser or device. Automatically, such as cookies, log data, and your IP address.
  • From Third-Party Services. Address-lookup and mapping results, weather data, and public property and parcel records, as described in Section 6.3.
  • From an Agency's outside systems. From ImageTrend Elite, if the Agency configures it to send data to us.
  • From a 911 center. Call records from a county 911 center's dispatch system, for the Agencies it routes to us.

4. How We Use Information

We use information to:

  • Provide 10-19 Command. Host and process Customer Data, apply each user's role and Workspace permissions, and produce the forms, reports, exports, and analytics that Agencies ask for.
  • Authenticate and secure it. Sign you in, limit repeated failed attempts, end sessions, keep the audit records described above, investigate abuse, and protect the system and its users.
  • Communicate with you. Send system messages, such as password-reset and account-setup emails, and notices about completed truck checks and medication checks, which go to recipients that the product selects from the Agency's roster, such as administrators, station command, and members with certain rank titles. We also send a daily reminder digest about items that are due, overdue, or waiting on you, such as an expiring certification, an overdue equipment test, or an unfinished incident report; officers receive a summary for the areas they oversee, which can name members and the items concerned. Each user can turn reminder emails off, by category, under Notifications, Preferences. We answer support requests. We send only service messages, not marketing emails.
  • Provide dispatch notifications. Match a call to the Agencies and units dispatched, show it on the Dispatch screens and map, send alerts to the members who are subscribed, and pre-fill a draft incident report from the call, with the source of each pre-filled value shown.
  • Send data where the Agency directs. For example, prepare a NERIS incident file and, where an Agency's export profile targets ImageTrend Elite and delivery is enabled, send it to the ImageTrend endpoint that we have configured.
  • Maintain and improve 10-19 Command. Fix problems, keep backups, test changes, and plan capacity and features. Our development database and the test builds we make before releasing a change use copies of the production database. These copies stay with the same database provider, under the same access controls, and only our own personnel use them.
  • Meet legal duties and protect rights. Comply with law and valid legal process, and enforce our terms.

We do not use Customer Data for advertising, and we do not make automated decisions about individuals that have legal or similarly significant effects. Indicators that the product calculates, such as pre-plan risk scores and response-time compliance, describe buildings and Agency operations, and Agencies decide how to use them.

5. Our Roles and Legal Bases

5.1 Service provider (processor) for Customer Data. For Customer Data, we act as a service provider or processor for the Customer. The Customer decides what information to collect, why, and how long to keep it. We process Customer Data on the Customer's instructions and for the purposes in our Terms of Service. This includes the account information that an Agency Administrator enters for its Authorized Users. The Agency is responsible for giving any notices and getting any consents that the law requires for its records.

5.2 Business (controller) for our own information. We act on our own behalf for information that we collect for our own purposes. This includes:

  • sign-in security and abuse-prevention records;
  • messages and requests that people send to us;
  • technical, diagnostic, and security logs that we use to run and protect 10-19 Command; and
  • account-administration records, and billing records if we charge fees.

5.3 Legal bases. Where a law requires us to identify a legal basis, we rely on the following, as appropriate:

  • carrying out our contract with the Customer, and the Customer's instructions;
  • our legitimate interests in securing, operating, supporting, and improving 10-19 Command, balanced against your rights;
  • compliance with legal obligations; and
  • your consent, where the law requires it.

The Agency decides on the legal basis for collecting the personal information in its own records, which is often a legal or official duty.

6. How We Share Information

6.1 With Authorized Users of the Agency and with our own administrators. Information in a Workspace is visible to the Agency's Authorized Users, according to their roles. Some roles are also limited to a station. Agency Administrators can see and manage accounts, roles, and audit history for the Workspace. Our own platform administrators also hold access to each Workspace, and an administrator's membership is created automatically when a Workspace is set up. They may switch between Workspaces, for example to onboard an Agency, provide support, investigate a problem, or keep 10-19 Command secure. A platform administrator's switch into a Workspace is recorded in that Workspace's audit history. The automatic creation of the membership and the reading of records are not separately recorded. Personnel with access to our hosting, database, and source-code systems can also reach Customer Data through those systems, and the application's audit history does not record that access. Today, platform-administrator and system access is held only by the company's founder. We grant it to anyone else only when their work requires it, and we remove it when they no longer need it.

6.2 With other Agencies (shared modules). Hydrant records and pre-incident plans are shared modules. Authorized Users of any active Agency whose role includes the Hydrants or Pre-Plans permission, and whose own Agency has that module turned on, can view every active Agency's hydrants and pre-incident plans, read-only. This includes plans that are still drafts or have been archived, and details such as hazards, tactical notes, and access details such as gate codes and key-box information. Printed plans show the name of the user who submitted the plan. The Hydrants page also shows other Agencies' names, codes, cities, and fire-protection boundaries, and their station names, codes, and coordinates. Only the Agency that owns a record can change it. Other Customer Data is limited to the Agency's own Workspace. An Agency cannot currently opt out of this sharing. Mutual aid depends on it: a crew responding into a neighboring district can see that district's hydrants and plans.

6.3 With service providers and subprocessors. We use the providers below to run 10-19 Command. Some of them, such as the hosting, database, and email providers, process information on our behalf. Others, such as public map and lookup services, receive only the requests described in the table and operate under their own terms.

Provider What it does for us Information involved
Vercel Hosts and serves the web application, and counts page views with Web Analytics All traffic to and from 10-19 Command, including Customer Data in transit, standard request logs, and page-view statistics
Neon Provides the managed PostgreSQL database that stores Customer Data, including uploaded files All Customer Data and account data
Resend Delivers system emails Recipient name and email address, and message content, which may include password-reset and setup links and, for check-completion notices, crew names, notes, and PDF reports; for reminder digests, the names of members, certifications, equipment, apparatus, pre-plan sites, and incident numbers that the reminder is about
GitHub Hosts our source code, runs scheduled jobs that trigger export processing, and stores encrypted nightly database backups for a limited time Encrypted backup files, which contain all Customer Data, and service credentials. During each nightly backup, a temporary GitHub-hosted runner briefly holds an unencrypted copy before it is encrypted and deleted
Expo (push notification service) Delivers push alerts to phones and reports whether they were delivered The push token and the alert text, which can include the call's address and nature unless you turn lock-screen detail off
Apple Push Notification service and Google Firebase Cloud Messaging Carry push alerts from Expo to iPhones and Android phones The push token and the alert text
Apple Maps (iPhone) and Google Maps (Android) Draw the maps in the mobile app Your phone's IP address and the map area you are viewing, and your location if you choose to show your position, handled on your phone by Apple's or Google's map service under their own terms
Google Maps Platform (Map Tiles) Road and aerial map tiles on the Dispatch map, fetched by our servers The map area being viewed, sent from our servers. Your IP address is not sent to Google for these tiles
Browser push services (run by your browser's maker) Carry push alerts to a browser that you allowed notifications in The browser's push address, its keys, and the encrypted alert
911 center and its CAD vendor Send us call records for Agencies the center has set up. They are a source of data, not a service we use See Section 2.9
Esri (ArcGIS) Address search and geocoding, map overlays, and printed map images Addresses (typed or already stored) and hydrant coordinates, sent from our servers. Your IP address and the map area are sent when your browser loads overlays or a printed map
OpenStreetMap Foundation and OpenStreetMap France Map tiles and address and place lookups (Nominatim) Addresses or coordinates for lookups, sent from our servers or from your browser, including lookups of hydrant coordinates. Your IP address and the map area for tiles
U.S. Geological Survey (National Map) Topographic and imagery map tiles Your IP address and the map area
Mapbox Satellite map tiles and static map images Your IP address, the map area, and an access token
Open-Meteo Weather data shown on incident reports Incident coordinates and date, and your IP address, sent from your browser
County property and parcel records Public parcel data used to pre-fill property details, from a county parcel data file where we have one and from the county's public assessor website (qPublic, run by Schneider Geospatial) Parcel identifiers and public parcel page addresses are used to look up records. The county file can include owner names, which we receive. We do not send personal information about people to these sources
Google Workspace Handles our own business email, including support requests Messages that you send us

6.4 With integrations that a Customer chooses. An Agency decides whether to send data to an outside system. When an Agency approves an incident report, 10-19 Command prepares an incident file in the NERIS format. The file includes, for example, the department's NERIS identifier, incident number, address and coordinates, incident types, dispatch and unit times, a narrative of the outcome, casualty counts, and summary patient-care information. It does not include structured fields for the names or dates of birth of people involved, but the narrative is free text and may contain whatever its author typed. The Agency can download the file and import it into its reporting system. Where an Agency's export profile sends reports to ImageTrend Elite and delivery is enabled, approving the report queues it for delivery to the ImageTrend endpoint that we have configured, using credentials that we hold. We keep a record of each attempt, including the content sent and the response or error. After data reaches an outside system, that system's own privacy practices apply.

6.5 For legal compliance, safety, and fraud prevention. We may disclose information when we believe it is necessary to comply with law, regulation, or valid legal process, to protect the rights, property, or safety of people or of 10-19 Command, or to detect, prevent, or address fraud, abuse, and security problems. If we receive a demand for Customer Data, we will direct the requester to the Customer where the law allows, and will tell the Customer unless we are legally barred from doing so.

6.6 Business transfers. If we are involved in a merger, acquisition, financing, reorganization, or sale of assets, information may be transferred as part of that deal. We will require the recipient to honor this policy for existing Customer Data, and we will tell affected Customers first where possible.

6.7 De-identified or aggregated information. We may create statistics about how 10-19 Command is used that do not identify any person or Agency, and use them to run and improve the service. We will not try to re-identify anyone from them.

6.8 We do not sell personal information. We do not sell personal information, and we do not share it with third parties for cross-context behavioral advertising.

6.9 With your consent or at your direction. We may share information with your permission or at your direction.

7. Data Retention and Deletion

7.1 Agencies decide retention of their records. While a Workspace is active, the Agency decides how long its records are kept. We do not delete Customer Data on a schedule unless the Customer asks us to. Many records are deactivated, voided, or archived rather than erased. For example, members and departments are made inactive, incidents move to an archived status, and equipment tests are voided with a reason.

7.2 Deleting your account or your data

10-19 Command does not currently offer self-service deletion of an account or of all of an Agency's data, in the website or in the mobile app. To delete your account:

  1. Ask your Agency Administrator to deactivate your membership. You lose access right away.
  2. Then email privacy@1019command.com from the address on your account, with the subject "Delete my account", and name your Agency. We may confirm the request with you and with your Agency before we act on it.
  3. Within 30 days, we delete your sign-in details (password, multi-factor secrets and recovery codes, sign-in tokens), your registered phones and browsers, and your alert settings, and we remove your name, email address, and phone number from your account. We tell you when it is done.

Some information stays with your Agency because the Agency must keep it: for example, incident reports that name you as a responder, training and certification records, and audit records. Ask your Agency if you want those changed. Deleted information leaves our backups within 30 days (see Section 7.4).

Authorized Users can permanently remove a few kinds of items themselves, such as member documents, certifications, draft check reports, and imported legacy batches, and editing an incident report replaces the people, units, and vehicles listed in it. A safeguard in the application blocks other permanent deletions. To delete all of an Agency's data, an Agency Administrator should contact us at support@1019command.com.

7.3 Retention of specific items.

Item How long we keep it
Password-reset and account-setup tokens Valid for 30 minutes and cleared when used. The hash of an unused, expired token stays until it is replaced
Web sign-in session Up to 30 days, or until you sign out or an administrator ends your sessions
Mobile access and refresh tokens The access token lasts 15 minutes. Each refresh issues a new 30-day token, so a mobile sign-in that is used regularly stays active until you sign out or it is revoked. Expired and revoked token records (hashes only) are not yet deleted automatically
Sign-in throttling records (hashes) Used for 10- and 15-minute windows and cleared after a successful sign-in. Other records are not yet deleted automatically
Browser incident drafts Until you use Sign out, submit the report, or reopen the form after 7 days. An unopened draft stays until you clear your browser data
Records of accepting the Terms or Privacy Policy Kept as evidence of acceptance while the Workspace is active, then deleted or de-identified within 90 days after the relationship ends, except what we must keep for law or a dispute. No automatic deletion exists today.
Raw CAD messages and attachments A message that parsed correctly is blanked 7 days after parsing, and one that did not parse after 30 days, by a job that runs daily
CAD dispatcher notes Blanked 30 days after the call closes (a per-center setting)
Calls for Agencies not on 10-19 Command 24 hours (a per-center setting)
CAD call records for Agencies on 10-19 Command Kept while the Workspace is active, then deleted or de-identified within 90 days after the relationship ends, except what we must keep for law, a dispute or security. No automatic deletion exists today
Alert devices, browsers and delivery records Kept while the Workspace is active, then deleted or de-identified within 90 days after the relationship ends, except what we must keep for law, a dispute or security. Devices and browsers are marked revoked, not deleted, and no automatic deletion exists today
Audit records Kept while the Workspace is active, then deleted or de-identified within 90 days after the relationship ends, except what we must keep for law, a dispute or security. No automatic deletion exists today
Export delivery records and messages received from outside systems Kept while the Workspace is active, then deleted or de-identified within 90 days after the relationship ends, except what we must keep for law, a dispute or security. No automatic deletion exists today
Support messages Two years
Server, hosting, and diagnostic logs A limited time set by our hosting provider's standard log retention

7.4 Backups. We keep backups to recover from errors and outages. Nightly encrypted backups of the production database are kept for 30 days. The database provider also keeps a short point-in-time recovery history, shorter than 30 days. Deleted information can remain in backups until they expire, so it leaves all backups within 30 days.

7.5 What we may keep. We may keep information that we are required by law to keep, that is subject to a legal hold, or that we need to resolve a dispute, enforce our agreements, or maintain security. We keep business records, such as contracts and correspondence about them, for as long as needed for the purposes in this policy, and delete or de-identify them within 90 days after the relationship ends unless we must keep them.

7.6 After the relationship ends. For 30 days after a Customer's access ends, the Customer may ask us for a copy of its Customer Data. After that, we delete or de-identify Customer Data from our active systems within 60 days, and copies leave our backups as they expire, as described in Section 7.4. Our Terms of Service set out the details.

8. Security Practices

We use reasonable administrative, technical, and organizational measures that are designed to protect information. The measures in place include:

  • Passwords. Passwords are stored as bcrypt hashes. New passwords set through the reset flow and the member form must be at least 12 characters long and include upper- and lower-case letters, a number, and a symbol. An Agency Administrator can also set a member's initial password. A password that our own platform administrators set on the user-administration screen must be at least 8 characters long.
  • Sign-in protection. Repeated failed sign-in attempts from the same email address and network address are throttled, and an Account is locked for 15 minutes after five failed attempts.
  • Multi-factor authentication. Authorized Users may turn on optional multi-factor authentication with an authenticator app. When it is on, the authenticator secret is stored encrypted and the one-time recovery codes are stored only as hashes. It is not required.
  • Reset and setup tokens. They are random, stored only as hashes, expire after 30 minutes, and can be used once. A password reset ends the user's existing sessions.
  • Sessions. The web session is a signed cookie that is marked HttpOnly and, in production, secure. Each request is checked against the current state of the user, the Workspace, and the user's membership, so that deactivating a member takes effect on the next request. A user can also sign out of all devices.
  • Access control. Access is based on roles and on the Workspace and station that a user belongs to. Our own administrators use the same Workspace-based access.
  • Audit records. Many actions are logged, as described in Section 2.5.
  • Uploaded files. The type of each file is checked from its contents, and files other than PDFs are served with a browser sandbox policy.
  • Machine-to-machine access. Credentials for scheduled jobs and for outside systems are compared using constant-time checks, and the Authorization, Cookie, and X-API-Key headers of received messages are not stored.
  • Backups. Nightly database backups are encrypted before they are stored.
  • Dispatch feeds. A feed's shared secret is stored only as a hash and is shown once. A feed can be limited to allowed senders or network ranges, and a feed that goes quiet triggers an alert to our operators. Station-screen links are stored only as hashes.
  • Mobile sign-in tokens. Refresh tokens are stored only as hashes and replaced on each use, and reusing an old token revokes all of them.
  • Encryption in transit. The website, the mobile app, and our connections to the database and our providers use encrypted connections (HTTPS or TLS).

What we do not claim. We do not claim that 10-19 Command holds SOC 2, ISO 27001, HIPAA, CJIS, PCI, or any similar certification or attestation, or that it complies with those standards. It has not had an independent security audit or penetration test. Multi-factor authentication is optional, sessions do not time out when idle, and apart from the multi-factor secrets, we do not encrypt individual fields in the database.

No method of storing or transmitting information is perfectly secure. You also play a part: keep your Credentials confidential, use a strong password, sign out on shared devices, and tell your Agency Administrator and us at security@1019command.com if you suspect misuse. If we learn of unauthorized access to Customer Data, we will notify the affected Customer without unreasonable delay, and no later than 72 hours after we confirm it.

9. Customer and Agency Responsibilities and Public-Records Obligations

9.1 Agencies must keep their own official records. Each Agency is responsible for maintaining the operational records that it is required to keep, in the systems and forms that its local, state, and federal laws, records-retention schedules, and public-safety reporting programs require. 10-19 Command is an aid to those duties and is not a substitute for them. Do not treat it as your only copy of a record.

9.2 Authority and notices. Each Customer is responsible for making sure that:

  • it and its Authorized Users have authority to enter, access, and manage the information in its Workspace;
  • it has given any notices to its personnel and to members of the public, and obtained any consents or authorizations, that Applicable Law requires; and
  • it collects only the personal information that it needs and is authorized to collect, especially sensitive information such as government identification numbers, health-related details, and information about minors.

9.3 Public-records and open-records laws. Records that a Government Customer keeps in 10-19 Command may be public records or may be exempt from disclosure. The Customer, not we, decides what to release or withhold, and responds to requests. If we receive a request for Customer Data, we will direct the requester to the Customer where the law allows, and will help the Customer as described in the Terms of Service.

9.4 Preservation and legal holds. The Customer is responsible for preserving records that it must keep for litigation, audits, or investigations. We are not the Customer's records custodian.

9.5 Shared records. Before adding hydrant records or pre-incident plans, each Agency should consider that users of other Agencies can view them. See Section 6.2.

10. Individual Privacy Choices and Rights

10.1 Start with the Agency. If your information is in an Agency's records, for example as a member, a patient, a property owner, or an emergency contact, the Agency controls that information, and it is the best place to ask to see, correct, or delete it. We will help the Agency respond. If you contact us about Customer Data, we will direct you to the Agency where the law allows.

10.2 Requests about our own information. For information that we hold for our own purposes, such as support messages, you may ask us to:

  • tell you what we hold about you and give you a copy;
  • correct information that is wrong;
  • delete information, subject to the exceptions in Section 7.5; or
  • limit or stop a particular use of it.

How to make a request. Email privacy@1019command.com or write to 10-19 Command LLC, 240 History Trl, Winterville, GA 30683. Tell us what you would like and how we can reach you. We may ask for information to confirm who you are, and we may need to confirm with the Agency before acting on Customer Data.

Our response. We will respond within 45 days, or tell you why we need more time. We may decline a request that we are legally required or permitted to decline, and we will explain why. If you disagree with our decision, reply to privacy@1019command.com and we will review it again. We will not treat you unfairly for making a request.

10.3 Communications choices. We send service messages that are needed to operate your account, such as password-reset emails, and we cannot turn them off while your Account is active. Notices of completed truck checks and medication checks go to recipients that the product selects from the Agency's roster, and individuals cannot opt out of them. Reminder emails can be turned off by category, as described in Section 4.

10.4 Cookies and tracking signals. Because 10-19 Command does not use advertising cookies or track you across other websites, it does not change its behavior for "Do Not Track" or similar browser signals. You can clear cookies and local storage in your browser settings, but you may need to sign in again, and unsaved drafts stored in your browser may be lost.

10.5 State-specific privacy rights. Some states give residents rights over their personal information, and they may also require additional disclosures, such as the categories of information collected in the last twelve months and a description of any sale or sharing. Many of these laws have exemptions, for example for government entities, for information that a service provider handles on a government entity's behalf, or for businesses below certain size or data-volume thresholds. If a law gives you rights over your personal information, you can use the request process in Section 10.2, and we will honor the rights that apply.

11. Children's Privacy

10-19 Command is for organizational use by adults. It is not directed to children under 13, and Authorized Users must be at least 18 years old unless an Agency has lawfully authorized a younger person, such as a junior or cadet member, to have access.

Agencies may record information about minors in their records, for example about junior members or about young people involved in incidents. The Agency is responsible for having the authority to do so. We do not knowingly collect personal information directly from children under 13 for our own purposes. If you believe that a child has given us personal information, contact us at privacy@1019command.com, and we will take steps to delete it.

12. International Users and Transfers

10-19 Command is designed for public-safety agencies in the United States, and our database is stored in the United States (Amazon Web Services, US East), with our hosting provider serving the application through its network. If you access 10-19 Command from outside the United States, you understand that your information will be transferred to and processed in the United States, where privacy laws may differ from those in your country.

13. Third-Party Sites and Services

10-19 Command uses and links to Third-Party Services, including the mapping and address providers in Section 6.3. They have their own terms and privacy notices, and we do not control them. When your browser loads map imagery directly from a provider, that provider sees your IP address. If an Agency sends data to an outside system, such as ImageTrend Elite, that system's privacy practices apply to the data it receives. We are not responsible for the practices of Third-Party Services.

14. Policy Updates

We may update this Privacy Policy from time to time, for example when we add features, change providers, or respond to legal requirements. The "Last Updated" date at the top shows the latest version. For material changes, we will give the Customer's Agency Administrators at least 30 days' notice by email, by a notice in 10-19 Command, or both. We do not need to give that notice for bug fixes, security fixes, corrections of typographical errors, clarifications that do not reduce your privacy protections, or changes needed sooner to comply with law or to address a security risk. Earlier versions are available on request at privacy@1019command.com.

15. Contact Information

Questions about this Privacy Policy, and requests described in Section 10, may be sent to:

  • Legal entity: 10-19 Command LLC
  • Privacy contact: privacy@1019command.com
  • Mailing address: 10-19 Command LLC, 240 History Trl, Winterville, GA 30683
  • Support email: support@1019command.com
  • Security contact: security@1019command.com
  • Website: https://1019command.com

Automated messages, such as password-reset messages, are sent from a no-reply address that is not monitored. Please do not send privacy requests to that address.

Privacy Policy