Data processing terms
These terms apply whenever you use IncidentFlare to handle personal data about other people — the contact details of the people you page, and the email addresses of the people who subscribe to your status page. For that data you are the controller and we are the processor, and Article 28 of the GDPR requires this to be written down.
They form part of the terms of service and apply automatically. No signature is needed and there is no separate form to request. If your procurement process requires a signed copy, write to privacy@incidentflare.com.
1. What is processed
| Subject matter | Providing status pages, uptime monitoring, alerting and on-call scheduling |
|---|---|
| Duration | For as long as you have an account, plus the deletion timings in section 8 |
| Nature and purpose | Storing your configuration, delivering alerts to the people you nominate, and sending status updates to people who asked for them |
| Categories of data subject | Your colleagues and responders; people who subscribe to your status page; people whose details you enter into an incident |
| Categories of personal data | Names, email addresses, phone numbers where you enter them, Telegram chat ids, Slack and webhook destinations, and the record of what was sent to whom and when |
| Special categories | None. Do not put health, biometric or similar data into the product |
2. What we will do
- Process this data only on your documented instructions. Using the product is the instruction; anything else needs a request from you, unless the law compels us, in which case we tell you first unless we are forbidden to.
- Keep it confidential, and make sure the small number of people who can reach production are bound to the same.
- Apply the security measures in section 5, and keep them current.
- Help you answer requests from data subjects — the delete button does this without us being involved, and we will produce a copy of your workspace whenever you ask for one.
- Help you with security assessments and breach notifications, given what we know about the service.
- Tell you what you need to know to demonstrate compliance, and not obstruct an audit you are entitled to (section 7).
3. What you undertake
- That you have a lawful basis for the data you put in, and for asking us to send messages to it.
- That you tell your responders their contact details are here and what they are used for.
- Not to add subscriber addresses that did not ask. We send every subscriber a confirmation link before anything else, which is a safeguard rather than a substitute for your responsibility.
4. Sub-processors
You give general authorisation for us to use the sub-processors listed on the sub-processors page. Each is bound by terms no weaker than these, and we remain responsible for what they do.
Before adding or replacing one we will email account holders at least 30 days beforehand. If you reasonably object on data protection grounds, tell us within those 30 days; if we cannot resolve it, you may terminate and receive a refund of any paid period you have not used.
Slack, your own webhook endpoints and any other destination you configure are not sub-processors. Those are recipients you chose, and what happens once a message reaches them is between you and them.
5. Security measures
- Encryption in transit over HTTPS for the application and its API.
- Passwords stored with bcrypt; session and API tokens stored only as hashes.
- Optional two-factor authentication on the accounts that can reach your data, with secrets encrypted under a key held outside the database.
- Tokens scoped to a single status page, separated into write and ingest, and individually revocable, so a leak in a CI pipeline does not need a password change.
- Outbound requests from monitors and webhooks blocked from private and loopback address ranges, so the service cannot be turned into a probe of internal networks.
- Rate limiting on authentication and on public endpoints.
- Access to production limited to the people operating the service.
- Backups of the database, held no longer than 30 days.
- Data isolated per workspace, with every query scoped to the workspace of the credential that made it.
6. Personal data breach
If we become aware of a breach affecting your data we will notify you without undue delay and in any event within 48 hours, with what happened, which data is involved as far as we know, what we are doing, and what we suggest you do. Notifying your supervisory authority within your own 72 hours remains yours to do; we will give you what you need for it.
7. Audits
We will answer a reasonable written security questionnaire once a year, and provide the documentation we have. An on-site audit is not something this service can support today; if you need one, say so before you rely on us, and we will tell you honestly whether we can meet it rather than agree and disappoint you.
8. Deletion and return
You can ask us at any time for a machine-readable copy, and delete the account yourself. Deleting it removes the workspace, its subscribers and its history immediately from the live database. Backups age out within 30 days, after which no copy remains.
When the agreement ends we delete the data rather than keep it, unless the law requires us to hold something, in which case we hold only that and only for as long as required.
9. International transfers
Data is processed in the European Union. Where a sub-processor involves a transfer outside it, that transfer relies on an adequacy decision or on the European Commission's standard contractual clauses, and the position for each is stated on the sub-processors page.
10. Order of precedence
If these terms conflict with the terms of service, these win for anything about personal data. Neither can reduce a right the GDPR gives a data subject.