Data Processing Agreement

1. Scope and roles

This Data Processing Agreement (“DPA”) forms part of the Terms of Service between FortressFlag LLC (“FortressFlag”) and the Customer, and applies whenever FortressFlag processes personal data on the Customer’s behalf in providing the Service.

For that processing the Customer is the controller and FortressFlag is the processor. Where the Customer is itself a processor for a third-party controller, FortressFlag is a sub-processor and this DPA applies as if the Customer were the controller.

FortressFlag is a separate, independent controller for the account data it collects to run its own business — who signed up, who signs in, billing contacts, and the support correspondence the Customer’s personnel submit through the product’s support section. That processing is described in the Privacy Policy and is outside this DPA.

“GDPR” means Regulation (EU) 2016/679 and, where applicable, the UK GDPR read with the Data Protection Act 2018. “Personal data”, “processing”, “controller”, “processor”, “data subject” and “personal data breach” have the meanings given in the GDPR.

2. Description of the processing (Article 28(3))

Subject matter. Provision of the FortressFlag feature-flagging platform.

Duration. The term of the Terms of Service, plus the retention periods in section 10.

Nature and purpose. Storing and serving the Customer’s feature-flag configuration; evaluating targeting rules against attributes reported by the Customer’s applications; counting distinct devices for billing; recording an audit trail of changes; authenticating the Customer’s own personnel.

Types of personal data.

Category	What it is	Notes
Account data of Authorised Users	Name, email address, role, and the IP address of a sign-in or of an audited action	The people the Customer gives dashboard access to.
Device identifiers	A random 128-bit identifier minted by our SDK on each device, prefixed dev_	Pseudonymous. Never derived from a hardware identifier or from end-user data, and we hold no mapping from it to any person.
Evaluation attributes	Attributes the Customer’s application reports about a device at evaluation time	Processed in memory and never stored or logged. What they contain is the Customer’s choice — see section 3.3.
Customer Content	Flag keys, names, descriptions, targeting rules, segment definitions	Free text authored by the Customer. Should contain no personal data; see section 3.3.

Categories of data subjects. The Customer’s personnel and contractors who use the dashboard; end users of the Customer’s applications, to the extent a device identifier or an evaluation attribute relates to them.

No special-category data. The Service is not designed for and must not be used to process data within Article 9 GDPR. The Acceptable Use Policy prohibits putting it into the Service.

3. FortressFlag’s obligations

3.1 Documented instructions (Art. 28(3)(a)). FortressFlag processes personal data only on the Customer’s documented instructions, including with regard to transfers to a third country. The Terms of Service, this DPA, and the Customer’s use of the Service’s features are the Customer’s complete documented instructions. FortressFlag will inform the Customer if it believes an instruction infringes the GDPR, unless the law prohibits it from doing so.

Where FortressFlag is required by Union or Member State law to process personal data beyond the Customer’s instructions, it will inform the Customer of that requirement before processing, unless the law prohibits that on important grounds of public interest.

3.2 Confidentiality (Art. 28(3)(b)). FortressFlag ensures that persons authorised to process personal data are bound by an obligation of confidentiality, contractual or statutory, and are granted access on a least-privilege basis.

3.3 What the Customer must not send. Evaluation attributes are evaluated server-side and never persisted or written to a log; at most, a log line records how many attributes a request carried and, on a validation failure, the offending key. Flag configuration fields are free text. The Customer controls what goes into both, and the Acceptable Use Policy prohibits personal data there. FortressFlag has no way to detect a breach of that prohibition and is not the controller of anything the Customer chooses to put in a field designed for configuration.

3.4 Security (Art. 28(3)(c), Art. 32). FortressFlag implements appropriate technical and organisational measures, described in Annex A. The Annex describes the measures as they are today, including the ones that are not yet in place, and is updated as they change.

3.5 Sub-processors (Art. 28(2), 28(3)(d), 28(4)). The Customer gives general written authorisation for FortressFlag to engage sub-processors. The current list is published at fortressflag.com/legal/subprocessors.

Before a new or replacement sub-processor begins processing, FortressFlag will give at least [[SUBPROCESSOR_NOTICE_DAYS]] days’ notice in the product — a notice every member of the organisation sees on signing in. Notice is given in the product deliberately: it is the one channel every member of an organisation reliably has, and a notice shown at sign-in cannot bounce, go to spam, or reach only a stale contact address.

