Summary: Routine To Response uses account, department, and training information to provide secure fire-service readiness tools. We do not sell personal information, use it for targeted advertising, or include third-party advertising trackers.
1. Who we are and what this policy covers
Routine To Response ("R2R," "we," "us," or "our") is operated by Ryan Thomann in North Carolina, United States. This policy explains how the Windows application, centralized application programming interface, support services, and related web pages collect, use, disclose, retain, and protect personal information.
Participating fire departments and other organizations decide which personnel and training records they place in R2R and who may access those records. For organization-managed information, the organization is responsible for its own notices, lawful authority, record-retention requirements, and user administration. Questions about the accuracy or authorized use of a department record should normally be directed to that department first.
This policy does not govern Microsoft Store, Microsoft Windows, Render, Supabase, or a participating organization's separate systems and privacy practices.
2. Information we process
| Category | Examples |
|---|---|
| Account and personnel information | Name, email address, optional phone number, department, Access Profile, rank, role, shift, station, certifications and credential history, credential evidence deliberately uploaded by a user, verification and expiration status, apparatus eligibility, account status, and internal user identifiers. |
| Authentication and security information | Password hashes and salts, password-change status, unsuccessful sign-in and lockout information, signed-session identifiers, access permissions, and audit events. R2R does not store account passwords in readable form on the central service. |
| Training and exercise information | Tabletops, Training tests, instructor statements, assignments, due dates, responses, scores, reviewer selections, comments, highlights, completion history, training dates, credit hours, instructors, locations, training types, attendance, approval status, rejection explanations, generated training-form PDFs, and limited focus-change/time-away records recorded while completing an assignment. |
| Department and administrative information | Department name and code, ranks, stations, roles, apparatus, category definitions, service status, administrator actions, and platform-owner audit records. |
| Content and files | Images, documents, videos, filenames, and other media deliberately uploaded or attached by an authorized user; Community Library submissions, descriptions, classifications, contributor department, moderation decisions, and reports about shared content. Uploaded content may contain personal information chosen by the user or organization. |
| Operational, scheduling, and notification information | Deployment identities, availability responses, equipment readiness and deficiencies, work rotations, roster assignments, open-shift bids and awards, time-off and trade requests and decisions, leave banks and ledger transactions, schedule publications and acknowledgements, Daily Board schedule items, station notes, staffing assignments, department-entered weather ZIP codes or addresses and resolved coordinates, operational tasks, operational periods, activity logs, ICS forms and messages, timestamps, authorship and edit history, in-app notification history, recipient matching, and delivery preferences. |
| Technical and support information | Internet Protocol address and request metadata available to hosting systems, application version, request/error identifiers, diagnostic records, and information included in a support request. |
| Website inquiries | Name, department, email address, roster-size range, requested workflows, submission reference and date, follow-up status, internal notes, and email delivery status. Inquiries are saved in the central platform-management queue and emailed to our sales inbox through the configured email provider. |
| Pilot distribution statistics | Anonymous installer-link clicks, completed pilot-package responses, application version, event timestamp, and a randomly generated installation identifier reported once after the pilot application first launches. R2R does not associate this identifier with an account, department, IP address, or advertising profile. |
R2R does not request precise location, contacts, financial account information, or health information as part of its normal operation. Users and organizations should not upload unnecessary sensitive information.
3. Information stored on a user's Windows device
The application stores limited preferences, such as the most recently used department code, on the user's device. If a user selects Remember me, the saved sign-in credential is protected through Windows Credential Manager for that Windows account. It is not placed in department data or stored as readable text by R2R. Users can clear remembered credentials by turning off Remember me or through Windows credential settings.
A portable/offline edition may store a department data file and backups in the folder selected for that edition. The person or organization controlling that device and folder is responsible for physical access, backups, and appropriate deletion.
4. How we use information
- Authenticate users and enforce department, role, and permission boundaries.
- Provide exercise creation, assignment, completion, scoring, review, history, import, export, and administration features.
- Generate, approve, retain, and—when configured by a department—email completed training forms to the department's designated recipient.
- Provide in-app notifications and, only when a user enables email for their own account, send notification email to the account address. Notification email normally identifies the user, department, and module and asks the user to open R2R without operational or personnel details. If a user separately enables email for the Deployment ICS 213 event, the email includes the complete recorded ICS 213 General Message so the matched R2R recipient can read it without opening the application.
- Review Community Library submissions, share approved content between participating departments, investigate reports, and remove or retire content that violates the Community Content Guidelines.
- Maintain data integrity, synchronize authorized changes, recover from failures, and prevent conflicting saves.
- Detect abuse, investigate errors, secure the service, enforce rate limits, and maintain audit records.
- Provide customer support, communicate about service operation, and improve reliability and usability.
- Respond to website inquiries, arrange demonstrations, and track requested sales follow-up. Inquiry details are accessible to authenticated platform owners and the sales mailbox; sending a request does not subscribe you to marketing email.
- Measure anonymous pilot downloads and first launches so we can evaluate release delivery and support pilot users.
- Comply with applicable law, valid legal process, and enforceable agreements.
Where a legal basis is required, processing is performed as necessary to provide the requested service or fulfill an agreement, to serve legitimate interests in operating and securing the service, to comply with legal obligations, or with consent where consent is required.
5. How information is disclosed
We disclose information only as needed for the purposes described above:
- Within an organization: authorized department administrators, supervisors, instructors, reviewers, learners, or platform operators receive access according to their role and the assignment workflow. Members of a department may view the public facts of other members' credential records; credential numbers and original evidence remain limited to the owner, department administrators, and explicitly assigned credential managers. Department-authorized paired station displays may show a minimized Station Board containing schedule items, station notes, task summaries, weather, time-limited recognition, and configured roster details such as personnel names, work positions, shifts, stations, and explicitly assigned apparatus. Departments control which boards show names and must place displays appropriately. Paired displays do not receive account contact details, credentials, note authors, private task descriptions, permission grants, or display-token hashes.
- Community Library: after contributor confirmation and platform review, approved content and its contributor department name can be viewed and copied by eligible users in other participating departments. Community submissions are not public until approved.
- Service providers: infrastructure providers process data for hosting, database, storage, security, or delivery. Current or planned providers include Render for application/API hosting and database infrastructure, Google/Gmail for configured training-form and user-enabled notification email delivery—including complete ICS 213 text when that recipient enabled the ICS 213 email event—Supabase where private database or media storage is enabled, Microsoft for Windows and Microsoft Store distribution, the National Weather Service for point forecasts and alerts, and OpenStreetMap's Nominatim service for department-requested ZIP code or address lookup. These providers operate under their own terms and privacy notices.
- Legal and safety purposes: information may be disclosed when reasonably necessary to comply with law or valid legal process, protect rights and safety, investigate fraud or security incidents, or defend legal claims.
- Business transfer: information may be transferred as part of a merger, acquisition, financing, reorganization, or sale of the service, subject to appropriate notice and applicable law.
We do not sell personal information. We do not share personal information for cross-context behavioral advertising and do not use third-party advertising SDKs.
6. Retention and deletion
Website inquiries and follow-up notes are retained only as long as reasonably needed to respond, manage the requested business relationship, and resolve related disputes. Contact support@routine2response.com to request correction or deletion. Closing an inquiry marks follow-up complete; it does not delete the record.
Department and training records are retained while needed to provide the service and meet the participating organization's training, accountability, and recordkeeping needs. Credential metadata, evidence, version history, and related audit history have a department-configurable retention period of at least seven years after separation or archival; credential-warning acknowledgements have a minimum three-year retention period. Departments may lengthen, but not shorten, those periods. An attributed legal hold prevents disposition for its subject until an authorized administrator releases it. Automatic credential-record deletion is disabled.
Members can export their own credential records. Assigned credential managers can export only records within their current scope, and department administrators can prepare an audited department export. An export may include original evidence only when the requester is already authorized to access that evidence.
Authorized administrators can correct records and archive personnel. A former member loses account access, but their governed credential record cannot be removed through ordinary personnel deletion while retained credential history remains. Community submissions, moderation decisions, and content reports are retained as needed to operate and protect the shared library. Platform operators can retire shared content and suspend or archive department access.
When an organization validly requests deletion or closes its service, primary data will be deleted or de-identified after any required export and a reasonable operational period, except where retention is required for security, dispute resolution, legal compliance, or enforcement. Residual copies may remain temporarily in encrypted or provider-managed backups until those backups rotate. Security, audit, and support records are retained only as long as reasonably necessary for their purpose.
7. Security
We use safeguards appropriate to the nature of the service, including HTTPS transport, salted password hashing, signed sessions, role-based access controls, department separation, request-size limits, rate limiting, audit logging, managed secret storage, restricted administrative functions, and hashed revocable station-display credentials. R2R support has no standing access to department credential records. Any future support access must be department-authorized, time-limited, reason-bound, audited, and disclosed to the department. Remembered credentials use Windows Credential Manager. No system can guarantee absolute security, and users must protect their devices, credentials, and paired-display links.
If we discover a breach requiring notice, we will investigate and provide notice to affected organizations, individuals, regulators, or others as required by applicable law.
8. Choices and privacy rights
R2R notifications default to in-app delivery. A user may enable or disable email separately for their own notification events in My Notification Settings; selecting email is the user's opt-in, and turning it off stops future notification email for that event. Enabling email for Deployment ICS 213 expressly sends the complete recorded message through the configured email provider to the user's account address. Department administrators may choose which authorized users watch department events, but they cannot enable email delivery for another user.
Depending on location and applicable law, a person may have rights to request access, correction, deletion, restriction, objection, portability, or withdrawal of consent. Users can update certain contact information in Profile. Other personnel and training records are managed by authorized department personnel.
To submit a privacy request, contact the department administrator responsible for the account or email support@routine2response.com. We may need to verify identity and organizational authority before acting. Some information may be retained when permitted or required by law. Users may also complain to an applicable privacy or data-protection authority.
9. Children's privacy
R2R is designed for fire-service and organizational training and is not directed to children under 13. We do not knowingly collect personal information from children under 13. Contact us if you believe a child has provided personal information without appropriate authorization.
10. International processing
The service is operated from the United States, and information may be processed in the United States or another location where a service provider operates. When required, we use appropriate contractual or legal safeguards for cross-border processing.
11. Changes to this policy
We may update this policy when the service, providers, or legal requirements change. The effective date above will be revised. Material changes will be communicated through the service, Store listing, participating organization, or other reasonable means before they take effect when required.
12. Contact
Routine To Response
Operator: Ryan Thomann
North Carolina, United States
Email: support@routine2response.com
Support: https://routine2response.com/support
Community guidelines: https://routine2response.com/community-guidelines