Security
Described as it stands.
Every control below is marked Operating or Planned. A measure listed as planned is not a measure — the same rule our Data Processing Agreement applies to itself.
As of 2026-10-30. Report a vulnerability to security@fortressflag.com.
Tenancy and access
Tenant isolationEvery data path is scoped by organisation, project and environment, and a build gate fails the build on any query against an organisation-owned table that does not name the organisation.Operating
Role-based accessFour roles — owner, admin, developer and viewer — with access decisions that default to deny.Operating
Two-person production changesA production flag change by the weaker writing role needs approval from a second person.Operating
Project allowlistsViewers and developers see only the projects they are granted; any other project answers as if it did not exist.Operating
No standing staff accessFortressFlag staff enter an organisation only through an explicit, time-boxed grant, and the grant and everything done under it appear in that organisation's own audit log.Operating
Authentication
Password hashingArgon2id with 64 MiB of memory, 3 iterations and 4 lanes; passwords of at least 12 characters.Operating
SessionsHttpOnly, Secure, SameSite cookies with the __Host- prefix; sessions end after 30 days at most, or 7 days without use, and every session ends when the password is reset.Operating
Second factorOptional organisation-wide TOTP, with single-use recovery codes.Operating
Single sign-onSAML single sign-on and SCIM provisioning against your identity provider, with owner-minted, hashed, revocable SCIM tokens.Operating
Rate limitingSign-in is limited per address and per account, alongside the management and data-plane APIs; the limiters fail closed.Operating
Password resetSingle-use, hashed reset links that expire after an hour, rate-limited per email address and per source address.Operating
Audit and logging
Append-only audit logEvery state change records who, what, when, from where and before/after; a database trigger refuses updates and refuses deletes without a separately authorised opt-in.Operating
Pseudonymous actorsThe actor is stored as an internal reference, so erasing a person does not destroy the record; the source address is recorded and never served back.Operating
ExportAdministrators can export the complete filtered audit history as CSV.Operating
Request logsStructured request logs carry no headers, bodies or query strings, and every response carries a request ID.Operating
Hash-chained integrityThe audit log is tamper-resistant, not tamper-evident: there is no hash chain yet.Planned
Data minimisation and privacy
Evaluation attributesThe attributes your application sends to evaluate a flag are never stored or logged.Operating
Device identifiersRandom, never derived from hardware identifiers, and FortressFlag holds no mapping from a device to a person; simulator devices are never billed or stored.Operating
No trackingNo analytics, advertising, session recording or third-party trackers in the website, the docs or the dashboard; user-agent strings are not collected.Operating
Classification at build timeEvery column carries a data classification, and the record of processing activities is checked against the schema by the build.Operating
Retention as publishedDevice records are dropped after 13 months; audit history is kept for the life of the relationship; contract-acceptance evidence is kept as the Privacy Policy explains.Operating
Session-record expirySession records, including the sign-in address, are retained indefinitely today: expiry is enforced when a session is read, but no job deletes old ones.Planned
Self-service data-subject requestsExport, correction and erasure are handled by hand on request to privacy@fortressflag.com; there is no self-service screen yet.Planned
Encryption
In transitTLS 1.2 or later on every external connection; HSTS on the website, the docs, the dashboard and the API; email submitted only over STARTTLS.Operating
At restThe database, its backups, the cache, stored secrets, logs and the storage behind the websites and the dashboard are encrypted with AWS KMS customer-managed keys, with key rotation.Operating
Signed flag payloadsFlag payloads delivered to your applications are signed with Ed25519, and the SDKs verify the signature before using them.Operating
CredentialsPasswords, session tokens, SDK keys and reset links are stored only as one-way hashes.Operating
Infrastructure
HostingAmazon Web Services, one Region — us-east-2 (Ohio) — for the database, the API and the application data.Operating
NetworkThe database and cache sit in private subnets with no internet route; the API runs behind a load balancer and accepts traffic only from it.Operating
BackupsDaily automated database backups, encrypted and kept for 30 days, with a standby replica in a second availability zone.Operating
Backup restore drillA restore from backup has not yet been rehearsed.Planned
Least privilegeEach workload and deploy identity can reach only what it needs; secrets are referenced by ARN and never stored in code; no storage is public.Operating
Scheduled jobs and alertingRetention purge, scheduled changes and metering run on a schedule with failure alarms, and service alarms page a person.Operating
Account audit trailEvery API call against the hosting account is recorded by AWS CloudTrail with log-file validation.Operating
Change management and supply chain
Reviewed changesEvery change is a pull request that automated checks must pass; infrastructure changes are reviewed as a plan before they are applied.Operating
Security scanningStatic analysis, reachability-based dependency scanning and secret scanning run on every pull request; Dependabot raises updates weekly.Operating
Hardened imagesThe service ships in a distroless image that CI asserts contains no shell.Operating
Branch protectionEnforced by GitHub on the public SDK repositories (signed commits, required checks, no bypass); the private repositories rely on the documented process.Operating
Single maintainerFortressFlag is a very small team: self-approval occurs, and the compensating controls are documented and dated rather than glossed over.Operating
Vulnerability disclosure
ReportingEmail security@fortressflag.com, also published in /.well-known/security.txt.Operating
Response targetsAcknowledgement within 3 business days, an initial assessment within 10, and a fix or documented mitigation for critical and high findings within 30 days of assessment.Operating
Safe harbourGood-faith research against your own organisation is welcome, with coordinated disclosure.Operating
Incident response
Breach notificationCustomers are notified within 72 hours of FortressFlag becoming aware of a personal data breach, as the Data Processing Agreement commits.Operating
RunbookA written breach-response runbook exists; it has not yet been exercised in a drill.Planned
Certifications and assessments
CertificationsNone held. SOC 2 Type II and ISO 27001 are planned; the controls on this page are operating and auditable today.Planned
Penetration testNo third-party penetration test has been performed yet.Planned
The full list of third parties that process customer data is on the sub-processors page, and Annex A of the Data Processing Agreement is the contractual statement of these measures. Annex A changes only when a new version of the legal documents is published; where this page is newer, this page is current.