The Customer may object on reasonable data-protection grounds within [[OBJECTION_DAYS]] days of that notice. The parties will discuss the objection in good faith; if it cannot be resolved, the Customer may terminate the affected part of the Service and receive a pro-rata refund of prepaid, unused fees.

FortressFlag imposes on each sub-processor data-protection obligations no less protective than those in this DPA, and remains fully liable to the Customer for its sub-processors’ performance.

3.6 Assistance with data subject rights (Art. 28(3)(e)). Stated as it actually is today, because a commitment written to what a product might one day do is not a commitment:

• Self-service export, erasure and rectification do not exist. There is no data-subject export endpoint, no self-service erasure path, and no way for a member or an administrator to edit a member’s name or email address. Building them is planned work, not a shipped feature.
• What FortressFlag does instead is manual, and it is available. On the Customer’s written request, FortressFlag will locate, export, correct or erase personal data relating to an identified data subject, and confirm what it did. Requests go to [[PRIVACY_CONTACT]].
• Timing. FortressFlag responds without undue delay and in any event in sufficient time for the Customer to meet its own deadline under Article 12(3).
• What the Service already gives the Customer directly. Administrators can see and remove memberships, and can revoke credentials, from the dashboard. Erasing a member’s account clears the mapping from the audit log’s pseudonymous actor reference to that person; the audit records themselves are retained, so the log continues to show that an actor performed a sequence of actions without identifying who.
• Device identifiers cannot be targeted by an erasure request, because FortressFlag holds no mapping from an identifier to a person. The available remedies are the SDK’s resetIdentity() — after which the device presents a new identifier — and retention expiry (section 10).
• Requests received directly from a data subject are not answered by FortressFlag on the Customer’s behalf. FortressFlag forwards them to the Customer without undue delay.

3.7 Assistance with Articles 32–36 (Art. 28(3)(f)). Taking into account the nature of the processing and the information available to it, FortressFlag assists the Customer in ensuring compliance with Article 32 (security), Articles 33 and 34 (breach notification), and Articles 35 and 36 (data protection impact assessment and prior consultation).

3.8 Personal data breach. FortressFlag notifies the Customer without undue delay, and in any event within [[BREACH_NOTICE_HOURS]] hours, of becoming aware of a personal data breach affecting the Customer’s personal data, and provides the information the Customer reasonably needs to meet its own Article 33 obligation.

3.9 Return and deletion (Art. 28(3)(g)). On termination, and at the Customer’s choice, FortressFlag deletes or returns the personal data it processes on the Customer’s behalf, and deletes existing copies, unless Union or Member State law requires storage. The export routes and the transitional period are in section 11.3 of the Terms of Service. Audit history is deleted as a deliberate, separately authorised operation.

3.10 Information and audits (Art. 28(3)(h)). FortressFlag makes available the information necessary to demonstrate compliance with Article 28, and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates. The Customer may request an audit no more than [[AUDIT_FREQUENCY]], on reasonable notice, during business hours, subject to confidentiality, and without access to another customer’s data or to FortressFlag’s shared infrastructure in a way that would compromise it. Where FortressFlag holds a current third-party audit report or certification covering the request, providing it discharges this obligation for that scope.

4. International transfers

FortressFlag’s control plane and its sub-processors may process personal data outside the European Economic Area and the United Kingdom. Where a transfer requires a safeguard under Chapter V GDPR, the parties rely on:

• the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller to processor) or Module Three (processor to processor) as applicable, which are incorporated into this DPA by reference and are deemed executed by the parties on acceptance of these documents. The optional docking clause applies; the option in clause 11(a) for an independent dispute-resolution body does not; the supervisory authority is that of the Customer’s place of establishment; the governing law and forum are those of the Member State in which the Customer is established; Annexes I, II and III are populated by section 2, Annex A and the sub-processor list respectively.
• the UK International Data Transfer Addendum (version B1.0), incorporated by reference where the UK GDPR applies, with the Standard Contractual Clauses above as its Approved EU SCCs, and with the Addendum’s tables populated by the same sections. Neither party may end the Addendum under its section 19.

FortressFlag will inform the Customer if it becomes subject to a law that prevents it from meeting these commitments, and will take reasonable measures to challenge unlawful access requests.

5. Other regimes

California. For personal information subject to the CCPA as amended by the CPRA, FortressFlag acts as a service provider. It does not sell or share personal information, does not retain, use or disclose it for any purpose other than performing the Service, and does not combine it with personal information from another source except as the CCPA permits. FortressFlag certifies that it understands and will comply with these restrictions.

6. Liability

