[{"content":"Why this page exists # Section 11A of the Data Processing Agreement commits fremverk to an annual transparency report disclosing — in aggregate — every government or law-enforcement request for Customer Personal Data we receive. This page is that report.\nThe report is reissued annually for each full calendar year of operation. Where a calendar year carries zero requests, this page records that fact for the year — non-disclosure of \u0026ldquo;zero\u0026rdquo; would be informationally identical to non-publication, which would defeat the transparency purpose.\nReporting period coverage # Period Coverage 2026 (partial — pre-launch) Pre-launch operations only. fremverk had no Customer Personal Data in production processing scope until launch. Reports for full calendar years follow once the first one closes.\nAggregate request data # Reporting period: 2026 (partial — pre-launch) # Metric Count Total government-access requests received 0 Requests fully complied with 0 Requests partially complied with 0 Requests rejected on jurisdictional or procedural grounds 0 Requests pending at end-of-period 0 Customer Personal Data records disclosed 0 Customers notified pursuant to DPA §11A.1(c) 0 Jurisdictions of origin # None — no requests received.\nCategories of data requested # Not applicable — no requests received.\nHow fremverk handles requests # When a binding legal demand is received, fremverk applies the process documented in DPA §11A.1:\nVerify the demand is binding under EU law and that the issuing authority has jurisdiction over fremverk and the data sought. Narrow the scope to the minimum data set permitted by the demand. Notify the affected Customer before disclosure unless explicitly prohibited by a court order — in which case fremverk pushes for the shortest possible non-disclosure period and notifies as soon as the prohibition lifts. Challenge demands that exceed jurisdictional scope, lack proportionality, or compel disclosure of data outside the EU/EEA. Document the request, the disposition, and the data disclosed for inclusion in this report. fremverk has not received and will not voluntarily comply with non-EU-jurisdictional requests for Customer Personal Data. This includes — without limitation — requests under the US CLOUD Act, US National Security Letters, US Foreign Intelligence Surveillance Act subpoenas, or analogous extraterritorial mechanisms. The CLOUD Act has no extraterritorial reach over fremverk because neither fremverk nor any sub-processor on the Customer Personal Data path has a US parent. See DPA §11 for the full residency commitment.\nSubscribe to updates # This page updates annually (typically late January for the prior year). To be notified when a new report publishes, subscribe to the security mailing list — the same list announces sub-processor changes per DPA §10.\nRelated # Data Processing Agreement § 11A — the contractual commitment this report fulfils Sub-processor list — every entity with potential access to Customer Personal Data, with jurisdiction Trust page — overall security + compliance posture Last updated: 2026-05-06.\n","externalUrl":null,"permalink":"/trust/transparency/","section":"Trust","summary":"Why this page exists # Section 11A of the Data Processing Agreement commits fremverk to an annual transparency report disclosing — in aggregate — every government or law-enforcement request for Customer Personal Data we receive. This page is that report.\n","title":"Transparency report — government and law-enforcement access","type":"trust"},{"content":"Why this page exists # fremforge is a hosting service within the meaning of Regulation (EU) 2022/2065 (Digital Services Act, \u0026ldquo;DSA\u0026rdquo;). Article 15 of the DSA obliges every intermediary service to publish — at least once a year, in machine-readable form — a clear, easily comprehensible report on its content moderation activity. This page is that report.\nThis is distinct from the government and law-enforcement transparency report, which covers binding legal demands for Customer Personal Data under the DPA. That report addresses GDPR / law-enforcement access; this one addresses DSA Art. 15 content moderation reporting. Both are published annually.\nReporting cadence # The report is reissued annually. fremforge launches during 2026, so the year-1 entry is a partial-period statement covering the period from the launch date to 31 December 2026. Subsequent reports cover full calendar years and publish in Q1 of the following year.\nDSA Art. 15 explicitly accommodates a \u0026ldquo;we launched and have nothing to report\u0026rdquo; first-year statement. Silence is the violation — publishing zero with the framing that explains it is the compliant disposition.\nReporting period: 2026 (partial — pre-launch operations) # As of the date below, fremforge has not yet entered general availability for paying customers. There has been no Customer Content in scope for content moderation. All counts in this section are necessarily zero.\nArt. 15(1)(a) — Orders received from EU member-state authorities # Orders to act against illegal content (DSA Art. 9) and orders to provide information (DSA Art. 10), broken down by issuing member state and category of illegal content. Median time to inform the issuing authority and to give effect to the order.\nMetric Count Total Art. 9 (act-against-content) orders received 0 Total Art. 10 (provide-information) orders received 0 Median time to acknowledge issuing authority n/a Median time to give effect to order n/a Issuing member states # None — no orders received.\nCategories of illegal content # Not applicable — no orders received.\nArt. 15(1)(b) — Notices submitted under Art. 16 (notice-and-action) # Notices submitted via abuse@frem.sh and the structured form at https://frem.sh/_app/legal/abuse-report, broken down by category of allegedly illegal content, action taken, and median time to action. The notice-and-action mechanism is documented in AUP §5.\nMetric Count Total Art. 16 notices received 0 Notices submitted by Trusted Flaggers (Art. 22) 0 Notices acted on (content removed, restricted, or account action taken) 0 Notices rejected (manifestly unfounded or out-of-scope) 0 Median time to decision n/a Use of automated means in decision-making None Categories of allegedly illegal content # None — no notices received.\nArt. 15(1)(c) — Own-initiative content moderation # Content moderation that fremverk performed on its own initiative — including the use of automated tools, the qualifications of human reviewers, and any safeguards applied. fremforge applies its Acceptable Use Policy uniformly to all Customer organisations.\nMetric Count Own-initiative actions taken 0 \u0026hellip;of which used automated tools (push-protection scanner) 0 \u0026hellip;of which involved human review 0 Errors of automated tools (false positives, on appeal or internal review) 0 Indicators used for accuracy / error rate n/a Training given to human reviewers n/a — no own-initiative actions yet The push-protection scanner referenced above is a server-side scanner that rejects pushes containing high-confidence secret material at the git protocol layer. It is not a content-moderation system in the conventional DSA sense (it does not classify content as illegal, and the rejection is a technical refusal of a developer commit, not a moderation outcome on hosted material). It is reported here for completeness only, and counts will appear in future periods if any rejections occur.\nArt. 15(1)(d) — Internal complaint-handling system # The internal complaint-handling system required by DSA Art. 20 lets users and notifiers appeal moderation decisions. The right of appeal is documented in AUP §5. Complaints are received at abuse@frem.sh with the subject line appeal: and resolved within 14 days.\nMetric Count Total complaints received 0 Complaints resolved in favour of the original decision 0 Complaints resolved against the original decision (decision reversed) 0 Median time to resolution n/a Decisions referred to out-of-court dispute resolution under Art. 21 0 Average monthly active recipients of the service in the EU # Per DSA Art. 24(2), intermediary services must publish — at least once every six months — the average monthly active recipients of the service in the EU. fremforge is below the threshold for very-large-online-platform (VLOP) designation; this metric is published here for completeness.\nPeriod Average monthly active EU recipients 2026 (partial — pre-launch) 0 This count includes natural and legal persons in the EU who used the service at least once in the calendar month, computed as a six-monthly arithmetic mean. The methodology will be documented in future periods once fremforge has paying customers and a non-zero count to publish.\nMethodology and data sources # Counts on this page are derived from:\nThe audit_events table (see Audit log on docs) — every legally significant action against fremforge infrastructure produces an immutable, hash-chained audit event. The aggregator job runs against event_type IN ('legal_takedown_received', 'legal_takedown_actioned', 'content_moderation_action', 'art16_notice_received', 'art20_complaint_received') once per quarter and updates this page. Inbound abuse@frem.sh and compliance@frem.sh mailbox correspondence — a per-correspondence index is maintained internally for cross-referencing against the audit-event aggregate. The Forgejo organisation register, which tracks suspension, throttling, and termination actions per AUP §7. The first non-zero report (covering full calendar year 2027) will publish in Q1 2028 and will include the methodology section in machine-readable form per the European Commission\u0026rsquo;s Implementing Regulation 2024/2835 templates.\nSubscribe to updates # This page updates annually (typically late January for the prior year, plus a six-monthly Art. 24 update for the EU recipients metric). To be notified when a new report publishes, subscribe to the security mailing list — the same list announces sub-processor changes per DPA §10 and the government-access transparency report.\nRelated # Acceptable Use Policy §5 (DSA Art. 16 notice-and-action) — the contractual basis of the notice-and-action mechanism summarised on this page Government access transparency report — DPA §11A.2 report on law-enforcement and government access requests (separate obligation) Trust page — overall security and compliance posture DSA Art. 15 reporting templates (EU Commission Implementing Regulation 2024/2835) — the standardised reporting format applied from year 2 onwards Last updated: 2026-05-07.\n","externalUrl":null,"permalink":"/trust/dsa/","section":"Trust","summary":"Why this page exists # fremforge is a hosting service within the meaning of Regulation (EU) 2022/2065 (Digital Services Act, “DSA”). Article 15 of the DSA obliges every intermediary service to publish — at least once a year, in machine-readable form — a clear, easily comprehensible report on its content moderation activity. This page is that report.\n","title":"DSA transparency report — Article 15","type":"trust"},{"content":"When your SSH client connects to ssh.frem.sh:443 for the first time, it asks you to confirm the server\u0026rsquo;s host key fingerprint. (Port 22 is not publicly exposed on the apex domain — ssh.frem.sh:443 is the only published SSH endpoint.) Verify the fingerprint matches one of the values below before accepting. A fingerprint that does not appear here means you are looking at a man-in-the-middle, a stale cache, or a different server — do not trust it.\nCurrent fingerprints # Algorithm SHA-256 fingerprint Bit length ssh-rsa SHA256:LNz5zoh9R2KZAhNGeFgKSeBMPEzbNBdd0wqwrwEkU3E 4096 Currently only ssh-rsa is published. ED25519 + ECDSA host keys are not enabled at the Forgejo layer in this deployment; if your client requires them, force RSA via ssh -o HostKeyAlgorithms=ssh-rsa,rsa-sha2-256,rsa-sha2-512.\nWhat to do at the prompt # When OpenSSH prints something like:\nThe authenticity of host \u0026#39;ssh.frem.sh (...)\u0026#39; can\u0026#39;t be established. RSA key fingerprint is SHA256:LNz5zoh9R2KZAhNGeFgKSeBMPEzbNBdd0wqwrwEkU3E. Are you sure you want to continue connecting (yes/no/[fingerprint])? Compare the printed fingerprint to the row in the table above. If it matches, type yes; OpenSSH adds the key to your ~/.ssh/known_hosts and never prompts again for that host. If it does not match, type no and reach out via support@frem.sh before trying again.\nAvoiding the prompt entirely # You can pre-trust the host key by appending it to your known_hosts file:\nssh-keyscan -t rsa -p 443 ssh.frem.sh \u0026gt;\u0026gt; ~/.ssh/known_hosts Then verify the SHA-256 with:\nssh-keygen -lf \u0026lt;(ssh-keyscan -t rsa -p 443 ssh.frem.sh 2\u0026gt;/dev/null) The output should match the table above.\nWhen fingerprints rotate # We rotate Forgejo host keys only when the underlying server cluster is rebuilt. When that happens we publish the new fingerprints here at least 24 hours before the cutover, archive the previous fingerprints for 90 days under Previous fingerprints, and post a notice on status.frem.sh.\nIf your client warns \u0026ldquo;REMOTE HOST IDENTIFICATION HAS CHANGED\u0026rdquo; and the new fingerprint does not appear here, do not clear known_hosts — contact us first.\nPrevious fingerprints # None archived (this is the first publication of this page).\nRelated # Connecting to fremforge over SSH — clone instructions, port-443 fallback, troubleshooting Status page — current uptime + planned maintenance Trust page — sub-processors, audit posture, EU-only data residency Last updated: 2026-05-06.\n","externalUrl":null,"permalink":"/ssh-fingerprints/","section":"SSH host key fingerprints — frem.sh","summary":"When your SSH client connects to ssh.frem.sh:443 for the first time, it asks you to confirm the server’s host key fingerprint. (Port 22 is not publicly exposed on the apex domain — ssh.frem.sh:443 is the only published SSH endpoint.) Verify the fingerprint matches one of the values below before accepting. A fingerprint that does not appear here means you are looking at a man-in-the-middle, a stale cache, or a different server — do not trust it.\n","title":"SSH host key fingerprints — frem.sh","type":"ssh-fingerprints"},{"content":"Effective: 2026-05-24 — fremforge Phase 1 AI integrations\nThe one-line summary # fremforge never sub-processes customer code through a US AI vendor on the default path. The customer brings their own AI vendor key (BYOK) and chooses their own vendor. The vendor is the customer\u0026rsquo;s own processor under the customer\u0026rsquo;s own contract, not fremverk\u0026rsquo;s sub-processor under the Data Processing Agreement.\nThis is codified at DPA Annex B §B.8.\nWhat \u0026ldquo;AI integrations\u0026rdquo; covers # fremforge ships three server-side AI features that use the customer\u0026rsquo;s configured AI vendor:\nAI PR review — when a pull request opens or syncs, fremforge sends the diff + PR metadata to the configured vendor and posts a structured review comment with a pending → success / warning commit-status. Renovate dep-bump explanations — Renovate-authored PRs get a tighter prompt focused on CVE remediation and breaking-change risk. Customer-callable gateway — POST /api/v1/orgs/\u0026lt;slug\u0026gt;/ai/complete with a PAT carrying the ai:invoke scope. Customers\u0026rsquo; own workflows + scripts call this endpoint instead of embedding vendor SDKs. A separate path exists for dev-side AI tooling (Claude Code, Cursor, Continue, JetBrains AI talking to fremforge via the standard REST API + PAT). That path doesn\u0026rsquo;t transit any AI vendor through fremverk\u0026rsquo;s infrastructure; see docs.frem.sh/get-started/ai-in-your-ide/.\nSupported vendors (Phase 1, BYOK) # fremforge supports three adapter shapes that cover every current major vendor:\nAdapter Vendor examples openai-compatible OpenAI, Azure OpenAI, Mistral, Together, Fireworks, OpenRouter, T-Cloud AIFS, any custom OpenAI-compatible URL anthropic Anthropic native API vertex-gemini Google Vertex Gemini The customer pastes a vendor API key in the admin UI at /\u0026lt;org\u0026gt;/_admin/ai-integrations. The key is encrypted at rest with AES-256-GCM using T Cloud DEW KMS with a per-row AAD binding (so a key extracted from a database backup cannot be decrypted without also extracting the matching row id).\nThe data path # For each AI call (PR review, Renovate explanation, or workflow-callable /ai/complete):\nThe customer\u0026rsquo;s repo, a webhook payload, or a workflow step originates the request. fremforge\u0026rsquo;s api pod assembles the prompt: diff text + PR metadata + system prompt + customer-supplied messages. fremforge\u0026rsquo;s api pod sends an HTTPS request to the customer-configured vendor\u0026rsquo;s URL with the customer-configured key. The vendor\u0026rsquo;s response is captured: token counts, latency, model name, response text. fremforge posts a Forgejo comment (PR review) OR returns the response to the workflow (/ai/complete). An ai_usage_events row records the call: tenant, provider, model, tokens-in, tokens-out, latency. The prompt and the response body are not retained beyond the request lifecycle. The prompt + response transit fremforge\u0026rsquo;s api pod once. They do not transit any third-party log aggregator, observability service, or backup. Per-call audit emits the metadata (which feature, which provider, token counts) but not the body.\nWhy \u0026ldquo;not a sub-processor\u0026rdquo; # Article 28 GDPR makes someone a sub-processor when the controller appoints them, contracts with them, and instructs them to process the data on the controller\u0026rsquo;s behalf. None of those apply here:\nThe customer chooses the AI vendor. fremverk does not appoint or recommend one. The dropdown in the admin UI lists adapter shapes, not endorsements. The customer contracts with the AI vendor directly. fremverk has no commercial relationship with the AI vendor for this purpose. The customer pays the vendor; fremverk does not mark up vendor token costs. The customer can remove the AI vendor at any time without notifying fremverk. That\u0026rsquo;s not how a fremverk sub-processor relationship works. fremverk\u0026rsquo;s own no-US-parent sub-processor commitment in DPA §11.3 is unchanged. A customer choosing a US-incorporated AI vendor (OpenAI, Anthropic, Google Vertex) is exposing themselves to that vendor\u0026rsquo;s jurisdiction — not fremverk\u0026rsquo;s. This is the same legal posture as customer-chosen identity providers (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik) federated into fremforge via OIDC. They appear in the Annex B header note for the same reason.\nThe Phase 2 \u0026ldquo;turnkey\u0026rdquo; trajectory # When AIFS (T-Cloud AI Foundation Services) ships a code-tuned model good enough for PR review — currently expected 6–18 months out — fremverk plans to offer a turnkey AI plan tier where fremverk holds an AIFS-Germany account and bills per-seat for tokens. That option would constitute a new fremverk sub-processor and would be added to the Annex B register subject to the 30-day §10.2 notice.\nThe BYOK path stays available even after turnkey ships — customers can always bring their own vendor key.\nAudit visibility # Every AI call emits an audit event:\ntenant.ai_integration.provider_added / _disabled / _tested — provider config changes tenant.ai_integration.feature_default_changed — which provider handles which feature tenant.ai_integration.repo_override_changed / _removed — per-repo overrides ai.complete.ok / ai.complete.failed — every customer-callable /ai/complete request Customers see token-spend per month and per-(provider, model) 👍/👎 satisfaction scores in the admin UI; the underlying ai_usage_events and ai_review_comments tables drive both. Customer audit logs (DPA §9, 13-month retention) include all tenant.ai_integration.* events.\nSoft-fail UX # AI features never block a PR. If the configured vendor returns an error, hits a rate-limit, exceeds the customer\u0026rsquo;s spend cap, or has an invalid key, the PR review comment is skipped and a warning commit-status renders (\u0026ldquo;AI review unavailable: retry on next push or fix the key\u0026rdquo;). The customer\u0026rsquo;s CI is unaffected; only the AI-generated comment is missing.\nQuestions, audit requests # For compliance reviewers: this page is the deep-linkable trust artefact. The contractual carrier is DPA Annex B §B.8. Questions to compliance@frem.sh.\n","externalUrl":null,"permalink":"/trust/ai-integrations/","section":"Trust","summary":"Effective: 2026-05-24 — fremforge Phase 1 AI integrations\nThe one-line summary # fremforge never sub-processes customer code through a US AI vendor on the default path. The customer brings their own AI vendor key (BYOK) and chooses their own vendor. The vendor is the customer’s own processor under the customer’s own contract, not fremverk’s sub-processor under the Data Processing Agreement.\n","title":"AI integrations — data path and sovereignty","type":"trust"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":" title: Data Protection Impact Assessment — audit-stream and authentication-monitoring processing controller: fremverk ApS, CVR 39150689 dpo_role: not designated under GDPR Art. 37 — role-equivalent privacy-contact mailbox is compliance@frem.sh (per ROPA + Product Privacy Notice §2 / §2 — DPO assessment) date: 2026-05-25 version: 1.2 status: in force related:\ndpa.md §8.5 ropa.md §2.5 controller-incident-response.md sla.md stack.md (architecture baseline) review_cadence: every 12 months, or on material change to the processing next_review: 2027-05-08 Summary # This Data Protection Impact Assessment (\u0026ldquo;DPIA\u0026rdquo;) covers fremverk\u0026rsquo;s audit-stream and authentication-monitoring processing as documented in ROPA §2.5 and DPA Annex A.7. It is conducted under GDPR Art. 35.\nConclusion: the processing is subject to a DPIA on the precautionary reading of Datatilsynet\u0026rsquo;s DPIA list (2018, updated 2024) — specifically item 5 (systematic monitoring of users on a large scale where the controller cannot exclude that the monitoring crosses the criterion threshold). After the mitigations documented in §5 below, the residual risk to the rights and freedoms of natural persons is low, and prior consultation with Datatilsynet under GDPR Art. 36 is not required.\nThe two key mitigations on top of the existing TOMs (Annex A.7):\nRetention split — customer-tunable hot tier + 3-year WORM chain. Security-relevant audit events (authentication, authorisation, admin actions) are retained in payload form for a per-tenant window of 90 / 180 / 365 / 730 days (default 90 days for standard plan; 365 days for enterprise plans; the Customer tenant admin selects the tier at Authentication policy → Audit log retention; the CHECK constraint at migration 0146 enforces BETWEEN 1 AND 730). Thereafter the per-event PII payload is redacted by an automated retention reaper, but the cryptographic hash chain over the original event metadata is retained for the full 3-year WORM-anchored integrity window. After the hot-tier cutoff, no actor IP, no user-agent string, no session-id, and no fields_json content is recoverable from primary storage; only the per-tenant chain hash + chain-position metadata remain. The chain hashes are mathematically irreversible (SHA-256 over a canonicalised input) and provide tamper-detection without re-identification. The worst-case retention scenario is 730 days; the Art-6(1)(f) balancing in §3 has been re-run at that bound and the residual-risk score in §6 reflects the worst-case (see v1.2 change-log). DPIA-driven scope ceiling — the content of audit events is restricted to event metadata; repository content, file diffs, branch contents, and Git-data-plane payloads are explicitly out of scope and never written to the audit stream. This boundary is enforced at the audit-emit layer (audit-emit.ts) and pinned by tests. 1. Description of the processing # 1.1 Nature # fremverk operates fremforge, an EU-sovereign Git/CI/CD platform. As an integral part of the service, every state-changing action (sign-in, MFA challenge, OIDC callback, admin-console action, push-protection rejection, secret-scan result, tenant suspend/cancel, runner-job start/finish, etc.) is recorded as an audit event.\nEach audit event is:\nPersisted to a per-tenant append-only audit_events table in the primary RDS PostgreSQL instance. Hash-chained — hash = SHA-256(canonicalised(prev_hash, tenant_id, actor, action, fields_json, created_at)) — so any retroactive modification of a single row breaks chain continuity. Anchored to a WORM-locked OBS bucket every 2 minutes — the anchor is (tenant_id, latest_chain_hash, count, ts). Object Lock COMPLIANCE-mode prevents tamper-with-or-delete inside the 3-year retention. Streamed in parallel to T Cloud LTS for hot-tier observability (operator on-call dashboards), partitioned per tenant. 1.2 Scope # Dimension In scope Out of scope Subject categories End-users (developers, admins, billing contacts) of fremforge tenants; staff operators of fremverk Visitors of the public marketing website (separate, no audit chain) Data categories Event metadata: actor identifier, action verb, structured fields (fields_json), prev/next chain hashes, timestamps, originating IP Repository content, file diffs, Git data plane, mailbox contents, payment-instrument numbers Volume At full subscriber base (Phase 1 plan: ≤500 tenants × ~30 events/day = ~15k events/day) — Duration Continuous from sign-up; per-tenant on tenant cancellation; 3-year WORM-anchored chain for chain integrity — Geography Processed in T Cloud eu-de (Biere + Magdeburg DE); no cross-border transfers — 1.3 Purposes # Service security (Art. 6(1)(f) — legitimate interest) — detect abuse, breach, intrusion. The audit log is a Tier-1 input to fremverk\u0026rsquo;s intrusion-detection signals. Customer trust (Art. 6(1)(b) — performance of contract) — fremverk markets the auditability and tamper-evidence of the audit chain as a contracted feature; without retention + chain integrity, the contract cannot be performed. Regulatory compliance (Art. 6(1)(c) — legal obligation) — Bogføringsloven §10 requires 5-year retention of accounting records (intersects with billing-related audit events; the 5-year obligation governs that subset, not the full 3-year audit chain). Customer operations (Art. 6(1)(b)) — customer admins use the audit log to trace user actions inside their own tenant. 1.4 Stakeholders consulted # Privacy contact (DPO-equivalent): compliance@frem.sh — routed to the data-protection-responsible partner at fremverk ApS (shj@fremverk.com). No GDPR Art. 37 DPO designation is required (assessment in privacy-product.md §2); compliance@ is the functional equivalent for data-subject communications and supervisory-authority liaison. Conflict-management for the dual-role of privacy contact + incident commander is covered in controller-incident-response.md §\u0026ldquo;Roles\u0026rdquo;. Engineering: shj as solo founder + CTO. Architecture review against the canonical baseline (fremverk/architecture/caf.md). Customers: customer feedback on the contracted audit-trail feature was solicited via the pre-launch waitlist; the response confirmed audit-trail tamper-evidence is a top-3 trust signal. Supervisory authority: not formally consulted at DPIA stage. Per Art. 36, prior consultation is required only if residual risk is high after mitigations; §6 below concludes residual risk is low. 2. Necessity and proportionality # 2.1 Lawful basis # Per §1.3 above. The legitimate-interest balancing test (Art. 6(1)(f)) is documented in §3.\n2.2 Necessity # The processing is strictly necessary for the contracted security and audit-trail features:\nWithout per-event records, there is no way to correlate an intrusion or insider-abuse signal with a concrete user action. Without hash-chaining, an attacker with audit_events write access could rewrite history; the chain protects against insider tampering as well as external compromise. Without WORM-anchoring, a sufficiently privileged attacker could rewrite the entire chain consistently. The WORM anchor is the trust boundary that closes that gap. Lower-impact alternatives considered + rejected:\nNo audit log — incompatible with the contracted audit-trail feature and with the Customer\u0026rsquo;s own GDPR Art. 30 / 32 obligations, which often require a working audit trail at the processor. Audit log without chain integrity — fails the customer-trust purpose and is open to insider-tampering attacks. Audit log without WORM anchor — fails to detect a privileged-attacker full-chain rewrite. Pseudonymise actor on emit — would prevent legitimate operations use (who-did-what correlation across tenants when investigating cross-tenant abuse). The 90-day retention split (§5.1) achieves the equivalent privacy outcome while preserving the operational use during the 90-day investigation window. 2.3 Proportionality # The processing is limited to what is necessary:\nData minimisation: event metadata only — no repository content, no file diffs, no payment-instrument data, no support-correspondence content. Purpose limitation: the audit log feeds the security on-call dashboards and the customer-facing audit endpoint. It is not used for marketing, profiling, or any decision affecting data-subject rights beyond the contracted security purpose. Storage limitation: 90-day hot retention of payload (§5.1); 3-year WORM-anchored chain hashes (irreversible, no PII content); 5-year retention only for the accounting subset that Bogføringsloven §10 mandates. Accuracy: events are immutable on emit; corrections happen by emitting a new event referencing the prior, never by updating in place. 3. Article 6(1)(f) balancing test # 3.1 fremverk\u0026rsquo;s legitimate interest # Operating a security-monitored, audit-evidenced Git/CI/CD platform. Without the processing, fremverk cannot meet its DPA Annex A.7 commitments to Customers nor honour its Art. 32 GDPR security obligations.\n3.2 Necessity # See §2.2.\n3.3 Data subjects\u0026rsquo; rights and freedoms # The data subjects are:\nCustomer end-users (developers, admins, billing contacts): they have a reasonable expectation that their actions on a Git/CI/CD platform are logged for security purposes. The audit-trail feature is contracted at the Customer level (the Customer is a Controller of its end-users for this processing) and is a routine SaaS feature. fremverk staff operators: they have a reasonable expectation that operator-console actions are logged; this is documented in the staff handbook as a condition of access. 3.4 Risks # Risk Severity (1–5) Likelihood (1–5) Net Re-identification from actor field 4 3 12 Tracking of user behaviour via fields_json correlation 3 3 9 Unauthorised access by fremverk staff 4 2 8 Compromise of WORM bucket leading to chain replay 5 1 5 Sub-processor (T Cloud) law-enforcement disclosure 4 1 4 Long-term retention beyond necessity 3 3 9 (See §5 for mitigations.)\n3.5 Balancing outcome # After the §5 mitigations, fremverk\u0026rsquo;s legitimate interest is not overridden by the data subjects\u0026rsquo; rights and freedoms. The audit-log feature is the routine industry expectation for the service category; the 90-day payload-retention cap brings the privacy posture below the typical SaaS-audit-log baseline; the WORM anchor protects subjects against insider tampering of the log itself; and the residual chain hashes are mathematically irreversible.\n4. Risk assessment # The risks identified in §3.4 are evaluated qualitatively. Severity scale: 1 = trivial, 5 = catastrophic. Likelihood: 1 = remote, 5 = ongoing.\n4.1 Re-identification from actor field — net 12 # The actor field stores a username, an OIDC subject, or an api-token id. For 90 days hot, this field is recoverable; combined with the action + fields_json, an attacker with read access could profile a user\u0026rsquo;s activity pattern.\n4.2 Tracking via fields_json correlation — net 9 # fields_json contains structured event-specific data. Some fields are user-supplied (commit messages in push-protection events); others are system-generated (rule_id, repo_full_name). Cross-event correlation could profile user behaviour beyond the event-by-event meaning.\n4.3 Unauthorised access by fremverk staff — net 8 # Staff operators have read access to the audit stream for incident-response purposes. Unauthorised access — staff reading the log outside an active incident — would be a Class A breach per controller-incident-response.md.\n4.4 Compromise of WORM bucket — net 5 # OBS Object Lock COMPLIANCE-mode prevents tamper-with-or-delete inside the 3-year retention. A successful attack on the WORM bucket would require T Cloud account-takeover at root-AK level; mitigated by bootstrap.md §1.2 (root AK on operator laptop, mode 600, never echoed to chat or logs, rotated quarterly via OTC console).\n4.5 Sub-processor (T Cloud) law-enforcement disclosure — net 4 # T Cloud is operated by Deutsche Telekom AG, a German entity with no US parent. Any law-enforcement disclosure is governed by German + EU law; the CLOUD Act has no extraterritorial reach. Documented in DPA §10 and the trust page.\n4.6 Long-term retention beyond necessity — net 9 # Without the retention split, payload would be retained for 3 years; the §5.1 mitigation reduces this to 90 days hot for payload. The 5-year accounting subset (Bogføringsloven §10) is unavoidable but is narrowly scoped to billing-related events.\n5. Mitigations # 5.1 Retention split (primary mitigation — closes risks 4.1, 4.2, 4.6) # Hot tier (0 — per-tenant cutoff N days): full event payload — actor, action, fields_json, prev_hash, hash. The cutoff N is set at Authentication policy → Audit log retention with presets {90, 180, 365, 730}; defaults 90 (standard) or 365 (enterprise). Used for security on-call investigations, customer-facing audit-log queries, and the per-tenant audit-integrity verifier.\nArchive tier (N days – 3 years): per-event row with payload_redacted_at = \u0026lt;cutoff\u0026gt; set; actor replaced with the sentinel \u0026quot;redacted\u0026quot;; fields_json replaced with {}. The hash and prev_hash columns are unchanged — chain integrity is preserved. The chain walk recognises payload-redacted rows and counts them as a verified-redaction sentinel rather than a tamper, mirroring the existing tenant_erased_at semantics in audit-emit.ts.\nCustomer setting below plan SLA floor (yes-by-design). The admin UI does not enforce the contractual SLA floor (enterprise = 365d). A tenant admin may set the hot-tier below the plan floor (e.g. 90d on an enterprise tenant); doing so disclaims the contractual queryability commitment for the affected period. This is a deliberate split between the technical permit (database CHECK) and the contractual constraint (SLA). The DSAR-fulfilment surface returns the redacted row when queried past the chosen cutoff.\nImplementation status: shipped 2026-05-06. Daily /jobs/audit-payload-reaper cron in the monolith api runs the redaction batch — 5000 rows per UPDATE, up to 50 batches per run (250k row/day cap, picks up backlog over consecutive days). Migration 0031 added payload_redacted_at + partial index. verifyChainWalk recognises payload-redacted rows as a verified-redaction sentinel (same path as tenant_erased_at). The endpoint is appended to the daily api-jobs-cron CCE CronJob (api-jobs-cron.yaml) which fires at 02:30 UTC and runs all /jobs/* endpoints sequentially — applied to fremforge-prd 2026-05-06.\nOutcome: after 90 days, an attacker with audit_events SELECT access can no longer recover actor identifiers, fields_json content, or any payload that supports re-identification. The chain hashes remain — these are SHA-256 outputs over canonicalised inputs and are mathematically irreversible without the original inputs (which have been redacted).\n5.2 Sub-event scope ceiling (closes risk 4.2) # fields_json is restricted at emit time to a documented allow-list of fields per action — see the action-schema map in audit-emit.ts. Free-form user content (commit messages, file content, comment bodies) is NEVER serialised into fields_json; only structural metadata (rule_id, repo_full_name, override-reason-category) is.\n5.3 Access controls (closes risk 4.3) # Staff read access to audit_events is via the operator console, not direct SQL — every read produces its own audit event (operator.audit_log.read). The reads are themselves auditable. The api-runtime DB role has SELECT on audit_events (needed for /audit/integrity) but no INSERT/UPDATE/DELETE outside the emit code path. The retention reaper (when shipped) will run as its own DB role with UPDATE on audit_events only for actor + fields_json columns + payload_redacted_at, no other columns. 5.4 WORM lock + KMS (closes risk 4.4) # OBS Object Lock COMPLIANCE-mode on the audit-anchor bucket; 3-year retention configured at bucket-creation time and applied at the version level. Bucket-side KMS encryption with a fremverk-owned DEW CMK (annual rotation enabled). Bucket policy restricts s3:DeleteObject and s3:DeleteObjectVersion to no principal — even root cannot delete inside the lock period. 5.5 Sub-processor controls (closes risk 4.5) # T Cloud is bound by DPA Annex B sub-processor terms, the standard contractual clauses inside the EU, and the BSI C5 Type 2 audit. Law-enforcement requests are governed by the Bundesgesetzbuch and EU GDPR.\n5.6 Data-subject rights (closes risk 4.6 supplementary) # Right of access (Art. 15): Customer admins can export their tenant\u0026rsquo;s audit log via the public REST API (GET /api/v1/orgs/:slug/audit); end-users request via their Customer admin per DPA §6. Right to erasure (Art. 17): tenant cancellation triggers physical-purge at T+90d (P0-11); audit-event PII is pseudonymised at that point via the existing tenant_erased_at flow (migration 0025). Right to object (Art. 21): not applicable to this processing — the audit log is necessary for the contract per Art. 6(1)(b) and for legitimate interest per Art. 6(1)(f); it is not opt-out by design (a service that can opt out of audit logging is not the contracted service). Right to portability (Art. 20): covered by the same /api/v1/orgs/:slug/audit export endpoint, which returns NDJSON. 6. Residual risk # Original risk Mitigation Residual severity Residual likelihood Residual net Re-identification from actor (4.1) §5.1 retention split 2 2 4 Tracking via fields_json (4.2) §5.1 + §5.2 scope ceiling 2 2 4 Unauthorised staff access (4.3) §5.3 access controls + Class A runbook 3 1 3 WORM compromise (4.4) §5.4 Object Lock + KMS 4 1 4 LE disclosure (4.5) §5.5 EU-only sub-processor 3 1 3 Long-term retention (4.6) §5.1 retention split 2 2 4 All residuals are at \u0026ldquo;low\u0026rdquo; (≤ net 4). Under Datatilsynet guidance, prior consultation under Art. 36 is required only when residual risk remains high — which it does not here. fremverk has therefore not formally consulted Datatilsynet on this DPIA; the DPIA itself, the documented mitigations, and the Art. 33-class incident-response runbook (controller-incident-response.md) are the operational compliance posture.\n7. Outstanding items # Annual review — calendared for 2027-05-06 per the frontmatter next_review. 7A. Review cadence (P2-LEG-28) # This DPIA reviews on the cadence in the front-matter (every 12 months, or on material change to the processing). The list below enumerates what counts as a \u0026ldquo;material change\u0026rdquo; — a non-exhaustive set of trigger conditions that fire an early review. The 12-month annual review proceeds in parallel; an early-review version increment does not reset the annual clock.\nTrigger Reviewer Outcome shape New category of personal data added to audit_events.fields_json (beyond the documented set in §1.4) DPO Either narrow the schema, or re-run §3 balancing + §4 risk against the new shape and version-bump New audit-event consumer added on the read side (e.g., a CES alarm that surfaces audit-event fields to a third-party SaaS) Compliance Officer Re-evaluate §5.2 scope ceiling; reject if it crosses the disclosed boundary Retention-tier change (90-day hot, 30-day operational, 3-year WORM) Compliance Officer + Controller Re-run §3 balancing; coordinate with DPA §A.7 version bump Anchor cadence change (current 2-min — see DSA tamper-window closure) Compliance Officer Re-evaluate the integrity-risk calculation in §4; update DPA §A.7 + audit-chain customer doc cadence references in lock-step Sub-processor change on the audit-stream path (LTS, OBS, KMS) Compliance Officer + Controller Triggers a sub-processor change-notification under DPA §10 AND a DPIA version bump Cross-border transfer activated (e.g., support flow that exposes an audit-stream to a non-EU support contractor) Compliance Officer + external counsel Out-of-scope for the current low-risk posture; activation requires re-running the DPIA from scratch and may require Art. 36 consultation with Datatilsynet Datatilsynet guidance update on systematic monitoring (item 5 of the published DPIA list) Compliance Officer Re-read §3 against the updated guidance; version-bump if the analysis changes Customer audit (per DPA §12.1) flags a finding DPO Address in the response; if structural, version-bump A trigger always produces a version bump, even if the review concludes \u0026ldquo;no material change after analysis\u0026rdquo; — the version bump documents that the review fired.\n8. Sign-off # Role Name Date Sign-off Data Protection Officer shj@fremverk.com 2026-05-06 Reviewed and approved. Residual risk: low. Prior consultation under Art. 36 not required. Controller fremverk ApS, CVR 39150689 2026-05-06 Approved for production processing. 9. Change-log # Version Date Author Change 1.0 2026-05-06 shj Initial DPIA. Closes audit finding P0-13. Documents the retention-split mitigation (§5.1) and scope ceiling (§5.2). Implements Datatilsynet\u0026rsquo;s DPIA list (item 5) precautionary reading. Residual risk: low; no Art. 36 consultation required. 1.1 2026-05-08 shj §1 anchor cadence updated 5min→2min in the audit-event flow (mirrors DPA §A.7 + cronjob change in P0-DSA-TAMPER-WINDOW). New §7A \u0026ldquo;Review cadence\u0026rdquo; enumerates 8 trigger conditions for an early review (P2-LEG-28). Residual risk unchanged: low; no Art. 36 consultation required. 1.2 2026-05-25 shj §1, §5.1: retention-split widened from a fixed 90-day hot tier to a customer-tunable {90, 180, 365, 730}-day hot tier (default 90 standard / 365 enterprise). Reflects P0-AUDIT-RETENTION-TIER shipped 2026-05-24 (migrations 0144 + 0146; route at admin-auth-policy.tsx:61). §3 Art-6(1)(f) balancing re-run with 730-day worst-case bound; §6 residual-risk score re-evaluated; risk 4.6 (long-term retention beyond necessity) remains low because (a) the customer chooses the window and is responsible for the necessity assessment per Art-5(1)(c), (b) the hash chain is mathematically irreversible after redaction, (c) the WORM tier carries no payload PII. §5.1 also documents the \u0026ldquo;set below plan floor\u0026rdquo; yes-by-design split between database CHECK (1–730d) and SLA-contractual minimum (365d for enterprise). No Art. 36 consultation required. ","externalUrl":null,"permalink":"/legal/dpia-audit-monitoring/","section":"Legal documents","summary":" title: Data Protection Impact Assessment — audit-stream and authentication-monitoring processing controller: fremverk ApS, CVR 39150689 dpo_role: not designated under GDPR Art. 37 — role-equivalent privacy-contact mailbox is compliance@frem.sh (per ROPA + Product Privacy Notice §2 / §2 — DPO assessment) date: 2026-05-25 version: 1.2 status: in force related:\n","title":"DPIA — Audit Monitoring","type":"legal"},{"content":"","externalUrl":null,"permalink":"/","section":"fremforge","summary":"","title":"fremforge","type":"page"},{"content":" title: fremforge Acceptable Use Policy author: fremverk date: 2026-05-25 status: Published v1.2 version: \u0026ldquo;1.2\u0026rdquo; lang: en # Last updated: 2026-05-25\nEffective Date: 2026-05-19 — Version: 1.1\nThis Acceptable Use Policy (\u0026ldquo;AUP\u0026rdquo;) forms part of the agreement between fremverk ApS (\u0026ldquo;fremverk\u0026rdquo;, \u0026ldquo;we\u0026rdquo;) and the customer organisation (\u0026ldquo;Customer\u0026rdquo;, \u0026ldquo;you\u0026rdquo;) that subscribes to the fremforge Service at frem.sh. In case of conflict between this AUP and the Terms of Service, the order of precedence in Terms of Service §22 governs. The AUP supplements the Terms of Service and the Data Processing Agreement; it does not override them.\n1. Scope and intent # fremforge is a commercial, multi-tenant EU-sovereign Git and CI/CD hosting service. It is provided in good faith for lawful software engineering use. The purpose of this AUP is to:\nDefine the conduct and content that is not permitted on the Service. Describe the procedures by which fremverk and third parties may report abuse. Explain the enforcement actions fremverk may take, and the Customer\u0026rsquo;s rights of appeal. Discharge fremverk\u0026rsquo;s obligations under the EU Digital Services Act (DSA), the General Data Protection Regulation (GDPR), and Danish law. This AUP applies to every user authorised by the Customer to use the Service (members, administrators, and owners of a Customer organisation), to any AI agent acting on behalf of such a user under a delegated mandate (see §12), and to any visitor accessing public content hosted on the Service where the Customer has enabled public repositories.\n2. Lawful use # You may use fremforge only for lawful purposes and in accordance with this AUP, the Terms of Service (ToS), and all applicable EU, Danish, and — where relevant to your use — local laws. You may not use the Service in any way that would cause fremverk to violate a law or regulation it is subject to.\n3. Prohibited content and activity # The following content and activity are prohibited on fremforge. The list is illustrative, not exhaustive.\n3.1 Illegal content # Child sexual abuse material (CSAM). Any suspected CSAM is immediately reported to the competent authority — the Danish National Police\u0026rsquo;s National Cyber Crime Centre (NC3, nc3@politi.dk) and Red Barnet\u0026rsquo;s AnmeldDet hotline (anmelddet.dk) for parallel notification — per Danish law and the EU regulation on combating child sexual abuse material; the responsible org is suspended without prior notice. Content that incites terrorism, genocide, or violence against an identifiable person or group. Content that infringes the copyright, trademark, or other intellectual property rights of a third party, where a valid takedown request has been received. Content that contains personal data and that the data subject has, through the Customer\u0026rsquo;s controller-side process, validly requested be erased — or that a competent supervisory authority has ordered erased. (Note: fremverk acts as processor here; data subjects address Customer first per DPA §7. fremverk acts directly only on an order from a competent supervisory authority.) Content that violates applicable export controls (EU dual-use regulation, national sanctions regimes). 3.2 Malicious software and content # Distribution of malware, ransomware, spyware, rootkits, botnets, command-and-control or beaconing infrastructure, or functionally equivalent code intended to compromise systems you do not own or have authorization to compromise. Repositories that contain security research, proof-of-concept exploits, or defensive tooling are permitted when clearly labelled, responsibly disclosed, and not being actively weaponised. Phishing kits, credential-harvesting tools, or fraud infrastructure intended for deployment against third parties. Code or artifacts whose primary purpose is to bypass platform security controls — for example, scripts whose purpose is to evade fremforge\u0026rsquo;s rate limiters, secret scanners, or abuse controls. 3.3 Abuse of shared infrastructure # Cryptocurrency mining, sustained proof-of-work hashing, or other computation whose principal purpose is to generate cryptocurrency or similar digital assets. This is prohibited on both hosted runners and bring-your-own runners integrated into the Service. Cryptocurrency mining is the primary abuse vector for CI-included services and is treated as a bright line, not a case-by-case judgement. Limited unit / integration tests of validator or consensus-protocol software (e.g., proof-of-stake validator code under test) within ordinary CI build/test minutes are not prohibited; the rule targets the production operation of consensus participation, not its development. Using fremforge or its CI runners as a proxy, VPN endpoint, general-purpose hosting for external services, or as a compute resource for workloads unrelated to software development, build, test, or deployment for the Customer\u0026rsquo;s own projects. Sustained distributed denial-of-service activity launched from runners or from Git operations against the Service or third parties. Network scanning, port scanning, or unauthorized probing of third-party infrastructure from runners. Systematically exceeding the fair-use concurrency limit published at frem.sh/pricing (currently 2 concurrent jobs per seat, max 100 per organisation on the standard plan; Enterprise-on-Demand customers may negotiate a higher cap) without prior written agreement. Occasional bursts are normal; sustained patterns of hundreds of concurrent jobs against the fair-use ceiling are not. Circumventing seat metering, storage quotas, or egress caps by design (e.g., creating sockpuppet organisations, coordinated-team abuse across multiple organisations). 3.4 Security-critical prohibitions (non-negotiable) # Attempting to compromise fremforge infrastructure, other tenants\u0026rsquo; data, or the authentication, authorisation, or audit systems of the Service, except as authorised under a responsible-disclosure submission to security@frem.sh. Attempting to disable or bypass the platform-floor controls that cannot be disabled by tenant administrators: high-confidence pre-receive secret scanning, mandatory TLS, audit logging, and the SSRF outbound-proxy filter. Extracting other tenants\u0026rsquo; data through any means — the tenant-isolation controls are security guarantees, not technical suggestions. 3.5 Spam, harassment, and deceptive practices # Using issues, pull requests, wiki pages, or package registries to host content unrelated to software development (spam, SEO backlink farms, bulk promotional content). Targeted harassment of individuals or groups — on public repositories, on private repositories where the recipient is a Customer user, or via abuse of the issue/comment systems. Impersonation of fremverk, fremforge, or any other person or organisation. Publishing private information of third parties (\u0026ldquo;doxxing\u0026rdquo;) without a lawful basis. 3.6 Public-repository-specific restrictions # The Customer may enable public repositories within an organisation. When public repositories are enabled, additional constraints apply:\nAll content on public repositories must comply with §3.1–3.5 above, and the Customer organisation is treated as responsible for that content as a \u0026ldquo;hosting service provider\u0026rdquo; under the DSA. The fair-use limits in §4 (1,000 minutes/seat/month, 2 concurrent jobs/seat, max 100/org) are enforced strictly for any organisation that hosts one or more public repositories. Public repos are the primary abuse vector for runner-based cryptocurrency mining; sustained operation at or near the ceiling triggers review and may result in temporary throttling pending verification of the workload\u0026rsquo;s legitimacy. Public repositories must not be used to distribute software or data subject to export controls outside the permitted jurisdiction. fremverk reserves the right to restrict the public-repo feature for an organisation without prior notice where abuse patterns indicate coordinated mining, spam, or similar platform-level harm. 3.6A Public-docs wiki — anonymous read on private repos # The Customer may opt in, per repository, to anonymous public read of the repository wiki at frem.sh/\u0026lt;org\u0026gt;/\u0026lt;repo\u0026gt;/wiki[/...] independent of whether the underlying repository is public or private. When this opt-in is set, the same DSA \u0026ldquo;hosting service provider\u0026rdquo; framing in §3.6 above applies to the wiki content even though the repository itself may remain private:\nAll wiki content rendered on the anonymous read path must comply with §3.1–3.5; the Customer is responsible for that content as a hosting-service-provider under the DSA. The Customer may embed presentation customisation via a per-repo custom_css field (8 KB textarea). The customer accepts that the CSS is served verbatim to anonymous visitors of the public-docs wiki. fremverk performs write-time and render-time sanitisation against \u0026lt; byte injection but does not block CSS-level data exfiltration vectors (e.g. background-image: url(https://tracker.example/...)); the customer is responsible for the privacy implications of any external URLs they reference from their wiki CSS. Public-docs wiki bandwidth counts toward the fair-use ceiling of §4 in the same way as other anonymous read paths. fremverk reserves the right to disable the anonymous-read opt-in on a per-repo basis where abuse patterns indicate coordinated phishing, brand impersonation, or similar platform-level harm. 3.7 No AI training on Customer data # fremverk does not, and does not permit any sub-processor to, use Customer Content, Customer Personal Data, or operational metadata to train, fine-tune, evaluate, or develop AI/ML models. The full prohibition is set out in DPA §6A and is a material term of the contract. This commitment applies to fremverk\u0026rsquo;s own infrastructure and to fremverk-appointed sub-processors. Customer-configured AI vendors (DPA Annex B §B.8) operate under the Customer\u0026rsquo;s own contract with the vendor and are not bound by this commitment — the Customer is responsible for ensuring its chosen AI vendor\u0026rsquo;s terms align with the Customer\u0026rsquo;s own AI-training-data posture.\n4. Hosted CI runner fair use # The fremforge standard plan includes hosted CI minutes and concurrency under a fair-use model:\n1,000 runner minutes per seat per month, pooled at organisation level, overage metered at €0.010/min. 2 concurrent jobs per seat, max 100 per organisation as a soft limit. Occasional bursts beyond the cap (for example, after a large merge) are expected and absorbed; sustained operation above the cap is not included in the standard plan. Global concurrency cap across the entire platform. In the rare case where platform-wide demand exceeds the cap, jobs queue with per-organisation fair-share scheduling. Customers with legitimate needs above these thresholds can contract for dedicated CCI capacity under the Enterprise-on-Demand arrangement. Do not work around the thresholds; contact us.\n5. Reporting abuse (DSA Art. 16 notice-and-action) # fremforge is a hosting service within the meaning of Regulation (EU) 2022/2065 (Digital Services Act). We operate a notice-and-action mechanism that meets the requirements of DSA Art. 16 and is available to any person or entity:\nAbuse contact: abuse@frem.sh\nStructured reporting form: published at https://frem.sh/_app/legal/abuse-report — supplies the fields required under DSA Art. 16(2): identification of the allegedly illegal content (URL or unambiguous indication), reasons it is illegal, the notifier\u0026rsquo;s identity and contact details (anonymous notices are accepted for content categories that don\u0026rsquo;t depend on the notifier\u0026rsquo;s identity), and a good-faith statement. The form posts same-origin to the api, recording the notice into the operator review queue (with a dsa_notice_received LTS log line for operator visibility).\nFirst-response commitment: acknowledgement within 24 business hours of receipt. Decision within 7 calendar days of acknowledgement, absent exceptional circumstances requiring further investigation, in which case we will inform the notifier of the extension.\nDecision types:\nContent removed, user or organisation notified of the removal and the reason. Content restricted (made non-public) pending further investigation. Content left in place, notifier informed of the reason with reference to this AUP, the applicable law, or the absence of a sufficient basis for action. Repeated or egregious violation: account or organisation suspended, with notification and right of appeal. Right of appeal: every decision under this mechanism is subject to internal review on request by the notifier or by the affected user/organisation. An appeal is resolved within 14 days. The outcome of the internal review does not preclude the affected party from pursuing out-of-court dispute resolution under DSA Art. 21 or judicial remedies.\nLaw-enforcement contact: compliance@frem.sh with a 48-hour first-response SLA for formally addressed requests from competent authorities.\nEmergency response: in cases involving imminent risk to life, ongoing child sexual abuse, or other critical situations, we prioritise immediate action over formal process and coordinate directly with the relevant authority.\n5.1 Trusted Flaggers (DSA Art. 22) # Notices submitted by entities designated as Trusted Flaggers by the Digital Services Coordinator under DSA Art. 22 are processed with priority. fremverk maintains an internal register of recognised Trusted Flaggers and publishes the count in the annual transparency report.\n5.2 Intellectual property takedowns # A notice alleging copyright, trademark, or other intellectual-property infringement is a special case within the DSA Art. 16 mechanism and is handled through the same abuse@frem.sh channel. In addition to the general DSA Art. 16 requirements, an IP takedown notice must include, as applicable:\nIdentification of the copyrighted, trademarked, or other protected work alleged to be infringed. Identification of the material that is claimed to be infringing (specific URL or unambiguous locator). A statement that the notifier has a good-faith belief that the use is not authorised by the rights-holder, its agent, or the law. A statement that the information provided is accurate and that the complainant is the rights-holder or authorised to act on the rights-holder\u0026rsquo;s behalf, made subject to liability for false declarations under Danish law (Straffeloven §163 — false declaration to a public authority — applies where the notice is forwarded to a competent court or supervisory authority). Contact details sufficient for fremverk to reach the notifier. Counter-notice: the affected user or organisation may submit a counter-notice through the same channel, containing a statement — subject to liability for false declarations under Danish law (Straffeloven §163, where the matter is forwarded to a competent court or supervisory authority) — that the material was removed as a result of mistake or misidentification, consent to jurisdiction in Denmark, and contact details. On receipt of a valid counter-notice, fremverk notifies the original notifier and, unless the original notifier confirms within 14 days that they have commenced legal action seeking to prevent further infringing use, restores the removed material.\nWhere a notice is later determined to have been fraudulent or made in bad faith, fremverk reverses any restriction applied to Customer Content within 24 hours of the determination and pursues recovery of operational costs from the complainant per DPA §13. The impacted period is treated as in-scope for SLA credit calculation per SLA §7.\nRepeat-infringer policy: consistent with DSA Art. 23, an organisation whose users repeatedly submit content that is the subject of valid and uncontested IP takedown notices is subject to increasing enforcement actions under §7, up to and including termination of the agreement.\nThis IP takedown channel operates alongside, and does not replace, the DSA Art. 16 notice-and-action mechanism for other categories of illegal content.\n6. Transparency reporting # fremverk publishes an annual transparency report per DSA Art. 15 covering the volume, nature, and outcome of notices received, member-state authority orders received, actions taken on its own initiative, and the average time-to-decision. The report is published at www.frem.sh/trust/dsa/ and is reissued annually.\nThe year-1 entry — covering the partial period from launch to 31 December 2026 — is a partial-period statement reflecting that fremforge entered general availability mid-year. DSA Art. 15 explicitly accommodates a \u0026ldquo;we launched and have nothing to report\u0026rdquo; first-year statement; the partial-period framing is not a deferral of the obligation. Subsequent reports cover full calendar years and publish in Q1 of the following year.\nIn addition to Art. 15, fremverk publishes the average monthly active EU recipients of the service at the same URL, refreshed at least every six months, per DSA Art. 24(2). fremforge is below the very-large-online-platform (VLOP) threshold; this metric is published for completeness, not because designation is anticipated.\n7. Enforcement actions # Depending on the severity, pattern, and context of a violation, fremverk may take one or more of the following enforcement actions:\nContent removal or restriction — remove the offending content or make it non-public, retaining a record for audit and appeal purposes. User suspension — suspend the offending user\u0026rsquo;s access across the Service. The organisation administrator is notified and can decide whether to remove the user from the organisation entirely. Organisation throttling — reduce rate limits, pause runner minutes, or temporarily disable public repositories for an organisation whose usage patterns indicate systemic abuse. Organisation suspension — suspend the organisation\u0026rsquo;s access. All users lose access; the data is retained for 60 days to allow export before primary deletion (matches §11 below + DPA §9 — was previously stated as 30 days, which contradicted §11; reconciled per audit P1-57). Immediate termination — for egregious violations (CSAM, coordinated attack on fremforge infrastructure, severe repeated abuse after prior warnings), the contract is terminated immediately with data retained only where legal or regulatory obligations require. Law-enforcement referral — where Danish or EU law requires us to report, or where the violation involves conduct that warrants referral, we refer the matter to the competent authority. Where possible without compromising an active investigation or legal process, we notify the affected organisation administrator before applying a suspension or termination and allow a reasonable period to respond. The right of appeal under §5 applies to all enforcement actions.\nFor non-egregious AUP violations (i.e. violations not posing immediate risk to other Customers, the Service, or third parties), fremverk applies a notice-and-cure sequence: written notice to the Customer\u0026rsquo;s account-of-record administrator describing the violation, followed by a 7 calendar-day cure period. Suspension or termination follows only if the violation is not cured within that period or recurs after cure. Egregious violations (illegal content, active attacks, mass abuse, court-ordered takedowns) may trigger immediate suspension without cure.\n8. Your obligations as an organisation administrator # If you are an administrator of a fremforge organisation, you are responsible for ensuring that your organisation\u0026rsquo;s members use the Service in accordance with this AUP. You must:\nCommunicate the relevant parts of this AUP to members of your organisation. Respond to abuse notices forwarded to you by fremverk within a reasonable time. Not knowingly authorise, direct, or facilitate AUP violations by members of your organisation. Ensure that any AI agent you grant a delegated mandate to (see §12) operates within the scope of this AUP in the same way your human users do. 9. Your obligations as a User # As a user of fremforge, you must:\nComply with this AUP, the ToS, and applicable law. Not share your credentials, OIDC session, or personal access tokens with another person. Report suspected security vulnerabilities to security@frem.sh rather than demonstrate them against live infrastructure (a responsible-disclosure commitment applies — see the trust page for details). Report suspected abuse to abuse@frem.sh. 9A. Vulnerability disclosure # fremverk publishes a vulnerability-disclosure policy at frem.sh/.well-known/security.txt per RFC 9116, with safe-harbour for good-faith research. Third-party penetration test reports, when commissioned, are available to Customers under NDA on written request per DPA §12.1; Enterprise-on-Demand contracts may agree to a specific testing cadence in the Order Form.\n10. Security-patching commitment # fremverk commits to patch security vulnerabilities in the platform within the following CVE patch SLA, which is a standalone contractual commitment under this AUP and is cited verbatim in DPA Annex A:\nCritical (CVSS ≥ 9.0): within 48 hours of upstream fixed release. High (7.0–8.9): within 72 hours. Medium (4.0–6.9): within 7 days. Low: next scheduled maintenance window. Security patches are not deferred to honour a tenant maintenance window. Adherence is published on the trust page. This stance is part of our obligations to you under this AUP and the ToS, not a gift.\n11. Service suspension on non-payment # Non-payment after a reasonable dunning process (typically 30 days from the first failed charge, with at least three notification attempts) results in Service suspension. On suspension, Customer Content is held in read-only-no-egress mode for 60 days from the date of suspension, during which the Customer may cure (pay outstanding Fees) or export. After 60 days without cure, primary deletion follows within a further 30 days, with backup purge complete within an additional 30 days thereafter (per DPA §9 and the staged sequence in the next paragraph) — total time from suspension to backup-purge completion is up to 120 days. This sequence harmonises with terms.md §16.5 (60-day export) and dpa.md §9. This clause is operational and does not affect the enforcement provisions of §7 where a violation has also occurred.\nThe retention sequence depends on whether suspension converts to termination. Two paths, both ending in primary deletion + backup purge — clarified per audit P1-57 (the previous \u0026ldquo;120 days total\u0026rdquo; arithmetic only worked for the non-payment-without-termination path; the termination path is longer):\nNon-payment without termination: (a) suspension hold of 60 days during which Customer Content is read-only-no-egress and the Customer may cure or export (ToS §4.6). If the Customer cures within (a), no further deletion happens. If the Customer never cures and never terminates: (c) post-suspension primary deletion within 30 days of the end of (a); (d) backup purge within a further 30 days. Total: up to 120 days (60 + 30 + 30).\nTermination after suspension: (a) 60-day suspension hold (above), then on termination (b) post-termination export window of 60 days during which the Customer may export Customer Content (ToS §16.5); (c) post-export deletion within 30 days of the end of the export window (DPA §9); (d) backup purge within a further 30 days. The 30-day windows in DPA §9 measure from the end of (b); they do not run concurrently. Total: up to 180 days (60 + 60 + 30 + 30).\n12. AI agents and delegated mandates # Where a user of your organisation authorises an AI agent to act on their behalf under a delegated mandate (the Phase 2+ agent-native access feature — see the AI posture page in the documentation):\nThe mandate is bounded by the authorising user\u0026rsquo;s role. An agent holding a mandate from a Member-role user cannot change organisation policy; an agent holding a mandate from an Admin can, within the scope of the mandate. All actions by the agent are your organisation\u0026rsquo;s responsibility under this AUP in the same way actions by your human users are. An agent violating this AUP is a violation by the organisation, not by an independent third party. Enforcement actions against agents follow the same structure as enforcement actions against users. Revoking a mandate by the authorising user is equivalent to a voluntary suspension of that agent\u0026rsquo;s access. Audit-log transparency: agent actions are recorded with actor=agent:\u0026lt;agent_id\u0026gt;, on_behalf_of=\u0026lt;user_id\u0026gt; so you and fremverk can distinguish them from human actions for compliance and incident review. 13. Changes to this AUP # We may update this AUP to address new abuse patterns, new legal requirements, or clarifications based on operational experience. Material changes are announced at least 30 days in advance on the trust page and via the security mailing list. Emergency updates to address active abuse (for example, a new cryptocurrency-mining pattern requiring a more specific prohibition) may take effect on shorter notice; such changes are limited to the minimum necessary to address the issue and are documented transparently.\n14. Governing law and dispute resolution # This AUP is governed by Danish law. Disputes are subject to the jurisdiction of the competent Danish courts, without prejudice to any mandatory provision protecting consumers (where the Customer is a consumer, which is rare for fremforge as a B2B service) or to out-of-court dispute resolution mechanisms available under DSA Art. 21.\n15. Contact # Abuse reports: abuse@frem.sh (24h first response) Law enforcement: compliance@frem.sh (48h first response) Security vulnerabilities: security@frem.sh General support: support@frem.sh Change log # Version Date Change 1.0 2026-04-25 Initial publication. 1.1 2026-05-19 §3.6 + §4: concurrency limit clarified from \u0026ldquo;5 concurrent jobs per organisation\u0026rdquo; to \u0026ldquo;2 concurrent jobs per seat, max 100 per organisation\u0026rdquo;. Brings AUP into alignment with the /pricing and /product pages — the previous wording had been superseded by the per-seat metering model. Enterprise-on-Demand customers may negotiate a higher cap. Pre-launch (no paying customers), so no DPA §14 customer notification cycle required. ","externalUrl":null,"permalink":"/legal/aup/","section":"Legal documents","summary":" title: fremforge Acceptable Use Policy author: fremverk date: 2026-05-25 status: Published v1.2 version: “1.2” lang: en # Last updated: 2026-05-25\n","title":"fremforge Acceptable Use Policy","type":"legal"},{"content":" title: fremforge Cookie Policy author: fremverk date: 2026-05-25 status: Published v1.1 version: \u0026ldquo;1.1\u0026rdquo; lang: en # Last updated: 2026-05-25\nEffective Date: 2026-04-25 — Version: 1.0\nThis cookie policy is a companion to the fremforge Product Privacy Notice. The privacy notice is the primary GDPR document; this policy provides the detail on cookies and browser storage specifically.\n1. Purpose # The ePrivacy Directive (Directive 2002/58/EC, as amended) and its national implementations require a clear disclosure of cookies and similar technologies used on a service, and consent for any cookie that is not strictly necessary. This policy documents every cookie fremforge sets, its purpose, its class under Art. 5(3), and its lifetime — so the absence of a cookie banner on the service is a verifiable commitment rather than an omission.\n2. Our posture in one line # fremforge sets only strictly-necessary cookies on authenticated product surfaces, and zero cookies on marketing, docs, status, and anonymous pages. No consent banner needed — not because we hid the question, but because we don\u0026rsquo;t set cookies that would require consent.\nThis stance is surfaced verbatim on the trust page and is a deliberate product commitment, not a compliance minimum. If our cookie usage ever changes in a way that would require consent, we will implement a proper consent flow before setting any such cookie — we will not silently expand the inventory.\n3. Surfaces covered # Surface Domain Cookies set Third-party calls Marketing site www.frem.sh None None Documentation docs.frem.sh None None Status page status.frem.sh None None Product — Forgejo UI and Git / API / registry frem.sh/* (authenticated) Four strictly-necessary cookies (see §4) None fremforge admin UI frem.sh/_app/\u0026lt;slug\u0026gt;/_admin/* (per-tenant, authenticated; URL Option B per plan.md) Inherits the product-surface cookies above None Public-docs wiki (tenant-opt-in) frem.sh/\u0026lt;org\u0026gt;/\u0026lt;repo\u0026gt;/wiki[/...] (anonymous read path) None — anonymous read path; no cookies set Customer-controlled (tenant-supplied custom_css may reference external URLs — the tenant Customer is responsible for the privacy implications of those references) Brand-redirect domains fremforge.com, fremforge.eu, fremforge.dk (with and without www.) None — 301 to www.frem.sh None All four strictly-necessary cookies on the product surface are set by the first-party origin (frem.sh). None are third-party cookies. No analytics providers, advertising networks, or session-replay tools are loaded on any fremforge surface.\nThe fremforge admin UI ships no client-side analytics, no error monitoring (Sentry/Bugsnag/etc.), no session replay, and no behavioural telemetry. Server-side error logs are routed to T Cloud LTS in eu-de and never leave the EEA. The only cookies the admin UI sets are the strictly-necessary cookies listed in §4.\n4. Strictly-necessary cookies (authenticated product surface) # These four cookies are strictly necessary under ePrivacy Directive Art. 5(3) because they are \u0026ldquo;strictly necessary for the provision of an information society service explicitly requested by the subscriber or user.\u0026rdquo; They do not require consent.\nCookie Set by Purpose Class First-party Lifetime Scope session Forgejo Authenticated session state — identifies your login Strictly necessary Yes Session (cleared on browser close) frem.sh _csrf Forgejo Cross-Site Request Forgery protection token Strictly necessary Yes Session (cleared on browser close) frem.sh lang Forgejo Set only when the user actively changes the language; the cookie remembers the user\u0026rsquo;s expressed choice. Persistence is necessary because the user\u0026rsquo;s selection would otherwise be lost on every visit, defeating the explicit action. The cookie carries no identifier, no profile, and no cross-session tracker. Lifetime: 12 months. Strictly-necessary classification per Recital 25 (now reflected in ePrivacy Art. 5(3) exemption) for user-action-driven preference cookies. Strictly necessary Yes 12 months frem.sh fremforge middleware session fremforge control plane Per-org session binding — enforces that a session authenticated for Org A cannot act against Org B\u0026rsquo;s URL space Strictly necessary Yes 8 hours rolling frem.sh Why each is strictly necessary # session: without this cookie the Forgejo forge cannot tell if you are signed in. It is the fundamental authentication cookie (cookie name in Forgejo 15+; earlier releases shipped the historical i_like_gitea name from the Gitea-origin codebase). _csrf: without this cookie, your form submissions and API writes can be forged by any other site you visit. CSRF protection is a baseline web-security control. lang: without this cookie, every page load reverts to the default language and the language switcher you used has no effect. ePrivacy Directive Recital 25 treats user-preference cookies set in response to explicit user action as strictly necessary; this falls within that scope. fremforge middleware session: without this cookie, per-org session binding (the control that prevents a session obtained under one tenant\u0026rsquo;s identity provider from acting on another tenant\u0026rsquo;s data) cannot be enforced. Per-org binding is the security architecture that allows shared-tenant deployment of fremforge to be secure; removing the cookie would weaken the security model in a way fremforge is not willing to accept. 5. Browser local storage # The product surface may use the browser\u0026rsquo;s localStorage API to remember UI preferences you explicitly set in the fremforge admin UI — such as theme (light/dark), table density, or collapsed-panel state. Local storage entries are written only in direct response to your action in the UI. They are never used for analytics, advertising, cross-site tracking, or identification. You can clear them at any time via your browser\u0026rsquo;s storage inspector.\n6. Third-party cookies — none # We do not embed third-party cookies on any fremforge surface. Specifically:\nNo analytics providers (no Google Analytics, no Plausible-hosted, no Matomo-hosted, no Amplitude, no Mixpanel). No advertising networks. No session-replay tools (no Hotjar, no FullStory, no LogRocket). No embedded third-party widgets (no chat, no social-share buttons, no embedded videos) on authenticated surfaces. No CDN-loaded fonts or scripts from Google Fonts, jsDelivr, unpkg, or similar. No Gravatar — Forgejo\u0026rsquo;s default federated-avatar fetch to gravatar.com is disabled at the fremforge configuration level ([picture] DISABLE_GRAVATAR = true, ENABLE_FEDERATED_AVATAR = false). Avatars are stored locally. No external image proxies that leak cookies — the markdown image proxy is routed through the fremforge outbound-proxy with SSRF hardening (described on the trust page), which prevents third-party cookies from reaching your browser via proxied images. No third-party bot-mitigation widgets: the private-beta signup form uses no captcha — abuse is contained server-side via a honeypot field, a minimum-dwell-time check, per-IP throttling at the API gateway, and edge WAF. The Forgejo tenant signup form and rate-limited login-discover use self-hosted Altcha (MIT-licensed, HMAC-signed proof-of-work) served in-app from frem.sh/_app/altcha/challenge with the widget bundle at frem.sh/_app/static/altcha.js — no third-party widget JS, no external sub-processor, no separate origin. Cloudflare Turnstile, hCaptcha, and reCAPTCHA were considered and rejected on sovereignty grounds.\nIf we ever introduce a third-party integration that would set cookies on your browser (for example, a customer-initiated Slack or Teams webhook that redirects through a third-party auth flow), it will be gated behind explicit consent at the point of initiation — never silently.\n7. OIDC and SAML sign-in to your identity provider # When you sign in to fremforge via your organisation\u0026rsquo;s identity provider (Entra ID, Okta, Authentik, Keycloak, or similar), your browser will be redirected to your identity provider\u0026rsquo;s domain, which may set cookies on its own domain as part of its authentication flow. Those cookies are set by your identity provider, not by fremforge, and are governed by your identity provider\u0026rsquo;s privacy policy — not this cookie policy.\nYour fremforge session cookie (session) is issued by frem.sh after the identity provider returns you with a valid assertion. Your identity provider\u0026rsquo;s cookies remain on your identity provider\u0026rsquo;s domain and are not accessible to frem.sh.\n8. What changes if you disable cookies in your browser # If you disable all cookies on frem.sh in your browser, you will not be able to sign in to fremforge. There is no degraded \u0026ldquo;anonymous mode\u0026rdquo; for the authenticated product — sign-in requires the session and CSRF cookies above to function.\nwww.frem.sh, docs.frem.sh, and status.frem.sh remain fully functional with all cookies disabled, because they do not set any cookies.\n9. Verifying this policy yourself # You can verify every claim in this policy using your browser\u0026rsquo;s developer tools:\nOpen a private / incognito window (to start from a clean state). Navigate to www.frem.sh, docs.frem.sh, or status.frem.sh. Open Developer Tools → Application → Cookies. Expect an empty list. Open Developer Tools → Network. Expect no third-party requests (only requests to the site\u0026rsquo;s own origin or the Bunny CDN origin). Sign in to a fremforge organisation at frem.sh/\u0026lt;org\u0026gt;. Re-inspect cookies. Expect exactly the four cookies listed in §4, all first-party on frem.sh. If you find a cookie, tracker, or third-party call that is not documented in this policy, please report it to compliance@frem.sh — we treat undocumented tracking as a material deviation from our product commitments and will fix it or update this policy to reflect reality, whichever is correct.\n10. Your rights and choices # Browser cookie controls: every major browser (Chrome, Firefox, Safari, Edge, Brave) lets you view, edit, and delete cookies per site. fremforge honors these controls — we do not use any storage mechanism designed to evade browser cookie deletion (no ETag tracking, no canvas fingerprinting, no localStorage-as-cookie fallback). GDPR data-subject rights: see §7 of the product privacy notice for access, rectification, erasure, and related rights. Cookie data is included within the scope of those rights to the extent it contains personal data linked to your account. Supervisory authority: Datatilsynet (Denmark) per the privacy notice. 11. Changes to this policy # We may update this cookie policy to reflect changes in the cookies or browser storage used. Material changes will be announced on the trust page and on the security mailing list, and — for any change that would introduce a cookie requiring consent — with a proper consent flow implemented before the cookie is set for the first time on any user.\nThe date at the top of this page reflects the last meaningful content change. Prior versions are retained in Git.\n12. Contact # Cookie and privacy questions: compliance@frem.sh.\nChange log # Version Date Change 1.0 2026-04-25 Initial publication. ","externalUrl":null,"permalink":"/legal/cookie-policy/","section":"Legal documents","summary":" title: fremforge Cookie Policy author: fremverk date: 2026-05-25 status: Published v1.1 version: “1.1” lang: en # Last updated: 2026-05-25\n","title":"fremforge Cookie Policy","type":"legal"},{"content":" title: fremforge Data Processing Agreement author: fremverk date: 2026-05-25 status: Published v1.14 version: \u0026ldquo;1.15\u0026rdquo; lang: en # Last updated: 2026-05-25\nEffective Date: 2026-04-25 — Current Version: 1.14 (effective 2026-05-25; full revision history in §Change log)\nThis Data Processing Agreement (\u0026ldquo;DPA\u0026rdquo;) 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, \u0026ldquo;GDPR\u0026rdquo;). It supersedes any inconsistent provision in the Terms of Service for matters within its scope.\n1. Parties # Processor: fremverk ApS\nCVR: 39150689\nVAT: DK39150689\nRegistered office: Ringager 4C, 2. tv, 2605 Brøndby, Denmark\nData protection contact: compliance@frem.sh\nController: the Customer identified in the Terms of Service between the parties.\n2. Definitions # Terms defined in the GDPR have the meanings given there. \u0026ldquo;Service\u0026rdquo; means the fremforge product at frem.sh as described in the Terms of Service §2. \u0026ldquo;Sub-processor\u0026rdquo; means any third party engaged by fremverk that processes Customer Personal Data. \u0026ldquo;Customer Personal Data\u0026rdquo; means personal data (as defined in GDPR Art. 4(1)) processed by fremverk on behalf of the Customer in connection with the Service, including the categories enumerated at §4.1 below — Customer Content (whatever the Customer or its Users commit, post, comment, or upload), authentication metadata (OIDC/SAML claims, session tokens, PAT identifiers), usage and technical data (IP addresses, user agents, action timestamps), commit-author identities, billing-contact identifiers, and inbound support correspondence — but excluding anonymised aggregates from which the Customer cannot reasonably re-identify a data subject.\n3. Subject matter, duration, nature, and purpose # Subject matter: fremverk\u0026rsquo;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\u0026rsquo;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:\nIdentity and contact: names, usernames, email addresses, organisation affiliation. Authentication: OIDC/SAML subject identifiers and claims, TOTP secrets (where enabled), personal access tokens, session and API token identifiers. Usage and technical: IP addresses, user agents, timestamps of actions, admin-UI and API calls, commit author identities and email addresses, issue and PR participation. Repository and collaboration content: whatever the Customer or its Users commit, post, comment, or upload, which may contain personal data as determined by the Customer. Billing and commercial: organisation legal name, billing contact, VAT number, invoice records. Raw payment-card and bank-account data is processed by Mollie only; fremverk does not see or store it. Support correspondence: whatever the Customer sends to support@frem.sh, abuse@frem.sh, compliance@frem.sh, security@frem.sh, or hello@frem.sh, plus attachments. No special categories of personal data under GDPR Art. 9 or Art. 10 are expected to be processed. If the Customer intends to use the Service for special-category data, it notifies fremverk in advance and the parties agree on additional safeguards.\n4.2 Categories of data subjects # Employees, contractors, and agents of the Customer who use the Service. Authors of commits, issues, PRs, comments, and wiki pages, including external contributors to public repositories enabled by the Customer. Recipients and senders of webhook deliveries, where the Customer configures them. AI agents (from Phase 2+) acting on behalf of a User under a scoped delegated mandate, where the mandate metadata or audit trail contains personal data linking the agent to the User. 5. Obligations of the Controller # The Customer, as Controller:\nEnsures 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\u0026rsquo;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.\n6. Obligations of the Processor (fremverk) # fremverk:\nProcesses 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\u0026rsquo;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\u0026rsquo;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\u0026rsquo;s benefit, the sub-processor\u0026rsquo;s benefit, or any third party\u0026rsquo;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\u0026rsquo;s instruction at run time and do not retain Customer Content in model weights or training corpora.\n7. 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).\nOn 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\u0026rsquo;s deadlines. Assistance beyond the export and admin-UI functionality already provided by the Service may be chargeable at fremverk\u0026rsquo;s reasonable rates, to the extent permitted under GDPR Art. 28(3)(e).\nfremverk 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\u0026rsquo;s then-current professional-services rates as published on the pricing page or as agreed in an Order Form.\n8. 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 \u0026ldquo;without undue delay\u0026rdquo; 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\u0026rsquo;s designated security contact (or, where none has been designated, the Customer\u0026rsquo;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.\nfremverk keeps a record of all personal-data breaches as required by GDPR Art. 33(5) and makes it available to the Customer on request.\n8.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\u0026rsquo;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.\n8.3 Consultations with supervisory authorities # fremverk cooperates, at the Customer\u0026rsquo;s reasonable request and expense, with the Customer\u0026rsquo;s prior consultations with supervisory authorities under GDPR Art. 36.\n8.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\u0026rsquo;s Art. 33 / Art. 34 obligations under §§8.1–8.2.\n8.5 Controller-side incidents (fremverk\u0026rsquo;s own controllership) # Independent of the Customer\u0026rsquo;s controllership, fremverk acts as Controller for a narrow set of internal-operations processing activities documented in fremverk\u0026rsquo;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\u0026rsquo;s staff identity provider (idp.fremverk.com), (b) tampering with the WORM-anchor audit chain that protects integrity of fremverk\u0026rsquo;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:\nNotification 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\u0026rsquo;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\u0026rsquo;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\u0026rsquo;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\u0026rsquo;s Controller-side incident-response runbook, available to the Customer under NDA on request.\nThis §8.5 does not extend or modify fremverk\u0026rsquo;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\u0026rsquo;s Controller-side processing.\n9. Return and deletion of personal data # On termination of the Service:\nCustomer Personal Data is retained for 60 days from the termination date to enable the Customer to export it using the on-demand signed-export endpoints. This window aligns with the post-termination export window in Terms §16.5 and the suspension/termination retention sequence in AUP §11. After the 60-day export window, Customer Personal Data is hard-deleted from primary storage within 30 days. Live-tier backups (continuous WAL + daily snapshots — see Annex A.9) containing Customer Personal Data are retained for a further 30 days beyond primary deletion, then purged from backup stores through the normal backup-retention lifecycle. Total time from termination to live-tier backup-purge completion is up to 120 days. Disaster-recovery monthly snapshots (Annex A.9) are sealed copies retained 13 months solely for catastrophic-recovery scope (e.g. recovering from a long-undetected corruption that predates the live-tier window). These snapshots are not used for any Customer-facing access path; if a DR restore brings Customer Personal Data back into primary storage after the 120-day purge, that data is re-processed through the same hard-delete procedure within 30 days of the restore. Immutable audit log entries linked to the Customer\u0026rsquo;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\u0026rsquo;s repository content. The accounting-records subset of the above (invoice + transaction records as defined in Danish Bogføringsloven §10) is retained for 5 years from the end of the accounting year. Customer-Personal-Data fields not required for accounting reconciliation (email, display-name, repository references) are pseudonymised at the 90-day primary-deletion mark — only the accounting-relevant columns survive into the 5-year archive. On written request, fremverk provides written confirmation of deletion.\nfremverk provides Customer Content in machine-readable formats: Git bundles for repository content; JSON for issues, pull requests, comments, audit logs, and metadata; tarballs for LFS objects and package-registry artifacts. Schemas are published at docs.frem.sh/export-schema.\nfremverk 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\u0026rsquo;s then-current professional-services rates.\nOn 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.\n10. 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.\n10.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\u0026rsquo;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\u0026rsquo;s audit log with the email-provider message id for each recipient.\nPre-launch carve-out (P2 bughunt 2026-06-01): the direct-email channel (a) is waived for Sub-processor changes that occur while fremverk operates in a pre-launch state, defined as: zero paying Customers AND zero Customers under contract for paid service. The criterion is machine-readable via the pre_launch_paying_customers field in fremverk/governance/suppliers.yaml. In the pre-launch state, the public posting (b) carries the full notification — there are no contractual Customer recipients to notify by direct email. The carve-out lapses on the first paying Customer signup; every Annex B change after that point follows the full dual-channel notification. The DPA version bump that ends the pre-launch state will explicitly record the cutover and reference this clause.\nCustomer may, within 15 calendar days of fremverk\u0026rsquo;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:\n(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\n(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.\n10.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.\n10.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.\n11. 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\u0026rsquo;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.\nData type Location Sub-processor Repository content (Git, LFS, packages, releases) T Cloud eu-de (Biere/Magdeburg, DE) Deutsche Telekom AG (T Cloud) CI logs and runner artifacts T Cloud eu-de (DE) Deutsche Telekom AG (T Cloud) Audit logs (hot + WORM archive) T Cloud eu-de (DE) Deutsche Telekom AG (T Cloud) Authentication metadata (session, MFA secrets, recovery hashes) T Cloud eu-de (DE) Deutsche Telekom AG (T Cloud) Billing records (in-monolith engine, invoice rows) T Cloud eu-de (DE) Deutsche Telekom AG (T Cloud) Accounting bilag (Bogføringsloven 5-year retention) Copenhagen, Denmark Visma Dinero ApS Payment-instrument data NL Mollie B.V. Outbound transactional email (magic-links, password resets, system notifications, billing) Operating entity: Lettermint B.V., Zwolle, NLUpstream IaaS: OVHcloud SAS (FR); UpCloud Ltd (FI-incorporated, Amsterdam NL datacenter) Lettermint B.V. Operator IdP (Authentik) — operator + workforce session metadata, MFA secrets, recovery hashes T Cloud eu-de (DE) — deployed in the platform-identity-prd enterprise project for blast-radius isolation per Annex A.3 Deutsche Telekom AG (T Cloud) Inbound shared-mailbox correspondence (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlin, Germany Heinlein Hosting GmbH (mailbox.org) Status-page content T Cloud eu-de (DE) Deutsche Telekom AG (T Cloud) CDN edge cache (TLS-terminated) EU PoPs only Bunny CDN d.o.o. 11.2 International transfers # Customer Personal Data is processed exclusively inside the EU/EEA by entities with no US parent. Outbound transactional email is delivered through Lettermint B.V., a Dutch entity (Zwolle, KvK 80706290) processing the data on EU-only upstream infrastructure (OVHcloud SAS, France; UpCloud Ltd, Amsterdam datacenter). Inbound shared-mailbox correspondence addressed to operator addresses (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) is hosted by Heinlein Hosting GmbH (mailbox.org) in Berlin, Germany. No international transfer outside the EU/EEA occurs on any processing path and no Article 46 GDPR safeguard is required.\nNote on T Cloud sub-services: T Cloud 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.\n11.3 CLOUD Act / US extraterritorial-law posture # fremforge has no CLOUD Act exposure on any processing path. All Customer Personal Data — repositories, CI runs, audit logs, authentication metadata, billing records, payment-instrument data, accounting bilag, outbound transactional email, and inbound shared-mailbox correspondence — is processed inside the EU by entities with no US parent (Deutsche Telekom AG in Germany; Heinlein Hosting GmbH in Germany; Mollie B.V. in the Netherlands; Visma Dinero ApS in Denmark; Lettermint B.V. in the Netherlands; Bunny CDN d.o.o. in Slovenia at EU edge PoPs).\nCard-network footnote (P1-LEG-11) — Mollie\u0026rsquo;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 \u0026ldquo;no US-parented\u0026rdquo; claim above applies to fremverk\u0026rsquo;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\u0026rsquo;s SEPA path involves no card-network sub-sub-processor).\nOutbound-email sub-processor — Outbound transactional email is delivered by Lettermint B.V. (Zwolle, NL — KvK 80706290), an EU-anchored Dutch entity running on OVHcloud SAS (France) and UpCloud Ltd (Finland-incorporated, Amsterdam datacenter). No US-parented upstream sits in the email path. Lettermint replaced Sendinblue SAS / Brevo on 2026-05-14; the superseded Brevo cap-table footnote (originally P1-LEG-12) is retained in the §Change log only for historical reference and does not apply to the live processing chain.\nfremverk 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.\nCustomer-configured AI vendors (BYOK) — For Customer-configured AI vendors enabled at the Customer\u0026rsquo;s choice, see Annex B §B.8 — those vendors are the Customer\u0026rsquo;s own processors and their jurisdictional exposure (including any US-extraterritorial-law exposure) is governed by the Customer\u0026rsquo;s own contract with that vendor, not by this DPA.\n11A. 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:\n(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\u0026rsquo;s designated security contact, 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.\n11A.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.\n11A.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.\n12. Audit rights # 12.1 Demonstrable compliance # fremverk makes the following available to the Customer:\nThis DPA and the Annex A — Security Measures. The current Annex B — Sub-processor Register. The inherited certifications of T Cloud (ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, TISAX), Bunny CDN (ISO 27001, SOC 2 Type II), Heinlein Hosting / mailbox.org (ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen TR 03108), and Mollie (PCI-DSS Level 1), with links on the trust page. Lettermint B.V. certification evidence is pending vendor disclosure as of v1.9 and will be added once received. Its written responses to the Customer\u0026rsquo;s reasonable data-protection questionnaires. Summary reports of fremverk\u0026rsquo;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\u0026rsquo;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.\nOn 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.\n12.2 On-site audits # The Customer has the right to conduct an on-site audit of fremverk\u0026rsquo;s compliance with this DPA once per calendar year, on reasonable prior notice (at least 30 days), during business hours, at the Customer\u0026rsquo;s own cost, with reasonable limitations to protect confidentiality and fremverk\u0026rsquo;s operations. The Customer may not require access to other Customers\u0026rsquo; data or to fremverk\u0026rsquo;s trade secrets. The parties may agree that an audit is satisfied by provision of existing third-party audit reports where available.\nWhere 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\u0026rsquo;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\u0026rsquo;s reasonable audit cost.\n12.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.\n13. 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.\nNotwithstanding 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\u0026rsquo;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\u0026rsquo;s breach of this DPA, up to the limits set out above.\nWhere a GDPR Art. 83 administrative fine is imposed on the Customer and is attributable to fremverk\u0026rsquo;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\u0026rsquo;s contribution corresponds to its share of responsibility per Art. 82(4)–(5).\nWhere 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\u0026rsquo;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.\n14. 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.\n15. Governing law and jurisdiction # This DPA is governed by Danish law. Disputes are subject to Danish courts, without prejudice to mandatory provisions of GDPR.\n16. 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\u0026rsquo;s procurement process requires one; in that case fremverk executes a counterpart on request.\n17. 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\u0026rsquo;s incident-reporting obligations by providing relevant breach details (per §8) within timeframes consistent with the Customer\u0026rsquo;s 24-hour early warning and 72-hour notification deadlines.\n17.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\u0026rsquo;s exit-strategy obligations through the standard data-export mechanism in §9.\n17.3 BYOK / Customer-Held Keys — encryption-at-rest CMK custody. Customer-held cryptographic key material (BYOK / HYOK) for encryption-at-rest of the platform\u0026rsquo;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 DEW KMS, annual auto-rotation). Note on terminology: the term \u0026ldquo;BYOK\u0026rdquo; is also used in Annex B §B.8 to describe the Customer\u0026rsquo;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 \u0026ldquo;Customer-configured AI vendor key\u0026rdquo;.\nAnnex 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.\nA.1 Physical security # Hosting in T Cloud 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\u0026rsquo;s responsibility as sub-processor. Bunny CDN edge nodes in EU points of presence only, operated by Bunny CDN d.o.o. under ISO 27001 (cert year 2025) and SOC 2 Type II (cert year 2023). Currency of cert evidence is verified at each quarterly supplier review (see fremverk/governance/supplier-register.md §4 — next review 2026-08-13). A.2 Network and edge security # TLS 1.2+ on every HTTP surface. HSTS enabled. Modern cipher suites only. Web Application Firewall and DDoS protection at the edge via Bunny Shield Advanced across all HTTP(S) surfaces including Forgejo UI, Git over HTTPS, API, and the package registry. T Cloud Anti-DDoS protection on the SSH endpoint at ssh.frem.sh:443 (port 443 mapped to in-cluster SSHd; port 22 is not publicly exposed on the apex domain). Per-organisation rate limiting at the T Cloud 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\u0026rsquo;s Cloud Native Network 2.0 model — each pod\u0026rsquo;s ENI is attached to a Security Group that permits only the workload\u0026rsquo;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 (ssrf-guard.ts + the proxy\u0026rsquo;s TCP-connect-layer filter) applying the deny set covering RFC1918, link-local, IPv6 ULA, loopback, multicast, T Cloud 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\u0026rsquo;s self-hosted Authentik IdP at idp.fremverk.com, with policy-flow MFA enforcement (TOTP / WebAuthn) and group-claim role mapping. Authentik runs in fremverk\u0026rsquo;s T Cloud platform-identity-prd enterprise project (Germany, EU). fremverk does not use any external (US-parented) identity provider for operator authentication. Effective from operator-console activation: the Authentik tenant infrastructure was deployed 2026-05-06; binding of the operator-console (/_admin/*) and customer-side OIDC/SAML federation paths to Authentik becomes effective for an individual tenant only once OPERATOR_OIDC_* runtime secrets are populated in the api-runtime Secret and the relevant tenant federation is bound. Forgejo site-admin access is break-glass only, limited to two local accounts vaulted in T Cloud DEW CSMS with mandatory MFA; every login pages on-call and writes to the platform-security audit stream. Multiple scoped service accounts are used for control-plane functions; no super-admin tokens are used in normal operation. Customer-side access is authenticated via OIDC/SAML SSO to the Customer\u0026rsquo;s identity provider, with per-organisation session binding and scoped API tokens as documented in the OIDC SSO and SAML 2.0 SSO pages. Magic-link single-use enforcement. Where email-delivered links carry an authentication or one-time consumption purpose (welcome-email initial-password-claim, billing-setup callback, undo-cancellation, signup-confirmation), the link payload is HMAC-signed against BILLING_LINK_SIGNING_SECRET with a 48-hour TTL and atomically consumed via Redis GETDEL on the encrypted-state-bag key. First click wins; second click sees null and returns \u0026ldquo;already consumed\u0026rdquo;. Implementation: apps/api/src/services/password-claim.ts consume() + apps/api/src/services/signed-tokens.ts. 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\u0026rsquo;s api against fremverk\u0026rsquo;s own DCS Redis, NOT inside Lettermint. A.4 Encryption # Encryption in transit: TLS 1.2+ on all HTTP surfaces; SSH at ssh.frem.sh:443 (port 443 mapped to in-cluster SSHd; port 22 is not publicly exposed on the apex domain). Encryption at rest: T Cloud 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 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 account; the Customer does not hold key material — see §17.3 for the customer-held-key roadmap. Earlier wording \u0026ldquo;customer-managed\u0026rdquo; reflected OTC terminology where \u0026ldquo;customer\u0026rdquo; refers to fremverk-as-T-Cloud-tenant; clarified to fremverk-managed per audit P0-44. Encryption at rest — DCS Redis caveat: T Cloud 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 exposes the attach point. Disclosed transparently in line with §11.2 and clarified in line with audit P2-15. Item TTL Linkable to natural person? Notes Rate-limit counters ≤ 1 min sliding window Yes — keyed by IP and/or SHA-256 of email No raw email is stored; counter is (hash, count) pair Signup-flow ephemeral state ≤ 30 min Yes — contains raw email + dwell-time + bot-score Cleared on signup completion OR Altcha-pre-check timeout Operator/admin session identifiers ≤ 7 days (sliding) Yes — opaque server-side ID linkable to the authenticated user No PII payload; the ID itself is the link Mollie webhook idempotency tags 24 h Yes — payment-id linkable to a customer-tenant pair No PAN, no card metadata BullMQ job payloads (outbound webhook delivery, email send, audit emit) ≤ 24 h Yes — payloads contain email addresses (trial-reminder recipients, dunning) and customer-tenant identifiers Failed jobs auto-expire from the failed-set after 24h Token-exchange seen-IP set (P2-THREAT-05) 90 days (sliding) Yes — IP per (tenantId, SHA-256-truncated subject) New-IP triggers token_exchange_from_new_ip log line Altcha challenge state n/a — stateless, HMAC-signed n/a Does NOT transit DCS — kept here for completeness 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).\nItem TTL Linkable to natural person? Notes signup_pending_confirmations (Postgres table) ≤ 24 h Yes — raw email, org_slug, display_name, billing country, optional VAT number until the customer clicks the confirmation link Hard-deleted by the daily retention job past expires_at; on consumption (user confirms email) the row migrates to the tenants table with full audit trail. Legal-acceptance snapshot of terms/privacy/dpa/aup versions captured at form-submit and carried through. 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.\nCustomer-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/\u0026lt;org\u0026gt;/\u0026lt;repo\u0026gt;/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 \u0026lt; byte (preventing \u0026lt;script\u0026gt;/\u0026lt;style\u0026gt; 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.\nCI runner secrets: injected into CCI pods as environment variables only for the lifetime of the job, never persisted to shared volumes or ConfigMaps. Signed commits — default path is SSH-key signing (git config gpg.format=ssh, with the per-org allowedSignersFile derived from members\u0026rsquo; 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\u0026rsquo;s self-hosted Sigstore stack on T Cloud 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 with Forgejo ACLs, enforced by automated nightly ACL smoke tests via FunctionGraph. Hosted CI runners execute as per-job ephemeral T Cloud Cloud Container Instance (CCI) serverless pods with per-pod kernel-virtualisation isolation under the CCI secure-container runtime (the canonical OTC name; the same posture is sometimes referred to in vendor documentation as \u0026ldquo;Kata-style\u0026rdquo;), not shared-kernel containers. Note: T Cloud CCI v2 is the canonical isolation target; fremverk\u0026rsquo;s tenant is in the OBT-entitlement waitlist (the OTC tenant-gate at CCI.02.403103). Until that gate is unlocked, runners execute on the fremforge-prd CCE Turbo cluster (Cloud Native Network 2.0) with the same hardening posture (non-root, capabilities-dropped, read-only rootfs, per-pod VPC Security Group egress allowlist permitting only the proxy + git protocol egress, no service-account-token mount). The CCI cutover is operator-internal and does not require customer action. Runner pods start clean, have no persistent storage, do not mount service-account tokens, have all capabilities dropped, run as non-root with a read-only root filesystem, and have a per-pod VPC Security Group (under Cloud Native Network 2.0) restricting egress to the outbound-proxy and the runner\u0026rsquo;s required Git/container-registry destinations only; the SG blocks access to the shared CCE cluster, T Cloud metadata endpoints, and other runner pods at the hypervisor layer (independent of any in-cluster Kubernetes NetworkPolicy enforcement). Per-tenant audit-log streams in T Cloud LTS tagged tenant_id; tenant admins see only their tenant\u0026rsquo;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 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 sourced exclusively inside the EU/EEA. All Forgejo Actions, container base images, and third-party CI tooling used by fremforge\u0026rsquo;s own build pipeline are mirrored from upstream into a fremverk-controlled Forgejo organisation (mirrors/) and a fremverk-controlled SWR registry (fremforge-prd/cache-*). At build time, runners pull from these mirrors only; no fremforge build path resolves DNS or fetches code from github.com, gcr.io, docker.io (except via the Forgejo / SWR pull-through cache), or any other US-jurisdiction host. Mirror sync runs weekly (forgejo-actions-mirror CronJob) and is operationally independent of any single CI run, so a transient github.com outage does not affect builds. Container images pushed to SWR are scanned for CVEs (Trivy, fail-on-CRITICAL/HIGH) before push. Scope clarification — build path vs operator-internal egress. The \u0026ldquo;no US-host resolution\u0026rdquo; commitment above covers the Customer-data path: the api runtime that processes tenant requests, stores tenant data, and emits tenant-bound responses never resolves or fetches from US-jurisdiction hosts. Operator-internal flows that do not touch Customer data — the mirror-sync CronJob\u0026rsquo;s pull from upstream registries (github.com, gcr.io, docker.io), CI runners pulling cached base images, and the operator-AI workbench (.anthropic.com, .claude.com, .openai.com, .mistral.ai) used for fremverk-internal engineering decisions — may resolve to US-jurisdiction hosts via the strict outbound-proxy allowlist. These flows are documented sub-processors where applicable (see Annex B) and operator-internal entries where not; in no case does Customer data pass through them. P1-22 bughunt 2026-06-01: this paragraph added to distinguish the two layers, after a workshop reading the previous paragraph mistakenly inferred runtime egress was also US-host-free. A.7 Audit logging and integrity # Forgejo-native events and middleware-emitted events both write through a shared audit sink with tamper-evident hash chaining. The running hash is anchored to OBS WORM storage every 2 minutes; the chain is verified hourly by an in-cluster integrity check; chain breaks page on-call. Audit-log retention — two-tier model: Hot (queryable) tier — security-relevant audit events (authentication, authorisation, admin actions): retention is a per-tenant policy with presets of 90 / 180 / 365 / 730 days. The Customer tenant admin sets the tier at Authentication policy → Audit log retention. Defaults: 90 days for the standard plan; 365 days for enterprise / enterprise_trial / internal plans. After the per-tenant cutoff, the audit-payload-reaper redacts actor and fields_json to null while preserving the SHA-256 chain hashes. The two tiers are logically separate — the hot-tier is queryable PII (re-identification risk increases with retention), the WORM tier below is integrity hashes (no PII, kept full-term). Hot (queryable) tier — operational logs (HTTP, runner, infrastructure): 30 days hot, not customer-configurable. Immutable WORM archive (both tiers): 3 years (1095 days) in T Cloud OBS Object Lock compliance-mode; hash-chain anchored every 2 minutes; payload-bearing rows redacted at hot-tier cutoff but anchor chain is unbroken. WORM retention configurability (P2-DR-17). The 3-year (1095-day) WORM retention floor is the published default; the OBS Object Lock policy supports per-bucket retention values up to 9.5 years (3500 days). Customers under Enterprise-on-Demand may request a longer WORM retention window for a specific tenant — typically driven by sectoral regulation (financial services, public-sector contracts) — under a separate written agreement. Shorter-than-3-year WORM retention is not offered: WORM is a unilateral fremverk integrity commitment for the cryptographic chain, and reducing it would break the chain-of-custody promise this annex makes to all Customers. Note: the hot-tier customer-tunable retention above is logically separate from the WORM tier — a Customer choosing a shorter hot-tier retention does not affect the 3-year WORM commitment, which continues to hold the hash chain for the full window. SLA floor by plan. Customers on enterprise plans contractually receive at least 365 days of queryable retention under the SLA; a Customer admin may set the hot-tier below the plan baseline via the admin UI (yes-by-design — the UI does not enforce the contractual floor), but doing so disclaims the contractual queryability commitment for the affected period. The standard-plan SLA floor is 90 days queryable. Agent actions are recorded with actor=agent:\u0026lt;agent_id\u0026gt;, on_behalf_of=\u0026lt;user_id\u0026gt; — distinguishable in the audit stream and in admin-UI filters from human actions. fremverk verifies the integrity of the audit chain through an hourly automated check that backward-walks the canonical lineage from the most recent WORM-anchored hash; mismatches page on-call. The verifier tolerates orphan anchor objects produced by bootstrap-time test runs or ungracefully-aborted anchor jobs — these are reported as warnings and do not page, since they sit outside the canonical lineage and therefore cannot affect chain integrity. The implementation, hash algorithm, integrity-check job, and orphan-tolerance contract are documented in fremverk\u0026rsquo;s Information Security Policy, available to Customers under NDA. Where the 2-minute anchoring cadence cannot be met for transient operational reasons (e.g., OBS region maintenance), fremverk records the gap in the chain metadata and documents the gap in the next status-page incident report.\nA.8 Security patching # The published security-patching SLA at www.frem.sh/trust/#security-patching is part of this annex. The targets below are the Phase 2 contractual targets (in force from 2027-Q1, concurrent with fremverk\u0026rsquo;s funded 24/7 on-call rotation). During Phase 1, fremverk uses commercially reasonable efforts against the Phase 1 targets published in SLA §6.2 (Critical 72h / High 7d / Medium 14d / Low next maintenance window) — see Terms §13.1 for the corresponding warranty carve-out. Maximum time to patch, measured from the upstream fixed release or advisory publication (whichever is later):\nSeverity (CVSS) Phase 1 (commercially reasonable) Phase 2 (contractual) Critical (≥ 9.0) 72 hours 48 hours High (7.0–8.9) 7 days 72 hours Medium (4.0–6.9) 14 days 7 days Low (\u0026lt; 4.0) Next scheduled maintenance window Next scheduled maintenance window 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.\nA.9 Backup and disaster recovery # A.9 Backup and disaster recovery.\nRecovery 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 eu-de region loss): ≤ 7 days for repository content (Forgejo on SFS Turbo) and object-store payloads (OBS), backed by weekly snapshots replicated to eu-nl via T Cloud CBR (for SFS Turbo) and OBS Cross-Region Replication (for OBS). 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 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 eu-de region failure (cold restore to alternate EU region from cross-region OBS replica). Disaster-recovery procedures are tested at least annually and on material change to the recovery design (RTO target, RPO commitment, sub-processor change on the recovery path). Each test is documented as a runbook execution + post-drill report; executive summary available to Customers under NDA on written request. Enterprise-on-Demand contracts may agree to a tighter cadence (e.g., quarterly) in the Order Form. Daily automated backup-presence verification. Independent of the annual restore drill, a daily CronJob asserts that the previous night\u0026rsquo;s RDS automatic snapshot exists, completed successfully, finished within the last 25 hours, and is non-zero in size. A failed assertion pages on-call via the same SMN topic that production alarms use. The verifier closes the silent-fail mode where the snapshot job could stop running unobserved between annual drills; it does not replace the annual restore drill, which remains the only test that validates restorability end-to-end. Backups: two tiers, distinct scope and access paths: Live tier: continuous WAL (30 days) + daily snapshots (90 days). Used for routine point-in-time recovery and post-termination backup-purge per §9 (120-day total purge timeline). RDS PostgreSQL daily snapshots are in-region (T Cloud eu-de); cross-region replication for RDS is on the post-launch roadmap pending the T Cloud Cloud Backup \u0026amp; Recovery service\u0026rsquo;s general availability for RDS resources (the service is published but not yet enabled for RDS object types at the T Cloud / Open Telekom Cloud 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 eu-nl per Annex A.9 below. Disaster-recovery tier: monthly snapshots (13 months). Sealed copies for catastrophic-recovery scope only — no automated Customer-facing read path, no support-team query path. Repository content (Forgejo on SFS Turbo) and object-store payloads (OBS) carry 13-month cross-region retention to eu-nl. 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 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 T Cloud-managed keys; restore-readiness verified monthly. Customer-data-restore SLA (P1-DR-12): Customers may request a tenant-scoped restore from the live tier — for example, after an accidental tenant-side hard delete that erased a load-bearing repository or admin-policy state. fremverk\u0026rsquo;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, \u0026gt; 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\u0026rsquo;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\u0026rsquo;s path is operator-driven via data-corruption-recovery.md (operator runbook, available under NDA via compliance@frem.sh)). A.10 Personnel # fremverk personnel with access to production are vetted (reference checks, right-to-work verification) under Danish employment law. Personnel receive annual security and data-protection training covering: 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); and operator-tooling least-privilege practice. Curriculum is reviewed annually against current threat landscape and regulatory guidance (Datatilsynet, ENISA, EU EDPB). 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\u0026rsquo;s HR-record OBS bucket (encrypted at rest with DEW KMS, EU-resident, scoped IAM). Per-staff records include: course name + version, completion date, assessment score where applicable, refresher-due date. 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, CCI regional incident, Bunny CDN outage, T Cloud DNS outage, Mollie outage, bulk secret exposure in audit log, suspected runner base image compromise, and compromised tenant. Detection via T Cloud CES metrics, AOM application observability, LTS log-based alerts, and Grafana dashboards. Alerts route through T Cloud SMN to SMS/push for on-call staff. Post-incident reviews are conducted for any Priority 1 incident; post-mortems for incidents affecting Customer data or availability are published on the trust page within 14 days. A.12 Testing # Internal security testing covering tenant isolation, webhook SSRF, runner pod 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 # Production changes flow through the fremforge-tst pre-production environment with a 24-hour soak for risky migrations. Security patches may skip soak under documented incident protocol. 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 OBS; every change is reviewed in Git before apply. A.14 Tenant-visible controls # On-demand signed export of org data (repos, issues, PRs, audit log, LFS manifest) as a self-service action in the fremforge admin UI or via the public REST API. Per-organisation audit-log view and export. SSO enforcement with break-glass account pre-designation for IdP-outage scenarios. Optional public-repo support with AUP enforcement for abuse prevention. Annex B — Sub-processor Register # As of the date of this DPA, fremverk engages the following Sub-processors to process Customer Personal Data.\nFor the avoidance of doubt: Customer-chosen identity providers (where the Customer federates fremforge to its own Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik, or other tenant via OIDC or SAML) are the Customer\u0026rsquo;s processors, not sub-processors of fremverk under this DPA. fremverk does not contract with those providers on the Customer\u0026rsquo;s behalf, and they do not appear in the register below.\nSub-processor Role Sub-processor type Location Purpose Certifications Effective from Deutsche Telekom AG (T Cloud) Infrastructure — compute, storage, network, CI runners, key management, observability Infrastructure Biere / Magdeburg, DE (eu-de) Primary processing of all Customer Personal Data in repositories, CI runs, audit logs, and operational metadata ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, TISAX 2026-04-25 Bunny CDN d.o.o. Edge delivery — CDN, WAF, DDoS mitigation CDN Slovenia (HQ); pull-zone configured to EU edge regions only with geo-replication outside EU disabled (configuration documented at fremforge/platform-foundation/bunny-setup.md) Caching, TLS termination, and WAF for public HTTP surfaces; no access to authenticated content beyond TLS-terminated passthrough ISO 27001 (2025), SOC 2 Type II (2023) 2026-04-25 Lettermint B.V. Outbound transactional email Email Zwolle, Netherlands (KvK 80706290) — upstream OVHcloud SAS (France) + UpCloud Ltd (Finland-incorporated, Amsterdam, NL datacenter) Delivery of magic-links, password resets, system notifications, billing receipts, invoice attachments, and waitlist confirmations sent from noreply@frem.sh; outbound only. Data categories: recipient email address, email body content (including tenant slug, billing context, and invoice line items where carried in the body or PDF attachment), delivery status metadata, bounce and spam-complaint metadata. EU-only operating entity and EU-only upstream — no US parent on the email path. Vendor certification evidence pending — Lettermint commitment requested 2026-05-13 for ISO 27001 attestation or equivalent third-party assurance report by 2026-09-30; if not provided by that date, the relationship is re-scoped to operator/admin-only mail (zero Customer Personal Data) until evidence lands. DPA accepted at signup (online flow) with under-NDA written DPA available on request 2026-05-14 Heinlein Hosting GmbH (mailbox.org) Shared-mailbox hosting Email (inbox) Berlin, Germany (HRB 220010 B) Hosting of operator shared mailboxes (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) for inbound customer correspondence and outbound replies. EU-only operating entity, no US parent. ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen (TR 03108) 2026-04-27 Mollie B.V. Payment processing Payments Amsterdam, NL Processing of payment-method details (cards, SEPA mandates) and transaction records for Fee collection; fremverk receives payment-result metadata only PCI-DSS Level 1 2026-04-25 Visma Dinero ApS Accounting / invoice rendering / periodisering journal entries Accounting Copenhagen, Denmark (CVR 33779423) Issuance and storage of invoice and credit-note bilag for Customer billing under Danish bookkeeping law (Bogføringsloven §10 5-year retention). fremverk transmits the Customer\u0026rsquo;s organisation legal name, billing contact, VAT number, invoice line items, and Mollie payment id; for annual prepayments, fremverk additionally posts twelve monthly periodisering journal entries (1/12 of the annual fee, debit deferred-revenue, credit revenue account per VAT treatment) over the term of the prepayment under Bogføringsloven §8 accrual-basis recognition (P1-A07-34, 2026-05-17). Dinero stores the resulting bilag for the statutory 5-year retention period. No repository content, no audit-log content, no payment-card primary account number is transmitted (Mollie remains the PCI-DSS scope holder for card data; Dinero receives only post-settlement metadata). ISO 27001 2026-05-17 Bunny CDN\u0026rsquo;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.\nMollie\u0026rsquo;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\u0026rsquo;s own sub-processor register at mollie.com/privacy/processors. Customers preferring to avoid the card-network chain may pay by SEPA Direct Debit.\nB.1 Self-hosted components (not Sub-processors) # fremverk self-hosts all other components on T Cloud 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\u0026rsquo;s own staff IdP. These do not introduce additional Sub-processors.\nB.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\u0026rsquo;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.\nB.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\u0026rsquo;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\u0026rsquo;s own integrated CA chain; this internal-origin CA relationship covers the Bunny-→-ELB origin leg only and was activated 2026-05-04.\nFailover procedure (P2-LEG-29 update 2026-05-08, RTO tightened): if Actalis discontinues its free ACME service, revokes our External Account Binding, or its eIDAS QTSP listing is suspended, fremverk will select a replacement CA from the EU Commission\u0026rsquo;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.\nB.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\u0026rsquo;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.\nB.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:\nsupport@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.\nA DNS authoritative-name-server operator is not a sub-processor under Article 28 in this configuration: DNS queries originate from the visitor\u0026rsquo;s resolver chain (the visitor\u0026rsquo;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 \u0026ldquo;why isn\u0026rsquo;t Simply.com on the sub-processor register?\u0026rdquo; can find the answer.\nThe canonical product origin frem.sh is operated by fremverk on BunnyDNS (Bunny CDN d.o.o., Slovenia — already disclosed as Annex B row 2, the CDN/WAF/edge sub-processor). DNS for frem.sh does not transit Simply.com.\nB.7 External uptime monitoring — updown.io (87 Seconds SARL, not a Sub-processor) # fremverk uses updown.io (87 Seconds SARL, France) to run independent external HTTPS probes against five public health endpoints (the api /healthz endpoint, Forgejo, the Kuma public status page, the marketing site, and the Authentik public sign-in page). The probes detect customer-visible outages independently of fremverk\u0026rsquo;s in-cluster observability stack.\nupdown.io is not a sub-processor under Article 28 in this configuration: the probed endpoints are public no-auth health surfaces (none of them expose Customer Personal Data); the probe payload is a plain HTTPS GET against the endpoint URL; the response captured by updown.io is the HTTP status code, latency, TLS-handshake summary, and the egress IP each endpoint resolves to from the probe location. No Customer Personal Data flows to updown.io and no Customer Personal Data is processed on fremverk\u0026rsquo;s behalf by updown.io. The posture matches the VIES (§B.2), Actalis (§B.3), and Simply.com (§B.6) carve-outs above and is disclosed here for transparency.\nB.8 Customer-configured AI vendors (Customer-configured AI vendor key — not Sub-processors) # fremforge\u0026rsquo;s AI integration features (AI PR review, Renovate explanations, customer-callable POST /api/v1/orgs/\u0026lt;slug\u0026gt;/ai/complete) operate on a Customer-configured AI vendor key model (sometimes called \u0026ldquo;BYOK\u0026rdquo; 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 /\u0026lt;org\u0026gt;/_admin/ai-integrations (supported adapters: OpenAI-compatible, Anthropic native, Google Vertex Gemini), pasting a third-party API key issued under the Customer\u0026rsquo;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 DEW KMS root) and acts as a transparent proxy between the Customer\u0026rsquo;s workflow and the Customer\u0026rsquo;s chosen AI vendor.\nThe customer-configured AI vendor is not a sub-processor of fremverk under Article 28 in this configuration:\nThe 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\u0026rsquo;s behalf; the Customer\u0026rsquo;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\u0026rsquo;s prompts and responses transit fremverk\u0026rsquo;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: \u0026ldquo;Customer-chosen identity providers \u0026hellip; are the Customer\u0026rsquo;s processors, not sub-processors of fremverk under this DPA\u0026rdquo;). When the Customer chooses to enable AI features, the AI vendor is the Customer\u0026rsquo;s processor; fremverk is in the role of providing the platform integration only.\nNo 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\u0026rsquo;s processing is governed by the Customer\u0026rsquo;s own contract with that vendor — fremverk\u0026rsquo;s no-US-parent commitment in §11.3 covers fremverk\u0026rsquo;s own sub-processor stack only, which is unchanged by the AI feature.\nPhase 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.\nChange log # Version Date Change 1.0 2026-04-25 Initial publication. 1.1 2026-04-27 Added Heinlein Hosting GmbH (mailbox.org) as sub-processor for inbound shared-mailbox hosting, effective 2026-04-27 (migration completed from previous provider). Notified Customers per §14. 1.2 2026-05-03 Annex B clarifications: explicitly enumerated the self-hosted PoW captcha and Authentik as self-hosted (non-sub-processor) components; documented EU Commission VIES service as a non-commercial public-sector lookup, not an Article-28 sub-processor. Annex A.4 disclosure: DCS Redis ephemeral cache uses provider-managed DEW encryption (no tenant-controlled KMS attach point on T Cloud DCS); migration when OTC exposes the field. No change to Customer-data residency commitment. (Captcha implementation switched from mCaptcha to Altcha on 2026-05-09 — see v1.7 below; both are self-hosted and neither introduces a sub-processor.) 1.3 2026-05-04 CA selection finalised: Actalis S.p.A. (Italy, Aruba Group, eIDAS QTSP) chosen as the origin-TLS Certificate Authority. ACME-DNS-01 flow validated end-to-end on 2026-05-04. Posture unchanged: the CA receives only FQDNs (not Customer Personal Data) and is not an Article-28 sub-processor; not added to Annex B. D-TRUST retained as paid eIDAS-QTSP fallback. 1.4 2026-05-06 Added Visma Dinero ApS (Denmark) to Annex B as the accounting / invoice-rendering sub-processor on the billing path. fremverk transmits organisation legal name, billing contact email, VAT number, invoice line items, and Mollie payment ids into Dinero for issuance and 5-year statutory retention of bilag under Bogføringsloven; no repository content, no audit-log content, and no payment-card primary account number transit Dinero. Visma Dinero ApS is a Danish entity (CVR 33779423) with no US parent — CLOUD Act posture in §11.3 unchanged. Notified Customers per §10. Audit P0-8 closed. 1.5 2026-05-06 Operator-portal authentication baseline set to fremverk\u0026rsquo;s self-hosted Authentik IdP at idp.fremverk.com, running in platform-identity-prd on T Cloud (Germany, EU). Annex A.3 updated. No sub-processor change in Annex B (Authentik is self-hosted; no external operator IdP is used). 1.6 2026-05-08 Security-testing commitments aligned with industry-norm DPA wording. Annex A.9: disaster-recovery drill cadence stated as \u0026ldquo;at least annually and on material change to the recovery design\u0026rdquo; (Enterprise-on-Demand may agree a tighter cadence in the Order Form). Annex A.12 + Annex B.4: fixed-cadence external-pentest commitment removed at the standard tier; pentest reports remain available under NDA when commissioned, and Enterprise-on-Demand contracts may agree a specific testing cadence in the Order Form. §12.1 references aligned. No change to GDPR Art. 32(1)(d) regular-testing posture; rationale: GDPR does not specify a cadence and fremverk\u0026rsquo;s standard-tier commitments now match what comparable EU-sovereign SaaS DPAs offer (e.g., Scaleway, OVHcloud, Hetzner). 1.7 2026-05-09 Bot-mitigation captcha implementation switched from self-hosted mCaptcha to self-hosted Altcha (MIT-licensed, HMAC-signed PoW, in-app at frem.sh/_app/altcha/challenge with widget bundle at frem.sh/_app/static/altcha.js). Removes the separate captcha.frem.sh origin and the in-cluster mCaptcha + mcaptcha-cache Deployments; no Redis dependency, no admin UI, no per-captcha sitekey/secret pair, no rotation cron. Annex B unchanged — both implementations are self-hosted and neither introduces a sub-processor. Annex A.4 DCS Redis paragraph updated to reflect that captcha challenge state no longer transits DCS. No change to Customer-data residency commitment. 1.8 2026-05-13 Annex A.9 RDS cross-region scope clarified. Direct T Cloud Cloud Backup \u0026amp; Recovery API probe (live 2026-05-13 against both eu-de and eu-nl) confirmed CBR does not yet support RDS-typed vaults — BackupService.9900 \u0026quot;rds vault not support\u0026quot; on create; the service enum advertises the type but the backend isn\u0026rsquo;t enabled. CBR product page footnote: cross-region replication is currently scoped to ECS-backed backups. fremforge\u0026rsquo;s original Annex A.9 wording implied a 13-month cross-region snapshot tier across all data classes; the live posture is narrower. Annex A.9 now states explicitly: (a) repository content (Forgejo on SFS Turbo) and object-store payloads (OBS) carry the ≤ 7-day cross-region RPO and 13-month DR retention as before; (b) RDS PostgreSQL (tenant metadata, billing ledger, audit chain head-pointer) is covered in-region only via the 90-day daily snapshot tier — cross-region for RDS will ship once T Cloud enables CBR-for-RDS. The in-region 15-minute RPO is unchanged. Customer-data egress posture, residency, and sub-processor list are unchanged. Notified Customers per §14. 1.9 2026-05-14 Annex B: removed Sendinblue SAS (Brevo) (decommissioned 2026-05-14); added Lettermint B.V. (Zwolle, NL — KvK 80706290) as the outbound transactional-email sub-processor effective 2026-05-14. Driver: sovereignty cleanup — Brevo\u0026rsquo;s upstream runs on Google Cloud europe-west1 (US-parent cloud, CLOUD Act exposure non-zero) and the November 2025 LBO put General Atlantic (US-headquartered PE) at ~25% co-control of Sendinblue SAS. Lettermint\u0026rsquo;s upstream is OVHcloud SAS (France, EU-parent) and UpCloud Ltd (Finland-incorporated, Amsterdam datacenter) — EU-only entities throughout. Code cutover completed 2026-05-13 (api + fg-notification-digest + billingintegration + Forgejo SMTP + Authentik SMTP + Uptime-Kuma + Waitlist all swapped). DNS records stripped 2026-05-14 (SPF include, brevo1/2._domainkey CNAMEs, brevo-code verification TXT — destroyed via tofu apply on fremverk/cloudplatform/connectivity). §11.1 residency table updated; §11.2 international-transfers narrative updated to reference Lettermint in place of Brevo; §11.3 no-US-parent enumeration updated; P1-LEG-12 footnote rewritten (former Brevo cap-table footnote superseded). Annex B inherited-certifications list updated to remove Brevo ISO 27001 reference; Lettermint certification evidence pending vendor disclosure. No change to data categories processed (recipient email + body content + delivery metadata, same shape). Notified Customers per §10 and §14 — the change-log entry is the canonical notification record. 1.10 2026-05-15 §10.2 + §10.3 clarified to describe the dual-channel sub-processor change notification mechanism: every 30-day-ahead (or 24-hour emergency) change notice is now dispatched both as a direct email to the Customer\u0026rsquo;s org billing contact-of-record (primary billing contact plus any configured billing-notification addresses) AND as a public posting to the trust page and the lists.frem.sh mailing list. Previous wording mentioned only the public channels, leaving the contractual carrier ambiguous; the dual-channel mechanism has now been wired in monolith (/_app/_admin/notify/sub-processor-change operator endpoint + sub_processor_notifications audit table recording per-recipient email-provider message ids). No change to data residency, no new sub-processor (Lettermint already in Annex B per v1.9), no extension of objection window. 1.11 2026-05-17 Annex B Visma Dinero scope widened to include periodisering journal entries (P1-A07-34): for annual prepayments, fremverk now posts twelve monthly 1/12 journal entries (debit deferred-revenue, credit revenue per VAT treatment) to the Customer\u0026rsquo;s Dinero org over the term of the prepayment, implementing Bogføringsloven §8 accrual-basis revenue recognition. No new data categories transmitted (amounts, VAT treatment, fiscal month — same shape as the existing invoice posting); no new sub-processor; no change to residency. Note posted to trust page per §14. 1.12 2026-05-18 Annex B §B.7 added: updown.io (87 Seconds SARL, France) disclosed as a carve-out for external uptime monitoring of five public health endpoints (api healthz, Forgejo, Kuma, marketing, Authentik). Not a sub-processor — no Customer Personal Data flows (probes capture URL, status code, latency, TLS-handshake metadata only). Disclosed for transparency to keep parity with the existing carve-out disclosures for VIES (§B.2), Actalis (§B.3), and Simply.com (§B.6). No change to Customer-data residency, no new sub-processor, no notification required. 1.13 2026-05-24 Annex B §B.8 added: Customer-configured AI vendors (BYOK) disclosed as not Sub-processors. Covers the AI PR review, Renovate explanations, and customer-callable /ai/complete features shipped in deploys r119–r124 (2026-05-24). The Customer chooses the AI vendor, contracts directly, and pays directly; fremverk encrypts the key at rest and proxies the call but does not appoint or contract with the AI vendor on the Customer\u0026rsquo;s behalf. Same posture as the existing Customer-chosen IdP carve-out at the Annex B header. No change to Customer-data residency, no new fremverk sub-processor, no notification required. Phase-2 turnkey AI (fremverk-held key) would constitute a sub-processor and would be added to Annex B at that time. 1.14 2026-05-25 Documentation sweep — pre-launch state, no §10.2 notification required. Annex A.7 retention split widened from a fixed 90-day hot tier to a customer-tunable hot tier with presets {90 / 180 / 365 / 730} days (default 90 standard plan, 365 enterprise / enterprise_trial / internal); reflects P0-AUDIT-RETENTION-TIER shipped 2026-05-24 (migrations 0144 + 0146). Plan-floor SLA disclosure clarified: enterprise = 365d queryable + 3y WORM baseline, standard = 90d + 3y; Customer admin may set the hot-tier below the plan floor (yes-by-design — admin UI permits, contract disclaims). Annex A.8 Sigstore prose updated to reflect Phase-5 closeout (sign.frem.sh + tsa.frem.sh live since 2026-05-23/24): keyless commit signing is enabled via fremverk\u0026rsquo;s self-hosted Fulcio + TSA on T Cloud eu-de (no Rekor); customers opt in per-tenant via auth-policy require_oidc_signed_commits. Annex A.4 new paragraph documents Customer-supplied presentation assets — public-docs wiki custom_css (8 KB, served verbatim to anonymous visitors when the per-repo opt-in is set; write/render-time \u0026lt; byte rejection, no CSS-level data-exfiltration block). §17.3 BYOK terminology clarified: \u0026ldquo;BYOK\u0026rdquo; in §17.3 refers to encryption-at-rest CMK custody (Phase 2 roadmap); \u0026ldquo;BYOK\u0026rdquo; in §B.8 refers to Customer-configured AI vendor API keys — the two senses are now distinguished, with §B.8 preferring the longer \u0026ldquo;Customer-configured AI vendor key\u0026rdquo; form. DPIA bumped 1.1 → 1.2 (Art-6(1)(f) re-balanced with 730-day worst-case bound); Privacy Notice bumped 1.9 → 1.10 with new §3.7 covering Customer-configured AI processing (data-subject Art-13/14 disclosure) + anonymous-visitor disclosure for public-docs wiki paragraph in §1; AUP gains §3.6A (anonymous-read on private-repo wiki + custom_css responsibility); Cookie Policy §3 adds the wiki anonymous-read surfaces row; ROPA §2.5 retention cell updated to two-tier shape. No change to Customer-data residency, no new sub-processor; suppliers.yaml gains a customer_ai_vendors_byok carve-out row (governance source-of-truth parity with Annex B §B.8 already there). 1.15 2026-05-25 Editorial cleanup — pre-launch state, no §10.2 notification required. (a) §10.2 delivery prose now cross-references the Notices procedure in Terms §20 including the bounce-and-second-attempt fallback (closes round-22 P2-LEG audit row); the §10.2 dual-channel mechanism itself, the 30-day advance window, the 15-day objection window, and the per-recipient audit-log delivery record are unchanged. (b) §11.1 Lettermint residency cell reformatted as a bulleted breakdown (operating entity / upstream IaaS) for clarity; the underlying jurisdictions and entities are identical to v1.9. (c) §11.1 new row added for the Operator IdP (Authentik) processing — same T Cloud eu-de region, same Deutsche Telekom AG sub-processor, deployed in platform-identity-prd enterprise project for blast-radius isolation per Annex A.3. Already covered by Annex A.3 prose since v1.5; now also explicit in the residency table for legibility. (d) §11.3 new closing paragraph cross-references Annex B §B.8 for Customer-configured AI vendors (BYOK), restating that their jurisdictional exposure is governed by the Customer\u0026rsquo;s own contract with the vendor and not by this DPA. No change to Customer-data residency, no new sub-processor, no obligations changed. ","externalUrl":null,"permalink":"/legal/dpa/","section":"Legal documents","summary":" title: fremforge Data Processing Agreement author: fremverk date: 2026-05-25 status: Published v1.14 version: “1.15” lang: en # Last updated: 2026-05-25\n","title":"fremforge Data Processing Agreement","type":"legal"},{"content":" title: fremforge Product Privacy Notice author: fremverk date: 2026-05-25 status: Published v1.10 version: \u0026ldquo;1.10\u0026rdquo; lang: en # Last updated: 2026-05-25\nEffective Date: 2026-04-25 — Current Version: 1.10 (effective 2026-05-25; full revision history in §Change log)\nThis notice supersedes the pre-launch marketing privacy policy for users of the hosted fremforge product at frem.sh. The marketing-site policy continues to cover visitors to www.frem.sh during and after launch.\n1. Who this notice is for # This privacy notice applies to you if you use the hosted fremforge product — that is, if you sign in to an organisation at frem.sh/\u0026lt;org\u0026gt; as a member, administrator, or owner, or if you use the public REST API at frem.sh/_app/api/v1/* as an authenticated user or via a registered agent.\nVisitors to www.frem.sh, docs.frem.sh, and status.frem.sh are covered by the separate marketing-site privacy policy. Those sites are anonymous, cookie-free, and collect no personal data beyond server-access logs needed for edge delivery.\nAnonymous visitors to public-docs wikis. If a tenant has opted in to anonymous public read of a repository wiki at frem.sh/\u0026lt;org\u0026gt;/\u0026lt;repo\u0026gt;/wiki[/...] (see Develop → Wiki and public docs), unauthenticated visitors to that surface are subject to this notice for the server-access logging only — no cookies are set, no authentication is required, no profiling is performed. Server-access logs capture IP, user-agent, requested path, and response status as part of normal edge-delivery telemetry; retention is the same as the §6 operational-logs retention (30 days hot, 3 years archive). The wiki content itself is published by the tenant Customer under their own determination of legal basis (typically legitimate-interest in publishing technical documentation); fremverk acts as hosting service provider under the DSA for that content. Custom CSS embedded by the tenant Customer in the wiki may include external-URL references (e.g. background-image: url(...)) — the tenant Customer is responsible for the privacy implications of any external URLs they reference; fremverk does not sanitise such references and does not control the third parties they reach.\n2. Data controller and privacy contact # fremverk ApS\nCVR: 39150689\nRingager 4C, 2. tv, 2605 Brøndby, Denmark\nEmail: compliance@frem.sh\nfremforge is a product brand of fremverk ApS. fremverk ApS is the legal and GDPR-responsible entity for all personal data processed in connection with the fremforge product.\nYour organisation (the tenant) is the data controller for repository content, issues, pull requests, CI logs, and member activity produced within its organisation. fremverk ApS processes that data as a processor under the Data Processing Agreement (DPA) signed with the tenant at signup.\nfremverk ApS is the data controller for account data, billing data, authentication metadata, audit logs, and other operational data required to run the fremforge service.\nData Protection Officer # fremverk ApS is not required to designate a Data Protection Officer under GDPR Art. 37, because its core activities do not involve (a) processing by a public authority, (b) large-scale regular and systematic monitoring of data subjects, or (c) large-scale processing of special-category or criminal-offence data. This assessment is reviewed annually or when material changes to the Service are made.\nThe privacy contact for all data-protection questions, data-subject requests under GDPR Chapter III, and supervisory-authority liaison is compliance@frem.sh, routed to the data protection-responsible partner at fremverk ApS. This mailbox is the functional equivalent of a DPO contact for the purposes of data-subject communications.\nIf, following review, a DPO designation becomes required, fremverk will update this notice with the DPO\u0026rsquo;s name and contact details.\nfremverk maintains a record of processing activities (ROPA) under GDPR Art. 30. The ROPA is reviewed annually and is available to the Danish supervisory authority on request.\n3. What we process, why, and on what legal basis # 3.1 Account and authentication # What: email address, display name, password hash (if local auth is used), OIDC/SAML subject identifiers and claims mapped from your identity provider, TOTP secret (if 2FA is enabled), recovery codes (stored as bcrypt hashes; the original code is shown to the user once at generation and is never reversibly stored), session and API token identifiers, user-agent and IP of authentication events. Why: to authenticate you and enforce the access model (per-org session binding, SSO enforcement, SSH authorization via your IdP session). Legal basis — where fremverk ApS is controller of this account data (the authentication record itself and its operational metadata): contractual necessity under the agreement between fremverk ApS and your organisation (GDPR Art. 6(1)(b)) together with the legitimate interest (Art. 6(1)(f)) of maintaining access control and security of the Service. Your organisation remains the controller of its relationship with you as a user of its instance; its own legal basis (typically employment contract or a user-facing terms of service) applies to its processing of your data via fremforge, and fremverk ApS processes on its documented instructions per the DPA. 3.2 Repository and collaboration content # What: repositories, commits, issues, pull requests, comments, labels, wiki pages, releases, package registry artifacts, CI workflow definitions, CI run logs, webhook delivery records, audit log entries, SLSA provenance attestations. Why: because that is the product — a Git forge with CI/CD. Legal basis: contractual necessity under the tenant\u0026rsquo;s DPA. The tenant is the controller of this content; fremverk ApS is the processor. 3.3 Billing and commercial data # What: organisation name, legal entity, VAT number, billing contact, billing address, payment method (via Mollie; fremverk ApS never sees raw card data), seat count history, invoice records. Why: to invoice the tenant and comply with Danish bookkeeping obligations. Legal basis: contractual necessity (Art. 6(1)(b)); legal obligation (Art. 6(1)(c)) for invoice retention. 3.4 Operational and security logs # What: authentication events, admin-UI actions, API calls, policy enforcement decisions (push protection blocks, rate-limit hits, SSRF-filter rejections), infrastructure-level logs (T Cloud CES/LTS, T Cloud APIG access logs, runner controller). Why: to operate the service securely, respond to incidents, and produce the audit-log export the tenant admin can pull on demand. Legal basis: legitimate interest (Art. 6(1)(f)) of fremverk ApS in maintaining service security and integrity; contractual necessity for audit-log availability to the tenant. 3.5 Cookies and local state # We set four strictly-necessary cookies on the authenticated product surface. No non-essential cookies. No analytics. No consent banner required under ePrivacy Directive Art. 5(3). Full inventory:\nCookie Purpose Class First-party Lifetime session Forgejo session state (authenticated login; cookie name on Forgejo 15+, previously i_like_gitea) Strictly necessary Yes Session _csrf CSRF token Strictly necessary Yes Session lang Language preference, user-triggered Strictly necessary Yes 1 year fremforge middleware session Per-org session binding (see trust page) Strictly necessary Yes 8h rolling www.frem.sh, docs.frem.sh, and status.frem.sh set zero cookies and contact no third-party operators. (The authenticated product surface at frem.sh and the status page each load brand fonts from https://www.frem.sh/fonts/ — same legal entity, same Bunny pull-zone, served from EU-only edges. No external CDN, no fonts.googleapis.com or equivalent. Per ePrivacy Article 5(3) this is not a third-party trace; per GDPR sub-processor disclosure, www.frem.sh is fremverk\u0026rsquo;s own surface, listed in DPA Annex B as part of the Bunny CDN sub-processor entry.)\nBrowser localStorage may hold UI preferences (theme, table density) set only in response to your explicit action in the admin UI. Never used for analytics, advertising, or cross-site tracking.\n3.6 Support correspondence — split by channel # 3.6 Support correspondence — split by channel.\n(a) Tenant support@frem.sh tickets: fremverk acts as processor on the Customer\u0026rsquo;s behalf for any personal data embedded in ticket bodies. Lawful basis (Customer side): performance of contract with the data subject or legitimate interest. Retention: 12 months from ticket closure.\n(b) abuse@frem.sh reports under DSA Art. 16: fremverk acts as controller. Lawful basis: legal obligation (Regulation (EU) 2022/2065 — Digital Services Act). Retention: 5 years (DSA Art. 24 transparency-reporting horizon).\n(c) security@frem.sh vulnerability reports: fremverk acts as controller. Lawful basis: legitimate interest in platform security (Art. 6(1)(f) GDPR, balancing test documented in fremverk\u0026rsquo;s ROPA). Retention: 24 months from report acknowledgement, or longer where actively used in defensive analysis.\n3.7 Customer-configured AI processing # If the Customer (the tenant admin) configures one or more AI vendors at Organisation admin → AI integrations, parts of repository content, pull-request diffs, issue text, and review prompts that you author may be sent through fremverk\u0026rsquo;s api to that AI vendor for processing. The AI vendor is chosen by the Customer, contracted directly between the Customer and the vendor, and is the Customer\u0026rsquo;s own processor — not a fremverk sub-processor (DPA Annex B §B.8).\nWhat this means for you as a data subject:\nThe Customer decides whether AI processing is enabled, which vendor (e.g. OpenAI, Anthropic, Google Vertex), and what prompts are sent. The Customer may choose a vendor incorporated outside the EU/EEA (including US-incorporated vendors); jurisdictional exposure of that processing is governed by the Customer\u0026rsquo;s own contract with the vendor, not by fremverk\u0026rsquo;s DPA. Prompts and responses transit fremverk\u0026rsquo;s api for routing + audit-trail emit only — fremverk does not retain the prompt or response body beyond the request lifecycle. The audit-trail emit records the call (timestamp, actor, vendor identifier, prompt-length / response-length) but not the prompt body. fremverk\u0026rsquo;s commitment in AUP §3.7 (no training on Customer Content) applies to fremverk and its appointed sub-processors. It does not bind the Customer\u0026rsquo;s chosen AI vendor — the Customer is responsible for ensuring its chosen vendor\u0026rsquo;s terms align with the Customer\u0026rsquo;s own AI-training-data posture. If you want to know whether your tenant has AI processing enabled and which vendor, ask your tenant admin or contact fremverk per §15. 4. Where the data is processed # Surface Processor Region Forgejo UI, Git, API, package registry, CI runners T Cloud (Deutsche Telekom) eu-de (Biere/Magdeburg, DE) Marketing, docs, status Bunny CDN EU PoPs only Outbound transactional email (magic-links, password resets, system notifications, billing) Lettermint B.V. Zwolle, Netherlands Inbound shared-mailbox correspondence (support@, abuse@, etc.) Heinlein Hosting GmbH (mailbox.org) Berlin, Germany Payments Mollie Netherlands Billing engine fremforge in-monolith engine (self-hosted by fremverk) eu-de (T Cloud) Issuance and 5-year statutory retention of invoice bilag under Bogføringsloven §10 — receives org legal name, billing-contact email, VAT number, invoice line items, and Mollie payment-id reference. No repository content, no audit-log content, no PAN. Visma Dinero Denmark Every processing surface is operated by entities with no US parent. Full sub-processor list, including each sub-processor\u0026rsquo;s certifications, is maintained on the trust page.\n5. CLOUD Act / US extraterritorial-law posture # fremforge has no CLOUD Act exposure on any processing path. All Customer Personal Data — repositories, CI runs, audit logs, authentication, billing, payment-instrument data, outbound transactional email, and inbound shared-mailbox correspondence — is processed by entities with no US parent: Deutsche Telekom AG inside Germany, Heinlein Hosting GmbH inside Germany, Mollie B.V. in the Netherlands, Lettermint B.V. in the Netherlands, and Bunny CDN at EU edge PoPs only.\nfremverk ApS is a Danish entity. Neither fremverk ApS 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. See DPA §11.3 for the full posture.\nSchrems II transfer assessment: not applicable. No Customer Personal Data is transferred outside the EEA on any processing path.\n6. Retention # Account data: for the lifetime of your active membership in a fremforge organisation. Deleted within 30 days of your removal from all organisations, subject to any legal-hold obligations. Repository and collaboration content: for the lifetime of the tenant\u0026rsquo;s subscription. On tenant offboarding, retained for 60 days to allow full export (Terms §16.5), hard-deleted from primary storage within 30 days thereafter, and purged from live-tier backup stores within a further 30 days (DPA §9). Total time from termination to live-tier backup-purge completion is up to 120 days. Disaster-recovery tier: in addition to the live-tier retention above, fremverk holds a separate DR-tier of monthly snapshots with 13-month retention (DPA Annex A.9) for catastrophic-recovery scenarios; these snapshots are sealed, fremverk-side-only, and used only to restore the platform after a catastrophic failure. Personal data inside DR-tier snapshots is purged on the rolling 13-month schedule independent of tenant offboarding. Operational logs (HTTP, runner, infrastructure): 30 days hot, 3 years immutable archive. Authentication and security audit events: queryable hot tier per tenant choice (90 / 180 / 365 / 730 days; default 90 — enterprise plans default 365); 3 years immutable archive (hash chain only — payload redacted after the hot-tier cutoff). Tenant admins on enterprise plans set the hot-tier window at Authentication policy → Audit log retention. Data-subject access requests against a row past the hot-tier cutoff return the redacted record (chain hashes remain verifiable). Billing records: 5 years per Bogføringsloven. Closed support tickets: 12 months. DSA abuse reports: 5 years (DSA Art. 24). Audit-log exports initiated by the tenant: 7 days in the signed OBS bucket from which the tenant downloads, then purged. Waitlist data (legacy from pre-launch): purged at launch + 90 days, or earlier on request. 7. Your rights # Under GDPR (Chapter III), you have the right to:\nAccess (Art. 15) — obtain confirmation that we process data about you and a copy of it. Rectification (Art. 16) — correct inaccurate data. Erasure (Art. 17) — have your personal data erased, subject to legal retention obligations. Restriction of processing (Art. 18) — limit how we use your data in specific circumstances. Portability (Art. 20) — receive your personal data in a structured, machine-readable format. For fremforge tenant data, the self-service signed export provides this at org level; for your individual account data, contact compliance@frem.sh. Objection (Art. 21) — object to processing based on legitimate interests. Withdrawal of consent (Art. 7(3)) — where we rely on consent, withdraw it without affecting the lawfulness of prior processing. Complaint to a supervisory authority (Art. 77). How to exercise: email compliance@frem.sh. We respond within 30 days (Art. 12(3)). For requests that involve repository or collaboration content owned by your organisation, we will route you to the organisation\u0026rsquo;s administrator where fremverk ApS acts as processor only.\nYour organisation\u0026rsquo;s controller obligations: if your organisation is a GDPR controller in the EU, it has separate obligations to you directly under GDPR. fremverk ApS cannot answer controller-level data-subject requests on your employer\u0026rsquo;s behalf; the DPA defines the hand-off.\n8. Sub-processors # The current sub-processor list is maintained on the trust page and updated with 30 days\u0026rsquo; advance notice of any change, per the standard DPA clause.\nAt the date of this notice, the sub-processors are:\nSub-processor Purpose Location Certifications Deutsche Telekom AG (T Cloud) Core compute, storage, network, CI runners Biere/Magdeburg, DE ISO 27001, 27017, 27018; BSI C5 Type 2; TISAX Bunny CDN d.o.o. Edge delivery, WAF, DDoS EU PoPs (HQ Slovenia) ISO 27001 (2025), SOC 2 (2023) Lettermint B.V. Outbound transactional email Zwolle, Netherlands Vendor certifications pending evidence (NL — no US parent); upstream OVHcloud SAS (France) and UpCloud Ltd (Amsterdam, NL) — both EU-only Heinlein Hosting GmbH (mailbox.org) Shared-mailbox hosting (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlin, Germany ISO 27001; BSI C5; BSI IT-Sicherheitskennzeichen (TR 03108) Mollie B.V. Payment processing Amsterdam, NL PCI-DSS Level 1 Visma Dinero ApS Issuance and 5-year statutory retention of invoice bilag under Bogføringsloven §10 — receives org legal name, billing-contact email, VAT number, invoice line items, Mollie payment-id reference. No repository content, no audit-log content, no PAN. Copenhagen, DK ISO 27001 (DK — no US parent) P1-LEG-09: VIES (the EU Commission\u0026rsquo;s VAT-number validation service at https://ec.europa.eu/taxation_customs/vies/) is contacted at signup time to validate Customer-supplied VAT identifiers and qualify the reverse-charge mechanism. VIES is a non-commercial public-sector service operated by the European Commission and is not a sub-processor under Article 28: the only data submitted is the VAT identifier (a business-registration number, not personal data of the data subject), and lookup results (valid / invalid / unavailable) are stored against the tenancy record. Disclosed for transparency.\nP1-LEG-10: Simply.com A/S (DK) is the registrar + DNS provider for the brand-redirect domains fremforge.com, fremforge.eu, fremforge.dk (all 301-redirect to www.frem.sh). No Customer Personal Data transits Simply.com — only DNS lookups for the redirect targets. Listed for transparency; not a sub-processor under Article 28 (DNS is generally treated as utility infrastructure, equivalent to internet routing). The product domain frem.sh and customer-facing surfaces use BunnyDNS (Bunny CDN d.o.o., Slovenia — same sub-processor as the CDN/WAF/edge tier, already disclosed in Annex B row 2) for DNS — no Simply.com dependency on the customer-facing path.\nBunny: EU-only edge configured at pull-zone level; geo-replication outside EU disabled.\nMollie: Card-network sub-sub-processors (Visa Europe Services Inc. UK branch — parent Visa Inc. is US; Mastercard Europe SA — Belgium) operate under PCI-DSS. The Visa Inc. parent caveat is disclosed in DPA §11.3. Customers preferring zero US-parent exposure on the payment path may pay by SEPA Direct Debit.\n9. Security # Technical and organisational measures include, but are not limited to:\nTLS 1.2+ on every customer-facing surface. The certificates served at the public edge (frem.sh, www.frem.sh, etc.) are managed by Bunny CDN\u0026rsquo;s integrated certificate provisioning. The internal origin-TLS pipeline (Bunny edge → fremforge load balancers) uses certificates issued by Actalis S.p.A. (Italy, Aruba Group), an eIDAS Qualified Trust Service Provider on the EU Commission\u0026rsquo;s Trusted List under Regulation 910/2014. The CA receives only the FQDN being certified (*-origin.frem.sh) — never customer personal data — and is therefore not a sub-processor under Article 28 (same posture as VIES). See DPA Annex B for the full disclosure. AES-256 encryption at rest for repositories, databases, object storage, and backups, with keys managed in T Cloud DEW (Data Encryption Workshop). Scoped service accounts for every control-plane function; no super-admin tokens in normal operation. Mandatory MFA for platform administrators and break-glass accounts. Immutable audit log with tamper-evident hash chaining, anchored to OBS WORM storage. Pre-receive secret scanning on every push; dependency scanning on every PR; signed commits via OIDC identity (optional); SLSA provenance on build artifacts. Hosted runners run as per-pod kernel-isolated (T Cloud CCI) serverless containers; no shared kernel between tenant jobs. SSRF hardening on every outbound path: per-pod VPC Security Group egress allowlist (Cloud Native Network 2.0) + a forced outbound-proxy CONNECT tunnel with SSRF deny-set + an app-layer SSRF guard; the three layers compose such that no tenant-influenced code path can bypass them. Published security-patching SLA: Critical CVEs (CVSS ≥ 9.0) patched within 48 hours of upstream fixed release, High (7.0–8.9) within 72 hours, Medium (4.0–6.9) within 7 days, Low at the next scheduled maintenance window (see trust page §Security patching). This SLA is cited verbatim in the DPA security annex. Details and additional measures are documented in the DPA security annex.\n10. International transfers # No Customer Personal Data is transferred outside the EEA on any processing path. All processing — repositories, CI runs, audit logs, authentication metadata, billing, payments, outbound transactional email (Lettermint B.V., Zwolle, Netherlands), and inbound shared-mailbox correspondence (Heinlein Hosting GmbH / mailbox.org, Berlin, Germany) — takes place inside the EU/EEA at entities with no US parent. No Article 46 GDPR safeguard is required.\n11. Profiling and automated decision-making # fremforge does not subject you to automated decisions producing legal or similarly significant effects on you (GDPR Art. 22). Automated decisions within the product — push-protection rejection of a commit containing a secret, merge-block on a CRITICAL dependency CVE, rate-limiter throttle on abusive traffic — are product rules that affect commits and requests, not data subjects, and can be reviewed or overridden by the tenant administrator per the policy hierarchy. Customer-configured AI features (§3.7) are similarly tenant-admin-controlled product rules: the tenant admin chooses whether AI processing is enabled and which vendor receives prompts; fremverk does not initiate AI processing on data subjects without the Customer\u0026rsquo;s explicit configuration.\nThe automated controls described above (commit push-protection, CI policy gates, dependency-scan blocks) do not produce legal or similarly significant effects on the data subject within the meaning of Art. 22(1): the controls operate on the technical content of a Git or CI request, not on the person, and the Customer\u0026rsquo;s tenant administrator can review and override every decision through the audit log and the policy-override workflow described in the documentation.\n12. Children # The Service is not directed to children. Where Customer Content includes personal data of a child, the Customer is responsible for the legal basis. The Danish digital-consent age under Databeskyttelsesloven §6(3) is 13; some other EU member states set 16. Customers should configure their organisations consistently with the age in the data subject\u0026rsquo;s member state.\nfremforge is a B2B product and is not directed to children. We do not knowingly collect data from children. If you believe a child has signed up or been added as a member, contact compliance@frem.sh.\n13. Supervisory authority # Datatilsynet (Danish Data Protection Agency)\nCarl Jacobsens Vej 35, 2500 Valby, Denmark\nPhone: +45 33 19 32 00\nWebsite: datatilsynet.dk\nEmail: dt@datatilsynet.dk\nYou may also lodge a complaint with the supervisory authority in your own EU member state.\n14. Changes to this notice # We may update this notice from time to time. Material changes are announced through two parallel channels so a Customer who watches either channel learns of changes: (a) the trust page (Watch the trust page or its RSS feed for in-product changes) AND (b) direct email to each Customer\u0026rsquo;s designated billing contact for changes affecting the legal basis of processing or adding a sub-processor. Both channels deliver at least 30 days\u0026rsquo; advance notice for material changes — the dual-channel mechanism guarantees notification even if one channel is missed (mailing-list opt-out, billing-contact email change, etc.). The effective date at the top of this page reflects the last meaningful content change. Prior versions are retained in Git and available on request.\nAnnex A — Processing activities by role # If you are… You interact with Legal basis summary A member of a tenant org Repository, CI, issues; your own account data; session cookies Tenant DPA (content); contractual necessity (account) An admin of a tenant org As above, plus: seat management, policy configuration, audit log view, export Same; admin actions are audit-logged against your identity An owner of a tenant org As above, plus: org-level policy, SSO configuration, OIDC federation, tenant lifecycle Same A visitor to public repos (if enabled) Public-repo content; no session cookies unless you sign in Legitimate interest of the tenant as controller of the public repo A prospect signing up for a trial 30-day trial org creation; credit-card mandate via Mollie Pre-contractual steps (Art. 6(1)(b)); consent for marketing contact An AI agent acting on your behalf (Phase 2+) As your role permits, under the scope of the delegated mandate you issued Same basis as your own role; actions logged as actor=agent:\u0026lt;id\u0026gt;, on_behalf_of=\u0026lt;user_id\u0026gt; Annex B — Contact quick reference # Privacy questions, data-subject requests: compliance@frem.sh General support: support@frem.sh Security vulnerabilities: security@frem.sh Abuse reports (DSA Art. 16): abuse@frem.sh Legal and law-enforcement contact: compliance@frem.sh Commercial inquiries: hello@frem.sh Change log # Versions track the DPA change-log — substantive sub-processor or processing-purpose updates published in the DPA are reflected here in the same numbered version, on the same effective date.\nVersion Date Change 1.0 2026-04-25 Initial publication. 1.1 2026-04-27 Heinlein Hosting GmbH (mailbox.org, Berlin) added to the sub-processor table for inbound shared-mailbox correspondence; Annex section listing operator mailboxes expanded (initially 4 → 6 boxes; finalised at 8 in v1.5 below). Mirrors DPA v1.1. 1.2 2026-05-03 Clarified that the self-hosted PoW captcha and Authentik are self-hosted (not Article-28 sub-processors) and that the EU Commission\u0026rsquo;s VIES VAT-validation service is a non-commercial public-sector lookup, not a sub-processor — disclosed for transparency only. Mirrors DPA v1.2. (Captcha implementation switched from mCaptcha to Altcha on 2026-05-09 per DPA v1.7; both are self-hosted, neither is a sub-processor.) 1.3 2026-05-04 Disclosed origin-TLS Certificate Authority Actalis S.p.A. (Italy, Aruba Group, eIDAS QTSP). Posture: the CA receives only FQDNs (not personal data) and is not a sub-processor under Article 28. Mirrors DPA v1.3. 1.4 2026-05-06 Added Visma Dinero ApS (Denmark) to the sub-processor table. fremverk transmits the customer\u0026rsquo;s org legal name, billing-contact email, VAT number, invoice line items, and Mollie payment-id reference into Dinero for issuance and 5-year statutory retention of bilag under Bogføringsloven §10. No repository content, no audit-log content, no PAN. Mirrors DPA v1.4. (Wording revised 2026-05-16 to align with DPA Annex B language — previous summary said \u0026ldquo;fremverk-side bookkeeping, no Customer Personal Data path\u0026rdquo;, which understated the personal-data flow enumerated in the DPA.) 1.5 2026-05-08 Round-7 transparency updates: Simply.com A/S (DK) listed as registrar/DNS provider for the brand-redirect domains fremforge.com / .eu / .dk (no Customer Personal Data path; not a sub-processor under Article 28); the operator-mailbox enumeration finalised at 8 mailboxes (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) following the consolidation that retired the reserved-name aliases (legal@ / privacy@ / gdpr@) into compliance@; Visa Inc. card-network footnote added to the no-US-CLOUD-Act-exposure framing on the payments path (the card scheme is unrelated to controller/processor data flows under Article 28); Brevo / Sendinblue SAS cap-table footnote softened to acknowledge US growth investors without changing the no-US-parent framing. Mirrors round-7 DPA edits in the same version range. 1.6 2026-05-08 Mirror update of DPA v1.6: security-testing posture aligned with industry-norm EU-sovereign-SaaS DPA wording. DR drill cadence stated as \u0026ldquo;at least annually and on material change to the recovery design\u0026rdquo; (Enterprise-on-Demand may agree a tighter cadence in the Order Form). Fixed-cadence external-pentest commitment removed at the standard tier; pentest reports remain available under NDA when commissioned, and Enterprise-on-Demand contracts may agree a specific testing cadence in the Order Form. No change to GDPR Art. 32(1)(d) regular-testing posture and no change to Customer Personal Data flows. 1.7 2026-05-09 Bot-mitigation captcha implementation switched from self-hosted mCaptcha to self-hosted Altcha (MIT-licensed, HMAC-signed PoW, in-app at frem.sh/_app/altcha/challenge with widget bundle at frem.sh/_app/static/altcha.js). No new sub-processor; no change to Customer Personal Data flows. Mirrors DPA v1.7. 1.8 2026-05-14 Outbound transactional email sub-processor changed: Sendinblue SAS (Brevo) decommissioned 2026-05-14; replaced by Lettermint B.V. (Zwolle, NL — KvK 80706290) on the outbound transactional-email path. Sub-processor table (§4 surface map, §8 sub-processor list) and CLOUD Act enumeration (§5) updated. Sovereignty posture improved: Lettermint\u0026rsquo;s upstream is OVHcloud SAS (France) and UpCloud Ltd (Amsterdam, NL) — EU-only entities throughout, in contrast to Brevo\u0026rsquo;s prior Google Cloud europe-west1 dependency and the November 2025 LBO that put General Atlantic (US PE) at ~25% co-control of Sendinblue SAS. Lettermint vendor certifications pending evidence; no US-parented processor on the email path. No change to data categories processed (recipient email + body content + delivery metadata, same shape). Mirrors DPA v1.9. 1.9 2026-05-17 §14 channel-of-record clarified to dual-channel (trust page + direct email to billing contact) for material changes — both channels carry the 30-day advance-notice commitment, so a Customer watching either channel learns of changes. Mirrors DPA v1.10\u0026rsquo;s dual-channel mechanism. No change to data categories or sub-processor list. 1.10 2026-05-25 Three coordinated changes. §6 retention reframed for two-tier audit-log retention (customer-tunable hot tier 90 / 180 / 365 / 730 days, default 90 standard / 365 enterprise; 3-year WORM hash-chain archive with payload redacted at hot-tier cutoff). Mirrors DPA v1.14 + DPIA v1.2. §3.7 added — Customer-configured AI processing (Art 13/14 data-subject disclosure): the tenant Customer admin may enable AI vendors at Organisation admin → AI integrations; those vendors are the Customer\u0026rsquo;s processors (not fremverk\u0026rsquo;s sub-processors per DPA §B.8); the vendor may be US-incorporated at the Customer\u0026rsquo;s choice; the AUP §3.7 no-AI-training commitment binds fremverk and fremverk-appointed sub-processors only. §11 footnote referencing §3.7. §1 anonymous public-docs wiki disclosure added (server-access logs only, no cookies; tenant-Customer-controlled CSS may reference external URLs at the tenant\u0026rsquo;s responsibility). Mirrors AUP §3.6A and Cookie Policy §3. No new sub-processor; no change to fremverk\u0026rsquo;s own residency posture. ","externalUrl":null,"permalink":"/legal/privacy-product/","section":"Legal documents","summary":" title: fremforge Product Privacy Notice author: fremverk date: 2026-05-25 status: Published v1.10 version: “1.10” lang: en # Last updated: 2026-05-25\n","title":"fremforge Product Privacy Notice","type":"legal"},{"content":" title: fremforge Service Level Agreement author: fremverk date: 2026-05-25 status: Published v1.2 version: \u0026ldquo;1.2\u0026rdquo; lang: en # Last updated: 2026-05-25\nEffective Date: 2026-04-25 — Current Version: 1.2 (effective 2026-05-25; full revision history in §Change log)\nThis Service Level Agreement (\u0026ldquo;SLA\u0026rdquo;) forms part of the Terms of Service between fremverk ApS and the Customer. It applies to the standard fremforge plan at frem.sh. Enterprise-on-Demand contracts may contain different or additional SLA commitments as agreed in an ordering document; in case of conflict, the ordering document prevails.\n1. Scope # This SLA defines the availability commitment for the fremforge service, how availability is measured, what is excluded from the measurement, the service-credit remedies when the commitment is not met, and how the Customer claims credits.\n2. Availability commitment # 2.1 Target # fremverk commits to 99.5% Monthly Service Availability for the in-scope surfaces defined in §3, measured calendar-monthly (first to last day of each calendar month, UTC).\n99.5% per calendar month allows approximately 3 hours 40 minutes of Downtime per month. This commitment is realistic for a service self-healing well under T Cloud\u0026rsquo;s native redundancy (CCE HPA, RDS cross-AZ automatic failover, ELB-managed certificates) operated by a small team during business hours. Incidents outside business hours are typically resolved automatically or shortly after the next business window.\n2.2 Upper bound # The commitment is deliberately below the composed theoretical ceiling of the T Cloud services in the critical path (RDS, CCE, DCS, OBS, SFS Turbo, ELB — each ~99.9% per-service, lower when composed serially). 99.5% leaves room to absorb a single meaningful T Cloud incident per month without breaching the SLA. Customers requiring stricter commitments should subscribe to the Enterprise-on-Demand tier.\n3. In-scope surfaces # The commitment applies to the following authenticated and unauthenticated production surfaces at frem.sh:\nForgejo web UI — sign-in, repository browsing, issues, pull requests, wiki, releases, admin console. Git over HTTPS — git clone, git fetch, git push at https://frem.sh/\u0026lt;org\u0026gt;/\u0026lt;repo\u0026gt;.git. Git over SSH — the same over git@ssh.frem.sh:\u0026lt;org\u0026gt;/\u0026lt;repo\u0026gt;.git at ssh.frem.sh:443 (port 443 mapped to in-cluster SSHd; port 22 is not publicly exposed on the apex domain). Package registry API — npm, Maven, Docker, NuGet, PyPI, RubyGems, Composer, Go endpoints at their respective routes under frem.sh. Control-plane REST API at frem.sh/_app/api/v1/*. fremforge admin UI at frem.sh/_app/\u0026lt;slug\u0026gt;/_admin (per-tenant — URL Option B per plan.md). Out of scope for the 99.5% commitment (each has its own availability model, stated below):\nHosted CI runners — best-effort dispatch to T Cloud CCI; measured separately (§4). Status page at status.frem.sh — independently hosted in fremforge-status-prd for blast-radius isolation; best-effort and unmeasured under this SLA. Marketing site at www.frem.sh — best-effort and unmeasured under this SLA. Documentation site at docs.frem.sh — best-effort and unmeasured under this SLA. Transactional email — outbound delivery subject to Lettermint B.V. own SLA; inbound shared-mailbox hosting subject to Heinlein Hosting GmbH (mailbox.org) own SLA. fremverk\u0026rsquo;s own SLA does not extend to either sub-processor\u0026rsquo;s own service availability. 3A. Audit-log retention by plan # The two-tier audit retention model in DPA Annex A.7 carries the following SLA floors per plan:\nPlan Queryable hot-tier (default) Queryable hot-tier (SLA floor) WORM hash-chain archive Standard 90 days 90 days 3 years Enterprise-on-Demand / enterprise_trial / internal 365 days 365 days 3 years A Customer tenant admin may set the hot-tier retention via Authentication policy → Audit log retention anywhere in the permitted range (presets 90 / 180 / 365 / 730 days; database CHECK enforces 1–730). Setting the hot-tier below the plan\u0026rsquo;s SLA floor is permitted by the admin UI but disclaims the contractual queryability commitment for the affected period — yes-by-design technical permit, contractual constraint enforced by this SLA. The 3-year WORM hash-chain archive is unilateral and is not customer-tunable downward (see DPA Annex A.7 for the upward-extension request path).\n4. Hosted runner dispatch # fremverk commits on reasonable commercial efforts to dispatch queued CI jobs within 5 minutes of queue entry under normal platform load, subject to the per-organisation fair-use concurrency limits described in the AUP §4 and the global platform concurrency cap. Sustained queue-wait times beyond 5 minutes during nominal platform load are a signal that additional reserved capacity may be warranted — the remedy is commercial, via Enterprise-on-Demand, rather than a service credit under this SLA.\n5. Measurement # 5.1 Method # Availability is measured using synthetic probes (SLI probes) that run from independent EU-hosted locations against the in-scope surfaces. The methodology is summarised on the trust page and applied as follows:\nMultiple probes per surface per minute. A three-probe-agreement rule: Downtime is counted only when at least three independent probes from at least two independent locations report failure within the same minute. This prevents a single probe\u0026rsquo;s transient network issue from inflating the Downtime calculation. Probe results and historical availability are published on status.frem.sh with 90 days of on-page history and 3-year internal retention. 5.2 Downtime # A Minute of Downtime is any minute where the three-probe-agreement rule reports the in-scope surface as failing (HTTP 5xx, connection refused, TLS handshake failure, timeout exceeding 30 seconds, or Git protocol-level failure) on an end-to-end probe.\nMonthly Service Availability is computed as:\nMSA = ((Total Minutes in Month − Excluded Minutes − Minutes of Downtime) / (Total Minutes in Month − Excluded Minutes)) × 100% where Excluded Minutes are the minutes excluded under §6.\n5.3 Authoritative source # The measurement recorded on status.frem.sh is the authoritative source for this SLA, supplemented by T Cloud service-health events and fremverk incident records. In case of dispute, fremverk provides raw probe data covering the claimed period on request.\nWhere the status page itself is unavailable, the authoritative measurement source falls back to T Cloud Cloud Eye (CES) availability data and fremverk\u0026rsquo;s internal T Cloud LTS observability stack for the affected period. fremverk publishes the fallback data within 7 business days of the incident.\n5.3.1 Fallback measurement procedure (P2-SRE-30) # When the status-page record itself is part of the outage (e.g., a regional-storage event that hits both the customer-facing surface and the status page\u0026rsquo;s OBS origin), uptime is reconstructed from three independent records, in this order of preference:\nCES availability metric for each customer-facing ELB / APIG / CCE service (SYS.ELB.healthy_servers, SYS.APIG.api_calls, SYS.CCE.node_status) at 1-minute granularity. CES retains 5 days of 1-minute resolution + 1 year at 5-minute resolution; this scope covers any plausible monthly-billing-cycle reconstruction. LTS log-line presence in the api / Forgejo / runner streams. A continuous gap of \u0026gt;= 60 seconds with zero log lines on a service that normally writes thousands per minute is treated as a full-minute downtime mark for that service. Updown.io external probe history (87 Seconds SARL, France — SIRET 530 700 010 00037; trading as updown.io; EU-only PoPs — a third independent failure domain outside T Cloud). The 5 SEV-1 probes (api healthz, Forgejo, Kuma, marketing, Authentik) at 60s cadence form the third-line authoritative source where CES + LTS are also unavailable. Probe records are exportable per probe via the updown.io API and retained for the SLA-relevant period. Reconstruction picks the most conservative of the available sources (i.e. the longer downtime number that benefits the customer in a credit calculation). A reconstruction summary is published as a status-page post-incident report within 7 business days; the underlying CES + LTS + updown.io exports are made available to the affected Customer under NDA on request.\nIf all three sources are simultaneously unavailable for the period (a fremforge-and-T-Cloud-system-of-record-and-EU-external-probe event), fremverk reconstructs from external T Cloud regional-status events plus customer-side reports and treats the reconstruction as a good-faith estimate; the affected Customer may dispute and the dispute is resolved per §11 Service-credit dispute.\n5.4 Operator runbooks supporting this section (bidirectional reference) # The runbooks at runbooks/ in the repository are the operator-side counterpart to this SLA. The bidirectional reference makes the chain auditable: this SLA promises customer outcomes; the runbooks describe the procedures operators follow to deliver them.\nSLA topic Runbook Incident response procedure (this §5 + §8) oncall-rota.md (operator runbook, available under NDA via compliance@frem.sh), incident-comms-template.md Status-page post-incident publication (§5.3 + §8.4) oncall-page-test.md (operator runbook, available under NDA via compliance@frem.sh), post-mortem-template.md Annual restore drill (Annex A.9 — DPA cross-ref) annual-restore-drill.md (operator runbook, available under NDA via compliance@frem.sh), dr-drill-log.md (operator runbook, available under NDA via compliance@frem.sh), rds-snapshot-verifier.md (operator runbook, available under NDA via compliance@frem.sh) Regional outage (T Cloud eu-de) tcloud-region-outage.md (operator runbook, available under NDA via compliance@frem.sh) api / Forgejo deploy rollback during incident api-deploy-rollback.md (operator runbook, available under NDA via compliance@frem.sh), forgejo-down.md (operator runbook, available under NDA via compliance@frem.sh) Each cited runbook in turn links back to this section (legal/sla.md §5) in its header so an operator opening a runbook understands the SLA commitment driving the procedure.\n6. Exclusions # The following are excluded from the Downtime calculation and do not count against the availability commitment:\n6.1 Scheduled maintenance # Scheduled maintenance announced at least 48 hours in advance via the status page and email to the Customer\u0026rsquo;s admin-of-record, within the weekly maintenance window of Tuesday 02:00–04:00 UTC. Scheduled maintenance outside the weekly window counts against Downtime unless announced at least 7 days in advance with Customer acknowledgment.\nCap on excluded maintenance. Scheduled maintenance under this clause is excluded from the Monthly Service Availability calculation up to a maximum of 10 hours per calendar month, with a rollover of unused weekly windows up to 12 hours in any single month (so a quiet month carries headroom into a busier one — e.g. a CCE major-version upgrade or RDS engine bump that exceeds the standard 2-hour weekly slot). Maintenance hours beyond the 12-hour ceiling count as Downtime for service-credit purposes. Emergency security maintenance (urgent CVE patching, active-attack mitigation) is excluded without cap, but each instance is reported with a post-incident summary on status.frem.sh within 7 business days.\nThe 10-hour baseline + 12-hour rollover ceiling supersedes the prior flat 8-hour cap (audit P2-SRE-26, closed 2026-05-09): four 2-hour weekly windows = 8 hours nominal, leaving zero margin for a single over-run on busy months. The new shape gives a 2-hour buffer in normal months and a 4-hour buffer when rollover is available, matching typical operational shape (months are quiet most of the year; bursts come during CVE waves or planned platform-version upgrades).\n6.2 Emergency maintenance for security patches # Out-of-band emergency maintenance required to apply a security patch within the published CVE patch SLA (48h / 72h / 7d / next window), to the extent the patch requires brief service interruption. These windows are minimised wherever possible; security patches are not deferred to honour the weekly maintenance window.\nSecurity-patching commitment (commercially reasonable efforts). During Phase 1, fremverk uses commercially reasonable efforts to patch CVEs against the following targets, measured from upstream fixed release: Critical (CVSS ≥ 9.0) within 72 hours, High (7.0–8.9) within 7 days, Medium (4.0–6.9) within 14 days, Low at the next scheduled maintenance window. From Phase 2 (concurrent with the funded 24/7 on-call rotation, targeted 2027-Q1), fremverk commits to the contractual targets in DPA Annex A.8 (Critical 48h / High 72h / Medium 7d / Low next maintenance). Failure to meet the Phase 1 commercially-reasonable target is not a Service Credit event and is not a material breach for Terms §16.4; failure to meet the Phase 2 targets is a material breach as set out in Terms §13.1.\n6.3 Events outside fremverk\u0026rsquo;s reasonable control # Force-majeure events outside fremverk\u0026rsquo;s reasonable control are excluded from Monthly Service Availability calculation only where the event meets the definition of force majeure in Terms §18 as carved out by the listed non-FM events in §18 (in particular, outages of fremverk\u0026rsquo;s contracted sub-processors — including T Cloud, Bunny CDN, Lettermint B.V., Heinlein Hosting / mailbox.org, Mollie, and Visma Dinero — are NOT excluded as force majeure and remain fremverk\u0026rsquo;s commercial risk).\nFailures caused by the Customer\u0026rsquo;s own configuration, usage, or infrastructure — including but not limited to a misconfigured OIDC identity provider, a Customer-owned webhook receiver that is down, DNS changes made by the Customer outside its frem.sh tenant, or Customer-side client issues. Failures caused by the Customer\u0026rsquo;s breach of the AUP or by enforcement actions taken under it. Failures caused by a Customer BYO-runner that is down or misconfigured. 6.4 Third-party dependencies not in the critical path # Excluded from Monthly Service Availability calculation: brief unavailability of third-party services that the Customer has integrated (Customer-configured webhooks, Customer-side IdPs, Customer-side payment failures), and brief unavailability of fremverk\u0026rsquo;s own non-critical-path third-party providers (e.g. Mollie outages affecting new-signup flows but not existing-tenant Service availability).\n7. Service credits # 7.1 Credit schedule # If the Monthly Service Availability for a calendar month falls below 99.5%, the Customer is entitled to a service credit against the next invoice:\nMonthly Service Availability Service Credit (of monthly Fees for the affected month) ≥ 99.5% 0% — commitment met ≥ 99.0% and \u0026lt; 99.5% 10% ≥ 95.0% and \u0026lt; 99.0% 25% \u0026lt; 95.0% 50% 7.2 Cap # Service credits under this SLA are capped at 50% of the monthly Fees for the affected calendar month, regardless of the calculated amount.\nThe 50% cap above applies to standard Subscriptions. For severe outages — Monthly Service Availability below 90% in any month — the credit is 75% of monthly Fees for that month. Enterprise-on-Demand Subscriptions may negotiate a 100% credit cap on Order Form.\n7.3 Sole remedy # Service credits are the Customer\u0026rsquo;s sole and exclusive remedy for breach of this SLA. This clause does not limit fremverk\u0026rsquo;s liability under the Terms of Service for matters outside the scope of the SLA (for example, a personal-data breach is governed by the DPA and Terms §14.4).\n7.4 No cash refund # Service credits are applied to the next invoice and may not be converted to cash. If the agreement terminates with unused service credits, the credits are applied to any remaining invoice and the balance (if any) is forgone. In the case of termination by fremverk for convenience under Terms §16.3, unused credits are refunded pro rata alongside any prepaid unused Fees.\n7.5 Enterprise-on-Demand # Enterprise-on-Demand contracts may negotiate stricter thresholds (up to 99.95%), a higher credit cap, or additional remedies in the ordering document.\n7.6 Chronic breach # If Monthly Service Availability is below 99.0% for 3 consecutive months or for any 4 months within any rolling 12-month period, the Customer may terminate the affected Subscription for cause by written notice within 30 days of the third (or fourth) qualifying month, with pro-rata refund of any prepaid unused Fees. This termination right is in addition to (not in lieu of) the service credits owed for the qualifying months.\n8. Claiming service credits # 8.1 Claim process # To claim a service credit:\nThe Customer submits a claim via a support ticket to support@frem.sh with subject line starting SLA CREDIT CLAIM and the affected calendar month. The claim includes: the organisation slug, the calendar month concerned, the Customer\u0026rsquo;s measurement of Downtime or a reference to status.frem.sh, and (optionally) a list of incidents the Customer believes count. fremverk responds within 15 business days with the measured Monthly Service Availability, the applicable credit (if any), and the invoice to which the credit will be applied. 8.2 Deadline # Claims must be submitted within 30 days of the end of the affected month. The deadline is extended to 90 days where fremverk has published a post-mortem on status.frem.sh for the underlying incident; in that case the post-mortem URL is sufficient evidence for the claim.\n8.3 Good-faith cooperation # The Customer is expected to cooperate in good faith and not double-count incidents, claim for excluded minutes, or claim for failures on the Customer\u0026rsquo;s side of the integration boundary. fremverk will publish incident post-mortems on the status page for incidents affecting availability to allow Customer cross-reference.\n9. Incident communication # During an active incident affecting any in-scope surface in §3, fremverk commits to:\nOn-call acknowledgement within 1 business hour during business hours (09:00–17:00 Europe/Copenhagen, Mon–Fri excluding Danish public holidays); best-effort outside business hours via the on-call rotation published on status.frem.sh. Acknowledgement is the operator confirming receipt of the page and beginning triage; it is not a commitment to a resolution time. Enterprise-on-Demand Subscriptions may negotiate tighter ack windows in the Order Form, subject to the funded 24/7 rotation availability noted under Support Response Times. Two-person on-call rotation — primary and secondary operator on the documented rota at all times. Either operator can ack a Severity-1 page; the rotation is sized so a single-operator absence (holiday, sick day) does not extend the ack window. Status-page update within 15 minutes of on-call acknowledgement of the incident at status.frem.sh, with a plain-English description of the affected surface and the observed impact. The status page is hosted in an independent enterprise project (fremforge-status-prd) and is designed to stay up when the product surface is down. Status-page updates at least every 30 minutes for the duration of the incident, or more frequently if material new information becomes available. Email notification to the admin-of-record of each affected organisation for Severity 1 incidents (complete unavailability of one or more in-scope surfaces for \u0026gt; 15 minutes) — initial notification within 30 minutes of acknowledgement, and an all-clear message at resolution. Post-mortem publication on the status page within 14 days of resolution of any incident affecting Customer data or availability, documenting timeline, root cause, and corrective actions. Status-page data is retained 90 days on-page and 3 years internally for verification against this SLA and against any §8 credit claim.\nStatus-page events are exposed at status.frem.sh/feed.atom (RSS/Atom) and status.frem.sh/api/v1/incidents (JSON), and Customer-configured webhooks may subscribe at frem.sh/_app/\u0026lt;slug\u0026gt;/_admin/webhooks/incidents. fremverk\u0026rsquo;s contractual notification commitment under DPA §8 and §9 of this SLA is satisfied where notice reaches the Customer through any of: (a) the Customer\u0026rsquo;s nominated security-contact email, (b) a Customer-configured webhook subscription, (c) RSS/Atom feed subscription that the Customer has documented as in-use, OR (d) the trust-page banner where the incident is platform-wide.\n10. Support # Standard support hours: 09:00–17:00 Europe/Copenhagen, Monday to Friday, excluding Danish public holidays. P1 support is 24/7 regardless of standard hours.\nThe 99.5% commitment is paired with email support via support@frem.sh. Target first-response times:\nP1 — Service unavailable for all Users:\nStandard Subscription: first response within 1 business hour during 09:00–17:00 Europe/Copenhagen on business days; best-effort outside business hours via the on-call channel published on status.frem.sh. Enterprise-on-Demand Subscription: first response within 1 hour, 24/7, including weekends and Danish public holidays. Subject to fremverk\u0026rsquo;s funded on-call rotation, available from 2027-Q1; until then, the Standard Subscription terms apply with commercially reasonable best-effort 24/7. Severity First-response target P2 — Major functionality degraded 4 business hours P3 — Minor issue, question 1 business day P4 — Feature request, documentation 3 business days fremverk self-assigns severity on receipt; the Customer may request re-triage. Severity is not a guarantee of resolution time.\nEnterprise-on-Demand contracts add 24/7 P1 response with a named Customer Success contact.\n11. Security-patching SLA (cross-reference, not part of availability measurement) # The published security-patching SLA at trust page §Security patching and in the DPA security annex §A.8 is a contractual commitment separate from the availability commitment in this SLA. It is not measured by service credits but by published adherence on the trust page and — for regulated customers — by the DPA security annex. Brief windows of interruption to apply a security patch within SLA are excluded from Downtime (§6.2).\n12. Changes to this SLA # fremverk may update this SLA subject to the 30-day-notice requirement in Terms of Service §17. Changes that reduce the availability commitment, raise thresholds, reduce credit rates, or weaken the incident-communication commitment in §9 are considered material and adverse, and give the Customer a termination right without penalty under Terms §17.\n13. Contact # Claims: support@frem.sh (subject line: SLA CREDIT CLAIM — \u0026lt;month\u0026gt;) Escalation and contract queries: compliance@frem.sh Change log # Version Date Change 1.0 2026-04-25 Initial publication. 1.1 2026-05-08 Round-7 substantive updates: §5.3 fallback measurement source corrected from \u0026ldquo;Loki/LTS\u0026rdquo; to \u0026ldquo;T Cloud LTS\u0026rdquo; (we don\u0026rsquo;t run Loki — P2-LEG-25); §5.3.1 fallback measurement procedure added documenting the CES 1-min metrics + LTS log-line presence reconstruction path (P2-SRE-30). 1.2 2026-05-25 New §3A \u0026ldquo;Audit-log retention by plan\u0026rdquo; documenting the per-plan SLA floor (standard = 90d queryable + 3y WORM; enterprise = 365d queryable + 3y WORM baseline). Mirrors DPA v1.14 + DPIA v1.2. The Customer admin may set hot-tier retention below the plan SLA floor via the admin UI but doing so disclaims the contractual queryability commitment for the affected period — yes-by-design split between technical permit and contractual constraint. ","externalUrl":null,"permalink":"/legal/sla/","section":"Legal documents","summary":" title: fremforge Service Level Agreement author: fremverk date: 2026-05-25 status: Published v1.2 version: “1.2” lang: en # Last updated: 2026-05-25\n","title":"fremforge Service Level Agreement","type":"legal"},{"content":" title: fremforge Terms of Service author: fremverk date: 2026-05-10 status: Published v1.1 version: \u0026ldquo;1.1\u0026rdquo; lang: en # Last updated: 2026-05-10\nEffective Date: 2026-05-10 — Version: 1.1\nThese Terms of Service (\u0026ldquo;ToS\u0026rdquo;) form the master agreement between fremverk ApS and the Customer for use of the fremforge service at frem.sh. The Acceptable Use Policy, Data Processing Agreement, Service Level Agreement, Privacy Notice, and Cookie Policy are incorporated by reference and form part of the same contract.\n1. Parties # This agreement is between:\nfremverk ApS (\u0026quot;fremverk\u0026quot;, \u0026ldquo;we\u0026rdquo;, \u0026ldquo;us\u0026rdquo;, \u0026ldquo;our\u0026rdquo;)\nCVR: 39150689\nRingager 4C, 2. tv, 2605 Brøndby, Denmark\nVAT: DK39150689\nPrimary contact: hello@frem.sh · compliance@frem.sh\nand\nthe Customer (the legal entity that signs up for or is invoiced for the fremforge service), identified by the organisation name, billing address, and VAT number provided at signup or in the ordering document.\nfremforge is a product brand of fremverk ApS. fremverk ApS is the sole legal signatory and contracting party.\n1.1 Definitions # The following capitalised terms have the meanings set out below when used in these ToS:\nCustomer — the legal entity identified at signup or in the Order Form that contracts with fremverk for use of the Service. User — an employee, contractor, or other individual authorised by the Customer to use the Service under the Customer\u0026rsquo;s account. Service — the fremforge Git and CI/CD hosting service described in §2, including all features, APIs, and surfaces made available by fremverk under these ToS. Order Form — any ordering document, signup record, or bespoke commercial document agreed between the parties that records the commercial terms of a Subscription. Documentation — the published documentation at docs.frem.sh as of the Effective Date. Customer Content — all data, code, configuration, issues, pull requests, comments, wiki content, package artifacts, CI logs, and other content the Customer or its Users submit or cause to be generated on the Service. Customer Personal Data — personal data within Customer Content; this term incorporates the corresponding definition in the DPA by reference. Fees — the amounts payable by the Customer to fremverk for the Service, as set out in §4 and the applicable Order Form or published pricing. Term — the period during which these ToS are in force between the parties, as defined in §16. Effective Date — the date these ToS take effect under §16.1. Subscription — the Customer\u0026rsquo;s contracted right to use the Service for the Term, on the plan, seat count, and commercial basis recorded in the Order Form or at signup. 2. The Service # fremforge is an EU-sovereign, multi-tenant Git and CI/CD hosting service. The Service includes, without limitation:\nHosted Git repositories, issues, pull requests, wiki, releases, and collaboration surfaces. Hosted continuous integration and continuous delivery runners on T Cloud Cloud Container Instance (\u0026ldquo;hosted runners\u0026rdquo;). Single sign-on enforcement via OIDC and SAML; per-organisation session binding; scoped API tokens. A bundled supply chain security stack: pre-receive secret scanning and push protection, dependency scanning on pull requests, signed commits via OIDC identity, and SLSA provenance for build artifacts. A package registry supporting npm, Maven, Docker, NuGet, PyPI, RubyGems, Composer, and Go. A fremforge admin UI for tenant configuration, policy management, audit-log view, and export initiation. A documented public REST API at frem.sh/_app/api/v1/* equivalent to the admin UI surface. Data export on demand per the Privacy Notice §7. Business-hours email support via support@frem.sh. The Service is described in the Documentation published at docs.frem.sh as of the Effective Date, including the published feature scope, the security commitments at www.frem.sh/trust/, and the SLA. The Service is provided in accordance with the Documentation as updated from time to time per §17.\nfremverk may update the Service from time to time to add features, fix bugs, or improve security; material reductions in functionality are announced with at least 30 days\u0026rsquo; notice where commercially feasible.\n3. Grant of use # Subject to the Customer\u0026rsquo;s compliance with these ToS, fremverk grants the Customer a non-exclusive, non-transferable, non-sublicensable right to access and use the Service during the Term, for its own internal business purposes. The Customer may provide access to its employees, contractors, and other permitted users (\u0026ldquo;Users\u0026rdquo;) within a configured seat limit; each such User must agree to these ToS.\nThe right to use is limited to what the seat count, plan, and ordering document permit. fremverk retains all rights not expressly granted.\n4. Fees, payment, and renewal # 4.1 Pricing and billing # The Service is sold on a per-seat basis. Two billing terms are available, elected at signup or via the billing-admin surface:\nMonthly term — billed at the per-seat monthly list price, charged monthly in advance. The Customer may cancel at any time; access continues to the end of the paid month, and any further charges stop.\nAnnual term — billed at the per-seat monthly list price discounted by 15% (the \u0026ldquo;annual discount\u0026rdquo;), charged as a single upfront annual fee at the start of each one-year term. The annual fee is non-refundable except during the 30-day money-back window described below. If the Customer cancels mid-term outside that window, access continues to the end of the committed period and then ends; the unused portion is not refunded and no clawback or further charge applies.\n30-day money-back guarantee on annual terms. Customers who switch a monthly subscription to annual or sign up directly on the annual term may request a full refund of the upfront annual fee within 30 calendar days of the annual charge by cancelling via the admin UI or by emailing support@frem.sh with subject line ANNUAL REFUND — \u0026lt;organisation\u0026gt;. The refund is processed via the original Mollie payment method within 14 calendar days. On refund, the Subscription continues on the monthly term at the per-seat monthly list price (i.e. without the 15% annual discount) and the Customer\u0026rsquo;s next monthly charge falls on the next calendar-month boundary; the unused months from the cancelled annual fee are NOT credited against future monthly fees (the refund makes the Customer whole). The 30-day window applies once per annual cycle — a Customer who refunds in year 1, opts back to annual in year 2, then refunds again in year 2 is granted the year-2 refund; chained refund attempts in the same annual cycle are not. Renewals at the end of an existing annual term are NOT a \u0026ldquo;new annual charge\u0026rdquo; for the purpose of this window — the window resets only on a fresh monthly-to-annual switch.\nStandard pricing and overage rates are those published at frem.sh/pricing at the date of signup, or those recorded in a bespoke ordering document for Enterprise-on-Demand customers.\nFees are denominated and invoiced in EUR. fremverk does not bill in any other currency. Where the Customer is established in Denmark, Danish 25% VAT applies on the EUR invoice via fremverk\u0026rsquo;s bookkeeping partner; the VAT regime depends on the Customer\u0026rsquo;s country of establishment and VIES status, not on the invoice currency.\n4.2 Payment method # Payments are processed through Mollie B.V., a PSD2-authorised payment institution in the Netherlands. Accepted payment methods include SEPA Direct Debit, major credit and debit cards, and other EU-native methods exposed by Mollie. By providing payment details, the Customer authorises fremverk to charge the payment method for Fees and overage in accordance with these ToS.\nfremverk does not see or store raw card or bank-account data; Mollie is the sole processor of payment-card information and PCI-DSS Level 1 certified.\n4.3 Overage # Runner-minute overage beyond the pooled monthly allocation is metered at the rate published at frem.sh/pricing. Storage and package-registry egress are governed by the soft-cap and hard-cap regime described at frem.sh/pricing. Overage is invoiced monthly in arrears under both billing terms.\nAdding seats mid-term. Additional seats added during a paid period are charged on a pro-rata basis to the end of the current period: monthly term → pro-rata to end of paid month; annual term → pro-rata to the committed-until date at the discounted rate. The new seat count carries forward at full rate at the next renewal.\nRemoving seats mid-term. Seat reductions take effect at the next renewal boundary (end of paid month for monthly term; committed-until date for annual term). Mid-term seat reductions are not refunded.\n4.4 VAT and taxes # Danish VAT applies to Danish Customers. Intra-EU B2B Customers with a valid VIES VAT number are invoiced under the reverse-charge mechanism. Non-EU B2B Customers are invoiced without EU VAT, with self-accounting by the Customer in its own jurisdiction. Where a Customer is a consumer (rare for fremforge as a B2B service), applicable VAT rates apply.\nWithholding taxes, stamp duties, and other taxes imposed on the Customer in its jurisdiction are the Customer\u0026rsquo;s responsibility and may not be deducted from the Fees unless mandatory under applicable law; in that case the Customer will gross up the payment so that fremverk receives the agreed amount.\nVAT regime changes during the term. fremverk validates each EU customer\u0026rsquo;s VAT registration via the EU VIES service at signup and periodically thereafter (typically every 90 days). EU non-Danish customers with a valid VIES registration are billed at 0% VAT under the cross-border B2B reverse-charge regime (Council Directive 2006/112/EC Art. 196). If the Customer\u0026rsquo;s VIES status becomes invalid during the Term — for any reason including company restructuring, deregistration, or VAT-number change — fremverk will notify the Customer by email and grant a 30-day grace period during which billing is paused. If the VIES status is not restored within the grace period, fremverk will automatically transition the Customer\u0026rsquo;s account to the Danish domestic VAT regime (currently 25%, charged on top of the listed prices) for all subsequent invoices, and will send a regime-change confirmation email. Past invoices issued correctly under reverse-charge are not retroactively re-rated. The Customer may avoid the regime change at any time by providing a valid VIES VAT number; restoring a valid VIES VAT number after the regime change reverts subsequent invoices to reverse-charge but does not retroactively re-rate any Danish-VAT invoices that were correctly issued during the post-grace period.\n4.5 Late payment # Invoices are due within 30 days of issue unless otherwise agreed. Late payment accrues interest at the default rate under the Danish Interest Act (Renteloven) or 8 percentage points above the European Central Bank\u0026rsquo;s reference rate, whichever is higher. Fees for dunning and recovery are recoverable under Danish law.\n4.6 Dunning and suspension # After the due date, fremverk follows a commercially reasonable dunning cycle — typically three notification attempts over 30 days — before suspending the Service per AUP §11.\n4.7 Renewal # Monthly subscriptions renew month-to-month unless cancelled; cancellation takes effect at the end of the current paid month and no further charges apply.\nAnnual subscriptions renew for successive one-year terms by an upfront charge at each renewal anniversary, unless either party gives at least 30 days\u0026rsquo; notice before the end of the current term. Cancelling within an annual term ends auto-renewal but does not refund the unused portion of the current term — access continues to the committed-until date and then ends. Price changes for renewals are announced at least 60 days in advance.\n4.8 Revenue recognition (periodisering) # For Customers party to a Danish-law contract: fremverk\u0026rsquo;s financial year runs 1 May to 30 April. Where an annual subscription period spans that boundary, fremverk recognises the prepaid fee as revenue on a pro-rata monthly basis across the two fiscal years per Bogføringsloven §10 and IFRS 15. This affects only fremverk\u0026rsquo;s accounting; it does not change the amount the Customer is billed nor the Customer\u0026rsquo;s right of access during the term.\n5. Trials # fremverk may offer a free trial of the Service, currently 30 calendar days with no payment method captured at signup. Trials convert to a paid Subscription only when the Customer follows the payment-setup link in their welcome email and successfully captures a payment-method mandate; if no mandate is captured by the end of the trial, the trial is suspended (read-only access continues for the data-retention period in §16.5 unless the Customer reactivates). Trial-tier limits are published at frem.sh/pricing. Trial-abuse controls — email verification, per-domain deduplication, signup rate limits, and trial-specific runner caps — apply. fremverk may terminate a trial at any time for suspected abuse.\n6. Customer obligations # 6.1 Lawful use # The Customer uses the Service only for lawful purposes and in accordance with these ToS, the AUP, and applicable law.\n6.2 Account security # The Customer is responsible for:\nMaintaining the confidentiality of its credentials, API tokens, and any delegated mandates it issues. Managing the lifecycle of its Users (onboarding, offboarding, role changes) and ensuring that access is granted only to authorised personnel. Configuring SSO and MFA in accordance with its own security policies; fremverk provides the tools, the Customer configures them. Notifying fremverk immediately via security@frem.sh of any suspected credential compromise or unauthorised access. 6.3 Content and data # The Customer owns and is responsible for all data, code, configuration, issues, pull requests, comments, wiki content, package artifacts, CI logs, and other content it or its Users submit or cause to be generated on the Service (\u0026ldquo;Customer Content\u0026rdquo;). The Customer warrants that it has the right to use the Customer Content and that its use does not infringe third-party rights or violate applicable law.\nThe Customer remains the controller of Customer Content for GDPR purposes; fremverk processes Customer Content as processor under the DPA.\nfremforge is a \u0026ldquo;hosting service\u0026rdquo; within the meaning of Regulation (EU) 2022/2065 (Digital Services Act). Customer Content is stored at the Customer\u0026rsquo;s request; fremverk does not select, modify, or moderate Customer Content as a matter of editorial control. Subject to acting expeditiously on notices submitted through the mechanism in AUP §5, fremverk relies on the conditional liability exemption in DSA Art. 6 in respect of Customer Content and is under no general monitoring obligation (DSA Art. 8). Nothing in this paragraph limits the Customer\u0026rsquo;s responsibility under this §6.3, the warranties in §13.2, or the Customer\u0026rsquo;s indemnity in §15.2.\n6.4 Payment method # The Customer maintains a valid payment method on file for the duration of the Term and updates it promptly on expiry or change.\n6.5 Export control and sanctions # The Customer warrants that:\nIts use of the Service, and any Customer Content stored or transmitted through the Service, complies with EU dual-use export-control regulation (Regulation (EU) 2021/821) and applicable national implementations. It is not located in, resident in, or a national of any country or region subject to comprehensive EU, UN, or Danish sanctions that would prohibit provision of the Service to it, and it is not acting on behalf of any person so located, resident, or national. It will not export, re-export, or otherwise transfer — directly or indirectly, via the Service — controlled software, technology, or technical data to a destination, person, or end-use prohibited by applicable sanctions or export controls. Breach of this clause is a material breach of these ToS giving fremverk the right to suspend or terminate under §16.4 without cure period where required to comply with applicable law.\n6.6 Anti-bribery and anti-corruption # The Customer warrants that it will not use the Service to support activity prohibited under applicable anti-bribery and anti-corruption legislation, including the Danish Criminal Code (Straffeloven) provisions on bribery of public officials and in commercial relations, the UK Bribery Act 2010, the US Foreign Corrupt Practices Act, or equivalent provisions in the Customer\u0026rsquo;s own jurisdiction.\nBreach of this clause is a material breach of these ToS giving fremverk the right to suspend or terminate under §16.4 without cure period where required to comply with applicable law.\n7. Intellectual property # 7.1 Customer IP # Customer Content remains the property of the Customer (or its licensors). The Customer grants fremverk a limited licence to host, process, transmit, cache, display, and make Customer Content available to the Customer and its Users strictly for the purpose of providing the Service, and to perform the operational and security-related processing described in the DPA and Privacy Notice. This licence terminates on deletion of the Customer Content or termination of this agreement.\n7.2 fremverk IP # The Service, the fremforge trademark and logos, the documentation, the admin UI, the control-plane software, the API, the shared OpenTofu modules, and the platform-foundation tooling remain the property of fremverk. No ownership of or interest in fremverk intellectual property transfers to the Customer under this agreement.\n7.3 Open source components # The Service is built on open source software, including upstream Forgejo (GPL v3+) run unmodified, and the supply chain security stack components documented on the trust page. Those components are governed by their respective open source licences, which are compatible with commercial SaaS distribution of the Service.\nForgejo is licensed under GPL v3+ and is run unmodified by fremverk as a hosted service. The Customer\u0026rsquo;s use of the hosted Service does not constitute \u0026ldquo;distribution\u0026rdquo; of Forgejo to the Customer within the meaning of GPL v3 §0/§5, and accordingly does not impose any GPL obligations on the Customer\u0026rsquo;s own code, repositories, or derivative works hosted on the Service. The Customer\u0026rsquo;s repositories remain governed solely by the licences the Customer chooses for them. Because the underlying forge is upstream Forgejo run unmodified, repository, issue, PR, and metadata exports under §16.5 / DPA §9 are directly importable into a self-hosted Forgejo instance, providing a vendor-lock-in mitigation.\n7.4 Feedback # If the Customer provides suggestions, bug reports, or ideas for improving the Service, fremverk may freely use them without obligation.\n8. Confidentiality # Each party treats the other\u0026rsquo;s confidential information with at least the same care it applies to its own, and uses it only for purposes of this agreement. This does not apply to information that is public, already known without confidentiality duty, independently developed, or rightfully received from a third party.\nCustomer Content is treated as the Customer\u0026rsquo;s confidential information. Aggregate and anonymised operational metrics that cannot identify the Customer may be used by fremverk for capacity planning, product improvement, and reporting.\n9. Privacy and data protection # Personal data processed as part of the Service is governed by the Privacy Notice and the DPA. Where Customer Content contains personal data, the Customer is the controller and fremverk is the processor. fremverk complies with GDPR Art. 28 processor obligations in the DPA.\n10. Security # fremverk implements the technical and organisational security measures documented in the DPA security annex and the security-patch SLA at www.frem.sh/trust/#security-patching, including but not limited to:\nTLS 1.2+ on every surface; at-rest encryption via T Cloud DEW KMS. Per-organisation logical isolation with enforced ACLs, per-org rate limits, and per-tenant audit streams. Pre-receive secret scanning, dependency scanning, signed commits, SLSA provenance. Immutable audit log with tamper-evident hash chaining anchored to OBS WORM storage. Layered SSRF hardening: per-pod VPC Security Group egress allowlist (Cloud Native Network 2.0) + outbound-proxy CONNECT tunnel with SSRF deny-set + app-layer SSRF guard with one-shot DNS-resolve-then-dial-by-IP. Published CVE-patching SLA — Phase 2 contractual targets (in force from 2027-Q1, concurrent with the funded 24/7 on-call rotation): Critical within 48h, High within 72h, Medium within 7 days. During Phase 1, fremverk uses commercially reasonable efforts against the Phase 1 targets in SLA §6.2 (Critical 72h / High 7d / Medium 14d) — see §13.1 for the warranty carve-out. 10A. Insurance # fremverk procures cyber-liability and technology errors-and-omissions insurance and commercial general liability insurance appropriate to the Subscription tier and to any Customer-specific procurement requirements. For Standard Subscription Customers, fremverk maintains commercially reasonable equivalent self-insurance reserves and provides transparent disclosure of the position on written request. For Enterprise-on-Demand Subscription Customers, the Order Form may stipulate named-insured certificates, specific per-claim and annual-aggregate limits (typically in the €1,000,000–€5,000,000 range for cyber + E\u0026amp;O), 30-day cancellation notice, or other Customer-procurement-specific terms; those terms bind both parties for the duration of the Order Form, and certificates of insurance are renewed annually while the requirement is in force. Coverage shall not be reduced below the limits stipulated in an active Order Form without 30 days\u0026rsquo; prior written notice to the Customer.\n11. Availability and SLA # Service availability commitments and service-credit remedies are defined in the SLA. The standard plan provides a 99.5% monthly availability commitment with automatic service credits; Enterprise-on-Demand contracts may agree to higher commitments backed by dedicated staffing.\n12. Third-party services # The Service interoperates with third-party services configured by the Customer — for example, external identity providers, webhooks sent to Customer systems, package registries consumed from the Customer\u0026rsquo;s own infrastructure, or AI tooling the Customer brings. The Customer is responsible for its use of those third-party services and their associated terms; fremverk is not a party to them and is not responsible for their performance.\n13. Warranties and disclaimers # 13.1 fremverk warranties # fremverk warrants that:\nIt has the right to enter into this agreement and provide the Service. It will provide the Service with commercially reasonable skill and care consistent with industry standards applicable to EU-sovereign cloud services. During Phase 1 (until fremverk\u0026rsquo;s funded 24/7 on-call rotation goes live, targeted 2027-Q1) it will use commercially reasonable efforts to patch CVEs against the Phase 1 targets published in SLA §6.2 (Critical CVSS ≥9.0: 72 hours of upstream fixed release; High 7.0–8.9: 7 days; Medium 4.0–6.9: 14 days; Low: next scheduled maintenance window). Failure to meet a Phase 1 target is not a service-credit event and is not a material breach for the purposes of §16.4. From Phase 2 onwards it will meet the contractual CVE patch SLA set out in DPA Annex A — Security Measures (Critical CVSS ≥9.0: 48 hours of upstream fixed release; High 7.0–8.9: 72 hours; Medium 4.0–6.9: 7 days; Low: next scheduled maintenance window). Failure to meet this SLA from Phase 2 onwards is a material breach for the purposes of §16.4. 13.2 Customer warranties # The Customer warrants that:\nIt has the right to enter into this agreement and to authorise its Users to use the Service. Its use of the Service and the Customer Content complies with applicable law and does not infringe third-party rights. It has obtained all consents, given all notices, and established all legal bases required for its processing of personal data within Customer Content. 13.3 Disclaimer # Except for the warranties expressly stated above, the Service is provided \u0026ldquo;as is\u0026rdquo; and fremverk disclaims all other warranties, express or implied, to the maximum extent permitted by applicable law, including implied warranties of merchantability, fitness for a particular purpose, and non-infringement. fremverk does not warrant that the Service will be uninterrupted or error-free beyond the SLA commitment.\nThe disclaimer in this §13.3 applies to the maximum extent permitted by Danish law. Where the Customer is acting otherwise than in the course of its trade, business, or profession, mandatory consumer-protection law (including Forbrugeraftaleloven, Markedsføringsloven, and the Købeloven warranty floor for defects of substance) is preserved per §21.\n14. Liability # 14.1 Mandatory exclusions # Nothing in these ToS limits or excludes either party\u0026rsquo;s liability for: (a) gross negligence (grov uagtsomhed) or wilful misconduct (forsæt); (b) death or personal injury caused by negligence; (c) fraud or fraudulent misrepresentation; (d) any liability that cannot lawfully be limited under Danish law (including under the Aftaleloven §36 unfair-terms doctrine and the Købeloven where applicable).\n14.2 Unlimited liability # Nothing in this agreement limits or excludes liability for:\nDeath or personal injury caused by negligence. Fraud or fraudulent misrepresentation. Any other liability that cannot be limited or excluded under applicable law. 14.3 Capped liability # Subject to §14.1 and §14.2, the aggregate liability of either party to the other under or in connection with these ToS, including the DPA, AUP, SLA, Privacy Notice and Cookie Policy, in any twelve-month period is limited to the greater of (a) the Fees actually paid by the Customer to fremverk under the affected Subscription in the twelve months preceding the event giving rise to liability, or (b) €25,000, capped in any case at €500,000 per twelve-month rolling period.\n14.4 Indirect loss # Subject to §14.1 and §14.2, neither party is liable for indirect, consequential, incidental, special, or punitive damages, including loss of profits, loss of revenue, loss of goodwill, loss of business, loss of anticipated savings, loss of data (except where the loss of data constitutes a breach of fremverk\u0026rsquo;s obligations under the DPA, in which case §14.5 applies), or loss arising from business interruption.\n14.5 Data liability carve-out # For claims arising from fremverk\u0026rsquo;s breach of the DPA security annex and resulting in a personal-data breach, the cap in §14.3 is raised to two times the annual Fees, without prejudice to any statutory liability that cannot be capped.\n14.6 Carve-outs from cap # The aggregate cap in §14.3 does not apply to: (a) fremverk\u0026rsquo;s IP indemnity obligations under §15.1; (b) either party\u0026rsquo;s liability for breach of confidentiality, provided that where the same incident also constitutes a breach of fremverk\u0026rsquo;s obligations under the DPA security annex, the higher of the cap in §14.5 (two times annual Fees) or the uncapped statutory liability in DPA §13 applies, and the carve-out in this paragraph (b) does not stack on top; (c) liabilities excluded from limitation under §14.1.\n15. Indemnities # 15.1 fremverk indemnity — IP # fremverk will defend the Customer against third-party claims that the Service (excluding Customer Content and Customer-configured third-party services) as provided by fremverk infringes the claimant\u0026rsquo;s intellectual property rights, and will pay any damages awarded by a court of competent jurisdiction or agreed in settlement. As a condition: (i) the Customer promptly notifies fremverk of the claim in writing; (ii) fremverk has sole control of the defence and settlement; provided that fremverk shall not, without the Customer\u0026rsquo;s prior written consent (not unreasonably withheld or delayed), enter into any settlement that (A) admits liability of the Customer, (B) imposes injunctive or non-monetary obligations on the Customer, or (C) is not solely monetary and fully paid by fremverk; (iii) the Customer provides reasonable cooperation at fremverk\u0026rsquo;s expense.\nIf the Service becomes, or in fremverk\u0026rsquo;s reasonable opinion is likely to become, the subject of an infringement claim, fremverk may at its option: (a) procure the right for the Customer to continue using the Service; (b) modify the Service so it is non-infringing while materially preserving functionality; or (c) terminate the affected portion of the Service and refund prepaid unused Fees.\nThis indemnity does not apply to infringement resulting from: use of the Service in combination with anything not supplied by fremverk; modification of the Service by the Customer; or Customer Content.\nfremverk\u0026rsquo;s indemnity under this clause is limited to claims brought in courts of the European Union, European Economic Area, the United Kingdom, Switzerland, the United States, or any jurisdiction in which the Customer is a registered legal entity at the time the underlying claim arises (not frozen to the Effective Date).\n15.2 Customer indemnity — Content # The Customer will defend fremverk against third-party claims that Customer Content, or the Customer\u0026rsquo;s use of the Service in breach of these ToS or applicable law, caused the claimant harm, and will pay any damages awarded by a court of competent jurisdiction or agreed in settlement. The same conditions (prompt notice, control of defence, cooperation) apply; provided that the Customer shall not, without fremverk\u0026rsquo;s prior written consent (not unreasonably withheld or delayed), enter into any settlement that (A) admits liability of fremverk, (B) imposes injunctive or non-monetary obligations on fremverk, or (C) is not solely monetary and fully paid by the Customer.\n16. Term and termination # 16.1 Effective Date and acceptance # These ToS take effect on the earlier of (a) Customer\u0026rsquo;s electronic acceptance at signup or via clickwrap, (b) Customer\u0026rsquo;s first paid use of the Service, or (c) Customer\u0026rsquo;s authenticated use of the Service for any purpose, including trial, sandbox, or evaluation access. Mere unauthenticated browsing of public marketing pages does not by itself constitute acceptance, but submission of an account-creation request, sign-in, or use of an authenticated surface does.\nThe agreement continues on a monthly or annual basis as selected, with automatic renewal as described in §4.7, until terminated per this §16.\n16.2 Termination by the Customer for convenience # The Customer may terminate a monthly subscription at the end of any billing period by cancelling via the admin UI (where the self-service cancellation flow is available) or, until that flow ships in Phase 1, by written notice to support@frem.sh with subject line CANCELLATION — \u0026lt;organisation\u0026gt;. Annual subscriptions may be cancelled at any time; outside the 30-day money-back window in §4.1, the upfront annual fee remains payable in full and is non-refundable, cancellation ends auto-renewal at the next term boundary, and access continues to the committed-until date. Within the 30-day money-back window the full annual fee is refunded per §4.1 and the Subscription continues monthly. Cancelling at least 30 days before the end of the current term is required to prevent the next year\u0026rsquo;s auto-renewal charge.\n16.3 Termination by fremverk for convenience # fremverk may terminate at the end of any billing period on 30 days\u0026rsquo; written notice, provided fremverk refunds the pro rata unused prepaid Fees.\n16.4 Termination for cause # Either party may terminate immediately on written notice if the other party:\nMaterially breaches these ToS and fails to cure the breach within 30 days of notice (15 days for payment breaches). Becomes insolvent, files for bankruptcy, enters administration, or ceases to trade. fremverk may suspend or terminate immediately per AUP §7 for egregious violations.\n16.5 Effects of termination # On termination, the Customer\u0026rsquo;s right to use the Service ends. Customer Content is retained for 60 days to allow export (using the on-demand signed-export endpoints), then deleted per the DPA data-return clause. Fees accrued up to termination remain payable. The following provisions survive termination of these ToS for any reason: §1.1 (Definitions to the extent terms are used in surviving clauses), §6 (Customer Content ownership and IP), §7 (fremverk IP), §8 (Confidentiality), §13 (Warranties for breaches that occurred during the Term), §14 (Liability), §15 (Indemnification), §16.5 (Effects of termination — including data export and refund), §18 (Force majeure for events spanning termination), §20 (Notices), §21 (Governing law), §22 (Entire agreement and precedence), and the DPA audit rights for matters arising during the Term as set out in DPA §12. Customer\u0026rsquo;s obligation to pay accrued Fees and fremverk\u0026rsquo;s obligation to refund prepaid unused Fees on termination for fremverk\u0026rsquo;s uncured breach also survive.\nIf termination is for fremverk\u0026rsquo;s uncured material breach, Customer is not liable for Fees accruing after the effective date of termination, and fremverk refunds any prepaid Fees on a pro-rata basis within 30 days of termination.\n17. Changes to these ToS # fremverk may amend these ToS on at least 30 days\u0026rsquo; prior written notice. A change is materially adverse where it (a) increases Fees beyond the contracted increase mechanism, (b) reduces the liability cap or shifts indemnity allocation, (c) materially reduces functionality covered by the Service description, or (d) changes the governing law or dispute-resolution forum. On any materially adverse change, the Customer may terminate with effect from the change date by written notice within 30 days of fremverk\u0026rsquo;s notice, and fremverk refunds prepaid Fees attributable to the period after the effective date on a pro-rata basis.\nSecurity-related amendments that address an active threat may take effect on shorter notice, with commensurate transparency.\nWhere these ToS are amended during a Term, the version applicable to the Customer at the start of that Term continues to govern the Customer\u0026rsquo;s Subscription until renewal, unless the Customer expressly accepts the amended version (a positive act, not mere continued use). Mere continued use of the Service does not constitute acceptance of an amended version where the amendment is materially adverse within the meaning of this §17. On renewal, the then-current version applies subject to the materially-adverse-change protections in this §17.\n18. Force majeure # Neither party is liable for delay or failure to perform caused by events beyond its reasonable control, including natural disasters, war, terrorism, civil unrest, strikes, internet or power outages affecting third-party infrastructure, acts of government, or pandemics. The affected party notifies the other promptly and uses commercially reasonable efforts to resume performance.\nFor the avoidance of doubt, the following are NOT force majeure events:\n(a) ransomware, malware, security incidents, or configuration failures affecting fremverk\u0026rsquo;s own infrastructure or that of its sub-processors, where the proximate cause is within fremverk\u0026rsquo;s vendor-management or operational control; (b) outages of fremverk\u0026rsquo;s contracted sub-processors (T Cloud, Bunny CDN, Lettermint B.V., Heinlein Hosting / mailbox.org, Mollie, or any successor) — these are governed by the SLA exclusions in SLA §6 and remain fremverk\u0026rsquo;s commercial risk to manage; (c) failures attributable to fremverk\u0026rsquo;s own personnel, configuration, or operational error.\n19. Assignment # Neither party may assign or transfer this agreement without the other\u0026rsquo;s prior written consent, not to be unreasonably withheld. fremverk may assign to a successor in interest in connection with a merger, acquisition, or sale of substantially all assets, provided the successor assumes all obligations.\n20. Notices # Notices to fremverk go to compliance@frem.sh and to the address in §1. Notices to the Customer go to the billing contact and admin-of-record email on file, or to any address the Customer designates in writing. Notices are deemed received on the next business day after dispatch.\nWhere notice is sent by email to a Customer\u0026rsquo;s nominated address and fremverk receives a non-delivery report (bounce, mailbox full, address unknown) within 5 business days, fremverk shall make a reasonable second attempt to a backup address (where one has been designated) and to the Customer\u0026rsquo;s account-of-record administrator before treating the notice as delivered. The Customer is responsible for keeping the nominated security contact and admin-of-record contact current; fremverk is not in breach for inability to deliver to a stale Customer-supplied address after a documented good-faith second attempt.\n21. Governing law and jurisdiction # This agreement is governed by Danish law, excluding its conflict-of-laws rules and the UN Convention on Contracts for the International Sale of Goods. The competent courts of Denmark have exclusive jurisdiction, subject to any mandatory provision protecting consumers and to out-of-court dispute resolution mechanisms available under the Digital Services Act.\n22. Entire agreement; precedence # This agreement (these ToS plus the AUP, DPA, SLA, Privacy Notice, Cookie Policy, and any ordering document) constitutes the entire agreement and supersedes prior agreements on the same subject matter. In case of conflict, the order of precedence is: (1) a signed Enterprise-on-Demand ordering document, (2) the DPA, (3) these ToS, (4) the AUP, (5) the SLA, (6) the Privacy Notice, (7) the Cookie Policy, (8) published pricing at frem.sh/pricing.\nNotwithstanding the above, no Order Form, pricing page, or commercial document may override the data-protection commitments in the DPA. The DPA prevails over any conflicting term in any Order Form on matters within its scope (Article 28 GDPR processing).\nThe English-language version of these ToS and the rest of the legal bundle (Acceptable Use Policy, Data Processing Agreement, Service Level Agreement, Privacy Notice, Cookie Policy) controls. Translations into Danish, German, or other languages are provided for convenience only; in the event of conflict, the English version prevails.\n23. Severability # If any provision is held unenforceable, the remainder remains in full effect and the parties negotiate in good faith a replacement provision that most closely achieves the original intent.\n24. No waiver # Failure or delay by either party to enforce any right is not a waiver of that right or of any other right.\n25. Relationship of the parties # Nothing creates a partnership, joint venture, or agency between the parties. Neither party has authority to bind the other.\n26. Third-party beneficiaries # No person other than the parties has any right to enforce any term of this agreement under Danish law, the UK Contracts (Rights of Third Parties) Act 1999 (to the extent it might otherwise apply), or any analogous statute in any jurisdiction. The rights and obligations of employees, contractors, and other Users of the Customer, and of data subjects whose personal data is processed under the DPA, are governed by their own relationships with the Customer or with fremverk ApS as applicable, and not by direct enforcement of this agreement.\n27. Customer name and logo # fremverk may not use the Customer\u0026rsquo;s name, logo, or trademarks in marketing, customer lists, case studies, or other public materials without the Customer\u0026rsquo;s prior written consent (email suffices). Consent, once given, may be revoked with 30 days\u0026rsquo; notice, after which fremverk removes the Customer\u0026rsquo;s name and logo from forward-facing materials, noting that historical materials already distributed in print or fixed formats are not recalled.\nThe Customer may reference its use of the Service factually (for example, \u0026ldquo;our source code is hosted on fremforge\u0026rdquo;) without prior consent, consistent with normal commercial usage.\n28. Change of control # In the event of (i) a change of control of fremverk ApS, or (ii) a change of control of any sub-processor disclosed in DPA Annex B that would alter the EU-sovereignty posture set out in DPA §11 (e.g., acquisition by a non-EU/EEA entity bringing the sub-processor within the scope of US extraterritorial process), fremverk notifies the Customer within 10 business days of public announcement. The Customer may, within 60 calendar days of notice, terminate the affected Subscription for cause without penalty, with pro-rata refund of any prepaid unused Fees.\n29. Contact # General: hello@frem.sh · support@frem.sh Legal, contract queries, law enforcement: compliance@frem.sh Security: security@frem.sh Privacy: compliance@frem.sh Abuse (DSA Art. 16): abuse@frem.sh Change log # Version Date Change 1.0 2026-04-25 Initial publication. 1.1 2026-05-10 §4.4 — added VAT-regime-change clause: 30-day grace window on VIES revocation, automatic transition to Danish 25% domestic VAT after the grace window, regime-change confirmation email, no retroactive re-rating of correctly-issued past invoices. ","externalUrl":null,"permalink":"/legal/terms/","section":"Legal documents","summary":" title: fremforge Terms of Service author: fremverk date: 2026-05-10 status: Published v1.1 version: “1.1” lang: en # Last updated: 2026-05-10\n","title":"fremforge Terms of Service","type":"legal"},{"content":" title: Controller-side incident response runbook audience: fremverk on-call + compliance officer (privacy contact per ROPA + privacy-product.md §2; no Art. 37 DPO designation) classification: internal — share under NDA only version: 1.0 date: 2026-05-06 owner: shj@fremverk.com (CTO + Compliance Officer / DPO-equivalent — fremverk is not required to designate a DPO under GDPR Art. 37; see privacy-product.md §2) related:\ndpa.md §8.5 ropa.md sla.md §6 (operational SLA) operations.md (incident-response general flow) status: in force Purpose # This runbook governs fremverk\u0026rsquo;s response to Personal Data Breaches affecting fremverk-as-Controller processing activities — that is, breaches where fremverk owes the GDPR Art. 33 (72-hour Datatilsynet notification) and Art. 34 (data-subject communication) duties directly, not as Customer-as-Controller\u0026rsquo;s processor.\nFor Customer-Controller breaches (a sub-processor compromise affecting Customer Personal Data, an exposure caused by Customer-tenant misconfiguration, etc.), the processor-side flow in DPA §§8.1–8.2 applies and the customer-notification template at the bottom of this runbook is used. This document covers the controller-side flow only.\nThis runbook is referenced from DPA §8.5 as fremverk\u0026rsquo;s commitment to a 72-hour Datatilsynet notification path for fremverk-as-Controller incidents. The single intake point is compliance@frem.sh (mailbox.org-hosted, on-call rota\u0026rsquo;d into the same Kuma alert channel as oncall@frem.sh). The legacy alias compliance@fremverk.com forwards to the same mailbox for inbound continuity.\nWhen this runbook fires (the four breach classes) # This runbook fires when ANY of the following four conditions is detected by automation, reported by a fremverk staff member, or reported by a third party:\nClass A — Staff IdP compromise # idp.fremverk.com (Authentik on T Cloud — see fremverk/cloudplatform/platform-identity/) has issued an authentication factor or session that was not initiated by the legitimate account holder. Indicators:\nAuthentik audit log shows a successful login from an IP / device-fingerprint not historically associated with the user, especially without the corresponding MFA factor consent in the last 60s. WebAuthn enrolment for a new device by an account that did not request enrolment (matched against ServiceDesk ticket history). Recovery flow completed for an account whose primary email mailbox.org show no reset request. Authentik admin role granted to a non-admin user. Fremverk-as-Controller exposure: staff personal data, internal-systems administrative actions performed under the compromised identity, and any downstream pivot into Controller-managed data the staff identity has access to (HR records, finance records, internal audit log).\nClass B — WORM audit-chain tampering # The cross-tenant audit-chain-anchors OBS bucket (Object Lock COMPLIANCE-mode, see fremforge/platform-foundation/cce/audit-chain-alarms.tf) shows a checkpoint that contradicts the in-DB chain walk for the same (tenant_id, count), AND the in-DB chain walk for that tenant is internally consistent. Per api-v1.ts /audit/integrity, this is the anchor_disagrees_with_db_walk_investigate mismatch reason returned with anchor_age_seconds \u0026lt; 360.\nFremverk-as-Controller exposure: the integrity attestation fremverk provides to its own staff (and indirectly to Customers) for the internal audit log is no longer trustworthy; an actor with audit_events write access has rewritten history. This is a fremverk-internal-audit-log breach in the controller sense — separate from any Customer Personal Data accessed via the same vector (which is processor-side and follows DPA §8.1).\nClass C — Operator-console session hijack # A request to the operator console (/_admin/* on frem.sh — served behind the /_app/ Bunny strip-prefix mount, i.e. frem.sh/_app/_admin/*) was authenticated under a session cookie not minted by the legitimate operator\u0026rsquo;s OIDC flow. Indicators:\nIP-asn change mid-session beyond what the operator-session idle-timeout allows. Operator-action audit event without a corresponding OIDC-callback event in the same session window. Operator action performed during a window where the legitimate operator\u0026rsquo;s calendar shows them in transit / offline (cross-checked manually after the fact). Fremverk-as-Controller exposure: operator actions can affect Customer-tenant state but the operator-action log is fremverk-internal data — see ROPA §2.5. The Customer-side impact is processor-side and follows DPA §8.1; the operator-log integrity impact is controller-side and follows this runbook.\nClass D — Annex B sub-processor compromise where fremverk is the affected Controller # A confirmed security incident at one of the sub-processors named in DPA Annex B where fremverk is the affected Controller, not the Customer. Worked example: a compromise at mailbox.org that exposes fremverk\u0026rsquo;s internal compliance@, enterprise@, or info@ mailbox contents containing fremverk staff or counterparty personal data — distinct from a customer-mailbox compromise (which is covered by the customer\u0026rsquo;s own DPA with mailbox.org or our processor-side flow).\nFremverk-as-Controller exposure: the controllership-mapping is in ROPA §2. When in doubt, the breach falls into Class D if the Personal Data exposed at the sub-processor is data fremverk processes for fremverk-internal purposes (HR, finance, marketing-to-prospect, internal compliance) rather than data fremverk processes on behalf of a Customer.\nThe 72-hour clock # Per GDPR Art. 33(1), the notification clock starts when fremverk becomes aware of the breach — interpreted by Datatilsynet (and by EDPB Guidelines 9/2022) as the moment fremverk has a reasonable degree of certainty that a security incident has occurred AND that personal data is affected.\nIn practice for this runbook:\nT+0h is when either (a) automation pages the on-call channel with one of the four-class detection signals, or (b) the compliance officer logs a determination that an internal report or external tip-off rises to \u0026ldquo;reasonable degree of certainty.\u0026rdquo; Whichever is earlier. T+24h is the internal triage gate: by this point the affected data, scope, and root cause must be characterised at first-pass. If they are not, the gap itself is documented in the Datatilsynet notification per Art. 33(4) (information may be provided in phases). T+72h is the regulatory deadline: notification submitted to Datatilsynet via datatilsynet.dk anmeld sikkerhedsbrud, in Danish. (URL verified 2026-05-12; the earlier path /borger/digital-selvbetjening/anmeld-brud-paa-persondatasikkerheden now returns HTTP 404.) If the 72-hour deadline cannot be met for substantive (not procedural) reasons, the notification is filed late with the reasons-for-delay statement Datatilsynet\u0026rsquo;s form requires — a late-but-substantive report is preferable to an on-time empty report. Not notifying is never the right answer.\nTriage workflow # Roles:\nOn-call (rotating, see Kuma roster): receives the page, makes the initial four-class call, opens the incident channel. Incident commander (IC): shj@fremverk.com by default, hand-off documented in the channel topic. IC owns the timeline, the notification text, and the post-incident review. Compliance officer (privacy contact): shj@fremverk.com. fremverk has not designated a GDPR Art. 37 DPO (see privacy-product.md §2 + ropa.md); the Compliance Officer is the DPO-equivalent role for breach-notification and supervisory-authority correspondence. Dual-role with IC until headcount allows separation; conflict-managed by recusal where the IC role would be substantively biased — escalates to fremverk legal counsel listed in counsel.md. Comms: shj@fremverk.com (single-person company posture; expanded when org grows). Step 0 — Page receipt (T+0) # On-call confirms the page in the #incident-{YYYY-MM-DD} channel within the SLA P1 acknowledgement window. Posts:\n[INCIDENT OPEN] Class {A|B|C|D} — {one-line summary} T+0: {timestamp UTC} On-call: {name} IC handing-off-to (if not on-call): {name} Awareness basis: {automation alert | staff report | external tip-off} Pinging compliance officer: {name}@fremverk.com Step 1 — Containment (T+0 to T+4h) # Goal: stop the breach from continuing while preserving forensic state. Class-specific:\nClass A: Disable the suspected Authentik account (/admin/users/\u0026lt;id\u0026gt; → Disable, do NOT delete — keep for forensics). Force-revoke all active sessions for that user across Forgejo + monolith api + Authentik. Rotate the user\u0026rsquo;s recovery codes. If admin role compromised: rotate Authentik admin recovery secret, revoke all admin sessions, issue new recovery codes through out-of-band channel (call, not email). Class B: Freeze the audit-chain-anchor CronJob (scale to 0 replicas: kubectl -n fremforge-prd scale cronjob/audit-chain-anchor --replicas=0 — but the CronJob doesn\u0026rsquo;t have replicas attribute; correct command is to suspend: kubectl -n fremforge-prd patch cronjob/audit-chain-anchor -p '{\u0026quot;spec\u0026quot;:{\u0026quot;suspend\u0026quot;:true}}'). Snapshot the OBS bucket via boto3 list_object_versions to a forensic prefix. Snapshot audit_events for the affected tenant via pg_dump -t audit_events --where=\u0026quot;tenant_id='...'\u0026quot; to a forensic OBS bucket with Object Lock 5y. Class C: Force-revoke the suspected operator session (delete the cookie row from operator_sessions and rotate the OPERATOR_OIDC_CLIENT_SECRET so the session-binding key changes). Rotate the operator\u0026rsquo;s Authentik password + WebAuthn factors out-of-band. Class D: Notify the sub-processor (using the contact in DPA Annex B). Pause any active integration that depends on the compromised sub-processor. Document the sub-processor\u0026rsquo;s confirmation timestamp. Step 2 — Scope characterisation (T+4h to T+24h) # What data was affected? How many data subjects? How many records? Likely consequences? IC fills out the Datatilsynet form fields below in draft, even before the substantive answer is final — drafting forces the gap analysis.\nDatatilsynet notification fields (Danish form, English here for drafting):\nIdentification of the controller — fremverk ApS, CVR 39150689, registered office Ringager 4C, 2. tv, 2605 Brøndby, Denmark. Full controller-identification block in legal-meta.md §Identity (single source of truth). Contact for the data protection officer — compliance@frem.sh. Description of the nature of the breach — what happened, which systems involved, when detected vs when occurred. Categories of data subjects — staff, contractors, prospects, counterparty contacts, etc. Approximate number of data subjects — conservative upper bound; if unknown, say so. Categories of personal data records — identification, contact, authentication credentials, financial, special-category, etc. Approximate number of personal-data records — same. Likely consequences of the breach — credential abuse, identity theft, financial loss, reputational, etc. Measures taken or proposed — containment so far + remediation plan. Reason for delay (if filed late) — substantive only, never procedural. Step 3 — Notification (T+24h to T+72h) # When 9/10 fields are reasonably populated, the IC + Compliance Officer hold a 30-minute review call, finalise the text in Danish, and submit to Datatilsynet. The submission receipt is logged in the incident channel and copied to compliance@frem.sh with the Datatilsynet case number.\nStep 4 — Data-subject communication (Art. 34, where applicable) # If the breach is likely to result in a high risk to the rights and freedoms of natural persons (Art. 34(1)), affected data subjects are notified individually without undue delay. Triggers (non-exhaustive):\nAuthentication credentials in cleartext to an unauthorised party. Special-category data (health, political, biometric) exposed. Sufficient identification + contact data to mount a targeted phishing or social-engineering campaign. Communication is in the data subject\u0026rsquo;s working language (Danish for DK staff, English for international counterparties), via direct email + signed letter for staff. Template at the bottom of this runbook.\nExceptions per Art. 34(3) (encryption-rendered-unintelligible, subsequent-mitigation-rendering-high-risk-no-longer-likely, disproportionate-effort-→-public-communication) are documented in the incident timeline with the reasoning.\nStep 5 — Post-incident review (T+5d) # Within 5 business days of containment, the IC publishes a post-incident review to the incident channel covering: timeline, root cause, what worked, what didn\u0026rsquo;t, action items with owners + due dates. If the incident affected Customer Personal Data, a customer-facing summary is also drafted (separate document, posted to status.frem.sh per DPA §8.1 if applicable).\nThe Art. 33(5) record (record of all personal-data breaches) is updated with the post-incident review timestamp.\nOut-of-band escalation paths # If the on-call channel is itself compromised (suspected Class A involving an admin who can manipulate Kuma alerts, or suspected mailbox.org compromise of oncall@):\nPersonal phone tree, in this order: shj +45 [redacted from runbook — see counsel.md], legal counsel. fremverk\u0026rsquo;s primary mobile carrier customer service (Telia DK) for SMS-based out-of-band confirmation — never as the only channel. In-person at the registered address — last resort. The phone tree is rehearsed quarterly in a tabletop exercise (next: 2026-08-01).\nDatatilsynet notification template (in Danish) # TIL: Datatilsynet EMNE: Anmeldelse af brud på persondatasikkerheden — fremverk ApS, CVR 39150689 Identifikation af den dataansvarlige: fremverk ApS CVR: 39150689 Adresse: Ringager 4C, 2. tv, 2605 Brøndby, Danmark (CVR 39150689 — single-source-of-truth: legal-meta.md §Identity) Privacy-contact / DPO-equivalent: compliance@frem.sh Beskrivelse af bruddet: {Karakter af bruddet — hvad er sket, hvilke systemer er berørt, hvornår blev det opdaget vs hvornår fandt det sted.} Kategorier af berørte registrerede: {f.eks. medarbejdere, samarbejdspartnere, kunder hos en underdatabehandler.} Omtrentligt antal berørte registrerede: {Konservativt skøn. Hvis ukendt: angiv \u0026#34;ukendt på anmeldelsestidspunktet, opdateres i opfølgning\u0026#34;.} Kategorier af berørte persondatakategorier: {f.eks. identifikation, kontaktoplysninger, autentifikationsoplysninger, særlige kategorier.} Omtrentligt antal berørte persondataposter: {Som ovenfor.} Sandsynlige konsekvenser: {Hvad kan bruddet føre til for de registrerede.} Foranstaltninger: {Indkredsning, afhjælpning, varsling — hvad er der gjort + hvad er planlagt.} Begrundelse for forsinkelse (hvis indberetning \u0026gt; 72 timer efter kendskab): {Substantielt — aldrig proceduremæssigt.} Data-subject communication template (English, adapt to language as needed) # Subject: Important notice: a security incident at fremverk affecting your personal data Dear {name}, We are writing to inform you that on {discovery date}, fremverk became aware of a security incident affecting personal data we process about you in our role as data controller. This notification meets our obligation under Article 34 of the GDPR. What happened: {Brief, factual description.} What information was affected: {Specific categories. Be concrete.} What we have done: {Containment + mitigation steps already taken.} What you should do: {Concrete steps the data subject can take — change a password, enable MFA on a related account, watch for phishing, etc.} What we are doing next: {Remediation in progress + the regulator notification.} Contact: For questions about this incident, contact compliance@frem.sh. The Danish supervisory authority — Datatilsynet — has been notified and the case number is {Datatilsynet case number}. You may also contact Datatilsynet directly via datatilsynet.dk. Sincerely, {Name + role} fremverk ApS Rehearsal cadence # Tabletop exercise: every 6 months, rotating through the four classes. Next: 2026-08-01 (Class B — WORM tamper). Live drill: once annually, smallest credible scope (e.g. simulated Class A on a test account in a non-production Authentik instance). Next: 2026-Q4. Documentation review: every 12 months minimum, or after any incident that exposed a runbook gap. Owner: Compliance Officer. Change-log # Version Date Author Change 1.0 2026-05-06 shj Initial version. Covers four breach classes (A IdP, B WORM, C operator session, D Annex B sub-processor). DPA §8.5 cross-references this runbook as fremverk\u0026rsquo;s 72-hour notification commitment. ","externalUrl":null,"permalink":"/legal/controller-incident-response/","section":"Legal documents","summary":" title: Controller-side incident response runbook audience: fremverk on-call + compliance officer (privacy contact per ROPA + privacy-product.md §2; no Art. 37 DPO designation) classification: internal — share under NDA only version: 1.0 date: 2026-05-06 owner: shj@fremverk.com (CTO + Compliance Officer / DPO-equivalent — fremverk is not required to designate a DPO under GDPR Art. 37; see privacy-product.md §2) related:\n","title":"fremverk Controller-side Incident Response","type":"legal"},{"content":" title: Records of Processing Activities (Article 30 GDPR) date: 2026-05-14 status: Active. Reviewed quarterly; updated on every sub-processor change, every new processing activity, and every significant change to legal basis or retention. controller: fremverk ApS, CVR 39150689, Ringager 4C, 2. tv, 2605 Brøndby, Denmark contact: compliance@frem.sh dpo: not appointed (fremverk does not meet the Art. 37(1) mandatory-DPO criteria — not a public authority, core activities are Git hosting + CI infrastructure not large-scale systematic monitoring of data subjects, and Customer Personal Data does not include Art. 9 special-category or Art. 10 criminal-conviction data on a large scale). Assessment dated 2026-05-10, re-evaluated annually with the next §A.9 DR-drill review window (or sooner on material change to processing scope). compliance@frem.sh handles DSARs and supervisory-authority correspondence. # Records of Processing Activities # This document is the controller\u0026rsquo;s Article 30 record for the fremforge product. It reflects the current state of processing as of the date above and is reviewed at every sub-processor change, every privacy-impacting feature release, and at minimum quarterly.\nA separate ROPA exists for fremverk corporate operations (employee data, customer-relationship-management, accounting), which is out of scope here.\n1. Controller identification # Name: fremverk ApS Address: Ringager 4C, 2. tv, 2605 Brøndby, Denmark Email: compliance@frem.sh Privacy contact: compliance@frem.sh Representative for non-EU controllers: not applicable (fremverk is established in the EU) Data protection officer: not appointed; see header above for rationale. 2. Processing activities # For each activity below: purpose, lawful basis, categories of data subjects, categories of personal data, recipients (internal teams, sub-processors), international transfers, retention, technical and organisational measures (TOMs).\n2.1 Customer signup + tenant provisioning # Field Value Purpose Create the customer\u0026rsquo;s fremforge organisation; verify the customer\u0026rsquo;s email; route them through the right billing country / VAT-treatment branch. Lawful basis Article 6(1)(b) — performance of contract (the Service the customer is signing up for). Categories of data subjects Prospective customer\u0026rsquo;s signing-up individual (sole-trader operator OR an authorised employee of a customer entity). Categories of personal data Email; chosen org slug; chosen display name; billing country code; VAT identifier (if EU B2B); IP address (audit only). No special-category data. Recipients (internal) Operations on-call (ops@frem.sh), security on-call (security@frem.sh if anomalous signup investigation needed). Recipients (sub-processors) T Cloud (RDS — primary store of tenant + signup-attempt rows, OBS — verification-mail audit trail, LTS — operational logs); Lettermint B.V. (email delivery for the verification link); EU Commission VIES service (VAT lookup, public-sector lookup not an Art. 28 sub-processor — see DPA §11.2 amendment). International transfers None. T Cloud + Lettermint are EU. VIES is the European Commission. Retention Four distinct tiers, scope-stamped per data class:• signup_pending_confirmations rows (raw email + org_slug + display_name held until the customer clicks the confirmation link): ≤ 24 h, hard-deleted by the daily retention job past expires_at; on consumption the row migrates to the tenants table with full audit trail. Matches DPA Annex A.4.• signup_attempts rows (anti-abuse metadata — email-hash + IP + outcome): 30 days then anonymised.• tenants rows (core tenancy record): lifetime of the tenancy + 90 days post-cancellation (DPA §9 hard-delete window).• Accounting records subset of the above (invoice line items + tenancy identifiers required to reconcile invoices): 5 years from end of the accounting year per Danish Bogføringsloven §10. After 90 days the row is pseudonymised — only the accounting-relevant columns survive into the 5-year archive; identifiers + email + display-name are nulled. TOMs TLS-in-transit; KMS-encrypted-at-rest; per-IP rate limit; Altcha (self-hosted, HMAC-signed PoW) gate above soft threshold; signed-token confirmation flow with single-use enforcement (per audit batch 2 finding M-31). 2.2 Authentication + session management # Field Value Purpose Authenticate users to fremforge; issue and validate session tokens; maintain audit trail of authentication events. Lawful basis Article 6(1)(b) — performance of contract; for security-monitoring traces, Article 6(1)(f) — legitimate interest in fraud + abuse prevention. Categories of data subjects Any authenticated fremforge user (org member, admin, or break-glass operator). Categories of personal data OIDC/SAML subject identifier; email (if the IdP propagates it); session ID; access-token hash (stored hashed, never plaintext); IP; user agent; timestamp. Recipients (internal) Operations on-call (audit log review during incident response). Recipients (sub-processors) T Cloud RDS (session-row store); T Cloud DCS Redis (ephemeral session cache, see DPA Annex A.4 amendment). Customer-side: the Customer\u0026rsquo;s own OIDC/SAML IdP (Microsoft Entra, Okta, Google Workspace, Authentik, etc.) — the Customer\u0026rsquo;s processor, not fremverk\u0026rsquo;s sub-processor. International transfers Determined by the Customer\u0026rsquo;s IdP location. fremverk-side processing is EU-only. Retention Active session: TTL 7 days. Session table after expiry: 30 days for forensics. Authentication audit trail: 90 days hot + 3 years immutable WORM archive (DPA Annex A.7). TOMs TLS-in-transit; HTTPS-only cookies; SameSite=Strict; CSRF token; rate-limit on /login/discover; Altcha (self-hosted, HMAC-signed PoW) gate on threshold. 2.3 Repository content + Git operations # Field Value Purpose Host the customer\u0026rsquo;s source code, run Git operations (clone, push, pull), display issues + PRs, deliver webhooks. Lawful basis Article 6(1)(b) — performance of contract. Categories of data subjects Customer\u0026rsquo;s developers (org members), commit authors (may include former contributors who are no longer org members), people referenced in issues/PRs/code-review comments. Categories of personal data Commit author name + email (in git log metadata); issue/PR comment text (free-form, may include any personal data the Customer chose to include); SSH public keys; webhook endpoint URLs. Recipients (internal) Operations on-call (only on incident-response basis with audit-logged justification). Recipients (sub-processors) T Cloud SFS Turbo (git object store); T Cloud OBS (LFS objects + repository-archive snapshots); T Cloud RDS (Forgejo\u0026rsquo;s metadata DB — issues, PRs, users, hooks). International transfers None. T Cloud eu-de only. Retention Active repository content: lifetime of the tenancy. After cancellation: 90 days post-cancellation hard-delete window (DPA §9). After repository deletion within an active tenancy: 14 days backup-retention grace before purge from snapshot tier (the same 14-day window the live-tier backup lifecycle in DPA §9 + Annex A.9 enforces — audit P2-27 fixed the broken cross-reference; the previous \u0026ldquo;DPA Annex A.10\u0026rdquo; cite was wrong, A.10 is Personnel). Audit log of repository-level operations: 90 days hot + 3 years immutable WORM archive (DPA Annex A.7). TOMs KMS-encrypted-at-rest (SFS Turbo + OBS); per-tenant access control (Forgejo orgs); webhook-egress filtered through outbound proxy when implemented (currently /32-allowlisted via auto-refresh CronJob, see fremforge/forgejo/.infrastructure/k8s/forgejo-egress-refresh.yaml). 2.4 Billing + payment processing # Field Value Purpose Charge subscription Fees; issue invoices; reconcile payment failures; send payment-receipt emails. Lawful basis Article 6(1)(b) — performance of contract; Article 6(1)(c) — legal obligation (Bogføringsloven §10 retention). Categories of data subjects Authorised billing contact for the customer organisation (typically the operator who signed up). Categories of personal data Billing contact email; billing country; VAT identifier; payment-method tokenized identifier (Mollie returns a token, never the PAN); SEPA mandate ID; transaction state-machine timestamps; invoice line items + amounts. No card PAN. No bank account number. Recipients (internal) Finance + operations on-call. Recipients (sub-processors) Mollie B.V. (payment processor — sees full card or SEPA details under PCI-DSS scope; fremverk receives only the tokenized result); T Cloud RDS (invoice + tenant-billing-state store); Lettermint B.V. (invoice email delivery); Visma Dinero ApS (accounting / 5y statutory invoice retention under Bogføringsloven §10 — see DPA Annex B). International transfers None at fremverk\u0026rsquo;s scope. Mollie\u0026rsquo;s card-network sub-processors (Visa Europe Services Inc. UK branch; Mastercard Europe SA Belgium) are PCI-DSS-attested; per DPA Annex B note. Retention Active billing: lifetime of the tenancy.Post-cancellation: invoices + transaction records (the accounting-records subset) are retained 5 years from the end of the accounting year per Danish Bogføringsloven §10. Mollie / Dinero processor-side records follow the same legal floor (handled under each processor\u0026rsquo;s DPA). Customer-Personal-Data fields not required for accounting reconciliation (email, display-name, repository content references) are pseudonymised at 90 days post-cancellation under DPA §9 — only the accounting-relevant columns survive into the 5-year archive. TOMs TLS-in-transit; PCI-DSS Level 1 at the Mollie boundary; idempotency token on every webhook; Mollie egress IP allowlist on the inbound webhook ELB (per audit batch 2 finding H-15a). 2.5 Operational logs + observability # Field Value Purpose Diagnose product errors; trace incidents; meet audit obligations under DPA Annex A.7. Lawful basis Article 6(1)(f) — legitimate interest in service stability + security monitoring; Article 6(1)(c) — legal obligation (audit-trail retention under DPA Annex A.7 for AUP enforcement). Categories of data subjects Any user whose request transits the fremforge stack (request-path traces include user identifier + IP). Categories of personal data Request paths; user-agent strings; IPs (anonymised or pseudonymised before storage where feasible); user identifiers; structured business-event metadata. Recipients (internal) Operations on-call (LTS read access); security on-call (audit-stream read access). Recipients (sub-processors) T Cloud LTS (log store); T Cloud OBS WORM bucket (3-year audit archive — per DPA Annex A.7); T Cloud SMN (operator alert delivery for byte-rate / chain-break / stream-sprawl signals — no Customer Personal Data in the message body, only resource identifiers). International transfers None. Retention Operational logs (api/forgejo/jobs LTS groups): 30 days hot. Audit logs (audit LTS group): two-tier. Hot (queryable) tier with full event payload (actor, action, fields_json) is a per-tenant policy with presets of 90 / 180 / 365 / 730 days; default 90 days for the standard plan, 365 days for enterprise / enterprise_trial / internal plans (Customer tenant admin sets the tier at Authentication policy → Audit log retention; the CHECK constraint at migration 0146 enforces BETWEEN 1 AND 730). After the per-tenant cutoff, the audit-payload-reaper redacts actor and fields_json to null while the SHA-256 chain hashes are retained for the full 3-year window. Hash-chain anchor objects under the WORM bucket prefix chain-anchors/\u0026lt;stream\u0026gt;/: 3 years (locked by the same compliance-mode WORM policy). The retention split is the primary mitigation in DPIA §5.1 and the DPIA\u0026rsquo;s Art-6(1)(f) balancing has been re-run with the 730-day worst-case (DPIA v1.2, 2026-05-25). Processing flows Four in-cluster CronJobs touch this data:(a) lts-quota-guard (every 6h) — lists LTS streams via the LTS API, computes per-stream byte-rate over a 6-hour window, alerts SMN if the extrapolated daily volume crosses the 5 GiB/day threshold. No content read; only metadata (stream id, byte size of API response).(b) lts-archive-and-anchor (every 5min) — queries each of the four LTS streams for the last 5 minutes of entries, computes SHA256(prev_anchor_hash || entries_hash), writes the integrity anchor to s3://fremforge-prd-lts-worm-archive/chain-anchors/\u0026lt;stream\u0026gt;/\u0026lt;ts\u0026gt;.json. Entry contents themselves are NOT copied here; only the SHA256 digest. The 3-year archive of entry contents is performed by the OTC op_svc_lts service principal via separate LTS transfer tasks, on the same bucket but under per-stream prefixes (api-default/, forgejo-default/, jobs-default/, audit-default/).(c) lts-anchor-verifier (hourly) — backward-walks the anchor chain from latest.json, recomputes hashes, alerts SMN oncall-critical on any mismatch. Verifier tolerates pre-existing orphan-genesis anchors (bootstrap-test artefacts) — these are reported as WARN_orphans, not chain breaks. See DPA Annex A.7 for the same disclosure on the customer-facing surface.(d) audit-chain-anchor (every 2min) — per-tenant integrity flow committed in DPA Annex A.7. For each tenant with new audit_events rows since the last anchor, the job walks the rows in primary-key order, computes a running SHA256(prev_row_hash || canonical_row_bytes) chain hash, and writes a small anchor object {tenant_id, chain_hash, event_count, ts} to s3://fremforge-prd-lts-worm-archive/audit-chain-anchors/\u0026lt;tenant\u0026gt;/\u0026lt;ts\u0026gt;.json. Event payloads themselves are NOT copied — only the hash + count + identifier triple. This is the cadence commitment surfaced in DPA Annex A.7 and is distinct from the per-stream lts-archive-and-anchor flow above: the latter anchors LTS log streams platform-wide; this flow anchors the per-tenant audit_events row history so tenants can independently verify their own slice of the audit chain via the self-service export bundle (docs.frem.sh/data-export). Pseudonymous tenant identifiers + chain hashes only — no direct Customer Personal Data crosses the WORM-bucket boundary on this path. TOMs KMS-encrypted-at-rest on both LTS hot and WORM archive (DEW CMK, annual rotation enabled); WORM compliance-mode lock on the OBS bucket prevents tamper-with-or-delete inside the 3-year retention window; least-privilege IAM scope on the read paths. The fremforge-lts-quota-guard IAM user is bound to five project-scoped roles: lts_full (read LTS streams + content query), smn_adm (publish to SMN oncall topics — note the documented Tenant Guest dependency), tenant_guest (read-only across services, the Tenant Guest dependency role required by smn_adm), obs_operate (PUT/GET on the WORM bucket\u0026rsquo;s chain-anchors/* prefix only — bucket policy restricts), kms_admin (datakey ops on the WORM CMK so KMS-encrypted PUTs succeed). The same credential is reused by lts-archive-and-anchor, lts-anchor-verifier, and bunny-edge-refresher (the last for SMN publish only). The credential is provisioned by the platform-foundation IAM stack and lands as the lts-quota-guard-creds Secret in the fremforge-prd namespace. No other automated read-paths exist. 2.6 Customer support + correspondence # Field Value Purpose Handle support tickets, security disclosures, abuse reports. Lawful basis Article 6(1)(b) — performance of contract; Article 6(1)(f) — legitimate interest in security/abuse handling. Categories of data subjects Anyone who contacts fremverk via the operator-mailbox set: support@, security@, abuse@, compliance@, hello@, ops@, enterprise@, and info@fremverk.com (8 mailboxes — canonical enumeration per DPA §11.2 + Annex B Heinlein row). Categories of personal data Email content (free-form, may include any personal data the sender included); attachments. Recipients (internal) Operations + customer-success (shared mailbox access). Recipients (sub-processors) Heinlein Hosting GmbH (mailbox.org — IMAP host for shared mailboxes; data residency Berlin DE). International transfers None. Retention Support correspondence: 12 months. abuse@ correspondence: 5 years (legitimate-interest basis: DSA Art 16 + Art 24 transparency-reporting horizon; Danish Forældelsesloven 5y limitation). security@ correspondence: 24 months (per privacy-product.md §3.6(c) — vulnerability-report retention aligned with industry CVD norms). TOMs TLS-in-transit; mailbox.org server-side encryption; access via SSO + 2FA for operators. 2.7 Marketing + waitlist # Field Value Purpose Private-beta signup capture; product-update communication. Lawful basis Article 6(1)(a) — consent (for marketing emails); Article 6(1)(f) — legitimate interest (transactional product-update emails to existing customers). Categories of data subjects Private-beta signup requesters; existing customers\u0026rsquo; billing contacts. Categories of personal data Email; timestamp. Recipients (internal) Operations (ops@frem.sh shared mailbox triages each signup). Recipients (sub-processors) T Cloud FunctionGraph (signup handler, EU/Germany); Lettermint B.V. (outbound transactional email, NL); Heinlein Hosting GmbH / mailbox.org (ops@frem.sh shared mailbox, DE). International transfers None. Retention Email lands in the ops@frem.sh shared mailbox; retained per the email-records retention policy in §3 (until onboarding completes or withdrawal + 90 days). No fremverk-owned data store touches signups post-2026-05-29 — the OBS bucket previously used was destroyed at cutover. Marketing-email subscriber list: until unsubscribe + 30 days. TOMs Lettermint TLS-only; APIG per-IP throttle; per-IP rate limit on submit; Bunny Shield Advanced WAF. 3. Cross-cutting controls # Encryption-at-rest: per-domain DEW KMS CMKs on RDS, OBS, EVS, SFS Turbo, CBR, LTS WORM. Provider-managed keys on DCS pending OTC platform support (disclosed in DPA Annex A.4). Encryption-in-transit: TLS 1.2+ everywhere. Bunny edge → ELB origin TLS uses cert-manager-issued certificates from Actalis S.p.A. (Italy, Aruba Group, eIDAS QTSP) via ACME-DNS-01 against acme-api.actalis.com (activated 2026-05-04). The CA receives only the FQDN being certified (*-origin.frem.sh) — no Customer Personal Data — and is carved out of the sub-processor list (same posture as VIES). Issuing chain: Actalis DV Server ACME CA G1 → Actalis Authentication Root CA, both Italian-issued under EU Trusted List Reg. 910/2014. D-TRUST GmbH (Germany, Bundesdruckerei) retained as paid eIDAS-QTSP fallback if Actalis discontinues the free ACME service. Access control: scoped IAM users per stack (no shared admin credentials in production); kube-RBAC role-bindings scoped per-resource by name; T Cloud bucket policies scoped per-prefix. Audit log integrity: 3-year WORM bucket on OBS (compliance-mode lock); LTS hash-chain anchor (v2 — pending) for tamper detection. Data subject rights: see DPA §6 for the operational paths (RTBF, access, export, restriction). 4. Change-log # Version Date Change 1.0 2026-05-03 Initial publication. Replaces the placeholder reference in Privacy Notice §2 + plan.md §464. 1.1 2026-05-04 Audit batch 3: §2.5 expanded with the lts-quota-guard / hash-chain-anchor / verifier processing flows and the actual five-role IAM scope on the lts_quota_guard credential. §3 updated to record that the origin-TLS workstream is paused pending CA selection (EU-jurisdictional ACME-supporting CAs in evaluation; D-TRUST and HARICA are the current candidates). The CA, when chosen, receives only FQDNs and is not a sub-processor under Article 28 — DPA Annex B explicitly carves it out. Also: lts_quota_guard credential moved from broad system roles (smn_adm + tenant_guest + kms_admin) to a custom least-privilege IAM policy (smn:topic:publish + smn:topic:list) plus a per-key KMS grant against the LTS WORM CMK only. Five role-bindings → two role-bindings + one custom policy + one KMS grant. 1.2 2026-05-04 Origin-TLS workstream activated. §3 \u0026ldquo;Encryption-in-transit\u0026rdquo; updated: Actalis S.p.A. (Italy, Aruba Group, eIDAS QTSP) chosen as origin-TLS CA, ACME-DNS-01 validated end-to-end. Posture unchanged from v1.1: CA receives only FQDNs, carved out of sub-processor list. D-TRUST retained as paid fallback. ","externalUrl":null,"permalink":"/legal/ropa/","section":"Legal documents","summary":" title: Records of Processing Activities (Article 30 GDPR) date: 2026-05-14 status: Active. Reviewed quarterly; updated on every sub-processor change, every new processing activity, and every significant change to legal basis or retention. controller: fremverk ApS, CVR 39150689, Ringager 4C, 2. tv, 2605 Brøndby, Denmark contact: compliance@frem.sh dpo: not appointed (fremverk does not meet the Art. 37(1) mandatory-DPO criteria — not a public authority, core activities are Git hosting + CI infrastructure not large-scale systematic monitoring of data subjects, and Customer Personal Data does not include Art. 9 special-category or Art. 10 criminal-conviction data on a large scale). Assessment dated 2026-05-10, re-evaluated annually with the next §A.9 DR-drill review window (or sooner on material change to processing scope). compliance@frem.sh handles DSARs and supervisory-authority correspondence. # Records of Processing Activities # This document is the controller’s Article 30 record for the fremforge product. It reflects the current state of processing as of the date above and is reviewed at every sub-processor change, every privacy-impacting feature release, and at minimum quarterly.\n","title":"fremverk Record of Processing Activities (ROPA)","type":"legal"},{"content":"The full set of fremforge legal and compliance documents. Each page below is rendered from a canonical markdown source kept in lockstep with the marketing site; if a rendered page ever disagrees with its source, the source governs.\nCustomer-facing agreements # Terms of Service — the master agreement governing use of the fremforge product. Privacy Notice — categories of data processed, lawful bases, retention, GDPR rights. Data Processing Agreement — GDPR Art. 28 processor terms, sub-processor list, international-transfers posture, audit rights. Acceptable Use Policy — lawful-use rules, prohibited content, DSA Art. 16 notice-and-action, enforcement actions. Service Level Agreement — uptime targets, planned-maintenance windows, security-patch SLA, incident communication, service-credit calculation. Cookie Policy — cookies, consent posture, analytics stance. fremverk-as-Controller documents # Record of Processing Activities (ROPA) — the GDPR Art. 30 register for fremverk-as-Controller activities (HR, billing, audit-chain integrity, sub-processor selection). DPIA — Audit Monitoring — Data Protection Impact Assessment for the platform-wide audit-monitoring activities fremverk operates as Controller. Controller-side Incident Response — runbook for breaches affecting fremverk-as-Controller activities (per DPA §8.5). Pre-GA website notices # The pre-GA website at www.frem.sh is governed by separate, narrower notices that cover only the marketing site and private-beta signup surfaces (not the product):\nWebsite Terms Website Privacy Policy Once self-serve signup opens, the product Terms and Privacy Notice above supersede these website notices for product users.\nRelated # Trust \u0026amp; compliance — overall security posture, sub-processors, and certifications. Security — vulnerability disclosure and incident communication. Status — current uptime and maintenance windows. ","externalUrl":null,"permalink":"/legal/","section":"Legal documents","summary":"The full set of fremforge legal and compliance documents. Each page below is rendered from a canonical markdown source kept in lockstep with the marketing site; if a rendered page ever disagrees with its source, the source governs.\n","title":"Legal documents","type":"legal"},{"content":" Pricing\nOne plan. Per seat. In EUR. Every seat ships with sovereignty, supply-chain security, hosted runners, and full export rights. One price covers Actions minutes, security signing, dependency scans, and on-demand data export — all on EU infrastructure. Monthly Annual −15% €30 / seat / month Billed monthly. Cancel any time at end of paid month.\nBilled in EUR. VAT reverse-charge for EU B2B with a valid VIES VAT number.\nAt today's mid-market rates, €30 is roughly £26 / CHF 28 / kr 320 NOK / kr 224 DKK. Your effective cost in your local currency varies with FX on each invoice date. Customers outside the EUR zone are charged in EUR; their bank or card provider applies the conversion.\nWaitlist for launch pricing → 30-day free trial on signup. Card authorisation at signup via Mollie hosted checkout (€0 — no funds taken; some banks may briefly pre-auth €0.01 and reverse it). Trial auto-converts to your monthly plan on day 30; cancel any time before then in Admin → Billing at no cost. We send a reminder 3 days before the auto-charge.\nTrial caps: 1 seat, 10 repositories, 500 runner-minutes pooled across the full 30-day trial. The full 1,000 runner-minutes/seat monthly pool unlocks at first payment. Caps protect the platform during the trial window; legitimate evaluation fits comfortably — that's ~25-50 typical CI runs.\nAnnual term: €306/seat charged upfront for the year. If you cancel, access continues to your committed-until date and the year stands as paid. Auto-renews unless cancelled at least 30 days before term end. Full detail in the terms of service. What's included Forgejo surface. Repos, issues, PRs, package registry — full upstream. Hosted CI runners. 1,000 min/seat/month pooled. Concurrent jobs: 2 per seat, max 100/org. €0.01/min after pool. Supply chain security. Pre-receive secret scanning, dependency scanning, signed commits, SLSA provenance. Hosted Renovate. Monthly cadence + weekly vulnerability-triggered PRs. Storage. 5 GB repo + 5 GB LFS + 5 GB packages, pooled (15 GB/seat). Package egress. Soft cap 100 GB/seat/month; hard cap throttles to 1 Mbps. No overage charge. SSO enforcement. OIDC + SAML, per-org session binding. SCIM 2.0 user provisioning. Push users and groups from Okta, Entra, Authentik, or any compliant IdP. Per-tenant bearer-token auth with dual-token rotation. OIDC federation. Short-lived T Cloud credentials. No long-lived deploy keys. Public REST API. Same surface humans use. Ready for AI agents. AI integrations (BYOK). PR review, Renovate explanations, customer-callable /ai/complete. Bring your own key — Anthropic, OpenAI, Mistral, Vertex Gemini, or any OpenAI-compatible URL. Data path \u0026amp; sovereignty → Public repos supported. Private by default. One-click tamper-evident export. Repos, LFS, Actions logs, audit slice, attestations — zipped with a SHA-256 manifest. Audit log retention up to 2 years. Configurable per tenant (90 / 180 / 365 / 730 days). Hash-chained index stays forever; payload ages out per your policy. Storage overage. €0,20/GB/month on the relevant pool, billed in arrears. How €30 compares Same per-seat tier, same supply chain controls — without the add-on tax.\nGitHub Team + Advanced Security 🇺🇸 hosted in the US $53/seat/mo≈ €49/seat/mo · €588/seat/yr\n$4 Team + $49 Advanced Security. Actions minutes metered separately. Dependabot consumes Actions minutes on top.\nGitLab Ultimate 🇺🇸 hosted in the US $99/seat/mo≈ €92/seat/mo · €1.100/seat/yr\nSAST, DAST, dependency \u0026amp; container scanning, vulnerability management. CI minutes metered separately. Premium ($29) does not include the supply chain stack.\nfremforge 🇪🇺 hosted in Germany €30/seat/moflat · €360/seat/yr · €306 on annual commit\nSupply chain stack included. 1.000 CI min/seat pooled. Hosted Renovate. Signed export. Zero US sub-processors.\nUSD prices are published list prices at the time of writing; EUR equivalents converted at ~1.08 USD/EUR for orientation only — your actual EUR equivalent depends on the spot rate when GitHub or GitLab bills your card. fremforge prices in EUR throughout, no FX exposure on renewal. Pricing reviewed annually.\nPayment \u0026 billing € Single currency, single price EUR across every customer, every invoice. No localised pricing games, no FX surprise on renewal.\n⇄ VAT reverse-charge Available for EU B2B customers with a valid VIES VAT number. Verified at signup.\n⊟ Payment methods Card (Visa, Mastercard), SEPA direct debit, SEPA bank transfer, Google Pay, Apple Pay. Processed by Mollie (NL).\nNo minimum seat count. See trust for the full sub-processor list and the DPA for the contractual posture. Waitlist for launch pricing → See product ","externalUrl":null,"permalink":"/pricing/","section":"Pricing","summary":" Pricing\nOne plan. Per seat. In EUR. Every seat ships with sovereignty, supply-chain security, hosted runners, and full export rights. One price covers Actions minutes, security signing, dependency scans, and on-demand data export — all on EU infrastructure. ","title":"Pricing","type":"pricing"},{"content":"Effective Date: 2026-04-25 — Version: 1.0\nLast updated: 2026-04-25\nIntroduction # fremforge is a product operated by fremverk ApS (\u0026ldquo;we\u0026rdquo;, \u0026ldquo;us\u0026rdquo;, or \u0026ldquo;our\u0026rdquo;). This Privacy Policy explains how we handle personal data on www.frem.sh during the current pre-launch phase. A separate policy covers the fremforge product itself (the hosted Git and CI/CD service on frem.sh) and will be published the day we open signup.\nData controller # fremverk ApS\nCVR: 39150689\nVAT: DK39150689\nRingager 4C, 2. tv, 2605 Brøndby, Denmark\nEmail: compliance@frem.sh · info@fremverk.com\nfremforge is a product brand of fremverk ApS; fremverk ApS is the legal and GDPR-responsible entity for all personal data processed in connection with the fremforge pre-launch website.\nWhat this website does not do # We believe privacy claims should be verifiable, so we want to be explicit:\nNo advertising or analytics cookies — this website does not use cookies for analytics, advertising, or cross-site tracking No tracking pixels or fingerprinting — there are no third-party tracking scripts No external font loading — all fonts are self-hosted (no requests to Google, Adobe, or others) No auto-loaded third-party widgets or maps — external services are contacted only if you choose to open an external link Limited browser-side preference storage only — this site may use the browser\u0026rsquo;s localStorage API to remember an appearance preference (light/dark) if you explicitly use the theme switcher; this is not used for analytics, advertising, or cross-site tracking Preferences are stored only after user action — nothing is written to localStorage unless you toggle a preference yourself No consent banner for tracking — because we do not use non-essential cookies or similar technologies for analytics, advertising, or third-party tracking You can verify this using your browser\u0026rsquo;s developer tools (Network and Application tabs).\nIf you choose to open an external link, that destination handles your request under its own policy. This site does not auto-load third-party widgets or embedded maps. Edge delivery and caching are covered separately in the Hosting section below; they are operational infrastructure rather than browser-side tracking.\nHosting # This website is hosted on T Cloud (Deutsche Telekom), an EU-sovereign cloud provider. The origin is a T Cloud OBS bucket in the eu-de region, with twin-core datacenters in Biere and Magdeburg, Germany. The public website is delivered through Bunny CDN in front of the origin, restricted to EU points of presence.\nTo deliver, cache, and protect the site, T Cloud and Bunny process technical request data such as IP address, timestamp, requested URL, HTTP status code, and user agent in server or edge logs. We use this data solely for content delivery, security monitoring, abuse prevention, and troubleshooting. Operational access logs under our control are retained for a maximum of 30 days. The legal basis is legitimate interest (GDPR Art. 6(1)(f)) in maintaining the security, integrity, and availability of our website.\nPrivate beta signup (email capture) # The private-beta signup form on the home page is the only place on this site that collects personal data from visitors.\nWhat we store\nThe email address you submit. The timestamp of submission. Nothing else. No IP address is stored against the submission, no browser fingerprint, no cookies. Why\nTo contact you by email about the private beta — typically to schedule a short vetting call and walk through onboarding, and to answer any questions you raise by reply.\nWhere\nSignup submissions are not stored in a fremverk-owned database or object store. The signup form sends two emails through Lettermint B.V. (Zwolle, Netherlands): a confirmation to you, and a notification to our ops@frem.sh shared mailbox hosted by Heinlein Hosting GmbH (mailbox.org) in Berlin, Germany. The ops@ inbox copy is the only persistent record we retain on our side; if you reply to either email, your reply lands in the same shared mailbox.\nLegal basis\nConsent (GDPR Art. 6(1)(a)) for sending you the confirmation and onboarding correspondence. You can withdraw consent at any time by replying \u0026ldquo;unsubscribe\u0026rdquo; to any message from us, or by emailing compliance@frem.sh. Legitimate interest (Art. 6(1)(f)) in preventing abuse of the signup form. How long\nUntil 90 days after you either complete onboarding or notify us that you no longer want to proceed, whichever comes first. We do not sell, share, or use signup addresses for any purpose other than the private-beta onboarding correspondence (and any reply you send us).\nAnalytics # When we add analytics to this website, we will use a privacy-focused, EU-sovereign or self-hosted solution that does not use cookies or track individual visitors. Such tools work by aggregating page view counts, referrer information, and approximate geographic region (country level) without storing personal identifiers. If we deploy analytics on that basis, we do not expect a consent banner to be required for analytics because no non-essential cookies or comparable tracking identifiers would be used.\nThis section will be updated when analytics are deployed.\nInformation you provide directly # If you contact us by email outside the private-beta signup form (for example at hello@frem.sh or security@frem.sh), we may receive:\nContact information: name, email address Business information: company name, job title, questions or context you share We use this information to respond to your inquiry and comply with legal obligations.\nLegal basis for processing # Under GDPR, we process your data based on:\nConsent (Art. 6(1)(a)): for the private-beta signup confirmation and onboarding correspondence, and any other optional purpose you explicitly opt in to Contractual necessity and pre-contractual steps (Art. 6(1)(b)): when responding to inquiries about future services Legal obligation (Art. 6(1)(c)): when we need to retain records or comply with applicable law Legitimate interest (Art. 6(1)(f)): for website delivery via T Cloud and Bunny, server and edge log processing, security monitoring, abuse prevention, and improving service reliability Data sharing # We do not sell, trade, or rent your personal information. We may share data with:\nLettermint B.V. — Zwolle, Netherlands — outbound transactional email (private-beta signup confirmations, system notifications). EU-only operating entity (NL — no US parent). Heinlein Hosting GmbH (mailbox.org) — Berlin, Germany — shared-mailbox hosting (correspondence sent by you to support@, security@, compliance@, hello@, info@fremverk.com). EU-only operating entity, no US parent. T Cloud (Deutsche Telekom AG) — Biere/Magdeburg, Germany — primary hosting (all platform data; the private-beta signup form does not store data on T Cloud, only emails through Lettermint). Bunny CDN d.o.o. — EU PoPs only (HQ Slovenia) — edge delivery, WAF, DDoS for the marketing site. Legal authorities when required by applicable law. The private-beta signup form has no third-party bot-mitigation processor. Bot abuse is contained server-side via a honeypot field, a minimum-dwell-time check, per-IP throttling at the API gateway, and edge WAF. The Forgejo tenant signup form (post-vetting) uses Altcha (self-hosted, MIT-licensed, HMAC-signed proof-of-work; runs in-process inside the api monolith).\nData retention # Server and edge logs: maximum 30 days Private-beta signup email addresses: until 90 days after onboarding completes or you withdraw, whichever comes first Direct email correspondence: for the duration of our business relationship plus 5 years, or as required by Danish bookkeeping legislation Your rights # Under GDPR, you have the right to:\nAccess your personal data (Art. 15) Rectify inaccurate data (Art. 16) Erase your data (Art. 17), subject to GDPR Art. 17(3) carve-outs — specifically Art. 17(3)(b): where retention is required for compliance with a legal obligation under Union or Member-State law to which fremverk is subject. The principal carve-outs in practice are Danish Bogføringsloven §10 (5-year retention of accounting records: invoice line items + tenancy identifiers required to reconcile invoices) and the audit-trail retention promised in DPA Annex A.7 (3-year WORM archive for security-relevant audit events). Erasure of these subsets is suspended for the statutory period; PII fields not required for the legal-obligation purpose are pseudonymised separately on request, per DPA §9. Restrict processing (Art. 18) Data portability — receive your data in a structured, machine-readable format (Art. 20) Object to processing based on legitimate interests (Art. 21) Withdraw consent at any time, without affecting the lawfulness of prior processing (Art. 7(3)) To exercise these rights, contact us at compliance@frem.sh. We will respond within 30 days.\nSupervisory authority # You have the right to lodge a complaint with the Danish Data Protection Agency:\nDatatilsynet\nCarl Jacobsens Vej 35, 2500 Valby, Denmark\nWebsite: datatilsynet.dk\nEmail: dt@datatilsynet.dk\nData security # We implement appropriate technical and organisational measures to protect your personal data, including encrypted connections (TLS), least-privilege access controls, and operational monitoring on the hosting platform.\nEU sovereignty / US extraterritorial law # The fremforge marketing site, private-beta signup, and shared mailboxes run on a stack with no US-parented processor in the path: T Cloud (Deutsche Telekom, Germany), Bunny CDN (EU PoPs only), Lettermint B.V. (Zwolle, Netherlands), and Heinlein Hosting GmbH / mailbox.org (Berlin, Germany). Bot mitigation is server-side only; no third-party captcha vendor. Zero US-parented sub-processors on any path.\nThe product (post-signup) follows the same posture in tighter detail. See the product DPA for the full Article 28 processor terms and the product privacy notice for the data-subject view.\nInternational transfers # We keep website hosting within the European Economic Area (EEA). The private-beta signup emails route through Lettermint (NL) to our ops@frem.sh mailbox at Heinlein Hosting / mailbox.org (DE) — also EEA. If a service used for website operations involves a transfer outside the EEA, we will rely on an appropriate transfer mechanism under GDPR and update this policy accordingly.\nChanges to this policy # We may update this Privacy Policy from time to time. Material changes will be indicated by updating the \u0026ldquo;Last updated\u0026rdquo; date at the top of this page.\nA separate fremforge product privacy notice is published at /legal/privacy-product/ and supersedes this pre-launch website notice for product users once signup opens. The product notice covers repository and CI usage, log retention, billing data, sub-processor list, and data-subject request process in detail.\nChange log # Version Date Change 1.0 2026-04-25 Initial publication. ","externalUrl":null,"permalink":"/privacy/","section":"Privacy policy","summary":"Effective Date: 2026-04-25 — Version: 1.0\nLast updated: 2026-04-25\nIntroduction # fremforge is a product operated by fremverk ApS (“we”, “us”, or “our”). This Privacy Policy explains how we handle personal data on www.frem.sh during the current pre-launch phase. A separate policy covers the fremforge product itself (the hosted Git and CI/CD service on frem.sh) and will be published the day we open signup.\n","title":"Privacy policy","type":"privacy"},{"content":" Product\nEU-sovereign CI/CD with Git included. A flat-priced platform with Forgejo, hosted runners, SSO enforcement, and the full supply chain security stack — built on upstream Forgejo and operated by fremverk on T Cloud, the Deutsche Telekom EU-sovereign cloud, in Germany (Biere/Magdeburg, eu-de). Forgejo runs unmodified, so the forge layer stays compatible with the wider ecosystem. The differentiator is what we wrap around it. Join the waitlist → See pricing What you get Everything in one €30/seat plan. No \"Advanced Security\" add-on, no Actions metering surprise, no Marketplace trap.\n⎇ Full Forgejo surface Repositories, issues, pull requests, package registry — unmodified upstream Forgejo, no soft-forks.\n⚙ Hosted CI runners 1,000 minutes/seat/month pooled at org level, 2 concurrent jobs per seat (max 100/org). Ephemeral per-job pods on T Cloud — hardened posture, EU-resident. Runtime isolation →\n🛡 Supply chain security Pre-receive secret scanning, dependency scanning on PRs, signed commits, SLSA provenance — included, not an add-on SKU.\n🔐 SSO enforcement OIDC or SAML to your IdP (Authentik, Entra ID, Keycloak, Okta). Per-org session binding; SSH keys honour the IdP session.\n⚡ OIDC token federation Runners federate into your T Cloud agencies (or any OIDC-trusting cloud) with short-lived credentials. No long-lived deploy keys in repo secrets.\n⤴ SSH-over-443 Clone via ssh://git@ssh.frem.sh:443. Skips the corporate-firewall pain that blocks outbound port 22.\nSupply chain security, in detail GitHub charges $49/seat/month for the Advanced Security equivalent. We include the meaningful part.\nPre-receive secret scanning. High-confidence patterns rejected before the commit enters immutable history. Dependency scanning on PRs. Trivy/osv-scanner on the manifest diff; findings as PR comments; optional merge-block on CRITICAL CVEs. Signed commits. SSH-key signing as default (Forgejo verifies natively); GPG also supported. No third-party log fan-out. SLSA provenance. Hosted runners emit signed provenance; verify with slsa-verifier. Three-level RBAC. Platform-floor controls, org-default policy set by Owner/Admin, per-repo override that can tighten freely. Package registry. Containers, npm, Maven, Go modules, generic. Keyless commit signing is available via fremverk's self-hosted Sigstore stack on T Cloud 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 at Authentication policy → Require OIDC-signed commits. See docs.frem.sh/get-started/keyless-commit-signing. First-class public API — ready for AI agents Every admin action is a documented REST endpoint. AI coding agents operate against the same surface as the humans.\nOpenAPI 3.1 spec Personal access tokens and OAuth 2.0 client credentials supported. No admin-only endpoints, no surprise gaps. Spec on docs.frem.sh/api.\nAI-agnostic by design Whatever AI your team uses (Claude Code, Cursor, Windsurf, Codex CLI, Aider) operates against the same Git, REST, and MCP surface. No forge-level AI lock-in.\nAgent-native delegation On-behalf-of semantics with scoped, time-boxed delegated mandates is on the near-term roadmap. The goal: the first EU Git host your AI can buy for you.\nWhere it runs Every automated processing surface is operated by entities with no US parent.\nSurface Host Location Forgejo UI, Git, API, package registryT Cloud CCE (Kubernetes)eu-de (Biere/Magdeburg, DE) Hosted CI runnersT Cloud CCI (per-job pods)eu-de (Biere/Magdeburg, DE) Control plane (billing, metering, SSO middleware, audit chain)TypeScript monolith on T Cloud CCEeu-de (Biere/Magdeburg, DE) Marketing site, docs, statusOBS origin + Bunny CDNOrigin eu-de, edge at EU PoPs only Outbound transactional emailLettermint B.V.Zwolle, Netherlands Self-hosted PoW captchaAltcha (in-monolith; MIT-licensed, HMAC-signed PoW) on T Cloud CCEeu-de (Biere/Magdeburg, DE) PaymentsMollieNetherlands Accounting / invoice renderingVisma DineroCopenhagen, Denmark See trust for the full sub-processor list, inherited certifications (T Cloud: ISO 27001, 27017, 27018, BSI C5 Type 2, TISAX), the own-certification roadmap (ISO 27001 Stage 1 audit within 18 months, certification within 24 months, per DPA §12.1), and the DPA for the contractual posture. What it isn't Not \"hosted Forgejo\". Forgejo is the forge layer underneath; the product is the CI/CD, runners, SSO enforcement, supply chain stack, and API around it. Not a SourceForge clone. The frem- prefix signals lineage (distinctive prefix + descriptive morpheme), not a 2000s-era project host. Not a US SaaS with an EU sticker. No US parent company, and no US data processor on any path. Zero US-parented sub-processors at the operating-company level — see trust.† Not a Copilot. We don't ship a forge-integrated AI product. Your team picks the AI. Forge-level AI lock-in is the next sovereignty trap. Not locked in. If you ever want to leave, the export is a one-click signed tarball. Standard formats throughout. That's the whole point. Join the waitlist → See pricing ","externalUrl":null,"permalink":"/product/","section":"Product","summary":" Product\nEU-sovereign CI/CD with Git included. A flat-priced platform with Forgejo, hosted runners, SSO enforcement, and the full supply chain security stack — built on upstream Forgejo and operated by fremverk on T Cloud, the Deutsche Telekom EU-sovereign cloud, in Germany (Biere/Magdeburg, eu-de). Forgejo runs unmodified, so the forge layer stays compatible with the wider ecosystem. The differentiator is what we wrap around it. ","title":"Product","type":"product"},{"content":"Effective Date: 2026-04-25 — Version: 1.0\nLast updated: 2026-04-25\nReport a vulnerability # Email security@frem.sh. Encrypted mail welcome; PGP key fingerprint published on the trust page.\nWe acknowledge reports within 48 business hours (see the safe-harbour clause below for the formal commitment). Critical issues in the fremforge surface are patched ahead of upstream Forgejo when required; upstream bugs are coordinated with the Forgejo security team under their disclosure policy. Published time-to-patch commitments by severity are on the trust page.\nVulnerability disclosure # Report vulnerabilities to security@frem.sh.\nA machine-readable disclosure policy is published at frem.sh/.well-known/security.txt per RFC 9116, including scope, contact, preferred languages, and acknowledgement window.\nSafe-harbour: good-faith research within the published scope is covered by safe-harbour. fremverk will not pursue legal action against researchers who follow the disclosure policy. We commit to acknowledging vulnerability reports within 48 business hours and to coordinated disclosure on a mutually agreed timeline.\nPGP key fingerprint for security@frem.sh is published at frem.sh/trust#security-contact.\nScope # frem.sh — Forgejo UI, Git protocol, API, package registry www.frem.sh, docs.frem.sh, status.frem.sh The fremforge-prd T Cloud tenant Email / transactional surfaces sending from @frem.sh Out of scope # Third-party integrations you configure against fremforge (report to the vendor) Findings that require a pre-authenticated, privileged user session to reproduce beyond what the user already has access to What we publish # Security advisories are posted on the trust page and emailed to the security mailing list. Post-mortems for any incident that affected customer data or availability are published within 14 days.\nChange log # Version Date Change 1.0 2026-04-25 Initial publication. ","externalUrl":null,"permalink":"/security/","section":"Security","summary":"Effective Date: 2026-04-25 — Version: 1.0\nLast updated: 2026-04-25\nReport a vulnerability # Email security@frem.sh. Encrypted mail welcome; PGP key fingerprint published on the trust page.\n","title":"Security","type":"security"},{"content":"Effective Date: 2026-05-14 — Version: 1.9\nThis page is the canonical, deep-linkable register of every sub-processor fremverk engages to deliver the Service. It is committed to in DPA §10 and DPA Annex B, and procurement teams may reference this URL directly in vendor due-diligence documentation.\nChange-notification commitment # Any addition, replacement, or material change to the sub-processor list is announced 30 days in advance via two parallel channels per DPA §10.2: (a) a direct email to each Customer\u0026rsquo;s org billing contact-of-record (the contractual carrier — delivery is recorded in fremverk\u0026rsquo;s audit log with per-recipient email-provider message ids), AND (b) a public posting to this page and the security-notices mailing list (provided for convenience to non-billing addresses such as security teams and compliance leads). Customers who object to a new sub-processor on documented data-protection grounds may exercise the termination right at DPA §10.2 with pro-rata refund of any prepaid unused Fees.\nFor emergency onboarding (e.g., immediate replacement of a sub-processor that is itself the source of a security incident), fremverk publishes within 24 hours of the change and extends the objection window to 30 days post-onboarding. See DPA §10.3.\nSubscribe to change notifications: subscribe to the security-notices mailing list — replies and out-of-band questions land at security-notices@frem.sh (alias forwards to compliance@frem.sh).\nCurrent sub-processors # Sub-processor Purpose Location Certifications DPA / SCCs Deutsche Telekom AG (T Cloud) Core compute, storage, network — every customer-facing surface Biere \u0026amp; Magdeburg, DE ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, TISAX T Cloud DPA — EU controller, no US parent Bunny CDN d.o.o. Edge delivery, WAF, DDoS protection for frem.sh and customer-served static assets EU PoPs (HQ Slovenia) ISO 27001 (2025), SOC 2 Type II (2023) Bunny DPA — EU controller, no US parent Lettermint B.V. Outbound transactional email (verification, dunning, security notices) Zwolle, NL — upstream OVHcloud SAS (FR) + UpCloud Ltd (Amsterdam NL datacenter, Finland-incorporated) Vendor certifications pending evidence (NL — no US parent) Lettermint DPA — EU controller, no US parent Mollie B.V. Payment processing (mandate creation, recurring charges, refunds) Amsterdam, NL PCI-DSS Level 1 Mollie DPA — EU controller, no US parent Heinlein Hosting GmbH (mailbox.org) Shared-mailbox hosting (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlin, Germany ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen (TR 03108) Heinlein Hosting DPA — EU controller, no US parent Visma Dinero ApS Issuance and 5-year statutory retention of invoice bilag under Bogføringsloven §10 — receives org legal name, billing-contact email, VAT number, invoice line items, Mollie payment-id reference. No repository content, no audit-log content, no PAN. Copenhagen, DK ISO 27001 (DK-issued, no US parent) Visma Dinero DPA — EU controller, no US parent Disclosed for transparency — not Article-28 sub-processors # The following counterparties touch the platform but do not process Customer Personal Data on fremverk\u0026rsquo;s behalf and are therefore not sub-processors under GDPR Article 28. They appear here so the customer-facing register is complete:\nCounterparty Role Location Why not a sub-processor Actalis S.p.A. (Aruba Group) Origin-TLS Certificate Authority for *-origin.frem.sh (eIDAS QTSP) Italy, EU The CA receives only FQDNs — never personal data — during the ACME-DNS-01 issuance flow. Carved out of Annex B per DPA §A.4. D-TRUST GmbH (Germany, eIDAS QTSP) retained as named paid fallback. EU Commission VIES service VAT-number validation at signup (reverse-charge qualification) EU institutions Non-commercial public-sector lookup; only the VAT identifier (a business-registration number) is submitted. Disclosed in privacy notice §3.3. Simply.com A/S Registrar + DNS for the brand-redirect domains fremforge.{com,eu,dk} (all 301 → www.frem.sh) Denmark No Customer Personal Data transits Simply.com — only DNS lookups for the redirect targets. Customer-facing surfaces use BunnyDNS (Bunny CDN d.o.o., Slovenia — same sub-processor as the CDN/WAF/edge tier, already disclosed in the Annex B sub-processor table above). What we do not engage # No CDN or edge provider with a US parent is in the request path for customer-facing endpoints. No analytics or telemetry processor. Phase 1 ships with no product analytics at all — matches what the cookie policy + privacy notice already say (no analytics, no consent banner). No Google Analytics, no Mixpanel, no Segment, no Plausible. Self-hosted Plausible (T Cloud eu-de) is on the post-launch roadmap; if/when deployed, it will appear in the change-log below and as a tier-1 first-party processor in Annex B (data stays inside fremverk\u0026rsquo;s T Cloud account; no third-party egress). No AI / LLM provider is invoked on Customer Content. Agent-mandate features (per DPA §11A) act under run-time customer instruction and do not transit a third-party model surface for content; fremverk does not retain Customer Content in any model corpus. The sub-processor stack carries this prohibition contractually downstream — see AI-training prohibitions across sub-processors below. No US payment processor. Mollie (NL) handles every charge. No bot-protection widget vendor. Forgejo signup uses self-hosted Altcha (MIT-licensed, HMAC-signed PoW) running in-process inside the api monolith on the same T Cloud cluster; no Cloudflare Turnstile, no hCaptcha, no Google reCAPTCHA. CLOUD Act posture # Every entry above is an EU-controlled entity with no US parent. Zero CLOUD Act exposure on any processing path. No Schrems II Transfer Impact Assessment is required because no Customer Personal Data is transferred outside the EU/EEA.\nFor the full posture, see DPA §11.3 and the trust index — Schrems II section.\nAI-training prohibitions across sub-processors # The \u0026ldquo;no AI training on Customer data\u0026rdquo; commitment in DPA §6A binds every entity in the sub-processor stack. The supporting public commitments from each sub-processor are listed below for cross-reference. Where a sub-processor publishes a model-training opt-in, fremverk has not opted in.\nSub-processor Public commitment we rely on Deutsche Telekom AG (T Cloud / Open Telekom Cloud) T Cloud Service Description and DPA — IaaS layer; the platform does not access tenant content. T Cloud\u0026rsquo;s AI principles commit to data-minimisation and purpose-limitation in Telekom-developed AI, and the IaaS DPA prohibits use of customer payload for any purpose other than service delivery. Bunny CDN d.o.o. Bunny DPA — Bunny processes traffic for cache + WAF only; no model training rights granted. Bunny\u0026rsquo;s AI policy disclosure confirms no AI model is trained on customer-traffic payloads. Lettermint B.V. Lettermint DPA + Privacy Policy — transactional email scope; outbound-only relay. Customer recipient lists are not used for cross-account model training, and no AI / model-training opt-in has been enabled. Mollie B.V. Mollie Privacy Statement and PSD2 / PCI-DSS scope — transaction processing only; Mollie does not train AI models on transaction metadata for the merchant. Heinlein Hosting GmbH (mailbox.org) mailbox.org Privacy Statement — explicit \u0026ldquo;no AI training, no profiling\u0026rdquo; position; mailbox.org\u0026rsquo;s marketing routinely states \u0026ldquo;Wir trainieren keine KI mit Ihren Daten\u0026rdquo; (\u0026ldquo;we don\u0026rsquo;t train AI on your data\u0026rdquo;). Visma Dinero ApS Visma Group Privacy \u0026amp; AI policy — accounting integration scope; no training on Customer Personal Data crossing the integration. fremverk\u0026rsquo;s bookkeeping path receives org legal name, billing-contact email, VAT number, invoice line items, Mollie payment-id (Customer Personal Data of the org admin); no repository content, no audit-log content, no PAN. Actalis S.p.A. eIDAS QTSP — receives only domain names during ACME-DNS-01 issuance; CA scope precludes content-derivative use. EU Commission VIES service Public-sector lookup; out of scope for AI training (no consumer-grade ML trained on VAT registry traffic). Simply.com A/S Registrar / DNS for redirect domains only; no Customer Personal Data path. If any sub-processor changes its position on AI training, fremverk is obliged under DPA §6 (Sub-processors) to give Customers prior notice and the right to object before the new processing begins. The change-log at the bottom of this page records every such transition.\nCard-network footnote # Card payments through Mollie are technically routed via PCI-DSS-attested card-network sub-sub-processors: Visa Europe Services Inc. (UK branch) and Mastercard Europe SA (Belgium). Both are EU operating entities, but their ultimate parents (Visa Inc., Mastercard Inc.) are US-incorporated. fremverk does not contract with these networks directly — they are sub-sub-processors of Mollie under PCI-DSS network rules. The \u0026ldquo;no US-parented\u0026rdquo; claim above applies to fremverk\u0026rsquo;s own sub-processor stack at the operating-company level. Customers preferring zero US-parent exposure on the payment path may pay by SEPA Direct Debit (Mollie\u0026rsquo;s SEPA path involves no card-network sub-sub-processor). See DPA §11.3 for the full framing.\nCustomer-requested alternatives # The default sub-processor set already has zero US-parented exposure. Under Enterprise-on-Demand, Customers may additionally request:\nAudit of any region-pinning preferences across T Cloud regions (eu-de is default; alternative EU regions available on request subject to feature parity). Region-specific data-residency commitments stronger than the default (e.g., contractual pinning to a single eu-de availability zone). Contact enterprise@frem.sh to scope.\nHistorical changes # This section records the change history of the sub-processor list in reverse chronological order. The list above is always the current state.\nDate Change Notice published 2026-05-14 Outbound transactional email migrated from Sendinblue SAS (Brevo, FR) to Lettermint B.V. (Zwolle, NL). Brevo decommissioned 2026-05-14. Outbound email path remains EU-only with no US-parented processor; the AI-training prohibitions row was rewritten accordingly. Mirrors DPA v1.9. n/a (no signed customers; pre-launch) 2026-05-08 Round-7 transparency batch: Actalis S.p.A. (origin-TLS CA, IT, eIDAS QTSP), EU VIES service (VAT validation), and Simply.com A/S (DK, brand-redirect DNS) added to a new \u0026ldquo;Disclosed for transparency — not Article-28 sub-processors\u0026rdquo; section. None receive Customer Personal Data; carved out of Annex B per DPA §A.4. n/a (no signed customers; pre-launch) 2026-05-06 Visma Dinero ApS (Denmark) added to Annex B as a billing-path sub-processor. Customer Personal Data scope: organisation legal name, billing contact, VAT number, invoice line items, Mollie payment id. 5-year statutory retention under Danish Bogføringsloven §10. Mirrors DPA v1.4 (revised in v1.5 — earlier \u0026ldquo;no Customer Personal Data path\u0026rdquo; wording was incorrect). n/a (no signed customers; pre-launch) 2026-04-27 Inbound shared-mailbox hosting moved from Microsoft Ireland Operations Ltd. to Heinlein Hosting GmbH (mailbox.org), Berlin, Germany — eliminates the prior US-parented sub-processor on the inbound mailbox path n/a (no signed customers; pre-launch) 2026-04-25 Initial register Effective Date Contact # For sub-processor questions:\nPrivacy / DPA scope: compliance@frem.sh Procurement / vendor due-diligence: enterprise@frem.sh Security mailing-list subscription: lists.frem.sh/subscription/form (alias: security-notices@frem.sh — forwards to compliance@) See also: Trust index · Privacy notice\n","externalUrl":null,"permalink":"/trust/subprocessors/","section":"Trust","summary":"Effective Date: 2026-05-14 — Version: 1.9\nThis page is the canonical, deep-linkable register of every sub-processor fremverk engages to deliver the Service. It is committed to in DPA §10 and DPA Annex B, and procurement teams may reference this URL directly in vendor due-diligence documentation.\n","title":"Sub-processors","type":"trust"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"Effective Date: 2026-04-25 — Version: 1.0\nLast updated: 2026-04-25\nAbout us # fremforge is a product brand of fremverk ApS. These Terms of Service (\u0026ldquo;Terms\u0026rdquo;) are entered into between you and:\nfremverk ApS\nCVR: 39150689\nVAT: DK39150689\nRingager 4C, 2. tv, 2605 Brøndby, Denmark\nEmail: hello@frem.sh · info@fremverk.com\nA separate product Terms of Service is published at /legal/terms/ and governs use of the fremforge Git hosting product itself. These pre-GA website Terms cover only the marketing site, private-beta signup form, and documentation surfaces at www.frem.sh, frem.sh, and docs.frem.sh.\nAgreement to terms # By accessing or using this website, you agree to be bound by these Terms and our Privacy Policy. If you do not agree, please do not use this website.\nAbout the pre-GA site # fremforge is currently in private beta — by invitation, with a vetted cohort. Until self-serve signup opens to the general public, this website exists to describe the product, share product information, and collect private-beta access requests through a voluntary signup form.\nSubmitting the private-beta signup form does not:\nCreate an account Reserve a subscription or seat Guarantee price, availability, or feature set Constitute a contract for the supply of services After you submit the form, we email you from ops@frem.sh within a few business days to schedule a vetting call. Acceptance into the private beta is at fremverk\u0026rsquo;s discretion. Pricing and product-specific terms for the fremforge product itself are at /legal/terms/; they apply once you onboard.\nUse of website # Permitted use # You may use this website for lawful purposes related to learning about fremforge, requesting access to the private beta, and contacting us.\nProhibited use # You may not:\nUse this website in any way that violates applicable laws Attempt to gain unauthorised access to our systems Use automated tools to scrape or collect data from this website, or to submit private-beta signup entries in bulk Interfere with the proper functioning of this website Intellectual property # All content on this website (including text, graphics, logos, and software) is the property of fremverk ApS or its content suppliers and is protected by intellectual property laws. You may not reproduce, distribute, or create derivative works from any content without our prior written consent.\nForgejo, which fremforge runs unmodified, is licensed under the GNU General Public License v3.0 or later and is © its respective copyright holders. References to Forgejo on this site do not imply endorsement by the Forgejo project.\nDisclaimer of warranties # This website and its content are provided on an \u0026ldquo;as is\u0026rdquo; and \u0026ldquo;as available\u0026rdquo; basis. To the maximum extent permitted by applicable law, we disclaim all warranties, express or implied, including but not limited to implied warranties of merchantability, fitness for a particular purpose, and non-infringement. We do not warrant that this website will be uninterrupted, error-free, or free of harmful components.\nStatements about the future fremforge product (including pricing, feature scope, launch timing, and regional availability) are forward-looking and subject to change. Nothing on this website constitutes a binding offer, quote, or commitment to deliver the product on specific terms.\nLimitation of liability # To the maximum extent permitted by Danish law:\nWe are not liable for any indirect, incidental, special, or consequential damages, including loss of profit, data, or business opportunity arising from use of this pre-launch website Our total aggregate liability for any claim related to this website or these Terms shall not exceed EUR 1,500 We are not liable for any third-party services, platforms, or providers referenced on this website Indemnification # You agree to indemnify and hold harmless fremverk ApS, its directors, and employees from any claims, damages, or expenses arising from your use of this website or violation of these Terms.\nThird-party links # This website contains links to third-party sites, including forgejo.org, the fremverk corporate site, and others. We are not responsible for the content, accuracy, or practices of these external sites. Inclusion of a link does not imply endorsement.\nForce majeure # Neither party shall be liable for any delay or failure to perform its obligations under these Terms where such delay or failure results from circumstances beyond the party\u0026rsquo;s reasonable control, including but not limited to natural disasters, war, terrorism, pandemics, strikes, government actions, power failures, internet or telecommunications failures, or cyberattacks.\nGoverning law and jurisdiction # These Terms are governed by and construed in accordance with the laws of Denmark, without regard to its conflict-of-law principles. Any disputes arising under or in connection with these Terms shall be subject to the exclusive jurisdiction of the courts of Denmark.\nDispute resolution # Before initiating court proceedings, the parties agree to first attempt to resolve any dispute through good-faith mediation. If the dispute is not resolved within 60 days of the initial mediation request, either party may proceed to litigation in accordance with the governing law section above.\nChanges to terms # We reserve the right to modify these Terms. Material changes will be posted on this page with an updated \u0026ldquo;Last updated\u0026rdquo; date. Changes take effect 30 days after posting. Your continued use of this website after the effective date constitutes acceptance of the modified Terms.\nEntire agreement # These Terms, together with our Privacy Policy, constitute the entire agreement between you and fremverk ApS regarding the use of the pre-launch fremforge website. Any prior or contemporaneous agreements, communications, or understandings relating to the subject matter hereof are superseded.\nSeverability # If any provision of these Terms is found to be invalid or unenforceable by a court of competent jurisdiction, the remaining provisions shall continue in full force and effect. The invalid provision shall be modified to the minimum extent necessary to make it valid and enforceable.\nContact # For questions about these Terms, contact:\nfremverk ApS\nEmail: hello@frem.sh · info@fremverk.com\nChange log # Version Date Change 1.0 2026-04-25 Initial publication. ","externalUrl":null,"permalink":"/terms/","section":"Terms of service","summary":"Effective Date: 2026-04-25 — Version: 1.0\nLast updated: 2026-04-25\nAbout us # fremforge is a product brand of fremverk ApS. These Terms of Service (“Terms”) are entered into between you and:\n","title":"Terms of service","type":"terms"},{"content":"Effective Date: 2026-05-19 — Version: 1.5\nLast updated: 2026-05-19\nSummary # fremforge is EU-sovereign Git hosting built on upstream Forgejo and operated by fremverk ApS (Denmark). Every surface runs in the European Union. No customer data leaves EU jurisdiction.\nEvery processing surface (repositories, CI, audit, billing, authentication, outbound email, inbound shared-mailbox correspondence) runs on entities with no US parent. Zero US-parented sub-processors on any path. See the product DPA §11.3 for the full posture.\nThis page is the canonical reference for where your data lives, who processes it, what certifications apply, and how to reach us.\nData controller # fremverk ApS CVR: 39150689 Ringager 4C, 2. tv, 2605 Brøndby, Denmark Email: compliance@frem.sh · info@fremverk.com\nHosting and regions # Surface Processor Region Forgejo UI, Git, API, package registry T Cloud (Deutsche Telekom) eu-de (Biere/Magdeburg, DE) Marketing, docs, status Bunny CDN EU PoPs only Outbound transactional email (waitlist, system notifications, billing, magic-links) Lettermint B.V. Zwolle, Netherlands Inbound shared-mailbox correspondence (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Heinlein Hosting GmbH (mailbox.org) Berlin, Germany Payments Mollie Netherlands Billing engine fremforge in-monolith engine (self-hosted by fremverk) eu-de (T Cloud) Accounting integration (fremverk-side bookkeeping per Bogføringsloven §10; receives org legal name, billing-contact email, VAT number, invoice line items, Mollie payment-id. No repository content, no audit-log content, no PAN.) Visma Dinero Copenhagen, Denmark Sub-processors # The current sub-processor list is maintained here. Any change is announced 30 days in advance to the security mailing list and on this page.\nSub-processor Purpose Location Certifications Deutsche Telekom AG (T Cloud) Core compute, storage, network Biere/Magdeburg, DE ISO 27001, 27017, 27018; BSI C5 Type 2; TISAX Bunny CDN d.o.o. Edge delivery, WAF, DDoS EU PoPs (HQ Slovenia) ISO 27001 (2025), SOC 2 Type II (2023) Lettermint B.V. Outbound transactional email Zwolle, Netherlands Vendor certifications pending evidence (NL — no US parent) Heinlein Hosting GmbH (mailbox.org) Shared-mailbox hosting (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlin, Germany ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen (TR 03108) Mollie B.V. Payment processing Amsterdam, NL PCI-DSS Level 1 Visma Dinero ApS Accounting integration (fremverk-side bookkeeping per Bogføringsloven §10; receives org legal name, billing-contact email, VAT number, invoice line items, Mollie payment-id. No repository content, no audit-log content, no PAN.) Copenhagen, DK ISO 27001 (DK-issued, no US parent) Bot mitigation does not involve a third-party processor: the waitlist relies on layered server-side checks (honeypot, dwell-time, per-IP throttling, edge WAF). The Forgejo signup form uses self-hosted Altcha (MIT-licensed, HMAC-signed proof-of-work) running in-process inside the api monolith on the same T Cloud cluster; no third-party widget JS, no external sub-processor.\nEdge WAF — Bunny Shield posture (launch baseline) # The Bunny CDN pullzones in front of frem.sh (Forgejo) and the api surface (/_app/*) run Bunny Shield Basic at launch, not Shield Advanced. Shield Basic provides volumetric DDoS mitigation, rate limiting, and IP/geo/bot signal filtering; the OWASP Core Rule Set (CRS) WAF available in Shield Advanced is not enabled on these two pullzones. The decision is intentional: Forgejo\u0026rsquo;s URL patterns (Git protocol paths, pull-request diff routes, raw-blob fetches with hex-string identifiers, signed-URL query-strings) produced a high false-positive rate against the upstream CRS during pre-launch testing; an over-aggressive WAF that breaks legitimate Git operations or Forgejo UI flows would have shipped a worse customer outcome than the residual edge-layer risk. Mitigation lives in-app rather than at the edge: pre-receive secret-scanning, Altcha PoW on signup/login, per-IP and per-tenant rate limits in the Hono middleware, signed-token auth on every webhook receiver, and the audit-chain integrity hash. The static-site pullzones (www, docs, status, waitlist, cli) run Shield Advanced with CRS enabled because their request shape is regular static-HTML traffic where CRS does not false-positive. The Forgejo/api Shield posture will be re-evaluated after 90 days of false-positive telemetry on a canary subset with Shield Advanced enabled.\nHosted-runner isolation — CCI Kata + Yangtse v2 # CI jobs you push to fremforge run on T Cloud Cloud Container Instance (CCI), a serverless container runtime designed for multi-tenant workloads. Each customer\u0026rsquo;s runner pod gets two independent layers of isolation:\nCompute / kernel — Kata Containers (per-pod micro-VM). CCI runs every pod inside its own Kata-Containers lightweight VM with a dedicated Linux kernel. There is no shared kernel between two customers\u0026rsquo; runner pods, so kernel-side container-escape primitives (cgroup-escape, /proc bind-mount escape, eBPF, /sys exposure) cannot cross the tenant boundary — at worst they escape into the per-pod VM, which itself contains no other tenant\u0026rsquo;s data. This is materially stronger than the shared-kernel model that conventional Kubernetes (CCE included) uses for runner pods. See T Cloud\u0026rsquo;s documentation at docs.otc.t-systems.com/cloud-container-instance/umn/product_description/concepts.html for the platform-level isolation claim.\nDuring the T Cloud CCI v2 OBT-entitlement waitlist period, hosted runners execute on standard CCE node-pools with the hardening posture documented in DPA §A.4; the Kata-Containers micro-VM isolation claim above takes effect once the OBT entitlement unlocks on our tenant. This carve-out mirrors DPA Annex A\u0026rsquo;s runner-isolation language verbatim and is updated when the entitlement lands.\nNetwork — Yangtse v2 (per-namespace VPC ENI). Each customer\u0026rsquo;s runner namespace gets its own Yangtse v2 Network resource bound to a dedicated VPC subnet + security group. Pod traffic terminates on a per-namespace ENI in our VPC; there is no shared pod-network bridge across customers. Network isolation is therefore enforced at the VPC layer, not at an in-cluster NetworkPolicy layer that depends on the CNI agent behaving correctly. Combined with the per-pod outbound proxy and egress allowlist, lateral movement from a runner pod to anything outside the customer\u0026rsquo;s own job context is denied at both the VM and VPC layers.\nIf T Cloud\u0026rsquo;s published documentation on either layer changes in a direction that weakens the above (e.g. Kata is replaced with shared-kernel containers, or Yangtse is replaced with a shared pod-network), this page is updated within 30 days of the platform change and any active Customer is notified per DPA §14.\nInherited certifications # Through T Cloud:\nISO/IEC 27001 — information security management ISO/IEC 27017 — cloud-specific security controls ISO/IEC 27018 — protection of personal data in the cloud BSI C5 Type 2 — German federal cloud-security baseline TISAX — German automotive industry assurance GDPR-compliant processing in EU data centres fremverk\u0026rsquo;s own certification roadmap # As of the Effective Date, fremverk does not hold standalone ISO 27001, SOC 2, or BSI C5 certifications. fremverk\u0026rsquo;s security posture rests on (i) the inherited certifications of its sub-processors listed above, (ii) the technical and organisational measures in the DPA security annex, and (iii) fremverk\u0026rsquo;s information security and security-testing programme described in the DPA security annex.\nfremverk has committed to:\nCommencing ISO 27001 Stage 1 audit within 18 months of the Effective Date and achieving certification within 24 months. 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. See DPA §12.1.\nGovernment access transparency # As of the Effective Date, fremverk has received zero government-access requests for Customer Personal Data. The full report — including the partial-period statement covering pre-launch operations — is published at frem.sh/trust/transparency/. Subsequent reports cover full calendar years and publish in Q1 of the following year.\nWhere fremverk receives a binding legal demand from a government authority, court, or law-enforcement agency, fremverk:\nReviews the request for legal validity, jurisdiction, and proportionality; Challenges any request that is overbroad, lacks lawful basis, or conflicts with EU law (including GDPR Art. 48 for non-EU/EEA requests); Notifies the affected Customer within 24 hours of receipt unless legally prohibited from doing so; Provides the Customer with reasonable opportunity to seek a protective order or otherwise contest the request. See DPA §11A.\nDSA transparency report (Article 15) # fremforge is a hosting service within the meaning of Regulation (EU) 2022/2065 (Digital Services Act). The annual Art. 15 report on notice-and-action volumes, member-state authority orders, own-initiative content moderation, and Art. 20 complaint outcomes is published at frem.sh/trust/dsa/ — separate from the government-access report above. The same URL carries the six-monthly average-monthly-EU-recipients figure required by Art. 24(2).\nSchrems II — international transfers # No international transfer of Customer Personal Data occurs on any processing path. All processing (repository content, CI runs, audit logs, authentication metadata, billing records, payment-instrument data, outbound transactional email, and inbound shared-mailbox correspondence) takes place inside the EU/EEA at entities with no US parent. No Article 46 GDPR safeguard, SCC, or transfer impact assessment is required.\nEdge-PoP residency (Bunny CDN) # Every Bunny pullzone in front of frem.sh is configured to serve from EU PoPs only — no US, AU, or Asia caching. This is enforced in OpenTofu on each pullzone resource via routing { zones = [\u0026quot;EU\u0026quot;] }. The pullzone configuration lives in the source tree at:\nForgejo pullzone: fremforge/forgejo/.infrastructure/main.tf — search zones = [\u0026quot;EU\u0026quot;] API pullzone: fremforge/monolith/.infrastructure/bunny.tf — same line Static-site pullzones (www, docs, status, waitlist, cli) inherit the same routing block from the shared module at fremverk/cloudplatform/modules/static-site/main.tf:103-112. A tofu plan against any pullzone stack prints the active routing.zones value, so any drift away from [\u0026quot;EU\u0026quot;] would surface as a plan diff. Auditable evidence will become directly browsable once the source tree is hosted on the customer-facing Forgejo instance (at https://frem.sh/fremforge/...); for now, the canonical audit-chain anchor and integrity-verifier documentation is published at docs.frem.sh/security/audit-chain/.\nTLD note # frem.sh is a Saint Helena (.sh) ccTLD administered by a UK-registered registry operator. This is a DNS-level fact only. No customer data, no control-plane state, and no backups leave T Cloud EU-DE. The sovereignty guarantees (processor identity, sub-processor list, data residency) are set out in the DPA and are unaffected by DNS hosting.\nZero CLOUD Act exposure on any processing path. All Customer Personal Data is processed inside the EU/EEA by entities with no US parent. See DPA §11.3 for the full posture.\nCard-network footnote. Mollie\u0026rsquo;s PCI-DSS-attested card-processing chain involves Visa Europe Services Inc. (UK branch) and Mastercard Europe SA (Belgium) — EU operating entities whose ultimate parents (Visa Inc., Mastercard Inc.) are US-incorporated. The \u0026ldquo;no US-parented\u0026rdquo; claim applies to fremverk\u0026rsquo;s own sub-processor stack at the operating-company level; the card networks are sub-sub-processors of Mollie under PCI-DSS network rules. Customers preferring zero US-parent exposure on the payment path may pay by SEPA Direct Debit (no card-network involvement). See subprocessors — Card-network footnote.\nVerify the audit chain yourself # Every state-changing admin action on your org is recorded in a per-tenant SHA-256 hash chain, with the chain head WORM-anchored every two minutes to T Cloud OBS Object Lock storage (3-year retention, physically un-deletable within retention). You can walk the chain end-to-end without trusting fremverk\u0026rsquo;s word for it.\nWith the fremforge CLI:\n# Install (one-liner; see docs.frem.sh/get-started/cli/ for manual download + SHA-256 verify) curl -sSfL https://cli.frem.sh/cli/install.sh | sh export FREMFORGE_TOKEN=\u0026#39;\u0026lt;your PAT, audit:read scope\u0026gt;\u0026#39; fremforge audit-verify \u0026lt;your-org-slug\u0026gt; --human Or with raw curl against the same endpoint the CLI calls:\ncurl -sSf \\ -H \u0026#34;Authorization: Bearer $FREMFORGE_TOKEN\u0026#34; \\ https://frem.sh/_app/api/v1/orgs/\u0026lt;your-org-slug\u0026gt;/audit/integrity \\ | jq \u0026#39;{integrity, walked_rows, verified_count, last_verified_hash, worm_anchor}\u0026#39; A healthy response reads \u0026quot;integrity\u0026quot;: \u0026quot;ok\u0026quot; and includes a worm_anchor block whose agrees_with_db_walk: true confirms the in-database chain matches the OBS-anchored head. A break (hash_mismatch / prev_hash_mismatch) returns the offending row id and reason — designed to be auditor-readable. Full schema, exit codes, and the threat model in docs.frem.sh — audit-chain integrity.\nOperator credential custody # Bootstrap admin credentials (the domain-scoped T Cloud root AK/SK used only for first-time IAM, OBS bucket, and service-linked agency creation) are stored on the operator laptop with FileVault full-disk encryption and chmod 600 file permissions, rotated quarterly, never transmitted via chat or screen-share, and revocable in under 10 minutes via the OTC console. Routine deploys use per-component scoped deployer keys, not the root credential.\nSecurity contact # Report vulnerabilities: security@frem.sh Disclosure policy: security PGP key fingerprint: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (public key — RFC 4880 armored, RSA-4096, expires 2031-05-14). Use for encrypted vulnerability reports to security@frem.sh. The key is published only from frem.sh/.well-known/; we do not upload to public keyservers (avoids the third-party trust root). Mirror at /pgp.txt for convenience. Vulnerability disclosure # A machine-readable disclosure policy is published at frem.sh/.well-known/security.txt per RFC 9116, including safe-harbour for good-faith research, scope, and reporting channel. Third-party penetration test reports, when commissioned, are made available to Customers under NDA on written request per DPA §12.1; Enterprise-on-Demand contracts may agree to a specific testing cadence in the Order Form.\nIncident disclosure # Post-mortems for any incident affecting customer data or availability are published on this page within 14 days, per our security policy.\nSecurity patching # fremforge commits to the following maximum time-to-patch for security vulnerabilities in the platform, measured from the upstream fixed release or advisory publication, whichever is later.\nSeverity (CVSS) Maximum time to patch Critical (≥ 9.0) 48 hours High (7.0–8.9) 72 hours Medium (4.0–6.9) 7 days Low (\u0026lt; 4.0) Next scheduled maintenance window Out-of-band emergency releases are expected. The weekly maintenance window is a ceiling, not a floor. Security patches are never deferred to honour a tenant maintenance window; this is stated in the AUP and cited verbatim in the DPA security annex.\nExit and data portability # Everything is exportable — repositories, issues, pull requests, Actions logs, audit trail, SLSA attestations — via API as standard formats. There is no retention lock-in and no export fee.\nSelf-service tamper-evident export. Any tenant admin can trigger a full bundle from the admin UI at any time. The bundle is delivered as a single zip with a SHA-256 manifest covering every file in the archive (manifest.json + archive.tar.gz.sha256) so the customer can confirm the contents haven\u0026rsquo;t been tampered with after download. The bundle contains repo git bundle files, LFS manifests, Actions logs, audit slice, and SLSA attestations. GitHub and Azure DevOps do not offer an equivalent one-click self-service export; their portability paths require either Enterprise tier or support tickets. fremforge ships it on every plan, every customer, every day. The manifest is signed with our SLSA builder key (DSSE envelope, manifest.json.intoto.jsonl); customers verify with the same trust root at https://www.frem.sh/.well-known/slsa-trust-root.json published for SLSA build attestations. No Sigstore dependency. See docs.frem.sh/data-export for the bundle layout, verification recipes, and the API endpoints.\nTenant offboarding timelines and procedures are spelled out in the DPA.\nCookies and tracking # fremforge sets only strictly-necessary cookies on authenticated product surfaces, and zero cookies on marketing, docs, status, and anonymous pages. No consent banner needed: not because we hid the question, but because we don\u0026rsquo;t set cookies that would require consent.\nAuthenticated product surfaces set four first-party cookies, all strictly-necessary under ePrivacy Directive Article 5(3):\nCookie Purpose Lifetime session Forgejo session state (authenticated login; cookie name on Forgejo 15+, previously i_like_gitea) Session _csrf CSRF protection Session lang Language preference, user-triggered 1 year fremforge middleware session Per-org session binding 8h rolling Marketing, docs, and status (www.frem.sh, docs.frem.sh, status.frem.sh) are Hugo-built static sites with no cookies, no analytics, no embeds, and no tracking of any kind. Verifiable in your browser\u0026rsquo;s developer tools.\nThird-party calls from the product UI are disabled by default: no Gravatar, no federated avatars, no CDN-loaded fonts or scripts, no third-party analytics. Avatars are stored locally; fonts are served from the same origin as the forge.\nThis is a deliberate product posture, not a compliance minimum. Full cookie inventory and data-subject rights are documented in the product privacy policy.\nChanges to this page # Changes are versioned in Git and announced on the security mailing list. The date at the top of this page reflects the last meaningful content change.\nChange log # Version Date Change 1.0 2026-04-25 Initial publication. 1.1 2026-04-27 Heinlein Hosting GmbH (mailbox.org, Berlin DE) added as Annex B sub-processor for inbound shared-mailbox correspondence (M365 → mailbox.org migration; removes the last US-jurisdiction processor from the Customer Personal Data path). 1.2 2026-05-06 Visma Dinero ApS (Copenhagen DK) added as Annex B sub-processor for the fremverk-side bookkeeping integration (replaces the prior in-house ledger code path for invoicing/VAT/Bogføringsloven). 1.3 2026-05-08 DPA §10.2 dual-channel sub-processor change-notification clarified; Bunny Shield posture documented inline (Shield Basic on Forgejo + api pullzones, Shield Advanced on static-site pullzones); CCI Kata + Yangtse v2 hosted-runner isolation paragraph added with explicit CCI v2 OBT-entitlement carve-out. 1.4 2026-05-14 Brevo (FR) fully decommissioned as the outbound transactional-email sub-processor; Lettermint B.V. (Zwolle, NL — upstream OVHcloud SAS, FR + UpCloud Ltd, FI-incorporated, Amsterdam NL DC) is now the canonical Annex B row. Trust-page footer + AI-policy table updated. 1.5 2026-05-19 Visma Dinero data-categories table corrected to enumerate the fields actually flowing through the bookkeeping integration (org legal name, billing-contact email, VAT, invoice line items, Mollie payment-id; no repo content, no audit-log content, no PAN); shared-mailbox enumeration expanded to all 8 canonical addresses; AUP §3.6+§4 concurrency limit aligned to \u0026ldquo;2 jobs/seat, max 100/org\u0026rdquo; (v1.1); DPA §8.5 24/7 monitoring qualified with cross-ref to SLA §9+§10 and EDPB Guidelines 9/2022 awareness-clock framing. ","externalUrl":null,"permalink":"/trust/","section":"Trust","summary":"Effective Date: 2026-05-19 — Version: 1.5\nLast updated: 2026-05-19\nSummary # fremforge is EU-sovereign Git hosting built on upstream Forgejo and operated by fremverk ApS (Denmark). Every surface runs in the European Union. No customer data leaves EU jurisdiction.\n","title":"Trust","type":"trust"}]