fremforge Data Processing Agreement — version 1.75.1

This is version 1.75.1 of this document, published 2026-11-05. It takes effect on 2026-11-12 together with version 1.75.2, which supersedes it the same day, so it is never in force on its own; see the current version.

Last updated: 2026-11-05

Effective Date: 2026-04-25 — Current Version: 1.75.1 (effective 2026-11-12; an erratum of version 1.75; 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 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 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, requests to the Customer’s package and container registry (the registry access log), 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.
• Dependency proxy: credentials the Customer stores for an upstream registry (encrypted at rest), and records of pulls through the proxy (the User, IP address, artifact and time).
• Push records and the committer rule: for each push to the Customer’s repositories, other than a merge, merge-queue update or web edit that the Service makes itself, the login and numeric id of the account that authenticated it, how it authenticated (HTTPS, SSH with the key’s id, a deploy key with its id, or a CI job), and each branch or tag updated with its old and new commit. Where the Customer’s committer rule is in warn or block mode, also the identifiers of the commits new to the repository (up to 500 per branch or tag updated), and the committer email address of each new commit that is not one of the pusher’s confirmed email addresses (up to 50 per branch or tag updated); to make that comparison the Service reads the pusher’s confirmed addresses at the time of the push and does not store them. The organisation’s owners and auditors see these records in the console and through the API, and each push is also an entry in the audit log. A push record is deleted once it is older than the organisation’s audit-log retention (the hot tier under Annex A.7: 90 days unless the Customer chooses otherwise, 365 days by default on enterprise plans), except while a legal hold applies to the organisation, and in any case with the organisation under §9.
• Active work (only for an organisation where it is on: off by default for an organisation created before 2026-11-12; for an organisation created on or after 2026-11-12, on by default with automatic draft pull requests on and presence, the match email and the idle-work email off, each of which the Customer can turn off or on): for each branch being worked on, the login of the User the work is done for (the pusher, or the pull-request author), the repository, branch, pull-request number and title, the opening of the pull-request description (up to 600 characters), up to ten commit subjects, the top-level folders the branch changes, and the agent-session links, handoff notes and co-author names that commit and pull-request trailers carry (never a co-author’s email address); for two pieces of work that look like the same work, the words and folders they share, a score, when each User was told, and how a User answered. The comparison is full-text matching inside the Service, and no AI model is used and nothing is sent outside the Service, unless the Customer also turns on semantic matching (off by default), which uses only an AI vendor the Customer has configured under Annex B §B.8 and is described there. Semantic matching can only add a match or raise a match’s score; a match it adds is shown and told as above, and for each pair the Service keeps only whether the AI vendor’s answer counted as a match and a confidence score, deleted with the match. A match is shown only to people who can read the repository (as a comment on the pull request, and through the API), to the organisation’s owners and auditors, and by email to the two Users concerned where the Customer has that email on (off by default for an organisation created on or after 2026-11-12), each of whom can turn that email off for themselves. A piece of work that has finished (its pull request merged or closed, or its branch deleted) is deleted 90 days after it finished, together with its matches, the record of who was told and how they answered. If the Customer turns Active work off, the organisation’s Active work records are deleted 30 days later unless it is turned back on in the meantime. Whatever remains is deleted with the organisation under §9. Separately from these records, the audit log keeps an entry, with the User who acted, each time the organisation’s Active work switches are changed, work is started through the API or agent tools, or a User answers a match (the answer and, where one was named, the User who continues the work); these entries follow the audit log’s retention (Annex A.7 and §9), not the deletion above. The Service also notes when a pull request changes hands (a push to its branch, or the opening of the pull request, by a User other than the one who pushed last) and when an open pull request has had no push for 7 days (checked daily, once per idle period), and keeps the two Users’ logins, the time, and the newest handoff note (what is done, what comes next, open questions) written in the pull-request description or a commit message; where the pull-request comment is on, the comment says who handed over to whom, or that there has been no push since a date and who pushed last, and shows that note. Unless the Customer turns it off (or, for an organisation created on or after 2026-11-12, where the Customer turns it on), the Service also sends each User at most one email a day listing that User’s own open pull requests and branches in the organisation that have had no push for 14 days (an item is listed again once, 14 days later, if nobody answered, and then not until the next push), with three answers: continue (no reminder for a chosen time), hand the work over to a named person with a handoff note, or close it. It keeps, per item, how many reminders were sent and when, and the latest answer with who gave it and when, and, per email, the User, the day and the items listed, deleted after 180 days. Only the User whose work it is and the organisation’s owners can open an item’s answer page and answer it. Each reminder is also an event on the event feed below, which, like every feed event, people who can read the repository can see. Where the Customer turns on automatic closing (off by default), an open pull request idle for at least 60 days (90 by default), with an unanswered reminder at least 7 days old and no approval, requested reviewer or request for changes, is closed and the User told in the email; a branch is never deleted. So that work which predates Active work being turned on is included, the Service reads the organisation’s open pull requests and branches from the Service’s own repository data. Each User can turn these emails off for themselves. Where presence is also on for the organisation (it can be turned off and on separately, and is off by default for an organisation created on or after 2026-11-12), the Service notes, when a request that a User’s AI agent or other client makes to the Service’s MCP server for a repository succeeds, that this User is working in that repository, so that people who can read it see this before the first push. Only the User’s login and the repository are kept, one record per User and repository, renewed by each such request and deleted no later than 60 minutes after the latest one. No history and no count of a User’s requests is kept, and the Service shows only that the User is working there now, never when or how often. It is shown to people who can read the repository (through the API and agent tools) and to the organisation’s owners and auditors on its Active work page. Each User can turn presence off for themselves, and the Customer for the organisation; either deletes the affected records at once and stops new ones.
• Event feed: for each pull request opened, updated, reviewed, merged or closed, each check, merge-queue or CI-run result, each merge hold, each release-train step, each Active work warning, each idle-work reminder and each runaway-CI alert in the Customer’s repositories, the login of the User who caused it, the pull-request title (up to 200 characters) and author, and the commit. A User reads only the events of repositories they can read at the time of reading. Each record is deleted 7 days after it was written, whether or not the feed is switched on for the organisation, and with the organisation under §9.
• CI usage and runaway CI: from the Service’s own records of CI runs, the organisation’s owners and auditors can see the runs and runner minutes each User triggered. Every 5 minutes the Service compares each User’s runs and runner minutes in the last 60 minutes, and the pushes they made to any one pull request, with that User’s own usual hour over the last 14 days (one figure per User, recomputed daily; no hourly history is kept). When a User is far above it, the Service records a runaway (the User’s login, the repository and pull request where it applies, the highest figures, and when it was detected, paused, ended or resumed), emails the organisation’s owners, naming the User, and the User concerned (a bot account is not emailed), puts an event on the event feed for each repository concerned, and writes an audit entry. Only where the Customer has turned it on (off by default) does the Service then hold that User’s runs that have not yet started until an owner resumes them; running jobs and other Users’ runs are never affected. Runaway records are kept for the term of the Service and deleted under §9.
• CI secret reads: when a CI job receives a scoped secret or an environment secret, the Service writes one entry to the organisation’s audit log for that job, listing the NAMES of the secrets it received: with the login of the User who started the run (or the organisation, for a scheduled run), the repository, workflow, job, run, ref and event. Where the job refers to such a secret that its scope does not allow, the entry also lists that secret’s name and the reason it was withheld. A secret’s value is never recorded. These entries are kept and deleted like every other audit-log entry (Annex A.7, §9).
• Security advisories and private vulnerability reports: for a security advisory the Customer drafts for one of its repositories, its description, the affected packages and versions, severity, weakness classification and references, the logins of the people the Customer invites to collaborate on the draft, the comments on the draft, and the names or logins of the people the Customer credits (a credit is shown only after the credited person has accepted it). Where the Customer turns on private vulnerability reporting for a repository (off by default), any person signed in to the Service may submit a report to it, whether or not they are a User of the Customer’s organisation; for each report, the login of the person who submitted it and what they wrote (a description, the affected versions, how the weakness was found and a proof of concept). The Customer is the controller of the reports and of the reporter’s identity, and fremverk processes them on the Customer’s behalf. Drafts, reports and comments are stored encrypted and are shown only to the organisation’s owners, the repository’s administrators, the people invited to the draft and, for a report, the person who submitted it; fremverk’s operational tooling and AI agents see neither their content nor the reporter’s login (Annex A.3). A report the Customer rejects is deleted 2 years after it was rejected. To prevent abuse across organisations, fremverk counts each person’s reports per repository and per day, as its own controller under its legitimate interest (GDPR Art. 6(1)(f)) and not on the Customer’s behalf: only the person’s account, the repository and the time of each report are kept, never what was reported, and each count is deleted after 30 days. When the Customer publishes an advisory for a public repository, its text and the accepted credits are public, on the advisory’s page and in the Service’s machine-readable advisory feed (OSV format), until the Customer withdraws or deletes it; an advisory for a private repository is shown only to those who can read the repository. If a reporter deletes their own account, their login in the reports they submitted is replaced by a pseudonym and the reports stay with the Customer. Whatever remains is deleted with the organisation under §9.
• 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.
• People who submit a private vulnerability report to a repository of the Customer, and people the Customer credits in a security advisory, who need not be Users of the Customer’s organisation.
• 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 90 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 90-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) are not edited to remove an individual Customer’s data. Customer Personal Data deleted from primary storage can therefore remain in these encrypted backups for up to 90 days after primary deletion, and expires with the snapshots that contain it through the normal backup-retention lifecycle. The backups are used only to recover the platform; they are not used to serve or otherwise process the deleted data. Total time from termination to expiry from the live-tier backups is up to 210 days (90-day export window, up to 30 days to primary deletion, up to 90 days in backups).
• Disaster-recovery snapshots (Annex A.9) are sealed copies retained 13 months for object-store payloads and 30 days for repository content (Actions artifacts, CI run logs and tenant-initiated exports are not held in this tier; Annex A.9) 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 it has expired from the live-tier backups, 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 120-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, audit logs, the registry access log, the pull census and the third-party component inventory; 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. On request, the export also includes the package payloads: every file of every package version the Customer’s organisation owns, as a separate archive covered by the same signed manifest (per-file SHA-256), with container images as OCI image layouts; each package file is accompanied by the software bill of materials (CycloneDX and, where produced, SPDX) that the Service generated for it; package payloads above 50 GiB are exported with fremverk’s assistance rather than self-service. Every export also includes, as newline-delimited JSON, the security-scan findings the Service holds for the Customer’s organisation (static analysis, dependency vulnerabilities, licences, container images, secrets — identified by location and fingerprint, never by the secret value — and malware), with their dismissals; the Customer’s package-policy configuration, verdicts, download decisions and exceptions with their approvals; and the build-provenance and release attestations the Service produced, with the signature the Service holds for each (the DSSE envelope and, where one was issued, the Sigstore bundle). These files are covered by the same signed manifest. LFS 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 (UpCloud Ltd, Amsterdam datacenter; OVHcloud, Germany, for backups). 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 fremverk chooses, and no Article 46 GDPR safeguard is required for them. Where the Customer directs the dependency proxy to an upstream registry outside the EU/EEA, see Annex B §B.9; where the Customer turns on a secret validity check for a third-party credential issuer, see Annex B §B.10.

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 fremverk chooses. 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; BunnyWay d.o.o. in Slovenia at EU edge PoPs).