Each party’s liability under this DPA is subject to the limitations in section 8 of the Terms of Service, except where those limitations are unenforceable under applicable data-protection law.

7. Precedence

Where this DPA and the Terms of Service conflict on the subject of personal data, this DPA prevails. Where this DPA and the Standard Contractual Clauses conflict, the Clauses prevail.

8. Changes

FortressFlag publishes a new version of this DPA at a permanent, dated URL, never editing a published version in place. Material changes are notified in the product and take effect when an administrator of the Customer accepts the new bundle version.

9. Contact

Privacy correspondence, including requests under section 3.6: [[PRIVACY_CONTACT]], or by post to FortressFlag LLC, [[ENTITY_ADDRESS]].

10. Retention

Data	Retained for
Flag configuration, targeting rules, segments, projects, environments	The term, then deleted per section 3.9.
Membership and account records	The life of the account.
Audit history	Retained for the life of the customer relationship. Deleted only by a deliberate, separately authorised purge — the audit table refuses ordinary deletion.
Device identifiers (device_seen)	13 months, then removed by dropping the storage partition.
Monthly device counts	Retained as billing history. They contain no identifiers.
Contract-acceptance evidence	Retained for the life of the customer relationship and for as long as a claim under the Terms of Service may be brought. This includes the accepting person’s email address as it stood at acceptance, which survives erasure of that person’s account — see section 11.

11. Contract evidence and the erasure exception

One narrow category of personal data survives an Article 17 erasure request: the record that a named person accepted a specific version of these documents on behalf of the Customer.

That record holds the acceptor’s email address as a snapshot taken at the moment of acceptance, the version of each document as served, its content hash, the time, and the originating IP address. It survives the deletion of the person’s account because it is evidence of a contract with the organisation, and deleting it would destroy FortressFlag’s own record of an agreement it relies on.

The lawful basis for retaining it is Article 17(3)(e) GDPR — establishment, exercise or defence of legal claims. It is the only deliberate exception to the deletion-on-erasure model described above, it is minimised to the fields listed, and it is not used for any other purpose.

Annex A — Technical and organisational measures

Described as they stand, including what is not yet in place. A measure listed as planned is not a measure.

Tenancy isolation. Every data-access path is scoped by organisation, project and environment. An automated build gate fails the build on any query against an organisation-owned table that does not name the organisation boundary. Access to a project a member has not been granted is refused as if the project did not exist.

Access control. Role-based access control with owner, admin, developer and viewer roles. Production flag changes by the weaker writing role require approval by a second person. Per-project allowlists for viewers and developers. FortressFlag’s own support staff hold no standing access to any customer organisation: a staff member enters one only through an explicit, time-boxed access grant, the grant and every action taken under it appear in that organisation’s own audit log, and it can be revoked at any time.

Authentication. Password authentication with Argon2id hashing; optional organisation-wide TOTP second factor; optional SAML single sign-on with SCIM provisioning against the Customer’s identity provider. Rate limiting on authentication and on the management and data-plane APIs.

Audit logging. Every state change writes an append-only record of who, what, when, from where, and before/after. The record is enforced by a database trigger that refuses updates and refuses deletes without an explicit, separately authorised opt-in. The log is exportable by the Customer. The actor is stored as a pseudonymous internal reference so that erasing a person does not destroy the record.

Data minimisation. Evaluation attributes are never persisted or logged. Device identifiers are random and are never derived from hardware identifiers. User-agent strings are not collected. Column -level data classification is enforced at build time, and the record of processing activities is checked against the schema by the same gate.

Encryption in transit. TLS 1.2 or above on every external connection.

Encryption at rest — NOT YET IN PLACE. The Service is not yet deployed to production infrastructure, and key-managed encryption at rest for the database, backups and artefacts is infrastructure work that has not been built. This will be corrected before the Service is generally available, and this Annex will be updated when it is.

Sub-processor governance. The list in Sub-processors is the complete set. Adding one is a documented decision, not a vendor choice.

Change management. All changes via reviewed pull request; automated security, dependency and secret scanning gate every merge; no direct pushes to protected branches. FortressFlag is a very small organisation, and the segregation-of-duties limits that follow from that are documented in its internal change-management record rather than glossed over here.

Incident response. A written breach-response runbook exists. Two decisions in it — the notification window and the lead supervisory authority — remain open and are placeholders in section 3.8 of this DPA for that reason.

Certifications. None held today. SOC 2 Type II is a stated engineering objective and is not yet audited. Claiming otherwise would be a misrepresentation.