fremforge Data Processing Agreement

title: fremforge Data Processing Agreement author: fremverk date: 2026-08-06 status: Published v1.34 version: “1.34” lang: en #

Last updated: 2026-08-06

Effective Date: 2026-04-25 — Current Version: 1.34 (effective 2026-08-06; full revision history in §Change log)

This Data Processing Agreement (“DPA”) is entered into between fremverk ApS and the Customer in connection with the fremforge service, pursuant to Article 28 of Regulation (EU) 2016/679 (General Data Protection Regulation, “GDPR”). It supersedes any inconsistent provision in the Terms of Service for matters within its scope.

1. Parties #

Processor: fremverk ApS
CVR: 39150689
VAT: DK39150689
Registered office: Ringager 4C, 2. tv, 2605 Brøndby, Denmark
Data protection contact: compliance@frem.sh

Controller: the Customer identified in the Terms of Service between the parties.

2. Definitions #

Terms defined in the GDPR have the meanings given there. “Service” means the fremforge product at frem.sh as described in the Terms of Service §2. “Sub-processor” means any third party engaged by fremverk that processes Customer Personal Data. “Customer Personal Data” means personal data (as defined in GDPR Art. 4(1)) processed by fremverk on behalf of the Customer in connection with the Service, including the categories enumerated at §4.1 below — Customer Content (whatever the Customer or its Users commit, post, comment, or upload), authentication metadata (OIDC/SAML claims, session tokens, PAT identifiers), usage and technical data (IP addresses, user agents, action timestamps), commit-author identities, billing-contact identifiers, and inbound support correspondence — but excluding anonymised aggregates from which the Customer cannot reasonably re-identify a data subject.

3. Subject matter, duration, nature, and purpose #

• Subject matter: fremverk’s processing of personal data contained in Customer Content and operational metadata, as processor on behalf of the Customer, for the purpose of providing the Service.
• Duration: the term of the Terms of Service, plus the retention periods set out in §9 below.
• Nature of processing: hosting, storage, transmission, collection, structuring, retrieval, consultation, display, erasure, and related operations necessary to provide the Service.
• Purpose: to provide the Service to the Customer and to comply with fremverk’s legal obligations.

4. Types of personal data and categories of data subjects #

4.1 Types of personal data #

The following categories of personal data are typically processed:

• Identity and contact: names, usernames, email addresses, organisation affiliation.
• Authentication: OIDC/SAML subject identifiers and claims, TOTP secrets (where enabled), personal access tokens, session and API token identifiers.
• Usage and technical: IP addresses, user agents, timestamps of actions, admin-UI and API calls, commit author identities and email addresses, issue and PR participation.
• Repository and collaboration content: whatever the Customer or its Users commit, post, comment, or upload, which may contain personal data as determined by the Customer.
• Billing and commercial: organisation legal name, billing contact, VAT number, invoice records. Raw payment-card and bank-account data is processed by Mollie only; fremverk does not see or store it.
• Support correspondence: whatever the Customer sends to support@frem.sh, abuse@frem.sh, compliance@frem.sh, security@frem.sh, or hello@frem.sh, plus attachments.

No special categories of personal data under GDPR Art. 9 or Art. 10 are expected to be processed. If the Customer intends to use the Service for special-category data, it notifies fremverk in advance and the parties agree on additional safeguards.

4.2 Categories of data subjects #

• Employees, contractors, and agents of the Customer who use the Service.
• Authors of commits, issues, PRs, comments, and wiki pages, including external contributors to public repositories enabled by the Customer.
• Recipients and senders of webhook deliveries, where the Customer configures them.
• AI agents (from Phase 2+) acting on behalf of a User under a scoped delegated mandate, where the mandate metadata or audit trail contains personal data linking the agent to the User.

5. Obligations of the Controller #

The Customer, as Controller:

• Ensures it has a lawful basis for processing each category of personal data included in Customer Content.
• Provides the information to data subjects required under GDPR Art. 13 and 14.
• Responds to data-subject requests directed to it as Controller, with support from fremverk as described in §7.
• Issues documented instructions to fremverk in these terms and through its configuration of the Service (including SSO setup, policy settings, public-repo toggle, and mandate issuance). fremverk will not process Customer Personal Data outside these instructions except as required by Union or Danish law, in which case fremverk informs the Customer unless prohibited by law.

The Customer’s documented instructions to fremverk consist of (i) this DPA, (ii) the Terms of Service, (iii) the Service configuration set by Customer admins through the Service, and (iv) further written instructions sent to compliance@frem.sh by an authorised representative of the Customer. fremverk processes Customer Personal Data only on instructions in these forms. fremverk informs the Customer (consistent with §6 below) if, in its opinion, an instruction infringes the GDPR or other applicable data-protection law.

6. Obligations of the Processor (fremverk) #

fremverk:

• Processes Customer Personal Data only on the documented instructions of the Customer, including those in this DPA and those given via Service configuration. fremverk applies the data-minimisation principle (GDPR Art. 5(1)(c)) to its own processing — it does not collect, retain, or process Customer Personal Data beyond what is necessary to provide the Service and comply with its legal obligations.
• Immediately informs the Customer (GDPR Art. 28(3)(h)) if, in fremverk’s opinion, an instruction received from the Customer infringes the GDPR or other applicable Union or Danish data-protection law. Pending resolution, fremverk is entitled to suspend performance of the infringing instruction without liability under the Terms of Service for the duration of the suspension.
• Ensures that all personnel authorised to process Customer Personal Data are bound by confidentiality obligations.
• Implements the technical and organisational security measures set out in the Annex A — Security Measures, which meet the requirements of GDPR Art. 32.
• Respects the conditions for engaging Sub-processors (§10) and international transfers (§11).
• Assists the Customer with data-subject requests (§7) and with Art. 32–36 obligations (§8).
• Returns or deletes Customer Personal Data at the end of the Service in accordance with §9.
• Makes available to the Customer information necessary to demonstrate compliance with Art. 28 obligations, and allows audits as described in §12.

6A. No AI training on Customer data #

fremverk shall not, and shall not permit any sub-processor to, use Customer Content, Customer Personal Data, or operational metadata derived from the Customer’s use of the Service to train, fine-tune, evaluate, develop, or improve any general-purpose AI model, machine-learning model, foundation model, or large language model, whether for fremverk’s benefit, the sub-processor’s benefit, or any third party’s benefit. This prohibition applies regardless of whether the data is anonymised, pseudonymised, or aggregated. AI features that are part of the Service and operate on Customer Content (for example, agent mandates as set out in AUP §12 and the Documentation) act on the Customer’s instruction at run time. fremverk does not retain Customer Content sent through those features beyond the request lifecycle, and does not use it for training.

Scope of this prohibition, stated precisely because the distinction is material. The prohibition above binds fremverk and fremverk’s sub-processors, which fremverk controls by contract. It does not and cannot bind an AI vendor that the Customer configures itself: for those features the Customer chooses the vendor, contracts with it directly and pays it directly, and fremverk acts as a conduit that encrypts the Customer’s API key at rest and forwards the request. Whether that vendor trains on the content the Customer sends is governed by the Customer’s own agreement with that vendor, not by this DPA — some vendor tiers permit training by default. fremverk applies no technical control that would prevent it and does not represent that it can.

Until 2026-08-06 this clause stated without qualification that Service AI features “do not retain Customer Content in model weights or training corpora”. For fremverk and its sub-processors that remains true. For a Customer-configured vendor it was a statement fremverk had no standing to make, and a Customer choosing a consumer-tier vendor account could reasonably have relied on it. Customers who require a contractual no-training guarantee on that path should obtain it from their chosen vendor — typically an enterprise or zero-retention tier — or use Enterprise-on-Demand, under which fremverk will contract with a vendor directly and the prohibition above then applies.

7. Assistance with data-subject requests #

Where fremverk receives a data-subject request directly, it forwards the request to the Customer and does not respond substantively except to confirm receipt and the routing, unless the request relates to personal data for which fremverk is Controller (account data, billing data, operational logs attributed to fremverk as Controller).

On reasonable request by the Customer, fremverk provides technical assistance — including the on-demand signed export for org data, audit-log exports, and user-specific deletion — to enable the Customer to respond within GDPR’s deadlines. Assistance beyond the export and admin-UI functionality already provided by the Service may be chargeable at fremverk’s reasonable rates, to the extent permitted under GDPR Art. 28(3)(e).

fremverk responds to Customer assistance requests within 5 business days of receipt and provides the requested assistance within the timeframe necessary for the Customer to meet its own GDPR deadline. Reasonable assistance for routine data-subject requests is included in the standard Subscription. Disproportionate or repeated requests, or requests requiring substantial engineering effort beyond standard tooling, are charged at fremverk’s then-current professional-services rates as published on the pricing page or as agreed in an Order Form.

8. Assistance with security, breach notification, impact assessments, consultations #

8.1 Incident and breach notification #

fremverk notifies the Customer of any Personal Data Breach affecting Customer Personal Data without undue delay, and in any event no later than 24 hours after becoming aware of the breach. The 24-hour outer limit does not waive the GDPR Art. 33 “without undue delay” obligation: where fremverk becomes aware of a breach earlier in the 24-hour window, fremverk shall notify as soon as reasonably practicable consistent with confirming the relevant facts. Notification is sent by email to the Customer’s designated security contact (or, where none has been designated, the Customer’s account-of-record administrator) and posted to status.frem.sh if the breach affects multiple Customers. The notification includes, to the extent then known: the nature of the breach, categories and approximate numbers of data subjects and records concerned, likely consequences, and measures taken or proposed.