**Card-network footnote ** — 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 UpCloud Ltd (Finland-incorporated, Amsterdam datacenter) with backups at OVHcloud (Germany). No US-parented upstream sits in the email path. Lettermint replaced Sendinblue SAS / Brevo on 2026-05-14; the superseded Brevo cap-table footnote 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.

Customer-chosen upstream registries (dependency proxy) — When the Customer uses the dependency proxy, fremforge fetches artifacts from the upstream registries the Customer names, several of which are operated by US-incorporated companies. See Annex B §B.9: those registries are not sub-processors of fremverk, and any US-extraterritorial-law exposure of their processing is governed by the Customer’s own relationship with them.

Customer-instructed secret validity checks — When the Customer turns on a validity check for a third-party credential issuer, fremforge asks that issuer whether a credential found in the Customer’s repositories is still valid. An issuer may be operated by a US-incorporated company; the setting shows each issuer’s operating jurisdiction (US-operated, EU-operated, UK-operated or Canada-operated) before the Customer turns its check on. See Annex B §B.10: those issuers are not sub-processors of fremverk, and any US-extraterritorial-law exposure of their processing is governed by the Customer’s own relationship with them.

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; and Lettermint B.V. (ISO/IEC 27001:2022, certificate published in Lettermint’s Trust Center).
• 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 BunnyWay 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, which records the current review dates).

