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. What we attempted to deliver to which device appears in our operational logs rather than in a record kept for you.
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. That state is kept in place rather than as a history, so satisfying, extending, or cancelling moves it and leaves no separate record. A deadline that is *missed* does leave one: it 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. Where you were when a check-in event happened, and where you said you were going. Captured at those moments and during an active incident raised from them — never continuously, never in the background, and never as a history of your movements. There is no map of where anyone is.
- 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.
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.
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 and does not contact one on your behalf. 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.
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. What remains 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.