Designating a security contact. A Customer designates one self-service, in the organisation’s billing and contact settings, as the Operational alerts email. That address receives fremverk’s operational and security notices — including the breach notification in §8.1 and the government-access notification in §11A.1 — and is the “designated security contact” those clauses refer to. Where it is not set, those notices fall back to the Customer’s billing contact-of-record, so no notice in this DPA depends on a channel the Customer has not provided. Invoice and billing correspondence is routed separately and is unaffected by this setting. fremverk keeps a record of all personal-data breaches as required by GDPR Art. 33(5) and makes it available to the Customer on request.

8.2 Data protection impact assessments (DPIAs) #

fremverk provides the Customer with information reasonably necessary to conduct a DPIA under GDPR Art. 35 where the Customer’s processing is subject to one. Standard information is available on the trust page and in this DPA; fremverk provides customer-specific detail on reasonable request.

8.3 Consultations with supervisory authorities #

fremverk cooperates, at the Customer’s reasonable request and expense, with the Customer’s prior consultations with supervisory authorities under GDPR Art. 36.

8.4 Roles in joint incident response #

Where a Personal Data Breach affects Customer Personal Data, the Customer is the Controller and is responsible for any GDPR Art. 33 notification to its supervisory authority and any GDPR Art. 34 communication to data subjects. fremverk supports the Customer’s Art. 33 / Art. 34 obligations under §§8.1–8.2.

8.5 Controller-side incidents (fremverk’s own controllership) #

Independent of the Customer’s controllership, fremverk acts as Controller for a narrow set of internal-operations processing activities documented in fremverk’s Record of Processing Activities (ROPA). Where a Personal Data Breach affects fremverk-as-Controller activities — including but not limited to (a) compromise of fremverk’s staff identity provider (idp.fremverk.com), (b) tampering with the WORM-anchor audit chain that protects integrity of fremverk’s internal audit log, (c) hijack or unauthorised use of an operator console session, or (d) confirmed compromise at a fremverk sub-processor that falls inside the Annex B scope but where fremverk is the affected Controller — fremverk operates its own Art. 33 / Art. 34 notification path:

• Notification to Datatilsynet within 72 hours of fremverk becoming aware of the breach, per GDPR Art. 33(1).
• Communication to data subjects without undue delay where the breach is likely to result in a high risk to the rights and freedoms of natural persons, per GDPR Art. 34(1).
• A record of every Controller-side breach is kept per GDPR Art. 33(5) and is available to the Customer on reasonable request to the extent the record relates to the Customer’s data or processing.

The single intake point for fremverk-as-Controller breach reports is compliance@frem.sh, monitored on the documented on-call rotation per SLA §9 (notification) + §10 (on-call coverage). Phase-1 ack windows are best-effort within the rotation’s coverage hours; funded 24/7 P1 coverage for the breach-mailbox specifically is on the Phase-2 roadmap (2027-Q1) tied to the Enterprise-on-Demand contractual primitive in SLA §10. The 72-hour Art. 33 clock starts at fremverk’s awareness per EDPB Guidelines 9/2022 — not at email receipt — so a delayed ack on the rotation does not by itself shorten the regulatory deadline. (Forwarding from the legacy alias compliance@fremverk.com is in place; both addresses route to the same on-call mailbox.) The internal triage, notification timeline, and Datatilsynet template are documented in fremverk’s Controller-side incident-response runbook, available to the Customer under NDA on request.

This §8.5 does not extend or modify fremverk’s processor-side obligations under §§8.1–8.4 in respect of Customer Personal Data, and does not create any direct contractual obligation owed by fremverk to data subjects of the Customer’s Controller-side processing.

9. Return and deletion of personal data #

On termination of the Service:

• Customer Personal Data is retained for 60 days from the termination date to enable the Customer to export it using the on-demand signed-export endpoints. This window aligns with the post-termination export window in Terms §16.5 and the suspension/termination retention sequence in AUP §11.
• After the 60-day export window, Customer Personal Data is hard-deleted from primary storage within 30 days.
• Live-tier backups (continuous WAL + daily snapshots — see Annex A.9) containing Customer Personal Data are retained for a further 30 days beyond primary deletion, then purged from backup stores through the normal backup-retention lifecycle. Total time from termination to live-tier backup-purge completion is up to 120 days.
• Disaster-recovery snapshots (Annex A.9) are sealed copies retained 13 months for object-store payloads and 30 days for repository content solely for catastrophic-recovery scope (e.g. recovering from a long-undetected corruption that predates the live-tier window). These snapshots are not used for any Customer-facing access path; if a DR restore brings Customer Personal Data back into primary storage after the 120-day purge, that data is re-processed through the same hard-delete procedure within 30 days of the restore.
• Immutable audit log entries linked to the Customer’s historical activity are retained in archive storage for up to 3 years for compliance and incident-reconstruction purposes; these entries are limited to event metadata and do not contain the Customer’s repository content.
• The accounting-records subset of the above (invoice + transaction records as defined in Danish Bogføringsloven §10) is retained for 5 years from the end of the accounting year. Customer-Personal-Data fields not required for accounting reconciliation (email, display-name, repository references) are pseudonymised at the 90-day primary-deletion mark — only the accounting-relevant columns survive into the 5-year archive.

On written request, fremverk provides written confirmation of deletion.

fremverk provides Customer Content in machine-readable formats: Git bundles for repository content (full history, all refs); JSON (newline-delimited) for issues, pull requests, comments, labels, milestones, releases, repository metadata, and audit logs; and machine-readable inventories for LFS objects and package-registry artifacts, listing each object’s identifier, size and path so it can be re-hydrated into another forge. LFS and package payloads are not included in the export archive — they remain retrievable from the Service for the retention period in §Data retention and deletion, and fremverk’s migration assistance under §Transition assistance covers their transfer. Schemas are published at docs.frem.sh/export-schema.

fremverk includes up to 8 hours of engineering assistance at no charge for transitions to a third-party forge or self-hosted Forgejo; additional time is billable at fremverk’s then-current professional-services rates.

On completion of deletion, fremverk provides the Customer with a certificate of destruction in writing within 14 days, identifying the data categories deleted, the storage tiers from which deletion occurred, and the date of deletion confirmation.

10. Sub-processors #

10.1 Authorisation #

The Customer authorises fremverk to engage the Sub-processors listed in the Annex B — Sub-processor Register to process Customer Personal Data for the purposes identified there.

10.2 Changes to Sub-processors #

fremverk may engage additional or replacement Sub-processors. fremverk notifies the Customer of any intended change at least 30 days in advance via two parallel channels: (a) a direct email to the Customer’s org billing contact-of-record (the primary billing-contact address registered for the org plus any additional billing-notification addresses the org has configured), and (b) a public posting to the trust page and the security mailing list at lists.frem.sh. The two channels are dispatched together as part of the same change-management workflow; the direct email is the contractual carrier and the mailing list is provided for convenience to non-billing addresses (security teams, compliance leads). Delivery follows the Notices procedure in Terms of Service §20, including the bounce-and-second-attempt fallback. Delivery of the direct email is recorded in fremverk’s audit log with the email-provider message id for each recipient.

Pre-launch carve-out — ENDED 2026-07-01 (recorded in DPA v1.17). During fremverk’s pre-launch period — defined as zero paying Customers AND zero Customers under contract for paid service, machine-readable via the pre_launch_paying_customers field in fremverk’s internal supplier register — the direct-email channel (a) was waived for Sub-processor changes and the public posting (b) carried the full notification, there being no contractual Customer recipients to notify by direct email. This carve-out lapsed at go-live on 2026-07-01 with the first paying Customer (pre_launch_paying_customers set false). As of DPA v1.17, every Annex B / Sub-processor change follows the full dual-channel notification in this §10.2 with no carve-out — direct email to the billing contact-of-record AND public posting, at least 30 days in advance. This paragraph is retained for audit continuity; the cutover is the record the clause previously anticipated.

Customer may, within 15 calendar days of fremverk’s notice, object in writing to a new Sub-processor on reasonable data-protection grounds. fremverk and Customer will work in good faith to find a solution within a further 15 calendar days. If no resolution is reached, Customer may, at its option:

(a) instruct fremverk not to use the new Sub-processor for Customer Personal Data, in which case fremverk may decline to deliver the affected portion of the Service and refund prepaid unused Fees attributable to that portion on a pro-rata basis; or

(b) terminate this DPA and the affected Service in the Terms of Service for cause without penalty, with pro-rata refund of any prepaid unused Fees, by written notice to fremverk no later than 15 calendar days after the end of the resolution period.

10.3 Emergency sub-processor onboarding #

Where a security or operational emergency requires fremverk to onboard a new sub-processor within a timeframe shorter than the §10.2 30-day notice (for example, replacement of a sub-processor that is itself the source of a security incident), fremverk may onboard the new sub-processor immediately, provided that fremverk: (a) notifies all Customers within 24 hours of the onboarding via the same dual-channel mechanism described in §10.2 (direct email to the billing contact-of-record AND public posting to the trust page and security mailing list); (b) describes the emergency justification; (c) confirms that the new sub-processor is bound by data-protection terms equivalent to those in this DPA; and (d) extends the §10.2 objection window to 30 days post-onboarding, during which the Customer retains the §10.2 termination right with pro-rata refund of prepaid unused Fees.

10.4 Sub-processor obligations #