A.2 Network and edge security #

• TLS 1.2+ on every HTTP surface. HSTS enabled. Modern cipher suites only.
• DDoS mitigation at the edge (Bunny CDN) on every public HTTP(S) surface — Forgejo UI, Git over HTTPS, the API, the package registry, and the marketing, documentation, status and trust sites. Volumetric attack traffic is blocked at the edge, combined with per-IP rate-limiting edge rules that apply a tighter cap to anonymous traffic than to authenticated requests.
• No Web Application Firewall (WAF) is enabled at the edge on any fremforge surface. This is deliberate. 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 the platform’s SSH service; 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 a dedicated, isolated fremverk cloud project on T Cloud Public (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 federation paths to Authentik becomes effective for an individual tenant only once the operator OIDC credentials are configured in the API’s runtime configuration and the relevant tenant federation is bound.
• Interactive Forgejo site-admin access is break-glass only, through a single local break-glass account vaulted in T Cloud Public DEW CSMS with mandatory MFA; every interactive login pages on-call and writes to the platform-security audit stream.
• Three service accounts also hold the site-admin role and use it in normal operation, and this Annex previously denied that. They serve control-plane provisioning, the CI job lifecycle and fleet-wide security scanning, one account each. 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.
• A fourth service account, the draft pull request account, also holds the site-admin role, for one purpose only: where the Customer turns on Active work’s Draft pull request on the first push for its organisation (off by default for an organisation created before 2026-11-12, and on by default, with Active work, for one created on or after that date; each User can turn it off for themselves), it opens a draft pull request for a branch a User has just pushed, in that User’s name, through Forgejo’s impersonation (Sudo) mechanism. Forgejo honours that mechanism only for a site administrator, which is the only reason the account holds the role. Its API token carries only two scopes, write:fremforge-draft-pr and read:user, and Forgejo itself enforces their limits: the token can open a work-in-progress draft pull request from a branch of the same repository, in the name of an active, non-administrator person who has write access to that repository, and nothing else; every other request made with it, including reading a repository, pushing, merging or acting as anyone on any other request, is refused. Each draft opened is recorded in the Customer’s audit log with the User as actor, and every use and every refusal of the token is logged by Forgejo and alarmed. It processes no category of personal data beyond what Active work already processes (§4.1).
• Control-plane functions otherwise use scoped, non-admin service accounts. The account that posts fremforge’s comments on pull requests (AI review, dependency and licence scan results, Active work) reads every repository through a read-only platform grant; it does not hold the site-admin role, cannot push to or change a repository, and can edit only its own comments.
• Customer-side access is authenticated via OIDC SSO to the Customer’s identity provider, with per-organisation session binding and scoped API tokens as documented in the OIDC SSO page. SAML 2.0 single sign-on is not offered.
• 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 the platform’s SSH service; 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 an internal audit.
• 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 an internal audit.

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 at least hourly. An automated probe 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 fremverk-controlled namespaces of the T Cloud Public container registry (SWR). Git sources are refreshed by Forgejo’s native pull-mirror and OCI images by a scheduled mirroring job, each at least every 12 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 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, with two exceptions the Customer controls: (1) the dependency proxy fetches from the upstream registries the Customer names (Annex B §B.9), some of which are US-jurisdiction hosts, through an outbound proxy that refuses internal and private addresses; and (2) where the Customer turns on a secret validity check for a third-party issuer, the api asks that issuer, at the fixed host, or the fixed list of hosts asked in order, that fremforge has set for it (shown in the setting before it is turned on), whether a credential found in the Customer’s repositories is still valid (Annex B §B.10), through the same outbound proxy, which admits only the hosts of the issuers fremforge offers, for that purpose. Operator-internal flows that do not touch Customer data — the scheduled image-mirroring job’s pull from upstream registries (github.com, gcr.io, docker.io), Forgejo’s own pull-mirror job, the runner image builds described above, fremforge’s own image builds installing npm packages (through the dependency proxy, with a logged fallback to a fremverk-operated cache and then to registry.npmjs.org directly), 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. Added 2026-06-01 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 at least every 5 minutes; the chain is verified at least hourly by an automated integrity check running on the platform; 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.
  • Registry access log (one record for each request to the Customer’s package and container registry, including pulls through the dependency proxy, with the User’s login, client IP address and user agent). Two kinds of routine request through the dependency proxy are the exception. Each is made with a Forgejo Actions job token, and each is allowed and answered without error. A package metadata read of this kind is not recorded. A download of this kind that the dependency proxy serves from its cache is recorded only as a count in the pull census: per day, package version, repository and Actions run, without a login, client IP address or user agent. Every other request, including every refused or failed request and every request by a User, bot, registry robot or anonymous caller, is one record. Retention is a per-tenant setting of 30 to 730 days. Unset, it follows the security-relevant audit-event retention above (90 days for the standard plan; 365 days for Enterprise-on-Demand, the operator-provisioned custom trial and internal plans). The pull census is kept for the same period. Older records are deleted daily, and none are deleted while a legal hold applies to the Customer’s organisation. Access records are not part of the audit hash chain.
  • Immutable WORM archive (both tiers): 3 years (1095 days) in T Cloud Public OBS Object Lock compliance-mode; hash-chain anchored at least every 5 minutes; payload-bearing rows redacted at hot-tier cutoff but anchor chain is unbroken.
• WORM retention configurability. 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.
• Agents have no audit identity of their own. An action an agent takes on behalf of a User, under a delegated mandate (OAuth 2.0 token exchange, RFC 8693) or through an MCP connector the User authorised, is recorded with that User as actor, the agent in the entry’s agent field and the token it used in via_token — distinguishable in the audit stream and in admin-UI filters from the User’s own actions: the actor filter of the audit log, in the admin UI and through the API, matches a value in actor, on_behalf_of or the entry’s agent field. Entries written before 2026-10-23 are not rewritten (the hash chain covers them) and keep the earlier form, with the agent as actor (oidc:agent:<agent_id>) and the User in on_behalf_of.

fremverk verifies the integrity of the audit chain through an automated check, run at least hourly, 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 anchoring interval in this Annex 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 copy-if-absent replication sweep to eu-nl run at least daily, verified per-object at least daily (for OBS). Both mechanisms run considerably ahead of the ≤ 7 day bound: SFS Turbo backups are taken at least every 12 hours and replicated continuously, and the OBS sweep runs at least 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 and backup-integrity verification at least monthly, the WORM archive read-back drill at least weekly, and backup-presence verification at least daily. 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.
• Automated backup-presence verification, at least daily. Independent of the annual restore drill, an automated check, run at least daily, asserts that the most recent RDS automatic snapshot exists, completed successfully, finished within the last 25 hours, and is non-zero in size. A failed assertion pages on-call through the same alerting channel 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 deletion per §9 (deleted data expires from this tier within 90 days of primary deletion, up to 210 days from termination). 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: an object-lifecycle rule on each eu-nl bucket permanently removes every copy within 395 days, plus at most one day, of the day it was written there, 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. Actions artifacts and CI run logs are also excluded from this DR tier: since 2026-10-21 they are not replicated cross-region, and the copies made before that date were permanently removed from eu-nl the same day. Excluded for the same reason as exports: an artifact or log lives only as long as the Customer’s own retention setting allows and is reproducible by re-running the workflow that produced it, so a sealed 13-month second copy would extend the life of Customer data well beyond the window the Customer chose, for no recovery benefit. 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 at least monthly.
• Customer-data-restore SLA: 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, following a written operator procedure 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 the on-call staff as email, which they receive as push email on their phones. Alerts of every severity take this path, and it sends no SMS. Independently of SMN, the external uptime checks in Annex B.7 alert the on-call staff by SMS when the api health endpoint, Forgejo, the identity provider or the alerting path’s own heartbeat stops responding.
• 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 separate 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.
• Active work: a per-organisation switch, off by default for an organisation created before 2026-11-12 and on by default for one created on or after that date (with automatic draft pull requests on and presence, the match email and the idle-work email off), with separate switches for the pull-request comment, the email, presence, automatic draft pull requests and semantic matching (semantic matching also requires the Customer’s own AI provider entry under Annex B §B.8, and sends only to the host of that entry as it was when semantic matching was turned on, through a restricted outbound proxy; a change of that host turns semantic matching off), each change to which is an audit event with the person who made it as actor; and each User’s own switch for presence.
• Private vulnerability reporting: a per-repository switch, off by default, with an organisation-wide default; each change, and each report accepted, rejected or published as an advisory, is an audit event with the person who made it as actor.

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) 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 (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 (BunnyWay d.o.o., Slovenia — already disclosed as Annex B row 2, the CDN/edge sub-processor). DNS for frem.sh does not transit Simply.com.

B.7 External uptime monitoring — Phare (not a Sub-processor) #

fremverk uses Phare (phare.io, operated by Lightkeeper OÜ, Estonia) to run independent external HTTPS probes against six public health endpoints (the api /healthz endpoint, Forgejo, the Kuma public status page, the marketing site, the Authentik public sign-in page, and the heartbeat endpoint of the on-call alerting path). The probes run on BunnyWay d.o.o.’s infrastructure in Frankfurt, Paris and Stockholm, and detect customer-visible outages independently of fremverk’s own monitoring on the platform.

Phare 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 Phare 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 Phare and no Customer Personal Data is processed on fremverk’s behalf by Phare. 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, AutoFix AI fixes for SAST findings, and Active work semantic matching) 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.

