Effective date: September 5, 2026 · Version 1
This Privacy Policy describes how Cloud Bedrock LLC ("Cloud Bedrock", "we", "us") handles personal data in AlertRoster — the hosted service, the mobile and desktop applications, the receiver hardware channel, and this website. It supplements the Terms of Service, the End User License Agreement, and the Disclaimer.
Two kinds of people, and who decides
AlertRoster is sold to an organization — a search and rescue team, a volunteer fire department, a business — which holds the account. The people on its roster are the responders. Almost everything in an account is put there by the organization or by the responders themselves, and the organization decides who is on the roster, what is alerted on, and who is paged.
For that data the organization is the controller and we are the processor: we hold and move it on their instructions. If you are a responder and want to know why you are on a roster, or want to be taken off one, your organization is the right place to ask — though you can also delete your own account from the app, and we describe below what that does.
For the small amount of data that is ours rather than a customer's — what someone types into an access request or a support request, and the operational logs the service keeps — we are the controller.
What we collect
Your identity on the roster
A name and an email address, and a password if you set one — stored only as an Argon2 hash, never as text we could read or return. If you sign in by emailed link, we record that the link was issued and used.
Your devices
For each phone or workstation you register: a device identifier you supply, the platform, an app version, and the push token that lets Apple deliver an alert to it. Push tokens are credentials for reaching a device, not identifiers of a person, and they are deleted when the device is removed or when Apple tells us the token is dead.
A receiver — the on-site hardware that drives a horn or a strobe — is not a phone and holds nothing about a person. Its record is a hardware identifier, a model, a name somebody gave it, its firmware version and capabilities, and the certificate it authenticates with.
The alerting itself
Incidents and their timelines: what raised an alert, its title and content, who was notified and when, who acknowledged it, who it was reassigned to, and when it closed. This is an audit trail, and it is meant to be — a team needs to be able to answer "who was called, and who answered" afterwards. Incident content comes from the customer's own systems and may describe those systems in detail.
Alongside it: schedules and rotations, and shift handoffs — who was asked to cover, who accepted, and who declined. Every page we send over a transport that reports back is recorded on the incident's timeline: who it was aimed at, which channel carried it, when, and whether it was delivered. A page to a desktop client goes over a live connection that reports no such outcome and leaves no per-page record; that one appears in our operational logs only.
Check-ins
If you use check-ins, we hold what you configured — a label, a deadline or a daily time, and the time zone that time is read in — and its current state: whether it is armed and when the next deadline falls.
We also keep a record of the transitions themselves: each time a check-in is armed, extended, satisfied, cancelled, or missed, we record that it happened, when, against which deadline, and who did it. That record cannot be altered or deleted by the service afterwards. It is what lets your organization answer, months later, whether its people were checking in — the same question the incident timeline answers about a call-out. A deadline that is missed additionally raises an incident to your own roster, recorded like any other.
If you set a check-in code, or a duress code, we store only an Argon2 hash of it. Neither is ever returned by the service, shown in any screen, or written to a log, and neither can be recovered — a forgotten code is replaced, not retrieved.
Optional safety information
Where these capabilities are available to you, every item in this section is off by default, is collected only if you turn it on for yourself, and is refused by the server for anyone who has not. Turning any of it off takes effect immediately. Some are still being built, and none of them collects anything until you have both been offered it and switched it on. These are optional capabilities for people who want a missed check-in to be actionable by their own roster. Nobody can turn them on for you, and the organization that holds the account cannot enable them on your behalf.
- Location, from your phone. Where you were when a check-in event happened, where you said you were going, and — if you switch it on — where you are for the length of a check-in you have armed, so that a roster looking for you has a trail rather than the spot you set off from. Your phone captures it only inside a check-in you started yourself and during an active incident raised from one. It keeps recording until your check-in ends or, if you miss it, until the incident it raises is closed; your phone collects nothing when you have nothing armed, and nobody else can start it. A trail from a check-in that ended without incident is not a history of your movements: it is deleted about two days later. A trail on an incident is the record of a search, and it is kept with that incident for as long as the incident is — see "How long we keep it" below. A satellite device is different in every one of these respects; it has its own section below.
- Photographs and images. A photograph of you, kept with the date it was taken so anyone using it knows how current it is; a photograph of a vehicle and its details; and still images captured during an active incident.
- Audio. Sound from your device during an active incident, if you have enabled it. Audio capture can record people near you who have not agreed to it, which is a reason to think carefully before turning it on and to know the law where you are.
- Your device's light. If you turn this on, somebody answering an incident raised by your own check-in can switch on your phone's flashlight, steady or flashing, so that a person looking for you can see where you are. It collects nothing about you; what we keep is the record that it was asked for, by whom, and what your phone answered. Your phone puts the light out by itself after a short time whatever else happens, it can never be switched on when no incident of yours is open, and turning this off here puts out a light that is already on.
- A duress signal. If you use a duress code, the fact that it was entered, and when. This is recorded as an incident to your roster.
- Descriptive details you supply. What you are wearing, vehicle information, and anything else you choose to attach so that a person looking for you knows what to look for.
Satellite devices
This section is not part of the optional capabilities above. It is not off by default and it is not yours to switch on: it applies when your organization registers a Garmin inReach to you on its own satellite plan, and it is that registration which starts it.
A satellite device puts its position into every transmission it makes — answering a page, sending a message, or reporting while tracking is on. That is how the satellite network works rather than something we switch on, and Garmin delivers the position to us along with the message. It is not tied to a check-in and not tied to an incident: the device reports whenever it is used.
We keep two things from that. On the device's own record we keep the most recent position and when it was taken, encrypted, each newer position replacing the one before it. That position is shown, with how long ago it was taken: to administrators of your organization, on the page where they manage the people on the account, and to anyone on your organization's account who can see an open incident you are on — one you hold or were paged for — so that they know where to look for you. A transmission sent with no satellite fix does not change any of it. The same transmission also tells us whether the device reports a low battery, so a roster can see a unit that may be about to go quiet.
We also keep each delivery from Garmin exactly as it arrived, as the receipt that we received it and acted on it. That receipt contains the position the message carried, it is stored as we received it rather than encrypted, and today we do not delete it on a schedule — so for a device used regularly these receipts do amount to a history of where it has been. Unregistering the device removes its record and the last known position on it; the receipts already taken remain, and so do they if you delete your account — without your name on them, but still carrying the device's identifier. Ask us and we will remove a device's receipts. We are settling on a retention period for them, and this policy will say what it is once we have.
AlertRoster also learns where your device is in three ways, each through your organization's own Garmin plan. Two of them ask the device itself. While you hold an open incident, AlertRoster turns tracking on, so the device reports on an interval your organization sets, and turns it off again when you hold none. And anyone who can see an open incident you are on can ask your device once for where it is now; every such request is recorded on the incident with who asked. The third does not contact the device: when we hold no position at all for a device on your organization's account — for example because it was registered before your organization connected it to us — we read the last position Garmin already holds for each of the organization's devices, and nothing more of its record, keeping it only where it is newer than the one we have. Garmin holds its own record of your unit's locations under its agreement with your organization, which is not ours and is not covered by this policy.
Your organization can have the app declare an emergency for you. If your organization turns on automatic SOS and has registered an inReach to you, and you miss a check-in while your phone has no signal, the AlertRoster app on your phone declares an SOS on your paired inReach on your behalf. The app first sounds an alarm and gives you time to cancel, unless your organization has set that time to zero. Once the SOS is declared the app never cancels it: you cancel it on the device, or Garmin Response, Garmin's emergency coordination service, stands it down. The SOS goes to Garmin Response under the Garmin plan your inReach is on — your organization's, or, if your organization uses AlertRoster with no Garmin Professional plan, your own — and it carries your name, the name of the check-in you missed, when you were last in contact, your last known position, and your organization's name. If the SOS is on your organization's plan, the app can also send the same details to your roster over the device. What Garmin Response does with them is governed by Garmin's agreement with whoever holds that plan, not by this policy.
Telephone numbers and the switchboard
An access request carries a telephone number if one was given. If your organization uses the managed switchboard, we hold the telephony configuration it set up — the numbers routed to it, the extensions and mailboxes defined, and the names and addresses attached to them — and voicemail left on a monitored mailbox can raise an incident to your roster the same way any other source does.
Signing up, support, and the site
Access requests carry the address and details the person typed, and the IP address they came from. Support requests carry what was written in them. Recording your acceptance of the Terms stores your name, address, the version accepted, the IP address it came from, and the browser's user agent — that record is the proof the agreement was made, so it is kept for as long as the agreement matters.
Our servers keep ordinary operational logs — IP addresses, request paths, timing, and errors — which we use to run the service, find faults, and detect abuse.
Who sees it
Your alerts go to your own roster. The people your organization put there, who agreed in advance to be reachable. Any optional safety information you enabled reaches the same people, on the incident it belongs to, and no further. What a registered satellite device reports is the exception to "on the incident": it is not attached to one, and your organization's administrators can see it on the page where they manage those devices. See "Satellite devices" above.
Nobody here is watching. There is no monitoring center, no staffed operation, and no person at Cloud Bedrock who sees or responds to your alerts. This matters for a privacy policy that describes location, images, and audio: those are things you send to your own roster, not things anyone here receives.
AlertRoster is a call-out notification and escalation tool. It notifies people who have agreed in advance to be notified, and records what happened. It is not an emergency service. It contacts one on your behalf only in the case described under "Satellite devices" above: an automatic SOS your organization has turned on, which the app declares on your inReach. It is not a fire alarm, a security alarm, or an alarm monitoring service, and it holds no life-safety certification. It is not a replacement for your team's official paging arrangements, and it should not be the only way a call-out can reach your people.
We do not sell personal data, and we do not share it for advertising or profiling. There is no advertising in AlertRoster.
If your organization connects AlertRoster to a system of its own — a ticket system, a monitoring platform — incidents flow there because your organization set that up, and what happens to them there is governed by that system.
A member of your roster can generate a report to hand to responders during a search — a single page carrying your photograph, what you said you were wearing and where you were going, your vehicle, and the locations your own device recorded, if you turned those on. The people it is given to are able to read it, and they do not need an account here. It is the one place any of this reaches somebody outside your roster, and it does so only because a person on your roster decided to hand it over.
The terms are the ones this policy set before the capability was built. Sharing is a deliberate act by a member of your roster, never automatic. The link is revocable, and stops working on its own after seven days. Every time it is opened is recorded on the call-out — the moment and the count, not who read it, because we do not learn that and do not want to. When the call-out is closed the page says the search has ended and stops showing your photograph, your description and your locations to whoever still holds it.
Service providers
We use a small number of providers to run the service, each handling only what their function needs:
- Amazon Web Services — hosting, databases, storage, and outbound email, in the United States.
- Apple Push Notification service — delivering alerts to phones and desktops.
- Google reCAPTCHA — on public forms only, to keep automated submissions out.
We may add or change providers as the service changes, and will keep this list current.
When the law asks
We disclose data when we are legally required to, and to establish or defend legal claims. Where we are permitted to tell the customer that we received such a demand, we will.
Where it is held
In the United States. If you are using AlertRoster from elsewhere, your data is transferred to and stored in the United States.
How long we keep it
Account and roster data for as long as the account is active. Incidents, timelines, and delivery records are the operational history a team relies on and are kept for the life of the account unless the customer asks us to remove them.
Optional safety information is kept with the incident it belongs to. It is the category most worth removing when it has served its purpose, so ask if you want it gone from a particular incident and we will remove it.
A satellite device belongs to none of the above and is described in its own section. The last known position on the device's record lasts until a newer one replaces it, and goes when the device is unregistered. The receipts of what Garmin delivered are, today, not deleted on a schedule; each one carries the position its message carried. Ask us and we will remove a device's receipts.
We delete or anonymise an account's data on request, and tell the customer when it is done. We do not yet run an automatic purge on a fixed schedule after an account closes, and we would rather say so than name a number nothing enforces.
Deleting yourself
You can delete your account from within the app, and it takes effect immediately.
What that does is worth being exact about, because it is not a row disappearing. Your name and email address are overwritten; your password, your sessions, and your check-in and duress codes are destroyed; your app installations and their push tokens are removed; you are taken off the on-call rotations; and any armed check-in is stood down, so nothing goes on paging your roster about you. The personal data is gone, with one exception named here rather than left to be discovered: the receipts of what a satellite device sent remain, no longer bearing your name but still bearing the device's own identifier and the positions its messages carried. Ask and we will remove them. What remains otherwise is the incident history with your name no longer in it: an incident someone acknowledged at 03:14 still says it was acknowledged at 03:14, by a deleted user. Erasing that instead would leave a team unable to reconstruct a call-out, and would rewrite a record other people also relied on.
Your rights
Depending on where you live, you may have the right to see what we hold about you, correct it, delete it, obtain a copy, or object to how it is handled. Ask us and we will act on it — and where the data belongs to a customer's account, we will work with that organization, which is the controller for it.
We will not treat you differently for exercising any of these rights.
How it is protected
Every account's data is separated inside the database itself, by the database, rather than by application code remembering to filter — a query that forgets which account it is for returns nothing rather than somebody else's rows. Traffic is encrypted in transit; passwords and check-in codes are stored only as Argon2 hashes; and sensitive configuration is encrypted at rest.
No system is perfectly secure, and we do not claim otherwise.
Children
AlertRoster is for adults responding on a roster. It is not directed at children under 13 and we do not knowingly collect their personal data. If you believe a child has provided us data, tell us and we will remove it.
Changes
We update this policy when what we do changes. The effective date and version at the top move when it does. A change that materially expands what we collect will be announced in the product, not left to be discovered here.
Contact
Reach us through support with any question about this policy or about data we hold.