fremverk imposes on each Sub-processor contractual data-protection obligations no less protective than those in this DPA. fremverk remains fully liable to the Customer for the acts and omissions of its Sub-processors.

11. International transfers #

11.1 Data residency #

fremverk processes Customer Personal Data and Customer Content in the regions and at the sub-processors set out below. fremverk shall not process Customer Personal Data outside these regions during the Term without the Customer’s prior written consent, except as required for the narrow transfers expressly disclosed in §11.2. This is a material term within the meaning of Terms of Service §16.4.

11.2 International transfers #

Customer Personal Data is processed exclusively inside the EU/EEA by entities with no US parent. Outbound transactional email is delivered through Lettermint B.V., a Dutch entity (Zwolle, KvK 80706290) processing the data on EU-only upstream infrastructure (OVHcloud SAS, France; UpCloud Ltd, Amsterdam datacenter). Inbound shared-mailbox correspondence addressed to operator addresses (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) is hosted by Heinlein Hosting GmbH (mailbox.org) in Berlin, Germany. No international transfer outside the EU/EEA occurs on any processing path and no Article 46 GDPR safeguard is required.

Note on T Cloud Public sub-services: T Cloud Public eu-de is a single legal entity (Deutsche Telekom AG / T-Systems International GmbH) operating multiple sub-services in scope of this DPA: CCE (Kubernetes), RDS (Postgres), DCS (Redis), SFS Turbo (NFS), OBS (object storage), DEW KMS, APIG (API gateway), FunctionGraph (serverless), SWR (container registry), CTS (audit), LTS (logs), CES (alarms), SMN (notifications), AOM (monitoring), Cloud DNS, NAT Gateway, ELB, EIP, ECS (compute under CCE). All sub-services run in the same eu-de legal/physical boundary and are covered by the single Deutsche Telekom AG row above; this list is informational.

11.3 CLOUD Act / US extraterritorial-law posture #

fremforge has no CLOUD Act exposure on any processing path. All Customer Personal Data — repositories, CI runs, audit logs, authentication metadata, billing records, payment-instrument data, accounting bilag, outbound transactional email, and inbound shared-mailbox correspondence — is processed inside the EU by entities with no US parent (Deutsche Telekom AG in Germany; Heinlein Hosting GmbH in Germany; Mollie B.V. in the Netherlands; Visma Dinero ApS in Denmark; Lettermint B.V. in the Netherlands; Bunny CDN d.o.o. in Slovenia at EU edge PoPs).

Card-network footnote (P1-LEG-11) — Mollie’s PCI-DSS-attested card-processing chain includes Visa Europe Services Inc. (UK branch — Brexit-era restructuring; the parent Visa Inc. is US-incorporated) and Mastercard Europe SA (Belgium). The “no US-parented” claim above applies to fremverk’s own sub-processor stack at the operating-company level; the card-network sub-sub-processors retain US ultimate parents under their network-rules contracts with the issuing banks. Customers preferring zero US-parent exposure on the payment path may pay by SEPA Direct Debit (Mollie’s SEPA path involves no card-network sub-sub-processor).

Outbound-email sub-processor — Outbound transactional email is delivered by Lettermint B.V. (Zwolle, NL — KvK 80706290), an EU-anchored Dutch entity running on OVHcloud SAS (France) and UpCloud Ltd (Finland-incorporated, Amsterdam datacenter). No US-parented upstream sits in the email path. Lettermint replaced Sendinblue SAS / Brevo on 2026-05-14; the superseded Brevo cap-table footnote (originally P1-LEG-12) is retained in the §Change log only for historical reference and does not apply to the live processing chain.

fremverk ApS is a Danish entity; neither fremverk nor any of its sub-processors is subject to the US CLOUD Act, Foreign Intelligence Surveillance Act, Executive Order 12333, or related US compelled-disclosure statutes (with the Visa-card-network chain caveat above). Legal requests for Customer Personal Data are handled per §11A.

Customer-configured AI vendors (BYOK) — For Customer-configured AI vendors enabled at the Customer’s choice, see Annex B §B.8 — those vendors are the Customer’s own processors and their jurisdictional exposure (including any US-extraterritorial-law exposure) is governed by the Customer’s own contract with that vendor, not by this DPA.

11A. Government and law-enforcement access #

11A.1 Where fremverk receives a binding legal demand from a government authority, court, or law-enforcement agency seeking disclosure of Customer Personal Data, fremverk applies the following process before disclosure:

(a) Reviews the request for legal validity, jurisdiction, and proportionality; (b) Challenges any request that is overbroad, lacks lawful basis, or conflicts with EU law (including Art. 48 GDPR for non-EU/EEA requests); (c) Notifies the affected Customer within 24 hours of receipt by email to the Customer’s designated security contact (or, where none has been designated, the Customer’s account-of-record administrator — the same addressing rule as §8.1), unless legally prohibited from doing so (in which case fremverk notifies as soon as the prohibition lapses); (d) Provides the Customer with reasonable opportunity to seek a protective order or otherwise contest the request.

11A.2 fremverk publishes an annual transparency report on www.frem.sh/trust/transparency/, summarising the number of government-access requests received, the jurisdictions of origin, the categories of data sought, and the disposition (complied / partially complied / rejected / pending), in aggregate form.

11A.3 For the avoidance of doubt: as of the Effective Date, fremverk has received zero government-access requests. The first transparency report covers the first full calendar year of operation.

12. Audit rights #

12.1 Demonstrable compliance #

fremverk makes the following available to the Customer:

• This DPA and the Annex A — Security Measures.
• The current Annex B — Sub-processor Register.
• The inherited certifications of T Cloud Public (ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, TISAX), Bunny CDN (ISO 27001, SOC 2 Type II), Heinlein Hosting / mailbox.org (ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen TR 03108), and Mollie (PCI-DSS Level 1), with links on the trust page. Lettermint B.V. certification evidence is pending vendor disclosure as of v1.9 and will be added once received.
• Its written responses to the Customer’s reasonable data-protection questionnaires.
• Summary reports of fremverk’s internal security testing programme; third-party penetration test reports, when commissioned, available under NDA on written request (the testing programme is summarised on the trust page).

fremverk does not hold standalone ISO 27001, SOC 2, or BSI C5 certifications as of the Effective Date. fremverk’s security posture rests on (i) the inherited certifications of the sub-processors listed in Annex B, (ii) the technical and organisational measures in Annex A, and (iii) the security-testing programme described at Annex A.12. fremverk commits to: (a) commencing a Stage 1 ISO 27001 audit within 18 months of the Effective Date and achieving certification within 24 months; (b) commencing a SOC 2 Type II readiness assessment within 24 months. Customers requiring direct certification before those milestones may contract under Enterprise-on-Demand with the certification-readiness milestones written into the Order Form.

On request and under NDA, fremverk provides the Customer with: the Information Security Policy (ISP), the Incident Response Plan (IRP), the Secure Software Development Lifecycle policy, the Third-Party Risk Management policy, the Business Continuity Plan, and the Access Control Policy.

12.2 On-site audits #

The Customer has the right to conduct an on-site audit of fremverk’s compliance with this DPA once per calendar year, on reasonable prior notice (at least 30 days), during business hours, at the Customer’s own cost, with reasonable limitations to protect confidentiality and fremverk’s operations. The Customer may not require access to other Customers’ data or to fremverk’s trade secrets. The parties may agree that an audit is satisfied by provision of existing third-party audit reports where available.

Where multiple Customers request on-site audits within a 60-day window, fremverk may organise a pooled audit under a common scope and a single auditor (modelled on the German pooled-audit pattern used by ECB-supervised institutions), with results shared under NDA. Where fremverk’s then-current ISO 27001, SOC 2 Type II, or BSI C5 attestation report is current and addresses the matter the Customer wishes to audit, the report is deemed to satisfy that part of the audit right. Where an audit reveals material non-compliance with this DPA, fremverk reimburses the Customer’s reasonable audit cost.

12.3 Additional audits #

Additional audits are permitted without the annual-frequency limitation following a personal-data breach affecting the Customer, or on a documented reasonable suspicion of a compliance failure.

13. Liability #

Liability under this DPA is governed by Terms of Service §14, including the data-liability carve-out at §14.5 that raises the cap to two times the annual Fees for claims arising from a breach of this DPA resulting in a personal-data breach.

Notwithstanding the cap in Terms of Service §14, neither party limits its liability under this DPA for: (a) administrative fines imposed by a supervisory authority under GDPR Art. 83 to the extent the fine is attributable to that party’s breach of this DPA; (b) compensation owed to a data subject under GDPR Art. 82; (c) gross negligence (grov uagtsomhed) or wilful misconduct (forsæt) under Danish law. Each party indemnifies the other for losses, fines, or settlements directly attributable to that party’s breach of this DPA, up to the limits set out above.

Where a GDPR Art. 83 administrative fine is imposed on the Customer and is attributable to fremverk’s documented breach of this DPA, fremverk indemnifies the Customer up to the higher of (a) the cap in Terms of Service §14.5 (two times annual Fees), or (b) the amount of the fine actually paid by the Customer to the supervisory authority. Where a Customer is found jointly liable with fremverk under Art. 82 for compensation to a data subject, fremverk’s contribution corresponds to its share of responsibility per Art. 82(4)–(5).