AutoFix AI fixes for SAST findings use the same model and nothing else. The feature is off unless the Customer turns it on, and runs only for an organisation that has configured its own AI provider entry: there is no fremverk-held key and no fallback, so without a Customer-configured provider the AI fix is not available. It applies to a curated set of SAST rules unless an owner of the Customer’s organisation chooses, in the AI fix settings, to apply it to every finding of the Service’s SAST scan (its standard rule set and its taint rules) in Go, Python, JavaScript or TypeScript, Java and C#; turning AI fixes on does not choose that wider scope, which applies only from the moment an owner chooses it. It never applies to secret-scanning findings, to the Customer’s own custom rules, or to a finding in a test, CI, suppression or dependency file, and it runs only when a User asks for a fix to a specific finding or to selected findings, at most 10 findings of one repository at a time, each handled as its own request under every limit in this paragraph. The request sent to the Customer’s chosen AI vendor contains the rule’s name and description, the scanner’s message for the finding (which can quote the code and is treated as the code is), the lines of code around the finding and, where the fix needs them, excerpts of up to three further files of the same repository (never test, CI, suppression or dependency files); each request is at most 48 KB and 400 lines of code. Before anything is sent, the Service’s secret scanning checks every part of the request: lines in which it finds a credential are masked, a request in which one remains is not sent, and if the scan cannot run nothing is sent. It is sent only to the host of the Customer’s provider entry, through a restricted outbound proxy that admits, for each request, only that host. The vendor’s answer is itself checked for credentials and is accepted only as a change to at most three of the files shown to the vendor, within the code shown, each of which is re-scanned; an answer that changes CI or workflow configuration, or that weakens security configuration (for example by turning off certificate checks), is refused. It is proposed as a draft pull request in the Customer’s own repository; when a User asked for several findings, the fixes that passed every check are proposed together in one draft pull request. The Customer’s checks run on that pull request as on a pull request from outside the repository, without the repository’s, the organisation’s or any environment’s secrets and without an identity token; a draft whose checks fail is closed; and no AI fix is ever merged automatically. The vendor may instead answer that a finding is not a real problem; that answer is shown to the User with the finding as a suggestion and changes nothing unless a User dismisses the finding. fremverk does not retain the request, the answer or the proposed change outside that pull request, except the vendor’s short reason for a “not a real problem” answer, which is kept with the finding (after a secret scan) so that a User can read it; the audit log records, for each call, which finding, which provider, how many files and lines were sent and the token counts, not the content.

