[{"content":"Waarom deze pagina bestaat # Sectie 11A van de verwerkersovereenkomst (DPA) verplicht fremverk tot een jaarlijks transparantierapport waarin – geaggregeerd – elk verzoek van een overheid of opsporingsdienst om persoonsgegevens van klanten wordt gemeld dat we ontvangen. Deze pagina is dat rapport.\nHet rapport wordt voor elk volledig kalenderjaar waarin we actief zijn opnieuw uitgebracht. Zijn er in een kalenderjaar nul verzoeken, dan legt deze pagina dat feit voor dat jaar vast – “nul” niet melden zou voor de lezer niet te onderscheiden zijn van niet publiceren, en dat zou het doel van transparantie ondermijnen.\nPeriode van de rapportage # Periode Omvang 2026 (gedeeltelijk – vóór de lancering) Alleen activiteiten vóór de lancering. Tot de lancering had fremverk geen persoonsgegevens van klanten in productie in verwerking. Rapporten over volledige kalenderjaren volgen zodra het eerste daarvan is afgesloten.\nGeaggregeerde gegevens over verzoeken # Rapportageperiode: 2026 (gedeeltelijk – vóór de lancering) # Maatstaf Aantal Totaal ontvangen verzoeken van overheden om toegang 0 Verzoeken waaraan volledig is voldaan 0 Verzoeken waaraan gedeeltelijk is voldaan 0 Verzoeken afgewezen op grond van bevoegdheid of procedure 0 Verzoeken nog in behandeling aan het einde van de periode 0 Verstrekte records met persoonsgegevens van klanten 0 Klanten geïnformeerd volgens DPA §11A.1(c) 0 Landen van herkomst # Geen – er zijn geen verzoeken ontvangen.\nGevraagde gegevenscategorieën # Niet van toepassing – er zijn geen verzoeken ontvangen.\nHoe fremverk verzoeken afhandelt # Ontvangt fremverk een bindend juridisch bevel, dan volgt fremverk het proces uit DPA §11A.1:\nVerifiëren dat het bevel bindend is naar EU-recht en dat de uitvaardigende autoriteit bevoegd is ten aanzien van fremverk en de gevraagde gegevens. Beperken van de scope tot de kleinste set gegevens die het bevel toelaat. Informeren van de betrokken klant vóór verstrekking, tenzij een rechterlijk bevel dat uitdrukkelijk verbiedt – in dat geval zet fremverk zich in voor een zo kort mogelijke geheimhoudingsperiode en informeert de klant zodra het verbod vervalt. Aanvechten van bevelen die de bevoegdheid te buiten gaan, niet proportioneel zijn of verstrekking afdwingen van gegevens buiten de EU/EER. Documenteren van het verzoek, de afhandeling en de verstrekte gegevens, zodat ze in dit rapport worden opgenomen. fremverk heeft geen verzoeken van buiten de EU-jurisdictie om persoonsgegevens van klanten ontvangen, en zal daar niet vrijwillig aan voldoen. Dat geldt – zonder beperking – voor verzoeken op grond van de Amerikaanse CLOUD Act, Amerikaanse National Security Letters, dagvaardingen op grond van de Amerikaanse Foreign Intelligence Surveillance Act of vergelijkbare extraterritoriale mechanismen. De CLOUD Act heeft geen extraterritoriale werking ten aanzien van fremverk, omdat noch fremverk noch een subverwerker op het pad van persoonsgegevens van klanten een Amerikaanse moedermaatschappij heeft. Zie DPA §11 voor de volledige toezegging over dataresidentie.\nOp de hoogte blijven # Deze pagina wordt jaarlijks bijgewerkt (meestal eind januari voor het voorgaande jaar). Wil je bericht krijgen als er een nieuw rapport verschijnt, abonneer je dan op de security-mailinglijst – dezelfde lijst kondigt wijzigingen in subverwerkers aan volgens DPA §10.\nGerelateerd # Verwerkersovereenkomst § 11A – de contractuele toezegging die dit rapport invult Lijst van subverwerkers – elke partij die mogelijk toegang heeft tot persoonsgegevens van klanten, met jurisdictie Trustpagina – het algemene beeld van beveiliging en compliance Laatst bijgewerkt: 2026-05-06.\n","externalUrl":null,"permalink":"/nl/trust/transparency/","section":"Vertrouwen","summary":"Waarom deze pagina bestaat # Sectie 11A van de verwerkersovereenkomst (DPA) verplicht fremverk tot een jaarlijks transparantierapport waarin – geaggregeerd – elk verzoek van een overheid of opsporingsdienst om persoonsgegevens van klanten wordt gemeld dat we ontvangen. Deze pagina is dat rapport.\n","title":"Transparantierapport – toegang door overheden en opsporingsdiensten","type":"trust"},{"content":"Waarom deze pagina bestaat # fremforge is een hostingdienst in de zin van Verordening (EU) 2022/2065 (Digital Services Act, “DSA”). Artikel 15 van de DSA verplicht elke tussenhandeldienst om – ten minste één keer per jaar en in machineleesbare vorm – een duidelijk en begrijpelijk verslag te publiceren over de contentmoderatie die hij heeft uitgevoerd. Deze pagina is dat verslag.\nDit staat los van het transparantierapport over toegang door overheden en opsporingsdiensten, dat gaat over bindende juridische bevelen tot verstrekking van persoonsgegevens van klanten onder de DPA. Dat rapport gaat over toegang op grond van de AVG en door opsporingsdiensten; dit verslag gaat over de rapportage over contentmoderatie volgens art. 15 DSA. Beide verschijnen jaarlijks.\nFrequentie # Het verslag wordt elk jaar opnieuw uitgebracht. fremforge gaat in de loop van 2026 van start, dus het verslag over jaar 1 is een verklaring over een gedeeltelijke periode, van de lanceringsdatum tot 31 december 2026. Latere verslagen beslaan volledige kalenderjaren en verschijnen in Q1 van het jaar daarna.\nArt. 15 DSA laat uitdrukkelijk ruimte voor een verklaring over het eerste jaar in de trant van “we zijn net begonnen en hebben niets te melden”. Zwijgen is de overtreding – nul publiceren, met de uitleg die erbij hoort, is de manier om aan de verplichting te voldoen.\nVerslagperiode: 2026 (gedeeltelijk – vóór de lancering) # Op de datum hieronder is fremforge nog niet algemeen beschikbaar voor betalende klanten. Er is geen klantinhoud geweest die onder contentmoderatie viel. Alle aantallen in deze sectie zijn daarom noodzakelijkerwijs nul.\nArt. 15(1)(a) – Bevelen van autoriteiten van EU-lidstaten # Bevelen om op te treden tegen illegale inhoud (art. 9 DSA) en bevelen om informatie te verstrekken (art. 10 DSA), uitgesplitst naar de lidstaat die het bevel uitvaardigt en naar categorie van illegale inhoud. Mediane tijd tot het informeren van de uitvaardigende autoriteit en tot het uitvoeren van het bevel.\nMaatstaf Aantal Totaal ontvangen bevelen volgens art. 9 (optreden tegen inhoud) 0 Totaal ontvangen bevelen volgens art. 10 (informatie verstrekken) 0 Mediane tijd tot ontvangstbevestiging aan de uitvaardigende autoriteit n.v.t. Mediane tijd tot uitvoering van het bevel n.v.t. Uitvaardigende lidstaten # Geen – er zijn geen bevelen ontvangen.\nCategorieën van illegale inhoud # Niet van toepassing – er zijn geen bevelen ontvangen.\nArt. 15(1)(b) – Meldingen volgens art. 16 (melding en actie) # Meldingen via abuse@frem.sh en het gestructureerde formulier op https://frem.sh/_app/legal/abuse-report, uitgesplitst naar categorie van vermoedelijk illegale inhoud, genomen maatregel en mediane tijd tot actie. Het meldings- en actiemechanisme is beschreven in AUP §5.\nMaatstaf Aantal Totaal ontvangen meldingen volgens art. 16 0 Meldingen van betrouwbare flaggers (art. 22) 0 Meldingen waarop actie is ondernomen (inhoud verwijderd of beperkt, of maatregel tegen het account) 0 Afgewezen meldingen (kennelijk ongegrond of buiten de scope) 0 Mediane tijd tot besluit n.v.t. Gebruik van geautomatiseerde middelen bij de besluitvorming Geen Categorieën van vermoedelijk illegale inhoud # Geen – er zijn geen meldingen ontvangen.\nArt. 15(1)(c) – Contentmoderatie op eigen initiatief # Contentmoderatie die fremverk op eigen initiatief heeft uitgevoerd – inclusief het gebruik van geautomatiseerde tools, de kwalificaties van menselijke beoordelaars en eventuele waarborgen. fremforge past zijn Acceptable Use Policy gelijk toe op alle organisaties van klanten.\nMaatstaf Aantal Maatregelen op eigen initiatief 0 \u0026hellip;waarvan met geautomatiseerde tools (push-beschermingsscanner) 0 \u0026hellip;waarvan met menselijke beoordeling 0 Fouten van geautomatiseerde tools (fout-positieven, na bezwaar of interne beoordeling) 0 Gebruikte indicatoren voor nauwkeurigheid / foutpercentage n.v.t. Training voor menselijke beoordelaars n.v.t. – nog geen maatregelen op eigen initiatief De push-beschermingsscanner hierboven is een server-side scanner die pushes met secrets die met hoge betrouwbaarheid zijn herkend, op de laag van het Git-protocol weigert. Het is geen systeem voor contentmoderatie in de gangbare DSA-betekenis (het classificeert inhoud niet als illegaal, en de weigering is een technische afwijzing van een commit van een ontwikkelaar, geen moderatiebesluit over gehoste inhoud). Hij wordt hier alleen voor de volledigheid vermeld; als er weigeringen zijn, verschijnen de aantallen in toekomstige periodes.\nArt. 15(1)(d) – Intern systeem voor klachtenafhandeling # Met het interne systeem voor klachtenafhandeling dat art. 20 DSA voorschrijft, kunnen gebruikers en melders in beroep gaan tegen moderatiebesluiten. Het recht van beroep is beschreven in AUP §5. Klachten komen binnen op abuse@frem.sh met de onderwerpregel appeal: en worden binnen 14 dagen afgehandeld.\nMaatstaf Aantal Totaal ontvangen klachten 0 Klachten afgehandeld ten gunste van het oorspronkelijke besluit 0 Klachten afgehandeld tegen het oorspronkelijke besluit (besluit herroepen) 0 Mediane tijd tot afhandeling n.v.t. Besluiten voorgelegd aan buitengerechtelijke geschillenbeslechting volgens art. 21 0 Gemiddeld aantal maandelijkse actieve afnemers van de dienst in de EU # Volgens art. 24(2) DSA moeten tussenhandeldiensten – ten minste één keer per zes maanden – het gemiddelde aantal maandelijkse actieve afnemers van de dienst in de EU publiceren. fremforge zit onder de drempel voor aanwijzing als zeer groot onlineplatform (VLOP); dit cijfer staat hier voor de volledigheid.\nPeriode Gemiddeld aantal maandelijkse actieve afnemers in de EU 2026 (gedeeltelijk – vóór de lancering) 0 Dit aantal omvat natuurlijke personen en rechtspersonen in de EU die de dienst in de kalendermaand ten minste één keer hebben gebruikt, berekend als het rekenkundig gemiddelde over zes maanden. De methode wordt in toekomstige periodes gedocumenteerd, zodra fremforge betalende klanten en een aantal boven nul heeft om te publiceren.\nMethode en gegevensbronnen # De aantallen op deze pagina zijn afgeleid uit:\nDe tabel audit_events (zie Auditlog in de documentatie) – elke juridisch relevante handeling tegen de infrastructuur van fremforge levert een onveranderlijk, hashgekoppeld audit-event op. De aggregatiejob draait eens per kwartaal op event_type IN ('legal_takedown_received', 'legal_takedown_actioned', 'content_moderation_action', 'art16_notice_received', 'art20_complaint_received') en werkt deze pagina bij. Inkomende correspondentie in de mailboxen abuse@frem.sh en compliance@frem.sh – intern wordt een index per bericht bijgehouden om te vergelijken met de geaggregeerde audit-events. Het organisatieregister van Forgejo, dat opschortingen, beperkingen en beëindigingen bijhoudt volgens AUP §7. Het eerste verslag met aantallen boven nul (over het volledige kalenderjaar 2027) verschijnt in Q1 2028 en bevat de sectie over de methode in machineleesbare vorm, volgens de sjablonen van Uitvoeringsverordening 2024/2835 van de Europese Commissie.\nOp de hoogte blijven # Deze pagina wordt jaarlijks bijgewerkt (meestal eind januari voor het voorgaande jaar, plus een halfjaarlijkse update volgens art. 24 voor het cijfer over afnemers in de EU). Wil je bericht krijgen als er een nieuw verslag verschijnt, abonneer je dan op de security-mailinglijst – dezelfde lijst kondigt wijzigingen in subverwerkers aan volgens DPA §10 en het transparantierapport over overheidstoegang.\nGerelateerd # Acceptable Use Policy §5 (melding en actie volgens art. 16 DSA) – de contractuele basis van het meldings- en actiemechanisme dat op deze pagina wordt samengevat Transparantierapport over overheidstoegang – rapport volgens DPA §11A.2 over verzoeken van opsporingsdiensten en overheden om toegang (een aparte verplichting) Trustpagina – het algemene beeld van beveiliging en compliance Rapportagesjablonen voor art. 15 DSA (Uitvoeringsverordening 2024/2835 van de Europese Commissie) – het gestandaardiseerde rapportageformaat dat vanaf jaar 2 wordt toegepast Laatst bijgewerkt: 2026-05-07.\n","externalUrl":null,"permalink":"/nl/trust/dsa/","section":"Vertrouwen","summary":"Waarom deze pagina bestaat # fremforge is een hostingdienst in de zin van Verordening (EU) 2022/2065 (Digital Services Act, “DSA”). Artikel 15 van de DSA verplicht elke tussenhandeldienst om – ten minste één keer per jaar en in machineleesbare vorm – een duidelijk en begrijpelijk verslag te publiceren over de contentmoderatie die hij heeft uitgevoerd. Deze pagina is dat verslag.\n","title":"DSA-transparantieverslag – artikel 15","type":"trust"},{"content":"Als je SSH-client voor het eerst verbinding maakt met ssh.frem.sh:443, vraagt hij je de vingerafdruk van de hostsleutel van de server te bevestigen. (Poort 22 is op het hoofddomein niet publiek bereikbaar - ssh.frem.sh:443 is het enige gepubliceerde SSH-endpoint.) Controleer of de vingerafdruk overeenkomt met een van de waarden hieronder voordat je hem accepteert. Een vingerafdruk die hier niet staat, betekent dat je te maken hebt met een man-in-the-middle, een verouderde cache of een andere server - vertrouw hem niet.\nHuidige vingerafdrukken # Algoritme SHA-256-vingerafdruk Sleutellengte (bits) ssh-rsa SHA256:LNz5zoh9R2KZAhNGeFgKSeBMPEzbNBdd0wqwrwEkU3E 4096 Op dit moment is alleen ssh-rsa gepubliceerd. ED25519- en ECDSA-hostsleutels zijn in deze deployment niet ingeschakeld in de Forgejo-laag; als je client die vereist, dwing dan RSA af met ssh -o HostKeyAlgorithms=ssh-rsa,rsa-sha2-256,rsa-sha2-512.\nWat je doet bij de vraag # Als OpenSSH iets toont als:\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])? Vergelijk de getoonde vingerafdruk met de rij in de tabel hierboven. Komt hij overeen, typ dan yes; OpenSSH voegt de sleutel toe aan je ~/.ssh/known_hosts en vraagt voor die host nooit meer. Komt hij niet overeen, typ dan no en neem contact op via support@frem.sh voordat je het opnieuw probeert.\nDe vraag helemaal vermijden # Je kunt de hostsleutel vooraf vertrouwen door hem toe te voegen aan je known_hosts-bestand:\nssh-keyscan -t rsa -p 443 ssh.frem.sh \u0026gt;\u0026gt; ~/.ssh/known_hosts Controleer daarna de SHA-256 met:\nssh-keygen -lf \u0026lt;(ssh-keyscan -t rsa -p 443 ssh.frem.sh 2\u0026gt;/dev/null) De uitvoer moet overeenkomen met de tabel hierboven.\nAls vingerafdrukken wijzigen # We roteren de hostsleutels van Forgejo alleen als het onderliggende servercluster opnieuw wordt opgebouwd. Gebeurt dat, dan publiceren we de nieuwe vingerafdrukken hier minstens 24 uur vóór de overstap, bewaren we de vorige vingerafdrukken 90 dagen onder Vorige vingerafdrukken en plaatsen we een melding op status.frem.sh.\nWaarschuwt je client met \u0026ldquo;REMOTE HOST IDENTIFICATION HAS CHANGED\u0026rdquo; en staat de nieuwe vingerafdruk hier niet, maak known_hosts dan niet leeg - neem eerst contact met ons op.\nVorige vingerafdrukken # Geen gearchiveerd (dit is de eerste publicatie van deze pagina).\nGerelateerd # Verbinding maken met fremforge via SSH - instructies voor clonen, uitwijken naar poort 443, probleemoplossing Statuspagina - actuele beschikbaarheid + gepland onderhoud Pagina Vertrouwen - subverwerkers, auditstatus, data alleen in de EU Laatst bijgewerkt: 2026-05-06.\n","externalUrl":null,"permalink":"/nl/ssh-fingerprints/","section":"Vingerafdrukken van SSH-hostsleutels - frem.sh","summary":"Als je SSH-client voor het eerst verbinding maakt met ssh.frem.sh:443, vraagt hij je de vingerafdruk van de hostsleutel van de server te bevestigen. (Poort 22 is op het hoofddomein niet publiek bereikbaar - ssh.frem.sh:443 is het enige gepubliceerde SSH-endpoint.) Controleer of de vingerafdruk overeenkomt met een van de waarden hieronder voordat je hem accepteert. Een vingerafdruk die hier niet staat, betekent dat je te maken hebt met een man-in-the-middle, een verouderde cache of een andere server - vertrouw hem niet.\n","title":"Vingerafdrukken van SSH-hostsleutels - frem.sh","type":"ssh-fingerprints"},{"content":"Van kracht vanaf: 2026-05-24 – AI-integraties van fremforge, fase 1\nSamenvatting in één regel # fremforge laat klantcode op het standaardpad nooit door een Amerikaanse AI-leverancier subverwerken. De klant brengt een eigen sleutel van een AI-leverancier mee (BYOK) en kiest zelf de leverancier. Die leverancier is de eigen verwerker van de klant, onder het eigen contract van de klant, en geen subverwerker van fremverk onder de verwerkersovereenkomst.\nDit is vastgelegd in DPA bijlage B §B.8.\nWat onder “AI-integraties” valt # fremforge heeft vier server-side AI-functies die de AI-leverancier gebruiken die de klant heeft ingesteld. Elk ervan staat uit tot de klant een sleutel van een leverancier toevoegt:\nAI-review van PR’s – als een pull request wordt geopend of bijgewerkt, stuurt fremforge de diff + PR-metadata naar de ingestelde leverancier en plaatst een gestructureerd reviewcommentaar met een commitstatus pending → success / warning. Uitleg bij dependency-updates van Renovate – PR’s van Renovate krijgen een gerichtere prompt, toegespitst op het verhelpen van CVE’s en het risico op breaking changes. Gateway die de klant zelf aanroept – POST /api/v1/orgs/\u0026lt;slug\u0026gt;/ai/complete met een PAT met de scope ai:invoke. De eigen workflows en scripts van klanten roepen dit endpoint aan, in plaats van SDK’s van leveranciers in te bouwen. AI-fix voor SAST-bevindingen – staat standaard uit, ook als er een sleutel is ingesteld; een eigenaar van de organisatie zet het aan. Klikt iemand op AI fix bij een bevinding van een van een korte lijst SAST-regels, dan stuurt fremforge de beschrijving van de regel en maximaal 60 regels van het betreffende bestand naar de ingestelde leverancier, controleert de teruggegeven diff en scant die opnieuw, en opent een pull request die nooit automatisch wordt gemerged. De prompt, de code en de diff worden niet door fremforge opgeslagen. Zie AutoFix. Daarnaast is er een apart pad voor AI-tools aan de kant van de ontwikkelaar (Claude Code, Cursor, Continue, JetBrains AI die via de gewone REST-API + PAT met fremforge praten). Dat pad loopt niet via de infrastructuur van fremverk naar een AI-leverancier; zie docs.frem.sh/get-started/ai-in-your-ide/.\nOndersteunde leveranciers (fase 1, BYOK) # fremforge ondersteunt drie soorten adapters, die samen elke grote leverancier van dit moment dekken:\nAdapter Voorbeelden van leveranciers openai-compatible OpenAI, Azure OpenAI, Mistral, Together, Fireworks, OpenRouter, T-Cloud AIFS, elke eigen OpenAI-compatibele URL anthropic De eigen API van Anthropic vertex-gemini Google Vertex Gemini De klant plakt een API-sleutel van de leverancier in de beheer-UI op /\u0026lt;org\u0026gt;/_admin/ai-integrations. De sleutel wordt in rust versleuteld met AES-256-GCM via T Cloud Public DEW KMS, met een AAD-binding per rij (zodat een sleutel die uit een databaseback-up is gehaald niet kan worden ontsleuteld zonder ook de bijbehorende rij-id te bemachtigen).\nHet datapad # Voor elke AI-aanroep (PR-review, uitleg bij Renovate, of /ai/complete vanuit een workflow):\nHet verzoek komt uit de repository van de klant, een webhook-payload of een workflowstap. De api-pod van fremforge stelt de prompt samen: difftekst + PR-metadata + systeemprompt + door de klant aangeleverde berichten. De api-pod van fremforge stuurt een HTTPS-verzoek naar de URL van de door de klant ingestelde leverancier, met de door de klant ingestelde sleutel. Het antwoord van de leverancier wordt vastgelegd: aantallen tokens, latentie, modelnaam, antwoordtekst. fremforge plaatst een Forgejo-commentaar (PR-review) OF geeft het antwoord terug aan de workflow (/ai/complete). Een rij in ai_usage_events registreert de aanroep: tenant, aanbieder, model, tokens in, tokens uit, latentie. De prompt en de inhoud van het antwoord worden niet bewaard na afloop van het verzoek. De prompt + het antwoord gaan één keer door de api-pod van fremforge. Ze gaan niet door een logaggregator, observability-dienst of back-up van derden. De audit per aanroep legt de metadata vast (welke functie, welke aanbieder, aantallen tokens), maar niet de inhoud.\nWaarom “geen subverwerker” # Volgens artikel 28 AVG is iemand subverwerker als de verantwoordelijke hem aanstelt, een contract met hem sluit en hem opdraagt de gegevens namens de verantwoordelijke te verwerken. Niets daarvan is hier van toepassing:\nDe klant kiest de AI-leverancier. fremverk stelt er geen aan en beveelt er geen aan. De keuzelijst in de beheer-UI toont soorten adapters, geen aanbevelingen. De klant sluit zelf een contract met de AI-leverancier. fremverk heeft hiervoor geen commerciële relatie met de AI-leverancier. De klant betaalt de leverancier; fremverk zet geen marge op de tokenkosten van de leverancier. De klant kan de AI-leverancier op elk moment verwijderen, zonder fremverk in te lichten. Zo werkt een relatie met een subverwerker van fremverk niet. De eigen toezegging van fremverk in DPA §11.3 – geen subverwerkers met een Amerikaanse moedermaatschappij – blijft ongewijzigd. Een klant die kiest voor een in de VS opgerichte AI-leverancier (OpenAI, Anthropic, Google Vertex) stelt zichzelf bloot aan de jurisdictie van die leverancier – niet aan die van fremverk. Dit is dezelfde juridische positie als bij identiteitsproviders die de klant kiest (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik) en die via OIDC aan fremforge worden gekoppeld. Om dezelfde reden staan ze in de toelichting bovenaan bijlage B.\nHet “turnkey”-traject van fase 2 # Zodra AIFS (T-Cloud AI Foundation Services) een op code afgestemd model levert dat goed genoeg is voor PR-review – naar verwachting over 6–18 maanden – wil fremverk een turnkey AI-abonnement aanbieden, waarbij fremverk een AIFS-account in Duitsland aanhoudt en tokens per plaats factureert. Die optie zou een nieuwe subverwerker van fremverk betekenen en zou aan het register in bijlage B worden toegevoegd, met inachtneming van de kennisgeving van 30 dagen volgens §10.2.\nHet BYOK-pad blijft beschikbaar, ook als turnkey er is – klanten kunnen altijd hun eigen sleutel van een leverancier meebrengen.\nZichtbaarheid in de audit # Elke AI-aanroep levert een audit-event op:\ntenant.ai_integration.provider_added / _disabled / _tested – wijzigingen in de configuratie van aanbieders tenant.ai_integration.feature_default_changed – welke aanbieder welke functie afhandelt tenant.ai_integration.repo_override_changed / _removed – uitzonderingen per repository ai.complete.ok / ai.complete.failed – elk /ai/complete-verzoek van de klant Klanten zien in de beheer-UI de tokenkosten per maand en de 👍/👎-tevredenheidsscores per (aanbieder, model); beide zijn gebaseerd op de onderliggende tabellen ai_usage_events en ai_review_comments. De auditlogs van klanten (DPA §9, bewaartermijn 13 maanden) bevatten alle tenant.ai_integration.*-events.\nZacht falen # AI-functies blokkeren nooit een PR. Geeft de ingestelde leverancier een fout, loopt hij tegen een rate limit aan, wordt het bestedingsplafond van de klant overschreden of is de sleutel ongeldig, dan wordt het reviewcommentaar overgeslagen en verschijnt er een commitstatus warning (“AI review unavailable: retry on next push or fix the key”). De CI van de klant merkt er niets van; alleen het door AI gegenereerde commentaar ontbreekt.\nVragen en auditverzoeken # Voor compliance-reviewers: deze pagina is het trustdocument waar je direct naar kunt linken. De contractuele basis is DPA bijlage B §B.8. Vragen kun je sturen naar compliance@frem.sh.\n","externalUrl":null,"permalink":"/nl/trust/ai-integrations/","section":"Vertrouwen","summary":"Van kracht vanaf: 2026-05-24 – AI-integraties van fremforge, fase 1\nSamenvatting in één regel # fremforge laat klantcode op het standaardpad nooit door een Amerikaanse AI-leverancier subverwerken. De klant brengt een eigen sleutel van een AI-leverancier mee (BYOK) en kiest zelf de leverancier. Die leverancier is de eigen verwerker van de klant, onder het eigen contract van de klant, en geen subverwerker van fremverk onder de verwerkersovereenkomst.\n","title":"AI-integraties – datapad en soevereiniteit","type":"trust"},{"content":"Ingangsdatum: 2026-04-25 - Versie: 1.1\nLaatst bijgewerkt: 2026-04-25\nEen kwetsbaarheid melden # Mail security@frem.sh. Versleutelde mail is welkom; de vingerafdruk van de PGP-sleutel staat op de pagina Vertrouwen.\nWe bevestigen meldingen binnen 48 werkuren (zie de safe-harbourbepaling hieronder voor de formele toezegging). Kritieke problemen in fremforge zelf worden zo nodig gepatcht voordat upstream Forgejo dat doet; bugs in upstream worden afgestemd met het beveiligingsteam van Forgejo volgens hun disclosurebeleid. De gepubliceerde patchtermijnen per ernst staan op de pagina Vertrouwen.\nKwetsbaarheden openbaar maken # Meld kwetsbaarheden aan security@frem.sh.\nEen machineleesbaar disclosurebeleid staat op frem.sh/.well-known/security.txt volgens RFC 9116, met scope, contact, voorkeurstalen en de termijn voor bevestiging.\nSafe harbour: onderzoek te goeder trouw binnen de gepubliceerde scope valt onder safe harbour. fremverk onderneemt geen juridische stappen tegen onderzoekers die het disclosurebeleid volgen. We zeggen toe dat we meldingen van kwetsbaarheden binnen 48 werkuren bevestigen en dat we gecoördineerd openbaar maken volgens een tijdlijn waarover we samen afspraken maken.\nDe vingerafdruk van de PGP-sleutel voor security@frem.sh staat op frem.sh/trust#security-contact.\nScope # frem.sh - Forgejo-UI, Git-protocol, API, pakketregister www.frem.sh, docs.frem.sh, status.frem.sh de productieomgeving van fremforge op T Cloud Public E-mail en transactionele berichten die vanaf @frem.sh worden verstuurd Buiten scope # Integraties van derden die je zelf aan fremforge koppelt (meld die bij de leverancier) Bevindingen die voor reproductie een vooraf geauthenticeerde, bevoorrechte gebruikerssessie vereisen die verder gaat dan de toegang die de gebruiker al heeft Wat we publiceren # Beveiligingsadviezen worden geplaatst op de pagina Vertrouwen en gemaild naar de beveiligingsmailinglijst. Post-mortems van elk incident dat gevolgen had voor klantdata of beschikbaarheid, publiceren we binnen 14 dagen.\nWijzigingslog # Versie Datum Wijziging 1.0 2026-04-25 Eerste publicatie. 1.1 2026-10-04 Scope: de productieomgeving in de cloud wordt beschreven in plaats van bij haar interne projectnaam genoemd. Geen wijziging in de scope. ","externalUrl":null,"permalink":"/nl/security/","section":"Beveiliging","summary":"Ingangsdatum: 2026-04-25 - Versie: 1.1\nLaatst bijgewerkt: 2026-04-25\nEen kwetsbaarheid melden # Mail security@frem.sh. Versleutelde mail is welkom; de vingerafdruk van de PGP-sleutel staat op de pagina Vertrouwen.\n","title":"Beveiliging","type":"security"},{"content":" 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 (the audit-emit service) 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 Public 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 Public 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\u0026rsquo;s canonical cloud-architecture baseline). 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 Public) 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 Public account-takeover at root-AK level; mitigated by fremverk\u0026rsquo;s platform bootstrap runbook, §1.2 Bootstrap-creds convention (root AK on operator laptop, mode 600, never echoed to chat or logs, rotated quarterly via OTC console).\n4.5 Sub-processor (T Cloud Public) law-enforcement disclosure — net 4 # T Cloud Public 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 the audit-emit service.\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 (its scheduled-jobs manifest) 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 the audit-emit service. 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 Public 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; the admin auth-policy route). §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":" Summary # This Data Protection Impact Assessment (“DPIA”) covers fremverk’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.\n","title":"DPIA - Audit Monitoring","type":"legal"},{"content":"","externalUrl":null,"permalink":"/nl/","section":"fremforge - Europees alternatief voor GitHub, met CI/CD","summary":"","title":"fremforge - Europees alternatief voor GitHub, met CI/CD","type":"page"},{"content":" Last updated: 2026-10-23\nEffective Date: 2026-09-30 — Version: 1.12 (effective 2026-11-17; until then version 1.10 applies from 2026-11-03, and version 1.8 before that; full revision history in §Change log)\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. The dependency proxy is the one exception: it is a proxy the Service provides, and §4A governs its use. 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 guaranteed, at least 10 and at most 60 per organisation on the standard plan, with use of idle platform capacity up to 60; 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, or using fremforge-hosted runners as a relay for package downloads). Package downloads by fremforge-hosted runners do not count toward the package egress caps published at frem.sh/pricing because they serve CI: the software development, build, test and deployment of the Customer\u0026rsquo;s own projects. A job whose purpose is to download packages for use outside that job, for example to hand them on to people, systems or networks that would otherwise download them directly, is not CI use, and those downloads may be counted toward the caps in addition to the enforcement actions in §7. 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 guaranteed, 60 concurrent jobs/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.\n3.8 AI Act Article 5 prohibited practices # Article 5 of Regulation (EU) 2024/1689 (the AI Act) has prohibited the following since 2 February 2025. They are prohibited on fremforge, and this subsection specifies — it does not extend — the general prohibition on unlawful use in §2:\nSocial scoring — evaluating or classifying people based on social behaviour or personal characteristics in a way that leads to detrimental or unfavourable treatment in unrelated contexts, or that is unjustified or disproportionate. Untargeted scraping for facial recognition — building or expanding facial-recognition databases by untargeted scraping of facial images from the internet or CCTV footage. Prohibited real-time remote biometric identification — real-time remote biometric identification in publicly accessible spaces, other than in the narrow cases Article 5 permits. Emotion inference in work and education — inferring emotions of natural persons in the workplace or in education, other than for medical or safety reasons. Biometric categorisation to infer protected attributes — inferring race, political opinions, trade-union membership, religious or philosophical beliefs, sex life or sexual orientation from biometric data. Exploitation of vulnerabilities — exploiting the vulnerabilities of a person or group by reason of age, disability, or a specific social or economic situation, so as to materially distort behaviour in a way that causes or is likely to cause significant harm. Manipulative or subliminal techniques — deploying subliminal, purposefully manipulative, or deceptive techniques that materially distort behaviour and cause or are likely to cause significant harm. Predictive policing on profiling alone — assessing or predicting the risk that a natural person will commit a criminal offence, based solely on profiling or on assessing personality traits and characteristics. Prohibited high-risk use without compliance — deploying AI outputs in a high-risk AI-system context (AI Act Annex III) without meeting the deployer obligations the law places on you. This applies to any use of fremforge in furtherance of such a practice, including where fremforge\u0026rsquo;s own AI features or a Customer-configured AI vendor (§3.7, DPA Annex B §B.8) form part of it. Because fremforge AI features are bring-your-own-key, the Customer\u0026rsquo;s own contract with its AI vendor also binds the Customer; that is a mitigation and not a substitute, since this AUP is the instrument fremverk can enforce.\nfremverk does not inspect Customer Content, so — as with the rest of §3 — these prohibitions are enforced contractually and on report rather than by pre-filtering. Enforcement follows §7.\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. Each job\u0026rsquo;s runtime is rounded up to the next whole minute, for both the included minutes and overage: a job that runs 61 seconds counts as 2 minutes. 2 concurrent jobs per seat, guaranteed, with at least 10 and at most 60 per organisation; trial organisations 2. Above its guaranteed share, an organisation may use idle platform capacity up to 60 concurrent jobs, as long as enough capacity stays free for other organisations\u0026rsquo; guaranteed jobs. That burst capacity is best-effort: it is available when the platform is not busy and is not a guaranteed allowance. The ceiling of 60 is a hard platform limit. 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 hosted-runner capacity under the Enterprise-on-Demand arrangement. Do not work around the thresholds; contact us.\n4A. Dependency proxy fair use # The dependency proxy fetches container images and packages from the upstream registries fremforge supports, caches them for the Customer\u0026rsquo;s organisation, and serves them to that organisation\u0026rsquo;s authenticated Users. Using it for that purpose is permitted. The following apply:\nYour organisation\u0026rsquo;s own use. The proxy serves your organisation\u0026rsquo;s own software development, build, test and deployment. Do not use it to run a public or third-party mirror, to redistribute content to anyone outside your organisation, or to get around an upstream registry\u0026rsquo;s access controls or rate limits on behalf of others. Your rights in the content. You are responsible for holding the rights and licences for what you fetch through the proxy, and for complying with the terms of each upstream registry you use. Where an upstream requires your own account (for example Docker Hub), the fetch is made with the credential you store for that account, and that registry\u0026rsquo;s terms for your account apply. Limits. fremforge applies technical limits to protect the shared Service, including per-organisation limits on upstream fetches and on object size. On a trial, cached content is limited to 5 GB. On a paid plan, cached content counts toward the package storage published at frem.sh/pricing. fremverk\u0026rsquo;s rights. fremverk may rate-limit the proxy for an organisation, remove cached content (for example on a takedown request, or when an upstream withdraws an artifact), and, as set out in §7, switch the proxy off for an organisation that uses it in breach of this section. 5. 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, and the deleted data expires from encrypted backups within up to 90 days thereafter (per DPA §9 and the staged sequence in the next paragraph) — total time from suspension to backup expiry is up to 180 days. This sequence harmonises with terms.md §16.5 (90-day post-termination 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 expiry — 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 expiry within up to a further 90 days. Total: up to 180 days (60 + 30 + 90).\nTermination after suspension: (a) 60-day suspension hold (above), then on termination (b) post-termination export window of 90 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 expiry within up to a further 90 days. The windows in DPA §9 measure from the end of (b); they do not run concurrently. Total: up to 270 days (60 + 90 + 30 + 90).\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: an agent has no audit identity of its own. Its actions, whether under a delegated mandate (OAuth 2.0 token exchange, RFC 8693) or through an MCP connector the user authorised, are recorded with the authorising user as the actor, and with the agent in the entry\u0026rsquo;s agent field and the token it used in via_token. You and fremverk can therefore distinguish them from the user\u0026rsquo;s own actions for compliance and incident review, and every one of them is attributed to the user it was taken for. Entries written before 2026-10-23 keep the form they were written in, with the agent as the actor (oidc:agent:\u0026lt;agent_id\u0026gt;) and the user in on_behalf_of. 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.12 2026-10-23 Effective 2026-11-17. Widening only. §12 — the person is the actor of every action an agent takes for them. §12 said agent actions are recorded with actor=agent:\u0026lt;agent_id\u0026gt;, on_behalf_of=\u0026lt;user_id\u0026gt;. From 2026-10-23 there are no agent identities in the audit log: an action an agent takes under a delegated mandate (token exchange) or through an MCP connector is recorded with the authorising user as the actor, the agent in the entry\u0026rsquo;s agent field and the token in via_token. Agent actions stay distinguishable from the user\u0026rsquo;s own, and entries written before 2026-10-23 are not rewritten (the hash chain covers them) and keep the earlier form. Not materially adverse: nothing that was recorded stops being recorded, no Customer obligation or restriction is added, and the user an action was taken for is now its actor. Queued behind 1.11 (2026-11-17), whose text it contains; no notice. 1.11 2026-10-18 Effective 2026-11-17. Materially adverse. Announced by notice f964f16e-e3b2-424b-b7af-441cca9ced41 on 2026-10-18 (as aup 1.11). §3.3 — hosted runners are not a relay for package downloads. Package-registry downloads by fremforge-hosted runners are counted apart and do not count toward the package egress caps published at frem.sh/pricing, while downloads by self-hosted runners and every other client still do. §3.3 already prohibited circumventing egress caps by design; it now names the one new way to do so, using hosted runners to download packages for use outside the job, and states that such downloads may be counted toward the caps. Adverse under ToS §17 because it adds a restriction on how hosted runners may be used, so it takes effect 30 days after notice. 1.10 2026-10-07 Effective 2026-11-03. Widening only. §3.3 and new §4A — the dependency proxy is permitted. §3.3 prohibited using fremforge \u0026ldquo;as a proxy\u0026rdquo;, which on its words covered the dependency proxy the Service now provides. §3.3 now names the dependency proxy as the one exception, and new §4A sets its fair-use terms: the organisation\u0026rsquo;s own use only (no public or third-party mirror), the Customer is responsible for its rights in the content and for each upstream registry\u0026rsquo;s terms, published technical limits (on a trial at most 5 GB of cached content; on a paid plan cached content counts toward the package storage at frem.sh/pricing), and fremverk may rate-limit, remove cached content, or switch the proxy off for an organisation in breach. Every term in §4A applies only to a use §3.3 prohibited until now, so nothing a Customer could do under 1.9 is restricted, and it is not materially adverse under ToS §17. Queued for 2026-11-03 behind 1.9, whose text it contains. 1.4 2026-08-04 Corrected the hosted-runner platform: runners are ephemeral T Cloud Public Elastic Cloud Server virtual machines, one per job, not Cloud Container Instance containers. The CCI model was pre-launch intent and never shipped; cce-node-image was archived 2026-06-24. DPA Annex A.5 was corrected on 2026-08-04 but this document was not, because the regression guard added at the time checked only the DPA. No control is weakened — per-job VMs give strictly stronger isolation than shared-kernel containers, so the substance (no shared kernel between tenant jobs) is unchanged and now accurately described. Not materially adverse under the Terms §1.2 test. 1.5 2026-08-05 §3.6 and §4: the organisation concurrency figure was 100 and the platform enforces 30. The runner-controller caps a tenant at RUNNER_PER_TENANT_CONCURRENCY_CAP: 30 against an 80-VM fleet ceiling, so any standard-plan organisation with 15 or more seats was told it could run up to 100 concurrent jobs and would have been refused at 30. Corrected to 30 in both clauses, and the \u0026ldquo;soft limit\u0026rdquo; framing removed from §4: the per-seat figure is an allowance, and the organisation ceiling binds first as a hard platform limit. Not adverse, and the reason is specific rather than a general assertion: §3.6 cites frem.sh/pricing as the authoritative published figure, and that page already said \u0026ldquo;Concurrent jobs: up to 30 per org (fair use; higher on request)\u0026rdquo; — verified live on 2026-08-05. So 30 is the number a Customer priced against, and this AUP was the sole outlier. AUP 1.1\u0026rsquo;s change-log row claimed the 100 figure was introduced to align with /pricing and /product; that alignment was either never true or silently diverged afterwards. Enterprise-on-Demand customers may still negotiate a higher cap, unchanged. Found by auditing the AUP\u0026rsquo;s quantified claims against the enforced configuration. 1.6 2026-09-30 §3.6, §4 and the public-repository fair-use clause: concurrency is now 2 jobs per seat guaranteed, at least 10 and at most 60 per organisation, plus best-effort use of idle capacity up to 60. It was 2 per seat capped at 30. The runner platform now enforces the per-seat figure: before, it applied a flat 30 to every organisation, and it did not enforce the trial limit of 2 that /pricing publishes. Not materially adverse under the Terms §1.2 test: every organisation\u0026rsquo;s guaranteed share is at least what version 1.5 published. The floor of 10 covers every organisation of 5 seats or fewer, the per-seat figure is unchanged, and the organisation ceiling rises from 30 to 60. The burst allowance is additional. Trials stay at 2, as published. Enterprise-on-Demand customers may still negotiate a higher cap, unchanged. 1.7 2026-10-03 §11 — the termination path now uses the 90-day post-termination export window of Terms 1.11 §16.5 (was 60), so the termination-after-suspension total is up to 210 days (was 180). The 60-day suspension hold for non-payment, its 120-day total and the §7 organisation-suspension retention are unchanged. Not materially adverse under ToS §17; effective on publication. 1.8 2026-10-03 §4 — runner minutes are counted per job, rounded up to the next whole minute, for both the included minutes and overage. A 61-second job counts as 2 minutes; a job that never starts, or runs for no time, is not counted. Until this version runtime was metered to the second. Every job boots its own virtual machine and most jobs finish in under a minute, so per-second metering priced short jobs below what they cost to run; whole-minute rounding per job is also how GitHub Actions counts. Materially adverse under ToS §17, by effect: the same work consumes the included minutes faster and can produce more overage. It nevertheless takes effect on publication, without the 30-day notice period of §13, by operator decision of 2026-10-03, because it has no practical effect on any paying Customer: the Service has one paying Customer, whose subscription ends on 2026-10-22 and which has used no runner minutes in the current period. Every other organisation on the plan is a test organisation. 1.9 2026-10-04 Effective 2026-11-03. Materially adverse. Announced by notice 999f05a2-d9ea-4be3-a423-59fd1e9354b0 on 2026-10-04 (as aup 1.9). The 2026-10-04 notice announced this change as aup 1.9, and it is published as 1.9. §11: deleted data expires from encrypted backups within up to 90 days of primary deletion (was \u0026ldquo;backup purge within 30 days\u0026rdquo;). Suspension without termination: total up to 180 days (was 120); termination after suspension: up to 270 days (was 210). Suspension hold and export windows unchanged. No infrastructure change: this describes the backup lifecycle and the rota that operate. 1.0 2026-04-25 Initial publication. 1.3 2026-08-04 §3.8 added — AI Act Article 5 prohibited practices. Enumerates the practices prohibited by Art. 5 of Reg. (EU) 2024/1689 since 2 February 2025 (social scoring; untargeted facial-image scraping; prohibited real-time remote biometric identification; emotion inference in work and education; biometric categorisation to infer protected attributes; exploitation of vulnerabilities; manipulative or subliminal techniques; predictive policing on profiling alone; prohibited Annex III high-risk deployment). Ports the equivalent clause from the fremai AUP §3 so both products carry the same list, and closes the gap recorded in fremverk\u0026rsquo;s internal EU AI Act conformity record §5.2 — fremforge\u0026rsquo;s AUP had contained no Art. 5 language at all. Not materially adverse within the meaning of §13, applying the same test as ToS 1.2: Art. 5 is directly applicable EU law that already binds the Customer irrespective of this AUP, and §2 (Lawful use) already prohibited unlawful use and was already enforceable under §7. §3.8 therefore specifies an existing prohibition rather than creating a new one or removing a right — the same shape as the ToS §7.3 correction, which restated an existing fact. It accordingly takes effect on publication and no 30-day notice period is required. Also corrects the header line, which had read \u0026ldquo;Version: 1.1\u0026rdquo; since the 1.2 release while the frontmatter said 1.2 — the version is now stated consistently in both places, and 1.2 remains without a change-log row because that release predates the lift into this repo. 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":" Last updated: 2026-10-23\n","title":"fremforge Acceptable Use Policy","type":"legal"},{"content":" Last updated: 2026-08-11\nCurrent Version: 1.3 (2026-08-11) — Published at www.frem.sh/legal/accessibility-statement/.\nThis statement applies to the fremforge service operated by fremverk ApS at frem.sh, www.frem.sh and docs.frem.sh. Controller identification is in legal-meta.md.\n1. Commitment # fremverk ApS is committed to making the fremforge service accessible, in accordance with EN 301 549 (the European standard for ICT accessibility, which incorporates WCAG 2.1 level AA by reference at clause 9), Directive (EU) 2019/882 (the European Accessibility Act) and its national transpositions, and — for the Norwegian market — the forskrift om universell utforming av IKT-løsninger made under the likestillings- og diskrimineringsloven.\nThis statement is written to the structure of the model statement in Commission Implementing Decision (EU) 2018/1523, because that is the form public-sector customers ask suppliers to provide during procurement.\n2. Compliance status # Partially compliant with EN 301 549 / WCAG 2.1 AA, because of the non-conformances listed in §3.\nThis is a self-assessment. No third-party audit has been carried out. A conformance claim supported only by self-assessment is weaker evidence than an independent audit report, and public-sector procurement may require the latter — see §6.\n3. Non-accessible content # 3.1 Non-conformances with EN 301 549 # # What Criterion Where Status 1 Some page content on the code-hosting surface sits outside any landmark region. WCAG 1.3.1 (best-practice level) frem.sh/explore/*, frem.sh/user/* Open. Upstream Forgejo markup — see §3.3. 2 The \u0026ldquo;remember me\u0026rdquo; checkbox on the sign-in form, and the same third-party checkbox pattern elsewhere in the code-hosting UI, ship with a label that is neither associated with the control nor wrapping it. WCAG 1.3.1, 4.1.2 frem.sh/user/login and other code-hosting forms Mitigated at our layer. fremverk repairs the association for every affected checkbox and radio in the interface, verified against the live sign-in page. Two limits stated plainly: the repair requires client-side scripting, so a user with scripting unavailable gets the unrepaired control; and it applies after the page is first rendered rather than shipping correct. fremverk has decided not to pursue a change in the third-party component and treats this mitigation as the control. Reviewed at each upgrade of that component. Resolved 2026-08-11 (recorded rather than deleted, because a reader assessing this statement should be able to see what moved, and in what order it was found):\nContrast — five defects in the design tokens, all measured:\nPrimary buttons failed WCAG 1.4.3 in dark mode on the administration console (4.26:1) and in both modes on the code-hosting surface (4.26:1). The brand green could not carry an accessible label in either direction; the interactive colour ramp now inverts by mode. Inline links on the code-hosting surface failed 1.4.3 in light mode (4.04:1 on the page background). The dark mode of the same token had been fixed earlier and measured; the light mode had not. Input placeholder text failed 1.4.3 (4.00:1 / 3.79:1). Text-input, select and textarea borders failed WCAG 1.4.11 (Non-text Contrast) at 1.43:1 (light) and 2.47:1 (dark), so form fields had no perceivable boundary. A danger-variant keyboard focus indicator failed 1.4.11 in dark mode (2.96:1). Structure and behaviour — found by the automated gates once they existed:\nInteractive controls in the shared interface announced behaviour they did not have. The account and organisation popovers and the appearance selector were described to assistive technology as menus — a description that promises arrow-key navigation and dismissal with Escape. Neither existed: the interface contained no arrow-key handling at all, so a user who was told \u0026ldquo;menu\u0026rdquo; and navigated accordingly found the keys inert, and Escape did not close the popover. WCAG 2.1.1 and 4.1.2. The behaviour is now implemented and asserted on every change, including returning focus to the control that opened a popover when it closes.\nWorth stating because it shapes what this statement can be relied on for: automated rule-checking had passed all of these. Rule-checkers verify that a description is present and structurally legal, not that the behaviour it promises exists — so this class of defect is invisible to them by construction, and finding it required driving a real browser with real key presses.\nLandmarks on every administration and operator page. The shell\u0026rsquo;s own role=\u0026quot;banner\u0026quot; top bar, sidebar navigation and footer were nested inside the page\u0026rsquo;s \u0026lt;main\u0026gt; landmark, so \u0026ldquo;jump to main content\u0026rdquo; skipped nothing and landmark navigation was materially degraded. WCAG 1.3.1. The content column is now the single \u0026lt;main\u0026gt;, and the skip-link target moved with it.\nTwo \u0026lt;main\u0026gt; landmarks on the welcome and onboarding pages — the pages a brand-new customer sees first — because the page supplied its own \u0026lt;main\u0026gt; inside the one the shared layout already emits. WCAG 1.3.1.\nAn uncontrollable timed redirect on the two-factor-enrolment gate, implemented as \u0026lt;meta http-equiv=\u0026quot;refresh\u0026quot;\u0026gt; with a few seconds\u0026rsquo; delay. This is a Level A failure of WCAG 2.2.1 (Timing Adjustable) with no applicable exception: the user could not turn it off, adjust it or extend it, and for a screen-reader or cognitive-load user it navigated the page away mid-sentence. Removed, along with the mechanism that produced it, so it cannot be reintroduced by a future caller. The page\u0026rsquo;s prominent action button was, and remains, the working affordance.\nNine transient error messages that were never announced. Error banners are shown in response to an action; 13 of 39 rendered without a live region, so a screen-reader user received no notification that anything had gone wrong. WCAG 3.3.1 / 4.1.3. Nine now announce assertively. Three were deliberately left silent and are documented as such: two describe standing account state rather than an event, and one is a styled container around a table — making those assertive would interrupt the user on every page load, which is a regression rather than a fix.\n3.2 Content not yet assessed # What follows is the limit of what has been assessed. Entries are listed because an unassessed area is not the same as a conformant one, and a statement that omitted them would overstate what is known. Two entries describe partial coverage rather than none, and say exactly where that coverage stops:\nKeyboard operability — assessed for the shared interface, with a narrower remaining gap. An automated gate drives real key sequences in a browser engine on every change. Covered: the command palette (opens on its advertised shortcut, places focus in its input, Escape closes it without trapping focus, arrow keys stay inside the dialog); the account and organisation popovers (open from the keyboard, arrow keys move between their items, Home and End jump to the ends, Escape closes and returns focus to the control that opened it); the appearance selector (arrow keys move between options and wrap); and the page framework (the skip link is the first stop and reveals itself when focused, and Tab reaches page content past the whole navigation chrome).\nStill not covered: keyboard behaviour on individual administration pages, rather than the shared interface they sit in. The setup-progress control that previously appeared here is resolved — it no longer describes itself as a set of tabs, and it is now exercised by the automated checks (see the change log).\nAssistive-technology testing — NOT performed. No testing with NVDA, JAWS or VoiceOver has been carried out, and nothing described in this statement has been heard by a person using a screen reader. This remains the most significant gap here, and it is why an external audit is being commissioned.\nTwo automated checks exist nearby and neither is a substitute. Both are described because a reader is entitled to know exactly how far the automation goes:\nSince 2026-08-11 a check confirms that error and status messages reach the accessibility tree as live regions carrying their text — not hidden, not stripped by a container, not left unnamed. That is a structural property computed by the browser. Also since 2026-08-11, a screen-reader simulator reads each page and produces the sequence of phrases a screen reader would say. It checks that an error is announced as an error rather than as ordinary prose, that it is announced before the form controls it refers to, that decorative marks stay silent, and that nothing is said twice in a row. What the second one is worth, stated plainly: it implements the specification for how a page should be announced. Real screen readers each depart from that specification in their own ways, and those departures are where announcement usually fails in practice — including how assertive and polite messages actually interrupt, and anything to do with braille or verbosity settings. During development the simulator reported a repeated phrase that a real screen reader would not produce, which is a concrete example of the divergence rather than a hypothetical one.\nSo read these as \u0026ldquo;the page is built to announce correctly\u0026rdquo;, never as \u0026ldquo;users hear it correctly\u0026rdquo;. Only testing with real assistive technology, and with people who use it, settles the second — and that has not been done.\nPopulated page states. Automated checks cover 39 view components, but render them from default props — that is each page\u0026rsquo;s empty, initial or error state. A page showing real data (long tables, deep nesting, many controls) is not yet swept.\nThe bulk of the code-hosting interface. Automated checks reach it only through the pages a signed-out visitor can load. Everything behind sign-in — repositories, issues, pull requests, code review, settings — is unassessed and is the subject of §3.3.\nNon-web documents (PDF exports, generated reports).\nNo longer in this list — \u0026lt;html lang\u0026gt; was hard-coded to en, which would have become a WCAG 3.1.1 failure the moment a second interface language shipped. The document language now follows the user\u0026rsquo;s own language choice, with an allowlist so an unrecognised value cannot land in the attribute.\n3.3 Disproportionate burden — third-party code-hosting interface # The code-hosting interface at frem.sh (repositories, issues, pull requests, code review, settings) is built on Forgejo, third-party free and open-source software. fremverk applies a small series of patches to it, none of which touch the user-interface layer, and a white-label theme.\nfremverk does not control the accessibility of this interface and cannot practically bring the whole of it into conformance: it is the large majority of the customer-facing surface, it changes with every upstream release, and remediating it would mean maintaining a permanent private fork of another project\u0026rsquo;s entire front end. fremverk relies on Article 14(1)(b) of Directive (EU) 2019/882 (fundamental alteration / disproportionate burden) for this component only.\nThis is a bounded and time-limited position, not a permanent exemption:\nIt applies only to interface behaviour originating upstream. Everything fremverk authors — the administration console, the marketing and documentation sites, the theme, the e-mail templates — is in scope for full conformance and is assessed in §3.1. Where a defect in the third-party interface can be repaired from the theme, template or script layer that fremverk does control, it is repaired there and not claimed as burden. The contrast defects resolved in §3.1 are examples — they were on the third-party surface but were fixable in fremverk\u0026rsquo;s own theme, so they were fixed — and item 2 in §3.1 is another. fremverk does not undertake to obtain changes in the third-party component itself. This is a deliberate position rather than an oversight. fremverk has no control over whether or when a change is accepted by a third-party project, so a commitment to achieve one would be a commitment it cannot keep, and an accessibility statement should not contain commitments of that kind. Where a defect cannot be repaired at fremverk\u0026rsquo;s own layer it is disclosed as unresolved in §3.1 or §3.2, so a reader can see it rather than being told it is being handled. The assessment underlying this claim is re-run when the upstream version is upgraded. 4. Preparation of this statement # Prepared: 2026-08-11.\nMethod: self-assessment, comprising (a) an automated scan of the live public surfaces using axe-core; (b) an automated audit of the design system\u0026rsquo;s colour tokens against the WCAG 2.x contrast formula; (c) a source-level review of the interface markup.\nScope of the live scan: frem.sh/user/login, frem.sh/user/forgot_password, frem.sh/user/sign_up, frem.sh/explore/repos, frem.sh/explore/users, frem.sh/explore/organizations, www.frem.sh, docs.frem.sh. Unauthenticated pages only.\nLimitations of the method: automated testing detects a minority of accessibility barriers. Colour contrast was assessed exhaustively against the design tokens rather than per-page, which is stronger for that criterion, but automated tooling cannot assess keyboard operability, focus management or assistive-technology compatibility at all. §3.2 lists what this leaves unknown.\nRegression protection: six automated assessments run in continuous integration on every change, so the resolved items in §3.1 cannot silently regress and a new violation of a covered rule fails the build:\na colour-contrast audit of the design tokens, covering light and dark themes for both text and non-text contrast; an axe-core structural sweep of the shared page framework plus 39 view components; a check that every transient error message sits in a live region; a keyboard-operability gate that presses real keys in a browser engine; an accessibility-tree gate confirming messages surface to assistive technology as named live regions — see the caveat in §3.2; a screen-reader simulator asserting what is announced and in what order — see the same caveat, which applies to this one most of all. Each carries a guard that fails the build if the check itself ever stops measuring anything, because a check that silently covers nothing reports success, which is worse than having no check.\n5. Feedback # If you encounter an accessibility barrier in fremforge, or need content provided in an alternative format, please contact:\nE-mail: accessibility@fremverk.com Postal: fremverk ApS, Ringager 4C, 2. tv, 2605 Brøndby, Denmark We aim to acknowledge within 5 working days and to give a substantive response, including a remediation timeline where a barrier is confirmed, within 20 working days.\n6. Public-sector procurement # Public-sector bodies in the EU and EEA are themselves bound by Directive (EU) 2016/2102 and generally require suppliers to evidence conformance with EN 301 549. fremverk will on request provide the current version of this statement and the underlying automated assessment output. fremverk cannot currently provide a third-party audit report or a completed accessibility conformance report (ACR). Where a tender requires one, that gap should be raised before bidding rather than discovered at evaluation.\n7. Enforcement procedure # If you are not satisfied with our response under §5, you can escalate. Accessibility of digital services is supervised nationally, so the competent body depends on the country you are in and, in several states, on whether the complaint concerns a product or a service.\nHow to escalate:\nTell us you are dissatisfied, at accessibility@fremverk.com. We will confirm in writing what we did and did not do, so you have something to hand on. Contact the accessibility supervisory authority in your own country. In EU Member States this is the body designated under Directive (EU) 2019/882; in Norway it is the authority designated under the forskrift om universell utforming av IKT-løsninger. Your national government\u0026rsquo;s accessibility or consumer-protection portal will name the current body. If you tell us which country you are in, we will identify the correct authority for you and put it in writing. You should not have to navigate this to make a complaint about us. This section deliberately does not print a table of named authorities. The allocation of competence between market-surveillance authorities, sector regulators and equality bodies differs by Member State and changes over time, and a statement that names the wrong authority obstructs the complaint it is supposed to enable. Naming the route accurately is more useful than naming a body inaccurately. Where fremverk contracts with a customer in a specific market, the competent authority for that market is confirmed and stated in the engagement documentation.\n8. Change log # Version Date Change 1.4 2026-08-12 Resolves open non-conformance 3: the setup-progress control on the administration overview described itself to assistive technology as a set of tabs, while no tab panels existed and nothing was marked as selected. Its segments are links that move to a step, so the description was corrected rather than the behaviour completed — the current step is now marked as the current step, and the group is a labelled set of links. The reason this one had stayed open is also addressed: the control could not previously be exercised by the automated checks, and now is. §3.1 drops to two open items and §3.2 narrows accordingly. Automated rule-checking alone would not have caught this — the previous description was structurally valid and merely untrue — so an explicit check of the description against the actual behaviour was added alongside it. 1.3 2026-08-11 Adds a sixth automated check: a screen-reader simulator that asserts what is announced and in what order — that an error is announced AS an error, that it precedes the form controls it refers to, that decorative marks stay silent, and that nothing is said twice. §3.2 is rewritten to describe both automated checks in the assistive-technology entry and to state precisely what a simulator is worth: it implements the specification, while real screen readers depart from it, and those departures are where announcement usually fails. Assistive-technology testing remains NOT performed and nothing in this statement has been heard by a person using a screen reader. No conformance claim in §2 or §3.1 changed. 1.2 2026-08-11 Resolves a further non-conformance: interactive controls in the shared interface (the account and organisation popovers, the appearance selector) announced menu behaviour — arrow-key navigation, dismissal with Escape — that did not exist. Implemented and now asserted on every change. §3.2\u0026rsquo;s keyboard entry narrows accordingly: the remaining gap is the overview setup-progress control and per-page behaviour, rather than menus and popovers generally. That control is added to §3.1 as open non-conformance 3, having previously been described only in internal tracking. §3.1 also records why automated rule-checking passed all of these: it verifies that a description is present, not that the promised behaviour exists. 1.1 2026-08-11 Keyboard operability moves from unassessed to assessed with a bounded scope — an automated gate now drives real key sequences against the shell and command palette on every change, and §3.2 states precisely what it still does not cover. A second gate asserts that error and status messages reach the accessibility tree as named live regions; §3.2 explains at length why that is not screen-reader testing and must not be read as such. Assistive-technology testing remains NOT performed and is named as the most significant remaining gap. No conformance claim in §2 or §3.1 changed. 1.0 2026-08-11 First published version. §7 rewritten to describe the escalation route rather than print a table of named national authorities — the allocation of competence differs by Member State and a wrongly-named body obstructs the complaint it should enable; fremverk instead undertakes to identify the correct authority on request. The draft-status warning is removed. §3.1 item 2 restated to match an explicit operator decision not to pursue the upstream fix (see that row). No conformance claim changed in this version. 0.2 2026-08-11 Broad remediation pass. Four further non-conformances resolved — nested landmarks on every admin/operator page, duplicate \u0026lt;main\u0026gt; on the welcome pages, a Level A timed-redirect failure (WCAG 2.2.1), and nine unannounced error messages. The \u0026lt;html lang\u0026gt; item is retired as fixed. The unlabelled-checkbox item is reclassified from open to mitigated-client-side. Automated coverage expanded from the shared page framework alone to 39 view components, and a third gate added. §3.2 rewritten: keyboard operability is now the largest known gap. §7 still pending counsel. 0.1 2026-08-11 Initial draft. Compliance status set to partially compliant on the basis of the first automated assessment. Five contrast non-conformances resolved in the same change-set. §7 pending counsel confirmation. ","externalUrl":null,"permalink":"/legal/accessibility-statement/","section":"Legal documents","summary":" Last updated: 2026-08-11\n","title":"fremforge Accessibility Statement","type":"legal"},{"content":" Last updated: 2026-10-10\nEffective Date: 2026-04-25 — Version: 1.6 (effective 2026-10-10; full revision history in §Change log)\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/\u0026lt;slug\u0026gt;/_admin/* (per-tenant, authenticated; URL Option B per fremverk\u0026rsquo;s internal product plan) 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 Public 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 7 days (persistent; SESSION_LIFE_TIME = 604800). Not cleared on browser close — see the note below. 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: effectively permanent (Max-Age=2147483647, ~68 years — Forgejo\u0026rsquo;s LangCookieMaxAge default) — corrected in 1.4, this said 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 Effectively permanent frem.sh fremforge_operator_session (operator console) fremforge control plane Operator-console session — authenticates a fremverk operator to the internal console. Corrected in 1.5: this cell said \u0026ldquo;per-org session binding\u0026rdquo;, which describes a tenant-scoped control; this cookie is the operator console\u0026rsquo;s own session and there is no separate per-org cookie Strictly necessary Yes 30-minute idle timeout (slides on each request), 12-hour absolute cap frem.sh Why each is strictly necessary # session: without this cookie the Forgejo forge cannot tell if you are signed in. Lifetime corrected in 1.3: this policy said the cookie was cleared on browser close. It is a persistent 7-day cookie, set deliberately so that users arriving via single sign-on survive a browser restart — an OIDC arrival never sees the \u0026ldquo;Remember Me\u0026rdquo; checkbox on the password form, and without a persistent cookie the identity provider re-prompted on every restart. The window matches the 7-day \u0026ldquo;Remember Me\u0026rdquo; period. This does not change the ePrivacy analysis: an authentication cookie is strictly necessary under Art. 5(3) whether it is session-scoped or persistent, so no consent is required and no banner is needed. What changed is the accuracy of the lifetime column, which is the evidence a reader checks. 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_operator_session: the operator-console session. Without it, an operator must re-authenticate through the identity provider on every request. Corrected in 1.5: this row was labelled \u0026ldquo;fremforge middleware session\u0026rdquo; and described as \u0026ldquo;per-org session binding\u0026rdquo; with an \u0026ldquo;8h rolling\u0026rdquo; lifetime. There is exactly one control-plane session cookie and it is this one; the 8-hour fixed TTL it named was REMOVED by audit P1-3 and replaced with a 30-minute idle timeout that slides on each authenticated request, plus a 12-hour absolute cap that forces a full re-authentication regardless of activity. That is materially STRONGER than what was published, not weaker — an idle session now dies in 30 minutes rather than lasting eight hours, and no session can outlive 12 hours even if continuously active. 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 per-IP rate limiting plus Shield DDoS protection at the CDN edge. 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 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. 1.2 2026-08-04 Bot-mitigation sentence corrected: it listed \u0026ldquo;edge WAF\u0026rdquo; among the server-side controls containing signup abuse. There is no edge WAF on any fremforge surface — every pull zone runs Bunny Shield at the Basic tier with the WAF disabled, deliberately, since 2026-05-09. Replaced with the controls that do run at the edge: per-IP rate limiting and Shield DDoS protection in Block mode. The honeypot, dwell-time check and API-gateway throttle named alongside it are unchanged and are the substantive controls here. No cookie is added, removed or re-scoped by this correction. Found in the same sweep as DPA 1.25, which carries the full account of the posture. 1.3 2026-08-05 The session cookie\u0026rsquo;s published lifetime was wrong: it is a persistent 7-day cookie, not cleared on browser close. Forgejo is configured with SESSION_LIFE_TIME = 604800, which governs both the server-side TTL and the cookie\u0026rsquo;s Max-Age, aligned to the 7-day LOGIN_REMEMBER_DAYS. The setting is deliberate — an OIDC arrival never sees the \u0026ldquo;Remember Me\u0026rdquo; checkbox, so without a persistent cookie the identity provider re-prompted on every browser restart. The ePrivacy conclusion is unchanged and no consent is required: an authentication cookie is strictly necessary under Art. 5(3) whether session-scoped or persistent. What was wrong is the lifetime column, and that column is the whole point of this document — §1 says it exists so that the absence of a cookie banner is \u0026ldquo;a verifiable commitment rather than an omission\u0026rdquo;, which a reader cannot verify against a figure that is wrong. The identical row in privacy notice §3.5 is corrected in lockstep (1.14). Found by auditing this policy\u0026rsquo;s claims against the Forgejo configuration; the config comment beside the setting was accurate and careful, and the published claim beside it had simply never been updated. Now gated by the session-cookie-lifetime-matches-the-config claim. 1.4 2026-08-05 The lang cookie\u0026rsquo;s published lifetime was 12 months; it is effectively permanent. It is set with Max-Age=2147483647 — about 68 years — mirroring Forgejo\u0026rsquo;s own LangCookieMaxAge default, and the code comment beside it says so. The implementation is deliberate; the published figure was wrong. Second wrong lifetime in this table in one day, after the session cookie in 1.3 — two of the four published lifetimes did not match the code, in the document whose §1 states it exists so the absence of a banner is \u0026ldquo;a verifiable commitment rather than an omission\u0026rdquo;. The strictly-necessary classification still holds: ePrivacy Recital 25 exempts preference cookies set in response to an explicit user action, and that exemption does not turn on duration — but a bounded 12-month figure was a stronger-looking position than the one we actually run, so the correction is disclosed rather than quietly adjusted. Now gated: the claim derives the value from the code and requires all three publishing surfaces to state it. The fourth row, \u0026ldquo;fremforge middleware session, 8h rolling\u0026rdquo;, remains UNVERIFIED — two searches did not locate an 8-hour TTL, and absence from a search is not evidence either way. 1.5 2026-08-05 The fourth cookie row was wrong on both its name and its lifetime, and this table is now fully reconciled against the code. The row read \u0026ldquo;fremforge middleware session 1.6 2026-10-10 §7 heading — OIDC, not SAML. The heading read \u0026ldquo;OIDC and SAML sign-in to your identity provider\u0026rdquo;. fremforge offers single sign-on over OIDC only; SAML is not offered, and never was. The section\u0026rsquo;s text, about cookies your identity provider sets on its own domain, is unchanged. A heading correction that leaves every right and obligation as it was, so it is not materially adverse under ToS §17 and takes effect on publication. ","externalUrl":null,"permalink":"/legal/cookie-policy/","section":"Legal documents","summary":" Last updated: 2026-10-10\n","title":"fremforge Cookie Policy","type":"legal"},{"content":" Last updated: 2026-10-23\nEffective Date: 2026-04-25 — Current Version: 1.57 (effective 2026-11-12; until then version 1.49 applies from 2026-11-09, version 1.48 from 2026-11-06, version 1.43 from 2026-11-03, and version 1.39 before that; 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 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 subject identifiers and claims, TOTP secrets (where enabled), personal access tokens, session and API token identifiers. Usage and technical: IP addresses, user agents, timestamps of actions, admin-UI and API calls, requests to the Customer\u0026rsquo;s package and container registry (the registry access log), commit author identities and email addresses, issue and PR participation. Repository and collaboration content: whatever the Customer or its Users commit, post, comment, or upload, which may contain personal data as determined by the Customer. Billing and commercial: organisation legal name, billing contact, VAT number, invoice records. Raw payment-card and bank-account data is processed by Mollie only; fremverk does not see or store it. Dependency proxy: credentials the Customer stores for an upstream registry (encrypted at rest), and records of pulls through the proxy (the User, IP address, artifact and time). 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. fremverk does not retain Customer Content sent through those features beyond the request lifecycle, and does not use it for training.\nScope of this prohibition, stated precisely because the distinction is material. The prohibition above binds fremverk and fremverk\u0026rsquo;s sub-processors, which fremverk controls by contract. It does not and cannot bind an AI vendor that the Customer configures itself: for those features the Customer chooses the vendor, contracts with it directly and pays it directly, and fremverk acts as a conduit that encrypts the Customer\u0026rsquo;s API key at rest and forwards the request. Whether that vendor trains on the content the Customer sends is governed by the Customer\u0026rsquo;s own agreement with that vendor, not by this DPA — some vendor tiers permit training by default. fremverk applies no technical control that would prevent it and does not represent that it can.\nUntil 2026-08-06 this clause stated without qualification that Service AI features \u0026ldquo;do not retain Customer Content in model weights or training corpora\u0026rdquo;. For fremverk and its sub-processors that remains true. For a Customer-configured vendor it was a statement fremverk had no standing to make, and a Customer choosing a consumer-tier vendor account could reasonably have relied on it. Customers who require a contractual no-training guarantee on that path should obtain it from their chosen vendor — typically an enterprise or zero-retention tier — or use Enterprise-on-Demand, under which fremverk will contract with a vendor directly and the prohibition above then applies.\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.\nDesignating a security contact. A Customer designates one self-service, in the organisation\u0026rsquo;s billing and contact settings, as the Operational alerts email. That address receives fremverk\u0026rsquo;s operational and security notices — including the breach notification in §8.1 and the government-access notification in §11A.1 — and is the \u0026ldquo;designated security contact\u0026rdquo; those clauses refer to. Where it is not set, those notices fall back to the Customer\u0026rsquo;s billing contact-of-record, so no notice in this DPA depends on a channel the Customer has not provided. Invoice and billing correspondence is routed separately and is unaffected by this setting. fremverk keeps a record of all personal-data breaches as required by GDPR Art. 33(5) and makes it available to the Customer on request.\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 90 days from the termination date to enable the Customer to export it using the on-demand signed-export endpoints. This window aligns with the post-termination export window in Terms §16.5 and the suspension/termination retention sequence in AUP §11. After the 90-day export window, Customer Personal Data is hard-deleted from primary storage within 30 days. Live-tier backups (continuous WAL + daily snapshots — see Annex A.9) are not edited to remove an individual Customer\u0026rsquo;s data. Customer Personal Data deleted from primary storage can therefore remain in these encrypted backups for up to 90 days after primary deletion, and expires with the snapshots that contain it through the normal backup-retention lifecycle. The backups are used only to recover the platform; they are not used to serve or otherwise process the deleted data. Total time from termination to expiry from the live-tier backups is up to 210 days (90-day export window, up to 30 days to primary deletion, up to 90 days in backups). Disaster-recovery snapshots (Annex A.9) are sealed copies retained 13 months for object-store payloads and 30 days for repository content (Actions artifacts, CI run logs and tenant-initiated exports are not held in this tier; Annex A.9) solely for catastrophic-recovery scope (e.g. recovering from a long-undetected corruption that predates the live-tier window). These snapshots are not used for any Customer-facing access path; if a DR restore brings Customer Personal Data back into primary storage after it has expired from the live-tier backups, that data is re-processed through the same hard-delete procedure within 30 days of the restore. Immutable audit log entries linked to the Customer\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 120-day primary-deletion mark — only the accounting-relevant columns survive into the 5-year archive. On written request, fremverk provides written confirmation of deletion.\nfremverk provides Customer Content in machine-readable formats: Git bundles for repository content (full history, all refs); JSON (newline-delimited) for issues, pull requests, comments, labels, milestones, releases, repository metadata, audit logs, the registry access log, the pull census and the third-party component inventory; and machine-readable inventories for LFS objects and package-registry artifacts, listing each object\u0026rsquo;s identifier, size and path so it can be re-hydrated into another forge. On request, the export also includes the package payloads: every file of every package version the Customer\u0026rsquo;s organisation owns, as a separate archive covered by the same signed manifest (per-file SHA-256), with container images as OCI image layouts; each package file is accompanied by the software bill of materials (CycloneDX and, where produced, SPDX) that the Service generated for it; package payloads above 50 GiB are exported with fremverk\u0026rsquo;s assistance rather than self-service. Every export also includes, as newline-delimited JSON, the security-scan findings the Service holds for the Customer\u0026rsquo;s organisation (static analysis, dependency vulnerabilities, licences, container images, secrets — identified by location and fingerprint, never by the secret value — and malware), with their dismissals; the Customer\u0026rsquo;s package-policy configuration, verdicts, download decisions and exceptions with their approvals; and the build-provenance and release attestations the Service produced, with the signature the Service holds for each (the DSSE envelope and, where one was issued, the Sigstore bundle). These files are covered by the same signed manifest. LFS payloads are not included in the export archive — they remain retrievable from the Service for the retention period in §Data retention and deletion, and fremverk\u0026rsquo;s migration assistance under §Transition assistance covers their transfer. 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 — ENDED 2026-07-01 (recorded in DPA v1.17). During fremverk\u0026rsquo;s pre-launch period — defined as zero paying Customers AND zero Customers under contract for paid service, machine-readable via the pre_launch_paying_customers field in fremverk\u0026rsquo;s internal supplier register — the direct-email channel (a) was waived for Sub-processor changes and the public posting (b) carried the full notification, there being no contractual Customer recipients to notify by direct email. This carve-out lapsed at go-live on 2026-07-01 with the first paying Customer (pre_launch_paying_customers set false). As of DPA v1.17, every Annex B / Sub-processor change follows the full dual-channel notification in this §10.2 with no carve-out — direct email to the billing contact-of-record AND public posting, at least 30 days in advance. This paragraph is retained for audit continuity; the cutover is the record the clause previously anticipated.\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 Public eu-de (Biere/Magdeburg, DE) Deutsche Telekom AG (T Cloud Public) CI logs and runner artifacts T Cloud Public eu-de (DE) Deutsche Telekom AG (T Cloud Public) Audit logs (hot + WORM archive) T Cloud Public eu-de (DE) Deutsche Telekom AG (T Cloud Public) Authentication metadata (session, MFA secrets, recovery hashes) T Cloud Public eu-de (DE) Deutsche Telekom AG (T Cloud Public) Billing records (in-monolith engine, invoice rows) T Cloud Public eu-de (DE) Deutsche Telekom AG (T Cloud Public) 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: UpCloud Ltd (FI-incorporated, Amsterdam NL datacenter); OVHcloud (DE, backups) Lettermint B.V. Operator IdP (Authentik) — operator + workforce session metadata, MFA secrets, recovery hashes T Cloud Public eu-de (DE) — deployed in a dedicated, isolated cloud project for blast-radius isolation per Annex A.3 Deutsche Telekom AG (T Cloud Public) 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 Public eu-de (DE) Deutsche Telekom AG (T Cloud Public) CDN edge cache (TLS-terminated) EU PoPs only BunnyWay d.o.o. CDN access logs (request metadata; client IP anonymised by default) Germany — retained by the CDN provider for 3 days; copied by fremverk to T Cloud Public eu-de (DE) and retained 30 days BunnyWay d.o.o.; Deutsche Telekom AG (T Cloud Public) 11.2 International transfers # Customer Personal Data is processed exclusively inside the EU/EEA by entities with no US parent. Outbound transactional email is delivered through Lettermint B.V., a Dutch entity (Zwolle, KvK 80706290) processing the data on EU-only upstream infrastructure (UpCloud Ltd, Amsterdam datacenter; OVHcloud, Germany, for backups). Inbound shared-mailbox correspondence addressed to operator addresses (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) is hosted by Heinlein Hosting GmbH (mailbox.org) in Berlin, Germany. No international transfer outside the EU/EEA occurs on any processing path fremverk chooses, and no Article 46 GDPR safeguard is required for them. Where the Customer directs the dependency proxy to an upstream registry outside the EU/EEA, see Annex B §B.9; where the Customer turns on a secret validity check for a third-party credential issuer, see Annex B §B.10.\nNote on T Cloud Public sub-services: T Cloud Public eu-de is a single legal entity (Deutsche Telekom AG / T-Systems International GmbH) operating multiple sub-services in scope of this DPA: CCE (Kubernetes), RDS (Postgres), DCS (Redis), SFS Turbo (NFS), OBS (object storage), DEW KMS, APIG (API gateway), FunctionGraph (serverless), SWR (container registry), CTS (audit), LTS (logs), CES (alarms), SMN (notifications), AOM (monitoring), Cloud DNS, NAT Gateway, ELB, EIP, ECS (compute under CCE). All sub-services run in the same eu-de legal/physical boundary and are covered by the single Deutsche Telekom AG row above; this list is informational.\n11.3 CLOUD Act / US extraterritorial-law posture # fremforge has no CLOUD Act exposure on any processing path fremverk chooses. All Customer Personal Data — repositories, CI runs, audit logs, authentication metadata, billing records, payment-instrument data, accounting bilag, outbound transactional email, and inbound shared-mailbox correspondence — is processed inside the EU by entities with no US parent (Deutsche Telekom AG in Germany; Heinlein Hosting GmbH in Germany; Mollie B.V. in the Netherlands; Visma Dinero ApS in Denmark; Lettermint B.V. in the Netherlands; BunnyWay d.o.o. in Slovenia at EU edge PoPs).\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 UpCloud Ltd (Finland-incorporated, Amsterdam datacenter) with backups at OVHcloud (Germany). No US-parented upstream sits in the email path. Lettermint replaced Sendinblue SAS / Brevo on 2026-05-14; the superseded Brevo cap-table footnote (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.\nCustomer-chosen upstream registries (dependency proxy) — When the Customer uses the dependency proxy, fremforge fetches artifacts from the upstream registries the Customer names, several of which are operated by US-incorporated companies. See Annex B §B.9: those registries are not sub-processors of fremverk, and any US-extraterritorial-law exposure of their processing is governed by the Customer\u0026rsquo;s own relationship with them.\nCustomer-instructed secret validity checks — When the Customer turns on a validity check for a third-party credential issuer, fremforge asks that issuer whether a credential found in the Customer\u0026rsquo;s repositories is still valid. An issuer may be operated by a US-incorporated company; the setting shows each issuer\u0026rsquo;s operating jurisdiction (US-operated or EU-operated) before the Customer turns its check on. See Annex B §B.10: those issuers are not sub-processors of fremverk, and any US-extraterritorial-law exposure of their processing is governed by the Customer\u0026rsquo;s own relationship with them.\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 (or, where none has been designated, the Customer\u0026rsquo;s account-of-record administrator — the same addressing rule as §8.1), unless legally prohibited from doing so (in which case fremverk notifies as soon as the prohibition lapses); (d) Provides the Customer with reasonable opportunity to seek a protective order or otherwise contest the request.\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 Public (ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, TISAX), Bunny CDN (ISO 27001, SOC 2 Type II), Heinlein Hosting / mailbox.org (ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen TR 03108), and Mollie (PCI-DSS Level 1), with links on the trust page; and Lettermint B.V. (ISO/IEC 27001:2022, certificate published in Lettermint\u0026rsquo;s Trust Center). 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 Public 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 Public eu-de data centres in Biere and Magdeburg, Germany, operated by Deutsche Telekom under ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, and TISAX certifications. Physical access controls, video surveillance, redundant power and cooling, and fire suppression are T Cloud Public\u0026rsquo;s responsibility as sub-processor. Bunny CDN edge nodes in EU points of presence only, operated by BunnyWay d.o.o. under ISO 27001 (cert year 2025) and SOC 2 Type II (cert year 2023). Currency of cert evidence is verified at each quarterly supplier review (see fremverk\u0026rsquo;s internal supplier register, §4 Quarterly review, which records the current review dates). A.2 Network and edge security # TLS 1.2+ on every HTTP surface. HSTS enabled. Modern cipher suites only. DDoS mitigation at the edge (Bunny CDN) on every public HTTP(S) surface — Forgejo UI, Git over HTTPS, the API, the package registry, and the marketing, documentation, status and trust sites. Volumetric attack traffic is blocked at the edge, combined with per-IP rate-limiting edge rules that apply a tighter cap to anonymous traffic than to authenticated requests. No Web Application Firewall (WAF) is enabled at the edge on any fremforge surface. This is deliberate. Pre-launch testing produced an unacceptable false-positive rate: the OWASP Core Rule Set flags ordinary Git protocol bodies, Forgejo\u0026rsquo;s asset and diff URLs, raw-blob paths carrying hex identifiers, signed-URL query strings, and every form-body surface on the API (signup with VAT number, proof-of-work captcha, billing setup, webhook receivers). Enabling it path-by-path left almost nothing actually protected while breaking legitimate Git operations, which is a worse outcome for the Customer than the residual edge-layer risk. The controls fremverk relies on instead are at the application layer and are listed in this Annex: Forgejo\u0026rsquo;s session and CSRF protection with parameterised SQL, proof-of-work and HMAC signed tokens on public write surfaces, OIDC for operator access, the per-IP and per-organisation rate limits above, and the SSRF hardening below. This posture is published on the trust page, and is re-reviewed at each quarterly operational review. T Cloud Public Anti-DDoS protection on the SSH endpoint at ssh.frem.sh:443 (port 443 mapped to the platform\u0026rsquo;s SSH service; port 22 is not publicly exposed on the apex domain). Per-organisation rate limiting at the T Cloud Public APIG layer (per-API-group throttling policies) keyed on the URL path prefix; for token-authenticated callers, additionally enforced at the application layer via the in-monolith rate-limit middleware backed by DCS Redis. Layered SSRF hardening on every workload that handles Customer-supplied URLs (webhook delivery, repo mirroring, OIDC discovery, avatar fetches, markdown image proxy) via three enforcing layers: (1) per-pod VPC Security Group egress allowlist under T Cloud Public\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 (an application-level SSRF guard plus the proxy\u0026rsquo;s TCP-connect-layer filter) applying the deny set covering RFC1918, link-local, IPv6 ULA, loopback, multicast, T Cloud Public metadata endpoints, and a one-shot DNS-resolve-then-dial-by-IP pattern to prevent TOCTOU/rebinding. A.3 Access control # Human access to production is federated from fremverk\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 a dedicated, isolated fremverk cloud project on T Cloud Public (Germany, EU). fremverk does not use any external (US-parented) identity provider for operator authentication. Effective from operator-console activation: the Authentik tenant infrastructure was deployed 2026-05-06; binding of the operator-console (/_admin/*) and customer-side OIDC federation paths to Authentik becomes effective for an individual tenant only once the operator OIDC credentials are configured in the API\u0026rsquo;s runtime configuration and the relevant tenant federation is bound. Interactive Forgejo site-admin access is break-glass only, through a single local account (fremforge-admin) vaulted in T Cloud Public DEW CSMS with mandatory MFA; every interactive login pages on-call and writes to the platform-security audit stream. Four service accounts also hold the site-admin role and use it in normal operation, and this Annex previously denied that. They are fremforge-monolith-bot (control-plane provisioning), fremforge-runner-bot (CI job lifecycle), fremforge-bot (platform automation) and fremforge-scan-bot (fleet-wide security scanning). Each authenticates with a scoped API token rather than interactively, so the MFA and on-call-paging controls above apply to the break-glass account and not to these; their activity is recorded in the audit log. The site-admin role is used because these functions act across every tenant — creating organisations, reading any repository to scan it, managing runner registration — which Forgejo\u0026rsquo;s permission model cannot express below site-admin. fremverk treats this as an accepted risk rather than a control: the mitigation is credential scoping at the point of use (each token is minted per function and the scanner\u0026rsquo;s credential is scoped per owner so a scan of one tenant cannot read as another), not a reduction of the role itself. Control-plane functions otherwise use scoped, non-admin service accounts. Customer-side access is authenticated via OIDC SSO to the Customer\u0026rsquo;s identity provider, with per-organisation session binding and scoped API tokens as documented in the OIDC SSO page. SAML 2.0 single sign-on is not offered. Magic-link single-use enforcement. Where email-delivered links carry an authentication or one-time consumption purpose (welcome-email initial-password-claim, billing-setup callback, undo-cancellation, signup-confirmation), the link payload is HMAC-signed against BILLING_LINK_SIGNING_SECRET with a 48-hour TTL and atomically consumed via Redis GETDEL on the encrypted-state-bag key. First click wins; second click sees null and returns \u0026ldquo;already consumed\u0026rdquo;. Implementation: the password-claim service\u0026rsquo;s single-use consume() path together with the signed-token service. Fail-closed on Redis-unreachable: the route refuses rather than letting a non-atomic check through. The Lettermint-side delivery is the transport for these links; the single-use claim is enforced inside fremverk\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 the platform\u0026rsquo;s SSH service; port 22 is not publicly exposed on the apex domain). Encryption at rest: T Cloud Public RDS for PostgreSQL, OBS object storage, EVS block storage, and SFS Turbo NFS all encrypted with fremverk-managed Customer Master Keys (CMKs) in T Cloud Public DEW KMS (separate per-component CMKs, one per data domain, with annual auto-rotation enabled). Backup archives on OBS WORM encrypted with the same DEW-managed keys (CBR vault SSE inheritance, see Annex A.9). The CMKs are held by fremverk in its T Cloud Public account; the Customer does not hold key material — see §17.3 for the customer-held-key roadmap. Earlier wording \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 Public DCS Redis does not currently expose a tenant-controlled KMS attach point on the OTC platform; data at rest is encrypted with provider-managed DEW keys rather than the per-component customer-managed CMK pattern used elsewhere. The full DCS contents inventory is in the table below; all items are TTL-bounded (≤ 7 days) and non-durable. fremverk will migrate DCS to customer-managed-KMS the moment T Cloud Public exposes the attach point. Disclosed transparently in line with §11.2 and clarified in line with audit P2-15. 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 the per-job runner virtual machine as environment variables only for the lifetime of the job, never persisted to shared volumes or ConfigMaps. The runner\u0026rsquo;s own registration credential is ephemeral and per-runner: Forgejo deletes the runner identity when its task completes, so a credential recovered from a terminated VM authenticates nothing. Signed commits — default path is SSH-key signing (git config gpg.format=ssh, with the per-org allowedSignersFile derived from members\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 Public eu-de (Fulcio + TSA; no Rekor transparency-log fan-out). Endpoints sign.frem.sh and tsa.frem.sh. No request transits the public Linux Foundation Sigstore instance. Customers opt in per-tenant via auth-policy require_oidc_signed_commits; the Fulcio signing trust anchor is rooted in customer-configured OIDC issuers (one per tenant, set at Authentication policy → OIDC issuers for keyless signing). Customer setup guide at docs.frem.sh/get-started/keyless-commit-signing/; operator runbook at docs.frem.sh/admin/sigstore-pki/. A.5 Isolation and multi-tenancy # Logical isolation per Forgejo organisation, enforced by Forgejo\u0026rsquo;s own access-control layer: a repository is readable only by the organisation\u0026rsquo;s members and its explicit collaborators, and every API and Git path resolves permission through that layer on each request. fremverk re-verifies this isolation at least hourly. An automated probe asks Forgejo directly, as an unauthenticated caller, whether any Customer organisation or its repository list can be read. A positive result raises a Critical alarm to on-call. The probe additionally asserts on every run that it can reach Forgejo at all, and reports its result as UNKNOWN rather than as a pass if it cannot — so a probe that has silently stopped working raises its own alarm instead of reporting clean. First clean sweep observed 2026-08-06: 8 organisations checked, 0 readable. What this verifies, and what it does not. The probe covers anonymous readability against Forgejo\u0026rsquo;s permission layer, which is the mechanism this Annex relies on. It does not verify authenticated cross-tenant access (a member of one Customer organisation attempting to read another), and it does not test the public CDN edge independently of Forgejo. Those surfaces are governed by the same permission model but are not separately probed today, and this Annex will not claim they are until they are. History, retained deliberately. Until 2026-08-05 this Annex stated that isolation was \u0026ldquo;enforced by automated nightly ACL smoke tests via FunctionGraph\u0026rdquo;. No such test existed and none ever had; DPA 1.28 corrected the Annex to say so plainly rather than quietly substituting a replacement. The probe described above was then built, and this clause was restored only after it was observed completing a real sweep — not when it was written, deployed, or scheduled. A reader who saw the 1.28 wording is entitled to know which of those happened. Hosted CI runners execute on ephemeral T Cloud Public Elastic Cloud Server (ECS) virtual machines, booted per job from a fremverk-built machine image and terminated when their work completes. A virtual machine is a full hardware-virtualisation boundary — a stronger isolation primitive than any container runtime, shared-kernel or secure — and no runner shares a kernel with another tenant, with the platform, or with the CCE cluster that hosts the control plane. Grouping is per commit, not per job. All jobs of a single Forgejo Actions run over the same commit in the same repository may execute on the same virtual machine, which is then destroyed. Jobs from a different commit, a different repository, or a different tenant always get a different machine, so the cross-tenant boundary is one VM per tenant workload at all times. fremverk has assessed and accepted that a later job of a commit may reuse the machine an earlier job of the same commit ran on: it is the same reviewed code either way, and the alternative is a cold-boot latency penalty on every step of a pipeline. This grouping is equivalent to the VM-per-job model of the major hosted-CI providers for cross-tenant purposes, and marginally more permissive within a single pipeline. Runner machines start clean from the image on every boot, hold no persistent storage, mount no Kubernetes service-account token (they are not cluster members), and carry a per-instance VPC Security Group restricting egress to the outbound proxy and the runner\u0026rsquo;s required Git and container-registry destinations only. The Security Group denies the shared CCE cluster, the T Cloud Public metadata endpoints, and other runner machines at the hypervisor layer, independently of anything running inside the machine. The Customer\u0026rsquo;s workflow has administrative rights inside its own runner machine. A CI job must be able to install packages, build container images and run privileged tooling, so it is not confined within the machine — this is the same posture as the major hosted-CI providers, where a workflow likewise has root or sudo on the runner it is given. The boundary that protects other tenants and the platform is therefore the machine itself plus the Security Group, not in-guest confinement, and it is the boundary this annex commits to. Earlier versions of this annex described in-guest confinement (non-root, capabilities dropped, read-only root filesystem) carried over from a container-based design that was never the production path; corrected here to describe the control that actually exists. Per-tenant audit-log streams in T Cloud Public LTS tagged tenant_id; tenant admins see only their tenant\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 Public AK/SK, GitHub ghp_*/ghs_*, Slack xoxb-*, and similar prefixed/entropy-signed tokens). This platform-floor control cannot be disabled by any tenant administrator or repo owner. Push protection — rejection of pushes introducing high-severity secrets, with an override path recorded in the audit log. Dependency scanning on pull requests via Trivy/osv-scanner; configurable per-org merge-block threshold on CRITICAL CVEs. Signed commits via SSH-key signing (default) or GPG, with verification surfaced per repo in the fremforge admin UI. SLSA provenance for build artifacts produced on hosted runners; attestations stored alongside artifacts and verifiable via slsa-verifier. Build-time tooling resolved through fremverk-controlled mirrors. Forgejo Actions, container base images and third-party CI tooling used by fremforge\u0026rsquo;s own build pipeline are mirrored from upstream into fremverk-controlled Forgejo organisations on frem.sh (one organisation per upstream namespace — actions, docker, pnpm, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny, forgejo) and into fremverk-controlled namespaces of the T Cloud Public container registry (SWR). Git sources are refreshed by Forgejo\u0026rsquo;s native pull-mirror and OCI images by a scheduled mirroring job, each at least every 12 hours. Both are operationally independent of any single CI run, so a transient upstream outage does not affect builds. Container images pushed to SWR are scanned for CVEs (Trivy, fail-on-CRITICAL/HIGH) before push. This is an availability control, not an integrity control. A pull-mirror copies whatever the upstream ref points at, so a repointed tag would propagate. Where fremverk builds from an upstream ref, the ref is additionally pinned by commit or content hash and verified after fetch. Scope — the runner-image build reaches upstream directly, by design. The preceding bullet describes how the build pipeline resolves its tooling. It is not a claim that no fremverk build process contacts a non-EU host, and the previous wording of this Annex — which said runners \u0026ldquo;pull from these mirrors only\u0026rdquo; and that \u0026ldquo;no fremforge build path resolves DNS or fetches code from github.com … or any other US-jurisdiction host\u0026rdquo; — overstated it. Building the runner machine images (runner-base, runner-toolchain) downloads language toolchains and CLI tooling from their origins, including nodejs.org, go.dev, api.adoptium.net, sh.rustup.rs, services.gradle.org, getcomposer.org, archive.apache.org, GitHub release assets, dl.google.com, awscli.amazonaws.com, and the packages.sury.org / packages.microsoft.com apt repositories. Several are US-jurisdiction hosts. This is a deliberate exception with three properties that bound it: it runs only in fremverk\u0026rsquo;s operator/CI build context and is not a runtime path, so no Customer data is present in the process; every downloaded artefact is pinned by SHA-256 and verified after download, with the build failing on mismatch (and signature verification where upstream publishes one); and egress traverses the strict outbound proxy allowlist. The resulting image is published to SWR, and that SWR image is what production runners consume. Scope clarification — build path vs operator-internal egress. The \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, with two exceptions the Customer controls: (1) the dependency proxy fetches from the upstream registries the Customer names (Annex B §B.9), some of which are US-jurisdiction hosts, through an outbound proxy that refuses internal and private addresses; and (2) where the Customer turns on a secret validity check for a third-party issuer, the api asks that issuer, at the fixed host, or the fixed list of hosts asked in order, that fremforge has set for it (shown in the setting before it is turned on), whether a credential found in the Customer\u0026rsquo;s repositories is still valid (Annex B §B.10), through the same outbound proxy, which admits only the hosts of the issuers fremforge offers, for that purpose. Operator-internal flows that do not touch Customer data — the scheduled image-mirroring job\u0026rsquo;s pull from upstream registries (github.com, gcr.io, docker.io), Forgejo\u0026rsquo;s own pull-mirror job, the runner-base / runner-toolchain image builds described above, fremforge\u0026rsquo;s own image builds installing npm packages (through the dependency proxy, with a logged fallback to a fremverk-operated cache and then to registry.npmjs.org directly), CI runners pulling cached base images, and the operator-AI workbench (.anthropic.com, .claude.com, .openai.com, .mistral.ai) used for fremverk-internal engineering decisions — may resolve to US-jurisdiction hosts via the strict outbound-proxy allowlist. These flows are documented sub-processors where applicable (see Annex B) and operator-internal entries where not; in no case does Customer data pass through them. 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 at least every 5 minutes; the chain is verified at least hourly by an automated integrity check running on the platform; chain breaks page on-call. Audit-log retention — two-tier model: Hot (queryable) tier — security-relevant audit events (authentication, authorisation, admin actions): retention is a per-tenant policy with presets of 90 / 180 / 365 / 730 days. The Customer tenant admin sets the tier at Authentication policy → Audit log retention. Defaults: 90 days for the standard plan; 365 days for Enterprise-on-Demand, the operator-provisioned custom trial, and internal plans. After the per-tenant cutoff, the audit-payload-reaper redacts actor and fields_json to null while preserving the SHA-256 chain hashes. The two tiers are logically separate — the hot-tier is queryable PII (re-identification risk increases with retention), the WORM tier below is integrity hashes (no PII, kept full-term). Hot (queryable) tier — operational logs (HTTP, runner, infrastructure): 30 days hot, not customer-configurable. Registry access log (one record for each request to the Customer\u0026rsquo;s package and container registry, including pulls through the dependency proxy, with the User\u0026rsquo;s login, client IP address and user agent). Two kinds of routine request through the dependency proxy are the exception. Each is made with a Forgejo Actions job token, and each is allowed and answered without error. A package metadata read of this kind is not recorded. A download of this kind that the dependency proxy serves from its cache is recorded only as a count in the pull census: per day, package version, repository and Actions run, without a login, client IP address or user agent. Every other request, including every refused or failed request and every request by a User, bot, registry robot or anonymous caller, is one record. Retention is a per-tenant setting of 30 to 730 days. Unset, it follows the security-relevant audit-event retention above (90 days for the standard plan; 365 days for Enterprise-on-Demand, the operator-provisioned custom trial and internal plans). The pull census is kept for the same period. Older records are deleted daily, and none are deleted while a legal hold applies to the Customer\u0026rsquo;s organisation. Access records are not part of the audit hash chain. Immutable WORM archive (both tiers): 3 years (1095 days) in T Cloud Public OBS Object Lock compliance-mode; hash-chain anchored at least every 5 minutes; payload-bearing rows redacted at hot-tier cutoff but anchor chain is unbroken. WORM retention configurability (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. Agents have no audit identity of their own. An action an agent takes on behalf of a User, under a delegated mandate (OAuth 2.0 token exchange, RFC 8693) or through an MCP connector the User authorised, is recorded with that User as actor, the agent in the entry\u0026rsquo;s agent field and the token it used in via_token — distinguishable in the audit stream and in admin-UI filters from the User\u0026rsquo;s own actions: the actor filter of the audit log, in the admin UI and through the API, matches a value in actor, on_behalf_of or the entry\u0026rsquo;s agent field. Entries written before 2026-10-23 are not rewritten (the hash chain covers them) and keep the earlier form, with the agent as actor (oidc:agent:\u0026lt;agent_id\u0026gt;) and the User in on_behalf_of. fremverk verifies the integrity of the audit chain through an automated check, run at least hourly, that backward-walks the canonical lineage from the most recent WORM-anchored hash; mismatches page on-call. The verifier tolerates orphan anchor objects produced by bootstrap-time test runs or ungracefully-aborted anchor jobs — these are reported as warnings and do not page, since they sit outside the canonical lineage and therefore cannot affect chain integrity. The implementation, hash algorithm, integrity-check job, and orphan-tolerance contract are documented in fremverk\u0026rsquo;s Information Security Policy, available to Customers under NDA. Where the anchoring interval in this Annex cannot be met for transient operational reasons (e.g., OBS region maintenance), fremverk records the gap in the chain metadata and documents the gap in the next status-page incident report.\nA.8 Security patching # The published security-patching SLA at www.frem.sh/trust/#security-patching is part of this annex, and the targets below are identical to it. These targets are contractual and in force now. The phased model previously set out here — weaker \u0026ldquo;Phase 1\u0026rdquo; targets under commercially reasonable efforts until 2027-Q1 — is withdrawn as of 2026-08-05: it stated commitments materially weaker than the ones fremverk was already publishing on its trust page, which a Customer reads first and which this annex incorporates by reference. Rather than narrow the published promise, fremverk has adopted it. Maximum time to patch, measured from the upstream fixed release or advisory publication (whichever is later):\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 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 Public eu-de region loss): ≤ 7 days for repository content (Forgejo on SFS Turbo) and object-store payloads (OBS), backed by CBR backups replicated to eu-nl (for SFS Turbo) and a copy-if-absent replication sweep to eu-nl run at least daily, verified per-object at least daily (for OBS). Both mechanisms run considerably ahead of the ≤ 7 day bound: SFS Turbo backups are taken at least every 12 hours and replicated continuously, and the OBS sweep runs at least daily, giving observed recovery points of hours rather than days. The ≤ 15 minute in-region commitment does NOT apply to this scenario because eu-de WAL state is unreachable during a regional outage. RDS PostgreSQL (tenant metadata, billing ledger, audit chain head-pointer) has no cross-region commitment at this DPA version — the T Cloud Public CBR service does not yet support cross-region replication for RDS-typed vaults (roadmap, not GA). In a eu-de total-loss scenario before this gap closes, RDS state would be reconstructed from authoritative upstreams (Forgejo as the customer-code system of record; Mollie / Dinero for billing and accounting state; the cross-region-replicated audit chain in OBS LTS-WORM for tamper-evident history). Cross-region RDS replication is on the post-launch roadmap and will be added to this Annex when shipped. Customers transacting through fremforge prior to that change accept this scoped cross-region RPO bound as documented here. Continuous WAL replication to a cross-region read replica is on the same roadmap. Recovery time objective (RTO): ≤ 4 hours for region-internal incidents (single AZ failure within eu-de); ≤ 24 hours for full T Cloud Public eu-de region failure (cold restore to alternate EU region from cross-region OBS replica). Disaster-recovery procedures are tested at least quarterly and on material change to the recovery design (RTO target, RPO commitment, sub-processor change on the recovery path). Testing is performed by scheduled automated drills against a synthetic tenant, which in practice run more frequently than the quarterly floor: the RDS restore drill and backup-integrity verification at least monthly, the WORM archive read-back drill at least weekly, and backup-presence verification at least daily. Each run is recorded in fremverk\u0026rsquo;s platform log stream and a failed run raises an alarm to on-call. What fremverk does not produce. Until 2026-08-05 this Annex stated that each test was \u0026ldquo;documented as a runbook execution + post-drill report\u0026rdquo; with an \u0026ldquo;executive summary available to Customers under NDA on written request\u0026rdquo;. No such report has ever been produced. The directory intended to hold them contains no report, none appears anywhere in fremverk\u0026rsquo;s repositories, and none is present in version-control history. That commitment is therefore withdrawn rather than left standing: fremverk relies on the automated drill runs and their alarms as the evidence that the recovery path works, and does not currently produce a separate signed post-drill document or offer an executive summary of one. Customers requiring an attested restore report should raise it in the Order Form, where it can be agreed as a specific deliverable. The drills themselves were and are real — what did not exist was the document describing them. Automated backup-presence verification, at least daily. Independent of the annual restore drill, an automated check, run at least daily, asserts that the most recent RDS automatic snapshot exists, completed successfully, finished within the last 25 hours, and is non-zero in size. A failed assertion pages on-call through the same alerting channel that production alarms use. The verifier closes the silent-fail mode where the snapshot job could stop running unobserved between annual drills; it does not replace the annual restore drill, which remains the only test that validates restorability end-to-end. Backups: two tiers, distinct scope and access paths: Live tier: continuous WAL (30 days) + daily snapshots (90 days). Used for routine point-in-time recovery and post-termination deletion per §9 (deleted data expires from this tier within 90 days of primary deletion, up to 210 days from termination). RDS PostgreSQL daily snapshots are in-region (T Cloud Public eu-de); cross-region replication for RDS is on the post-launch roadmap pending the T Cloud Public Cloud Backup \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 Public tenancy boundary — the daily snapshots themselves are unaffected by this gap). Code, repository, and object-store backups (SFS Turbo + OBS) are already replicated cross-region to T Cloud Public eu-nl per Annex A.9 below. Disaster-recovery tier: 13 months for object-store payloads, 30 days for repository content (see the per-surface note below). Sealed copies for catastrophic-recovery scope only — no automated Customer-facing read path, no support-team query path. Retention differs by surface, and the difference is stated rather than averaged: object-store payloads (OBS) carry 13-month (395-day) cross-region retention to eu-nl: an object-lifecycle rule on each eu-nl bucket permanently removes every copy within 395 days, plus at most one day, of the day it was written there, while repository content (Forgejo on SFS Turbo) carries 30 days — the CBR vault policy keeps the last 30 daily backups, locally and cross-region. Earlier versions of this Annex stated 13 months for both; that was correct for OBS and wrong for SFS Turbo (see change log 1.24). Tenant-initiated audit-log exports are the one object-store payload excluded from this DR tier: they are not replicated cross-region at all, and live 7 days in-region in the signed download bucket before purge (see the export row in §Retention). Excluded deliberately — a signed, tenant-downloadable export is reproducible on demand from the audit log itself, so a sealed 13-month second copy of it would extend the life of Customer data well beyond the window the Customer was told about, for no recovery benefit. Corrected in DPA 1.26 / privacy 1.13: the replication toggle was set false on 2026-08-04 and the two Annex sentences still said every object-store payload carried the 13-month copy. Actions artifacts and CI run logs are also excluded from this DR tier: since 2026-10-21 they are not replicated cross-region, and the copies made before that date were permanently removed from eu-nl the same day. Excluded for the same reason as exports: an artifact or log lives only as long as the Customer\u0026rsquo;s own retention setting allows and is reproducible by re-running the workflow that produced it, so a sealed 13-month second copy would extend the life of Customer data well beyond the window the Customer chose, for no recovery benefit. RDS PostgreSQL is currently covered by the 90-day in-region live tier only; the cross-region 13-month DR tier for RDS will ship once T Cloud Public enables CBR for RDS (roadmap, not GA at the date of this DPA version). Restored data is processed through the §9 hard-delete procedure if a DR restore brings post-termination Customer Personal Data back into primary storage. Both tiers are encrypted with fremverk-managed DEW Customer Master Keys — the RDS snapshot tiers inherit the source instance\u0026rsquo;s per-component CMK, and the object-store archives carry their own per-bucket CMKs — consistent with Annex A.4. Earlier versions of this line said \u0026ldquo;T Cloud Public-managed keys\u0026rdquo;, which contradicted A.4 and understated the control; corrected here. Restore-readiness verified at least 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, following a written operator procedure available under NDA via compliance@frem.sh). A.10 Personnel # fremverk personnel with access to production are vetted (reference checks, right-to-work verification) under Danish employment law. Personnel maintain continuous professional currency in security and data protection across a defined curriculum. fremverk attests to that currency at organisation level at least annually, on a dated record signed by fremverk\u0026rsquo;s chief executive. The curriculum covers: GDPR Articles 5, 6, 25, 28, 32, 33, 34, 35, and 44–49; Danish bookkeeping-law obligations (Bogføringsloven §10); the fremverk security incident-response playbook (including escalation paths and the 72-hour Art 33 clock); secure-coding fundamentals (OWASP Top 10, supply-chain hygiene); operator-tooling least-privilege practice; and AI-specific literacy under Article 4 of the AI Act. The curriculum itself is reviewed at least annually against the current threat landscape and regulatory guidance (Datatilsynet, ENISA, EU EDPB), and the review is recorded with its date. Training records are retained for five (5) years alongside the bookkeeping bilag (matching the Bogføringsloven §10 floor; one retention number across the org), held in fremverk\u0026rsquo;s internal governance repository, which is hosted on fremverk\u0026rsquo;s own EU-resident T Cloud Public infrastructure, encrypted at rest, and access-scoped to fremverk personnel. Each attestation is recorded with: the curriculum areas covered, the curriculum version, the attestation date, the signatory, and the next-review-due date. Individual personnel may additionally record a personal attestation, carrying the same fields plus an assessment score where one applies. fremverk does not commit to holding a separate per-person attestation for every member of personnel — the organisation-level attestation is the instrument, and this is a deliberate change from earlier versions of this Annex (see change log 1.23). Every change is version-controlled and attributable. Records are made available to a Customer auditor under NDA on reasonable request per §12 Audits. Confidentiality undertakings are in every employment and contractor agreement and survive termination. A.11 Incident response # Pre-written runbooks cover Forgejo down, RDS failover, SSH unavailable, runaway tenant (single-org DDoS), data corruption, hosted-runner capacity exhaustion, fremforge api (billing-engine) outage, CCE control-plane incident, DCS Redis unavailable, OBS regional incident, SFS Turbo incident, runner-fleet regional incident, Bunny CDN outage, T Cloud Public DNS outage, Mollie outage, bulk secret exposure in audit log, suspected runner base image compromise, and compromised tenant. Detection via T Cloud Public CES metrics, AOM application observability, LTS log-based alerts, and Grafana dashboards. Alerts route through T Cloud Public SMN to the on-call staff as email, which they receive as push email on their phones. Alerts of every severity take this path, and it sends no SMS. Independently of SMN, the external uptime checks in Annex B.7 alert the on-call staff by SMS when the api health endpoint, Forgejo, the identity provider or the alerting path\u0026rsquo;s own heartbeat stops responding. Post-incident reviews are conducted for any Priority 1 incident; post-mortems for incidents affecting Customer data or availability are published on the trust page within 14 days. A.12 Testing # Internal security testing covering tenant isolation, webhook SSRF, runner machine isolation, authentication flows, push-protection override, rate-limit and abuse controls is a launch-blocker. Results are summarised and made available to the Customer on request under the confidentiality terms of this DPA. Third-party penetration test reports, when commissioned, are made available to Customers under NDA on written request. fremverk does not commit to a fixed external-pentest cadence at the standard tier; Enterprise-on-Demand contracts may agree to a specific testing cadence in the Order Form. A disaster-recovery drill (PITR restore, SFS snapshot restore, data-integrity verify) is executed at least annually and on material change to the recovery design, with a written report archived. A.13 Change management # Every production change is proposed as a pull request against the component\u0026rsquo;s repository and cannot reach production without passing the required checks on that pull request: build and full automated test suite, static analysis, dependency vulnerability scan, container-image vulnerability scan, licence-policy scan, and signature verification. Branch protection enforces the checks and code-owner review; a change that fails any of them is not mergeable. Database migrations additionally pass a schema-drift gate that fails when the declared schema and the migration history disagree. Risky changes are staged behind feature flags and reversible migrations rather than a separate pre-production soak. Earlier versions of this annex described a fremforge-tst pre-production environment with a 24-hour soak; that environment does not exist and this annex should not have described it — the control chain above is what has gated production changes throughout, and it is what fremverk commits to. Security patches may bypass the scheduled maintenance window under documented incident protocol, but not the required checks. Maintenance window: Tuesday 02:00–04:00 UTC weekly, used only when needed, announced 48 hours in advance. Every production change is applied via OpenTofu with state in T Cloud Public OBS; every change is reviewed in Git before apply. A.14 Tenant-visible controls # On-demand signed export of org data (repos, issues, PRs, audit log, LFS manifest) as a self-service action in the fremforge admin UI or via the public REST API. Per-organisation audit-log view and export. SSO enforcement with break-glass account pre-designation for IdP-outage scenarios. Optional public-repo support with AUP enforcement for abuse prevention. Annex B — Sub-processor Register # As of the date of this DPA, fremverk engages the following Sub-processors to process Customer Personal Data.\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) 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 Public) 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 BunnyWay d.o.o. Edge delivery — CDN, DDoS mitigation, rate limiting CDN Slovenia (HQ); pull-zone configured to EU edge regions only with geo-replication outside EU disabled (configuration documented in fremverk\u0026rsquo;s internal CDN configuration record). Pull-zone access logs are stored and processed by BunnyWay in Germany, IP-anonymised by default, and retained for 3 days. Caching, TLS termination, DDoS mitigation and rate limiting for public HTTP surfaces (no Web Application Firewall is enabled; see Annex A.2); 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 UpCloud Ltd (Finland-incorporated; Amsterdam, NL datacenter — primary infrastructure) + OVHcloud (Germany — backups). Email Data is hosted, stored and processed in the EU (Lettermint DPA §8.1). 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. ISO/IEC 27001:2022 (certified 2026-08-21; scope: Lettermint\u0026rsquo;s email infrastructure). Evidence: trust.lettermint.co. Lettermint\u0026rsquo;s Article 28 terms are its published Data Processing Agreement; its sub-processors are listed at lettermint.co/subprocessors. 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 Public infrastructure under its own control, including the Forgejo forge, the fremforge middleware (which carries the in-monolith billing engine), the admin UI, the runner controller, FunctionGraph jobs, the Altcha proof-of-work CAPTCHA (rate-limit defence on signup and login-discover; in-app HMAC-signed PoW served from frem.sh/_app/altcha/challenge with widget bundle at frem.sh/_app/static/altcha.js; no third-party widget JS, no external sub-processor, no separate origin, no Redis state — challenge state is HMAC-signed and ephemeral), and the Authentik identity provider where used as fremverk\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 (BunnyWay d.o.o., Slovenia — already disclosed as Annex B row 2, the CDN/edge sub-processor). DNS for frem.sh does not transit Simply.com.\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 six public health endpoints (the api /healthz endpoint, Forgejo, the Kuma public status page, the marketing site, the Authentik public sign-in page, and the heartbeat endpoint of the on-call alerting path). The probes detect customer-visible outages independently of fremverk\u0026rsquo;s own monitoring on the platform.\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, and AutoFix AI fixes for SAST findings) 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 Public DEW KMS root) and acts as a transparent proxy between the Customer\u0026rsquo;s workflow and the Customer\u0026rsquo;s chosen AI vendor.\nAutoFix AI fixes for SAST findings use the same model and nothing else. The feature is off unless the Customer turns it on, and runs only for an organisation that has configured its own AI provider entry: there is no fremverk-held key and no fallback, so without a Customer-configured provider the AI fix is not available. It applies only to a curated set of SAST rules, and only when a User asks for a fix to a specific finding. The request sent to the Customer\u0026rsquo;s chosen AI vendor contains the rule\u0026rsquo;s description, the scanner\u0026rsquo;s message and the lines of code around the finding; the vendor\u0026rsquo;s answer is accepted only as a small change at the finding\u0026rsquo;s location, which is re-scanned and proposed as a pull request in the Customer\u0026rsquo;s own repository for a User to review. fremverk does not retain the request, the answer or the proposed change outside that pull request; the audit log records which finding, which provider and the token counts, not the content.\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.\nB.9 Customer-chosen upstream registries (dependency proxy — not Sub-processors) # The dependency proxy fetches container images and packages from upstream registries on the Customer\u0026rsquo;s instruction. The Customer enables the proxy for its organisation, and a User names the upstream registry and the artifact in each pull. The upstreams are a fixed list of public registries and repositories (currently, for container images: Docker Hub, GitHub Container Registry, Quay, Microsoft Container Registry, the Kubernetes registry, Amazon ECR Public and the Red Hat registries; for packages: npm, PyPI, Maven Central, nuget.org, the Go module proxy and its checksum database, crates.io, the Red Hat Universal Base Image package repositories, and the Helm chart repositories of prometheus-community, Grafana, Jetstack and ingress-nginx, several of which serve their charts from GitHub); Apart from the registry and module hosts the Customer designates under Customer-designated registry and module hosts below, fremforge never fetches from an address the Customer supplies. Several of these registries are operated by US-incorporated companies.\nAn upstream registry is not a sub-processor of fremverk under Article 28:\nThe Customer chooses whether to use the proxy and which upstream each artifact comes from. fremverk does not appoint, vet or contract with the upstream on the Customer\u0026rsquo;s behalf. The upstream receives a request from fremforge\u0026rsquo;s IP address for the named artifact. It does not receive the identity or IP address of the User who pulled. The Customer may store its own credential for an upstream, issued under its own agreement with that registry. Some upstreams require one (Docker Hub, and the Red Hat registries that require an account). For others the Customer may add one to reach its own private content (GitHub Container Registry and Quay), and every pull from that registry then uses it. fremverk encrypts the credential at rest, never displays or logs it, and sends it only to that registry when fetching for that Customer. The registry then identifies the Customer\u0026rsquo;s own account, and that relationship is governed by the Customer\u0026rsquo;s agreement with the registry, not by this DPA. Content fetched with a Customer\u0026rsquo;s credential is cached for that Customer\u0026rsquo;s organisation only and is never served to another organisation. The Customer may switch the proxy off, or remove a stored credential, at any time. Customer-designated registry and module hosts. The Customer\u0026rsquo;s organisation owners may switch this on and store a credential for a private container registry or git module host of the Customer\u0026rsquo;s own choosing. The Customer limits the credential to read access, and fremforge only reads with it: fremforge\u0026rsquo;s security scanners use it, only on scans of the Customer\u0026rsquo;s own organisation, to read from that host the container images and infrastructure modules that the Customer\u0026rsquo;s repositories reference, in order to scan them for the Customer. The host is chosen by, and operated by or for, the Customer, and is not a sub-processor of fremverk. fremverk encrypts the credential at rest and never displays or logs it. It is sent only to the exact host the Customer designated, including a token endpoint on that same host; a redirect to any other host is followed without it. Content read with it is cached for the Customer\u0026rsquo;s organisation only and is never served to another organisation; when the credential is deleted, that content is deleted too, the cached copies within the following hour. Each credential carries an expiry of at most one year. The Customer may switch the feature off, after which no stored credential is used, or delete a credential, at any time. Storing, replacing and deleting a credential, switching the feature on or off, and each scan that used a credential are recorded in the Customer\u0026rsquo;s audit log.\nCached content is stored in T Cloud Public eu-de and served through the EU edge, by the sub-processors already listed in this Annex. If the Customer names a US-operated upstream, any US-extraterritorial-law exposure of that registry\u0026rsquo;s processing is governed by the Customer\u0026rsquo;s relationship with it; fremverk\u0026rsquo;s commitments in §11.2 and §11.3 cover the processing paths fremverk chooses and fremverk\u0026rsquo;s own sub-processors, which the proxy does not change.\nB.10 Customer-instructed secret validity checks (not Sub-processors) # fremforge\u0026rsquo;s secret scanning finds credentials committed to the Customer\u0026rsquo;s repositories. For a credential it finds, fremforge can check whether it is still valid, so the Customer can rotate the live ones first. For credentials that fremforge itself issues (frem.sh API tokens) the check runs inside fremforge and nothing leaves the Service. For credentials issued by a third party, the check is a request to that issuer, made only on the Customer\u0026rsquo;s instruction, under the following safeguards:\nA curated list, offered by fremforge. fremforge offers a check only for an issuer it has added to the Service, each with a fixed host, or a fixed list of hosts asked in order, and one fixed check. The Customer cannot enter a URL, host or request of its own, and fremforge never sends a credential anywhere but to the issuer it belongs to. The current issuers, the host each check contacts, the request it makes and each issuer\u0026rsquo;s operating jurisdiction are published in the documentation and shown in the setting. Opt-in per issuer, off by default. Each issuer is its own setting for the Customer\u0026rsquo;s organisation at /\u0026lt;org\u0026gt;/_admin/security/policies/push-protection (and the API). A check for an issuer runs only while the Customer has turned it on. Before it is turned on, the setting names the host the check contacts and whether the issuer is US-operated or EU-operated. An issuer that fremforge adds later is offered switched off, and fremverk never turns a check on for the Customer. What is sent. The credential itself, to its own issuer, in a single request to a read-only endpoint that reports whether the credential is valid, or, where the issuer has a fixed list of hosts, one such request to each host in order, stopping at the first that reports the credential valid (where the issuer requires it, the request is signed with the credential found, as for an identity call). No request creates, changes or deletes anything at the issuer, and fremforge offers no issuer that lacks such a read-only check. No other repository content, and no identity or IP address of a User, is sent. What is kept. Only the outcome (active, inactive or unknown) and the time of the check, on the finding. The credential is never stored by fremforge: it is read during the repository scan, passed once to fremforge\u0026rsquo;s api encrypted to a key created for that scan alone (the key is deleted when the scan ends), used for the check and discarded. It is never logged. Where it runs. In fremforge\u0026rsquo;s api in T Cloud Public eu-de, through fremforge\u0026rsquo;s outbound proxy, which admits only the hosts of the issuers fremforge offers, for this purpose. The scanning components that read the Customer\u0026rsquo;s repositories have no network access to the issuers. An issuer contacted for a validity check is not a sub-processor of fremverk under Article 28:\nThe Customer chooses whether to turn each check on, and which issuers. fremverk does not appoint, vet or contract with the issuer on the Customer\u0026rsquo;s behalf. The issuer receives a credential it issued itself, under its own agreement with the Customer (or with whoever holds the credential), and answers whether it is valid. The relationship between the Customer and that issuer is governed by their own agreement, not by this DPA. The Customer may turn any check off at any time; doing so also removes the stored outcomes for that issuer. Turning a check on causes a new scan of the Customer\u0026rsquo;s repositories\u0026rsquo; history, because a credential\u0026rsquo;s value exists only while a scan reads it. If the Customer chooses a US-operated issuer, any US-extraterritorial-law exposure of that issuer\u0026rsquo;s processing is governed by the Customer\u0026rsquo;s relationship with it; fremverk\u0026rsquo;s commitments in §11.2 and §11.3 cover the processing paths fremverk chooses and fremverk\u0026rsquo;s own sub-processors, which these checks do not change.\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 Public 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 Public (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 Public 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 Public 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\u0026rsquo;s shared connectivity stack). §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 Public 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; fremverk\u0026rsquo;s internal supplier register 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 Public 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. 1.16 2026-06-16 Editorial — pre-launch state, no §10.2 notification required. Brand-rename sweep: all references to the prior product names Open Telekom Cloud and T Cloud (the Deutsche Telekom sub-processor at Annex B §1) updated to the rebranded product name T Cloud Public per Deutsche Telekom\u0026rsquo;s 2026-06-09 marketing-site rebrand (public.t-cloud.com → www.t-cloud-public.com). No change to the underlying legal entity (Deutsche Telekom AG / T-Systems International GmbH operating the OTC service), the operating jurisdiction (Germany), the data residency (eu-de), the certifications, the sub-processor chain, or any Customer-facing obligation. Identifier strings preserved as-is: the OpenTofu provider (opentelekomcloud/opentelekomcloud), env-var names (OTC_AK / TCLOUD_AK), prose abbreviation OTC, and the live domain open-telekom-cloud.com are unchanged — they\u0026rsquo;re product/API contracts, not brand text. Suppliers register at fremverk\u0026rsquo;s internal supplier register updated in lockstep. 1.17 2026-07-01 Go-live / GA — pre-launch Sub-processor-notification carve-out ENDED. fremverk exited the pre-launch state at go-live on 2026-07-01 (self-serve signup opened; first paying Customer). The §10.2 pre-launch carve-out — which waived the direct-email notification channel while there were zero paying Customers — has lapsed; pre_launch_paying_customers set false in fremverk\u0026rsquo;s internal supplier register. All Annex B / Sub-processor changes now follow the full dual-channel §10.2 notification (≥30 days advance, direct email to the billing contact-of-record + public posting to the trust page and lists.frem.sh). This is the cutover-recording version bump the §10.2 carve-out clause anticipated. No change to data categories, residency, the sub-processor list, or any other Customer-facing obligation — this bump records the notification-regime cutover only. Customers notified per §14; this GA notification is the canonical delivery record. 1.18 2026-08-02 Annex A.9 — cross-region DR mechanisms corrected to what actually runs. No commitment changed: the ≤ 7-day cross-region RPO for repository content and object-store payloads is unchanged, and is now met with a large margin on both paths. What changed is the DESCRIPTION. (a) OBS — A.9 named \u0026ldquo;OBS Cross-Region Replication\u0026rdquo;. CRR was removed from the estate on 2026-08-02 because it cannot deliver: OTC documents that buckets with WORM enabled do not support cross-region replication (obs_03_0003), and the 3-year immutable audit archive is exactly such a bucket; on the remaining buckets every object reported replication status FAILED. Replication is now performed by a fremverk-operated daily copy-if-absent sweep into eu-nl, independently verified per-object each night. Verified on the day of change: 13 bucket pairs reconciled, including 123,726 audit-archive objects and 21,718 objects of repository content. (b) SFS Turbo — A.9 said \u0026ldquo;weekly snapshots\u0026rdquo;; the live posture is CBR backups approximately every six hours replicated continuously to the eu-nl DR vault (302 GB against a 307 GB source at time of writing). The text understated a mechanism that was working. Net effect is favourable to Customers: observed recovery points are hours rather than days, and the OBS half of this commitment is met for the first time. No change to data categories, residency, the sub-processor list, or any other obligation; Annex B unchanged. Recorded as an Annex A technical-measures update. Notification determination: delivered through the in-product acknowledgement channel (the platform surfaces the version change to every tenant admin and records acceptance per tenant); no separate §10.2 dual-channel notice issued. §10.2\u0026rsquo;s 30-day advance dual-channel route governs Sub-processor changes, and this is not one — Annex B is unchanged, no sub-processor, data category, residency or Customer obligation is affected. The only substantive movement is favourable: the cross-region RPO commitment for object-store payloads is now met, where the mechanism previously named could not deliver it for the WORM archive at all. 1.19 2026-08-03 §Data portability aligned with what the export actually produces. The clause promised \u0026ldquo;tarballs for LFS objects and package-registry artifacts\u0026rdquo;; the export delivers machine-readable inventories (identifier, size, path) sufficient to re-hydrate those objects elsewhere, with the payloads retrievable from the Service and their transfer covered by migration assistance. The JSON category is also now enumerated precisely (issues, pull requests, comments, labels, milestones, releases, repository metadata, audit logs) and stated as newline-delimited. This narrows a stated commitment and is notifiable under §Changes to this DPA. Occasioned by an operator audit on 2026-08-03 which produced the first end-to-end export and found it contained repository bundles and audit logs only; the missing JSON categories were implemented the same day, and the LFS/package wording was corrected here rather than left overstated. 1.20 2026-08-04 Annex A.10 — the personnel-training clause now describes the arrangement that exists. Two corrections, both found on 2026-08-04 while closing the AI Act Article 4 literacy item. (a) Record location. A.10 stated that training records are “held in fremverk\u0026rsquo;s HR-record OBS bucket (encrypted at rest with DEW KMS, EU-resident, scoped IAM)”. No such bucket exists — verified against live object storage in eu-de: 45 buckets, none matching HR, staff, training, people, person or employee, and none declared in fremverk\u0026rsquo;s infrastructure-as-code. The clause now names the actual location, the version-controlled internal governance repository, which is EU-resident on fremverk\u0026rsquo;s own T Cloud Public infrastructure, encrypted at rest and access-scoped. This is a stronger control than the one described, not a weaker one: every change to a record is attributable and reviewable, which an object-store blob cannot offer. (b) Training model. A.10 stated that personnel “receive annual security and data-protection training”, phrased as a course with a completion date and an assessment score. fremverk maintains currency continuously as a matter of professional practice rather than by sitting a periodic course, so the clause described a mechanism that was not the one in use — and no record of it existed. A.10 now commits to continuous currency across the same named curriculum, plus a dated annual attestation, which is auditable in a way that “we keep up to date” is not. The curriculum is unchanged except that Article 4 AI literacy is added to it. Record fields are restated to match (curriculum area and version, attestation or completion date, assessment score where one applies, next-review-due date); the five-year retention and the Customer-auditor access right under §12 are unchanged. Not materially adverse to the Customer, applying the test used in ToS 1.2: no Customer obligation is added and no Customer right is removed — the audit right and the retention period are untouched, and both limbs replace a described control with the control actually operated. It accordingly takes effect on publication. Recorded as counsel question 9 in fremverk\u0026rsquo;s internal EU AI Act conformity record §11, because a clause describing a control that was not in place is a disclosure question as well as a drafting one, and whether the historical gap needs notifying to existing Customers is a legal judgement rather than an engineering one. Neither limb changes a sub-processor, a data category, a location, or a transfer mechanism, so §10.2 sub-processor notification is not engaged. 1.21 2026-08-04 Annex A corrected where it described controls that were not the ones operated. Four findings from a deliberate sweep of Annex A, prompted by A.10 in v1.20 having been found only incidentally. (a) A.5 / A.4 / A.11 / A.12 — the hosted-CI-runner model. The annex described runners as per-job Cloud Container Instance serverless pods with a CCE-cluster fallback, non-root, all capabilities dropped and a read-only root filesystem. Runners in fact execute on ephemeral ECS virtual machines, and have done throughout: verified live (the controller\u0026rsquo;s ECS spawner is the only dispatch path, machine assignments are being written continuously, no cluster node carries the runner role, and the container-instance path was never enabled for this tenant). Two corrections in opposite directions, stated plainly rather than netted off. The isolation primitive is stronger than described — a virtual machine is a full hardware-virtualisation boundary, where a secure container is not. The in-guest hardening was overstated: a CI job has administrative rights inside its own machine, because it must be able to install packages and build images, exactly as it does on the major hosted-CI providers. The boundary that protects other tenants is the machine plus its per-instance Security Group, enforced at the hypervisor, and that is now what the annex commits to. Grouping is also per commit rather than per job — jobs of one run over one commit may share a machine, which is then destroyed; a different commit, repository or tenant always gets a different machine, so the cross-tenant boundary is unchanged. (b) A.9 — backup key management. A.9 said both backup tiers use \u0026ldquo;T Cloud Public-managed keys\u0026rdquo;, contradicting A.4 in the same annex. A.4 was right: verified live that the RDS instance encrypts with a fremverk-created DEW CMK which its snapshots inherit, and that each backup bucket in both regions carries its own CMK. A.9 understated the control and is corrected to match. (c) A.13 — pre-production environment. A.13 described production changes flowing through a fremforge-tst environment with a 24-hour soak. That environment does not exist — no infrastructure definition, no namespace, no deployment path, and fremverk\u0026rsquo;s own infrastructure code records \u0026ldquo;no dedicated non-prod fremforge env today\u0026rdquo;. A.13 now describes the control chain that has actually gated every production change: pull request, code-owner review, and branch protection requiring build, full test suite, static analysis, dependency scan, image scan, licence scan, signature verification and a schema-drift gate, with risk managed by feature flags and reversible migrations. Not materially adverse to the Customer, on the test used in ToS 1.2 and DPA 1.20: no Customer obligation is added and no Customer right is removed, and every limb replaces a described control with the control operated. On (a) specifically, the net security posture a Customer relies on is not reduced — the isolation boundary is stronger than the annex claimed, and administrative rights inside one\u0026rsquo;s own ephemeral runner is the industry-standard posture rather than a concession. Accordingly effective on publication. No sub-processor, data category, location or transfer mechanism changes, so §10.2 notification is not engaged. For counsel, alongside question 9: whether a published annex having described in-guest runner confinement that was never in place, and a pre-production environment that never existed, needs disclosing to existing Customers beyond this change log. As with A.10, that the correction is non-adverse does not settle whether the historical misdescription is disclosable. 1.22 2026-08-04 Audit-retention tables: the plan name enterprise_trial no longer exists. Migration 0164 renamed the plan_tier enum value to custom_trial; the retention tables in DPA A.7, SLA §3A and the ROPA were not updated and had named a plan for ~2.5 months that no system recognises. Now described as \u0026ldquo;the operator-provisioned custom trial\u0026rdquo; rather than by an internal identifier, so a future enum rename cannot make the contract wrong again — naming an implementation detail in a customer document is what created this. No retention value, floor or default changes; this is the same plan under an accurate description, so it is not materially adverse and takes effect on publication. Found while verifying the 365-day default itself, which turned out not to be implemented at all (fixed in monolith #1271 and backfilled across 7 tenants); the stale name was the smaller half of that finding. 1.23 2026-08-04 A.10 amended: the personnel-currency attestation is given at organisation level by fremverk\u0026rsquo;s chief executive on a dated record, rather than as a separate per-staff attestation held for every member of personnel. Unchanged: the curriculum itself, its annual review, the five-year retention period, the storage location, Customer auditor access under §12, personnel vetting, and confidentiality undertakings. Rationale: attestation per named person does not scale at fremverk\u0026rsquo;s size, and the previous wording promised per-staff records that were not in fact held for all personnel — so this aligns the Annex with the operating model rather than reducing a control. Assessed as not materially adverse under the Terms §1.2 test: no curriculum area, retention period or audit right is narrowed, and the substantive commitment (personnel are current, and it is evidenced on a dated record available to an auditor) is unchanged. Disclosed via this change log per §14. Operator determination; superseded if counsel disagrees. 1.24 2026-08-04 Annex A.9 DR retention corrected to per-surface figures. The Annex stated 13-month cross-region retention for both object-store payloads and repository content. That was correct for OBS and wrong for repository content: the SFS Turbo CBR vault policies keep the last 30 daily backups (day_backups = 30, max_backups = 30) locally and cross-region. Corrected to state 30 days for repository content and 13 months for OBS. Operator decision to correct the document rather than extend CBR retention: a 13-month snapshot window on SFS Turbo is a standing cost line, and 30 days covers the realistic recovery cases. Adverse on the ToS §1.2 test in the recoverability direction — a Customer previously told repository content was restorable from 13 months back is restorable from 30 days — so this row is the disclosure, and the RDS carve-out already in this Annex is unaffected and remains accurate. 1.25 2026-08-04 Annex A.2 — the edge Web Application Firewall described in this Annex is not enabled, and has not been for the whole period any Customer has been under this DPA. A.2 stated: \u0026ldquo;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.\u0026rdquo; Measured 2026-08-04 across every pull zone on fremverk\u0026rsquo;s CDN account: each fremforge surface runs Shield at the Basic tier with the WAF disabled (planType: 0, wafEnabled: false) — the Forgejo/Git zone, the API zone, and the marketing, documentation, status and trust sites alike. Exactly one zone on the account has a WAF enabled, and it is api.fremverk.com, fremverk\u0026rsquo;s own billing and operator API, which is not a Customer surface. History, stated plainly: the Forgejo and API zones did run Shield Advanced with the WAF on — verified 2026-05-03 — and were deliberately downgraded to Basic on 2026-05-09 because the OWASP Core Rule Set flagged ordinary Git protocol bodies, Forgejo asset and diff URLs, and every API form-body surface, so that enabling it path-by-path left almost nothing protected while breaking legitimate Git operations. Go-live was 2026-07-01. No paying Customer has therefore ever been served by an edge WAF, and this Annex has misdescribed the posture for that entire period. A.2 now states the actual arrangement: Shield Basic DDoS protection in Block mode on every public surface, per-IP rate-limiting edge rules, and the WAF deliberately not enabled, with the reasoning and the application-layer controls fremverk relies on instead named explicitly. Adverse on the ToS §1.2 test, in the edge-filtering direction — a Customer whose own risk assessment credited an edge WAF must now read this Annex without one — so this row is the disclosure, and unlike the corrections at 1.21 and 1.23 it is not offset by a stronger control in the same place: the compensating controls are real and are listed, but they are application-layer, not edge-layer. The true posture was already published, on the trust page since its v1.3 of 2026-05-08 (\u0026ldquo;Shield Basic at launch, not Shield Advanced\u0026rdquo;, with the false-positive reasoning); this Annex simply contradicted it, so a Customer reading both fremverk documents was given contradictory statements about the same control. The ROPA\u0026rsquo;s technical-measures row carried the same wording and is corrected in lockstep. Two engineering artefacts that had propagated the same claim are also corrected: a bunny_shield_advanced variable defaulting to true and described as \u0026ldquo;matches the security baseline\u0026rdquo;, which was referenced by nothing at all, and three comment blocks in the Forgejo edge configuration still asserting the pre-downgrade Advanced posture directly above the resource setting tier = \u0026quot;Basic\u0026quot;. No sub-processor, data category, residency or transfer mechanism changes, so §10.2 notification is not engaged. For counsel, alongside question 9 and the note at 1.21: whether an Annex having described an edge WAF that was not enabled at any point during the paying-Customer period requires disclosure to existing Customers beyond this change log. Of the three misdescriptions found in this sweep this is the one most likely to have been relied upon, because an edge WAF is a control a Customer\u0026rsquo;s own security questionnaire commonly asks about by name. 1.26 2026-08-05 Annex A.9: tenant-initiated audit-log exports are excluded from the 13-month DR tier, and the Annex did not say so. A.9 stated without qualification that \u0026ldquo;object-store payloads (OBS) carry 13-month (395-day) cross-region retention to eu-nl\u0026rdquo;. Cross-region replication of the export bucket was switched off on 2026-08-04 (platform-foundation #521) and the DR twin destroyed, so export bundles are an object-store payload with no cross-region copy: they live 7 days in-region in the signed download bucket and are then purged, exactly as the export row in A.7 and the privacy notice already said. For roughly one day this Annex therefore over-stated DR coverage for one surface, and the over-statement was introduced by fremverk\u0026rsquo;s own change rather than inherited. Not adverse to the Customer on the ToS §1.2 test — no obligation is added and no right removed, and the shortened path is the one the Customer was already told about for exports; the correction removes a promise fremverk had briefly made about holding Customer data longer, which is favourable rather than adverse. Effective on publication. Why exports are excluded, stated so the decision is reviewable: a signed export is reproducible on demand from the audit log it is derived from, so a sealed 13-month second copy would extend the life of Customer data far beyond the 7-day window published for it, for no recovery benefit. The privacy notice carried the identical sentence and is corrected in lockstep at 1.13. Found by asking what the previous day\u0026rsquo;s DR change had made untrue — the same question that produced 1.24 and 1.25, and it is now the third time it has returned a real answer. 1.27 2026-08-05 Annex A.3 said Forgejo site-admin was \u0026ldquo;break-glass only, limited to two local accounts\u0026rdquo; and that \u0026ldquo;no super-admin tokens are used in normal operation\u0026rdquo;. There are FIVE site-admin accounts and four of them are service bots that use the role continuously. Enumerated live: fremforge-admin (the break-glass account — one, not two), plus fremforge-monolith-bot, fremforge-runner-bot, fremforge-bot and fremforge-scan-bot. ADVERSE on the ToS §1.2 test, and the most consequential correction in this sweep: standing super-admin service accounts are precisely what a security questionnaire asks about, the previous wording denied their existence in terms (\u0026ldquo;no super-admin tokens \u0026hellip; in normal operation\u0026rdquo;), and the MFA and on-call-paging controls the clause offered as compensating apply to interactive login only — a token-authenticating bot triggers neither. Wrong in both directions: there is one break-glass account rather than the two claimed, and four undisclosed standing admins. A.3 now names each bot, its function, why the role cannot be narrower (these functions act across every tenant and Forgejo\u0026rsquo;s permission model cannot express that below site-admin), and states plainly that fremverk treats this as an accepted risk rather than a control — the mitigation is per-function token minting and per-owner credential scoping on the scanner, not a reduction of the role. For counsel, with the 1.25 edge-WAF question: an access-control clause that denied the existence of standing super-admin credentials is the strongest candidate yet for disclosure beyond a change log, because it is the class of statement a customer\u0026rsquo;s own security review is most likely to have relied on. Found by auditing A.3\u0026rsquo;s qualitative claims after the quantified sweep was complete — the numbers in Annex A had all been checked by then, and this was in the prose. 1.28 2026-08-05 Annex A.5 stated that per-organisation isolation was \u0026ldquo;enforced by automated nightly ACL smoke tests via FunctionGraph\u0026rdquo;. That test does not exist and never did. Verified in three directions before recording: all 21 FunctionGraph functions enumerated (none is an ACL test), all 136 in-cluster CronJobs enumerated (none verifies tenant ACL isolation), and the phrase \u0026ldquo;ACL smoke\u0026rdquo; occurs nowhere in any .tf, .py or .ts in the workspace — only in fremverk\u0026rsquo;s internal planning documents, in this Annex, and in an unpublished internal blog draft (originally recorded here as \u0026ldquo;a public engineering blog post\u0026rdquo;, corrected 2026-08-05 — the draft has never been published, so the claim was never publicly visible; no version bump, as no commitment or control description changes). This is a different and more serious class than the preceding corrections: 1.21, 1.25 and 1.27 were inaccurate descriptions of controls that existed, whereas this was a detective control that was promised and never built, asserted in a contractual annex as operative. It is also the isolation claim, which is the single most load-bearing statement in a multi-tenant Git platform. What is and is not affected: the isolation itself is real and unchanged — Forgejo\u0026rsquo;s permission layer resolves every API and Git request, and no cross-tenant exposure is implied by this correction. What was absent is fremverk\u0026rsquo;s independent verification that no organisation\u0026rsquo;s ACL had drifted; that would today be noticed by the affected Customer rather than by fremverk. A.5 now describes the isolation mechanism accurately, states the absence of a scheduled re-verification in terms, names the compensating controls that do exist without presenting them as substitutes, and commits to updating this Annex when a cross-tenant probe is operating and not before. Also in this revision, Annex A.6 corrected in three respects. It named a Forgejo organisation mirrors/ that returns 404 and has never existed (the real mirrors are twelve organisations, one per upstream namespace); it attributed mirror sync to a weekly forgejo-actions-mirror CronJob that does not exist (Git sources mirror via Forgejo\u0026rsquo;s native pull-mirror every 8 hours, OCI images via swr-mirror every 6 hours — so the true cadence is materially fresher than claimed); and it asserted that runners \u0026ldquo;pull from these mirrors only\u0026rdquo; and that \u0026ldquo;no fremforge build path resolves DNS or fetches code from github.com \u0026hellip; or any other US-jurisdiction host\u0026rdquo;, which overstated the position. The runner-base / runner-toolchain image builds fetch language toolchains directly from 13 upstream origins including 15 GitHub release URLs, packages.microsoft.com, dl.google.com and awscli.amazonaws.com. That exception is deliberate, bounded to the operator build context with no Customer data present, SHA-256-pinned with verification after download, and behind the strict egress allowlist — but it was not disclosed, and the paragraph that enumerated operator-internal egress exemptions omitted the largest one. The Customer-data-path commitment is unaffected and restated. Found by auditing A.5 and A.6\u0026rsquo;s qualitative claims; three of the four defects in this revision were invisible to every existing gate. 1.29 2026-08-05 Annex A.9 promised Customers a post-drill disaster-recovery report, and no such report has ever existed. A.9 stated each DR test was \u0026ldquo;documented as a runbook execution + post-drill report\u0026rdquo; with an \u0026ldquo;executive summary available to Customers under NDA on written request\u0026rdquo;. Verified three ways: the runbooks/drill-archive/ directory intended to hold them contains only its README, no file matching the documented naming pattern exists anywhere in fremverk\u0026rsquo;s repositories, and version-control history contains no record of one ever being committed. A Customer exercising that clause would have received nothing. The drills themselves were and are real — the RDS restore drill runs monthly, the WORM read-back drill weekly, backup-integrity verification monthly and backup-presence verification daily, each recorded in the platform log stream with alarms on failure. What did not exist was the document describing them, which is the same shape as the A.5 correction in 1.28: the substance real, the attestation absent. Two changes follow. The report commitment is withdrawn rather than left standing, with the position stated in terms and Customers requiring an attested restore report directed to the Order Form where it can be agreed as a specific deliverable. And the tested-at-least cadence is raised from annually to quarterly, resolving a three-way contradiction in which this Annex and the internal runbook said annual (softened from quarterly on 2026-05-08) while the drill archive\u0026rsquo;s own README still specified quarterly reports. Quarterly is now the contractual floor and is satisfied by the existing automation, which already exceeds it — so the raised commitment adds assurance without adding manual work. Assessed NOT adverse: the correction withdraws an undeliverable promise while simultaneously strengthening the cadence, and no Customer has requested a drill report. Found by auditing the qualitative claims of the seven Annex A sections not previously swept; it was the only finding among them. 1.30 2026-08-05 Annex A.8 stated patching targets materially weaker than the ones fremverk publishes, while simultaneously incorporating the published page into this annex by reference — so the annex contradicted itself and the stricter numbers were the ones a Customer could rely on. A.8 set out a phased model: \u0026ldquo;Phase 1\u0026rdquo; targets of Critical 72h / High 7d / Medium 14d under commercially reasonable efforts until 2027-Q1, with Critical 48h / High 72h / Medium 7d as \u0026ldquo;Phase 2\u0026rdquo; contractual targets from then. The public trust page published the Phase 2 figures with no phase distinction and no efforts qualifier, as \u0026ldquo;fremforge commits to\u0026rdquo;. Same class as the 1.25 edge-WAF correction — the trust page asserting something the contract did not — but sharper, because patch windows are numeric and dated. Resolved in the Customer\u0026rsquo;s favour: the published targets are adopted as contractual and in force now, the phased model is withdrawn, and the single table here is identical to the trust page. fremverk is now bound to 48-hour Critical patching before the funded 24/7 on-call rotation that the phasing existed to await — an accepted operational cost, taken deliberately rather than narrowing a published promise. Assessed NOT adverse to Customers: every target moves in their favour and none is weakened. Paired changes in SLA §6.2 and Terms §10 remove the same phasing. The incorporation-by-reference clause is deliberately KEPT — it is a real Customer benefit and was only hazardous while the documents disagreed. Found by auditing A.8 for a cross-document gate after A.1 and A.9; A.8 had been recorded as ungatable. 1.31 2026-08-06 Annex A.5\u0026rsquo;s isolation-verification clause restored, after the control it describes was built and observed working. DPA 1.28 removed a claim that isolation was \u0026ldquo;enforced by automated nightly ACL smoke tests via FunctionGraph\u0026rdquo; — a detective control that had never existed — and stated plainly that no scheduled re-verification ran. That gap is now closed: tenant-acl-isolation-probe runs hourly, asks Forgejo as an unauthenticated caller whether any Customer organisation or repository list is readable, and raises a Critical alarm to on-call if one is. The clause was restored only after a clean sweep was observed in production on 2026-08-06 — 8 organisations checked, 0 readable — not when the probe was written, deployed or scheduled. That sequencing is the point: 1.28 exists because a control was described before it worked. The probe also asserts every run that it can reach Forgejo, and reports UNKNOWN rather than a pass when it cannot, so a probe that silently breaks alarms on itself rather than reporting clean — a property that caught two defects in the probe\u0026rsquo;s own first two runs before either could produce a false assurance. Scope is stated in the negative as well as the positive: authenticated cross-tenant access and the public CDN edge are not separately probed, and A.5 now says so rather than leaving a reader to assume the broadest reading. Assessed NOT adverse: this restores an assurance that 1.28 withdrew, on evidence, and narrows nothing. 1.32 2026-08-06 §6A asserted without qualification that the Service\u0026rsquo;s AI features \u0026ldquo;do not retain Customer Content in model weights or training corpora\u0026rdquo;. For Customer-configured AI vendors that was a statement fremverk had no standing to make. The prohibition in §6A binds fremverk and fremverk\u0026rsquo;s sub-processors, which fremverk controls by contract. The AI vendors that actually receive repository content on this path are neither: the supplier register classes them customer_processor — the Customer chooses the vendor, contracts with it directly and pays it directly, and fremverk encrypts the API key and forwards the request as a conduit. Whether that vendor trains on the content is governed by the Customer\u0026rsquo;s own agreement with it, and some vendor tiers permit training by default. Verified that fremverk applies no technical control on that path either — no zero-retention or no-training flag is set on the outbound calls — so the sentence was neither contractually nor technically supported. Same shape as the 1.25 edge-WAF and 1.28 A.5 corrections: an unconditional promise about behaviour the system does not control. §6A now states the scope in both directions and points Customers who need a contractual no-training guarantee to their vendor\u0026rsquo;s enterprise or zero-retention tier, or to Enterprise-on-Demand where fremverk contracts with the vendor directly and the prohibition does apply. Assessed ADVERSE and flagged for counsel with the 1.27 and 1.28 items: it narrows what a Customer could reasonably have read as an absolute guarantee, on the one path where repository content leaves the platform to a third party. Found by sweeping the DPA body after Annex A and Annex B were closed. 1.33 2026-08-06 §11A.1 directed government- and law-enforcement-access notice to a \u0026ldquo;designated security contact\u0026rdquo; with no fallback, and no mechanism existed to designate one. §8.1 names the same contact for breach notice but carries a fallback — \u0026ldquo;or, where none has been designated, the Customer\u0026rsquo;s account-of-record administrator\u0026rdquo;. §11A.1 did not. Verified against the data model: the only contact field on a tenant is billing_contact_email; there is no security-contact field, no UI to set one, and no documented designation process. So the single most consequential notice in this DPA — that a government authority has demanded the Customer\u0026rsquo;s data — named a channel that could not be populated and had no alternative. §11A.1 now carries §8.1\u0026rsquo;s fallback verbatim, and a new paragraph states how designation actually works today (written notice to compliance@frem.sh, recorded against the tenant) and that the account-of-record administrator is the default recipient, so no notice in this DPA depends on a channel the Customer was never asked for. Assessed NOT adverse: it makes an undeliverable notice deliverable and widens no obligation. A self-service security-contact field remains the better end state and is not claimed here. Found by sweeping the DPA body; the asymmetry between two clauses naming the same contact is what surfaced it. 1.34 2026-08-06 Corrects an error introduced by 1.33: the DPA said fremverk exposes no self-service field for designating a security contact. It does. The field is the Operational alerts email in the organisation\u0026rsquo;s billing and contact settings (technical_admin_email), which already routes operational and security notices and falls back to the billing contact-of-record when unset — implemented in services/email-routing.ts and settable by the Customer without contacting fremverk. 1.33 reached its conclusion by searching for a field named \u0026ldquo;security contact\u0026rdquo;, finding none, and inferring absence; the capability exists under an operational name. The practical effect of the error was to send Customers to compliance@frem.sh for something they can set themselves in two clicks, and to understate a control fremverk actually has. §8.1 and §11A.1 now name the real mechanism, and the fallback ordering is unchanged. Assessed NOT adverse: it corrects an understatement and removes a manual step. 1.35 2026-08-15 Annex A.1 no longer prints the supplier register\u0026rsquo;s next-review date; it cites the register instead. A.1 carried next review 2026-08-13, duplicating a value the register owns. The quarterly reviews were stamped on 2026-08-14, moving next_review_due to 2026-11-09, and the contract was left asserting a date that had passed — caught by the annex-a1-cert-evidence-matches-the-supplier-register claim gate. Referencing rather than copying removes the drift at every future quarterly review, not just this one. No term, obligation or assurance changes, and the certifications A.1 asserts (ISO 27001 2025, SOC 2 Type II 2023 for Bunny CDN) are unchanged. 1.36 2026-08-20 Annex B named the CDN sub-processor as an entity that does not exist. Annex B row 2, the Annex A.3 sub-processor summary, the Annex A.2 edge-node description, the §11 CLOUD-Act exposure statement and the Annex A.6 DNS note all called this sub-processor \u0026ldquo;Bunny CDN d.o.o.\u0026rdquo;. There is no such company. The sub-processor is BunnyWay d.o.o. (full registered name BUNNYWAY, informacijske storitve d.o.o., Slovenian reg. no. 7297513000, VAT SI99251558, registered seat Dunajska cesta 165, 1000 Ljubljana), verified 2026-08-20 against the AJPES business register, Bunny\u0026rsquo;s own privacy notice and its trust centre, all five references corrected. \u0026ldquo;Bunny CDN\u0026rdquo; remains correct as the product name and is unchanged where it is used that way. Why this mattered in practice: a Customer running supplier due diligence on the name printed in this Annex — the ordinary response to an Article 28 disclosure — would search the Slovenian register and find nothing, for the sub-processor that terminates TLS on every fremforge surface. So the defect was not cosmetic: it defeated the verification the disclosure exists to enable, and it had been present since Annex B was first published. Not adverse on the ToS §1.2 test — the same real company, correctly named, with no change to residency, data categories, purpose, certifications or transfer mechanism, so §10.2 sub-processor notification is not engaged and no objection right arises. Found while recording Bunny\u0026rsquo;s executed DPA in fremverk\u0026rsquo;s internal supplier register, which had the entity right; the register was the correct side of the disagreement and this contract was the wrong one. The Product Privacy Notice carried the same error in two places and is corrected in lockstep at its v1.17. 1.37 2026-10-03 Package payloads included on request (§9). The export of Customer Content could previously carry package-registry inventories only; payloads had to be fetched from the Service or moved with transition assistance. A Customer may now request the payloads themselves: every file of every package version its organisation owns, delivered as a separate archive next to the export bundle, covered by the bundle\u0026rsquo;s signed manifest with a SHA-256 per file, container images as OCI image layouts. Self-service up to 50 GiB of package payloads; above that, fremverk performs the export with the Customer (assisted path). The separate archive is deleted 8 days after the export is produced; the download link is valid for 7. This widens what fremverk provides and narrows nothing, so it is not a materially adverse change and takes effect on publication. LFS payloads are unchanged (still retrievable from the Service and covered by transition assistance). 1.38 2026-10-03 §9 — post-termination retention for export raised from 60 to 90 days (Terms 1.11 §16.5). Every later step moves by the same 30 days: hard deletion from primary storage within 30 days after the 90-day window, live-tier backup purge complete within 150 days of termination (was 120), the accounting-subset pseudonymisation at the 120-day primary-deletion mark (was 90), and Annex A.9\u0026rsquo;s live-tier purge timeline 150 days. The DR-tier schedules and the 3-year audit archive are unchanged. Follows 1.37 (§9 package payloads), which it does not alter. Not materially adverse under ToS §17: it lengthens a Customer right and takes nothing away; the Customer may still export, and ask for deletion, earlier. Effective on publication, no notice period. Paired with monolith, where the deletion clock (READONLY_GRACE_DAYS) moves from 60 to 90 days, so the code keeps data for the period this document promises. 1.39 2026-10-04 Internal implementation names replaced by descriptions; the edge protection described as what it does. §11.1 and Annex A.3 named the identity provider\u0026rsquo;s cloud project; they now say it runs in a dedicated, isolated cloud project. Annex A.6 named the container-registry namespace and the mirroring CronJob; it now describes them, with the same cadences. Annex A.2, A.3, A.4, A.6, A.7, A.9 and B.7 use plain descriptions where they named in-cluster components, CronJobs, an alerting topic, a runtime secret or a runbook file. Annex A.2 now describes the edge protection by what it does (DDoS mitigation and per-IP rate limiting at the edge) rather than by the vendor\u0026rsquo;s plan tier, and states plainly that no Web Application Firewall is enabled at the edge on any fremforge surface, unchanged in substance from 1.25. Annex B and B.6 no longer list WAF among BunnyWay\u0026rsquo;s processing activities, which they did although no WAF has been enabled on any fremforge surface (see 1.25). No control, commitment, cadence, sub-processor or retention period changes, so this is a clarification, not materially adverse under ToS §17, effective on publication. 1.40 2026-10-04 Effective 2026-11-03. Materially adverse. Announced by notice 999f05a2-d9ea-4be3-a423-59fd1e9354b0 on 2026-10-04 (as dpa 1.39). The 2026-10-04 notice announced this change as dpa 1.39: those numbers were taken the same day by a clarification (#145, internal names become descriptions), which was already published when the notice went out, so this change carries the next number. Same change, same effective date. §9 and A.9: backups described as they operate. Deleted data can remain in the encrypted live-tier backups (RDS daily snapshots and WAL, kept 90 days, keep_days = 90) for up to 90 days after primary deletion and expires with them; the backups are used only to recover the platform. Total from termination up to 210 days (was 150). A.9\u0026rsquo;s live-tier line and the DR-restore re-deletion sentence follow. No infrastructure change: this describes the backup lifecycle and the rota that operate. 1.41 2026-10-04 Effective 2026-11-03. Materially adverse. Announced by notice effac7b9-0802-48f2-af88-f11fc4462fa6 on 2026-10-04 (as dpa 1.41). Annex A.5, A.6, A.7 and A.9 — exact implementation intervals replaced by bounds the platform meets with headroom. Audit-chain anchoring \u0026ldquo;every 2 minutes\u0026rdquo; becomes at least every 5 minutes; it runs every 2 minutes. Chain verification \u0026ldquo;hourly\u0026rdquo; becomes at least hourly. The tenant-isolation probe \u0026ldquo;on an hourly schedule\u0026rdquo; becomes at least hourly. Build-tooling mirrors, \u0026ldquo;8-hour\u0026rdquo; (Git) and \u0026ldquo;every 6 hours\u0026rdquo; (OCI), become at least every 12 hours. SFS Turbo backups, \u0026ldquo;approximately every six hours\u0026rdquo;, become at least every 12 hours. The OBS replication sweep and its per-object verification, \u0026ldquo;daily\u0026rdquo; and \u0026ldquo;nightly\u0026rdquo;, become at least daily. The RDS restore drill, backup-integrity verification and restore-readiness, \u0026ldquo;monthly\u0026rdquo;, become at least monthly. The WORM read-back drill, \u0026ldquo;weekly\u0026rdquo;, becomes at least weekly. Backup-presence verification, \u0026ldquo;daily\u0026rdquo;, becomes at least daily. Each bound is met by the schedule running today, and nothing runs less often. Materially adverse under ToS §17, because the stated anchoring and mirroring intervals are wider, so it takes effect on 2026-11-03, 30 days after the notice sent on 2026-10-04, with the §17 termination right. Until then version 1.39 applies, as it does for 1.40. 1.42 2026-10-05 Effective 2026-11-03. Widening only. Package SBOMs in the package payload export (§9). Each exported package file now comes with its software bill of materials. This widens what fremverk provides and narrows nothing, so it is not a materially adverse change and needs no notice. Its text contains 1.41, so it takes effect on 2026-11-03 together with 1.41; until then version 1.39 applies. 1.43 2026-10-06 Effective 2026-11-03. Widening only. Corrections to the email and CDN disclosures (§11.1, §11.2, §11.3, §12.1, Annex B), with no processing change; and more in the data export (§9). (a) Lettermint B.V. certification. Annex B said its certification evidence was pending, with a re-scope to operator/admin-only mail if none arrived by 2026-09-30. Lettermint has been certified to ISO/IEC 27001:2022 since 2026-08-21 and publishes the certificate, its Data Processing Agreement and its sub-processor list; Annex B and §12.1 now say so, and the re-scope clause is removed because its condition did not arise. (b) Lettermint\u0026rsquo;s backup provider is in Germany, not France. §11.1, §11.2, §11.3 and Annex B named OVHcloud SAS (France) as an upstream; Lettermint\u0026rsquo;s own list places OVHcloud backups in Germany, and its primary infrastructure is UpCloud in Amsterdam. Both are in the EU, the sub-processor is unchanged, and no data moves. (c) CDN access logs are now listed in §11.1 and Annex B. BunnyWay keeps pull-zone access logs (request metadata, client IP anonymised by default) for 3 days, stored and processed in Germany; fremverk copies them to T Cloud Public eu-de for 30 days. This processing already took place under the existing BunnyWay and T Cloud Public rows; it was not listed as its own data type. (d) More in the data export (§9). Every export now also carries, as newline-delimited JSON under the same signed manifest, the security-scan findings the Service holds for the organisation with their dismissals, the package-policy configuration, verdicts, download decisions and exceptions with their approvals, and the build-provenance and release attestations with the signature the Service holds for each. §9\u0026rsquo;s list of JSON files now also names the registry access log and the third-party component inventory, which the export already contained. This widens what fremverk provides. None of (a) to (d) adds a sub-processor, a location outside the EU, a data category or a retention period, or removes anything the Customer receives, so it is not a materially adverse change and needs no notice (§10.2 is not engaged). Its text contains 1.41 and 1.42, so it takes effect on 2026-11-03 together with them; until then version 1.39 applies. 1.44 2026-10-07 Effective 2026-11-06. Materially adverse. Announced by notice 5e419442-13b2-43cc-8236-1df67d517431 on 2026-10-07 (as dpa 1.44). Annex A.11 — how alerts reach on-call staff, stated as it operates. A.11 said alerts \u0026ldquo;route through T Cloud Public SMN to SMS/push for on-call staff\u0026rdquo;. SMS delivery from SMN was switched off on 2026-05-18 for cost, so since then every SMN alert, of every severity, has reached the on-call staff as email only. A.11 now says so: SMN alerts arrive as email, received as push email on the on-call staff\u0026rsquo;s phones, and send no SMS; separately, the external uptime checks in Annex B.7 alert by SMS when the api health endpoint, Forgejo, the identity provider or the alerting path\u0026rsquo;s own heartbeat stops responding. Annex B.7 now lists the sixth probe, on the alerting path\u0026rsquo;s heartbeat endpoint, which it had left out; like the other five it carries no Customer Personal Data. Detection sources, runbooks and post-incident commitments are unchanged. It removes a stated alerting channel, so it is materially adverse under ToS §17 (an amendment that reduces a commitment of fremverk) and a material change to Annex A, notified as Annex A requires; it takes effect 30 days after the notice, with the §17 termination right. Until then version 1.43 applies from 2026-11-03, and version 1.39 before that. 1.45 2026-10-07 Effective 2026-11-06. Materially adverse. Announced by notice 06068339-c7e1-4210-8c21-2344b66a19a7 on 2026-10-07 (as dpa 1.45). The dependency proxy: upstream registries the Customer chooses (new Annex B §B.9; §4.1, §11.2, §11.3, Annex A.6). The dependency proxy fetches container images and packages from public registries the Customer names, several operated by US-incorporated companies, and for Docker Hub and the Red Hat registry sends the credential the Customer stores for its own account. New §B.9, modelled on §B.8, states that these registries are chosen by the Customer and are not sub-processors, that they receive fremforge\u0026rsquo;s IP address and the artifact name but not the identity or IP address of the User, and how stored credentials are protected. §4.1 lists the stored credentials and pull records. §11.2 (no transfer outside the EU/EEA) and §11.3 (no CLOUD Act exposure) now apply to the processing paths fremverk chooses, with the proxy pointed to §B.9, and Annex A.6 names the proxy as the one exception to the runtime never fetching from US hosts. No new sub-processor. It narrows the scope of the §11.2, §11.3 and A.6 statements, so it is materially adverse under ToS §17 and a material change to Annex A, and takes effect 30 days after the notice, with the §17 termination right. It takes effect on the same day as 1.44, whose text it contains, so on 2026-11-06 version 1.45 applies and 1.44 is never in force on its own. 1.46 2026-10-07 Effective 2026-11-06. Widening only. Annex B §B.9 — credentials the Customer chooses to store. §B.9 said a credential is sent where an upstream \u0026ldquo;requires the Customer\u0026rsquo;s own account (Docker Hub; the Red Hat registry)\u0026rdquo;. The Customer may now also store its own credential for GitHub Container Registry and Quay, to reach its own private content, and for a second Red Hat registry that requires an account; with a credential stored, every pull from that registry uses it. §B.9 now covers any upstream for which the Customer chooses to store a credential, and names both cases. Every protection in §B.9 is unchanged: the credential is encrypted at rest, never displayed or logged, sent only to that registry when fetching for that Customer, and content fetched with it is cached for that Customer\u0026rsquo;s organisation only. A credential reaches a registry only if the Customer chooses to store one, so this adds an option and takes nothing away. It is not materially adverse under ToS §17 and needs no notice. Queued for 2026-11-06 with 1.45, whose text it contains: on that day 1.46 applies, and 1.44 and 1.45 are never in force on their own. 1.47 2026-10-08 Effective 2026-11-06. Widening only. §4.1 and Annex A.7 — the registry access log. The registry access log (one record per request to the Customer\u0026rsquo;s package and container registry, with the User\u0026rsquo;s login, client IP address and user agent) had no stated retention. Annex A.7 now states it: a per-tenant setting of 30 to 730 days; unset, the security-relevant audit-event retention (90 days standard; 365 for Enterprise-on-Demand, the custom trial and internal plans); daily deletion; nothing deleted under a legal hold; not part of the audit hash chain. §4.1 names registry requests among the usage data. It describes processing that already takes place, on the schedule it already runs, and gives the Customer a retention commitment it did not have, so it is not materially adverse under ToS §17. Queued for 2026-11-06 with 1.44 to 1.46, whose text it contains. 1.48 2026-10-10 Effective 2026-11-06. Widening only. Annex B §B.9 — the upstreams the dependency proxy can fetch from; Annex A.6 — npm in fremforge\u0026rsquo;s own image builds. §B.9\u0026rsquo;s fixed list of upstreams named the container registries, npm and PyPI. The proxy can now also fetch packages from Maven Central, nuget.org, the Go module proxy and its checksum database (proxy.golang.org, sum.golang.org), crates.io (index.crates.io, static.crates.io), the Red Hat Universal Base Image package repositories (cdn-ubi.redhat.com), and four Helm chart repositories (prometheus-community, Grafana, Jetstack, ingress-nginx; charts may be served from GitHub release assets). §B.9 now lists them. Each is fetched only when a User names it in a pull, from a fixed address, as for the existing upstreams. Every statement in §B.9 is unchanged: these upstreams are chosen by the Customer and are not sub-processors, they receive fremforge\u0026rsquo;s IP address and the artifact name but not the identity or IP address of the User, and none of the new upstreams takes a stored credential. No new sub-processor; §11.2, §11.3 and Annex A.6 already cover the proxy through §B.9. Separately, the list of operator-internal flows in Annex A.6 now names fremforge\u0026rsquo;s own image builds installing npm packages, through the dependency proxy, with a logged fallback to a fremverk-operated cache and then to registry.npmjs.org directly; no Customer data is present in those builds. An upstream is used only if the Customer chooses it, so the §B.9 change adds options and takes nothing away, and the A.6 change discloses an operator-internal flow that carries no Customer data. Neither reduces a right or commitment, so this is not materially adverse under ToS §17 and needs no notice. Queued for 2026-11-06 with 1.44 to 1.47, whose text it contains. 1.49 2026-10-10 Effective 2026-11-09. Materially adverse. Announced by notice 634f47e8-4e3e-4466-9b78-1bd4ffe6e663 on 2026-10-10 (as dpa 1.49), together with Terms 1.13, Privacy Notice 1.25, Cookie Policy 1.6 and the ROPA. §2, §4.1, Annex A.3 and the Annex B header note — SAML 2.0 single sign-on is not offered, and never was. §2 and §4.1 listed SAML claims and subject identifiers among the authentication data processed, and A.3 said Customer-side access is authenticated \u0026ldquo;via OIDC/SAML SSO\u0026rdquo;, citing a SAML documentation page. Measured 2026-10-10: the Forgejo release fremforge runs has no SAML authentication source, no fremforge patch adds one, the endpoint the SAML registration flow called answers 404, and the SAML assertion consumer URL answers 404, so the SAML registration flow could never complete and no SAML identifier has been processed. Each now says OIDC (including A.3\u0026rsquo;s Authentik paragraph and the Annex B note on Customer-chosen identity providers), and A.3 states that SAML is not offered. Adverse on the Terms §17 test: it removes an authentication option this DPA described, and an amendment that is adverse in any respect is adverse as a whole. The §2 and §4.1 changes alone narrow the data processed and are not adverse. No change to the processing that takes place, to sub-processors or to residency. 1.50 2026-10-13 Effective 2026-11-12. Materially adverse. Announced by notice 81ccd763-bc11-4bcd-a56b-bb12b3c92de9 on 2026-10-13 (as dpa 1.50), together with Privacy Notice 1.26. Annex A.7 and §9: the registry access log no longer records every request. Two kinds of routine CI request through the dependency proxy, made with a Forgejo Actions job token and allowed and answered without error, are no longer one record each. A package metadata read is not recorded (in practice since 2026-10-12). A download served from the proxy\u0026rsquo;s cache is counted per day, package version, repository and run in the pull census (since 2026-10-13), without login, client IP address or user agent. Those requests are therefore no longer in the access log\u0026rsquo;s SIEM delivery or in access-log.ndjson. §9 names the pull census, which the export already contains. Less personal data is processed; no new sub-processor, location, data category or retention. 1.51 2026-10-14 Effective 2026-11-12. Widening only. Annex B §B.8 — AutoFix AI fixes for SAST findings named among the features that use a Customer-configured AI vendor. §B.8 listed three AI integration features (AI PR review, Renovate explanations, the customer-callable /ai/complete). AutoFix\u0026rsquo;s AI fixes for SAST findings use the same Customer-configured AI vendor key model and are now named in that list, with a paragraph stating how they work: off unless the Customer turns them on; only with the Customer\u0026rsquo;s own provider entry, never a fremverk-held key, with no fallback; a curated set of SAST rules; one finding at a time on a User\u0026rsquo;s request; the request carries the rule description, the scanner\u0026rsquo;s message and the surrounding code; the result is a pull request in the Customer\u0026rsquo;s repository for a User to review; nothing is retained outside that pull request, and the audit log carries ids and token counts only. Every statement in §B.8 is unchanged, and the vendor remains the Customer\u0026rsquo;s processor, not a sub-processor. It describes a Customer-chosen option and takes nothing away, so it is not materially adverse under ToS §17 and needs no notice. Queued for 2026-11-12 behind 1.50, whose text it contains. 1.52 2026-10-18 Effective 2026-11-12. Widening only. Annex B §B.10 (new) — Customer-instructed secret validity checks; Annex A.6, §11.2 and §11.3 refer to it. fremforge can check whether a credential its secret scanning found in the Customer\u0026rsquo;s repositories is still valid. For frem.sh API tokens the check runs inside fremforge and nothing leaves the Service. For credentials issued by GitHub, GitLab.com, Amazon Web Services, Slack or Stripe, the check is one read-only request to that issuer, at a fixed host, made only while the Customer has turned that issuer\u0026rsquo;s check on (off by default). The credential is never stored; only the outcome and the time are kept. §B.10 states that these issuers are chosen by the Customer and are not sub-processors, in the same way as §B.8 and §B.9. Annex A.6\u0026rsquo;s commitment that the api never contacts US-jurisdiction hosts now names this as a second exception the Customer controls, next to the dependency proxy; §11.2 and §11.3 point to §B.10. Nothing happens unless the Customer turns a check on, and no right or commitment is reduced for a Customer who does not, so this is not materially adverse under ToS §17 and needs no notice. Queued for 2026-11-12 behind 1.50 and 1.51, whose text it contains. 1.53 2026-10-19 Effective 2026-11-12. Widening only. Annex B §B.10 — secret validity checks described by their mechanism and safeguards, not by a list of issuers; §11.3 and Annex A.6 follow. §B.10 named five third-party issuers and their hosts. It now states the rules every issuer is held to, the same way §B.8 does for AI vendors: a curated list offered by fremforge, each issuer with one fixed host and one fixed read-only check, never a URL, host or request the Customer enters; opt-in per issuer and off by default, with the host and the issuer\u0026rsquo;s operating jurisdiction (US-operated or EU-operated) shown before it is turned on; an issuer added later is offered switched off and is never turned on by fremverk; one read-only request carrying the credential only to its own issuer; the outcome and time kept, the credential never; only through the outbound proxy, which admits only the offered issuers\u0026rsquo; hosts. The list of issuers, hosts, requests and jurisdictions moves to the documentation and the setting itself. Every safeguard of 1.52 stays, the issuers remain the Customer\u0026rsquo;s choice and not sub-processors, and nothing reaches an issuer the Customer has not turned on, so this is not materially adverse under ToS §17 and needs no notice. Queued for 2026-11-12 behind 1.52, whose text it replaces in §B.10. 1.54 2026-10-21 Effective 2026-11-12. Widening only. Annex A.9 and §9 — Actions artifacts and CI run logs are excluded from the disaster-recovery tier, and the 13-month figure for object-store payloads is now true of the bytes, not just of the copy. (a) Until 2026-10-21 the cross-region sweep copied Actions artifacts and CI run logs into eu-nl with the rest of the repository object store, and that copy did not follow the Customer\u0026rsquo;s artifact-retention setting: an artifact the Customer\u0026rsquo;s setting deleted after a few days stayed in eu-nl for up to 13 months. Since 2026-10-21 they are excluded from the sweep, and the same day every copy already in eu-nl was permanently removed. Excluded for the reason given for exports at 1.26: an artifact or log is reproducible by re-running its workflow and lives only as long as the Customer chose, so a sealed 13-month second copy extends the life of Customer data for no recovery benefit. (b) The eu-nl buckets are versioned. Their lifecycle rule expired each copy at 395 days, but expiry only made it a non-current version, which the rule then kept for another 395 days, so the bytes of a copy could remain for up to about 26 months. The rule now removes a non-current version after one day (platform-foundation #1851, applied 2026-10-21), so every copy is permanently removed within 395 days plus one of being written, which is what this Annex has said since 1.24. Before this change no copy had yet reached its first 395 days, because the sweep started on 2026-08-02. Both changes shorten how long fremverk holds Customer data and add no obligation for the Customer, so this is not materially adverse under ToS §17 and needs no notice. The tenant-initiated exports sentence of 1.26 is unchanged. Queued for 2026-11-12 behind 1.53, whose text it carries. The privacy notice is corrected in lockstep at 1.27. 1.55 2026-10-22 Effective 2026-11-12. Widening only. Annex B §B.9 — Customer-designated registry and module hosts. A new opt-in, off by default and for organisation owners only: the Customer may store a credential for a private container registry or git module host of its own choosing, which fremforge\u0026rsquo;s security scanners use, only on scans of the Customer\u0026rsquo;s own organisation, to read the images and infrastructure modules the Customer\u0026rsquo;s repositories reference. The host is not a sub-processor of fremverk. The credential is encrypted at rest, never displayed or logged, sent only to that exact host (including a token endpoint on that host; a redirect elsewhere is followed without it), and expires within a year. Content read with it is cached for the Customer\u0026rsquo;s organisation only and deleted with the credential. Storing, replacing, deleting, switching on or off, and each scan that used a credential are audited. The sentence \u0026ldquo;fremforge never fetches from an address the Customer supplies\u0026rdquo; now excepts these hosts. Not materially adverse: nothing else changes, and a Customer that does not switch it on is unaffected. 1.56 2026-10-23 Effective 2026-11-12. Widening only. Annex B §B.10 and Annex A.6 — an issuer\u0026rsquo;s check may use a fixed list of hosts, asked in order. Some issuers serve their credentials from more than one regional host, and a credential is valid on only one of them (for example a key pinned to an EU region, or to one of an issuer\u0026rsquo;s sites). §B.10 said each issuer has \u0026ldquo;one fixed host\u0026rdquo;; it now says \u0026ldquo;a fixed host, or a fixed list of hosts asked in order\u0026rdquo;, and the What is sent safeguard allows one read-only request to each of those hosts in order, stopping at the first that reports the credential valid. A.6\u0026rsquo;s description of the same exception follows. Every host on a list belongs to the credential\u0026rsquo;s own issuer, is fixed by fremforge, is shown in the setting before the check is turned on and is admitted by the outbound proxy for this purpose only; the Customer still cannot enter a host. Every other safeguard of 1.53 stays, and nothing reaches an issuer the Customer has not turned on, so this is not materially adverse under ToS §17 and needs no notice. Queued for 2026-11-12 behind 1.55, whose text it carries. 1.57 2026-10-23 Effective 2026-11-12. Widening only. Annex A.7 — the User is the actor of every action an agent takes for them. A.7 said agent actions are recorded with actor=agent:\u0026lt;agent_id\u0026gt;, on_behalf_of=\u0026lt;user_id\u0026gt; and are distinguishable from human actions in admin-UI filters. From 2026-10-23 agents have no audit identity: an action an agent takes under a delegated mandate (token exchange) or through an MCP connector is recorded with the User as actor, the agent in the entry\u0026rsquo;s agent field and the token in via_token. Agent actions stay distinguishable from the User\u0026rsquo;s own in the audit stream and in admin-UI filters: the actor filter, in the admin UI and the API, matches a value in actor, on_behalf_of or the entry\u0026rsquo;s agent field, so it finds both new and earlier agent entries. Entries written before 2026-10-23 are not rewritten (the hash chain covers them) and keep the earlier form. Not materially adverse: nothing that was recorded stops being recorded, no Customer obligation is added, and the User an action was taken for is now its actor. Lockstep with privacy 1.28 and AUP 1.12. Queued behind 1.56 (2026-11-12); no notice. ","externalUrl":null,"permalink":"/legal/dpa/","section":"Legal documents","summary":" Last updated: 2026-10-23\n","title":"fremforge Data Processing Agreement","type":"legal"},{"content":" Last updated: 2026-10-23\nEffective Date: 2026-04-25 — Current Version: 1.28 (effective 2026-11-12; until then version 1.25 applies from 2026-11-06, version 1.20 from 2026-11-03, and version 1.19 before that; 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 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 Public CES/LTS, T Cloud Public APIG access logs, runner controller), and the registry access log: one record for each request to an organisation\u0026rsquo;s package and container registry, including pulls through the dependency proxy, with the time, your login (or the bot or anonymous caller), your IP address, your client\u0026rsquo;s user agent, the package or image asked for, the action, and whether it was allowed or blocked. Routine requests that an organisation\u0026rsquo;s CI jobs make through the dependency proxy are the exception. When such a request is allowed and succeeds, a package metadata read is not recorded, and a download served from the proxy\u0026rsquo;s cache is only counted, per day, package version, repository and CI run. No login, IP address or user agent is kept for either. Access tokens, cookies and query strings are never recorded. Why: to operate the service securely, respond to incidents, and produce the audit-log export the tenant admin can pull on demand. The registry access log also gives the tenant admin a record of who fetched or published what from the organisation\u0026rsquo;s registry. 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 7 days (persistent) _csrf CSRF token Strictly necessary Yes Session lang Language preference, user-triggered Strictly necessary Yes Effectively permanent fremforge_operator_session (operator console) Operator-console session (fremverk operators, not tenant users) Strictly necessary Yes 30-min idle, 12h absolute cap 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 plus an audit-trail emit — fremverk does not retain the prompt or response body beyond the request lifecycle. The audit-trail emit records the call (timestamp, actor, vendor identifier, model, token counts in and out, and latency) and never the prompt or response body. Corrected in privacy 1.13: this said \u0026ldquo;prompt-length / response-length\u0026rdquo;, which described character counts that are not what is recorded — the fields are the vendor\u0026rsquo;s own token counts. The substantive commitment, that no prompt or response body is stored, was and remains accurate, and is now machine-checked against the emit\u0026rsquo;s field list rather than asserted. 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. 3.8 Dependency proxy # If the Customer (the tenant admin) enables the dependency proxy, Users can pull container images and packages from public registries through fremforge. fremforge fetches each artifact from the upstream registry the User names and caches it for the Customer\u0026rsquo;s organisation.\nWhat this means for you as a data subject:\nThe upstream registry receives a request from fremforge\u0026rsquo;s IP address for the named artifact. It does not receive your identity or your IP address. The Customer may store its own credential for a registry, under the Customer\u0026rsquo;s agreement with that registry. Some registries require one (Docker Hub, and the Red Hat registries that require an account). For others the Customer may add one to reach its own private content (GitHub Container Registry and Quay). Where the Customer has stored a credential, every request to that registry carries it. Some of these registries are operated by US-incorporated companies; they are chosen by the Customer and are not fremverk sub-processors (DPA Annex B §B.9). Your pulls through the proxy are processed like other use of the package registry, as described in §3.4. 3.9 Product-update email (opt-in) # If you turn on Product updates in your notification settings (frem.sh/_app/settings/notifications), fremverk ApS sends you occasional emails about significant new features and changes to the interface of fremforge. Each one is based on an entry of the public changelog. The setting is off unless you turn it on, and nothing is sent to you because of your organisation\u0026rsquo;s subscription alone.\nWhat: your username, the primary email address of your account, your interface language, and which fremforge organisations you are an owner of; the record of your consent (when you turned the setting on or off, how, and which wording you agreed to); and, for each email, the address it was sent to, its language, when it was sent, and whether it was delivered or bounced. Why: to send you the product updates you asked for, only while you are an owner of at least one fremforge organisation, and to be able to show that you asked for them. Legal basis: your consent (GDPR Art. 6(1)(a)). This is also the prior consent that the Danish Marketing Practices Act (markedsføringsloven) §10 requires before electronic marketing is sent. fremverk ApS is the controller of this processing. It is not processing on your organisation\u0026rsquo;s behalf, and your organisation does not decide whether you receive these emails. Withdrawal: turn the setting off in your notification settings, or use the one-click unsubscribe link in any product-update email. Withdrawal takes effect immediately and does not affect the lawfulness of emails sent before it (Art. 7(3)). It does not affect service, security, billing or legal notices, which do not depend on this setting. Recipients: Lettermint B.V. delivers the email (§4, §8). The data is not shared with anyone else. 4. Where the data is processed # Surface Processor Region Forgejo UI, Git, API, package registry, CI runners T Cloud Public (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) and opt-in product-update email (§3.9) 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 Public) 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 fremverk chooses. 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 fremverk chooses. The AI vendors and upstream registries a Customer chooses are described in §3.7 and §3.8.\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 90 days to allow full export (Terms §16.5), hard-deleted from primary storage within 30 days thereafter, and then expires from the encrypted live-tier backups within up to 90 days, as the snapshots that contain it age out (DPA §9). Total time from termination to expiry from the live-tier backups is up to 210 days. Disaster-recovery tier: in addition to the live-tier retention above, fremverk holds a separate DR tier of sealed snapshots — 13-month (395-day) retention for object-store payloads, 30 days for repository content (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. Tenant-initiated audit-log exports are the one object-store payload excluded from this DR tier: they are not replicated cross-region at all, and live 7 days in-region in the signed download bucket before purge (see the export row in §Retention). Excluded deliberately — a signed, tenant-downloadable export is reproducible on demand from the audit log itself, so a sealed 13-month second copy of it would extend the life of Customer data well beyond the window the Customer was told about, for no recovery benefit. Corrected in DPA 1.26 / privacy 1.13: the replication toggle was set false on 2026-08-04 and the two Annex sentences still said every object-store payload carried the 13-month copy. Actions artifacts and CI run logs are also excluded from this DR tier: since 2026-10-21 they are not replicated cross-region, and the copies made before that date were permanently removed from eu-nl the same day. Excluded for the same reason as exports: an artifact or log lives only as long as your organisation\u0026rsquo;s own retention setting allows and is reproducible by re-running the workflow that produced it, so a sealed 13-month second copy would extend the life of that data well beyond the window your organisation chose, for no recovery benefit. Personal data inside DR-tier copies is purged on those rolling schedules independent of tenant offboarding — enforced by an object-lifecycle rule on each cross-region bucket, not by manual housekeeping: each object-store copy is permanently removed within 395 days, plus at most one day, of the day it was written to the DR region. 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). Registry access log (§3.4): for the period the tenant chooses, between 30 and 730 days. If the tenant has not chosen one, it follows the tenant\u0026rsquo;s audit-log retention above (default 90 days; enterprise plans 365 days). Older records are deleted once a day. While a legal hold applies to the tenant\u0026rsquo;s organisation, no records are deleted. Billing records: 5 years per Bogføringsloven. Closed support tickets: 12 months. Product-update email (§3.9): the setting itself for as long as your account exists. The record of each time you turned it on or off, for 3 years after you withdraw consent or your account is deleted, whichever is later, as proof of consent (GDPR Art. 7(1)). The record of each email sent to you (address, language, time, delivery status), for 3 years after it was sent. 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 Public) Core compute, storage, network, CI runners Biere/Magdeburg, DE ISO 27001, 27017, 27018; BSI C5 Type 2; TISAX BunnyWay d.o.o. Edge delivery, DDoS mitigation, rate limiting EU PoPs (HQ Slovenia) ISO 27001 (2025), SOC 2 (2023) Lettermint B.V. Outbound transactional email, and the opt-in product-update email (§3.9) 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 (BunnyWay 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 Public 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 ephemeral T Cloud Public Elastic Cloud Server virtual machines, one per job and destroyed when the job ends; 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 fremverk chooses. 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. If your organisation enables an AI vendor (§3.7) or uses the dependency proxy with an upstream registry outside the EEA (§3.8), what the Customer sends there is governed by the Customer\u0026rsquo;s own agreement with that party.\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 changes that are adverse to you or otherwise materially change how we process your data. Corrections of inaccuracy take effect immediately, disclosed through the change log at the foot of this notice: where a published statement is found to be wrong, holding the correction back for 30 days would mean knowingly continuing to publish something we know to be untrue, which is worse for you than a prompt correction. Neither route reduces your rights — 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 An owner of a tenant org who turns on product updates Product-update emails about fremforge (§3.9); the consent record and the delivery records Consent (Art. 6(1)(a)); markedsføringsloven §10 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 with you as the actor and the agent in the entry\u0026rsquo;s agent field (an agent has no audit identity of its own). Entries before 2026-10-23 keep the form actor=oidc: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.12 2026-08-04 Two changes. (1) §6 DR-tier retention corrected to per-surface figures: 13 months for object-store payloads, 30 days for repository content — the previous single 13-month figure was correct for OBS and wrong for SFS Turbo (see DPA 1.24). The purge is now stated as enforced by an object-lifecycle rule rather than left unattributed, because until 2026-08-04 no lifecycle existed on the cross-region buckets and nothing was purging them; that is fixed. (2) §14 now distinguishes adverse or materially-changing amendments (30 days\u0026rsquo; advance notice, unchanged) from corrections of inaccuracy (immediate, change-log disclosure). Holding a known-false statement live for 30 days to satisfy a notice period is worse for the reader than correcting it promptly. Neither route reduces any right. 1.13 2026-08-05 Two corrections, both found by sweeping §3 and §7, which had not been read in the 2026-08-04 pass. (a) §6 Retention — the DR tier. The notice said the disaster-recovery tier holds \u0026ldquo;13-month (395-day) retention for object-store payloads\u0026rdquo; without qualification. Tenant-initiated audit-log exports are excluded: cross-region replication of that bucket was switched off on 2026-08-04, so exports live 7 days in-region and are then purged — which is what the export row in this same §6 already said, so the notice contradicted itself for a day. Corrected in lockstep with DPA 1.26, which carries the full account and the reasoning. Favourable rather than adverse: it withdraws a promise to hold Customer data longer. (b) §3.7 Customer-configured AI processing. The audit-trail emit was described as recording \u0026ldquo;prompt-length / response-length\u0026rdquo;. It records the vendor\u0026rsquo;s token counts in and out, plus model, provider identifier, latency, actor and timestamp — not character lengths. The substantive commitment, that no prompt or response body is stored, was accurate and is unchanged; it is now machine-checked against the emit\u0026rsquo;s actual field list rather than asserted in prose. The same sweep found that one of the two AI call paths (the pull-request review) emitted an audit event only when a spend cap rejected the call, so a successful PR-review call left no audit record while this section told data subjects the call is recorded. Rather than narrow the sentence, the missing emit was added (monolith ai.pr_review.ok), because a data subject exercising Article 15 against AI processing should find the call in the audit log. No new data category, recipient, legal basis or retention period. 1.14 2026-08-05 §3.5 cookie table: the session cookie\u0026rsquo;s lifetime read \u0026ldquo;Session\u0026rdquo; and it is a persistent 7 days (SESSION_LIFE_TIME = 604800, aligned to the 7-day \u0026ldquo;Remember Me\u0026rdquo; window). Set deliberately so single-sign-on arrivals survive a browser restart. Corrected in lockstep with cookie-policy 1.3, which carries the full account. No consent implication — an authentication cookie is strictly necessary under ePrivacy Art. 5(3) whether session-scoped or persistent. No new cookie, no new purpose, no new recipient. 1.15 2026-08-05 §3.5 cookie table: the lang cookie read \u0026ldquo;1 year\u0026rdquo; and it is effectively permanent (Max-Age=2147483647, Forgejo\u0026rsquo;s LangCookieMaxAge default). Corrected in lockstep with cookie-policy 1.4, which carries the full account. The strictly-necessary classification is unchanged — ePrivacy Recital 25 exempts user-action preference cookies irrespective of duration. No new cookie, purpose or recipient. 1.16 2026-08-05 §3.5 cookie table: the fourth row read \u0026ldquo;fremforge middleware session 1.17 2026-08-20 The CDN sub-processor was named as an entity that does not exist, in the §7 sub-processor table and the §7 registrar/DNS note. Both read \u0026ldquo;Bunny CDN d.o.o.\u0026rdquo;; the sub-processor is BunnyWay d.o.o. (registered as BUNNYWAY, informacijske storitve d.o.o., Slovenian reg. no. 7297513000, seat Dunajska cesta 165, 1000 Ljubljana), verified against the AJPES business register, Bunny\u0026rsquo;s privacy notice and its trust centre. \u0026ldquo;Bunny CDN\u0026rdquo; is retained where it refers to the product rather than the company. Mirrors DPA v1.36, which corrects the same error in five places and carries the full reasoning; no change to residency, data categories, purpose or transfer mechanism, so no §14 notification obligation is engaged. 1.18 2026-10-03 §6 — repository and collaboration content is retained for 90 days after offboarding (was 60) to allow full export, per Terms 1.11 §16.5 and DPA 1.38 §9; hard deletion and backup purge follow on the same 30-day steps, so live-tier backup purge completes within 150 days of termination (was 120). For data subjects this is a disclosed 30-day extension of an existing retention period, on the same basis (the Customer\u0026rsquo;s export right). Not materially adverse under ToS §17; effective on publication. 1.19 2026-10-04 §8 sub-processor table: BunnyWay\u0026rsquo;s purpose no longer lists WAF. No Web Application Firewall is enabled at the edge on any fremforge surface (DPA Annex A.2, since DPA 1.25); the row now reads \u0026ldquo;Edge delivery, DDoS mitigation, rate limiting\u0026rdquo;, matching DPA 1.39 Annex B. No sub-processor, purpose of processing, data category or retention period changes, so this is a clarification, not materially adverse under ToS §17, effective on publication. 1.20 2026-10-04 Effective 2026-11-03. Materially adverse. Announced by notice 999f05a2-d9ea-4be3-a423-59fd1e9354b0 on 2026-10-04 (as privacy 1.19). The 2026-10-04 notice announced this change as privacy 1.19: those numbers were taken the same day by a clarification (#145, internal names become descriptions), which was already published when the notice went out, so this change carries the next number. Same change, same effective date. §6: after primary deletion, repository and collaboration content can remain in the encrypted live-tier backups for up to 90 days and expires with them; total from termination up to 210 days (was 150). No infrastructure change: this describes the backup lifecycle and the rota that operate. 1.21 2026-10-07 Effective 2026-11-06. Materially adverse. Announced by notice 06068339-c7e1-4210-8c21-2344b66a19a7 on 2026-10-07 (as privacy 1.21). §3.8 (new), §5 and §10 — the dependency proxy. New §3.8 explains the dependency proxy to data subjects: the upstream registry receives fremforge\u0026rsquo;s IP address and the artifact name but not the User\u0026rsquo;s identity or IP address; for registries that need an account, the request carries the Customer\u0026rsquo;s own stored credential; some registries are US-operated, chosen by the Customer and not fremverk sub-processors (DPA Annex B §B.9). §5 (no CLOUD Act exposure) and §10 (no transfer outside the EEA) now apply to the processing paths fremverk chooses, and point to §3.7 and §3.8 for the AI vendors and upstream registries a Customer chooses. Made in step with DPA 1.45. It narrows §5 and §10 and changes how data may travel when a Customer enables the feature, so it is a material change under §14 and adverse under ToS §17: it takes effect 30 days after the notice. 1.22 2026-10-07 Effective 2026-11-06. Widening only. §3.9 (new), §4, §6, §8 and Annex A — the opt-in product-update email. New §3.9 describes the email fremverk sends about significant fremforge changes to a user who turns on Product updates in their notification settings: the data used (username, primary email address, interface language, which organisations the user owns, the consent record, and per email the address, language, time and delivery status), the purpose, the legal basis (consent, GDPR Art. 6(1)(a), which is also the prior consent markedsføringsloven §10 requires), fremverk ApS as controller, and withdrawal by the setting or the one-click unsubscribe link in every email. §6 adds its retention, §4 and §8 name Lettermint B.V. as the deliverer of this email as well as of transactional email, and Annex A adds a row. Not materially adverse under Terms §17: it reduces no right and no fremverk commitment, and adds no Customer obligation, restriction or cost. Not a material change under §14: no one\u0026rsquo;s data is processed for this purpose unless that person turns the setting on, and they are told at that point. Scheduled with privacy 1.21 because its text contains that change, so it cannot take effect before 2026-11-06. No product-update email is sent before this version is in force. 1.23 2026-10-07 Effective 2026-11-06. Widening only. §3.8 — credentials the Customer chooses to store, in step with DPA 1.46. §3.8 said the request carries the Customer\u0026rsquo;s stored credential \u0026ldquo;where the registry requires an account (for example Docker Hub)\u0026rdquo;. The Customer may now also store its own credential for GitHub Container Registry and Quay, to reach its own private content, and for a second Red Hat registry that requires an account. §3.8 now covers any registry for which the Customer chooses to store a credential, and names both cases. Unchanged: the registry receives fremforge\u0026rsquo;s IP address and the artifact name but not your identity or IP address, and these registries are chosen by the Customer and are not fremverk sub-processors. A credential reaches a registry only if the Customer stores one, so this is not materially adverse under ToS §17 or a material change under §14. Queued for 2026-11-06 with 1.21 and 1.22, whose text it contains: on that day 1.23 applies. 1.24 2026-10-08 Effective 2026-11-06. Widening only. §3.4 and §6 — the registry access log and how long it is kept. The registry access log records each request to an organisation\u0026rsquo;s package and container registry (time, login, IP address, user agent, artifact, action, result) and was not named in this notice. §3.4 now names it and says why it is kept, and §6 states its retention: the period the tenant chooses, 30 to 730 days, or, if none is chosen, the tenant\u0026rsquo;s audit-log retention (default 90 days, enterprise plans 365); daily deletion; nothing deleted under a legal hold. This describes processing that already takes place, on the schedule it already runs; it neither starts new processing nor lengthens any retention, so it is not materially adverse under ToS §17 and is a correction under §14. Queued for 2026-11-06 with 1.21 to 1.23, whose text it contains. 1.25 2026-10-10 Effective 2026-11-06. Widening only. §3 — authentication data: OIDC, not SAML. §3 listed \u0026ldquo;OIDC/SAML subject identifiers and claims\u0026rdquo; among the data processed for a signed-in user. Measured 2026-10-10: the Forgejo release fremforge runs has no SAML authentication source, no fremforge patch adds one, and the SAML registration endpoint and assertion consumer URL both answer 404, so no SAML sign-in has ever been possible. No SAML identifier has been processed, so the list now says OIDC. It removes a category of data that was never collected and leaves every right and obligation as it was, so it is not materially adverse under ToS §17. Queued for 2026-11-06 with 1.21 to 1.24, whose text it contains, and announced alongside DPA 1.49 and Terms 1.13. 1.26 2026-10-13 Effective 2026-11-12. Materially adverse. Announced by notice 81ccd763-bc11-4bcd-a56b-bb12b3c92de9 on 2026-10-13 (as privacy 1.26), together with DPA 1.50. §3.4: routine CI requests through the dependency proxy. An allowed package metadata read by a CI job is not recorded, and an allowed CI download served from the proxy\u0026rsquo;s cache is only counted (day, package version, repository, run). No login, IP address or user agent is kept for either. Less personal data is processed. 1.27 2026-10-21 Effective 2026-11-12. Widening only. §6 Disaster-recovery tier: Actions artifacts and CI run logs are excluded from the DR tier since 2026-10-21, and the copies made before then were permanently removed from eu-nl the same day (they had followed the 13-month DR schedule rather than your organisation\u0026rsquo;s artifact-retention setting). The lifecycle sentence now says what it removes and when: each object-store copy is permanently removed within 395 days, plus at most one day, of being written to the DR region; before platform-foundation #1851 a versioned copy\u0026rsquo;s bytes could outlive that by up to another 395 days. Both shorten retention, so this is not materially adverse and needs no notice. Lockstep with DPA 1.54. 1.28 2026-10-23 Effective 2026-11-12. Widening only. Annex A, the AI-agent row: actions an agent takes on your behalf, under a delegated mandate or through an MCP connector you authorised, are logged with you as the actor and the agent in the entry\u0026rsquo;s agent field, not as actor=agent:\u0026lt;id\u0026gt;, on_behalf_of=\u0026lt;user_id\u0026gt;. Agents have no audit identity of their own since 2026-10-23; earlier entries are not rewritten and keep the earlier form. Not materially adverse: nothing that was recorded stops being recorded. Lockstep with DPA 1.57. Queued behind 1.27 (2026-11-12); no notice. 1.11 2026-08-04 Corrected the hosted-runner platform: runners are ephemeral T Cloud Public Elastic Cloud Server virtual machines, one per job, not Cloud Container Instance containers. The CCI model was pre-launch intent and never shipped; cce-node-image was archived 2026-06-24. DPA Annex A.5 was corrected on 2026-08-04 but this document was not, because the regression guard added at the time checked only the DPA. No control is weakened — per-job VMs give strictly stronger isolation than shared-kernel containers, so the substance (no shared kernel between tenant jobs) is unchanged and now accurately described. Not materially adverse under the Terms §1.2 test. 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":" Last updated: 2026-10-23\n","title":"fremforge Product Privacy Notice","type":"legal"},{"content":" Last updated: 2026-10-06\nEffective Date: 2026-04-25 — Current Version: 1.14 (effective 2026-11-03; until then version 1.11 applies; 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.9% Monthly Service Availability for the in-scope surfaces defined in §3, measured calendar-monthly (first to last day of each calendar month, UTC).\n99.9% per calendar month allows approximately 43 minutes of Downtime in a 30-day month (44 minutes in a 31-day month). That is shorter than an operator response outside business hours, where on-call acknowledgement is best-effort (§9). The commitment therefore rests on the service recovering automatically under T Cloud Public\u0026rsquo;s native redundancy (CCE HPA, RDS cross-AZ automatic failover, ELB-managed certificates), not on human intervention. An incident outside business hours that does not recover automatically will usually use up a month\u0026rsquo;s allowance on its own, and the Customer is then entitled to a service credit under §7.\n2.2 Relationship to the underlying platform # The commitment is above the composed theoretical ceiling of the T Cloud Public services in the critical path, not below it. Those services (RDS, CCE, DCS, OBS, SFS Turbo, ELB) are each published at about 99.9% per service; composed serially, the published figures multiply out to about 99.4%. Up to version 1.5 this section said the commitment was deliberately set below that ceiling. At 99.9% that is no longer true, so this section now states what the commitment rests on instead.\nIt rests on two things:\nMeasurement is end-to-end. A per-service figure is a provider\u0026rsquo;s contractual floor, not its measured availability, and Downtime under this SLA is counted only when the end-to-end probes in §5 fail. A dependency fault that the redundancy described in §2.1 absorbs is not Downtime. fremverk carries the dependency risk. Where a dependency fault does reach the Customer, it counts in full: outages of T Cloud Public and fremverk\u0026rsquo;s other contracted sub-processors are not excluded (§6.3), and the service credits in §7 apply on the same terms whichever layer failed. The 99.9% figure is therefore a commercial commitment backed by a financial remedy, not an engineering claim that the platform cannot fall below it. Customers whose own obligations require more than a service credit should discuss Enterprise-on-Demand terms.\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 the platform\u0026rsquo;s SSH service; 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/\u0026lt;slug\u0026gt;/_admin (per-tenant — URL Option B per fremverk\u0026rsquo;s internal product plan). Out of scope for the 99.9% commitment (each has its own availability model, stated below):\nHosted CI runners — best-effort dispatch to ephemeral T Cloud Public Elastic Cloud Server virtual machines; measured separately (§4). Status page at status.frem.sh — hosted in a separate, isolated cloud project 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 / the operator-provisioned custom 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 Public 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 Public Cloud Eye (CES) availability data and fremverk\u0026rsquo;s internal T Cloud Public 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 Public). 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 Public 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 procedures # fremverk maintains written operator procedures for delivering the commitments in this SLA, covering incident response, status-page and post-incident publication, the restore drills in DPA Annex A.9, a T Cloud Public regional outage, and deploy rollback during an incident. They are available to Customers under NDA on request via compliance@frem.sh. The incident-communication and post-mortem templates are public at docs.frem.sh/runbooks/incident-comms-template and docs.frem.sh/runbooks/post-mortem-template.\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 — contractual, in force now), 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 (contractual). fremverk patches CVEs against the following targets, measured from the upstream fixed release or advisory publication (whichever is later): Critical (CVSS ≥ 9.0) within 48 hours, High (7.0–8.9) within 72 hours, Medium (4.0–6.9) within 7 days, Low (\u0026lt; 4.0) by the next scheduled maintenance window. These are contractual and in force now. The previous phased model — weaker targets under commercially reasonable efforts until 2027-Q1 — was withdrawn on 2026-08-05 because fremverk\u0026rsquo;s published trust page already stated the stricter figures as a commitment, and DPA Annex A.8 incorporates that page by reference. See DPA A.8 (v1.30).\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 Public, 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.9%, 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.9% 0% — commitment met ≥ 99.5% and \u0026lt; 99.9% 10% ≥ 99.0% and \u0026lt; 99.5% 25% \u0026lt; 99.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.5% 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. 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. On-call coverage — fremverk maintains a documented on-call rotation, with cover for absence, sized to meet the acknowledgement and response targets in this section and §10. 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 a separate, isolated cloud project 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/\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 (\u0026ldquo;business hours\u0026rdquo;): 09:00–17:00 Europe/Copenhagen, Monday to Friday, excluding Danish public holidays. A P1 may be reported at any time; outside business hours its first response is best-effort, as set out below.\nThe 99.9% commitment is paired with email support via support@frem.sh. Target first-response times:\nP1 — Critical (defined in §10.1): first response within 1 hour during business hours (09:00–17:00 Europe/Copenhagen, Monday to Friday, excluding Danish public holidays), best-effort outside business hours. Contracted 24/7 P1 response (1 hour, including weekends and Danish public holidays) is available from 2027-Q1 for Enterprise-on-Demand Subscriptions.\nStandard Subscription: as above. Outside business hours a P1 is reported to support@frem.sh in the same way, and the response is best-effort. Enterprise-on-Demand Subscription: from 2027-Q1, first response within 1 hour, 24/7, including weekends and Danish public holidays, subject to fremverk\u0026rsquo;s funded on-call rotation. Until then, the Standard Subscription targets apply, with commercially reasonable best-effort response outside business hours. 10.1 Support targets # Each severity has a first-response target, and P1 to P3 also have a workaround and a resolution target. This table is the support commitment; the support page at docs.frem.sh restates it and does not change it.\nSeverity Definition First response Workaround Resolution P1 — Critical The Service, or an in-scope surface in §3, is unavailable for all Users, or for all Users of the Customer\u0026rsquo;s organisation; no User of the organisation can authenticate; or Customer data is at risk of loss 1 hour during business hours; best-effort outside business hours 4 business hours 2 business days P2 — High Major functionality degraded or unavailable, for example hosted runners down or single sign-on failing for most Users 4 business hours 2 business days 10 business days P3 — Medium Minor issue or question: degraded performance, a problem affecting a single User, any non-blocking issue, or a question about using the Service 1 business day 5 business days 20 business days P4 — Low Feature request, documentation 3 business days — — First response is a reply from a person at fremverk who has read the request, states the severity assigned and says what happens next. Workaround means the Customer can use the affected function again, in full or by an alternative fremverk has described, or the Service is restored. Resolution means the cause is fixed in the Service, or, for a question, the question is answered. Where the cause lies outside fremverk\u0026rsquo;s control (§6.3, §6.4) or on the Customer\u0026rsquo;s side, resolution means fremverk has done what is in its control and has told the Customer what remains. Workaround and resolution targets run from receipt of the request at support@frem.sh and count business hours and business days only, so outside business hours they wait for the next business hour. They pause while fremverk waits for information it has asked the Customer for. P4 has no workaround or resolution target: feature requests are considered for the roadmap without a commitment, and documentation errors are corrected in the published documentation. Missing a workaround or resolution target does not by itself give rise to a service credit; service credits arise under §7. fremverk self-assigns severity on receipt; the Customer may request re-triage.\nEnterprise-on-Demand contracts add a named Customer Success contact and, from 2027-Q1, contracted 24/7 P1 response.\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 under Terms of Service §17. That section decides, by a change\u0026rsquo;s effect on the Customer and not by the direction in which a number moves, whether the change is adverse, and therefore whether it takes effect only after 30 days\u0026rsquo; notice with the termination right, or on publication. A change adverse in any respect is adverse as a whole. For this SLA:\nAdverse changes include lowering the availability commitment in §2.1; widening an exclusion in §6 or raising the maintenance cap; reducing a credit percentage or the cap in §7; lowering the availability level below which a credit or the §7.6 termination right arises; shortening the claim deadline in §8.2 or adding conditions to a claim; and weakening the incident-communication commitment in §9. Changes that raise a commitment or make a remedy easier to obtain or larger, such as raising the availability commitment, a credit percentage, or the level below which a credit or the §7.6 termination right arises, are not adverse, unless they are adverse in another respect. 13. 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.14 2026-10-06 Effective 2026-11-03. Widening only. §10 support targets: one table of severity, first response, workaround and resolution, which the support page at docs.frem.sh restates without change (SKI 02.06 K65–K66). §10 gave first-response targets only and said severity was not a guarantee of resolution time. New §10.1 adds a workaround target and a resolution target for each severity (P1: 4 business hours and 2 business days; P2: 2 and 10 business days; P3: 5 and 20 business days; P4: none), defines first response, workaround and resolution, and says when the workaround and resolution clocks run and pause. The severity definitions now include the examples the support page used (no User of the organisation able to authenticate, Customer data at risk of loss, hosted runners down, single sign-on failing for most Users, a problem affecting a single User), so a request is classified the same way in both places; each definition covers at least what it covered before. Every first-response target, the business hours, the best-effort P1 response outside them, the 2027-Q1 Enterprise-on-Demand 24/7 P1 response and the §9 acknowledgement targets are unchanged. It adds commitments and removes none, so it is not adverse under ToS §17 or SLA §12 and needs no notice. Queued for 2026-11-03 behind 1.13, whose text it contains: on that day 1.14 applies, and 1.13 is never in force on its own. 1.13 2026-10-04 Effective 2026-11-03. Materially adverse. Announced by notice effac7b9-0802-48f2-af88-f11fc4462fa6 on 2026-10-04 (as sla 1.13). §9 — on-call coverage stated as an outcome, not as staffing. 1.12 (effective the same day) describes the on-call rota by headcount: two operators in business hours, one outside, the secondary covering around the clock when the primary is absent. 1.13 replaces that with an outcome: fremverk maintains a documented on-call rotation, with cover for absence, sized to meet the acknowledgement and response targets in §9 and §10. The SLA no longer states how many operators are on call or when. Every acknowledgement, response, status-page and notification target is unchanged. Materially adverse under ToS §17 and SLA §12, because it removes a stated staffing commitment, so it takes effect on 2026-11-03, 30 days after the notice sent on 2026-10-04, with the §17 termination right. Until then version 1.11 applies, as it does for 1.12. 1.12 2026-10-04 Effective 2026-11-03. Materially adverse. Announced by notice 999f05a2-d9ea-4be3-a423-59fd1e9354b0 on 2026-10-04 (as sla 1.11). The 2026-10-04 notice announced this change as sla 1.11: those numbers were taken the same day by a clarification (#145, internal names become descriptions), which was already published when the notice went out, so this change carries the next number. Same change, same effective date. §9 on-call coverage as staffed: two operators in business hours (the secondary is paged after 15 minutes without acknowledgement), one, the primary, outside business hours; the secondary is on call around the clock when the primary is absent. Was \u0026ldquo;two-person on-call rotation … at all times\u0026rdquo;. Acknowledgement targets unchanged. No infrastructure change: this describes the backup lifecycle and the rota that operate. 1.11 2026-10-04 Internal implementation names replaced by descriptions. §5.4 listed operator runbooks by file name; it now describes the procedures fremverk keeps and how a Customer obtains them (under NDA via compliance@frem.sh), and keeps the links to the two public templates. §3 and §9 named the status page\u0026rsquo;s cloud project; they now say it is hosted in a separate, isolated cloud project. §3 says \u0026ldquo;the platform\u0026rsquo;s SSH service\u0026rdquo; instead of an internal component name. No commitment, target, measurement method or remedy changes, so this is a clarification, not materially adverse under ToS §17 or SLA §12, effective on publication. 1.10 2026-10-03 §10 support targets stated once, the same way everywhere, and matched to the rota that is staffed. §10 said both \u0026ldquo;P1 support is 24/7 regardless of standard hours\u0026rdquo; and that the P1 first response outside business hours is best-effort, and the support page at docs.frem.sh gave 2 business hours for P1. The commitment is now one sentence, used identically in the docs: P1 first response within 1 hour during business hours, best-effort outside business hours; contracted 24/7 P1 response from 2027-Q1 (Enterprise-on-Demand). A P1 may still be reported at any time. §9 and §10 no longer say the out-of-hours channel or rotation is published on status.frem.sh, which it is not; out of hours a P1 goes to support@frem.sh as in hours. The closing Enterprise-on-Demand line now carries the 2027-Q1 date its own bullet already had. No target changes — the 1-hour business-hours target, the best-effort out-of-hours response, P2–P4 and the 2027-Q1 date are as before — so this is a clarification, not materially adverse under ToS §17, effective on publication. 1.9 2026-10-01 §12 now takes the rule from Terms §17 (Terms 1.10), which decides by its effect on the Customer whether a change is adverse and when it takes effect, instead of restating it. §12 keeps the SLA-specific examples of adverse and not-adverse changes. The test is the same as in 1.8, except that Terms §17 also treats an added obligation, restriction or cost for the Customer as adverse, so it is not adverse within Terms §17, and takes effect on publication. 1.8 2026-10-01 §12 now defines an adverse change by its effect on the Customer. It had listed \u0026ldquo;raise thresholds\u0026rdquo; as adverse, which read literally covered 1.7, where raising the §7.6 termination threshold made the remedy easier to reach. A change is now adverse if it reduces a commitment or makes a remedy harder to obtain or smaller, with examples that include lowering the level below which a credit or the termination right arises; a change that raises a commitment or makes a remedy easier to obtain or larger takes effect on publication. Every change that reduces a commitment or makes a remedy harder to obtain or smaller is still adverse, the list now also covers changes the old wording missed (an exclusion widened, a claim deadline shortened), and the 30-day notice and termination right in Terms §17 are unchanged. Only a change in the Customer\u0026rsquo;s favour, which the old wording caught by its literal terms, is no longer adverse, so it is not adverse within §12 or materially adverse within Terms §17, and takes effect on publication. 1.7 2026-10-01 §7.6 chronic-breach termination threshold raised from 99.0% to 99.5%. The for-cause termination right with pro-rata refund now arises when Monthly Service Availability is below 99.5% (was 99.0%) for 3 consecutive months, or for any 4 months in a rolling 12-month period. The month counts, the 30-day exercise window and the refund are unchanged. 99.5% is the bottom of the 10% credit band that 1.6 introduced, so the right now arises from the band in which a month already earns more than the minimum credit. It makes the remedy easier to obtain and removes nothing a Customer could do under 1.6, so it is not adverse within §12 of this SLA or materially adverse within Terms §17, and takes effect on publication. 1.6 2026-10-01 Availability commitment raised from 99.5% to 99.9% (§2.1, §3, §7.1, §10), and the §7.1 credit schedule moved up with it: 0% at ≥ 99.9%, 10% at 99.5–99.9%, 25% at 99.0–99.5%, 50% below 99.0% (in 1.5: 0% at ≥ 99.5%, 10% at 99.0–99.5%, 25% at 95.0–99.0%, 50% below 95.0%). At every availability level the credit is equal to or higher than under 1.5. The 50% cap, the 75% severe-outage credit below 90% (§7.2) and the 99.0% chronic-breach threshold (§7.6) are unchanged. §2.2 rewritten: it said the commitment was deliberately below the composed ceiling of the T Cloud Public services in the critical path, which stops being true at 99.9% (six services at ~99.9% each compose serially to ~99.4%). It now says the commitment is above that ceiling and rests on end-to-end measurement plus fremverk carrying dependency risk through §7. §2.1 now says that a 43-minute monthly allowance is shorter than an out-of-hours response, so the commitment depends on automatic recovery. Made in step with Terms 1.9 (§11). It raises a commitment and increases every credit, so it is not materially adverse within Terms §17 or §12 of this SLA, and takes effect on publication. 1.5 2026-08-05 Security-patching commitment moved from commercially reasonable efforts to contractual. §6.2 now states Critical 48h / High 72h / Medium 7 days / Low next maintenance window, in force now, replacing the phased model that had weaker Phase 1 targets until 2027-Q1. Made in step with DPA 1.30 and Terms 1.6: fremverk\u0026rsquo;s published trust page already committed to these figures and DPA Annex A.8 incorporates that page by reference, so the phasing had the contract promising less than the public page. Resolved in the Customer\u0026rsquo;s favour — every target moves in their favour and none is weakened. 1.4 2026-08-04 Corrected the hosted-runner platform: runners are ephemeral T Cloud Public Elastic Cloud Server virtual machines, one per job, not Cloud Container Instance containers. The CCI model was pre-launch intent and never shipped; cce-node-image was archived 2026-06-24. DPA Annex A.5 was corrected on 2026-08-04 but this document was not, because the regression guard added at the time checked only the DPA. No control is weakened — per-job VMs give strictly stronger isolation than shared-kernel containers, so the substance (no shared kernel between tenant jobs) is unchanged and now accurately described. Not materially adverse under the Terms §1.2 test. 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 Public 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. 1.3 2026-08-04 Audit-retention tables: the plan name enterprise_trial no longer exists. Migration 0164 renamed the plan_tier enum value to custom_trial; the retention tables in DPA A.7, SLA §3A and the ROPA were not updated and had named a plan for ~2.5 months that no system recognises. Now described as \u0026ldquo;the operator-provisioned custom trial\u0026rdquo; rather than by an internal identifier, so a future enum rename cannot make the contract wrong again — naming an implementation detail in a customer document is what created this. No retention value, floor or default changes; this is the same plan under an accurate description, so it is not materially adverse and takes effect on publication. Found while verifying the 365-day default itself, which turned out not to be implemented at all (fixed in monolith #1271 and backfilled across 7 tenants); the stale name was the smaller half of that finding. ","externalUrl":null,"permalink":"/legal/sla/","section":"Legal documents","summary":" Last updated: 2026-10-06\n","title":"fremforge Service Level Agreement","type":"legal"},{"content":" Last updated: 2026-10-10\nEffective Date: 2026-05-10 — Current Version: 1.13 (effective 2026-11-09; until then version 1.12 applies; full revision history in §Change log)\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. Customer Group — the Customer and the other authorities, bodies, and entities that may use the Customer\u0026rsquo;s Subscription, as set out in §3. User — an employee, contractor, or other individual authorised by the Customer to use the Service under the Customer\u0026rsquo;s account, including one who works for a member of the Customer Group. 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 Public Elastic Cloud Server — one ephemeral virtual machine per job, destroyed when the job ends (\u0026ldquo;hosted runners\u0026rdquo;). Single sign-on enforcement via OIDC; 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-sublicensable right to access and use the Service during the Term, for the internal purposes of the Customer and the Customer Group. The right may be transferred as set out in this §3 and §19. The Customer may provide access to its employees, contractors, and other permitted users (\u0026ldquo;Users\u0026rdquo;), including the employees and contractors of any member of the Customer Group, 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.\nCustomer Group. The Customer Group is:\nwhere the Customer is a public authority, a municipality, a region, or another public-sector body: the Customer, every authority or body within the Customer\u0026rsquo;s authority or group, and any new or changed authority or body that takes over all or part of the Customer\u0026rsquo;s functions through a reorganisation, a transfer of responsibilities between ministries, a merger, or a similar restructuring; where the Customer is constituted under private law, including a self-governing institution: the Customer, any entity that controls the Customer, and every entity controlled by the Customer or by such an entity. An entity controls another if it holds, directly or indirectly, more than half of the voting rights in it or can otherwise direct its management and policies. Use of the Service by a member of the Customer Group is use by the Customer under these ToS and is not a sublicence. The Customer is responsible for that use as it is for the use of its own Users.\nMoving the Subscription. The Customer may, without fremverk\u0026rsquo;s consent, transfer all or part of its Subscription, including some of its seats:\nto any member of the Customer Group, including a new or changed authority, body, or entity described above; and where the Customer buys the Service on behalf of other public authorities, from one of those authorities to another. The same applies between municipalities, between regions, and between comparable public bodies. The Customer gives fremverk written notice of the transfer under §20, naming the receiving authority, body, or entity. Where the transfer changes the legal entity that holds the Subscription or the name in which it is held, the Customer arranges for the parties concerned to sign fremverk\u0026rsquo;s standard change-of-name or assignment document; that document records the change and adds no terms. fremverk does not refuse or delay a transfer made under this paragraph and charges no fee for it. A transfer moves seats; it does not add any, and it does not change the price, plan, or other limits that apply to them. The receiving authority, body, or entity is bound by these ToS for what it receives.\nWhere the Service may be used. The Customer, the Customer Group, and their Users may access and use the Service, and run the CLI under §7.5, from any location in any country, subject only to §6.5 (Export control and sanctions). This does not change where Customer Content is hosted, which the DPA governs.\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 by default, and every Subscription paid by card or SEPA Direct Debit is billed in EUR without exception.\nDanish kroner (DKK) are available only on Enterprise-on-Demand terms. Where an Enterprise-on-Demand Customer is invoiced on payment terms and settles by bank transfer rather than by a stored payment method (§4.5), fremverk and the Customer may agree in the ordering document that Fees are denominated and invoiced in DKK. That election is made at contract signature and applies to invoices issued after it; it does not re-denominate invoices already issued. Where no such election is recorded, EUR applies.\nThe invoice currency does not affect VAT. Where the Customer is established in Denmark, Danish 25% VAT applies via fremverk\u0026rsquo;s bookkeeping partner whether the invoice is denominated in EUR or DKK; 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 fremverk and fremforge trademarks 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.\nfremverk® is a registered trademark of fremverk ApS. fremforge® is a registered European Union trade mark of fremverk ApS.\nNothing in this agreement grants the Customer any licence to use the fremverk or fremforge names, marks, or logos. The Customer may nonetheless refer to fremverk and fremforge by name for factual and descriptive purposes — for example describing its own use of the Service, its toolchain, or its integrations — which is nominative use and requires no licence from fremverk. Use of the marks or logos in a manner that implies endorsement, partnership, certification, or common origin requires fremverk\u0026rsquo;s prior written consent (email suffices). This mirrors the reciprocal restriction on fremverk\u0026rsquo;s use of Customer marks in §27.\n7.3 Open source components # The Service is built on open source software, including Forgejo (GPL v3+), which fremverk runs as a modified build, 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+. fremverk runs a modified build of Forgejo as a hosted service: a maintained patch series is applied on top of a pinned upstream commit, principally for single-sign-on and MFA claim handling, tenant-boundary enforcement, system-bot concealment, and additional Actions APIs. 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. GPL v3 contains no network-use clause (unlike AGPL v3 §13), so operating a modified build as a service does not trigger a source-provision obligation; that conclusion is unchanged by the modifications. The Customer\u0026rsquo;s repositories remain governed solely by the licences the Customer chooses for them. The modifications do not alter Forgejo\u0026rsquo;s data model, so repository, issue, PR, and metadata exports under §16.5 / DPA §9 remain 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.\n7.5 fremforge CLI — licence, support period, and security updates # fremverk publishes the fremforge CLI, a single-file executable that wraps the public REST API, at cli.frem.sh and documents it at docs.frem.sh/get-started/cli/. Unlike the rest of the Service, the CLI is software the Customer downloads and runs on its own systems, so it is addressed separately here.\n(a) Licence. fremverk grants the Customer a non-exclusive, non-sublicensable licence to download, install, and run the CLI on any number of systems, in any location, solely to access the Service under a valid Subscription and for the internal purposes of the Customer and the Customer Group (§3). Members of the Customer Group may run the CLI on the same terms, and that is not a sublicence. The licence moves with the Subscription when all or part of it is transferred under §3, and it lasts as long as the Customer\u0026rsquo;s right to use the Service. The CLI is proprietary software; it is not open source and no source licence is granted. The Customer may not decompile, reverse-engineer, or redistribute it, except where such a restriction is unenforceable under applicable law (including Art. 6 of Directive 2009/24/EC on interoperability).\n(b) No separate charge. The CLI is provided at no additional cost as part of the Subscription. It is not a separate product and confers no rights beyond those in this §7.5.\n(c) Support period. fremverk declares a support period of five (5) years from the release date of each minor version of the CLI, during which fremverk handles vulnerabilities in that version in accordance with (d). This is the support period within the meaning of Art. 13(8) of Regulation (EU) 2024/2847 (the Cyber Resilience Act), and it is published alongside the download so that it is available before installation. The support period is independent of the Customer\u0026rsquo;s Subscription term: it attaches to the released version, not to the account.\n(d) Security updates and vulnerability handling. fremverk remediates vulnerabilities in the CLI by publishing a new release, made available at the same URLs and covered by the same signed SHA256SUMS manifest. Security fixes are provided free of charge and are announced separately from feature releases. Because fixes ship forward, the Customer is expected to run a supported version; a Customer running a superseded version can obtain the fix by upgrading, which fremverk will not gate behind a paid plan or a new licence. Vulnerability reports go to security@frem.sh under the coordinated-disclosure process published at www.frem.sh/security.\n(e) Software bill of materials. A CycloneDX SBOM for each release is published at cli.frem.sh/cli/SBOM.cdx.json (and per-version at cli.frem.sh/cli/v\u0026lt;version\u0026gt;/SBOM.cdx.json), covered by the same signed manifest as the binaries, so the Customer can verify its provenance rather than take it on trust.\n(f) Warranty and liability. The CLI is subject to §13 (Warranties) and §14 (Liability) on the same basis as the Service, save that fremverk gives no warranty that the CLI will operate on any specific operating-system version, architecture, or configuration beyond the platforms listed in the Documentation. Nothing in this §7.5 limits liability that cannot be limited under §14.1, and nothing in it excludes the Customer\u0026rsquo;s rights under mandatory consumer or product-safety law.\n(g) Not required. The CLI is a convenience. Every operation it performs is available through the documented REST API and, where applicable, the admin UI. A Customer that prefers not to run third-party executables can decline it with no loss of functionality.\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 Public 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 — contractual and in force now: Critical within 48h, High within 72h, Medium within 7 days, Low by the next scheduled maintenance window. The previously stated phasing (these targets from 2027-Q1, weaker commercially-reasonable targets until then) was withdrawn on 2026-08-05 because fremverk\u0026rsquo;s published trust page already committed to these figures and DPA Annex A.8 incorporates that page by reference. See DPA A.8 (v1.30). 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.9% 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. 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). These targets are in force now. The phased warranty previously given here — commercially reasonable efforts against weaker targets until fremverk\u0026rsquo;s funded 24/7 on-call rotation went live, targeted 2027-Q1 — was withdrawn on 2026-08-05, because fremverk\u0026rsquo;s published trust page already committed to the stricter figures and DPA Annex A.8 incorporates that page by reference. Failure to meet this SLA 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 90 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), §16.6 (Switching, porting and exit), §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.\n16.6 Switching, porting and exit (EU Data Act Chapter VI) # This §16.6 implements Chapter VI of Regulation (EU) 2023/2854 (the Data Act), which applies to fremverk as a provider of a data processing service. It applies in addition to, and does not narrow, the export rights in §16.5 or the DPA. Where this §16.6 and any other provision of the Agreement conflict on switching, this §16.6 prevails.\n(a) Right to switch. The Customer may at any time, without cause, direct fremverk to (i) switch the Service to another provider of an equivalent service, (ii) port the Customer\u0026rsquo;s Exportable Data and Digital Assets to on-premises ICT infrastructure operated by or for the Customer, or (iii) erase the Customer\u0026rsquo;s Exportable Data and Digital Assets. The Customer may exercise any of these while remaining a Customer, and exercising (i) or (ii) is not itself a termination of the Agreement.\n(b) Definitions. Exportable Data means the input and output data of the Service, including metadata, generated directly or indirectly by the Customer\u0026rsquo;s use of the Service — for fremforge, this is repository content and history, LFS object references, issues and pull requests, Actions workflow definitions and logs, the Customer\u0026rsquo;s audit-log slice, build attestations, and account and organisation configuration. It excludes fremverk\u0026rsquo;s own operational data, aggregate or derived data that does not relate to the Customer, and any asset protected by third-party intellectual-property rights or constituting a trade secret. Digital Assets has the meaning given in Art. 2(31) of the Data Act.\n(c) Notice period. The Customer initiates switching by written notice to support@frem.sh or through the admin UI. The maximum notice period before the switching process begins is two months from the Customer\u0026rsquo;s request; fremverk in practice begins immediately on receipt and does not require the Customer to wait.\n(d) Maximum transitional period. fremverk completes the switching process within a mandatory maximum transitional period of 30 calendar days, beginning at the end of the notice period in (c). Where completion within 30 calendar days is technically unfeasible, fremverk notifies the Customer within 14 working days of the switching request, with a duly substantiated justification, and specifies an extended transitional period, which will not exceed seven months. The Customer may extend the transitional period once, to a period the Customer considers more appropriate for its own purposes.\n(e) Continuity during transition. Throughout the transitional period, fremverk maintains full continuity of the Service and continued business operations under the Agreement, at the same service levels (SLA) and the same Fees as before, and keeps the Customer\u0026rsquo;s security obligations under §11 and the DPA intact.\n(f) Retrieval and erasure. After the transitional period ends, the Customer has a retrieval period of 30 calendar days in which to retrieve Exportable Data and Digital Assets. This runs in parallel with, and does not shorten, the 90-day retention window in §16.5 — the longer of the two applies. At the end of the applicable window, fremverk erases all Exportable Data and Digital Assets in accordance with DPA §9, and confirms erasure in writing on request.\n(g) No switching charges. fremverk does not charge switching charges, early-termination penalties, egress fees, data-transfer fees, or any other charge for exercising rights under this §16.6. Art. 29 of the Data Act permits cost-based reduced charges until 12 January 2027 and prohibits them thereafter; fremverk waives them in full from the date of this version rather than at the statutory deadline. Fees for the Service itself remain payable for the period the Service is provided.\n(h) Assistance and good faith. fremverk assists the switching process in good faith and with due care, including by providing the information in (i) below, responding to reasonable technical questions from the Customer or the receiving provider, and not introducing pre-commercial, commercial, technical, contractual, or organisational obstacles to switching. The Customer likewise cooperates in good faith, including by identifying the receiving provider or target infrastructure and by testing retrieved data promptly.\n(i) Functional equivalence and open formats. fremforge is a software-as-a-service offering, so the functional-equivalence obligation in Art. 30(1) of the Data Act — which applies to infrastructure-as-a-service — does not attach. fremverk instead meets Art. 30(5) and 30(6): it makes open interfaces available free of charge and exports Exportable Data in structured, commonly used, machine-readable open formats. Specifically: repositories as native git bundle archives, LFS as standard pointer manifests, audit data as JSONL, attestations as in-toto DSSE envelopes, and account and organisation metadata as JSON, with a DSSE-signed SHA-256 manifest over every file. No fremverk-proprietary format is used and no fremverk tooling is required to read an export. Because fremverk runs Forgejo without altering its data model (§7.3), an export is directly importable into a self-hosted Forgejo instance or another Forgejo-compatible host.\n(j) Information on switching. The procedures, formats, tooling, size limits, and step-by-step verification recipe are published and kept current at docs.frem.sh/admin/data-export/, which forms the information notice required by Art. 26 of the Data Act. The self-service export is included in the standard per-seat price and is available to every organisation administrator at any time, including throughout the transitional and retrieval periods.\n(k) Interaction with termination. Nothing in this §16.6 requires the Customer to terminate in order to switch or port, and nothing in §16.2 to §16.5 limits the rights in this §16.6.\n17. Changes to these ToS # fremverk may amend these ToS. Whether an amendment is adverse is decided by its effect on the Customer, not by the direction in which a number moves or by how the amendment is described:\nAn amendment is adverse if it reduces a right of the Customer or a commitment of fremverk, makes a remedy harder to obtain or smaller, or adds an obligation, restriction or cost for the Customer. Examples: increasing Fees beyond the contracted increase mechanism; reducing the liability cap or shifting indemnity allocation; materially reducing functionality covered by the Service description; or changing the governing law or dispute-resolution forum. SLA §12 gives examples specific to the SLA. An amendment that raises a commitment, makes a remedy easier to obtain or larger, or corrects or clarifies wording while leaving every right and obligation as it was, is not adverse, provided it is not adverse in any other respect. An amendment that is adverse in any respect is adverse as a whole. Where these ToS or a document they incorporate refer to a \u0026ldquo;materially adverse\u0026rdquo; change, they mean an adverse amendment in this sense.\nAn adverse amendment takes effect only after at least 30 days\u0026rsquo; prior written notice. The Customer may terminate without penalty, 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.\nAn amendment that is not adverse takes effect on publication. fremverk is bound by it from that date, and the Customer does not need to accept it to rely on it.\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). This does not delay an amendment that is not adverse, which binds fremverk from publication as set out above. Mere continued use of the Service does not constitute acceptance of an adverse amendment. On renewal, the then-current version applies subject to the 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 Public, 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, except as this §19 provides. The Customer may transfer this agreement, in whole or in part, as set out in §3 (Moving the Subscription) without fremverk\u0026rsquo;s consent. A change in who controls the Customer, or a reorganisation that leaves the Customer\u0026rsquo;s legal entity unchanged, is not an assignment and needs no consent. 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.12 2026-10-05 §3, §7.5(a) and §19 — the Customer may use the Service across its group and move its Subscription after a reorganisation, for every Customer. §3 granted a non-transferable right for the Customer\u0026rsquo;s own internal business purposes, §7.5(a) granted a non-transferable, revocable CLI licence on the same basis, and §19 let the Customer assign only with fremverk\u0026rsquo;s consent. §3 now extends use to the Customer Group: for a public-sector Customer, the bodies within its authority or group and any new or changed authority that takes over its functions after a reorganisation; for a Customer under private law, its parent and every entity the parent controls. The Customer may move all or part of its Subscription to a member of the Customer Group, and a Customer that buys on behalf of other public authorities may move it between them, as may municipalities, regions and comparable public bodies. It gives fremverk written notice and, where the holder or its name changes, has fremverk\u0026rsquo;s standard change-of-name or assignment document signed. fremverk charges no fee, and seat, plan and other limits are unchanged. §3 also states that the Service may be used from any country, subject only to §6.5; where Customer Content is hosted does not change. §19 needs no consent for those transfers, and a change of control of the Customer is not an assignment. The §7.5(a) CLI licence follows the same scope, moves with the Subscription, and lasts as long as the right to use the Service rather than being revocable. §1.1 defines Customer Group and includes its people as Users. Driver: public-sector procurement terms (SKI 02.06 K5, usage terms 4 and 5) require organisational use and transfer rights and use in every country where the customer operates; the same rights are given to every Customer rather than per contract. Not materially adverse under ToS §17: it widens Customer rights and removes none; the notice and document apply only when a Customer chooses to use the new transfer right. Effective on publication, no notice period. Paired with monolith, where terms 1.11 → 1.12 is a widening-only step, so tenants who accepted 1.11 raise no acknowledgement banner. 1.13 2026-10-10 Effective 2026-11-09. Materially adverse. Announced by notice 634f47e8-4e3e-4466-9b78-1bd4ffe6e663 on 2026-10-10 (as terms 1.13), together with DPA 1.49. §2 — single sign-on is OIDC only; SAML is not offered, and never was. §2 listed \u0026ldquo;Single sign-on enforcement via OIDC and SAML\u0026rdquo; in the description of the Service. Measured 2026-10-10: the Forgejo release fremforge runs has no SAML authentication source, no fremforge patch adds one, and the SAML registration endpoint and assertion consumer URL both answer 404, so no SAML sign-in has ever been possible. §2 now says OIDC. It reduces the functionality the Service description covers, which §17 names as an adverse amendment, so it takes effect 30 days after the notice, with the §17 termination right. No change to what the Service does. 1.11 2026-10-03 §16.5 — post-termination export window raised from 60 to 90 days, for every Customer. Customer Content is now retained for 90 days after termination to allow export, then deleted per DPA §9; §16.6(f) refers to the 90-day window. Driver: public-sector procurement terms (SKI 02.06 usage term 6) require 90 days\u0026rsquo; free access to data and data transfer after expiry, and the same period is given to every Customer rather than per contract. DPA 1.38, Privacy Notice 1.18 and AUP 1.7 move with it. Not materially adverse under ToS §17: it lengthens a Customer right and takes nothing away; the Customer may still export, and ask for deletion, earlier. Effective on publication, no notice period. Paired with monolith, where the deletion clock (READONLY_GRACE_DAYS) moves from 60 to 90 days, so the code keeps data for the period this document promises. 1.10 2026-10-01 §17 now decides whether an amendment is adverse by its effect on the Customer. It required 30 days\u0026rsquo; notice for every amendment and called a change materially adverse only if it fell in one of four listed categories. Read literally, that delayed changes in the Customer\u0026rsquo;s favour, such as 1.9 and SLA 1.6 to 1.8, while a harmful change outside the four categories carried no termination right. An amendment is now adverse if it reduces a right of the Customer or a commitment of fremverk, makes a remedy harder to obtain or smaller, or adds an obligation, restriction or cost for the Customer; the four categories remain as examples. An adverse amendment takes effect only after 30 days\u0026rsquo; written notice and gives the Customer the right to terminate without penalty, with a pro-rata refund. An amendment that is not adverse takes effect on publication and binds fremverk from then. An amendment that is adverse in any respect is adverse as a whole. \u0026ldquo;Materially adverse\u0026rdquo; elsewhere in the bundle now means adverse in this sense. Made in step with SLA 1.9 (§12), which now takes the rule from this section. Every amendment that had the termination right still has it, more amendments now have it, and the only notice removed is for amendments that are not adverse in any respect, so it is not adverse within §17, and takes effect on publication. 1.9 2026-10-01 §11 — the standard plan\u0026rsquo;s availability commitment is now 99.9% per month, up from 99.5%, made in step with SLA 1.6, which also raises every service-credit band. Nothing else in these ToS moves. It raises a commitment fremverk makes and removes no Customer right, so it is not materially adverse within §17, and takes effect on publication. 1.8 2026-08-13 §7.2 updated — the fremforge mark is now REGISTERED. The European Union trade mark fremforge (EUIPO, EUTM no. 019356995, Nice classes 9, 35 and 42) was registered on 2026-08-13, unopposed — the application was published 2026-05-05 and the opposition period closed 2026-08-05 with no oppositions filed. §7.2 previously described fremforge™ as \u0026ldquo;a trademark of fremverk ApS for which a registration application is pending\u0026rdquo;, asserted as an unregistered mark and expressly not held out as registered. That wording was accurate when written in v1.4 and is now simply out of date; it reads fremforge®, a registered European Union trade mark. Nothing else in §7.2 moved: ownership is unchanged, the Customer is still granted no licence to use the names, marks or logos, and the nominative-use permission added in v1.4 is untouched — a Customer may continue to refer to fremverk and fremforge by name for factual and descriptive purposes, including describing its own toolchain and integrations, without a licence. The amendment is status-reflecting rather than rights-changing: it confers no new right on fremverk as against the Customer, imposes no new obligation, and restricts nothing the Customer could do the day before. Not materially adverse within §17, and effective on publication. As in v1.4, the register, registration number and Nice classes are held in fremverk\u0026rsquo;s internal trademark log rather than recited in the Terms, so a renewal or a further filing does not require a contract amendment. 1.7 2026-08-11 §4.1 — DKK invoicing added for Enterprise-on-Demand customers on invoice terms. The clause previously read \u0026ldquo;fremverk does not bill in any other currency\u0026rdquo; than EUR, which is no longer accurate: an Enterprise-on-Demand Customer invoiced against a purchase order may now agree in its ordering document to be invoiced in DKK. The card and SEPA Direct Debit paths remain EUR-only and are stated as such. The clause also now says plainly that the currency election does not re-denominate invoices already issued, and repeats — because it is the question this most often prompts — that VAT follows the Customer\u0026rsquo;s country of establishment and VIES status, not the invoice currency, so a Danish Customer\u0026rsquo;s 25% VAT is unaffected either way. Not materially adverse within §17: it adds an option available only by mutual agreement in a negotiated ordering document, removes no right, and changes no price. Effective on publication. 1.6 2026-08-05 CVE-patching phasing withdrawn from §10 and from the §13 warranties. Both now state the contractual targets in force now (Critical 48h / High 72h / Medium 7 days), replacing \u0026ldquo;commercially reasonable efforts against weaker Phase 1 targets until 2027-Q1\u0026rdquo;. The warranty half is the material change: it previously warranted only best efforts until the funded 24/7 on-call rotation went live, which would have left the warranty contradicting the commitment DPA Annex A.8 makes. Made in step with DPA 1.30 and SLA 1.5. NOT adverse to Customers — the warranty strengthens. 1.5 2026-08-04 Corrected the hosted-runner platform: runners are ephemeral T Cloud Public Elastic Cloud Server virtual machines, one per job, not Cloud Container Instance containers. The CCI model was pre-launch intent and never shipped; cce-node-image was archived 2026-06-24. DPA Annex A.5 was corrected on 2026-08-04 but this document was not, because the regression guard added at the time checked only the DPA. No control is weakened — per-job VMs give strictly stronger isolation than shared-kernel containers, so the substance (no shared kernel between tenant jobs) is unchanged and now accurately described. Not materially adverse under the Terms §1.2 test. 1.0 2026-04-25 Initial publication. 1.4 2026-08-04 §7.2 revised — trademark status stated, and a nominative-use permission added. The fremverk word mark is a registered Danish trademark (DKPTO reg. no. VR 2026 01041, registered 2026-07-13, class 42 — this row first said \u0026ldquo;granted on 2026-08-04\u0026rdquo;, which was the date the grant was noticed internally, not the registration date); §7.2 previously named only \u0026ldquo;the fremforge trademark\u0026rdquo; and asserted no fremverk mark at all. The clause now distinguishes the two: fremverk® is registered, while fremforge™ is an unregistered mark with an application pending and is expressly not held out as registered — the distinction matters because asserting ® on a pending application is misleading marking under DK markedsføringsloven §5 and the equivalent provisions in other jurisdictions where the sites are reachable. A third paragraph confirms that factual, nominative reference to the fremverk and fremforge names requires no licence (a Customer may describe its own toolchain and integrations freely), while implying endorsement, partnership, certification, or common origin needs written consent, mirroring the reciprocal restriction in §27. Rights-clarifying and rights-conferring — the nominative-use paragraph grants the Customer certainty it did not previously have and imposes no new obligation on it — so not materially adverse within §17; effective on publication. Registration number, register, and Nice classes are held in fremverk\u0026rsquo;s internal trademark log rather than recited in the Terms, so a renewal or a further filing does not require a contract amendment. 1.3 2026-08-04 §7.5 added — fremforge CLI: licence, support period, security updates, SBOM. The CLI is a proprietary single-file executable customers download and run on their own systems; the ToS previously governed only \u0026ldquo;the Service\u0026rdquo; and did not mention it, so a downloaded binary had no licence grant, no warranty or liability allocation, and no support commitment. §7.5 grants a licence for use with a valid Subscription, confirms no separate charge, declares a five-year support period per minor version (the support period within the meaning of Art. 13(8) of Regulation (EU) 2024/2847, the Cyber Resilience Act), commits to free security fixes shipped forward and never gated behind a paid plan, points at the published CycloneDX SBOM, and confirms the CLI is optional — every operation is available through the REST API. Rights-conferring and clarifying, so not materially adverse within §17; effective on publication. 1.2 2026-08-04 §16.6 added — Switching, porting and exit (EU Data Act Chapter VI). Implements Arts. 23–30 of Regulation (EU) 2023/2854: express switching right, two-month maximum notice period, 30-calendar-day mandatory maximum transitional period (extendable to seven months only where technically unfeasible and duly substantiated within 14 working days), 30-day retrieval period, continuity of service and service levels during transition, assistance in good faith, and open machine-readable export formats. §16.6(g) waives switching charges in full, ahead of the 12 January 2027 statutory deadline in Art. 29. §7.3 corrected — the Terms previously stated that fremverk runs Forgejo \u0026ldquo;unmodified\u0026rdquo;; fremverk runs a modified build (a maintained patch series on a pinned upstream commit), and the clause now says so. The GPL analysis and the Customer\u0026rsquo;s position are unchanged by the correction. Neither change is materially adverse within the meaning of §17: §16.6 confers rights on the Customer and imposes obligations only on fremverk, and the §7.3 correction restates an existing fact without altering any right or obligation. Both accordingly take effect on publication; no 30-day notice period is required to confer a benefit, and the §17 termination right for materially adverse changes is not engaged. 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":" Last updated: 2026-10-10\n","title":"fremforge Terms of Service","type":"legal"},{"content":" Vergelijking\nfremforge vs GitHub fremforge is een Europees alternatief voor GitHub: Git-hosting, pull requests, CI/CD-runners, pakketregisters en beveiligingsscans op één platform, beheerd door een Europees bedrijf op T\u0026nbsp;Cloud\u0026nbsp;Public in Duitsland. Deze pagina vergelijkt de twee op prijs, beveiliging, supply chain en datalocatie, op basis van de eigen gepubliceerde pagina’s van GitHub, en zegt eerlijk wat GitHub heeft dat wij niet hebben. Prijs voor een team dat code commit Bij GitHub zijn secret scanning en code scanning op privérepositories betaalde add-ons per actieve committer. Bij fremforge zitten ze in de plaats.\nGitHub Enterprise Cloud 🇺🇸 Amerikaans bedrijf $70/committer/mnd$21 Enterprise Cloud + $19 Secret Protection + $30 Code Security\nEnterprise Cloud \"starting at $21 USD per user/month\" (GitHub-prijzen). Secret Protection kost \"$19 USD per active committer/month\" en Code Security \"$30 USD per active committer/month\" (beveiligingsplannen van GitHub). Een committer is actief als \"one of their commits has been pushed to the repository within the last 90 days\" (facturatiedocumentatie van GitHub). Voor een lid dat commit, is dat $70 per maand; een lid dat nooit commit, kost $21.\nfremforge 🇪🇺 gehost in Duitsland € 30/plaats/mndvast · € 25,50/plaats/mnd bij jaarlijkse facturatie\nSecret scanning met push-bescherming, SAST, scannen van afhankelijkheden, containerimages, IaC en licenties, bereikbaarheid, pull requests met beveiligingsfixes, de dependency-proxy en 1.000 CI-minuten per plaats per maand, allemaal in de prijs per plaats. Prijzen.\nDe prijzen van GitHub staan in USD, zoals gepubliceerd; we hebben ze niet omgerekend. GitHub Team kost $4 per gebruiker per maand en kan dezelfde twee add-ons kopen; het heeft geen SAML-single sign-on en geen IP-allowlist (plannen van GitHub).\nFunctie voor functie Kolom GitHub: wat de eigen documentatie van GitHub zegt, voor privérepositories van een organisatie. Kolom fremforge: wat elke fremforge-plaats bevat.\nFunctieGitHubfremforge Secret scanning en push-beschermingVereist de add-on Secret Protection op Team of Enterprise Cloud (docs)Inbegrepen. Secrets worden geweigerd voordat de commit in de geschiedenis komt, met eigen patronen per organisatie of repository Geldigheidscontrole van secretsAdd-on Secret Protection (docs)Inbegrepen, per aanbieder in te schakelen; de console toont waarheen elke controle wordt gestuurd Code scanning (SAST)CodeQL; vereist de add-on Code Security (docs)Inbegrepen. OpenGrep op elke pull request, standaard aan Meldingen over kwetsbare afhankelijkhedenDependabot-alerts en -beveiligingsupdates in elk plan (docs)Inbegrepen. Trivy en osv-scanner op elke pull request, merge geblokkeerd vanaf de ernst die je kiest Scannen van containerimagesVia scanners van derden die SARIF-resultaten uploaden (docs)Inbegrepen. Elk image dat naar het register wordt gepusht, wordt gescand, met pull requests die het basisimage fixen Scannen van infrastructure-as-codeVia scanners van derden (dezelfde SARIF-route)Inbegrepen. Terraform, Kubernetes, Helm, Dockerfile en Compose, op elke pull request BereikbaarheidEen rangschikkingssignaal voor Dependabot-alerts (\"whether vulnerable function calls are detected\") (docs)Elke bevinding gemarkeerd als bereikbaar, niet bereikbaar of onbekend, met bestand en regel als bewijs. Call graphs voor Go, JavaScript en TypeScript; Python, Java en Kotlin op importniveau Bekend misbruikt eerstEPSS-filter op Dependabot-alerts (docs)Vermeldingen in de EU Vulnerability Database van ENISA en in CISA KEV krijgen een badge, komen bovenaan en worden als eerste gefixt; EPSS binnen een ernstniveau Automatische fixesDependabot-beveiligingsupdates; Copilot Autofix voor code scanning vereist Code Security (docs)Pull requests met beveiligingsfixes voor npm, Go, PyPI, Maven, Gradle, NuGet, Cargo en basisimages, één per pakket, bekend misbruikt eerst; AI-fixes voor geselecteerde SAST-bevindingen met je eigen modelsleutel LicentiecomplianceEnterprise-account met Code Security (docs)Inbegrepen. SPDX-allowlist per repository, overgenomen van de organisatie Dependency-proxy en pakketcacheEen package firewall in public preview voor enterprises, gedocumenteerd voor npm (docs)Inbegrepen en standaard aan: npm, PyPI, Go, Maven, NuGet, Cargo, Helm, RPM en containerimages, gecachet per organisatie. Bekende malware geweigerd, pakketbeleid, minimale leeftijd van releases; blijft leveren als een upstream-register plat ligt MalwareMalware-alerts bij de Dependabot-alerts (docs)Bekende malware geweigerd in de dependency-proxy; ClamAV bij elke upload van pakketten en images SBOM en provenanceSBOM-export voor iedereen; artifact attestations op privérepositories vereisen Enterprise Cloud, SLSA Build Level 2 (docs)SBOM bij elk image dat een runner bouwt; ondertekende SLSA-provenance van de gehoste runners OndertekenenAttestations op Sigstore Public Good voor publieke repositories, de eigen instantie van GitHub voor privérepositories (docs)Sleutelloos ondertekenen met cosign op de eigen Sigstore van fremforge (Fulcio en timestamp authority) in Duitsland; beleid voor image-handtekeningen bij het pullen DeploygoedkeuringenVerplichte reviewers op privérepositories vereisen Enterprise (docs)Inbegrepen. Benoemde omgevingen met secrets, branchregels en verplichte reviewers per omgeving Audit naar je SIEMAudit log streaming op Enterprise Cloud (docs)Inbegrepen. Ondertekende aflevering bij Splunk, QRadar, Sentinel of Datadog; hashgekoppelde audittrail IP-allowlistAlleen Enterprise Cloud (docs)Inbegrepen CI-minuten3.000 per maand op Team, 50.000 op Enterprise Cloud, per account; daarna Linux voor $0.006 per minuut (docs)1.000 per maand per plaats, gedeeld; daarna € 0,01 per minuut; één wegwerp-VM per job Waar je data staat\"your local region, the United States, and other countries\" (privacyverklaring); een optie voor dataresidentie in de EU op Enterprise Cloud, waarbij sommige data buiten de regio wordt opgeslagen (docs)Duitsland, op T\u0026nbsp;Cloud\u0026nbsp;Public van Deutsche Telekom (eu-de). Geen verwerker met een Amerikaanse moedermaatschappij op het datapad Wat GitHub heeft dat fremforge niet heeft Een gratis plan. GitHub Free kost $0. fremforge heeft een gratis proefperiode van 30 dagen, daarna € 30 per plaats. SAML-single sign-on. Bij fremforge log je in via OIDC (Entra ID, Okta, Google Workspace, Keycloak, Authentik en andere), niet via SAML. Zelf hosten. GitHub Enterprise Server draait in je eigen datacenter. fremforge is alleen als gehoste dienst beschikbaar. Copilot. fremforge heeft geen eigen AI; optionele AI-functies werken alleen met een sleutel van je eigen aanbieder. Het ecosysteem. GitHub Marketplace, Codespaces, GitHub Pages en de grootste opensourcecommunity. Gangbare Actions zoals actions/checkout werken op fremforge via mirrors in de EU; sommige Marketplace-actions hebben kleine aanpassingen nodig. Projecten en planning. fremforge heeft issues, labels en milestones, geen GitHub Projects-borden. Overstappen van GitHub De importer kopieert repositories met hun geschiedenis, issues, pull requests en releases. Een kleine repository met eenvoudige Actions kost 15 tot 30 minuten handwerk. Je kunt repositories ook mirroren en op GitHub blijven werken terwijl je overstapt.\nStart je gratis proefperiode van 30 dagen → Lees de migratiegids voor GitHub Elke uitspraak over GitHub op deze pagina komt van de eigen pagina’s van GitHub, gelinkt op de plek waar ze wordt gedaan, en gelezen op 23 oktober 2026. GitHub wijzigt zijn plannen en prijzen; is hier iets verouderd, laat het ons weten via support@frem.sh, dan passen we het aan. GitHub is een handelsmerk van GitHub, Inc. fremforge is niet verbonden aan GitHub.\n","externalUrl":null,"permalink":"/nl/vs/github/","section":"Vs","summary":" Vergelijking\nfremforge vs GitHub fremforge is een Europees alternatief voor GitHub: Git-hosting, pull requests, CI/CD-runners, pakketregisters en beveiligingsscans op één platform, beheerd door een Europees bedrijf op T Cloud Public in Duitsland. Deze pagina vergelijkt de twee op prijs, beveiliging, supply chain en datalocatie, op basis van de eigen gepubliceerde pagina’s van GitHub, en zegt eerlijk wat GitHub heeft dat wij niet hebben. ","title":"fremforge vs GitHub: een Europees alternatief voor GitHub","type":"vs"},{"content":" Vergelijking\nfremforge vs GitLab fremforge is een Europees alternatief voor GitLab: Git-hosting, merge requests in de vorm van pull requests, CI/CD-runners, pakketregisters en beveiligingsscans op één platform, beheerd door een Europees bedrijf op T\u0026nbsp;Cloud\u0026nbsp;Public in Duitsland. Deze pagina vergelijkt de twee op prijs, beveiliging, supply chain en datalocatie, op basis van de eigen gepubliceerde pagina’s van GitLab, en zegt eerlijk wat GitLab heeft dat wij niet hebben. Prijs per plaats Het grootste deel van de beveiligingsscans van GitLab zit in Ultimate, waarvoor GitLab nu alleen op aanvraag een prijs geeft. Bij fremforge zit het in die ene prijs per plaats.\nGitLab Premium 🇺🇸 Amerikaans bedrijf $29/gebruiker/mndjaarlijks gefactureerd\n\"$29 per user/month, billed annually\", met 10.000 compute-minuten per maand (GitLab-prijzen). Scannen van afhankelijkheden, secret push protection, DAST en licentiescans zijn functies van Ultimate (bronnen in de tabel hieronder).\nGitLab Ultimate 🇺🇸 Amerikaans bedrijf $99/gebruiker/mndgerapporteerde catalogusprijs, jaarlijks gefactureerd\nOp de pagina van GitLab staat \"Get custom pricing\", met 50.000 compute-minuten per maand (GitLab-prijzen); $99 per gebruiker per maand, jaarlijks gefactureerd, is de prijs die kopers melden (SpendBase).\nfremforge 🇪🇺 gehost in Duitsland € 30/plaats/mndvast · € 25,50/plaats/mnd bij jaarlijkse facturatie\nSecret scanning met push-bescherming, SAST, scannen van afhankelijkheden, containerimages, IaC en licenties, bereikbaarheid, pull requests met beveiligingsfixes, de dependency-proxy en 1.000 CI-minuten per plaats per maand, allemaal in de prijs per plaats. Prijzen.\nDe prijzen van GitLab staan in USD, zoals gepubliceerd; we hebben ze niet omgerekend. GitLab Free kost $0 voor maximaal 5 gebruikers per top-level group, met 400 compute-minuten per maand (GitLab-prijzen).\nFunctie voor functie Kolom GitLab: de tier die de eigen documentatie van GitLab noemt voor gitlab.com. Kolom fremforge: wat elke fremforge-plaats bevat.\nFunctieGitLabfremforge Secret detection in pipelinesFree en hoger (docs)Inbegrepen Secret push protectionUltimate (docs)Inbegrepen. Secrets worden geweigerd voordat de commit in de geschiedenis komt, met eigen patronen per organisatie of repository Geldigheidscontrole van secretsUltimate (docs)Inbegrepen, per aanbieder in te schakelen SASTBasisscans in elke tier; bevindingen in merge requests en Advanced SAST in Ultimate (docs)Inbegrepen. OpenGrep op elke pull request, bevindingen op de pull request Scannen van afhankelijkhedenUltimate (docs)Inbegrepen. Trivy en osv-scanner op elke pull request Scannen van containersScannen in elke tier; weergaven in merge requests en in het beveiligingsoverzicht in Ultimate (docs)Inbegrepen. Elk gepusht image gescand, met pull requests die het basisimage fixen Scannen van infrastructure-as-codeScannen in elke tier; verwerking van resultaten in Ultimate (docs)Inbegrepen. Terraform, Kubernetes, Helm, Dockerfile en Compose BereikbaarheidStatische bereikbaarheid, Ultimate (docs)Inbegrepen. Bereikbaar, niet bereikbaar of onbekend, met bestand en regel als bewijs Bekend misbruikt en EPSSKEV en EPSS op de detailpagina van een kwetsbaarheid, Ultimate (docs)Inbegrepen. Vermeldingen in de EU Vulnerability Database van ENISA en in CISA KEV komen bovenaan en worden als eerste gefixt; EPSS binnen een ernstniveau Automatische fixesAutomatisch herstel bij container scanning en agentische SAST-oplossing, Ultimate (docs)Inbegrepen. Pull requests met beveiligingsfixes voor npm, Go, PyPI, Maven, Gradle, NuGet, Cargo en basisimages; AI-fixes voor geselecteerde SAST-bevindingen met je eigen modelsleutel LicentiecomplianceUltimate (docs)Inbegrepen. SPDX-allowlist per repository DASTUltimate (docs)Niet beschikbaar Dependency-proxyContainerimages in elke tier, als pull-through cache (docs); een virtueel register voor andere formaten in bèta, Premium en hoger (docs)Inbegrepen en standaard aan: npm, PyPI, Go, Maven, NuGet, Cargo, Helm, RPM en containerimages, met bekende malware geweigerd, pakketbeleid en een minimale leeftijd van releases SBOMLijst met afhankelijkheden en export, Ultimate (docs)SBOM bij elk image dat een runner bouwt; ondertekende SLSA-provenance OndertekenenSleutelloos ondertekenen met Sigstore in CI (docs)Sleutelloos ondertekenen met cosign op de eigen Sigstore van fremforge in Duitsland; beleid voor image-handtekeningen bij het pullen Beschermde omgevingenPremium en hoger (docs)Inbegrepen. Verplichte reviewers per omgeving Audit naar je SIEMAudit event streaming, Ultimate (docs)Inbegrepen. Ondertekende aflevering bij Splunk, QRadar, Sentinel of Datadog IP-allowlistPremium en hoger (docs)Inbegrepen Waar je data staat\"hosted in the United States\" voor gitlab.com (privacyverklaring); een keuze uit regio’s, waaronder EU-regio’s, met GitLab Dedicated, een single-tenant Ultimate-aanbod op AWS (docs)Duitsland, op T\u0026nbsp;Cloud\u0026nbsp;Public van Deutsche Telekom (eu-de). Geen verwerker met een Amerikaanse moedermaatschappij op het datapad Wat GitLab heeft dat fremforge niet heeft Een gratis plan. GitLab Free kost $0 voor maximaal 5 gebruikers. fremforge heeft een gratis proefperiode van 30 dagen, daarna € 30 per plaats. Self-managed en Dedicated. GitLab draait in je eigen omgeving of als single-tenant-instantie. fremforge is alleen als gehoste dienst beschikbaar. SAML-single sign-on. Bij fremforge log je in via OIDC (Entra ID, Okta, Google Workspace, Keycloak, Authentik en andere), niet via SAML. DAST. fremforge doet geen dynamische applicatiebeveiligingstests. Planning. Epics, roadmaps en iteraties. fremforge heeft issues, labels en milestones. GitLab CI-syntaxis. De CI van fremforge gebruikt de workflowsyntaxis van GitHub Actions, dus pipelines in .gitlab-ci.yml worden herschreven als workflows. De migratiegids laat zien hoe. Overstappen van GitLab De importer kopieert repositories met hun volledige geschiedenis, issues, merge requests (als pull requests), labels, milestones, wiki’s en releases. Een kleine repository met een eenvoudige .gitlab-ci.yml kost 30 tot 60 minuten, inclusief de pipeline.\nStart je gratis proefperiode van 30 dagen → Lees de migratiegids voor GitLab Elke uitspraak over GitLab op deze pagina komt van de eigen pagina’s van GitLab, gelinkt op de plek waar ze wordt gedaan, en gelezen op 23 oktober 2026. GitLab wijzigt zijn tiers en prijzen; is hier iets verouderd, laat het ons weten via support@frem.sh, dan passen we het aan. GitLab is een handelsmerk van GitLab Inc. fremforge is niet verbonden aan GitLab.\n","externalUrl":null,"permalink":"/nl/vs/gitlab/","section":"Vs","summary":" Vergelijking\nfremforge vs GitLab fremforge is een Europees alternatief voor GitLab: Git-hosting, merge requests in de vorm van pull requests, CI/CD-runners, pakketregisters en beveiligingsscans op één platform, beheerd door een Europees bedrijf op T Cloud Public in Duitsland. Deze pagina vergelijkt de twee op prijs, beveiliging, supply chain en datalocatie, op basis van de eigen gepubliceerde pagina’s van GitLab, en zegt eerlijk wat GitLab heeft dat wij niet hebben. ","title":"fremforge vs GitLab: een Europees alternatief voor GitLab","type":"vs"},{"content":" Scope # fremverk maintains a controller-side incident-response runbook governing our response to Personal Data Breaches affecting fremverk-as-Controller processing activities — breaches where fremverk owes the GDPR Art. 33 (72-hour Datatilsynet notification) and Art. 34 (data-subject communication) duties directly, rather than in our role as a Customer-as-Controller\u0026rsquo;s processor.\nFor Customer-Controller breaches — a sub-processor compromise affecting Customer Personal Data, or an exposure caused by Customer-tenant misconfiguration — the processor-side flow in DPA §§8.1–8.2 applies instead.\nThe runbook is in force. It is referenced by DPA §8.5 and by the Audit-Monitoring DPIA.\nWhat it covers # Breach-severity classification and the criteria for each class. The Art. 33 notification decision and its 72-hour clock, including the assessment of whether a breach is likely to result in a risk to data subjects. The Art. 34 data-subject communication decision and threshold. Incident roles, and how the dual-role of privacy contact and incident commander is managed to avoid a conflict of interest. Containment, evidence-preservation, and post-incident review steps. The customer-notification template used for processor-side breaches. Availability # The runbook itself is classified internal. It contains operational detail — infrastructure identifiers, internal escalation contacts, and step-by-step recovery procedures — that would weaken our security posture if published, so this page carries the scope and coverage rather than the document.\nCustomers, prospective customers under evaluation, and auditors can obtain the full runbook under NDA. Email compliance@frem.sh with your organisation name and the purpose of the request.\nFor the incident-notification commitments that are contractually binding on fremverk, see DPA §8 and SLA §6 — those are public and are the authoritative statement of what we owe you.\n","externalUrl":null,"permalink":"/legal/controller-incident-response/","section":"Legal documents","summary":" Scope # fremverk maintains a controller-side incident-response runbook governing our response to Personal Data Breaches affecting fremverk-as-Controller processing activities — breaches where fremverk owes the GDPR Art. 33 (72-hour Datatilsynet notification) and Art. 34 (data-subject communication) duties directly, rather than in our role as a Customer-as-Controller’s processor.\n","title":"fremverk Controller-side Incident Response","type":"legal"},{"content":" Records of Processing Activities # Last updated: 2026-10-10\nVersion: 1.13\nThis 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 Public (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 Public + 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 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 Public RDS (session-row store); T Cloud Public DCS Redis (ephemeral session cache, see DPA Annex A.4 amendment). Customer-side: the Customer\u0026rsquo;s own OIDC 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 Public SFS Turbo (git object store); T Cloud Public OBS (LFS objects + repository-archive snapshots); T Cloud Public RDS (Forgejo\u0026rsquo;s metadata DB — issues, PRs, users, hooks). International transfers None. T Cloud Public eu-de only. Retention Active repository content: lifetime of the tenancy. After cancellation: 90-day post-cancellation export window, primary deletion within 30 days after it, then expiry from the encrypted live-tier backups within up to 90 days (DPA §9). After repository deletion within an active tenancy: up to 90 days in the encrypted backups before they expire (the same live-tier backup lifecycle as DPA §9 + Annex A.9 — 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).Supply-chain artefacts derived from repository content — SBOMs (CycloneDX) + SLSA build attestations, stored KMS-encrypted in a dedicated T Cloud Public OBS bucket — follow a tiered retention enforced by the /jobs/sbom-prune sweep (not a flat bucket hold): release artefacts (default branch + release tags, per the org\u0026rsquo;s code-security → SBOM policy) are kept for the lifetime of the tenancy + the 90-day post-cancellation window (matching repository content above); non-release (branch/PR) SBOMs are deleted after the org\u0026rsquo;s configured keep_non_release_days (default: not retained); all SBOMs/attestations are deleted on tenancy termination. These artefacts list software component names/versions + repository file paths (no special-category data). fremverk\u0026rsquo;s own platform SBOMs are retained for the product support period per EU CRA (Reg 2024/2847) Annex I. TOMs KMS-encrypted-at-rest (SFS Turbo + OBS); per-tenant access control (Forgejo orgs); webhook-egress filtered through outbound proxy when implemented (currently restricted to an allowlist of individual destination addresses that an automated job keeps current). 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 Public 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 Public LTS (log store); T Cloud Public OBS WORM bucket (3-year audit archive — per DPA Annex A.7); T Cloud Public 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 (the API log group, which carries the HTTP access log — request path, user-agent, IP — and the operational-audit log group): 30 days hot. The api group held 90 days until 2026-09-06; the figure came from an incident-look-back convenience, not from anything published, and the Privacy Notice has always told data subjects 30. Cut to 30 in the infrastructure configuration on 2026-09-06 so the hot tier matches the disclosed period. The three groups this row named until then (api/forgejo/jobs) were separate log groups, since deleted because nothing ever shipped to them; the groups above are where the logs actually land. Known gap, disclosed rather than implied: no operational log generated before 2026-09-06 is in the WORM archive. The LTS→OBS transfer for these groups was created on 2026-09-06 and LTS cycle transfers carry only logs generated after the task exists. The one-off transfer that can target a historical range is console-only — the LTS v2 API rejects every one-time transfer mode with LTS.0424, and a one-off task cannot select a stream that already has OBS transfer settings — so the pre-2026-09-06 window could not be backfilled by any supported path. The gap is bounded and closed: it covers 2026-05-02 (group creation) to 2026-09-06, and every operational log from 2026-09-06 onward is archived for 3 years per DPA Annex A.7. This affects fremverk\u0026rsquo;s own diagnostic record only; the audit trail a Customer or regulator would ask for lives in the audit-event table and is archived in full by the daily audit-event export (flow (c) below), unaffected. 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 / the operator-provisioned custom trial / internal plans (Customer tenant admin sets the tier at Authentication policy → Audit log retention; a database constraint enforces 1 to 730 days). After the per-tenant cutoff, an automated redaction job sets the actor and payload fields to null while the SHA-256 chain hashes are retained for the full 3-year window. Hash-chain anchor objects in the WORM archive: 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 scheduled jobs on the platform touch this data:(a) Log-volume 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) Audit-chain anchor verifier (hourly) — walks each tenant\u0026rsquo;s anchor objects in timestamp order, checks that every anchor\u0026rsquo;s prev_anchor_head matches the preceding anchor\u0026rsquo;s anchor_head, and pages on-call on a mismatch. Reads anchor objects only (hash + count + identifier); no entry contents. This is the hourly integrity check committed in DPA Annex A.7.(c) Audit-event archive export (daily, 02:40 UTC) — writes the audit-event rows themselves to the WORM archive as one compressed file per day with a SHA-256 checksum alongside, COMPLIANCE-locked for 1095 days. This is what implements the 3-year immutable archive of entry contents; rows already flagged tenant_erased_at or payload_redacted_at at export time are excluded, so an erasure completed before a nightly run is honoured in full (see §2.3 and DPA Annex A.7).(d) Audit-chain anchoring (every 2min) — per-tenant integrity flow committed in DPA Annex A.7. For each tenant with new audit-event 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 identifier, chain hash, event count, timestamp) to the WORM archive. Event payloads themselves are NOT copied — only the hash + count + identifier triple. From 2026-11-03, DPA Annex A.7 (1.41) commits to anchoring at least every 5 minutes, which this cadence meets; until then it states the 2-minute cadence itself. It anchors the per-tenant audit-event 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.Retired flow, recorded for completeness. Until 2026-08-02 a per-stream pair of jobs (an archive-and-anchor job every 5min and an anchor verifier hourly) anchored four LTS log streams in the WORM archive. Both CronJobs were removed on 2026-08-02 together with the LTS-based pipeline they belonged to: the log field that pipeline consumed was never emitted by the platform, so the four transfer sources carried no log lines and the anchors recorded the digest of an empty query response rather than of audit content. No Personal Data was lost — the audit trail those anchors were meant to cover lives in the audit-event table in the database and is now archived in full by (c). The 104,510 objects those jobs already wrote remain in place and cannot be altered or deleted before their retention expires, which is why they are disclosed here rather than described as removed. 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 jobs above authenticate as one shared platform service identity bound to five project-scoped roles: full access to the log service (read streams and query content); publishing to the on-call alerting topics; read-only access across services, which the alert-publishing role requires; object read and write on the WORM bucket, restricted by bucket policy to the anchor objects; and data-key operations on the WORM encryption key so encrypted writes succeed. The credential is provisioned by infrastructure-as-code and held as a secret in the production environment. It is a shared platform credential rather than a per-job one: as of 2026-08-05 roughly 35 scheduled jobs on the platform use it, the large majority only to publish alerts. The jobs that use it to reach the WORM bucket on the paths described above are the audit-chain anchoring job, the anchor verifier, the daily audit-event export and a weekly restore rehearsal that reads one archived object back. This record previously named only the two retired per-stream jobs plus an edge-configuration job and asserted that \u0026ldquo;no other automated read-paths exist\u0026rdquo;, which understated the breadth of the shared credential; narrowing it to per-job credentials is tracked as platform work, and until then the accurate statement is the one given here. 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 Public 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; DDoS mitigation at the edge, which blocks volumetric attack traffic. No Web Application Firewall is enabled at the edge, deliberately — see DPA Annex A.2 and the trust page for the reasoning and the compensating application-layer controls. Corrected 2026-08-04 (DPA 1.25): this row previously claimed a Web Application Firewall at the edge, which was never the posture on any fremforge surface during the paying-Customer period. 2.8 Opt-in product-update email # Field Value Purpose Tell organisation owners who asked for it about significant new features and interface changes in fremforge, one short email per significant changelog entry, sent by an operator by hand; and keep the proof that each recipient consented. Product Privacy Notice §3.9 (from 1.22, effective 2026-11-06). Lawful basis Article 6(1)(a) — consent, which is also the prior consent the Danish Marketing Practices Act (markedsføringsloven) §10 requires for electronic marketing. Off by default; given only by the user turning on Product updates in their notification settings; withdrawn by the same setting or the one-click unsubscribe link in every email (also the RFC 8058 one-click header). Article 7(1) — the consent record is kept to demonstrate consent. Categories of data subjects fremforge users who turned the setting on. Emails go only to those who are, at the time of the send, owners of at least one organisation under contract. Categories of personal data Forgejo username; primary email address; interface language; which organisations the user owns (resolved at send time, not stored beyond the send plan); the consent record (each opt-in and opt-out with time, channel and the wording version agreed to); per email: address, language, send time, delivery status and any bounce. No special-category data. Recipients (internal) Operators in operators-sre who draft and send the email. The console shows them counts only, never an address. Agents and API tokens have no access: there is no API and no job that sends. Recipients (sub-processors) T Cloud Public RDS (consent record, send plans, delivery records); Lettermint B.V. (email delivery, NL). International transfers None. Retention The setting: as long as the account exists. Consent record (each opt-in and opt-out): 3 years after the later of withdrawal of consent and deletion of the account. Delivery records (address, language, time, status) and the recipient plan of each send: 3 years after sending. Both enforced by the daily retention job (policies product_update_consent_records and product_update_send_records); an account is treated as deleted only when Forgejo\u0026rsquo;s user table definitely no longer has it. TOMs Send only from the operator console, for an operators-sre session with an MFA re-authentication from the last 10 minutes, the typed reference and a recipient dry run under an hour old; refused while the Product Privacy Notice in force does not describe this processing (before 1.22, 2026-11-06). Each recipient\u0026rsquo;s consent re-checked immediately before their email goes. Consent record append-only at database level (deletions only by the retention job). Unsubscribe links are signed tokens that can only withdraw consent. TLS-in-transit; KMS-encrypted-at-rest (RDS). 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 Public 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). 3A. Art. 37 DPO re-evaluation — 2026-08-16 # The DPO assessment recorded in the header is dated 2026-05-10 and is re-evaluated \u0026ldquo;annually … or sooner on material change to processing scope.\u0026rdquo; Three material changes have landed since that date, so the second trigger has fired ahead of the annual one. This section is the record it requires.\nProcessing added since 2026-05-10\nChange Effective What it adds Customer-configured AI vendors (BYOK) DPA v1.13 Annex B §B.8, 2026-05-24 Repository content and PR diffs transit fremverk\u0026rsquo;s api to a Customer-chosen vendor. fremverk holds no key, sets no default, and retains no prompt or response — ai_usage_events has no column able to hold either. Partner programme 2026-08 Partner company and signatory data, cross-tenant by design; electronic execution of fremverk\u0026rsquo;s own counterparty agreements via Addo Sign, using national eID (MitID Erhverv, FrejaOrg, Norwegian BankID, FTN). fremai 2026-08 Separate product on the shared cluster, separate namespace and database. Assessment against Art. 37(1)\n(a) Public authority or body — unchanged. fremverk ApS is a private company; none of the three changes alters that. (b) Core activities requiring regular and systematic monitoring of data subjects on a large scale — the core activities remain Git hosting and CI infrastructure. The AI feature processes repository content at the Customer\u0026rsquo;s instruction and under the Customer\u0026rsquo;s own vendor contract; it does not monitor data subjects\u0026rsquo; behaviour. Audit logging records operator and Customer actions on the Service, which is security telemetry for a processor, not systematic monitoring of data subjects as a core activity. The partner programme concerns a small number of business counterparties, so it is not large-scale on any reading. (c) Large-scale processing of Art. 9 special-category or Art. 10 criminal-offence data — none of the three introduces either. National eID credentials are identity-assurance data, not special-category: they evidence who signed, and carry no data revealing health, biometrics used for unique identification, or the other Art. 9 categories. Determination.\nThe Art. 37(1) analysis is unchanged. A DPO designation is not required, and compliance@frem.sh continues as the published privacy contact and DPO-equivalent for data-subject and supervisory-authority correspondence.\nDetermined by fremverk\u0026rsquo;s Compliance Officer (compliance@frem.sh) on 2026-08-16, having considered each of the three processing changes above against all three Art. 37(1) limbs.\nNext re-evaluation: the annual review falls due 2027-05-10, or sooner on the next material change to processing scope. The trigger is deliberately recorded as a dated section rather than a header field, because the header field said only when the assessment was made and could not show that a trigger had fired and been answered.\n4. Change-log # Version Date Change 1.0 2026-05-03 Initial publication. Replaces the placeholder reference in Privacy Notice §2 and fremverk\u0026rsquo;s internal product plan. 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. 1.3 2026-06-19 §2.3 Retention: documented the supply-chain artefact (SBOM + SLSA attestation) tiered-retention policy now enforced in code by /jobs/sbom-prune — release artefacts kept tenancy-lifetime +90d (matching repository content), non-release deleted per the org\u0026rsquo;s keep_non_release_days (default: not retained), all purged on tenancy termination; fremverk\u0026rsquo;s own platform SBOMs kept for the CRA Annex I support period. Reconciles the previously-undocumented (and over-broad \u0026ldquo;retain forever\u0026rdquo;) SBOM storage. 1.4 2026-08-04 §2 technical-measures row for the signup activity corrected: it read \u0026ldquo;Bunny Shield Advanced WAF\u0026rdquo;. No fremforge surface runs the Shield WAF — every pull zone is at the Basic tier with the WAF disabled, deliberately, since 2026-05-09. The row now states Shield Basic DDoS protection in Block mode and points to DPA Annex A.2 for the reasoning and the compensating application-layer controls. Corrected in lockstep with DPA 1.25, which carries the full account, the measurement, and the counsel question on disclosure. No processing activity, legal basis, retention period, recipient or transfer changes. 1.5 2026-08-05 Editorial: this record now states its own version where a reader can see it. It carried no version: frontmatter and no in-body marker, so the only way to tell which revision you were reading was to scroll to this table — and the published page at www.frem.sh/legal/ropa/ showed no version at all. Added version: \u0026quot;1.5\u0026quot; plus a **Version:** line under the heading, matching the other six published documents. Deliberately NOT added to the monolith\u0026rsquo;s LEGAL_DOC_VERSIONS: that constant drives legalVersionsDrifted(), which raises a tenant acknowledgement banner, and this is an Article 30 record fremverk keeps as controller — not a document a Customer accepts. Wiring it there would ask every tenant to re-acknowledge a record they are not party to. Its internal consistency is gated instead by the ropa-states-its-own-version claim. No processing activity, legal basis, retention period, recipient or transfer changes. 1.6 2026-08-05 §2.5 described two integrity CronJobs that no longer exist. lts-archive-and-anchor (every 5min) and lts-anchor-verifier (hourly) were removed on 2026-08-02 with the LTS-based pipeline they belonged to, and this record still described both as live processing flows, still attributed the 3-year archive of entry contents to LTS transfer tasks, and did not mention audit-events-worm-export — the job that has actually performed that archive since 2026-08-02. The removed pipeline was non-functional for its whole life: the log field it consumed was never emitted, so it anchored the digest of an empty query response. No Personal Data was lost and no commitment is withdrawn — DPA Annex A.7\u0026rsquo;s substance (2-minute anchoring, hourly verification, pages on mismatch, 3-year immutable archive) is delivered by audit-chain-anchor, audit-chain-anchor-verifier and audit-events-worm-export, all verified running on 2026-08-05. The 104,510 objects already under chain-anchors/ are disclosed as retained-and-immutable rather than deleted, because WORM retention means they cannot be removed. §3 TOMs corrected in the same pass: it named only the two retired jobs plus bunny-edge-refresher as users of lts-quota-guard-creds and asserted \u0026ldquo;no other automated read-paths exist\u0026rdquo;, where ~35 CronJobs in fact mount that credential. Editorial accuracy correction to a register, not a change to processing; effective on publication. 1.7 2026-08-16 §3A added — Art. 37 DPO re-evaluation. The header assessment (2026-05-10) re-evaluates annually or sooner on material change to processing scope; three such changes landed since (BYOK AI vendors per DPA §B.8, the partner programme incl. national-eID signing, fremai). The trigger had fired with no artefact recording it. §3A walks all three Art. 37(1) limbs against those changes. Determination: unchanged — no DPO required, made by the Compliance Officer 2026-08-16. Cadence stays annual; next scheduled re-evaluation 2027-05-10. 1.8 2026-09-06 §2.5 Retention corrected on both halves. (1) It named api/forgejo/jobs LTS groups; those were fremforge-prd-lts-* and were deleted in platform-foundation#1078 as groups nothing ever shipped to, so the row described the retention of three things that do not exist. It now names the live groups. (2) The live fremforge-api-prd-api group — the one holding HTTP access logs with IP, path and user-agent — was set to 90 days hot against a Privacy Notice that has always said 30. That is over-retention measured against our own published period, and it is now cut to 30 (monolith .infrastructure/main.tf, 2026-09-06). (3) A known gap is disclosed rather than left implied: no operational log generated before 2026-09-06 reached the WORM archive, because the LTS→OBS transfer was only created that day and cycle transfers do not backfill; the one-off transfer that could target the historical window is console-only and is refused on a stream that already has OBS transfer settings. The window is bounded (2026-05-02 to 2026-09-06) and affects fremverk\u0026rsquo;s diagnostic logs only — the audit_events trail behind DPA Annex A.7 is archived in full and is not affected. Retention period SHORTENED and a factual gap disclosed; no change to purpose, legal basis, recipients or transfers. 1.9 2026-10-04 Internal names replaced by descriptions. §2 named log groups, storage paths, scheduled-job names, a database migration, an IAM user, a Kubernetes secret and namespace, and an internal manifest; it now describes each by what it is and does, with the same cadences, roles, retention periods and recipients. The signup row describes the edge protection by what it does instead of by the vendor\u0026rsquo;s plan tier, and still states plainly that no Web Application Firewall is enabled at the edge. §3A names the Compliance Officer role and its published address (compliance@frem.sh) instead of a personal address. No processing activity, legal basis, retention period, recipient or transfer changes: a clarification, not materially adverse. 1.10 2026-10-04 Repository-content retention row: after cancellation, the 90-day export window, primary deletion within 30 days, then expiry from the encrypted live-tier backups within up to 90 days (DPA 1.40 §9); after repository deletion in an active tenancy, up to 90 days in the backups (was \u0026ldquo;14 days\u0026rdquo;, which matched no backup tier). Records the lifecycle that operates. 1.11 2026-10-04 §2.5 flow (d): records that DPA Annex A.7 states a bound from 2026-11-03 (at least every 5 minutes, DPA 1.41), which the 2-minute job meets. The recorded cadences are unchanged. This is a record of processing, not a Customer commitment, so it takes effect on publication. 1.12 2026-10-07 §2.8 added — opt-in product-update email (SKI K71): purpose, consent as lawful basis (Art. 6(1)(a), markedsføringsloven §10), data, recipients, the 3-year retention periods Product Privacy Notice 1.22 §6 publishes and the retention job that enforces them, and the send controls. The activity starts on 2026-11-06, when privacy 1.22 takes effect; no email is sent before then. 1.13 2026-10-10 §2.2 Authentication + session management — OIDC, not SAML. The categories and recipients rows named \u0026ldquo;OIDC/SAML\u0026rdquo; subject identifiers and identity providers. fremforge offers single sign-on over OIDC only; SAML is not offered, and never was. Both rows now say OIDC. An Article 30 record, not part of the Agreement, so ToS §17 does not apply; updated on publication, in step with DPA 1.49 and Privacy Notice 1.25. ","externalUrl":null,"permalink":"/legal/ropa/","section":"Legal documents","summary":" Records of Processing Activities # Last updated: 2026-10-10\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 - scope and availability of the runbook for breaches affecting fremverk-as-Controller activities (per DPA §8.5). The runbook itself is classified internal and is available to customers and auditors under NDA. Website notices # The marketing website at www.frem.sh is governed by separate, narrower notices that cover only the marketing site (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":"Voor adviesbureaus en managed service providers die developer tooling verkopen in de Noordse landen.\nWaarom partner worden van fremforge # Je klanten krijgen de vraag waar hun broncode staat. fremforge is EU-soevereine Git-hosting met CI inbegrepen – alle verwerking binnen de EU, geen subverwerkers met een Amerikaanse moedermaatschappij op welk pad dan ook, en export vanaf dag één.\nJij brengt de klantrelatie in. Wij draaien het platform.\nHoe het werkt # Registreer de deal. Laat ons zo vroeg mogelijk weten met welk bedrijf je in gesprek bent. Met de registratie gaat een beschermingsperiode van 90 dagen in voor die klant. We mailen je 14 dagen en 3 dagen voordat die afloopt, zodat hij nooit ongemerkt verloopt.\nWin de deal en maak de klant daarna zelf aan. Vanuit je portal richt je hun organisatie in en nodig je hun beheerder uit, en de klant wordt aan jou toegewezen op het moment dat hij bestaat – zo telt je marge vanaf hun eerste factuur, en niet pas vanaf het moment dat iemand bij ons eraan toe kwam.\nVerdien terugkerende marge. Geen eenmalige aanbrengvergoeding. Je verdient op de werkelijke facturen van je klanten, zolang ze klant blijven, en het percentage hangt af van hoe lang de relatie al loopt.\nOntvang een maandelijks overzicht. Op de 1e van de maand stellen we je overzicht over de vorige maand op en mailen we het je. Je factureert ons op je eigen factuur; wij betalen binnen 30 dagen na ontvangst. Tussen de overzichten door toont je portal in realtime hoe je marge oploopt, dus niets komt als verrassing.\nAls twee partners dezelfde klant claimen # We beslissen op basis van bewijs van verkoopactiviteit – afspraken, offertes, correspondentie – nooit op wie zich het eerst registreerde, en nooit op wie het grootst is.\nWe vertellen ook geen van beide partners wie de ander is. Een conflict is een gesprek tussen jou en ons, niet tussen jou en een concurrent.\nWat je krijgt # Een partnerportal in het Engels, Deens, Duits, Frans, Nederlands en Zweeds Dealregistratie met automatische bewaking van de beschermingsperiode Klanten zelf inrichten Maandelijkse overzichten met een uitsplitsing per klant die je kunt afstemmen Een volledige REST-API – alles in de portal is scriptbaar, dus je kunt hem aansturen vanuit je eigen CRM of een assistent Een ondertekende raamovereenkomst, getekend met een nationale eID Ondertekening # De raamovereenkomst wordt elektronisch ondertekend met je nationale eID. In Denemarken en Zweden gebruiken we een aan het bedrijf gekoppelde identiteit – MitID Erhverv en Freja eID+ organisation – zodat de handtekening aantoont dat de ondertekenaar bevoegd is het bedrijf te binden, en niet alleen wie er klikte.\nIn Noorwegen en Finland bestaat zo’n bedrijfsidentiteit niet. Daar leggen we de functie van de ondertekenaar vast en steunen we op de garantie van bevoegdheid in de overeenkomst. We laten je weten wat voor jou geldt voordat er iets wordt verstuurd.\nJe hoeft niet zelf de persoon te zijn die geregistreerd staat om voor het bedrijf te tekenen. Een salesdirecteur die binnen zijn of haar mandaat tekent, bindt het bedrijf volgens de gewone regels van vertegenwoordiging; als je organisatie beperkt wie de bedrijfsidentiteit beheert, hebben we daar een gedocumenteerde route voor.\nWaar we partners zoeken # Op dit moment in Denemarken, Zweden, Noorwegen en Finland. Verkoop je developer tooling elders in de EU, neem dan toch contact op – het platform werkt in de hele EU en het programma volgt de vraag.\nAanmelden # Mail partners@frem.sh met je bedrijf, de landen waarin je verkoopt en het soort klanten waarmee je werkt. We nemen partners op uitnodiging aan en spreken met iedereen die zich aanmeldt.\nDe commerciële voorwaarden – margepercentages, niveaus en drempels – bespreken we in dat gesprek en worden vastgelegd in de raamovereenkomst.\n","externalUrl":null,"permalink":"/nl/partners/","section":"Partnerprogramma","summary":"Voor adviesbureaus en managed service providers die developer tooling verkopen in de Noordse landen.\nWaarom partner worden van fremforge # Je klanten krijgen de vraag waar hun broncode staat. fremforge is EU-soevereine Git-hosting met CI inbegrepen – alle verwerking binnen de EU, geen subverwerkers met een Amerikaanse moedermaatschappij op welk pad dan ook, en export vanaf dag één.\n","title":"Partnerprogramma","type":"partners"},{"content":" Prijzen\nEén plan. Per plaats. In EUR. Elke plaats komt met soevereiniteit, Security (scannen, prioriteren en fixen), gehoste runners en volledige exportrechten. Eén prijs dekt Actions-minuten, ondertekening, scans van afhankelijkheden en data-export op aanvraag – alles op EU-infrastructuur. Maandelijks Jaarlijks −15% € 30 / plaats / maand Maandelijks gefactureerd. Altijd opzegbaar per het einde van de betaalde maand.\nGefactureerd in EUR. Btw verlegd voor B2B-klanten in de EU met een geldig btw-nummer in VIES.\nLeesaccounts zijn gratis en onbeperkt. Alleen leden die kunnen pushen of beheren tellen als plaats. Zo werken leesaccounts →\nTegen de huidige middenkoers is € 30 ongeveer £26 / CHF 28 / kr 320 NOK / kr 224 DKK. Wat je in je eigen valuta betaalt, hangt af van de wisselkoers op elke factuurdatum. Klanten buiten de eurozone betalen in EUR; hun bank of kaartaanbieder rekent om. Enterpriseklanten die op betalingstermijn worden gefactureerd, kunnen in plaats daarvan facturatie in DKK afspreken.\nStart je gratis proefperiode van 30 dagen → Gratis proefperiode van 30 dagen bij registratie. Je kaart wordt daarbij geautoriseerd via de gehoste checkout van Mollie (€ 0 – er wordt niets afgeschreven; sommige banken reserveren kort € 0,01 en draaien dat weer terug). Op dag 30 gaat de proefperiode automatisch over in je maandplan; tot die tijd kun je kosteloos opzeggen via Admin → Facturatie. We sturen 3 dagen vóór de eerste afschrijving een herinnering.\nLimieten tijdens de proefperiode: 1 plaats, 10 repositories, 500 runnerminuten voor de hele proefperiode van 30 dagen samen, en tot 5 GB cache in de dependency-proxy. De volledige maandelijkse pool van 1.000 runnerminuten per plaats komt vrij bij de eerste betaling. De limieten beschermen het platform tijdens de proefperiode; een serieuze evaluatie past er ruim in – dat zijn zo’n 25-50 gewone CI-runs.\nJaarcontract: € 306 per plaats, vooraf voor het hele jaar afgeschreven. Zeg je op, dan houd je toegang tot het einde van de afgesproken termijn en blijft het jaar betaald. Wordt automatisch verlengd, tenzij je uiterlijk 30 dagen voor het einde van de termijn opzegt. Alle details staan in de gebruiksvoorwaarden. Wat er inbegrepen is Forgejo. Repos, issues, PR’s, pakketregister – Forgejo upstream met een kleine set MFA-patches (API-compatibel). Gratis leesaccounts. Voeg onbeperkt leden met de rol reader toe – clonen, code bekijken, issues en PR’s lezen – zonder kosten. Je betaalt alleen voor leden die kunnen pushen of beheren. Auditors. Elke organisatie heeft een ingebouwd alleen-lezen team Auditors dat ook de instellingen, leden en audittrail van de organisatie kan lezen – maar nooit iets kan wijzigen of exports kan downloaden. De eerste 5 auditors per organisatie zijn gratis; vanaf de zesde telt elke auditor als plaats. Zo werken auditors. Gehoste CI-runners. 1.000 min per plaats per maand, gedeeld. Gelijktijdige jobs: 2 per plaats gegarandeerd (minimaal 10, maximaal 60), en tot 60 als er capaciteit vrij is (fair use; meer op aanvraag). € 0,01 per minuut boven de pool. Elke job telt in hele minuten, naar boven afgerond (een job van 61 seconden telt als 2 minuten), voor de pool en voor meerverbruik. Eén wegwerp-VM per job. Soevereine buildketen. Gehoste runners installeren npm-, PyPI-, Go-, Maven- en NuGet-pakketten en pullen containerimages via de dependency-proxy van je organisatie, en halen GitHub Actions op uit Forgejo-pull-mirrors. Automatisch ingericht bij elke runnerjob. Dependency-proxy. Pull containerimages en npm-, PyPI-, Maven-, NuGet-, Go-, Cargo-, Helm- en RPM-pakketten uit de grote publieke registers via frem.sh, gecachet voor je organisatie. Standaard aan. Pulls van Docker Hub gebruiken de eigen Docker Hub-inloggegevens van je organisatie. Fair use volgens AUP §4A. Security. Pre-receive scan op secrets, push-bescherming, scannen van afhankelijkheden, licenties, images en malware, SAST, bereikbaarheidsoordelen (bereikbaar, niet bereikbaar, onbekend), markering van bekend misbruikte kwetsbaarheden (ENISA EUVD + CISA KEV), pull requests met beveiligingsfixes, ondertekende commits, SLSA-provenance, SBOM per build, workflows vastpinnen (PR die naar SHA-pins herschrijft). Compliance. Compliancerapport, controlebewijs en op aanvraag een ondertekende leveranciersattestatie over auditketen en beveiligingsstatus (HTML + JSON). Updates van afhankelijkheden (beveiligingsfixes en versie-updates). Versie-updates volgens schema, met een wachttijd van 3 dagen na een release, en pull requests met beveiligingsfixes met één klik of, als je dat kiest, automatisch voor de bevindingen die het zwaarst wegen – één per pakket, naar de laagste versie met de fix. Beveiligingsfixes werken zonder dat versie-updates aan staan; standaard wachten ze op review, mergen zodra de checks slagen schakel je zelf in. Opslag. 5 GB repo + 5 GB LFS + 5 GB pakketten per plaats, als drie afzonderlijke pools voor de hele organisatie. De cache van de dependency-proxy telt mee voor de pakketpool. Uitgaand pakketverkeer. Zachte limiet van 100 GB per plaats per maand (we laten het je weten); harde limiet van 300 GB per plaats per maand, daarna beperkt tot 1 Mbps tot de 1e van de maand. Geen kosten voor meerverbruik. Downloads door runners die fremforge host, tellen nooit mee voor een van beide limieten; self-hosted runners en andere clients wel. SSO met step-up MFA. OIDC-SSO (Entra ID, ADFS, Okta, Google Workspace) met echte verificatie van acr_values/amr-claims (niet alleen bij de eerste login), sessiebinding per organisatie. Enterprise-toegangsbeheer. SSH-CA, hardwarematige sleutels (alleen WebAuthn), IP-allowlist, allowlist voor e-maildomeinen, maximale PAT-levensduur per organisatie, afdwingen van ondertekende commits, standaard-branchbescherming voor de hele organisatie. SCIM 2.0-provisioning. Push gebruikers en groepen vanuit Okta, Entra, Authentik of elke compatibele IdP. Bearer-token-authenticatie per tenant met rotatie via twee tokens. OIDC-federatie. Kortlevende T Cloud Public-credentials bij elke job. Geen langlevende deploysleutels. Deployomgevingen. Secrets per omgeving, branchbeperkingen, verplichte reviewers als poort. SIEM-doorsturen. Audit-events met HMAC-handtekening via POST naar je Splunk/QRadar/Sentinel/Datadog-endpoint. Fix-by-SLA. Je stelt per ernst zelf het aantal dagen in waarbinnen een bevinding opgelost moet zijn; bevindingen over hun termijn verschijnen als meldingen onder de bel. Optioneel geef je bevindingen die niet bereikbaar zijn meer tijd; bekend misbruikte houden altijd de volledige SLA. Publieke REST-API. Dezelfde API die mensen gebruiken. PAT + OAuth 2.0 client credentials. Klaar voor AI-agents. AI-integraties (eigen sleutel). PR-review, uitleg bij Renovate, AI-fix voor geselecteerde SAST-bevindingen (standaard uit), /ai/complete om zelf aan te roepen. Neem je eigen sleutel mee – Anthropic, OpenAI, Mistral, Vertex Gemini of elke OpenAI-compatibele URL. Datapad \u0026amp; soevereiniteit → Publieke repos ondersteund. Standaard privé. Export met één klik, aantoonbaar ongewijzigd. Repos, LFS, Actions-logs, auditfragment, attestaties – gezipt met een SHA-256-manifest. Bewaring van het auditlog tot 2 jaar. Per tenant in te stellen (90 / 180 / 365 / 730 dagen). De hashgekoppelde index blijft voor altijd bewaard; de inhoud verloopt volgens je beleid. WORM-verankerd met een replica in een andere regio. Extra opslag. € 0,20 per GB per maand op de betreffende pool, achteraf gefactureerd. Hoe € 30 zich verhoudt Eén prijs per plaats, met de supply-chainstack inbegrepen – geen beveiligingsadd-on. Functie voor functie: fremforge vs GitHub en fremforge vs GitLab.\nGitHub Enterprise + beveiligingsadd-ons 🇺🇸 Amerikaans bedrijf $70/committer/mnd$21 Enterprise + $19 Secret Protection + $30 Code Security\nEnterprise kost $21 per gebruiker per maand (GitHub-prijzen). Secret Protection ($19) en Code Security ($30) zijn add-ons, per maand gefactureerd voor elke actieve committer: iedereen van wie in de afgelopen 90 dagen een commit is gepusht naar een repository waarop de functie aan staat (GitHub-changelog, 4 maart 2025; facturatiedocumentatie van GitHub). Voor een lid dat commit, is dat $70 per maand. Team ($4) heeft geen SAML-single sign-on en geen IP-allowlist. Actions-minuten worden apart afgerekend.\nGitLab Ultimate 🇺🇸 Amerikaans bedrijf $99/gebruiker/mndgerapporteerde catalogusprijs, jaarlijks gefactureerd\nSAST, DAST, scannen van afhankelijkheden \u0026amp; containers, kwetsbaarheidsbeheer. CI-minuten worden apart afgerekend. Op de eigen pagina van GitLab staat nu \"Get custom pricing\"; $99 per gebruiker per maand is de prijs die kopers melden (SpendBase). Premium ($29 per gebruiker per maand, jaarlijks gefactureerd) bevat ze niet (GitLab-prijzen).\nfremforge 🇪🇺 gehost in Duitsland € 30/plaats/mndvast · € 360/plaats/jr · € 306 bij een jaarcontract\nSecurity inbegrepen, met bereikbaarheid en pull requests met beveiligingsfixes. 1.000 CI-min per plaats, gedeeld. Updates van afhankelijkheden (beveiligingsfixes en versie-updates). Ondertekende export. Nul Amerikaanse subverwerkers.\nDe prijzen van GitHub en GitLab zijn in USD, gelezen op 23 oktober 2026: die van GitHub zijn de gepubliceerde catalogusprijzen, die van GitLab Ultimate is de gerapporteerde catalogusprijs, omdat GitLab die alleen op aanvraag noemt. GitHub rekent zijn beveiligingsadd-ons per actieve committer af, dus een team betaalt ze alleen voor de leden die code pushen; bij fremforge zitten ze in elke plaats. fremforge rekent overal in EUR, zonder wisselkoersrisico bij verlenging. De prijzen worden jaarlijks herzien.\nfrembench – add-on, per bench-plaats Een Linux-machine die je vanuit de browser gebruikt, om een codeeragent te draaien zonder je laptop. Vereist een fremforge-plaats.\n€ 39 / bench-plaats / maand 200 uur draaitijd inbegrepen, gedeeld over bench-plaatsen. Naar rato verrekend bij wijzigingen. Btw verlegd voor B2B-klanten in de EU met een geldig btw-nummer in VIES.\nTegen de huidige middenkoers is € 39 ongeveer £34 / CHF 36 / kr 416 NOK / kr 291 DKK. Afgerekend in EUR, net als elke andere regel op je factuur; je bank of kaartaanbieder rekent om.\nWat er inbegrepen is 200 uur per plaats per maand, gedeeld op organisatieniveau, net als CI-minuten. Een bench pauzeert na 30 minuten zonder activiteit, dus een werkdag verbruikt er veel minder dan acht uur van. € 0,20 per uur boven de pool. Hetzelfde tarief als dat van de plaats (39 ÷ 200 = 0,195), dus pieken in gebruik kosten niet meer dan een extra plaats kopen. Gemaximeerd op € 99 per plaats per maand. Geen schatting – daar stopt de rekening. Dat plafond bereik je bij 500 uur op één plaats; daarboven draaien je benches zonder verdere kosten. Per seconde gefactureerd, één keer afgerond aan het einde van de periode. Twintig keer tien seconden wakker kost per keer tien seconden, geen twintig minuten. Naar rato verrekend bij wijzigingen, net als een gewone plaats. Profielvolume van 50 GB per bench voor je code, tools en logins. Het blijft bewaard als de bench pauzeert; de bootschijf wordt bij elke start opnieuw opgebouwd uit een vers image. Dezelfde toolchain als je CI-runners, uit hetzelfde image. Documentatie over benches. Betaling \u0026amp; facturatie Eén valuta, één prijs EUR op elk selfserviceplan en elke factuur. Geen spelletjes met lokale prijzen, geen wisselkoersverrassing bij verlenging. Enterpriseklanten die op factuur betalen, kunnen in overleg in DKK worden gefactureerd.\nBtw verlegd Voor B2B-klanten in de EU met een geldig btw-nummer in VIES. Gecontroleerd bij registratie.\nBetaalmethoden Kaart (Visa, Mastercard), SEPA-incasso, SEPA-overboeking, Google Pay, Apple Pay. Verwerkt door Mollie (NL).\nGeen minimumaantal plaatsen. Kopers uit de publieke sector of gereguleerde sectoren die facturatie op 30 dagen op basis van een inkooporder nodig hebben: mail hello@frem.sh – die gevallen behandelen we individueel. Zie Vertrouwen voor de volledige lijst van subverwerkers en de verwerkersovereenkomst voor de contractuele afspraken. Start je gratis proefperiode van 30 dagen → Bekijk het product ","externalUrl":null,"permalink":"/nl/pricing/","section":"Prijzen","summary":" Prijzen\nEén plan. Per plaats. In EUR. Elke plaats komt met soevereiniteit, Security (scannen, prioriteren en fixen), gehoste runners en volledige exportrechten. Eén prijs dekt Actions-minuten, ondertekening, scans van afhankelijkheden en data-export op aanvraag – alles op EU-infrastructuur. ","title":"Prijzen","type":"pricing"},{"content":"Effective Date: 2026-04-25 - Version: 1.1\nLast updated: 2026-07-01\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 (the fremforge marketing website). A separate Product Privacy Notice covers the fremforge product itself - the hosted Git and CI/CD service on frem.sh.\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 marketing 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 Public (Deutsche Telekom), an EU-sovereign cloud provider. The origin is a T Cloud Public 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 Public 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.\nSigning up # This website does not collect personal data through any form - there is no waitlist or email-capture form on it.\nTo create an account, you go to the product signup at frem.sh/_app/signup, which includes a 30-day free trial. Any personal data you provide while signing up or using the product is governed by the product privacy policy, not this website notice. This website itself only processes the technical request and log data described above, for content delivery and security.\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 (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 any 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 Public 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 (system notifications and any reply we send you). 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 Public (Deutsche Telekom AG) - Biere/Magdeburg, Germany - primary hosting (all platform data). 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. This marketing website runs no signup form and uses no third-party bot-mitigation processor. Account signup in the product uses Altcha (self-hosted, MIT-licensed, HMAC-signed proof-of-work; runs in-process inside the api monolith) - no third-party widget, no external sub-processor.\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 and shared mailboxes run on a stack with no US-parented processor in the path: T Cloud Public (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). Email you send us routes to our shared mailboxes 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 website notice for product users. 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. 1.1 2026-07-01 Go-live / GA: removed pre-launch framing. This policy now describes the live fremforge marketing website (www.frem.sh); the Product Privacy Notice at /legal/privacy-product/ is published and covers product users. No change to what data the marketing site processes. ","externalUrl":null,"permalink":"/privacy/","section":"Privacy policy","summary":"Effective Date: 2026-04-25 - Version: 1.1\nLast updated: 2026-07-01\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 (the fremforge marketing website). A separate Product Privacy Notice covers the fremforge product itself - the hosted Git and CI/CD service on frem.sh.\n","title":"Privacy policy","type":"privacy"},{"content":"Ingangsdatum: 2026-05-14 - Versie: 1.10\nDeze pagina is het officiële register, waar je direct naar kunt linken, van elke subverwerker die fremverk inschakelt om de dienst te leveren. Het register is toegezegd in DPA §10 en DPA bijlage B, en inkoopteams kunnen in hun leveranciersbeoordeling rechtstreeks naar deze URL verwijzen.\nToezegging over kennisgeving van wijzigingen # Elke toevoeging, vervanging of wezenlijke wijziging in de lijst van subverwerkers wordt 30 dagen van tevoren aangekondigd via twee kanalen tegelijk, volgens DPA §10.2: (a) een e-mail rechtstreeks aan de geregistreerde factuurcontactpersoon van de organisatie van elke klant (de contractuele drager – de bezorging wordt vastgelegd in het auditlog van fremverk, met de bericht-id’s van de e-mailprovider per ontvanger), EN (b) een publieke melding op deze pagina en op de mailinglijst voor beveiligingsmeldingen (voor het gemak bedoeld voor adressen die geen factuuradres zijn, zoals securityteams en compliance-verantwoordelijken). Klanten die op gedocumenteerde gronden van gegevensbescherming bezwaar maken tegen een nieuwe subverwerker, kunnen het opzeggingsrecht uit DPA §10.2 uitoefenen, met terugbetaling naar rato van vooruitbetaalde, ongebruikte vergoedingen.\nBij inschakeling in noodgevallen (bijvoorbeeld de onmiddellijke vervanging van een subverwerker die zelf de bron van een beveiligingsincident is) publiceert fremverk binnen 24 uur na de wijziging en wordt de bezwaartermijn verlengd tot 30 dagen na de inschakeling. Zie DPA §10.3.\nAbonneer je op meldingen van wijzigingen: abonneer je op de mailinglijst voor beveiligingsmeldingen – antwoorden en losse vragen komen binnen op security-notices@frem.sh (alias die doorstuurt naar compliance@frem.sh).\nHuidige subverwerkers # Subverwerker Doel Locatie Certificeringen DPA / SCC’s Deutsche Telekom AG (T Cloud Public) Kerncompute, opslag, netwerk – elk onderdeel dat klanten zien Biere \u0026amp; Magdeburg, DE ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, TISAX DPA van T Cloud Public – Europese verantwoordelijke, geen Amerikaanse moedermaatschappij Bunny CDN d.o.o. Edge-levering, DDoS-mitigatie en rate limiting voor frem.sh en statische bestanden die klanten serveren (er is geen Web Application Firewall ingeschakeld) PoP’s in de EU (hoofdkantoor Slovenië) ISO 27001 (2025), SOC 2 Type II (2023) DPA van Bunny – Europese verantwoordelijke, geen Amerikaanse moedermaatschappij Lettermint B.V. Uitgaande transactionele e-mail (verificatie, betalingsherinneringen, beveiligingsmeldingen) Zwolle, NL – upstream OVHcloud SAS (FR) + UpCloud Ltd (datacenter in Amsterdam NL, opgericht in Finland) Certificeringen van de leverancier: bewijs nog in behandeling (NL – geen Amerikaanse moedermaatschappij) DPA van Lettermint – Europese verantwoordelijke, geen Amerikaanse moedermaatschappij Mollie B.V. Betalingsverwerking (aanmaken van mandaten, terugkerende afschrijvingen, terugbetalingen) Amsterdam, NL PCI-DSS Level 1 DPA van Mollie – Europese verantwoordelijke, geen Amerikaanse moedermaatschappij Heinlein Hosting GmbH (mailbox.org) Hosting van gedeelde mailboxen (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlijn, Duitsland ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen (TR 03108) DPA van Heinlein Hosting – Europese verantwoordelijke, geen Amerikaanse moedermaatschappij Visma Dinero ApS Uitgifte van factuurbijlagen (bilag) en de wettelijke bewaring daarvan gedurende 5 jaar volgens Bogføringsloven §10 – ontvangt de juridische naam van de organisatie, het e-mailadres van de factuurcontactpersoon, het btw-nummer, de factuurregels en de referentie van de Mollie-betalings-id. Geen inhoud van repositories, geen inhoud van auditlogs, geen PAN. Kopenhagen, DK ISO 27001 (uitgegeven in DK, geen Amerikaanse moedermaatschappij) DPA van Visma Dinero – Europese verantwoordelijke, geen Amerikaanse moedermaatschappij Vermeld voor de transparantie – geen subverwerkers in de zin van artikel 28 # De volgende partijen hebben raakvlakken met het platform, maar verwerken geen persoonsgegevens van klanten namens fremverk en zijn daarom geen subverwerkers in de zin van artikel 28 AVG. Ze staan hier zodat het register voor klanten volledig is:\nPartij Rol Locatie Waarom geen subverwerker Actalis S.p.A. (Aruba Group) Certificaatautoriteit voor origin-TLS van *-origin.frem.sh (eIDAS-QTSP) Italië, EU De CA ontvangt tijdens de ACME-DNS-01-uitgifte alleen FQDN’s – nooit persoonsgegevens. Uitgezonderd van bijlage B volgens DPA §A.4. D-TRUST GmbH (Duitsland, eIDAS-QTSP) blijft de benoemde betaalde terugvaloptie. VIES-dienst van de Europese Commissie Validatie van btw-nummers bij registratie (kwalificatie voor btw-verlegging) EU-instellingen Niet-commerciële opzoekdienst van de publieke sector; alleen het btw-nummer (een bedrijfsregistratienummer) wordt ingediend. Vermeld in privacyverklaring §3.3. Simply.com A/S Registrar + DNS voor de merkdomeinen met doorverwijzing fremforge.{com,eu,dk} (allemaal 301 → www.frem.sh) Denemarken Er gaan geen persoonsgegevens van klanten via Simply.com – alleen DNS-lookups voor de doorverwijzingsdoelen. De onderdelen die klanten zien, gebruiken BunnyDNS (Bunny CDN d.o.o., Slovenië – dezelfde subverwerker als voor de CDN/WAF/edge-laag, al vermeld in de tabel met subverwerkers uit bijlage B hierboven). Wat we niet inschakelen # Geen CDN of edge-provider met een Amerikaanse moedermaatschappij in het verzoekpad van endpoints voor klanten. Geen verwerker voor analytics of telemetrie. Fase 1 bevat helemaal geen productanalytics – in lijn met wat het cookiebeleid en de privacyverklaring al zeggen (geen analytics, geen toestemmingsbanner). Geen Google Analytics, geen Mixpanel, geen Segment, geen Plausible. Zelf gehoste Plausible (T Cloud Public eu-de) staat op de roadmap voor na de lancering; als het er komt, verschijnt het in het wijzigingslogboek hieronder en als eigen verwerker van niveau 1 in bijlage B (de gegevens blijven binnen het T Cloud Public-account van fremverk; geen uitgaand verkeer naar derden). Geen AI-/LLM-aanbieder wordt ingezet op klantinhoud. Functies op basis van agentmandaten (volgens DPA §11A) handelen op instructie van de klant tijdens de uitvoering en sturen inhoud niet langs een model van derden; fremverk bewaart geen klantinhoud in een modelcorpus. De keten van subverwerkers legt dit verbod contractueel door – zie Verboden op AI-training in de keten van subverwerkers hieronder. Geen Amerikaanse betalingsverwerker. Mollie (NL) handelt elke betaling af. Geen leverancier van een widget voor botbescherming. De registratie in Forgejo gebruikt zelf gehoste Altcha (MIT-licentie, met HMAC ondertekende PoW), die in hetzelfde proces draait als de api-monoliet op hetzelfde T Cloud Public-cluster; geen Cloudflare Turnstile, geen hCaptcha, geen Google reCAPTCHA. Positie ten opzichte van de CLOUD Act # Elke partij hierboven is een door de EU beheerste entiteit zonder Amerikaanse moedermaatschappij. Op geen enkel verwerkingspad is er blootstelling aan de CLOUD Act. Een Schrems II-transfer impact assessment is niet nodig, omdat er geen persoonsgegevens van klanten buiten de EU/EER worden doorgegeven.\nVoor het volledige beleid, zie DPA §11.3 en de trustpagina – sectie Schrems II.\nVerboden op AI-training in de keten van subverwerkers # De toezegging “geen AI-training op klantgegevens” in DPA §6A bindt elke partij in de keten van subverwerkers. De publieke toezeggingen van elke subverwerker die dit onderbouwen, staan hieronder ter vergelijking. Waar een subverwerker een opt-in voor modeltraining aanbiedt, heeft fremverk daar niet voor gekozen.\nSubverwerker Publieke toezegging waarop we vertrouwen Deutsche Telekom AG (T Cloud Public / T Cloud Public) Dienstbeschrijving en DPA van T Cloud Public – IaaS-laag; het platform heeft geen toegang tot de inhoud van tenants. De AI-principes van T Cloud Public verplichten tot dataminimalisatie en doelbinding bij AI die Telekom zelf ontwikkelt, en de IaaS-DPA verbiedt het gebruik van de payload van klanten voor iets anders dan het leveren van de dienst. Bunny CDN d.o.o. DPA van Bunny – Bunny verwerkt verkeer alleen voor caching, TLS-terminatie, DDoS-mitigatie en rate limiting; er zijn geen rechten voor modeltraining verleend. De toelichting op het AI-beleid van Bunny bevestigt dat er geen AI-model wordt getraind op de payload van klantverkeer. Lettermint B.V. DPA + privacybeleid van Lettermint – scope van transactionele e-mail; alleen uitgaande relay. Ontvangerslijsten van klanten worden niet gebruikt voor modeltraining over accounts heen, en er is geen opt-in voor AI of modeltraining ingeschakeld. Mollie B.V. Privacyverklaring van Mollie en scope van PSD2 / PCI-DSS – alleen transactieverwerking; Mollie traint voor de merchant geen AI-modellen op transactiemetadata. Heinlein Hosting GmbH (mailbox.org) Privacyverklaring van mailbox.org – uitdrukkelijk standpunt “geen AI-training, geen profilering”; de marketing van mailbox.org zegt geregeld “Wir trainieren keine KI mit Ihren Daten” (“we trainen geen AI met jouw gegevens”). Visma Dinero ApS Privacy- en AI-beleid van Visma Group – scope van de boekhoudkoppeling; geen training op persoonsgegevens van klanten die via de koppeling gaan. Het boekhoudpad van fremverk ontvangt de juridische naam van de organisatie, het e-mailadres van de factuurcontactpersoon, het btw-nummer, de factuurregels en de Mollie-betalings-id (persoonsgegevens van de beheerder van de organisatie); geen inhoud van repositories, geen inhoud van auditlogs, geen PAN. Actalis S.p.A. eIDAS-QTSP – ontvangt tijdens de ACME-DNS-01-uitgifte alleen domeinnamen; de scope van een CA sluit afgeleid gebruik van inhoud uit. VIES-dienst van de Europese Commissie Opzoekdienst van de publieke sector; valt buiten de scope van AI-training (geen consumenten-ML getraind op verkeer naar het btw-register). Simply.com A/S Alleen registrar / DNS voor doorverwijzingsdomeinen; geen pad voor persoonsgegevens van klanten. Als een subverwerker zijn standpunt over AI-training wijzigt, is fremverk volgens DPA §6 (Subverwerkers) verplicht klanten vooraf te informeren en hun het recht te geven bezwaar te maken voordat de nieuwe verwerking begint. Het wijzigingslogboek onderaan deze pagina legt elke zo’n overgang vast.\nVoetnoot over kaartnetwerken # Kaartbetalingen via Mollie lopen technisch via PCI-DSS-gecertificeerde sub-subverwerkers van de kaartnetwerken: Visa Europe Services Inc. (Britse vestiging) en Mastercard Europe SA (België). Beide zijn Europese entiteiten, maar hun uiteindelijke moedermaatschappijen (Visa Inc., Mastercard Inc.) zijn in de VS opgericht. fremverk sluit geen rechtstreeks contract met deze netwerken – het zijn sub-subverwerkers van Mollie volgens de netwerkregels van PCI-DSS. De claim “geen Amerikaanse moedermaatschappij” hierboven geldt voor de eigen keten van subverwerkers van fremverk op het niveau van de exploiterende onderneming. Wil je op het betaalpad helemaal geen blootstelling aan een Amerikaanse moedermaatschappij, betaal dan via SEPA-incasso (bij het SEPA-pad van Mollie is geen sub-subverwerker van een kaartnetwerk betrokken). Zie DPA §11.3 voor de volledige toelichting.\nAlternatieven op verzoek van de klant # De standaardset van subverwerkers heeft al nul blootstelling aan Amerikaanse moedermaatschappijen. Onder Enterprise-on-Demand kunnen klanten daarnaast vragen om:\neen audit van eventuele voorkeuren voor het vastzetten van regio’s binnen T Cloud Public (eu-de is de standaard; andere EU-regio’s zijn op aanvraag beschikbaar, mits de functionaliteit gelijk is); regiospecifieke toezeggingen over dataresidentie die verder gaan dan de standaard (bijvoorbeeld contractueel vastzetten op één availability zone in eu-de). Neem contact op met enterprise@frem.sh om de mogelijkheden te bespreken.\nEerdere wijzigingen # Deze sectie legt de wijzigingsgeschiedenis van de lijst van subverwerkers vast, de nieuwste eerst. De lijst hierboven is altijd de actuele stand.\nDatum Wijziging Kennisgeving gepubliceerd 2026-10-04 Bij het doel van Bunny CDN staat geen WAF meer: sinds 2026-05-09 is op geen enkel onderdeel van fremforge aan de edge een Web Application Firewall ingeschakeld (DPA bijlage A.2). Er verandert geen subverwerker, verwerkingsdoel of gegevenscategorie; de beschrijving komt nu overeen met wat Bunny doet. Niet vereist (correctie, geen wijziging in de verwerking) 2026-05-14 Uitgaande transactionele e-mail gemigreerd van Sendinblue SAS (Brevo, FR) naar Lettermint B.V. (Zwolle, NL). Brevo uitgefaseerd op 2026-05-14. Het pad voor uitgaande e-mail blijft volledig binnen de EU, zonder verwerker met een Amerikaanse moedermaatschappij; de regel over verboden op AI-training is daarop aangepast. Komt overeen met DPA v1.9. n.v.t. (geen klanten met een contract; vóór de lancering) 2026-05-08 Transparantiebatch ronde 7: Actalis S.p.A. (CA voor origin-TLS, IT, eIDAS-QTSP), de VIES-dienst van de EU (btw-validatie) en Simply.com A/S (DK, DNS voor merkdoorverwijzingen) toegevoegd aan een nieuwe sectie “Vermeld voor de transparantie – geen subverwerkers in de zin van artikel 28”. Geen van hen ontvangt persoonsgegevens van klanten; uitgezonderd van bijlage B volgens DPA §A.4. n.v.t. (geen klanten met een contract; vóór de lancering) 2026-05-06 Visma Dinero ApS (Denemarken) toegevoegd aan bijlage B als subverwerker op het factuurpad. Scope van persoonsgegevens van klanten: juridische naam van de organisatie, factuurcontactpersoon, btw-nummer, factuurregels, Mollie-betalings-id. Wettelijke bewaartermijn van 5 jaar volgens de Deense Bogføringsloven §10. Komt overeen met DPA v1.4 (herzien in v1.5 – de eerdere formulering “geen pad voor persoonsgegevens van klanten” was onjuist). n.v.t. (geen klanten met een contract; vóór de lancering) 2026-04-27 Hosting van inkomende gedeelde mailboxen verhuisd van Microsoft Ireland Operations Ltd. naar Heinlein Hosting GmbH (mailbox.org), Berlijn, Duitsland – daarmee verdwijnt de eerdere subverwerker met een Amerikaanse moedermaatschappij op het pad van de inkomende mailboxen n.v.t. (geen klanten met een contract; vóór de lancering) 2026-04-25 Eerste register Ingangsdatum Contact # Voor vragen over subverwerkers:\nPrivacy / scope van de DPA: compliance@frem.sh Inkoop / leveranciersbeoordeling: enterprise@frem.sh Abonnement op de security-mailinglijst: lists.frem.sh/subscription/form (alias: security-notices@frem.sh – stuurt door naar compliance@) Zie ook: Trustpagina · Privacyverklaring\n","externalUrl":null,"permalink":"/nl/trust/subprocessors/","section":"Vertrouwen","summary":"Ingangsdatum: 2026-05-14 - Versie: 1.10\nDeze pagina is het officiële register, waar je direct naar kunt linken, van elke subverwerker die fremverk inschakelt om de dienst te leveren. Het register is toegezegd in DPA §10 en DPA bijlage B, en inkoopteams kunnen in hun leveranciersbeoordeling rechtstreeks naar deze URL verwijzen.\n","title":"Subverwerkers","type":"trust"},{"content":"Effective Date: 2026-04-25 - Version: 1.1\nLast updated: 2026-07-01\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 website Terms cover only the marketing site 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 this site # fremforge is live - self-serve signup is open at frem.sh/_app/signup, including a 30-day free trial. This website exists to describe the product and its terms; creating an account, starting a trial, and subscribing all happen in the product itself.\nBrowsing this website does not:\nCreate an account Reserve a subscription or seat Guarantee price, availability, or feature set Constitute a contract for the supply of services Account creation, the free trial, pricing, and the product-specific terms are handled in the product; the fremforge product terms at /legal/terms/ apply once you sign up.\nUse of website # Permitted use # You may use this website for lawful purposes related to learning about fremforge, signing up for the product, 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 forms or requests 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 as a modified build, 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 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 fremforge marketing 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. 1.1 2026-07-01 Go-live / GA: removed \u0026ldquo;pre-launch website\u0026rdquo; framing throughout; these Terms now cover the live fremforge marketing website. No change to liability, governing law, or any substantive term. ","externalUrl":null,"permalink":"/terms/","section":"Terms of service","summary":"Effective Date: 2026-04-25 - Version: 1.1\nLast updated: 2026-07-01\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":"Ingangsdatum: 2026-05-19 - Versie: 1.13\nLaatst bijgewerkt: 2026-10-07\nSamenvatting # fremforge is EU-soevereine Git-hosting, gebouwd op upstream Forgejo en geëxploiteerd door fremverk ApS (Denemarken). Elk onderdeel draait in de Europese Unie. Geen enkel klantgegeven verlaat de EU-jurisdictie.\nElke verwerking (repositories, CI, audit, facturatie, authenticatie, uitgaande e-mail, inkomende correspondentie in gedeelde mailboxen) gebeurt bij partijen zonder Amerikaanse moedermaatschappij. Nul subverwerkers met een Amerikaanse moedermaatschappij, op welk pad dan ook. Zie §11.3 van de verwerkersovereenkomst (DPA) van het product voor het volledige beleid.\nDeze pagina is de officiële referentie voor waar je gegevens staan, wie ze verwerkt, welke certificeringen van toepassing zijn en hoe je ons bereikt.\nVerwerkingsverantwoordelijke # fremverk ApS CVR: 39150689 Ringager 4C, 2. tv, 2605 Brøndby, Denemarken E-mail: compliance@frem.sh · info@fremverk.com\nHosting en regio’s # Onderdeel Verwerker Regio Forgejo-UI, Git, API, pakketregister T Cloud Public (Deutsche Telekom) eu-de (Biere/Magdeburg, DE) Website, documentatie, status Bunny CDN Alleen PoP’s in de EU Uitgaande transactionele e-mail (systeemmeldingen, facturatie, magic links) Lettermint B.V. Zwolle, Nederland Inkomende correspondentie in gedeelde mailboxen (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Heinlein Hosting GmbH (mailbox.org) Berlijn, Duitsland Betalingen Mollie Nederland Facturatie-engine fremforge-engine in de monoliet (door fremverk zelf gehost) eu-de (T Cloud Public) Boekhoudkoppeling (boekhouding aan de kant van fremverk volgens Bogføringsloven §10; ontvangt de juridische naam van de organisatie, het e-mailadres van de factuurcontactpersoon, het btw-nummer, de factuurregels en de Mollie-betalings-id. Geen inhoud van repositories, geen inhoud van auditlogs, geen PAN.) Visma Dinero Kopenhagen, Denemarken Subverwerkers # De actuele lijst van subverwerkers wordt hier bijgehouden. Elke wijziging wordt 30 dagen van tevoren aangekondigd via de security-mailinglijst en op deze pagina.\nSubverwerker Doel Locatie Certificeringen Deutsche Telekom AG (T Cloud Public) Kerncompute, opslag, netwerk Biere/Magdeburg, DE ISO 27001, 27017, 27018; BSI C5 Type 2; TISAX Bunny CDN d.o.o. Edge-levering, TLS-terminatie, DDoS-mitigatie, rate limiting (er is geen Web Application Firewall ingeschakeld – zie §Edge-bescherming hieronder) PoP’s in de EU (hoofdkantoor Slovenië) ISO 27001 (2025), SOC 2 Type II (2023) Lettermint B.V. Uitgaande transactionele e-mail Zwolle, Nederland Certificeringen van de leverancier: bewijs nog in behandeling (NL – geen Amerikaanse moedermaatschappij) Heinlein Hosting GmbH (mailbox.org) Hosting van gedeelde mailboxen (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlijn, Duitsland ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen (TR 03108) Mollie B.V. Betalingsverwerking Amsterdam, NL PCI-DSS Level 1 Visma Dinero ApS Boekhoudkoppeling (boekhouding aan de kant van fremverk volgens Bogføringsloven §10; ontvangt de juridische naam van de organisatie, het e-mailadres van de factuurcontactpersoon, het btw-nummer, de factuurregels en de Mollie-betalings-id. Geen inhoud van repositories, geen inhoud van auditlogs, geen PAN.) Kopenhagen, DK ISO 27001 (uitgegeven in DK, geen Amerikaanse moedermaatschappij) Voor botbestrijding wordt geen externe verwerker ingezet. De registratie- en inlogformulieren van het product gebruiken zelf gehoste Altcha (MIT-licentie, met HMAC ondertekende proof-of-work), die in hetzelfde proces draait als de api-monoliet op hetzelfde T Cloud Public-cluster; geen widget-JavaScript van derden, geen externe subverwerker. Daarnaast gelden over het hele platform server-side controles (throttling en rate limits per IP-adres). Aan de edge is geen Web Application Firewall ingeschakeld; zie §Edge-bescherming hieronder.\nEdge-bescherming – DDoS-mitigatie, geen WAF # Elk onderdeel van fremforge (frem.sh voor Forgejo en Git, de API, en de sites www, docs, status en cli) staat achter de edge van Bunny CDN, die volumetrische DDoS-aanvallen afslaat en rate limiting per IP-adres toepast. Op geen enkel onderdeel van fremforge is aan de edge een Web Application Firewall (WAF) ingeschakeld, en dat is al zo sinds vóór de livegang. Dat is een bewuste keuze. Tijdens de tests vóór de lancering gaf de OWASP Core Rule Set veel fout-positieven op de verzoeken van Forgejo (paden van het Git-protocol, diff-routes van pull requests, ophalen van raw blobs met hexadecimale identifiers, querystrings van ondertekende URL’s) en op de formulierinhoud van de API. Een te agressieve WAF die legitieme Git-operaties of de Forgejo-UI breekt, zou voor klanten slechter uitpakken dan het resterende risico op de edge-laag. De bescherming zit daarom in de applicatie: pre-receive scan op secrets, Altcha-proof-of-work bij registratie en inloggen, rate limits per IP-adres en per tenant in de API, authenticatie met ondertekende tokens op elke webhook-ontvanger, en de integriteitshash van de auditketen. Dit beleid staat in DPA bijlage A.2 en wordt bij elke kwartaalreview van de operatie opnieuw beoordeeld.\nIsolatie van gehoste runners – wegwerp-ECS-VM, één per commit # CI-jobs die je naar fremforge pusht, draaien op T Cloud Public Elastic Cloud Server (ECS): elke commit of pull request krijgt een eigen wegwerp-VM, die vers wordt aangemaakt en wordt vernietigd zodra de jobs van die commit klaar zijn. Er zijn twee onafhankelijke isolatielagen:\nCompute / kernel – een eigen VM per commit. De jobs van elke commit draaien in een ECS-VM met een eigen Linux-kernel, geïsoleerd door de hypervisor. Nooit delen twee klanten, of twee commits, een kernel of een machine, dus kernelgebaseerde container-escapes (cgroup-escape, escape via een bind-mount van /proc, eBPF, blootstelling van /sys) hebben geen grens tussen tenants om over te steken: er is geen gedeelde kernel om naar uit te breken. De isolatie-eenheid is een complete VM, geen container – een sterkere grens dan het containermodel met gedeelde kernel dat gangbare Kubernetes (ook CCE) voor runner-pods gebruikt. De VM wordt opgeruimd (verwijderd) zodra de jobs van die commit klaar zijn, zodat niets – buildcache, gekloonde code, geïnjecteerde secrets – overgaat naar de jobs van een andere commit of naar een andere klant. Binnen één commit kunnen jobs de machine delen. Opeenvolgende jobs van dezelfde workflowrun (bijvoorbeeld build en daarna deploy op dezelfde commit) kunnen op dezelfde VM draaien, die wordt vernietigd als ze klaar zijn. Dat is bewust: het is in beide jobs dezelfde gereviewde code, en een verse machine per job kost bij elke stap van een pipeline ongeveer 40 seconden extra opstarttijd. Het gevolg, en dat zeggen we liever ronduit: een buildstap die code van externe afhankelijkheden uitvoert, deelt een machine met een latere stap van dezelfde commit. Behandel een pipeline daarom als één vertrouwensdomein, en beperk elke credential die een deploystap nodig heeft tot die pipeline. De isolatie tussen tenants en tussen commits hierboven verandert hierdoor niet. Netwerk – een VPC Security Group per VM. Elke runner-VM staat achter een eigen VPC Security Group: geen inkomend verkeer, verkeer tussen VM’s (binnen het subnet) geweigerd, en uitgaand verkeer beperkt tot de tegen SSRF beveiligde uitgaande runner-proxy, de Forgejo-API en DNS. De isolatie wordt afgedwongen op de VPC-/hypervisorlaag, niet op een NetworkPolicy-laag binnen het cluster die afhangt van een CNI-agent die zich correct gedraagt. Samen met de verplichte uitgaande proxy en de SSRF-blokkeerlijst daarvan wordt laterale beweging van een runner-VM naar iets buiten de eigen jobcontext van de klant geweigerd, zowel op VM- als op VPC-niveau. Als het isolatiemodel van T Cloud Public voor een van beide lagen zo verandert dat het bovenstaande zwakker wordt (bijvoorbeeld als VM’s per job worden vervangen door containers met een gedeelde kernel, of als de grens van de Security Group per VM verdwijnt), wordt deze pagina binnen 30 dagen na de wijziging bijgewerkt en wordt elke actieve klant geïnformeerd volgens DPA §14.\nOvergenomen certificeringen # Via T Cloud Public:\nISO/IEC 27001 – managementsysteem voor informatiebeveiliging ISO/IEC 27017 – beveiligingsmaatregelen specifiek voor de cloud ISO/IEC 27018 – bescherming van persoonsgegevens in de cloud BSI C5 Type 2 – Duitse federale basislijn voor cloudbeveiliging TISAX – zekerheidsstandaard van de Duitse auto-industrie AVG-conforme verwerking in datacenters in de EU De eigen certificeringsroadmap van fremverk # Op de ingangsdatum heeft fremverk geen eigen ISO 27001-, SOC 2- of BSI C5-certificering. Het beveiligingsniveau van fremverk berust op (i) de hierboven genoemde overgenomen certificeringen van de subverwerkers, (ii) de technische en organisatorische maatregelen in de beveiligingsbijlage van de DPA, en (iii) het programma voor informatiebeveiliging en beveiligingstests van fremverk dat in de beveiligingsbijlage van de DPA is beschreven.\nfremverk heeft zich ertoe verplicht:\nbinnen 18 maanden na de ingangsdatum te beginnen met de ISO 27001 Stage 1-audit en binnen 24 maanden gecertificeerd te zijn; binnen 24 maanden te beginnen met een SOC 2 Type II-readiness assessment. Klanten die vóór die mijlpalen een directe certificering nodig hebben, kunnen een Enterprise-on-Demand-contract sluiten waarin de mijlpalen voor certificeringsgereedheid in het Order Form worden vastgelegd. Zie DPA §12.1.\nTransparantie over overheidstoegang # Op de ingangsdatum heeft fremverk nul verzoeken van overheden om toegang tot persoonsgegevens van klanten ontvangen. Het volledige rapport – inclusief de verklaring over de periode vóór de lancering – staat op frem.sh/trust/transparency/. Latere rapporten beslaan volledige kalenderjaren en verschijnen in Q1 van het jaar daarna.\nOntvangt fremverk een bindend juridisch bevel van een overheidsinstantie, rechtbank of opsporingsdienst, dan:\ntoetst fremverk het verzoek op rechtsgeldigheid, bevoegdheid en proportionaliteit; vecht fremverk elk verzoek aan dat te ruim is, geen wettelijke grondslag heeft of in strijd is met EU-recht (waaronder art. 48 AVG voor verzoeken van buiten de EU/EER); informeert fremverk de betrokken klant binnen 24 uur na ontvangst, tenzij dat wettelijk verboden is; geeft fremverk de klant redelijkerwijs de gelegenheid om een beschermingsbevel te vragen of het verzoek op een andere manier aan te vechten. Zie DPA §11A.\nDSA-transparantieverslag (artikel 15) # fremforge is een hostingdienst in de zin van Verordening (EU) 2022/2065 (Digital Services Act). Het jaarlijkse verslag op grond van art. 15 – over het aantal meldingen en de afhandeling ervan, bevelen van autoriteiten van lidstaten, contentmoderatie op eigen initiatief en de uitkomst van klachten op grond van art. 20 – staat op frem.sh/trust/dsa/, los van het rapport over overheidstoegang hierboven. Op dezelfde URL staat ook het halfjaarlijkse gemiddelde aantal maandelijkse afnemers in de EU dat art. 24(2) vereist.\nSchrems II – internationale doorgiften # Op geen enkel verwerkingspad worden persoonsgegevens van klanten internationaal doorgegeven. Alle verwerking (inhoud van repositories, CI-runs, auditlogs, authenticatiemetadata, factuurgegevens, gegevens van betaalmiddelen, uitgaande transactionele e-mail en inkomende correspondentie in gedeelde mailboxen) vindt plaats binnen de EU/EER, bij partijen zonder Amerikaanse moedermaatschappij. Er is geen waarborg volgens artikel 46 AVG, geen SCC en geen transfer impact assessment nodig.\nResidentie van edge-PoP’s (Bunny CDN) # Elke Bunny-pullzone vóór frem.sh is zo ingesteld dat hij alleen vanaf PoP’s in de EU levert – geen caching in de VS, Australië of Azië. Dat wordt in OpenTofu op elke pullzone-resource afgedwongen met routing { zones = [\u0026quot;EU\u0026quot;] }. De configuratie van de pullzones staat in de broncode op:\nForgejo-pullzone: fremforge/forgejo/.infrastructure/main.tf – zoek op zones = [\u0026quot;EU\u0026quot;] API-pullzone: fremforge/monolith/.infrastructure/bunny.tf – dezelfde regel De pullzones van de statische sites (www, docs, status, cli) nemen hetzelfde routing-blok over uit de gedeelde module in fremverk/cloudplatform/modules/static-site/main.tf:103-112. Een tofu plan op een willekeurige pullzone-stack toont de actieve waarde van routing.zones, dus elke afwijking van [\u0026quot;EU\u0026quot;] zou als verschil in het plan opduiken. Het controleerbare bewijs wordt direct doorzoekbaar zodra de broncode op de Forgejo-instantie voor klanten staat (op https://frem.sh/fremforge/...); voorlopig staat de officiële documentatie over het anker van de auditketen en de integriteitscontrole op docs.frem.sh/security/audit-chain/.\nOver het TLD # frem.sh is een ccTLD van Sint-Helena (.sh), beheerd door een in het Verenigd Koninkrijk geregistreerde registry-operator. Dat is uitsluitend een feit op DNS-niveau. Geen klantgegevens, geen status van het control plane en geen back-ups verlaten T Cloud Public EU-DE. De soevereiniteitsgaranties (identiteit van de verwerker, lijst van subverwerkers, dataresidentie) staan in de DPA en worden niet beïnvloed door waar de DNS wordt gehost.\nOp geen enkel verwerkingspad is er blootstelling aan de CLOUD Act. Alle persoonsgegevens van klanten worden binnen de EU/EER verwerkt door partijen zonder Amerikaanse moedermaatschappij. Zie DPA §11.3 voor het volledige beleid.\nVoetnoot over kaartnetwerken. De PCI-DSS-gecertificeerde keten voor kaartbetalingen van Mollie omvat Visa Europe Services Inc. (Britse vestiging) en Mastercard Europe SA (België) – Europese entiteiten waarvan de uiteindelijke moedermaatschappijen (Visa Inc., Mastercard Inc.) in de VS zijn opgericht. De claim “geen Amerikaanse moedermaatschappij” geldt voor de eigen keten van subverwerkers van fremverk op het niveau van de exploiterende onderneming; de kaartnetwerken zijn sub-subverwerkers van Mollie volgens de netwerkregels van PCI-DSS. Wil je op het betaalpad helemaal geen blootstelling aan een Amerikaanse moedermaatschappij, betaal dan via SEPA-incasso (zonder betrokkenheid van kaartnetwerken). Zie subverwerkers – Voetnoot over kaartnetwerken.\nControleer de auditketen zelf # Elke beheeractie die de status van je organisatie wijzigt, wordt vastgelegd in een SHA-256-hashketen per tenant. De kop van die keten wordt elke twee minuten WORM-verankerd in T Cloud Public OBS Object Lock-opslag (bewaartermijn 3 jaar, binnen die termijn fysiek niet te verwijderen). Je kunt de keten van begin tot eind nalopen zonder fremverk op zijn woord te hoeven geloven.\nMet de 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 Of met kale curl tegen hetzelfde endpoint dat de CLI aanroept:\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_status, walked_rows, verified_count, last_verified_hash, worm_anchor}\u0026#39; Een gezond antwoord bevat \u0026quot;integrity_status\u0026quot;: \u0026quot;ok\u0026quot; en een worm_anchor-blok waarin agrees_with_db_walk: true bevestigt dat de keten in de database overeenkomt met de in OBS verankerde kop. Bij een breuk (hash_mismatch / prev_hash_mismatch) krijg je de id van de betreffende rij en de reden terug – bewust zo opgezet dat een auditor het kan lezen. Het volledige schema, de exitcodes en het dreigingsmodel staan in docs.frem.sh – integriteit van de auditketen.\nBeheer van operatorcredentials # De bootstrap-beheercredentials (de root-AK/SK van T Cloud Public op domeinniveau, die alleen worden gebruikt om IAM, OBS-buckets en service-linked agencies voor het eerst aan te maken) staan op de laptop van de operator, met volledige schijfversleuteling via FileVault en bestandsrechten chmod 600. Ze worden elk kwartaal geroteerd, nooit via chat of schermdeling verstuurd, en kunnen binnen 10 minuten worden ingetrokken via de OTC-console. Gewone deploys gebruiken afgebakende deployer-sleutels per component, niet de root-credential.\nBeveiligingscontact # Kwetsbaarheden melden: security@frem.sh Disclosurebeleid: beveiliging Vingerafdruk van de PGP-sleutel: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (publieke sleutel – RFC 4880 armored, RSA-4096, verloopt 2031-05-14). Gebruik deze voor versleutelde meldingen van kwetsbaarheden aan security@frem.sh. De sleutel wordt alleen gepubliceerd vanaf frem.sh/.well-known/; we uploaden hem niet naar publieke keyservers (zo vermijden we een vertrouwensanker van derden). Voor het gemak staat er een kopie op /pgp.txt. Melden van kwetsbaarheden # Een machineleesbaar disclosurebeleid staat op frem.sh/.well-known/security.txt volgens RFC 9116, met een safe harbour voor onderzoek te goeder trouw, de scope en het meldkanaal. Rapporten van pentests door derden, als die worden uitgevoerd, stellen we volgens DPA §12.1 op schriftelijk verzoek onder NDA beschikbaar aan klanten; in Enterprise-on-Demand-contracten kan in het Order Form een vaste testfrequentie worden afgesproken.\nOpenbaarmaking van incidenten # Post-mortems van elk incident dat klantgegevens of beschikbaarheid raakt, publiceren we binnen 14 dagen op deze pagina, volgens ons beveiligingsbeleid.\nBeveiligingspatches # fremforge verplicht zich tot de volgende maximale termijnen voor het patchen van beveiligingslekken in het platform, gerekend vanaf de upstream release met de fix of de publicatie van de advisory, wat het laatst is.\nErnst (CVSS) Maximale termijn voor de patch Kritiek (≥ 9.0) 48 uur Hoog (7.0–8.9) 72 uur Gemiddeld (4.0–6.9) 7 dagen Laag (\u0026lt; 4.0) Volgende geplande onderhoudsvenster Noodreleases buiten het schema zijn te verwachten. Het wekelijkse onderhoudsvenster is een bovengrens, geen ondergrens. Beveiligingspatches worden nooit uitgesteld vanwege een onderhoudsvenster van een tenant; dat staat in de AUP en wordt letterlijk aangehaald in de beveiligingsbijlage van de DPA.\nVertrek en dataportabiliteit # Alles is exporteerbaar – repositories, issues, pull requests, Actions-logs, audittrail, SLSA-attestaties – via de API, in standaardformaten. Er is geen lock-in via bewaring en er zijn geen exportkosten.\nSelfservice-export, aantoonbaar ongewijzigd. Elke tenantbeheerder kan op elk moment vanuit de beheer-UI een volledige bundel aanmaken. De bundel wordt geleverd als één zip met een SHA-256-manifest over elk bestand in het archief (manifest.json + archive.tar.gz.sha256), zodat de klant kan bevestigen dat de inhoud na het downloaden niet is gewijzigd. De bundel bevat git bundle-bestanden van de repositories, LFS-manifests, Actions-logs, een auditfragment en SLSA-attestaties. Ter vergelijking: de organisatie-export van GitHub is een reeks REST-API-aanroepen, beschikbaar voor eigenaren van de organisatie, die een archief oplevert dat bedoeld is om in GitHub Enterprise Server te importeren (GitHub-documentatie, geraadpleegd op 17 oktober 2026). fremforge levert het in elk plan, aan elke klant, elke dag. Het manifest is ondertekend met onze SLSA-buildersleutel (DSSE-envelop, manifest.json.intoto.jsonl); klanten verifiëren met hetzelfde vertrouwensanker op https://www.frem.sh/.well-known/slsa-trust-root.json dat voor SLSA-buildattestaties is gepubliceerd. Voor het verifiëren van het manifest is helemaal geen Sigstore nodig – niet de publieke instantie, en ook niet de zelf gehoste Fulcio en TSA die we als tweede handtekening op buildattestaties gebruiken. Zie docs.frem.sh/data-export voor de opbouw van de bundel, verificatierecepten en de API-endpoints.\nDe termijnen en procedures voor het offboarden van een tenant staan in de DPA.\nCookies en tracking # fremforge zet alleen strikt noodzakelijke cookies op de onderdelen van het product waar je bent ingelogd, en nul cookies op de website, de documentatie, de statuspagina en anonieme pagina’s. Een toestemmingsbanner is niet nodig: niet omdat we de vraag hebben weggestopt, maar omdat we geen cookies zetten waarvoor toestemming nodig is.\nOnderdelen van het product waar je bent ingelogd zetten vier first-party cookies, allemaal strikt noodzakelijk in de zin van artikel 5(3) van de e-privacyrichtlijn:\nCookie Doel Levensduur session Sessiestatus van Forgejo (ingelogde sessie; cookienaam vanaf Forgejo 15, voorheen i_like_gitea) 7 dagen (persistent) _csrf CSRF-bescherming Sessie lang Taalvoorkeur, ingesteld door de gebruiker Feitelijk permanent fremforge_operator_session (operatorconsole) Sessie van de operatorconsole 30 min inactiviteit, absoluut maximum 12 uur Website, documentatie en status (www.frem.sh, docs.frem.sh, status.frem.sh) zijn statische sites, gebouwd met Hugo, zonder cookies, zonder analytics, zonder embeds en zonder enige vorm van tracking. Controleer het zelf in de ontwikkelaarstools van je browser.\nAanroepen naar derden vanuit de product-UI zijn standaard uitgeschakeld: geen Gravatar, geen gefedereerde avatars, geen fonts of scripts via een CDN, geen analytics van derden. Avatars worden lokaal opgeslagen; fonts komen van dezelfde origin als de forge.\nDit is een bewuste productkeuze, geen minimale compliance-eis. De volledige cookie-inventaris en de rechten van betrokkenen staan in het privacybeleid van het product.\nWijzigingen in beveiligingsmaatregelen # Bijlage A van de DPA somt de technische en organisatorische maatregelen op die fremverk toepast, en bepaalt dat wezenlijke wijzigingen daarin hier worden gemeld. Wijzigingen vanaf 2026-10-04 staan hieronder, de nieuwste eerst; eerdere wijzigingen staan in het wijzigingslogboek van de DPA. Een wijziging die een toezegging afzwakt, gaat in 30 dagen na een kennisgeving aan elke beheerder bij de klant, met het opzeggingsrecht uit Terms §17; de overige gaan in bij publicatie. Elke versie linkt naar de bijbehorende tekst.\nDPA-versie Gepubliceerd Van kracht vanaf Bijlage A Wijziging 1.45 2026-10-07 2026-11-06 A.6 De dependency-proxy is de enige uitzondering op de regel dat de runtime nooit iets ophaalt bij hosts in de VS: hij haalt op bij de upstream-registers die de klant opgeeft (bijlage B §B.9). Kennisgeving aan klanten verstuurd op 2026-10-07. 1.44 2026-10-07 2026-11-06 A.11 Alerts bereiken de dienstdoende medewerkers per e-mail, die ze als push-e-mail ontvangen; de externe uptimecontroles sturen sms. Kennisgeving aan klanten verstuurd op 2026-10-07. 1.41 2026-10-04 2026-11-03 A.5, A.6, A.7, A.9 Exacte controle-intervallen vervangen door minimale frequenties, bijvoorbeeld verankering van de auditketen minstens elke 5 minuten. Kennisgeving aan klanten verstuurd op 2026-10-04. 1.40 2026-10-04 2026-11-03 A.9 Verwijderde gegevens kunnen tot 90 dagen na verwijdering uit de primaire opslag in de versleutelde back-ups van de live-laag blijven staan. Kennisgeving aan klanten verstuurd op 2026-10-04. Wijzigingen op deze pagina # Wijzigingen worden in Git geversioneerd en aangekondigd via de security-mailinglijst. De datum bovenaan deze pagina is die van de laatste inhoudelijke wijziging.\nWijzigingslogboek # Versie Datum Wijziging 1.0 2026-04-25 Eerste publicatie. 1.1 2026-04-27 Heinlein Hosting GmbH (mailbox.org, Berlijn DE) toegevoegd als subverwerker in bijlage B voor inkomende correspondentie in gedeelde mailboxen (migratie van M365 naar mailbox.org; daarmee verdwijnt de laatste verwerker onder Amerikaanse jurisdictie van het pad van persoonsgegevens van klanten). 1.2 2026-05-06 Visma Dinero ApS (Kopenhagen DK) toegevoegd als subverwerker in bijlage B voor de boekhoudkoppeling aan de kant van fremverk (vervangt het eerdere eigen grootboek voor facturatie/btw/Bogføringsloven). 1.3 2026-05-08 Kennisgeving van wijzigingen in subverwerkers via twee kanalen volgens DPA §10.2 verduidelijkt; Bunny Shield-configuratie op de pagina beschreven (Shield Basic op de Forgejo- en api-pullzones, Shield Advanced op de pullzones van de statische sites); alinea over runner-isolatie met CCI Kata + Yangtse v2 toegevoegd, met een expliciete uitzondering voor de OBT-toegang tot CCI v2. 1.4 2026-05-14 Brevo (FR) volledig uitgefaseerd als subverwerker voor uitgaande transactionele e-mail; Lettermint B.V. (Zwolle, NL – upstream OVHcloud SAS, FR + UpCloud Ltd, opgericht in FI, datacenter in Amsterdam NL) is nu de officiële regel in bijlage B. Footer van de trustpagina en tabel in het AI-beleid bijgewerkt. 1.5 2026-05-19 Tabel met gegevenscategorieën van Visma Dinero gecorrigeerd: die somt nu de velden op die werkelijk door de boekhoudkoppeling gaan (juridische naam van de organisatie, e-mailadres van de factuurcontactpersoon, btw-nummer, factuurregels, Mollie-betalings-id; geen inhoud van repositories, geen inhoud van auditlogs, geen PAN); opsomming van gedeelde mailboxen uitgebreid tot alle 8 officiële adressen; limiet voor gelijktijdige jobs in AUP §3.6+§4 gelijkgetrokken naar “2 jobs/plaats, max. 100/organisatie” (v1.1); 24/7-monitoring in DPA §8.5 genuanceerd, met verwijzing naar SLA §9+§10 en naar de benadering van het moment van kennisname in EDPB-richtsnoeren 9/2022. 1.6 2026-07-01 Sectie over isolatie van gehoste runners herschreven na de migratie naar eenmalige T Cloud Public ECS-VM’s – één wegwerp-VM per job, geïsoleerd door de hypervisor, opgeruimd na de job (afgerond op 2026-06-24). Vervangt de eerdere beschrijving “CCI Kata + Yangtse v2” en schrapt de uitzondering voor de wachtlijst voor OBT-toegang tot CCI v2 (niet meer van toepassing). Dit is een sterkere isolatiegrens (complete VM in plaats van container met gedeelde kernel), bij dezelfde subverwerker (T Cloud Public, eu-de); komt overeen met DPA v1.16 bijlage A.5. 1.7 2026-08-04 Isolatie van gehoste runners gecorrigeerd: de VM-grens ligt per COMMIT, niet per job. Deze sectie zei dat “each job gets its own single-use virtual machine”, dat “no two jobs \u0026hellip; ever share a kernel or a machine”, en dat niets “persists into any subsequent job”. In werkelijkheid kunnen opeenvolgende jobs van één workflowrun op dezelfde commit de machine delen, die wordt vernietigd als ze klaar zijn – een bewuste afweging (een verse VM per job kost bij elke stap van de pipeline ongeveer 40s extra opstarttijd). De isolatie tussen tenants en tussen commits is ongewijzigd, en dat blijven de eigenschappen waartoe deze pagina zich verplicht: nooit delen twee klanten of twee commits een kernel of een machine. Het gevolg binnen een commit wordt nu expliciet benoemd in plaats van weggemoffeld: behandel een pipeline als één vertrouwensdomein. Behandeld als verduidelijking en niet als kennisgeving van een afzwakking: de toezegging volgens §14 in deze sectie is gekoppeld aan een wijziging van het isolatiemodel van T Cloud Public (“bijvoorbeeld als VM’s per job worden vervangen door containers met een gedeelde kernel”), en die heeft niet plaatsgevonden – de VM-grens en de Security Group per VM zijn precies zoals beschreven. Gevonden op 2026-08-04 tijdens een gerichte controle van de gepubliceerde documenten tegen het draaiende systeem; dezelfde controle corrigeerde DPA bijlage A.5, die nog Cloud Container Instance-pods beschreef en waarvan de regel 1.6 hierboven ten onrechte beweerde dat die ermee overeenkwam. 1.8 2026-08-05 Twee correcties op deze pagina, beide gevonden door de pagina te toetsen aan de systemen die ze beschrijft. (a) Bij de levensduur van de session-cookie stond “Session”. Hij is 7 dagen persistent (SESSION_LIFE_TIME = 604800, gelijk aan het “Remember Me”-venster van 7 dagen), bewust zo ingesteld dat aankomsten via single sign-on een herstart van de browser overleven. Gecorrigeerd samen met cookiebeleid 1.3 en privacyverklaring 1.14, die de volledige toelichting geven – deze pagina was het DERDE onderdeel dat hetzelfde verkeerde getal publiceerde, en de controle die de andere twee ving, moest worden verruimd om het te zien. Geen gevolgen voor toestemming: een authenticatiecookie is strikt noodzakelijk volgens art. 5(3) van de e-privacyrichtlijn, of hij nu per sessie of persistent is. (b) De regel voor de subverwerker Bunny noemde “WAF” als rol, terwijl de sectie over de edge-WAF verderop op dezelfde pagina zegt dat de Shield-WAF op de Forgejo- en api-pullzones niet is ingeschakeld. De regel beschrijft nu wat Bunny werkelijk voor fremforge doet – edge-levering, TLS-terminatie, DDoS-mitigatie en rate limiting – en verwijst naar die sectie. Aan de verwerkingsscope, locatie of certificeringen van Bunny verandert niets; de regel beschreef een mogelijkheid en geen ingezette maatregel. 1.9 2026-08-05 Cookietabel: bij de lang-cookie stond “1 year”, terwijl hij feitelijk permanent is (Max-Age=2147483647, gelijk aan de standaard LangCookieMaxAge van Forgejo). Gecorrigeerd samen met cookiebeleid 1.4 en privacyverklaring 1.15. Dit is de tweede levensduur in deze tabel die vandaag is gecorrigeerd – de session-regel was fout in 1.8 – en beide kwamen pas aan het licht door de tabel naast de code te leggen die de cookies zet. De indeling als strikt noodzakelijk blijft: overweging 25 van de e-privacyrichtlijn zondert voorkeurscookies op initiatief van de gebruiker uit, ongeacht de duur, dus toestemming is in geen van beide gevallen nodig; wat fout was, is het getal dat een lezer controleert. Beide worden nu uit de code afgeleid door de claim cookie-lifetimes-match-the-code, die ook deze pagina dekt. 1.10 2026-08-05 Cookietabel: in de vierde regel stond “fremforge middleware session 1.11 2026-10-04 Edge-bescherming gecorrigeerd: op geen enkel onderdeel van fremforge is aan de edge een WAF ingeschakeld. De edge-sectie zei dat de pullzones van de statische sites (www, docs, status, cli) “run Shield Advanced with CRS enabled”, en de alinea over botbestrijding noemde een “edge WAF” bij de maatregelen die over het hele platform gelden. Geen van beide klopte: sinds 2026-05-09, vóór de livegang, draait elke pullzone van fremforge met de WAF uitgeschakeld, zoals DPA bijlage A.2 sinds DPA 1.25 (2026-08-04) vermeldt. De sectie beschrijft de bescherming nu aan de hand van wat ze doet (DDoS-mitigatie en rate limiting per IP-adres aan de edge) in plaats van het abonnementsniveau van de leverancier, zegt ronduit dat er geen WAF is ingeschakeld, en laat de beloofde canary-herbeoordeling vallen, die in DPA bijlage A.2 is vervangen door de kwartaalreview. De versieregel bovenaan deze pagina vermeldde ook nog 1.5, terwijl deze tabel al bij 1.10 was; nu staat daar de actuele versie. 1.12 2026-10-07 Nieuwe sectie: Wijzigingen in beveiligingsmaatregelen. Bijlage A van de DPA zegt dat wezenlijke wijzigingen in de beveiligingsmaatregelen op deze pagina worden gemeld, en de pagina had daar geen plek voor. De sectie somt wijzigingen in bijlage A op vanaf 2026-10-04, toen de kennisgevingen aan klanten voor zulke wijzigingen begonnen (DPA 1.40 en 1.41), te beginnen met DPA 1.44 (alerts bereiken dienstdoende medewerkers per e-mail; kennisgeving verstuurd op 2026-10-07, van kracht vanaf 2026-11-06). Eerdere wijzigingen staan in het wijzigingslogboek van de DPA. 1.13 2026-10-07 Wijzigingen in beveiligingsmaatregelen: DPA 1.45 toegevoegd (bijlage A.6, de dependency-proxy; kennisgeving verstuurd op 2026-10-07, van kracht vanaf 2026-11-06). DPA 1.44 linkt nu naar een eigen versiepagina. ","externalUrl":null,"permalink":"/nl/trust/","section":"Vertrouwen","summary":"Ingangsdatum: 2026-05-19 - Versie: 1.13\nLaatst bijgewerkt: 2026-10-07\nSamenvatting # fremforge is EU-soevereine Git-hosting, gebouwd op upstream Forgejo en geëxploiteerd door fremverk ApS (Denemarken). Elk onderdeel draait in de Europese Unie. Geen enkel klantgegeven verlaat de EU-jurisdictie.\n","title":"Vertrouwen","type":"trust"},{"content":"","externalUrl":null,"permalink":"/nl/vs/","section":"Vs","summary":"","title":"Vs","type":"vs"}]