Where a third party submits a notice under the Digital Services Act Art. 16 against the Customer or its Users that is later determined to be fraudulent or made in bad faith (including but not limited to false statements of rights-holder identity, attestations later proven false, or competitor-driven harassment patterns), fremverk uses commercially reasonable efforts to recover its operational costs and the Customer’s documented losses from the complainant via the Straffeloven §163 path or civil action. fremverk reverses any restriction applied to Customer Content within 24 hours of confirming the bad-faith determination, and the impacted period is treated as in-scope for SLA credit calculation under SLA §7.

14. Order of precedence #

In case of conflict with the Terms of Service, this DPA prevails on matters of data protection. In case of conflict with any Standard Contractual Clauses incorporated by reference for international transfers, the Standard Contractual Clauses prevail on matters governed by them.

15. Governing law and jurisdiction #

This DPA is governed by Danish law. Disputes are subject to Danish courts, without prejudice to mandatory provisions of GDPR.

16. Signature #

This DPA takes effect on the same date as the Terms of Service between the parties and does not require a separate signature unless the Customer’s procurement process requires one; in that case fremverk executes a counterpart on request.

17. Regulated-customer support #

17.1 NIS2. Where the Customer is an essential or important entity under Directive (EU) 2022/2555 (NIS2) or its national transposition, fremverk supports the Customer’s incident-reporting obligations by providing relevant breach details (per §8) within timeframes consistent with the Customer’s 24-hour early warning and 72-hour notification deadlines.

17.2 DORA. Where the Customer is a financial entity under Regulation (EU) 2022/2554 (DORA), fremverk provides the ICT-third-party-service register fields required under DORA Art. 28 and Art. 30 (service description, location, certifications, sub-processor chain) on request, and supports the Customer’s exit-strategy obligations through the standard data-export mechanism in §9.

17.3 BYOK / Customer-Held Keys — encryption-at-rest CMK custody. Customer-held cryptographic key material (BYOK / HYOK) for encryption-at-rest of the platform’s data stores (RDS for PostgreSQL, OBS object storage, EVS, SFS Turbo) is not available at launch. A customer-held-CMK option is on the Phase 2 roadmap for the Enterprise-on-Demand tier. The current cryptographic-protection model is set out in Annex A — Security Measures (fremverk-held CMKs in T Cloud Public DEW KMS, annual auto-rotation). Note on terminology: the term “BYOK” is also used in Annex B §B.8 to describe the Customer’s own commercial-API key for a Customer-configured AI vendor — that is a different concept (a third-party API credential the Customer pastes into the fremforge admin UI to authenticate Customer-chosen AI providers), and not the encryption-at-rest CMK custody covered in this §17.3. The two uses are kept distinct in this DPA; where ambiguity could matter, Annex B §B.8 prefers the longer form “Customer-configured AI vendor key”.

Annex A — Security Measures #

fremverk implements the following technical and organisational measures. This list is indicative and non-exhaustive; fremverk updates the measures over time to maintain a level of security appropriate to the risk, notifying the Customer via the trust page of material changes.

A.1 Physical security #

• Hosting in T Cloud Public eu-de data centres in Biere and Magdeburg, Germany, operated by Deutsche Telekom under ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, and TISAX certifications. Physical access controls, video surveillance, redundant power and cooling, and fire suppression are T Cloud Public’s responsibility as sub-processor.
• Bunny CDN edge nodes in EU points of presence only, operated by Bunny CDN d.o.o. under ISO 27001 (cert year 2025) and SOC 2 Type II (cert year 2023). Currency of cert evidence is verified at each quarterly supplier review (see fremverk’s internal supplier register, §4 Quarterly review — next review 2026-08-13).

A.2 Network and edge security #

• TLS 1.2+ on every HTTP surface. HSTS enabled. Modern cipher suites only.
• DDoS protection at the edge via Bunny Shield (Basic tier) on every public HTTP(S) surface — Forgejo UI, Git over HTTPS, the API, the package registry, and the marketing, documentation, status and trust sites. Configured in Block mode, and combined with per-IP rate-limiting edge rules that apply a tighter cap to anonymous traffic than to authenticated requests.
• The Web Application Firewall available in Bunny Shield Advanced is deliberately NOT enabled on fremforge surfaces. Pre-launch testing produced an unacceptable false-positive rate: the OWASP Core Rule Set flags ordinary Git protocol bodies, Forgejo’s asset and diff URLs, raw-blob paths carrying hex identifiers, signed-URL query strings, and every form-body surface on the API (signup with VAT number, proof-of-work captcha, billing setup, webhook receivers). Enabling it path-by-path left almost nothing actually protected while breaking legitimate Git operations, which is a worse outcome for the Customer than the residual edge-layer risk. The controls fremverk relies on instead are at the application layer and are listed in this Annex: Forgejo’s session and CSRF protection with parameterised SQL, proof-of-work and HMAC signed tokens on public write surfaces, OIDC for operator access, the per-IP and per-organisation rate limits above, and the SSRF hardening below. This posture is published on the trust page, and is re-reviewed at each quarterly operational review.
• T Cloud Public Anti-DDoS protection on the SSH endpoint at ssh.frem.sh:443 (port 443 mapped to in-cluster SSHd; port 22 is not publicly exposed on the apex domain).
• Per-organisation rate limiting at the T Cloud Public APIG layer (per-API-group throttling policies) keyed on the URL path prefix; for token-authenticated callers, additionally enforced at the application layer via the in-monolith rate-limit middleware backed by DCS Redis.
• Layered SSRF hardening on every workload that handles Customer-supplied URLs (webhook delivery, repo mirroring, OIDC discovery, avatar fetches, markdown image proxy) via three enforcing layers: (1) per-pod VPC Security Group egress allowlist under T Cloud Public’s Cloud Native Network 2.0 model — each pod’s ENI is attached to a Security Group that permits only the workload’s required egress (intra-VPC ANY, HTTPS:443 to the public internet, NTP, DNS forward, Lettermint SMTP) and denies everything else at the hypervisor layer; (2) outbound-proxy CONNECT tunnel through which all Customer-supplied-URL HTTP requests are routed (Forgejo [proxy] config, monolith api OUTBOUND_PROXY_URL env, FunctionGraph jobs via the same proxy); (3) app-layer SSRF guard (an application-level SSRF guard plus the proxy’s TCP-connect-layer filter) applying the deny set covering RFC1918, link-local, IPv6 ULA, loopback, multicast, T Cloud Public metadata endpoints, and a one-shot DNS-resolve-then-dial-by-IP pattern to prevent TOCTOU/rebinding.

A.3 Access control #