Active work semantic matching uses the same model and nothing else. It is off unless the Customer turns it on, in addition to Active work (§4.1), and runs only with an AI provider entry the Customer configured: there is no fremverk-held key and no fallback. When it is on, when a piece of work in a repository, or the other work in progress it is compared with, has changed (at most once every 10 minutes for each piece of work), the Service sends to the Customer’s chosen AI vendor, for that piece of work and for at most 15 other pieces of work in progress in the same repository: the title, the opening of the pull-request description (up to 600 characters), the branch name without a leading User login, and the top-level folders the branch changes. The request contains no code, diff or file content, and, apart from anything Users themselves wrote in a title, description or branch name, no User’s login, name or email address; a field in which the Service’s secret scanning finds a credential is left out of it. It is sent only to the host of the Customer’s provider entry as it was when semantic matching was turned on, through a restricted outbound proxy that admits, for each request, only that host; if the host of the provider entry changes, semantic matching turns itself off until the Customer turns it on again, and that is recorded in the audit log. fremverk does not retain the request or the answer, apart from a one-way hash of the request, kept only so that the same request is not sent twice; for each pair of pieces of work it keeps only whether the answer counted as a match and a confidence score. The hash and these records are deleted with the piece of work and its matches, under the Active work retention in §4.1. A pull-request comment or email about a match found or confirmed this way says so and names the AI vendor and model. If the call fails, is slow, or would exceed the Customer’s limits, matching continues with full-text matching alone. Turning semantic matching on or off, and each change of the provider it uses, is recorded in the Customer’s audit log with the User who acted; each call is recorded as for the other AI features (feature, provider, token counts, latency), never its content.

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.

