Security

This page covers what we store and where, who can reach it, and what happens if we go down. It's written for security reviews. If your question isn't answered here, write to us.

What we keep, and where

• Consent records (each visitor's choice, the banner they saw, when they chose, and where they were: the country, plus the state or province in the US and Canada) are kept in a database restricted to the EU. We never store IP addresses in any form. A visitor's IP address is used only to work out where they are, then discarded.
• Accounts: your team's email addresses and roles, and your site settings, are kept in the same EU database.
• Each site chooses how long its consent records are kept: 1, 2, 3 or 5 years. Older records are deleted automatically every day. If a deletion would remove far more than usual (after the retention period is shortened, for example), the owner is told a week ahead so they can export first. Putting a site on hold (during a dispute, for example) stops deletion altogether.
• Every company that processes personal data for us is on the subprocessor list, and we give 30 days' notice before any change to it. Our Data Processing Agreement covers all of this, with the EU Standard Contractual Clauses for transfers.

Encryption

• Everything travels over HTTPS.
• Stored data is encrypted at rest by our host, Cloudflare (D1 data security).
• We also encrypt two-factor secrets and single sign-on client secrets ourselves (AES-GCM) before storing them. Recovery codes, API keys, SCIM tokens and sign-in links are stored only as hashes.

Who can reach your data

• Roles: owner, admin, editor and viewer, and access can be limited to particular sites. Every request is checked against these in one place.
• Two-factor sign-in uses an authenticator app. A workspace can require it of everyone.
• Single sign-on works through your identity provider (OpenID Connect or SAML 2.0) for a company domain you've proved you own with a DNS record. You can make it the only way to sign in.
• SCIM provisioning lets your identity provider add people and switch them off. Switching someone off ends their sessions and stops their API keys at once.
• API keys act as the person who made them, with that person's role, and stop working when that person leaves.
• People sign in with an emailed link or with single sign-on, so there are no passwords to leak.

Audit logs

• Settings: every change is logged with who made it, when, and the values before and after.
• Consent records: every view, download and deletion is logged, with the person or API key that did it.
• Team: invites, role changes, removals and changes to sign-in settings are logged.
• Tamper evidence: each day's consent records are chained into a fingerprint, which two independent authorities timestamp (RFC 3161), and exports are signed, so a record can't be changed without it showing. How to check a record.

How we build and release

• Every code change is type-checked and tested automatically before it's deployed.
• A new banner version first goes to a small share of sites (normally 5%) for 48 hours. When that trial starts, we run the new and current versions side by side on real sites for every platform we support and on installed customer sites. The new version reaches everyone only if every one of those sites reported back and nothing regressed; a regression stops the trial. A banner file never changes once it's released.
• Changes to the legal rules go through similar steps: a week's trial with checkout rehearsals on real stores, then 5% of sites for 48 hours, then everyone. They can be rolled back at once.

If we go down

We aim for 99.9% availability each month (about 43 minutes of downtime at most).

The banner is designed to fail closed. If it can't reach us, the trackers it holds stay held (even for visitors who had said yes), no banner appears, and your site and its checkout keep working. Payment, checkout and sign-in services are never blocked. If the banner script itself couldn't be downloaded because our delivery network was unreachable, nothing would be held automatically. Your site would still work, but trackers that only the banner holds would run. Tags you've marked to wait for consent (see Embeds and scripts) stay off either way. The status page shows current and past availability.

Certifications

Flat Consent isn't SOC 2 or ISO 27001 certified yet. Our host, Cloudflare, holds SOC 2 Type II and ISO 27001. We're glad to fill in security questionnaires; write to hello@flatconsent.com.

Reporting a vulnerability

Write to hello@flatconsent.com with “Security” in the subject. We'll reply as soon as we can and keep you posted while we fix it. Please don't access other people's data or disrupt the service while testing. The same details are in our security.txt.