• Human access to production is federated from fremverk’s self-hosted Authentik IdP at idp.fremverk.com, with policy-flow MFA enforcement (TOTP / WebAuthn) and group-claim role mapping. Authentik runs in fremverk’s T Cloud Public platform-identity-prd enterprise project (Germany, EU). fremverk does not use any external (US-parented) identity provider for operator authentication. Effective from operator-console activation: the Authentik tenant infrastructure was deployed 2026-05-06; binding of the operator-console (/_admin/*) and customer-side OIDC/SAML federation paths to Authentik becomes effective for an individual tenant only once OPERATOR_OIDC_* runtime secrets are populated in the api-runtime Secret and the relevant tenant federation is bound.
• Interactive Forgejo site-admin access is break-glass only, through a single local account (fremforge-admin) vaulted in T Cloud Public DEW CSMS with mandatory MFA; every interactive login pages on-call and writes to the platform-security audit stream.
• Four service accounts also hold the site-admin role and use it in normal operation, and this Annex previously denied that. They are fremforge-monolith-bot (control-plane provisioning), fremforge-runner-bot (CI job lifecycle), fremforge-bot (platform automation) and fremforge-scan-bot (fleet-wide security scanning). Each authenticates with a scoped API token rather than interactively, so the MFA and on-call-paging controls above apply to the break-glass account and not to these; their activity is recorded in the audit log. The site-admin role is used because these functions act across every tenant — creating organisations, reading any repository to scan it, managing runner registration — which Forgejo’s permission model cannot express below site-admin. fremverk treats this as an accepted risk rather than a control: the mitigation is credential scoping at the point of use (each token is minted per function and the scanner’s credential is scoped per owner so a scan of one tenant cannot read as another), not a reduction of the role itself.
• Control-plane functions otherwise use scoped, non-admin service accounts.
• Customer-side access is authenticated via OIDC/SAML SSO to the Customer’s identity provider, with per-organisation session binding and scoped API tokens as documented in the OIDC SSO and SAML 2.0 SSO pages.
• Magic-link single-use enforcement. Where email-delivered links carry an authentication or one-time consumption purpose (welcome-email initial-password-claim, billing-setup callback, undo-cancellation, signup-confirmation), the link payload is HMAC-signed against BILLING_LINK_SIGNING_SECRET with a 48-hour TTL and atomically consumed via Redis GETDEL on the encrypted-state-bag key. First click wins; second click sees null and returns “already consumed”. Implementation: the password-claim service’s single-use consume() path together with the signed-token service. Fail-closed on Redis-unreachable: the route refuses rather than letting a non-atomic check through. The Lettermint-side delivery is the transport for these links; the single-use claim is enforced inside fremverk’s api against fremverk’s own DCS Redis, NOT inside Lettermint.

A.4 Encryption #

• Encryption in transit: TLS 1.2+ on all HTTP surfaces; SSH at ssh.frem.sh:443 (port 443 mapped to in-cluster SSHd; port 22 is not publicly exposed on the apex domain).
• Encryption at rest: T Cloud Public RDS for PostgreSQL, OBS object storage, EVS block storage, and SFS Turbo NFS all encrypted with fremverk-managed Customer Master Keys (CMKs) in T Cloud Public DEW KMS (separate per-component CMKs, one per data domain, with annual auto-rotation enabled). Backup archives on OBS WORM encrypted with the same DEW-managed keys (CBR vault SSE inheritance, see Annex A.9). The CMKs are held by fremverk in its T Cloud Public account; the Customer does not hold key material — see §17.3 for the customer-held-key roadmap. Earlier wording “customer-managed” reflected OTC terminology where “customer” refers to fremverk-as-T-Cloud-tenant; clarified to fremverk-managed per audit P0-44.
• Encryption at rest — DCS Redis caveat: T Cloud Public DCS Redis does not currently expose a tenant-controlled KMS attach point on the OTC platform; data at rest is encrypted with provider-managed DEW keys rather than the per-component customer-managed CMK pattern used elsewhere. The full DCS contents inventory is in the table below; all items are TTL-bounded (≤ 7 days) and non-durable. fremverk will migrate DCS to customer-managed-KMS the moment T Cloud Public exposes the attach point. Disclosed transparently in line with §11.2 and clarified in line with audit P2-15.

Parallel transient PII in RDS PostgreSQL — disclosed here for completeness because the data shape carries the same ≤24h ephemeral envelope as the DCS items above but lives in the transactional database. Encrypted at rest with fremverk-managed CMK (the same database-encryption DEW key used for the main RDS instance, not the DCS provider-managed key caveat above).

Explicitly NOT in DCS or in signup_pending_confirmations: payment-card primary account numbers (PANs), government identifiers, repository content, audit-chain hashes, customer-managed CMK key material.

Customer-supplied presentation assets — public-docs wiki custom_css. Each tenant may, per repository, store an 8 KB custom_css textarea on public_docs_settings for the anonymous-read wiki at frem.sh/<org>/<repo>/wiki[/...]. Storage is durable RDS PostgreSQL encrypted with the same database-encryption DEW CMK. The CSS is customer-controlled, persisted, and served verbatim to anonymous internet visitors when the per-repo opt-in is set. Write-time and render-time guards reject any < byte (preventing <script>/<style> element injection), but CSS-level data-exfiltration vectors (e.g. background-image: url(https://tracker.example/...)) are NOT blocked — the Customer is responsible for the privacy implications of any external URLs they reference. See AUP §3.6A and Privacy Notice §1 for the corresponding customer-side framing.

• CI runner secrets: injected into the per-job runner virtual machine as environment variables only for the lifetime of the job, never persisted to shared volumes or ConfigMaps. The runner’s own registration credential is ephemeral and per-runner: Forgejo deletes the runner identity when its task completes, so a credential recovered from a terminated VM authenticates nothing.
• Signed commits — default path is SSH-key signing (git config gpg.format=ssh, with the per-org allowedSignersFile derived from members’ registered SSH keys). No third-party sub-processor, no transparency-log dependency, no US jurisdiction transit. Forgejo verifies SSH-signed commits natively. The classical GPG signing path is also supported. Sigstore-style keyless commit signing is available via fremverk’s self-hosted Sigstore stack on T Cloud Public eu-de (Fulcio + TSA; no Rekor transparency-log fan-out). Endpoints sign.frem.sh and tsa.frem.sh. No request transits the public Linux Foundation Sigstore instance. Customers opt in per-tenant via auth-policy require_oidc_signed_commits; the Fulcio signing trust anchor is rooted in customer-configured OIDC issuers (one per tenant, set at Authentication policy → OIDC issuers for keyless signing). Customer setup guide at docs.frem.sh/get-started/keyless-commit-signing/; operator runbook at docs.frem.sh/admin/sigstore-pki/.

A.5 Isolation and multi-tenancy #

• Logical isolation per Forgejo organisation, enforced by Forgejo’s own access-control layer: a repository is readable only by the organisation’s members and its explicit collaborators, and every API and Git path resolves permission through that layer on each request.
• fremverk re-verifies this isolation on an hourly schedule. An automated probe (tenant-acl-isolation-probe, hourly) asks Forgejo directly, as an unauthenticated caller, whether any Customer organisation or its repository list can be read. A positive result raises a Critical alarm to on-call. The probe additionally asserts on every run that it can reach Forgejo at all, and reports its result as UNKNOWN rather than as a pass if it cannot — so a probe that has silently stopped working raises its own alarm instead of reporting clean. First clean sweep observed 2026-08-06: 8 organisations checked, 0 readable.
  • What this verifies, and what it does not. The probe covers anonymous readability against Forgejo’s permission layer, which is the mechanism this Annex relies on. It does not verify authenticated cross-tenant access (a member of one Customer organisation attempting to read another), and it does not test the public CDN edge independently of Forgejo. Those surfaces are governed by the same permission model but are not separately probed today, and this Annex will not claim they are until they are.
  • History, retained deliberately. Until 2026-08-05 this Annex stated that isolation was “enforced by automated nightly ACL smoke tests via FunctionGraph”. No such test existed and none ever had; DPA 1.28 corrected the Annex to say so plainly rather than quietly substituting a replacement. The probe described above was then built, and this clause was restored only after it was observed completing a real sweep — not when it was written, deployed, or scheduled. A reader who saw the 1.28 wording is entitled to know which of those happened.
• Hosted CI runners execute on ephemeral T Cloud Public Elastic Cloud Server (ECS) virtual machines, booted per job from a fremverk-built machine image and terminated when their work completes. A virtual machine is a full hardware-virtualisation boundary — a stronger isolation primitive than any container runtime, shared-kernel or secure — and no runner shares a kernel with another tenant, with the platform, or with the CCE cluster that hosts the control plane.
• Grouping is per commit, not per job. All jobs of a single Forgejo Actions run over the same commit in the same repository may execute on the same virtual machine, which is then destroyed. Jobs from a different commit, a different repository, or a different tenant always get a different machine, so the cross-tenant boundary is one VM per tenant workload at all times. fremverk has assessed and accepted that a later job of a commit may reuse the machine an earlier job of the same commit ran on: it is the same reviewed code either way, and the alternative is a cold-boot latency penalty on every step of a pipeline. This grouping is equivalent to the VM-per-job model of the major hosted-CI providers for cross-tenant purposes, and marginally more permissive within a single pipeline.
• Runner machines start clean from the image on every boot, hold no persistent storage, mount no Kubernetes service-account token (they are not cluster members), and carry a per-instance VPC Security Group restricting egress to the outbound proxy and the runner’s required Git and container-registry destinations only. The Security Group denies the shared CCE cluster, the T Cloud Public metadata endpoints, and other runner machines at the hypervisor layer, independently of anything running inside the machine.
• The Customer’s workflow has administrative rights inside its own runner machine. A CI job must be able to install packages, build container images and run privileged tooling, so it is not confined within the machine — this is the same posture as the major hosted-CI providers, where a workflow likewise has root or sudo on the runner it is given. The boundary that protects other tenants and the platform is therefore the machine itself plus the Security Group, not in-guest confinement, and it is the boundary this annex commits to. Earlier versions of this annex described in-guest confinement (non-root, capabilities dropped, read-only root filesystem) carried over from a container-based design that was never the production path; corrected here to describe the control that actually exists.
• Per-tenant audit-log streams in T Cloud Public LTS tagged tenant_id; tenant admins see only their tenant’s entries; immutable archive to OBS WORM.

A.6 Pre-receive and supply chain controls #

• Pre-receive secret scanning on every push for high-confidence patterns (SSH keys, PEM private keys, AWS AKIA*, T Cloud Public AK/SK, GitHub ghp_*/ghs_*, Slack xoxb-*, and similar prefixed/entropy-signed tokens). This platform-floor control cannot be disabled by any tenant administrator or repo owner.
• Push protection — rejection of pushes introducing high-severity secrets, with an override path recorded in the audit log.
• Dependency scanning on pull requests via Trivy/osv-scanner; configurable per-org merge-block threshold on CRITICAL CVEs.
• Signed commits via SSH-key signing (default) or GPG, with verification surfaced per repo in the fremforge admin UI.
• SLSA provenance for build artifacts produced on hosted runners; attestations stored alongside artifacts and verifiable via slsa-verifier.
• Build-time tooling resolved through fremverk-controlled mirrors. Forgejo Actions, container base images and third-party CI tooling used by fremforge’s own build pipeline are mirrored from upstream into fremverk-controlled Forgejo organisations on frem.sh (one organisation per upstream namespace — actions, docker, pnpm, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny, forgejo) and into a fremverk-controlled SWR registry (fremforge-prd/cache-*). Git sources are mirrored by Forgejo’s native pull-mirror on an 8-hour interval; OCI images by the swr-mirror CronJob every 6 hours. Both are operationally independent of any single CI run, so a transient upstream outage does not affect builds. Container images pushed to SWR are scanned for CVEs (Trivy, fail-on-CRITICAL/HIGH) before push.
  • This is an availability control, not an integrity control. A pull-mirror copies whatever the upstream ref points at, so a repointed tag would propagate. Where fremverk builds from an upstream ref, the ref is additionally pinned by commit or content hash and verified after fetch.