B.9 Customer-chosen upstream registries (dependency proxy — not Sub-processors) #

The dependency proxy fetches container images and packages from upstream registries on the Customer’s instruction. The Customer enables the proxy for its organisation, and a User names the upstream registry and the artifact in each pull. The upstreams are a fixed list of public registries and repositories (currently, for container images: Docker Hub, GitHub Container Registry, Quay, Microsoft Container Registry, the Kubernetes registry, Amazon ECR Public and the Red Hat registries; for packages: npm, PyPI, Maven Central, nuget.org, the Go module proxy and its checksum database, crates.io, the Red Hat Universal Base Image package repositories, and the Helm chart repositories of prometheus-community, Grafana, Jetstack and ingress-nginx, several of which serve their charts from GitHub); Apart from the registry and module hosts the Customer designates under Customer-designated registry and module hosts below, fremforge never fetches from an address the Customer supplies. Several of these registries are operated by US-incorporated companies.

An upstream registry is not a sub-processor of fremverk under Article 28:

• The Customer chooses whether to use the proxy and which upstream each artifact comes from. fremverk does not appoint, vet or contract with the upstream on the Customer’s behalf.
• The upstream receives a request from fremforge’s IP address for the named artifact. It does not receive the identity or IP address of the User who pulled.
• The Customer may store its own credential for an upstream, issued under its own agreement with that registry. Some upstreams require one (Docker Hub, and the Red Hat registries that require an account). For others the Customer may add one to reach its own private content (GitHub Container Registry and Quay), and every pull from that registry then uses it. fremverk encrypts the credential at rest, never displays or logs it, and sends it only to that registry when fetching for that Customer. The registry then identifies the Customer’s own account, and that relationship is governed by the Customer’s agreement with the registry, not by this DPA.
• Content fetched with a Customer’s credential is cached for that Customer’s organisation only and is never served to another organisation.
• The Customer may switch the proxy off, or remove a stored credential, at any time.