• Scope — the runner-image build reaches upstream directly, by design. The preceding bullet describes how the build pipeline resolves its tooling. It is not a claim that no fremverk build process contacts a non-EU host, and the previous wording of this Annex — which said runners “pull from these mirrors only” and that “no fremforge build path resolves DNS or fetches code from github.com … or any other US-jurisdiction host” — overstated it. Building the runner machine images (runner-base, runner-toolchain) downloads language toolchains and CLI tooling from their origins, including nodejs.org, go.dev, api.adoptium.net, sh.rustup.rs, services.gradle.org, getcomposer.org, archive.apache.org, GitHub release assets, dl.google.com, awscli.amazonaws.com, and the packages.sury.org / packages.microsoft.com apt repositories. Several are US-jurisdiction hosts. This is a deliberate exception with three properties that bound it: it runs only in fremverk’s operator/CI build context and is not a runtime path, so no Customer data is present in the process; every downloaded artefact is pinned by SHA-256 and verified after download, with the build failing on mismatch (and signature verification where upstream publishes one); and egress traverses the strict outbound proxy allowlist. The resulting image is published to SWR, and that SWR image is what production runners consume.
• Scope clarification — build path vs operator-internal egress. The “no US-host resolution” commitment above covers the Customer-data path: the api runtime that processes tenant requests, stores tenant data, and emits tenant-bound responses never resolves or fetches from US-jurisdiction hosts. Operator-internal flows that do not touch Customer data — the mirror-sync CronJob’s pull from upstream registries (github.com, gcr.io, docker.io), Forgejo’s own pull-mirror job, the runner-base / runner-toolchain image builds described above, CI runners pulling cached base images, and the operator-AI workbench (.anthropic.com, .claude.com, .openai.com, .mistral.ai) used for fremverk-internal engineering decisions — may resolve to US-jurisdiction hosts via the strict outbound-proxy allowlist. These flows are documented sub-processors where applicable (see Annex B) and operator-internal entries where not; in no case does Customer data pass through them. P1-22 bughunt 2026-06-01: this paragraph added to distinguish the two layers, after a workshop reading the previous paragraph mistakenly inferred runtime egress was also US-host-free.

A.7 Audit logging and integrity #

• Forgejo-native events and middleware-emitted events both write through a shared audit sink with tamper-evident hash chaining.
• The running hash is anchored to OBS WORM storage every 2 minutes; the chain is verified hourly by an in-cluster integrity check; chain breaks page on-call.
• Audit-log retention — two-tier model:
  • Hot (queryable) tier — security-relevant audit events (authentication, authorisation, admin actions): retention is a per-tenant policy with presets of 90 / 180 / 365 / 730 days. The Customer tenant admin sets the tier at Authentication policy → Audit log retention. Defaults: 90 days for the standard plan; 365 days for Enterprise-on-Demand, the operator-provisioned custom trial, and internal plans. After the per-tenant cutoff, the audit-payload-reaper redacts actor and fields_json to null while preserving the SHA-256 chain hashes. The two tiers are logically separate — the hot-tier is queryable PII (re-identification risk increases with retention), the WORM tier below is integrity hashes (no PII, kept full-term).
  • Hot (queryable) tier — operational logs (HTTP, runner, infrastructure): 30 days hot, not customer-configurable.
  • Immutable WORM archive (both tiers): 3 years (1095 days) in T Cloud Public OBS Object Lock compliance-mode; hash-chain anchored every 2 minutes; payload-bearing rows redacted at hot-tier cutoff but anchor chain is unbroken.
• WORM retention configurability (P2-DR-17). The 3-year (1095-day) WORM retention floor is the published default; the OBS Object Lock policy supports per-bucket retention values up to 9.5 years (3500 days). Customers under Enterprise-on-Demand may request a longer WORM retention window for a specific tenant — typically driven by sectoral regulation (financial services, public-sector contracts) — under a separate written agreement. Shorter-than-3-year WORM retention is not offered: WORM is a unilateral fremverk integrity commitment for the cryptographic chain, and reducing it would break the chain-of-custody promise this annex makes to all Customers. Note: the hot-tier customer-tunable retention above is logically separate from the WORM tier — a Customer choosing a shorter hot-tier retention does not affect the 3-year WORM commitment, which continues to hold the hash chain for the full window.
• SLA floor by plan. Customers on enterprise plans contractually receive at least 365 days of queryable retention under the SLA; a Customer admin may set the hot-tier below the plan baseline via the admin UI (yes-by-design — the UI does not enforce the contractual floor), but doing so disclaims the contractual queryability commitment for the affected period. The standard-plan SLA floor is 90 days queryable.
• Agent actions are recorded with actor=agent:<agent_id>, on_behalf_of=<user_id> — distinguishable in the audit stream and in admin-UI filters from human actions.

fremverk verifies the integrity of the audit chain through an hourly automated check that backward-walks the canonical lineage from the most recent WORM-anchored hash; mismatches page on-call. The verifier tolerates orphan anchor objects produced by bootstrap-time test runs or ungracefully-aborted anchor jobs — these are reported as warnings and do not page, since they sit outside the canonical lineage and therefore cannot affect chain integrity. The implementation, hash algorithm, integrity-check job, and orphan-tolerance contract are documented in fremverk’s Information Security Policy, available to Customers under NDA. Where the 2-minute anchoring cadence cannot be met for transient operational reasons (e.g., OBS region maintenance), fremverk records the gap in the chain metadata and documents the gap in the next status-page incident report.

A.8 Security patching #

The published security-patching SLA at www.frem.sh/trust/#security-patching is part of this annex, and the targets below are identical to it. These targets are contractual and in force now. The phased model previously set out here — weaker “Phase 1” targets under commercially reasonable efforts until 2027-Q1 — is withdrawn as of 2026-08-05: it stated commitments materially weaker than the ones fremverk was already publishing on its trust page, which a Customer reads first and which this annex incorporates by reference. Rather than narrow the published promise, fremverk has adopted it. Maximum time to patch, measured from the upstream fixed release or advisory publication (whichever is later):

Out-of-band emergency releases are permitted and expected — the weekly maintenance window is a ceiling, not a floor. Security patches are not deferred to honour a tenant maintenance window.

A.9 Backup and disaster recovery #

A.9 Backup and disaster recovery.

• Recovery point objective (RPO):
  • In-region recovery (single AZ failure or in-region data-corruption event): ≤ 15 minutes for repository content, audit logs, and authentication state — backed by continuous WAL replication on RDS plus asynchronous cross-AZ replication on object storage.
  • Cross-region catastrophic recovery (full T Cloud Public eu-de region loss): ≤ 7 days for repository content (Forgejo on SFS Turbo) and object-store payloads (OBS), backed by CBR backups replicated to eu-nl (for SFS Turbo) and a daily copy-if-absent replication sweep to eu-nl, verified per-object nightly (for OBS). Both mechanisms run considerably ahead of the ≤ 7 day bound: SFS Turbo backups are taken approximately every six hours and replicated continuously, and the OBS sweep runs daily, giving observed recovery points of hours rather than days. The ≤ 15 minute in-region commitment does NOT apply to this scenario because eu-de WAL state is unreachable during a regional outage. RDS PostgreSQL (tenant metadata, billing ledger, audit chain head-pointer) has no cross-region commitment at this DPA version — the T Cloud Public CBR service does not yet support cross-region replication for RDS-typed vaults (roadmap, not GA). In a eu-de total-loss scenario before this gap closes, RDS state would be reconstructed from authoritative upstreams (Forgejo as the customer-code system of record; Mollie / Dinero for billing and accounting state; the cross-region-replicated audit chain in OBS LTS-WORM for tamper-evident history). Cross-region RDS replication is on the post-launch roadmap and will be added to this Annex when shipped. Customers transacting through fremforge prior to that change accept this scoped cross-region RPO bound as documented here. Continuous WAL replication to a cross-region read replica is on the same roadmap.
• Recovery time objective (RTO): ≤ 4 hours for region-internal incidents (single AZ failure within eu-de); ≤ 24 hours for full T Cloud Public eu-de region failure (cold restore to alternate EU region from cross-region OBS replica).
• Disaster-recovery procedures are tested at least quarterly and on material change to the recovery design (RTO target, RPO commitment, sub-processor change on the recovery path). Testing is performed by scheduled automated drills against a synthetic tenant, which in practice run more frequently than the quarterly floor: the RDS restore drill monthly, the WORM archive read-back drill weekly, and backup-integrity verification monthly, alongside daily backup-presence verification. Each run is recorded in fremverk’s platform log stream and a failed run raises an alarm to on-call.
  • What fremverk does not produce. Until 2026-08-05 this Annex stated that each test was “documented as a runbook execution + post-drill report” with an “executive summary available to Customers under NDA on written request”. No such report has ever been produced. The directory intended to hold them contains no report, none appears anywhere in fremverk’s repositories, and none is present in version-control history. That commitment is therefore withdrawn rather than left standing: fremverk relies on the automated drill runs and their alarms as the evidence that the recovery path works, and does not currently produce a separate signed post-drill document or offer an executive summary of one. Customers requiring an attested restore report should raise it in the Order Form, where it can be agreed as a specific deliverable. The drills themselves were and are real — what did not exist was the document describing them.
• Daily automated backup-presence verification. Independent of the annual restore drill, a daily CronJob asserts that the previous night’s RDS automatic snapshot exists, completed successfully, finished within the last 25 hours, and is non-zero in size. A failed assertion pages on-call via the same SMN topic that production alarms use. The verifier closes the silent-fail mode where the snapshot job could stop running unobserved between annual drills; it does not replace the annual restore drill, which remains the only test that validates restorability end-to-end.
• Backups: two tiers, distinct scope and access paths:
  • Live tier: continuous WAL (30 days) + daily snapshots (90 days). Used for routine point-in-time recovery and post-termination backup-purge per §9 (120-day total purge timeline). RDS PostgreSQL daily snapshots are in-region (T Cloud Public eu-de); cross-region replication for RDS is on the post-launch roadmap pending the T Cloud Public Cloud Backup & Recovery service’s general availability for RDS resources (the service is published but not yet enabled for RDS object types at the T Cloud Public tenancy boundary — the daily snapshots themselves are unaffected by this gap). Code, repository, and object-store backups (SFS Turbo + OBS) are already replicated cross-region to T Cloud Public eu-nl per Annex A.9 below.
  • Disaster-recovery tier: 13 months for object-store payloads, 30 days for repository content (see the per-surface note below). Sealed copies for catastrophic-recovery scope only — no automated Customer-facing read path, no support-team query path. Retention differs by surface, and the difference is stated rather than averaged: object-store payloads (OBS) carry 13-month (395-day) cross-region retention to eu-nl, while repository content (Forgejo on SFS Turbo) carries 30 days — the CBR vault policy keeps the last 30 daily backups, locally and cross-region. Earlier versions of this Annex stated 13 months for both; that was correct for OBS and wrong for SFS Turbo (see change log 1.24). Tenant-initiated audit-log exports are the one object-store payload excluded from this DR tier: they are not replicated cross-region at all, and live 7 days in-region in the signed download bucket before purge (see the export row in §Retention). Excluded deliberately — a signed, tenant-downloadable export is reproducible on demand from the audit log itself, so a sealed 13-month second copy of it would extend the life of Customer data well beyond the window the Customer was told about, for no recovery benefit. Corrected in DPA 1.26 / privacy 1.13: the replication toggle was set false on 2026-08-04 and the two Annex sentences still said every object-store payload carried the 13-month copy. RDS PostgreSQL is currently covered by the 90-day in-region live tier only; the cross-region 13-month DR tier for RDS will ship once T Cloud Public enables CBR for RDS (roadmap, not GA at the date of this DPA version). Restored data is processed through the §9 hard-delete procedure if a DR restore brings post-termination Customer Personal Data back into primary storage. Both tiers are encrypted with fremverk-managed DEW Customer Master Keys — the RDS snapshot tiers inherit the source instance’s per-component CMK, and the object-store archives carry their own per-bucket CMKs — consistent with Annex A.4. Earlier versions of this line said “T Cloud Public-managed keys”, which contradicted A.4 and understated the control; corrected here. Restore-readiness verified monthly.
• Customer-data-restore SLA (P1-DR-12): Customers may request a tenant-scoped restore from the live tier — for example, after an accidental tenant-side hard delete that erased a load-bearing repository or admin-policy state. fremverk’s commitment is same-business-day acknowledgement (response from compliance@frem.sh within 8 working hours) plus ≤ 48 hours from request to restored read-only snapshot of the requested timestamp for live-tier restores. Restore from the DR tier (monthly snapshots, > 90 days old) takes longer because the cold-storage retrieval path is operator-driven; the commitment is ≤ 5 business days with status updates every 24h. Both targets are subject to §A.9’s overarching RTO ceilings during a regional incident. Restore requests are logged in the audit chain (tenant.restore_request); tenant-side restore endpoints in the admin UI are a Phase 1.5 add-on (today’s path is operator-driven via data-corruption-recovery.md (operator runbook, available under NDA via compliance@frem.sh)).

A.10 Personnel #

• fremverk personnel with access to production are vetted (reference checks, right-to-work verification) under Danish employment law.
• Personnel maintain continuous professional currency in security and data protection across a defined curriculum. fremverk attests to that currency at organisation level at least annually, on a dated record signed by fremverk’s chief executive. The curriculum covers: GDPR Articles 5, 6, 25, 28, 32, 33, 34, 35, and 44–49; Danish bookkeeping-law obligations (Bogføringsloven §10); the fremverk security incident-response playbook (including escalation paths and the 72-hour Art 33 clock); secure-coding fundamentals (OWASP Top 10, supply-chain hygiene); operator-tooling least-privilege practice; and AI-specific literacy under Article 4 of the AI Act. The curriculum itself is reviewed at least annually against the current threat landscape and regulatory guidance (Datatilsynet, ENISA, EU EDPB), and the review is recorded with its date.
• Training records are retained for five (5) years alongside the bookkeeping bilag (matching the Bogføringsloven §10 floor; one retention number across the org), held in fremverk’s internal governance repository, which is hosted on fremverk’s own EU-resident T Cloud Public infrastructure, encrypted at rest, and access-scoped to fremverk personnel. Each attestation is recorded with: the curriculum areas covered, the curriculum version, the attestation date, the signatory, and the next-review-due date. Individual personnel may additionally record a personal attestation, carrying the same fields plus an assessment score where one applies. fremverk does not commit to holding a separate per-person attestation for every member of personnel — the organisation-level attestation is the instrument, and this is a deliberate change from earlier versions of this Annex (see change log 1.23). Every change is version-controlled and attributable. Records are made available to a Customer auditor under NDA on reasonable request per §12 Audits.
• Confidentiality undertakings are in every employment and contractor agreement and survive termination.

A.11 Incident response #

• Pre-written runbooks cover Forgejo down, RDS failover, SSH unavailable, runaway tenant (single-org DDoS), data corruption, hosted-runner capacity exhaustion, fremforge api (billing-engine) outage, CCE control-plane incident, DCS Redis unavailable, OBS regional incident, SFS Turbo incident, runner-fleet regional incident, Bunny CDN outage, T Cloud Public DNS outage, Mollie outage, bulk secret exposure in audit log, suspected runner base image compromise, and compromised tenant.
• Detection via T Cloud Public CES metrics, AOM application observability, LTS log-based alerts, and Grafana dashboards. Alerts route through T Cloud Public SMN to SMS/push for on-call staff.
• Post-incident reviews are conducted for any Priority 1 incident; post-mortems for incidents affecting Customer data or availability are published on the trust page within 14 days.

A.12 Testing #

• Internal security testing covering tenant isolation, webhook SSRF, runner machine isolation, authentication flows, push-protection override, rate-limit and abuse controls is a launch-blocker. Results are summarised and made available to the Customer on request under the confidentiality terms of this DPA.
• Third-party penetration test reports, when commissioned, are made available to Customers under NDA on written request. fremverk does not commit to a fixed external-pentest cadence at the standard tier; Enterprise-on-Demand contracts may agree to a specific testing cadence in the Order Form.
• A disaster-recovery drill (PITR restore, SFS snapshot restore, data-integrity verify) is executed at least annually and on material change to the recovery design, with a written report archived.

A.13 Change management #

• Every production change is proposed as a pull request against the component’s repository and cannot reach production without passing the required checks on that pull request: build and full automated test suite, static analysis, dependency vulnerability scan, container-image vulnerability scan, licence-policy scan, and signature verification. Branch protection enforces the checks and code-owner review; a change that fails any of them is not mergeable. Database migrations additionally pass a schema-drift gate that fails when the declared schema and the migration history disagree.
• Risky changes are staged behind feature flags and reversible migrations rather than a separate pre-production soak. Earlier versions of this annex described a fremforge-tst pre-production environment with a 24-hour soak; that environment does not exist and this annex should not have described it — the control chain above is what has gated production changes throughout, and it is what fremverk commits to. Security patches may bypass the scheduled maintenance window under documented incident protocol, but not the required checks.
• Maintenance window: Tuesday 02:00–04:00 UTC weekly, used only when needed, announced 48 hours in advance.
• Every production change is applied via OpenTofu with state in T Cloud Public OBS; every change is reviewed in Git before apply.

A.14 Tenant-visible controls #

• On-demand signed export of org data (repos, issues, PRs, audit log, LFS manifest) as a self-service action in the fremforge admin UI or via the public REST API.
• Per-organisation audit-log view and export.
• SSO enforcement with break-glass account pre-designation for IdP-outage scenarios.
• Optional public-repo support with AUP enforcement for abuse prevention.

Annex B — Sub-processor Register #

As of the date of this DPA, fremverk engages the following Sub-processors to process Customer Personal Data.

For the avoidance of doubt: Customer-chosen identity providers (where the Customer federates fremforge to its own Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik, or other tenant via OIDC or SAML) are the Customer’s processors, not sub-processors of fremverk under this DPA. fremverk does not contract with those providers on the Customer’s behalf, and they do not appear in the register below.

Bunny CDN’s commercial agreement does not by default restrict global PoPs; the EU-only routing is configured at the pull-zone level and verified by the post-deploy script.

Mollie’s card-processing chain includes Visa Europe Services Inc. (UK branch) and Mastercard Europe SA (Belgium) as PCI-DSS-attested sub-processors, governed by Mollie’s own sub-processor register at mollie.com/privacy/processors. Customers preferring to avoid the card-network chain may pay by SEPA Direct Debit.

B.1 Self-hosted components (not Sub-processors) #

fremverk self-hosts all other components on T Cloud Public infrastructure under its own control, including the Forgejo forge, the fremforge middleware (which carries the in-monolith billing engine), the admin UI, the runner controller, FunctionGraph jobs, the Altcha proof-of-work CAPTCHA (rate-limit defence on signup and login-discover; in-app HMAC-signed PoW served from frem.sh/_app/altcha/challenge with widget bundle at frem.sh/_app/static/altcha.js; no third-party widget JS, no external sub-processor, no separate origin, no Redis state — challenge state is HMAC-signed and ephemeral), and the Authentik identity provider where used as fremverk’s own staff IdP. These do not introduce additional Sub-processors.