Customer-designated registry and module hosts. The Customer’s organisation owners may switch this on and store a credential for a private container registry or git module host of the Customer’s own choosing. The Customer limits the credential to read access, and fremforge only reads with it: fremforge’s security scanners use it, only on scans of the Customer’s own organisation, to read from that host the container images and infrastructure modules that the Customer’s repositories reference, in order to scan them for the Customer. The host is chosen by, and operated by or for, the Customer, and is not a sub-processor of fremverk. fremverk encrypts the credential at rest and never displays or logs it. It is sent only to the exact host the Customer designated, including a token endpoint on that same host; a redirect to any other host is followed without it. Content read with it is cached for the Customer’s organisation only and is never served to another organisation; when the credential is deleted, that content is deleted too, the cached copies within the following hour. Each credential carries an expiry of at most one year. The Customer may switch the feature off, after which no stored credential is used, or delete a credential, at any time. Storing, replacing and deleting a credential, switching the feature on or off, and each scan that used a credential are recorded in the Customer’s audit log.

Cached content is stored in T Cloud Public eu-de and served through the EU edge, by the sub-processors already listed in this Annex. If the Customer names a US-operated upstream, any US-extraterritorial-law exposure of that registry’s processing is governed by the Customer’s relationship with it; fremverk’s commitments in §11.2 and §11.3 cover the processing paths fremverk chooses and fremverk’s own sub-processors, which the proxy does not change.

B.10 Customer-instructed secret validity checks (not Sub-processors) #

fremforge’s secret scanning finds credentials committed to the Customer’s repositories. For a credential it finds, fremforge can check whether it is still valid, so the Customer can rotate the live ones first. For credentials that fremforge itself issues (frem.sh API tokens) the check runs inside fremforge and nothing leaves the Service. For credentials issued by a third party, the check is a request to that issuer, made only on the Customer’s instruction, under the following safeguards:

• A curated list, offered by fremforge. fremforge offers a check only for an issuer it has added to the Service, each with a fixed host, or a fixed list of hosts asked in order, and one fixed check. The Customer cannot enter a URL, host or request of its own, and fremforge never sends a credential anywhere but to the issuer it belongs to. The current issuers, the host each check contacts, the request it makes and each issuer’s operating jurisdiction are published in the documentation and shown in the setting.
• Opt-in per issuer, off by default. Each issuer is its own setting for the Customer’s organisation at /<org>/_admin/security/policies/push-protection (and the API). A check for an issuer runs only while the Customer has turned it on. Before it is turned on, the setting names the host the check contacts and whether the issuer is US-operated, EU-operated, UK-operated or Canada-operated. fremforge offers an issuer operated from outside the EU/EEA only where it is US-operated, or operated from the United Kingdom or Canada, both countries for which the European Commission has adopted an adequacy decision under Article 45 GDPR. An issuer that fremforge adds later is offered switched off, and fremverk never turns a check on for the Customer.
• What is sent. The credential itself, to its own issuer, in a single request to a read-only endpoint that reports whether the credential is valid, or, where the issuer has a fixed list of hosts, one such request to each host in order, stopping at the first that reports the credential valid (where the issuer requires it, the request is signed with the credential found, as for an identity call). No request creates, changes or deletes anything at the issuer, and fremforge offers no issuer that lacks such a read-only check. No other repository content, and no identity or IP address of a User, is sent.
• What is kept. Only the outcome (active, inactive or unknown) and the time of the check, on the finding. The credential is never stored by fremforge: it is read during the repository scan, passed once to fremforge’s api encrypted to a key created for that scan alone (the key is deleted when the scan ends), used for the check and discarded. It is never logged.
• Where it runs. In fremforge’s api in T Cloud Public eu-de, through fremforge’s outbound proxy, which admits only the hosts of the issuers fremforge offers, for this purpose. The scanning components that read the Customer’s repositories have no network access to the issuers.

An issuer contacted for a validity check is not a sub-processor of fremverk under Article 28:

• The Customer chooses whether to turn each check on, and which issuers. fremverk does not appoint, vet or contract with the issuer on the Customer’s behalf.
• The issuer receives a credential it issued itself, under its own agreement with the Customer (or with whoever holds the credential), and answers whether it is valid. The relationship between the Customer and that issuer is governed by their own agreement, not by this DPA.
• The Customer may turn any check off at any time; doing so also removes the stored outcomes for that issuer.

Turning a check on causes a new scan of the Customer’s repositories’ history, because a credential’s value exists only while a scan reads it. If the Customer chooses a US-operated issuer, any US-extraterritorial-law exposure of that issuer’s processing is governed by the Customer’s relationship with it, and the same holds for the law of the United Kingdom or Canada where the Customer chooses an issuer operated from there; fremverk’s commitments in §11.2 and §11.3 cover the processing paths fremverk chooses and fremverk’s own sub-processors, which these checks do not change.

B.11 Public leak monitoring for frem.sh credentials (no Customer data leaves; not Sub-processors) #

fremforge reads public code on github.com to find credentials that fremforge itself issues: frem.sh platform API tokens (beginning ffp_), OAuth client secrets (beginning ffs_), and frem.sh personal access tokens where they appear in a frem.sh URL. It does this so that a credential of the Customer’s that has been published outside the Service can be stopped quickly. It reads GitHub’s public events feed and the public commits that feed names.

• What is sent. Nothing about the Customer. fremforge makes the requests under fremverk’s own GitHub account, and each request names only a public repository and commit that GitHub’s own feed listed. No Customer Personal Data, credential, credential hash, organisation name or repository of the Customer is sent to GitHub or to anyone else.
• Where it runs. In T Cloud Public eu-de. The component that reads GitHub holds no database credential and reaches GitHub only through fremforge’s outbound proxy. The comparison with frem.sh’s own credential store runs inside fremforge’s api and makes no external call, as for frem.sh tokens in §B.10.
• What is kept. Public content that matches nothing is processed in memory and discarded. Where a credential matches a live frem.sh credential, fremforge keeps a finding for the Customer’s organisation: the public URL, repository, commit, file and line where the credential was found, which credential it was (a reference, never the credential itself), when it was found and what was done. fremforge never keeps the credential or a copy of the public content.
• What fremforge does. It notifies the credential’s owner and the organisation’s owners, and records the finding in the Customer’s audit log. It also revokes the credential, unless the Customer’s organisation owners have chosen “notify only” for the organisation. That setting is at /<org>/_admin/security/policies/push-protection (and the API). The default is to notify and revoke, because a credential published in public code must be treated as compromised. Revoking does not delete the public content. The Customer remains responsible for removing it and for rotating the credential (Terms §6.2).

GitHub is the source of public data, not a sub-processor of fremverk under Article 28. It receives no Customer Personal Data and processes nothing on the Customer’s behalf. GitHub is US-operated, but because nothing of the Customer is sent to it, this monitoring does not change fremverk’s commitments in §11.2 and §11.3.

Coverage is best effort. GitHub’s feed is a delayed sample of public activity, so fremforge does not commit to finding every published credential.

Change log #