B.2 EU Commission VIES service (non-commercial public-sector lookup) #

For VAT-number validation at signup, fremverk submits the customer-supplied VAT identifier to the EU Commission’s VIES service (https://ec.europa.eu/taxation_customs/vies/) to qualify cross-border B2B for the reverse-charge mechanism. VIES is operated by the European Commission, is a non-commercial public-sector service, and is neither a sub-processor under Article 28 nor a recipient of personal data beyond the VAT identifier itself (which is a business-registration number, not personal data of the data subject for the purposes of this DPA). Lookup results (valid / invalid / unavailable) are stored against the tenant record for the lifetime of the tenancy plus the audit-log retention window in §9.

B.3 Origin-TLS Certificate Authority — Actalis (eIDAS QTSP) #

For TLS certificate issuance on internal origin hostnames (git-origin.frem.sh and any future *-origin.frem.sh Bunny→ELB origin endpoints), fremverk uses Actalis S.p.A. (Aruba Group, Italy), an eIDAS Qualified Trust Service Provider on the EU Commission’s Trusted List under Regulation 910/2014. Actalis operates an EU-only ACME service (free unlimited 90-day DV certificates, EAB-protected) and the issuing chain (Actalis DV Server ACME CA G1 → Actalis Authentication Root CA) is published in Italy with all infrastructure inside the EU. The ACME-DNS-01 flow submits only the FQDN being certified to Actalis — the CA receives no Customer Personal Data and is not a sub-processor under Article 28 (same posture as VIES above). The certificate authority for the public-edge frem.sh certificates served by Bunny CDN remains Bunny’s own integrated CA chain; this internal-origin CA relationship covers the Bunny-→-ELB origin leg only and was activated 2026-05-04.

Failover procedure (P2-LEG-29 update 2026-05-08, RTO tightened): if Actalis discontinues its free ACME service, revokes our External Account Binding, or its eIDAS QTSP listing is suspended, fremverk will select a replacement CA from the EU Commission’s eIDAS Trusted List (Regulation 910/2014) within 14 days, prioritising paid QTSP-listed providers with public ACME endpoints. The 14-day RTO is set against the 90-day Actalis cert lifetime: ACME renewal runs at 1/3-remaining (every ~60 days), so a 14-day failover window leaves at least one full renewal cycle of headroom before any cert can expire. Candidate fallback identified as of the Effective Date: D-TRUST GmbH (Bundesdruckerei, Germany), eIDAS QTSP — held as the named first-look candidate, but no commercial contract is in place pending the failover trigger condition. The selection is logged in the change log below and announced to Customers per §10. A failover does not by itself constitute a sub-processor change under Annex B because the CA does not receive Customer Personal Data.

B.4 Vulnerability disclosure and pen-test commitments #

fremverk publishes a vulnerability disclosure policy at frem.sh/.well-known/security.txt per RFC 9116, including safe-harbour for good-faith research, scope, and reporting channel. Security testing is conducted under fremverk’s information security programme; third-party penetration test reports, when commissioned, are made available to Customers under NDA on written request. Enterprise-on-Demand contracts may agree to a specific testing cadence in the Order Form.

B.5 Operator mailbox roles #

The shared mailboxes hosted at mailbox.org (Annex B row above) carry the following purpose split. Each is a publicly-routable address; each maps to a documented internal handler:

• support@frem.sh — general customer support and how-do-I tickets.
• abuse@frem.sh — reports of abuse on the platform (spam, malware, ToS violations) per AUP §11.
• security@frem.sh — vulnerability disclosure intake (mirror of the security.txt channel above).
• compliance@frem.sh — GDPR / DPA / DSAR enquiries, controller-side breach reports, and authorised-instruction channel per §5.1.
• hello@frem.sh — first-contact / pre-sales enquiries.
• enterprise@frem.sh — Enterprise-on-Demand and bespoke-contract enquiries.
• ops@frem.sh — operator / oncall mailbox; the destination address that internal monitoring (CES alarms, status-page subscriber bounces, sub-processor change announcements from upstream vendors) routes to. Not a customer-facing channel; routine customer correspondence sent here is forwarded to support@.
• info@fremverk.com — the legal-entity-level address (fremverk ApS) for non-product correspondence (vendor outreach, regulatory filings, KYC). Listed as @fremverk.com rather than @frem.sh because it predates the product domain and is bound to the legal entity, not the product.

B.6 Brand-redirect DNS — Simply.com A/S (not a Sub-processor) #

fremverk uses Simply.com A/S (Denmark, CVR 30 33 88 02) as the registrar and authoritative DNS operator for the brand-redirect domains fremforge.com / fremforge.eu / fremforge.dk (and any future brand-redirect TLDs in the same family). These domains carry only HTTP-301 redirects to the canonical product origin at frem.sh; they hold no application content, no Customer repository data, and no Customer Personal Data.

A DNS authoritative-name-server operator is not a sub-processor under Article 28 in this configuration: DNS queries originate from the visitor’s resolver chain (the visitor’s ISP, public resolver, or stub resolver), not from fremverk. Simply.com receives only the zone-file content fremverk publishes (NS, A/AAAA, CAA, MX, TXT records — all describing routing, not data subjects) and the resolver-side query metadata its own resolvers see when third-party recursive resolvers cache-miss against its authoritative servers. fremverk does not transmit Customer Personal Data to Simply.com, does not have Simply.com process Customer Personal Data on its behalf, and does not appoint Simply.com as an Article-28 processor. The posture matches the VIES (§B.2), Actalis (§B.3), and Card-Network (§Annex B header note for Visa/Mastercard) carve-outs above and is disclosed here for transparency so a procurement reviewer asking “why isn’t Simply.com on the sub-processor register?” can find the answer.

The canonical product origin frem.sh is operated by fremverk on BunnyDNS (Bunny CDN d.o.o., Slovenia — already disclosed as Annex B row 2, the CDN/WAF/edge sub-processor). DNS for frem.sh does not transit Simply.com.

B.7 External uptime monitoring — updown.io (87 Seconds SARL, not a Sub-processor) #

fremverk uses updown.io (87 Seconds SARL, France) to run independent external HTTPS probes against five public health endpoints (the api /healthz endpoint, Forgejo, the Kuma public status page, the marketing site, and the Authentik public sign-in page). The probes detect customer-visible outages independently of fremverk’s in-cluster observability stack.

updown.io is not a sub-processor under Article 28 in this configuration: the probed endpoints are public no-auth health surfaces (none of them expose Customer Personal Data); the probe payload is a plain HTTPS GET against the endpoint URL; the response captured by updown.io is the HTTP status code, latency, TLS-handshake summary, and the egress IP each endpoint resolves to from the probe location. No Customer Personal Data flows to updown.io and no Customer Personal Data is processed on fremverk’s behalf by updown.io. The posture matches the VIES (§B.2), Actalis (§B.3), and Simply.com (§B.6) carve-outs above and is disclosed here for transparency.

B.8 Customer-configured AI vendors (Customer-configured AI vendor key — not Sub-processors) #

fremforge’s AI integration features (AI PR review, Renovate explanations, customer-callable POST /api/v1/orgs/<slug>/ai/complete) operate on a Customer-configured AI vendor key model (sometimes called “BYOK” in vendor marketing, but distinct from the encryption-at-rest CMK custody covered in §17.3 — see §17.3 note on terminology). The Customer configures one or more AI provider entries at /<org>/_admin/ai-integrations (supported adapters: OpenAI-compatible, Anthropic native, Google Vertex Gemini), pasting a third-party API key issued under the Customer’s own commercial agreement with that AI vendor. fremverk encrypts the key at rest using AES-256-GCM with a per-row AAD binding (T Cloud Public DEW KMS root) and acts as a transparent proxy between the Customer’s workflow and the Customer’s chosen AI vendor.

The customer-configured AI vendor is not a sub-processor of fremverk under Article 28 in this configuration:

• The Customer chose the vendor, contracted with the vendor directly, and pays the vendor directly.
• fremverk does not appoint, vet, certify, or contract with the AI vendor on the Customer’s behalf; the Customer’s DPA with the AI vendor governs that processing relationship.
• fremverk does not include AI vendor pricing in Fees and does not mark up vendor costs.
• The Customer may add, change, or remove the AI vendor at any time without notice to fremverk.
• The Customer’s prompts and responses transit fremverk’s api (audit-logged: which feature triggered the call, which provider id, token counts, latency) but fremverk does not retain the prompt or response bodies beyond the request lifecycle.

This is the same posture as Customer-chosen identity providers (Annex B header note: “Customer-chosen identity providers … are the Customer’s processors, not sub-processors of fremverk under this DPA”). When the Customer chooses to enable AI features, the AI vendor is the Customer’s processor; fremverk is in the role of providing the platform integration only.

No US AI vendor on the default path. fremverk does not configure, recommend, or default to any AI vendor. If the Customer chooses a US-incorporated AI vendor (e.g., OpenAI, Anthropic, Google Vertex), CLOUD Act exposure on that AI vendor’s processing is governed by the Customer’s own contract with that vendor — fremverk’s no-US-parent commitment in §11.3 covers fremverk’s own sub-processor stack only, which is unchanged by the AI feature.

Phase 2 turnkey AI. If and when fremverk ships a turnkey AI option (a fremverk-held key + EU-anchored model), that option would constitute a new fremverk sub-processor and would be added to the Annex B register subject to the §10.2 30-day notice. Until then, only the BYOK path is offered and the AI vendor is not a fremverk sub-processor.

Change log #