[{"content":"Hvorfor denne side findes # I afsnit 11A i databehandleraftalen forpligter fremverk sig til at offentliggøre en årlig transparensrapport, der – samlet – oplyser om hver anmodning fra myndigheder eller politi om Kundens personoplysninger, som vi modtager. Denne side er den rapport.\nRapporten udgives hvert år for hvert fulde kalenderår, vi har været i drift. Er der ingen anmodninger i et kalenderår, står det her for det pågældende år – at undlade at oplyse »nul« ville i praksis være det samme som slet ikke at offentliggøre, og så ville rapporten miste sit formål.\nRapporteringsperioder # Periode Dækning 2026 (delvis – før lancering) Kun drift før lancering. fremverk havde ingen af Kundens personoplysninger under behandling i produktion før lanceringen. Rapporter for hele kalenderår følger, når det første er afsluttet.\nSamlede tal for anmodninger # Rapporteringsperiode: 2026 (delvis – før lancering) # Måling Antal Anmodninger om adgang fra myndigheder i alt 0 Anmodninger, der blev efterkommet fuldt ud 0 Anmodninger, der blev efterkommet delvist 0 Anmodninger afvist af jurisdiktionelle eller processuelle grunde 0 Anmodninger under behandling ved periodens udløb 0 Udleverede poster med Kundens personoplysninger 0 Kunder underrettet i henhold til DPA §11A.1(c) 0 Jurisdiktioner, anmodningerne kom fra # Ingen – der er ikke modtaget nogen anmodninger.\nKategorier af data, der blev anmodet om # Ikke relevant – der er ikke modtaget nogen anmodninger.\nSådan håndterer fremverk anmodninger # Når fremverk modtager et bindende retligt krav, følger vi den proces, der er beskrevet i DPA §11A.1:\nVerificér, at kravet er bindende efter EU-retten, og at den udstedende myndighed har jurisdiktion over fremverk og de data, kravet gælder. Afgræns omfanget til det mindste datasæt, kravet giver hjemmel til. Underret den berørte kunde før udlevering, medmindre en retskendelse udtrykkeligt forbyder det – i så fald arbejder fremverk for, at perioden med tavshedspligt bliver så kort som muligt, og underretter, så snart forbuddet ophæves. Anfægt krav, der går ud over myndighedens jurisdiktion, ikke er proportionale eller kræver udlevering af data uden for EU/EØS. Dokumentér anmodningen, hvordan den blev behandlet, og hvilke data der blev udleveret, så det kan indgå i denne rapport. fremverk har ikke modtaget og vil ikke frivilligt efterkomme anmodninger om Kundens personoplysninger fra jurisdiktioner uden for EU. Det omfatter – uden begrænsning – anmodninger efter den amerikanske CLOUD Act, amerikanske National Security Letters, stævninger efter den amerikanske Foreign Intelligence Surveillance Act eller tilsvarende ekstraterritoriale mekanismer. CLOUD Act har ingen ekstraterritorial rækkevidde over fremverk, fordi hverken fremverk eller nogen underdatabehandler på vejen for Kundens personoplysninger har et amerikansk moderselskab. Se DPA §11 for hele forpligtelsen om dataophold.\nAbonnér på opdateringer # Siden opdateres én gang om året (typisk i slutningen af januar for det foregående år). Vil du have besked, når en ny rapport udkommer, så tilmeld dig sikkerhedsmailinglisten – den samme liste annoncerer ændringer af underdatabehandlere i henhold til DPA §10.\nRelateret # Databehandleraftalen § 11A – den kontraktlige forpligtelse, som denne rapport opfylder Liste over underdatabehandlere – alle enheder, der potentielt kan få adgang til Kundens personoplysninger, med jurisdiktion Tillid – det samlede billede af sikkerhed og compliance Senest opdateret: 2026-05-06.\n","externalUrl":null,"permalink":"/da/trust/transparency/","section":"Tillid","summary":"Hvorfor denne side findes # I afsnit 11A i databehandleraftalen forpligter fremverk sig til at offentliggøre en årlig transparensrapport, der – samlet – oplyser om hver anmodning fra myndigheder eller politi om Kundens personoplysninger, som vi modtager. Denne side er den rapport.\n","title":"Transparensrapport – myndigheders og politiets adgang","type":"trust"},{"content":"Hvorfor denne side findes # fremforge er en hostingtjeneste som defineret i forordning (EU) 2022/2065 (retsakten om digitale tjenester, »DSA«). Efter artikel 15 i DSA skal alle formidlingstjenester mindst én gang om året offentliggøre en klar og letforståelig rapport i maskinlæsbart format om deres indholdsmoderering. Denne side er den rapport.\nDen er adskilt fra transparensrapporten om myndigheders og politiets adgang, som dækker bindende retlige krav om Kundens personoplysninger efter databehandleraftalen. Den rapport handler om adgang efter GDPR og for politiet; denne handler om rapportering af indholdsmoderering efter DSA art. 15. Begge offentliggøres årligt.\nRapporteringsfrekvens # Rapporten udgives hvert år. fremforge lanceres i løbet af 2026, så rapporten for det første år er en erklæring for en delvis periode, der dækker tiden fra lanceringsdatoen til 31. december 2026. De følgende rapporter dækker hele kalenderår og offentliggøres i 1. kvartal året efter.\nDSA art. 15 giver udtrykkeligt plads til en erklæring for det første år om, at »vi er lanceret og har intet at rapportere«. Det er tavshed, der er overtrædelsen – at offentliggøre nul med en forklaring på hvorfor er den korrekte måde at overholde reglen på.\nRapporteringsperiode: 2026 (delvis – drift før lancering) # På datoen nedenfor er fremforge endnu ikke generelt tilgængelig for betalende kunder. Der har ikke været noget kundeindhold omfattet af indholdsmoderering. Alle tal i dette afsnit er derfor nødvendigvis nul.\nArt. 15(1)(a) – Påbud fra myndigheder i EU’s medlemsstater # Påbud om at gribe ind over for ulovligt indhold (DSA art. 9) og påbud om at afgive oplysninger (DSA art. 10), opdelt efter udstedende medlemsstat og kategori af ulovligt indhold. Mediantid til at orientere den udstedende myndighed og til at efterkomme påbuddet.\nMåling Antal Påbud efter art. 9 (gribe ind over for indhold) i alt 0 Påbud efter art. 10 (afgive oplysninger) i alt 0 Mediantid til kvittering over for den udstedende myndighed n/a Mediantid til at efterkomme påbuddet n/a Udstedende medlemsstater # Ingen – der er ikke modtaget nogen påbud.\nKategorier af ulovligt indhold # Ikke relevant – der er ikke modtaget nogen påbud.\nArt. 15(1)(b) – Anmeldelser efter art. 16 (notice-and-action) # Anmeldelser indsendt via abuse@frem.sh og den strukturerede formular på https://frem.sh/_app/legal/abuse-report, opdelt efter kategori af angiveligt ulovligt indhold, hvad der blev gjort, og mediantid til handling. Ordningen for notice-and-action er beskrevet i AUP §5.\nMåling Antal Anmeldelser efter art. 16 i alt 0 Anmeldelser fra troværdige indberettere (art. 22) 0 Anmeldelser, der førte til handling (indhold fjernet eller begrænset, eller tiltag over for kontoen) 0 Afviste anmeldelser (åbenbart ubegrundede eller uden for området) 0 Mediantid til afgørelse n/a Brug af automatiserede midler i afgørelser Ingen Kategorier af angiveligt ulovligt indhold # Ingen – der er ikke modtaget nogen anmeldelser.\nArt. 15(1)(c) – Indholdsmoderering på eget initiativ # Indholdsmoderering, som fremverk har foretaget på eget initiativ – herunder brugen af automatiserede værktøjer, de menneskelige korrekturlæseres kvalifikationer og de anvendte garantier. fremforge anvender sin Acceptable Use Policy ens over for alle kundeorganisationer.\nMåling Antal Tiltag på eget initiativ 0 \u0026hellip;heraf med automatiserede værktøjer (push-beskyttelsesscanneren) 0 \u0026hellip;heraf med menneskelig gennemgang 0 Fejl i automatiserede værktøjer (falske positiver ved klage eller intern gennemgang) 0 Indikatorer for nøjagtighed / fejlrate n/a Uddannelse af menneskelige korrekturlæsere n/a – endnu ingen tiltag på eget initiativ Push-beskyttelsesscanneren nævnt ovenfor er en scanner på serversiden, som afviser pushes med hemmeligheder, der genkendes med høj sikkerhed, i git-protokollaget. Den er ikke et system til indholdsmoderering i den gængse DSA-forstand (den klassificerer ikke indhold som ulovligt, og afvisningen er en teknisk afvisning af en udviklers commit, ikke en modereringsafgørelse om hostet materiale). Den medtages her udelukkende for fuldstændighedens skyld, og der vil stå tal i fremtidige perioder, hvis der forekommer afvisninger.\nArt. 15(1)(d) – Internt klagebehandlingssystem # Det interne klagebehandlingssystem, som DSA art. 20 kræver, giver brugere og anmeldere mulighed for at klage over modereringsafgørelser. Klageadgangen er beskrevet i AUP §5. Klager modtages på abuse@frem.sh med emnelinjen appeal: og afgøres inden for 14 dage.\nMåling Antal Klager i alt 0 Klager afgjort til fordel for den oprindelige afgørelse 0 Klager afgjort imod den oprindelige afgørelse (afgørelsen omgjort) 0 Mediantid til afgørelse n/a Afgørelser henvist til udenretlig tvistbilæggelse efter art. 21 0 Gennemsnitligt antal aktive modtagere af tjenesten i EU pr. måned # Efter DSA art. 24, stk. 2, skal formidlingstjenester mindst hver sjette måned offentliggøre det gennemsnitlige antal aktive modtagere af tjenesten i EU pr. måned. fremforge ligger under tærsklen for udpegning som meget stor onlineplatform (VLOP); tallet offentliggøres her for fuldstændighedens skyld.\nPeriode Gennemsnitligt antal aktive modtagere i EU pr. måned 2026 (delvis – før lancering) 0 Tallet omfatter fysiske og juridiske personer i EU, der har brugt tjenesten mindst én gang i kalendermåneden, beregnet som et aritmetisk gennemsnit over seks måneder. Metoden bliver dokumenteret i fremtidige perioder, når fremforge har betalende kunder og et tal over nul at offentliggøre.\nMetode og datakilder # Tallene på denne side stammer fra:\nTabellen audit_events (se Revisionslog i dokumentationen) – enhver juridisk betydningsfuld handling mod fremforges infrastruktur giver en uforanderlig, hashkædet hændelse i revisionsloggen. Opsamlingsjobbet kører mod event_type IN ('legal_takedown_received', 'legal_takedown_actioned', 'content_moderation_action', 'art16_notice_received', 'art20_complaint_received') én gang i kvartalet og opdaterer denne side. Indgående korrespondance i postkasserne abuse@frem.sh og compliance@frem.sh – der føres internt et indeks pr. henvendelse, så det kan krydstjekkes mod tallene fra revisionsloggen. Forgejos register over organisationer, som registrerer suspendering, begrænsning og opsigelse i henhold til AUP §7. Den første rapport med tal over nul (for hele kalenderåret 2027) offentliggøres i 1. kvartal 2028 og vil indeholde metodeafsnittet i maskinlæsbart format efter skabelonerne i Kommissionens gennemførelsesforordning 2024/2835.\nAbonnér på opdateringer # Siden opdateres én gang om året (typisk i slutningen af januar for det foregående år) og desuden hver sjette måned efter art. 24 for tallet over modtagere i EU. Vil du have besked, når en ny rapport udkommer, så tilmeld dig sikkerhedsmailinglisten – den samme liste annoncerer ændringer af underdatabehandlere i henhold til DPA §10 og transparensrapporten om myndigheders adgang.\nRelateret # Acceptable Use Policy §5 (DSA art. 16, notice-and-action) – det kontraktlige grundlag for ordningen for notice-and-action, der er opsummeret på denne side Transparensrapport om myndigheders adgang – rapporten efter DPA §11A.2 om anmodninger om adgang fra politi og myndigheder (en særskilt forpligtelse) Tillid – det samlede billede af sikkerhed og compliance Rapporteringsskabeloner til DSA art. 15 (Kommissionens gennemførelsesforordning (EU) 2024/2835) – det standardiserede rapporteringsformat, der anvendes fra år 2 Senest opdateret: 2026-05-07.\n","externalUrl":null,"permalink":"/da/trust/dsa/","section":"Tillid","summary":"Hvorfor denne side findes # fremforge er en hostingtjeneste som defineret i forordning (EU) 2022/2065 (retsakten om digitale tjenester, »DSA«). Efter artikel 15 i DSA skal alle formidlingstjenester mindst én gang om året offentliggøre en klar og letforståelig rapport i maskinlæsbart format om deres indholdsmoderering. Denne side er den rapport.\n","title":"DSA-transparensrapport – artikel 15","type":"trust"},{"content":"Første gang din SSH-klient forbinder til ssh.frem.sh:443, beder den dig bekræfte serverens fingeraftryk for værtsnøglen. (Port 22 er ikke åben offentligt på hoveddomænet - ssh.frem.sh:443 er det eneste offentliggjorte SSH-endpoint.) Kontrollér, at fingeraftrykket svarer til en af værdierne nedenfor, før du accepterer. Et fingeraftryk, der ikke står her, betyder, at du ser på et man-in-the-middle-angreb, en forældet cache eller en anden server - stol ikke på det.\nAktuelle fingeraftryk # Algoritme SHA-256-fingeraftryk Nøglelængde i bit ssh-rsa SHA256:LNz5zoh9R2KZAhNGeFgKSeBMPEzbNBdd0wqwrwEkU3E 4096 I øjeblikket er kun ssh-rsa offentliggjort. ED25519- og ECDSA-værtsnøgler er ikke slået til i Forgejo-laget i denne installation; kræver din klient dem, kan du tvinge RSA med ssh -o HostKeyAlgorithms=ssh-rsa,rsa-sha2-256,rsa-sha2-512.\nDet gør du, når du bliver spurgt # Når OpenSSH skriver noget i retning af:\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])? Sammenlign det viste fingeraftryk med rækken i tabellen ovenfor. Passer det, skriver du yes; OpenSSH tilføjer nøglen til din ~/.ssh/known_hosts og spørger aldrig igen for den vært. Passer det ikke, skriver du no og kontakter os på support@frem.sh, før du prøver igen.\nUndgå spørgsmålet helt # Du kan stole på værtsnøglen på forhånd ved at føje den til din known_hosts-fil:\nssh-keyscan -t rsa -p 443 ssh.frem.sh \u0026gt;\u0026gt; ~/.ssh/known_hosts Kontrollér derefter SHA-256-værdien med:\nssh-keygen -lf \u0026lt;(ssh-keyscan -t rsa -p 443 ssh.frem.sh 2\u0026gt;/dev/null) Outputtet skal svare til tabellen ovenfor.\nNår fingeraftrykkene skiftes # Vi skifter Forgejos værtsnøgler, kun når den underliggende serverklynge bygges op på ny. Når det sker, offentliggør vi de nye fingeraftryk her mindst 24 timer før skiftet, arkiverer de tidligere fingeraftryk i 90 dage under Tidligere fingeraftryk og lægger en meddelelse på status.frem.sh.\nAdvarer din klient med \u0026ldquo;REMOTE HOST IDENTIFICATION HAS CHANGED\u0026rdquo;, og står det nye fingeraftryk ikke her, så ryd ikke known_hosts - kontakt os først.\nTidligere fingeraftryk # Ingen arkiverede (dette er første gang, siden er offentliggjort).\nRelateret # Forbind til fremforge over SSH - vejledning til clone, reserveløsning via port 443, fejlfinding Statusside - aktuel oppetid + planlagt vedligeholdelse Tillid-siden - underdatabehandlere, revisionsgrundlag, dataopbevaring kun i EU Senest opdateret: 2026-05-06.\n","externalUrl":null,"permalink":"/da/ssh-fingerprints/","section":"Fingeraftryk for SSH-værtsnøgler - frem.sh","summary":"Første gang din SSH-klient forbinder til ssh.frem.sh:443, beder den dig bekræfte serverens fingeraftryk for værtsnøglen. (Port 22 er ikke åben offentligt på hoveddomænet - ssh.frem.sh:443 er det eneste offentliggjorte SSH-endpoint.) Kontrollér, at fingeraftrykket svarer til en af værdierne nedenfor, før du accepterer. Et fingeraftryk, der ikke står her, betyder, at du ser på et man-in-the-middle-angreb, en forældet cache eller en anden server - stol ikke på det.\n","title":"Fingeraftryk for SSH-værtsnøgler - frem.sh","type":"ssh-fingerprints"},{"content":"Gældende fra: 2026-05-24 – fremforges AI-integrationer, fase 1\nKort fortalt # fremforge lader aldrig kundens kode behandle af en amerikansk AI-leverandør som underdatabehandler på standardvejen. Kunden tager sin egen nøgle til en AI-leverandør med (BYOK) og vælger selv leverandøren. Leverandøren er kundens egen databehandler under kundens egen kontrakt og ikke fremverks underdatabehandler under databehandleraftalen.\nDet er fastlagt i DPA bilag B §B.8.\nHvad »AI-integrationer« dækker # fremforge har fire AI-funktioner på serversiden, som bruger den AI-leverandør, kunden har sat op. Hver af dem er slået fra, indtil kunden tilføjer en nøgle:\nAI-review af PR’er – når en pull request åbnes eller opdateres, sender fremforge diffen og PR’ens metadata til den valgte leverandør og poster en struktureret review-kommentar med en commit-status pending → success / warning. Forklaringer til Renovate-opdateringer – PR’er oprettet af Renovate får en mere fokuseret prompt om udbedring af CVE’er og risikoen for ændringer, der bryder bagudkompatibiliteten. Gateway, som kunden selv kan kalde – POST /api/v1/orgs/\u0026lt;slug\u0026gt;/ai/complete med en PAT med scopet ai:invoke. Kundens egne workflows og scripts kalder dette endpoint i stedet for at indlejre leverandørernes SDK’er. AI-rettelser til SAST-fund – slået fra som standard, også når der er sat en nøgle op; en ejer af organisationen slår det til. Når en person klikker på AI fix ved et fund fra en af nogle få udvalgte SAST-regler, sender fremforge reglens beskrivelse og højst 60 linjer fra den berørte fil til leverandøren, kontrollerer den diff, der kommer tilbage, scanner den igen og åbner en pull request, som aldrig merges automatisk. fremforge gemmer hverken prompt, kode eller diff. Se AutoFix. Der findes en separat vej for AI-værktøjer på udviklersiden (Claude Code, Cursor, Continue og JetBrains AI, der taler med fremforge via det almindelige REST-API og en PAT). Den vej sender ikke noget til en AI-leverandør gennem fremverks infrastruktur; se docs.frem.sh/get-started/ai-in-your-ide/.\nUnderstøttede leverandører (fase 1, BYOK) # fremforge understøtter tre typer adaptere, som tilsammen dækker alle de store leverandører i dag:\nAdapter Eksempler på leverandører openai-compatible OpenAI, Azure OpenAI, Mistral, Together, Fireworks, OpenRouter, T-Cloud AIFS og enhver anden OpenAI-kompatibel URL anthropic Anthropics eget API vertex-gemini Google Vertex Gemini Kunden indsætter en API-nøgle fra leverandøren i admin-UI’et på /\u0026lt;org\u0026gt;/_admin/ai-integrations. Nøglen krypteres i hvile med AES-256-GCM via T Cloud Public DEW KMS med AAD-binding pr. række (så en nøgle, der trækkes ud af en databasebackup, ikke kan dekrypteres, medmindre man også får fat i det tilhørende række-id).\nDatavejen # For hvert AI-kald (PR-review, Renovate-forklaring eller /ai/complete kaldt fra et workflow):\nKundens repository, en webhook-payload eller et workflow-trin starter forespørgslen. fremforges api-pod sammensætter prompten: diff-tekst + PR-metadata + systemprompt + beskeder fra kunden. fremforges api-pod sender en HTTPS-forespørgsel til den URL, kunden har sat op for leverandøren, med kundens nøgle. Leverandørens svar registreres: antal tokens, svartid, modelnavn og svartekst. fremforge poster en Forgejo-kommentar (PR-review) ELLER returnerer svaret til workflowet (/ai/complete). En række i ai_usage_events registrerer kaldet: organisation, udbyder, model, tokens ind, tokens ud og svartid. Prompten og selve svaret gemmes ikke ud over forespørgslens levetid. Prompt og svar passerer fremforges api-pod én gang. De passerer ikke nogen tredjeparts logaggregator, observability-tjeneste eller backup. Revisionsloggen for hvert kald indeholder metadata (hvilken funktion, hvilken udbyder, antal tokens), men ikke indholdet.\nHvorfor »ikke en underdatabehandler« # Efter artikel 28 i GDPR er nogen underdatabehandler, når den dataansvarlige udpeger dem, indgår kontrakt med dem og instruerer dem i at behandle data på den dataansvarliges vegne. Intet af det gælder her:\nKunden vælger AI-leverandøren. fremverk hverken udpeger eller anbefaler en. Rullelisten i admin-UI’et viser typer af adaptere, ikke anbefalinger. Kunden indgår selv kontrakt med AI-leverandøren. fremverk har intet kommercielt forhold til AI-leverandøren til dette formål. Kunden betaler leverandøren; fremverk lægger ikke noget oven i leverandørens tokenpriser. Kunden kan til enhver tid fjerne AI-leverandøren uden at give fremverk besked. Sådan fungerer et forhold til en af fremverks underdatabehandlere ikke. fremverks egen forpligtelse om ingen underdatabehandlere med amerikansk moderselskab i DPA §11.3 er uændret. En kunde, der vælger en AI-leverandør registreret i USA (OpenAI, Anthropic, Google Vertex), udsætter sig selv for den leverandørs jurisdiktion – ikke fremverks. Det er den samme juridiske stilling som for identitetsudbydere, kunden selv vælger (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik) og forbinder til fremforge via OIDC. De står i indledningen til bilag B af samme grund.\nFase 2: en »nøglefærdig« løsning # Når AIFS (T-Cloud AI Foundation Services) får en kodetrænet model, der er god nok til PR-review – forventet om 6–18 måneder – planlægger fremverk at tilbyde et nøglefærdigt AI-abonnement, hvor fremverk har en AIFS-konto i Tyskland og fakturerer tokens pr. plads. Den løsning vil gøre AIFS til en ny underdatabehandler for fremverk, og den vil blive føjet til registret i bilag B med det varsel på 30 dage, der følger af §10.2.\nBYOK-vejen forbliver tilgængelig, også når den nøglefærdige løsning er lanceret – kunderne kan altid tage deres egen nøgle med.\nSynlighed i revisionsloggen # Hvert AI-kald giver en hændelse i revisionsloggen:\ntenant.ai_integration.provider_added / _disabled / _tested – ændringer i opsætningen af udbydere tenant.ai_integration.feature_default_changed – hvilken udbyder der håndterer hvilken funktion tenant.ai_integration.repo_override_changed / _removed – undtagelser pr. repository ai.complete.ok / ai.complete.failed – hver forespørgsel til /ai/complete, som kunden selv kalder Kunderne ser tokenforbrug pr. måned og 👍/👎-tilfredshed pr. udbyder og model i admin-UI’et; begge dele bygger på tabellerne ai_usage_events og ai_review_comments. Kundernes revisionslogs (DPA §9, opbevaring i 13 måneder) indeholder alle tenant.ai_integration.*-hændelser.\nFejl håndteres blidt # AI-funktioner blokerer aldrig en PR. Hvis leverandøren returnerer en fejl, rammer en rate limit, overskrider kundens loft for forbrug eller nøglen er ugyldig, springes review-kommentaren over, og der vises en commit-status warning (»AI review unavailable: retry on next push or fix the key«). Kundens CI påvirkes ikke; det eneste, der mangler, er den AI-genererede kommentar.\nSpørgsmål og anmodninger om revision # Til compliance-gennemgang: denne side er tillidsdokumentationen, du kan linke direkte til. Den kontraktlige forankring er DPA bilag B §B.8. Spørgsmål sendes til compliance@frem.sh.\n","externalUrl":null,"permalink":"/da/trust/ai-integrations/","section":"Tillid","summary":"Gældende fra: 2026-05-24 – fremforges AI-integrationer, fase 1\nKort fortalt # fremforge lader aldrig kundens kode behandle af en amerikansk AI-leverandør som underdatabehandler på standardvejen. Kunden tager sin egen nøgle til en AI-leverandør med (BYOK) og vælger selv leverandøren. Leverandøren er kundens egen databehandler under kundens egen kontrakt og ikke fremverks underdatabehandler under databehandleraftalen.\n","title":"AI-integrationer – datavej og suverænitet","type":"trust"},{"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":"/da/","section":"fremforge - europæisk alternativ til GitHub med CI/CD","summary":"","title":"fremforge - europæisk alternativ til GitHub med 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":" Sammenlign\nfremforge vs. GitHub fremforge er et europæisk alternativ til GitHub: Git-hosting, pull requests, CI/CD-runnere, pakkeregistries og sikkerhedsscanning på én platform, drevet af en europæisk virksomhed på T\u0026nbsp;Cloud\u0026nbsp;Public i Tyskland. Siden her sammenligner de to på pris, sikkerhed, forsyningskæde og dataplacering ud fra GitHubs egne offentliggjorte sider og siger ligeud, hvad GitHub har, som vi ikke har. Pris for et team, der committer kode På GitHub er hemmelighedsscanning og kodescanning på private repositorier betalte tilkøb pr. aktiv committer. På fremforge er de med i pladsen.\nGitHub Enterprise Cloud 🇺🇸 amerikansk selskab $70/committer/md.$21 Enterprise Cloud + $19 Secret Protection + $30 Code Security\nEnterprise Cloud \"starting at $21 USD per user/month\" (GitHubs priser). Secret Protection koster \"$19 USD per active committer/month\" og Code Security \"$30 USD per active committer/month\" (GitHubs sikkerhedsplaner). En committer er aktiv, hvis \"one of their commits has been pushed to the repository within the last 90 days\" (GitHubs dokumentation om fakturering). For et medlem, der committer, bliver det $70 om måneden; et medlem, der aldrig committer, koster $21.\nfremforge 🇪🇺 hostet i Tyskland 30 €/plads/md.fast pris · 25,50 €/plads/md. ved årlig betaling\nHemmelighedsscanning med push-beskyttelse, SAST, scanning af afhængigheder, container-images, IaC og licenser, nåbarhed, rettelses-pull requests, afhængighedsproxyen og 1.000 CI-minutter pr. plads pr. måned – alt sammen i prisen pr. plads. Priser.\nGitHubs priser er i USD, som de er offentliggjort; vi har ikke omregnet dem. GitHub Team koster $4 pr. bruger pr. måned og kan købe de samme to tilkøb; planen har hverken SAML single sign-on eller IP-tilladelsesliste (GitHubs planer).\nFunktion for funktion GitHub-kolonnen: hvad GitHubs egen dokumentation siger for private repositorier ejet af en organisation. fremforge-kolonnen: hvad hver fremforge-plads indeholder.\nFunktionGitHubfremforge Hemmelighedsscanning og push-beskyttelseKræver tilkøbet Secret Protection på Team eller Enterprise Cloud (dokumentation)Inkluderet. Hemmeligheder afvises, før commit’et kommer ind i historikken, med egne mønstre pr. organisation eller repository Kontrol af, om hemmeligheder er gyldigeTilkøbet Secret Protection (dokumentation)Inkluderet og slås til pr. udbyder; konsollen viser, hvor hver kontrol sendes hen Kodescanning (SAST)CodeQL; kræver tilkøbet Code Security (dokumentation)Inkluderet. OpenGrep på hver pull request, slået til som standard Advarsler om sårbare afhængighederDependabot-advarsler og sikkerhedsopdateringer på alle planer (dokumentation)Inkluderet. Trivy og osv-scanner på hver pull request; merge blokeres ved den alvorlighed, du vælger Scanning af container-imagesVia scannere fra tredjepart, der uploader SARIF-resultater (dokumentation)Inkluderet. Hvert image, der pushes til registryet, scannes, med rettelses-pull requests til base-imaget Scanning af infrastructure-as-codeVia scannere fra tredjepart (samme SARIF-vej)Inkluderet. Terraform, Kubernetes, Helm, Dockerfile og Compose på hver pull request NåbarhedEt signal til rangering af Dependabot-advarsler (\"whether vulnerable function calls are detected\") (dokumentation)Hvert fund markeres som nåbart, ikke nåbart eller ukendt, med fil og linje som bevis. Kaldgrafer for Go, JavaScript og TypeScript; Python, Java og Kotlin på import-niveau Kendt udnyttede førstEPSS-filter på Dependabot-advarsler (dokumentation)Sårbarheder i ENISA’s EU Vulnerability Database og CISA’s KEV får et mærke, rangeres først og rettes først; EPSS inden for samme alvorlighed Automatiske rettelserDependabot-sikkerhedsopdateringer; Copilot Autofix til kodescanning kræver Code Security (dokumentation)Rettelses-pull requests til npm, Go, PyPI, Maven, Gradle, NuGet, Cargo og base-images, én pr. pakke, kendt udnyttede først; AI-rettelser til udvalgte SAST-fund med din egen modelnøgle LicensoverholdelseEnterprise-konto med Code Security (dokumentation)Inkluderet. SPDX-tilladelsesliste pr. repository, arvet fra organisationen Afhængighedsproxy og pakkecacheEn pakke-firewall i offentlig preview for enterprises, dokumenteret for npm (dokumentation)Inkluderet og slået til som standard: npm, PyPI, Go, Maven, NuGet, Cargo, Helm, RPM og container-images caches pr. organisation. Kendt malware afvises, pakkepolitik, minimumsalder for releases; leverer fortsat, når et upstream-registry er nede MalwareMalware-advarsler sammen med Dependabot-advarsler (dokumentation)Kendt malware afvises i afhængighedsproxyen; ClamAV på hver upload af pakker og images SBOM og provenanceSBOM-eksport for alle; artefaktattesteringer på private repositorier kræver Enterprise Cloud, SLSA Build Level 2 (dokumentation)SBOM med hvert image, runneren bygger; signeret SLSA-provenance fra de hostede runnere SigneringAttesteringer på Sigstore Public Good for offentlige repositorier, GitHubs egen instans for private (dokumentation)Nøglefri signering med cosign på fremforges egen Sigstore (Fulcio og tidsstempelautoritet) i Tyskland; politik for image-signaturer ved pull Godkendelse af udrulningerKrav om godkendere på private repositorier kræver Enterprise (dokumentation)Inkluderet. Navngivne miljøer med secrets, branch-regler og krav om godkendere pr. miljø Revisionslog til din SIEMStreaming af revisionsloggen på Enterprise Cloud (dokumentation)Inkluderet. Signeret levering til Splunk, QRadar, Sentinel eller Datadog; hashkædet revisionsspor IP-tilladelseslisteKun Enterprise Cloud (dokumentation)Inkluderet CI-minutter3.000 om måneden på Team og 50.000 på Enterprise Cloud pr. konto; derefter $0.006 pr. minut for Linux (dokumentation)1.000 om måneden pr. plads i en fælles pulje; derefter 0,01 € pr. minut; én engangs-VM pr. job Hvor dine data ligger\"your local region, the United States, and other countries\" (privatlivserklæring); en mulighed for dataopbevaring i EU på Enterprise Cloud, hvor nogle data dog gemmes uden for regionen (dokumentation)Tyskland, på Deutsche Telekoms T\u0026nbsp;Cloud\u0026nbsp;Public (eu-de). Ingen databehandler med amerikansk moderselskab på datavejen Det har GitHub, som fremforge ikke har En gratis plan. GitHub Free koster $0. fremforge har en gratis prøveperiode på 30 dage og koster derefter 30 € pr. plads. SAML single sign-on. fremforge logger ind via OIDC (Entra ID, Okta, Google Workspace, Keycloak, Authentik med flere), ikke SAML. Selvhosting. GitHub Enterprise Server kører i dit eget datacenter. fremforge findes kun hostet. Copilot. fremforge har ingen egen AI; de valgfrie AI-funktioner kører kun med din egen nøgle hos udbyderen. Økosystemet. GitHub Marketplace, Codespaces, GitHub Pages og det største open source-fællesskab. Almindelige Actions som actions/checkout virker på fremforge via spejle i EU; nogle Marketplace-actions kræver små ændringer. Projekter og planlægning. fremforge har issues, labels og milepæle, men ikke GitHub Projects-tavler. Flyt fra GitHub Importværktøjet kopierer repositorier med deres historik, issues, pull requests og releases. Et lille repository med enkle Actions tager 15 til 30 minutters aktivt arbejde. Du kan også spejle repositorier og arbejde videre på GitHub, mens du flytter.\nPrøv gratis i 30 dage → Læs vejledningen til migrering fra GitHub Alle udsagn om GitHub på denne side stammer fra GitHubs egne sider, linket hvor udsagnet står, og er aflæst 23. oktober 2026. GitHub ændrer sine planer og priser; er noget her forældet, så skriv til os på support@frem.sh, så retter vi det. GitHub er et varemærke tilhørende GitHub, Inc. fremforge er ikke tilknyttet GitHub.\n","externalUrl":null,"permalink":"/da/vs/github/","section":"Vs","summary":" Sammenlign\nfremforge vs. GitHub fremforge er et europæisk alternativ til GitHub: Git-hosting, pull requests, CI/CD-runnere, pakkeregistries og sikkerhedsscanning på én platform, drevet af en europæisk virksomhed på T Cloud Public i Tyskland. Siden her sammenligner de to på pris, sikkerhed, forsyningskæde og dataplacering ud fra GitHubs egne offentliggjorte sider og siger ligeud, hvad GitHub har, som vi ikke har. ","title":"fremforge vs. GitHub: et europæisk alternativ til GitHub","type":"vs"},{"content":" Sammenlign\nfremforge vs. GitLab fremforge er et europæisk alternativ til GitLab: Git-hosting, merge requests som pull requests, CI/CD-runnere, pakkeregistries og sikkerhedsscanning på én platform, drevet af en europæisk virksomhed på T\u0026nbsp;Cloud\u0026nbsp;Public i Tyskland. Siden her sammenligner de to på pris, sikkerhed, forsyningskæde og dataplacering ud fra GitLabs egne offentliggjorte sider og siger ligeud, hvad GitLab har, som vi ikke har. Pris pr. plads Det meste af GitLabs sikkerhedsscanning ligger i Ultimate, som GitLab nu kun prissætter på forespørgsel. På fremforge er den med i den samme pris pr. plads.\nGitLab Premium 🇺🇸 amerikansk selskab $29/bruger/md.ved årlig betaling\n\"$29 per user/month, billed annually\" med 10.000 compute-minutter om måneden (GitLabs priser). Scanning af afhængigheder, secret push protection, DAST og licensscanning er Ultimate-funktioner (kilder i tabellen nedenfor).\nGitLab Ultimate 🇺🇸 amerikansk selskab $99/bruger/md.rapporteret listepris ved årlig betaling\nGitLabs side skriver \"Get custom pricing\", med 50.000 compute-minutter om måneden (GitLabs priser); $99 pr. bruger pr. måned ved årlig betaling er den pris, købere oplyser (SpendBase).\nfremforge 🇪🇺 hostet i Tyskland 30 €/plads/md.fast pris · 25,50 €/plads/md. ved årlig betaling\nHemmelighedsscanning med push-beskyttelse, SAST, scanning af afhængigheder, container-images, IaC og licenser, nåbarhed, rettelses-pull requests, afhængighedsproxyen og 1.000 CI-minutter pr. plads pr. måned – alt sammen i prisen pr. plads. Priser.\nGitLabs priser er i USD, som de er offentliggjort; vi har ikke omregnet dem. GitLab Free koster $0 for op til 5 brugere pr. topniveau-gruppe, med 400 compute-minutter om måneden (GitLabs priser).\nFunktion for funktion GitLab-kolonnen: det niveau, GitLabs egen dokumentation angiver for gitlab.com. fremforge-kolonnen: hvad hver fremforge-plads indeholder.\nFunktionGitLabfremforge Hemmelighedsscanning i pipelinesFree og opefter (dokumentation)Inkluderet Push-beskyttelse mod hemmelighederUltimate (dokumentation)Inkluderet. Hemmeligheder afvises, før commit’et kommer ind i historikken, med egne mønstre pr. organisation eller repository Kontrol af, om hemmeligheder er gyldigeUltimate (dokumentation)Inkluderet og slås til pr. udbyder SASTGrundlæggende scanning på alle niveauer; fund i merge requests og Advanced SAST i Ultimate (dokumentation)Inkluderet. OpenGrep på hver pull request, med fund direkte på pull requesten Scanning af afhængighederUltimate (dokumentation)Inkluderet. Trivy og osv-scanner på hver pull request Scanning af containereScanning på alle niveauer; visning i merge requests og sikkerhedsoversigter i Ultimate (dokumentation)Inkluderet. Hvert image, der pushes, scannes, med rettelses-pull requests til base-imaget Scanning af infrastructure-as-codeScanning på alle niveauer; behandling af resultater i Ultimate (dokumentation)Inkluderet. Terraform, Kubernetes, Helm, Dockerfile og Compose NåbarhedStatisk nåbarhed, Ultimate (dokumentation)Inkluderet. Nåbar, ikke nåbar eller ukendt, med fil og linje som bevis Kendt udnyttede og EPSSKEV og EPSS på siden med sårbarhedsdetaljer, Ultimate (dokumentation)Inkluderet. Sårbarheder i ENISA’s EU Vulnerability Database og CISA’s KEV rangeres og rettes først; EPSS inden for samme alvorlighed Automatiske rettelserAutomatisk afhjælpning ved containerscanning og agentbaseret løsning af SAST-fund, Ultimate (dokumentation)Inkluderet. Rettelses-pull requests til npm, Go, PyPI, Maven, Gradle, NuGet, Cargo og base-images; AI-rettelser til udvalgte SAST-fund med din egen modelnøgle LicensoverholdelseUltimate (dokumentation)Inkluderet. SPDX-tilladelsesliste pr. repository DASTUltimate (dokumentation)Tilbydes ikke AfhængighedsproxyContainer-images på alle niveauer, som pull-through-cache (dokumentation); et virtuelt registry til andre formater i beta, Premium og opefter (dokumentation)Inkluderet og slået til som standard: npm, PyPI, Go, Maven, NuGet, Cargo, Helm, RPM og container-images – kendt malware afvises, med pakkepolitik og minimumsalder for releases SBOMAfhængighedsliste og eksport, Ultimate (dokumentation)SBOM med hvert image, runneren bygger; signeret SLSA-provenance SigneringNøglefri signering med Sigstore i CI (dokumentation)Nøglefri signering med cosign på fremforges egen Sigstore i Tyskland; politik for image-signaturer ved pull Beskyttede miljøerPremium og opefter (dokumentation)Inkluderet. Krav om godkendere pr. miljø Revisionslog til din SIEMStreaming af revisionshændelser, Ultimate (dokumentation)Inkluderet. Signeret levering til Splunk, QRadar, Sentinel eller Datadog IP-tilladelseslistePremium og opefter (dokumentation)Inkluderet Hvor dine data ligger\"hosted in the United States\" for gitlab.com (privatlivserklæring); valg af region, også i EU, med GitLab Dedicated, et single-tenant Ultimate-tilbud på AWS (dokumentation)Tyskland, på Deutsche Telekoms T\u0026nbsp;Cloud\u0026nbsp;Public (eu-de). Ingen databehandler med amerikansk moderselskab på datavejen Det har GitLab, som fremforge ikke har En gratis plan. GitLab Free koster $0 for op til 5 brugere. fremforge har en gratis prøveperiode på 30 dage og koster derefter 30 € pr. plads. Self-managed og Dedicated. GitLab kører i dit eget miljø eller som en single-tenant-instans. fremforge findes kun hostet. SAML single sign-on. fremforge logger ind via OIDC (Entra ID, Okta, Google Workspace, Keycloak, Authentik med flere), ikke SAML. DAST. fremforge udfører ikke dynamisk sikkerhedstest af applikationer. Planlægning. Epics, roadmaps og iterationer. fremforge har issues, labels og milepæle. GitLab CI-syntaks. fremforges CI bruger workflow-syntaksen fra GitHub Actions, så .gitlab-ci.yml-pipelines skal skrives om til workflows. Migreringsvejledningen viser hvordan. Flyt fra GitLab Importværktøjet kopierer repositorier med hele deres historik, issues, merge requests (som pull requests), labels, milepæle, wikier og releases. Et lille repository med en enkel .gitlab-ci.yml tager 30 til 60 minutter, inklusive pipelinen.\nPrøv gratis i 30 dage → Læs vejledningen til migrering fra GitLab Alle udsagn om GitLab på denne side stammer fra GitLabs egne sider, linket hvor udsagnet står, og er aflæst 23. oktober 2026. GitLab ændrer sine niveauer og priser; er noget her forældet, så skriv til os på support@frem.sh, så retter vi det. GitLab er et varemærke tilhørende GitLab Inc. fremforge er ikke tilknyttet GitLab.\n","externalUrl":null,"permalink":"/da/vs/gitlab/","section":"Vs","summary":" Sammenlign\nfremforge vs. GitLab fremforge er et europæisk alternativ til GitLab: Git-hosting, merge requests som pull requests, CI/CD-runnere, pakkeregistries og sikkerhedsscanning på én platform, drevet af en europæisk virksomhed på T Cloud Public i Tyskland. Siden her sammenligner de to på pris, sikkerhed, forsyningskæde og dataplacering ud fra GitLabs egne offentliggjorte sider og siger ligeud, hvad GitLab har, som vi ikke har. ","title":"fremforge vs. GitLab: et europæisk alternativ til 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":"For konsulenthuse og managed service-udbydere, der sælger udviklerværktøjer i Norden.\nHvorfor blive partner hos fremforge # Dine kunder bliver spurgt, hvor deres kildekode ligger. fremforge er EU-suveræn Git-hosting med CI inkluderet – al behandling foregår i EU, der er ingen underdatabehandlere med amerikansk moderselskab på nogen vej, og du kan eksportere fra første dag.\nDu har kunderelationen. Vi driver platformen.\nSådan fungerer det # Registrér salget. Fortæl os, hvilken virksomhed du arbejder med, så tidligt som muligt. Registreringen giver dig en beskyttelsesperiode på 90 dage på kunden. Vi sender dig en e-mail 14 dage og 3 dage før den udløber, så den aldrig løber ud i stilhed.\nVind kunden, og opret den selv. Fra din portal opretter du kundens organisation og inviterer deres administrator, og kunden knyttes til dig i samme øjeblik, den findes – så avancen tæller fra deres første faktura og ikke fra det tidspunkt, hvor en operatør nåede at gøre det.\nTjen løbende avance. Ikke et engangshonorar for en henvisning. Du tjener på dine kunders faktiske fakturaer, så længe de bliver, og satsen afspejler, hvor længe relationen har varet.\nFå betaling efter en månedlig opgørelse. Vi laver din opgørelse for den foregående måned den 1. og sender den til dig på e-mail. Du fakturerer os på dit eget dokument; vi betaler 30 dage efter modtagelsen. Mellem opgørelserne viser din portal avancen, efterhånden som den optjenes, så intet kommer bag på dig.\nHvis to partnere gør krav på samme kunde # Vi afgør det ud fra dokumenteret salgsaktivitet – møder, tilbud, korrespondance – aldrig ud fra, hvem der registrerede først, og aldrig ud fra, hvem der er størst.\nVi fortæller heller aldrig nogen af parterne, hvem den anden er. En konflikt er en samtale mellem dig og os, ikke mellem dig og en konkurrent.\nDet får du # En partnerportal på engelsk, dansk, tysk, fransk, hollandsk og svensk Registrering af salg med automatisk opfølgning på beskyttelsen Selvbetjent oprettelse af kunder Månedlige opgørelser fordelt pr. kunde, som du kan afstemme Et komplet REST-API – alt i portalen kan scriptes, så du kan styre det fra dit eget CRM eller en assistent En signeret rammeaftale, underskrevet med nationalt eID Underskrift # Rammeaftalen underskrives elektronisk med dit nationale eID. I Danmark og Sverige bruger vi et virksomhedsbundet login – MitID Erhverv og Freja eID+ organisation – så underskriften dokumenterer retten til at forpligte virksomheden og ikke kun, hvem der klikkede.\nI Norge og Finland findes der ikke et virksomhedslogin, så vi registrerer underskriverens titel og læner os op ad garantien for fuldmagt i aftalen. Vi fortæller dig, hvad der gælder for dig, før noget bliver sendt.\nDu behøver ikke være den person, der er registreret som tegningsberettiget for virksomheden. En salgsdirektør, der underskriver inden for sit ansvarsområde, forpligter virksomheden efter almindelige fuldmagtsregler; hvis din organisation begrænser, hvem der har virksomhedens login, har vi en dokumenteret fremgangsmåde for det.\nHvor vi søger partnere # Danmark, Sverige, Norge og Finland i dag. Sælger du udviklerværktøjer andre steder i EU, så tag alligevel fat i os – platformen dækker hele EU, og programmet følger efterspørgslen.\nAnsøg # Skriv til partners@frem.sh med din virksomhed, de lande, du sælger i, og hvilken type kunder du arbejder med. Vi optager partnere efter invitation og taler med alle, der ansøger.\nDe kommercielle vilkår – avancesatser, niveauer og tærskler – deles i den samtale og fremgår af rammeaftalen.\n","externalUrl":null,"permalink":"/da/partners/","section":"Partnerprogram","summary":"For konsulenthuse og managed service-udbydere, der sælger udviklerværktøjer i Norden.\nHvorfor blive partner hos fremforge # Dine kunder bliver spurgt, hvor deres kildekode ligger. fremforge er EU-suveræn Git-hosting med CI inkluderet – al behandling foregår i EU, der er ingen underdatabehandlere med amerikansk moderselskab på nogen vej, og du kan eksportere fra første dag.\n","title":"Partnerprogram","type":"partners"},{"content":" Priser\nÉn plan. Pr. plads. I EUR. Hver plads leveres med suverænitet, Security (scanning, prioritering og rettelser), hostede runnere og fuld ret til eksport. Én pris dækker Actions-minutter, sikker signering, scanning af afhængigheder og dataeksport, når du har brug for den – alt sammen på EU-infrastruktur. Månedlig Årlig −15 % 30 € / plads / måned Faktureres månedligt. Opsig når som helst til udgangen af den betalte måned.\nFaktureres i EUR. Omvendt betalingspligt for moms for B2B-kunder i EU med et gyldigt VIES-momsnummer.\nLæsere med læseadgang er gratis og ubegrænsede. Kun medlemmer, der kan pushe eller administrere, tæller som en plads. Sådan fungerer læsere →\nMed dagens midtkurser svarer 30 € til cirka 26 £ / 28 CHF / 320 NOK / 224 DKK. Din faktiske pris i lokal valuta afhænger af kursen på hver fakturadato. Kunder uden for euroområdet betaler i EUR; deres bank eller kortudbyder står for omregningen. Enterprise-kunder, der faktureres med betalingsfrist, kan i stedet aftale fakturering i DKK.\nPrøv gratis i 30 dage → Gratis prøveperiode i 30 dage ved oprettelsen. Kortet godkendes ved oprettelsen via Mollies hostede checkout (0 € – der trækkes intet; nogle banker reserverer kortvarigt 0,01 € og frigiver det igen). Prøveperioden overgår automatisk til din månedlige plan på dag 30; du kan opsige gratis når som helst før under Admin → Fakturering. Vi sender en påmindelse 3 dage før den automatiske opkrævning.\nGrænser i prøveperioden: 1 plads, 10 repositorier, 500 runner-minutter i en fælles pulje for hele prøveperioden på 30 dage og op til 5 GB cache i afhængighedsproxyen. Den fulde månedlige pulje på 1.000 runner-minutter pr. plads låses op ved første betaling. Grænserne beskytter platformen i prøveperioden; en reel evaluering ligger komfortabelt inden for dem – det svarer til ca. 25-50 typiske CI-kørsler.\nÅrlig binding: 306 € pr. plads opkræves forud for hele året. Opsiger du, har du adgang frem til slutdatoen for bindingen, og året er betalt. Fornyes automatisk, medmindre du opsiger senest 30 dage før periodens udløb. Alle detaljer står i servicevilkårene. Det er inkluderet Forgejo-fladen. Repositorier, issues, PR’er og pakkeregistry – Forgejo upstream med et lille sæt MFA-patches (API-kompatibelt). Gratis læsere. Tilføj et ubegrænset antal medlemmer med rollen læser – de kan clone, gennemse kode og læse issues og PR’er – uden beregning. Du betaler kun for medlemmer, der kan pushe eller administrere. Auditors. Hver organisation har et indbygget Auditors-team med læseadgang, som også kan læse organisationens indstillinger, medlemmer og revisionssporet – men aldrig ændre noget eller downloade eksporter. De første 5 auditors pr. organisation er gratis; den sjette og de følgende tæller som en plads. Sådan fungerer auditors. Hostede CI-runnere. 1.000 minutter pr. plads pr. måned i en fælles pulje. Samtidige jobs: 2 pr. plads garanteret (mindst 10, højst 60) og op til 60, når der er ledig kapacitet (rimelig brug; mere efter aftale). 0,01 € pr. minut ud over puljen. Hvert job tælles i hele minutter, rundet op (et job på 61 sekunder tæller som 2 minutter), både i puljen og ved merforbrug. Én engangs-VM pr. job. Suveræn byggekæde. De hostede runnere installerer npm-, PyPI-, Go-, Maven- og NuGet-pakker og henter container-images gennem din organisations afhængighedsproxy, og GitHub Actions hentes fra Forgejo-spejle (pull). Sættes automatisk op i hvert runner-job. Afhængighedsproxy. Hent container-images samt npm-, PyPI-, Maven-, NuGet-, Go-, Cargo-, Helm- og RPM-pakker fra de store offentlige registries gennem frem.sh, cachet for din organisation. Slået til som standard. Hentninger fra Docker Hub bruger din organisations egne Docker Hub-loginoplysninger. Rimelig brug jf. AUP §4A. Security. Hemmelighedsscanning i pre-receive, push-beskyttelse, scanning af afhængigheder, licenser, images og malware, SAST, nåbarhedsvurderinger (nåbar, ikke nåbar, ukendt), mærker for kendt udnyttede sårbarheder (ENISA EUVD + CISA KEV), rettelses-pull requests, signerede commits, SLSA-provenance, SBOM for hvert build og fastlåsning af workflows (PR, der omskriver til SHA-pins). Compliance. Compliancerapport, kontroldokumentation og en signeret leverandørattestering af revisionskæden og sikkerhedsniveauet, når du beder om den (HTML + JSON). Opdatering af afhængigheder (sikkerhedsrettelser og versionsopdateringer). Versionsopdateringer efter en tidsplan med 3 dages ventetid efter en release, og rettelses-pull requests med ét klik eller, hvis du vælger det, automatisk for de vigtigste fund – én pr. pakke til den laveste version med rettelsen. Sikkerhedsrettelser virker uden at versionsopdateringer er slået til; som standard venter de på review, og automatisk merge, når tjekkene er grønne, er noget, du selv slår til. Lager. 5 GB repository + 5 GB LFS + 5 GB pakker pr. plads, som tre separate puljer for hele organisationen. Cachen i afhængighedsproxyen tæller med i pakkepuljen. Udgående pakketrafik. Blødt loft på 100 GB pr. plads pr. måned (vi giver dig besked); hårdt loft på 300 GB pr. plads pr. måned, hvorefter hastigheden begrænses til 1 Mbps indtil den 1. i måneden. Intet gebyr for merforbrug. Downloads fra runnere hostet af fremforge tæller aldrig med i nogen af lofterne; selvhostede runnere og andre klienter gør. SSO med step-up MFA. OIDC SSO (Entra ID, ADFS, Okta, Google Workspace) med ægte verifikation af acr_values/amr-claim (ikke kun ved første login) og sessioner bundet til organisationen. Adgangskontrol på enterprise-niveau. SSH-CA, hardwarebaserede nøgler (kun WebAuthn), IP-tilladelsesliste, tilladelsesliste for e-maildomæner, maksimal levetid for PAT’er pr. organisation, krav om signerede commits og standarder for branch-beskyttelse i hele organisationen. SCIM 2.0-provisionering. Send brugere og grupper fra Okta, Entra, Authentik eller enhver kompatibel IdP. Bearer-token-godkendelse pr. organisation med rotation af to tokens. OIDC-føderation. Kortlivede T Cloud Public-adgangsoplysninger i hvert job. Ingen langlivede deploy-nøgler. Udrulningsmiljøer. Secrets og branch-begrænsninger pr. miljø samt krav om godkendere. SIEM-videresendelse. HMAC-signerede revisionshændelser sendes med POST til dit Splunk/QRadar/Sentinel/Datadog-endpoint. Rettefrist (SLA). Du sætter selv antal dage til rettelse pr. alvorlighed; fund over fristen vises som notifikationer. Du kan vælge at forlænge fristen for fund, der ikke er nåbare; kendt udnyttede fund beholder altid den fulde frist. Offentligt REST-API. Samme flade, som mennesker bruger. PAT + OAuth 2.0 client credentials. Klar til AI-agenter. AI-integrationer (egen nøgle). PR-review, Renovate-forklaringer, AI-rettelser til udvalgte SAST-fund (slået fra som standard) og /ai/complete, som kunder selv kan kalde. Tag din egen nøgle med – Anthropic, OpenAI, Mistral, Vertex Gemini eller en hvilken som helst OpenAI-kompatibel URL. Datavej \u0026amp; suverænitet → Offentlige repositorier understøttes. Private som standard. Eksport med ét klik, der afslører manipulation. Repositorier, LFS, Actions-logs, udsnit af revisionsloggen og attesteringer – pakket med et SHA-256-manifest. Opbevaring af revisionsloggen i op til 2 år. Kan indstilles pr. organisation (90 / 180 / 365 / 730 dage). Det hashkædede indeks gemmes for altid; indholdet udløber efter din politik. WORM-forankret med replika i en anden region. Merforbrug af lager. 0,20 € pr. GB pr. måned på den pågældende pulje, faktureret bagud. Sådan står 30 € i sammenligning Én pris pr. plads med hele forsyningskædens sikkerhed inkluderet – intet sikkerhedstilkøb. Funktion for funktion: fremforge vs. GitHub og fremforge vs. GitLab.\nGitHub Enterprise + sikkerhedstilkøb 🇺🇸 amerikansk selskab $70/committer/md.$21 Enterprise + $19 Secret Protection + $30 Code Security\nEnterprise koster $21 pr. bruger pr. måned (GitHubs priser). Secret Protection ($19) og Code Security ($30) er tilkøb, der faktureres pr. måned for hver aktiv committer: alle, hvis commit er blevet pushet til et repository med funktionen slået til inden for de seneste 90 dage (GitHubs changelog, 4. marts 2025; GitHubs dokumentation om fakturering). For et medlem, der committer, bliver det $70 om måneden. Team ($4) mangler SAML single sign-on og IP-tilladelseslisten. Actions-minutter måles og faktureres separat.\nGitLab Ultimate 🇺🇸 amerikansk selskab $99/bruger/md.rapporteret listepris ved årlig betaling\nSAST, DAST, scanning af afhængigheder \u0026amp; containere og sårbarhedsstyring. CI-minutter måles og faktureres separat. GitLabs egen side skriver nu \"Get custom pricing\"; $99 pr. bruger pr. måned er den pris, købere oplyser (SpendBase). Premium ($29 pr. bruger pr. måned ved årlig betaling) indeholder dem ikke (GitLabs priser).\nfremforge 🇪🇺 hostet i Tyskland 30 €/plads/md.fast pris · 360 €/plads/år · 306 € ved årlig binding\nSecurity inkluderet, med nåbarhed og rettelses-pull requests. 1.000 CI-minutter pr. plads i en fælles pulje. Opdatering af afhængigheder (sikkerhedsrettelser og versionsopdateringer). Signeret eksport. Ingen amerikanske underdatabehandlere.\nPriserne for GitHub og GitLab er i USD, aflæst 23. oktober 2026: GitHubs er de offentliggjorte listepriser, og GitLab Ultimates er den rapporterede listepris, da GitLab kun oplyser den på forespørgsel. GitHub fakturerer sine sikkerhedstilkøb pr. aktiv committer, så et team kun betaler for de medlemmer, der pusher kode; hos fremforge er de inkluderet i hver plads. fremforge prissætter i EUR hele vejen igennem, uden valutarisiko ved fornyelse. Priserne gennemgås én gang om året.\nfrembench — tilkøb pr. bench-plads En Linux-maskine, du bruger fra browseren, så din kodeagent kan køre uden din laptop. Kræver en fremforge-plads.\n39 € / bench-plads / måned 200 timers driftstid inkluderet i en fælles pulje på tværs af bench-pladser. Forholdsmæssig afregning ved ændringer. Omvendt betalingspligt for moms for B2B-kunder i EU med et gyldigt VIES-momsnummer.\nMed dagens midtkurser svarer 39 € til cirka 34 £ / 36 CHF / 416 NOK / 291 DKK. Opkræves i EUR ligesom alle andre linjer på din faktura; din bank eller kortudbyder står for omregningen.\nDet er inkluderet 200 timer pr. plads pr. måned i en fælles pulje på organisationsniveau, ligesom CI-minutter. En bench sætter sig på pause efter 30 minutter uden aktivitet, så en arbejdsdag bruger langt mindre end otte timer af puljen. 0,20 € pr. time ud over puljen. Samme sats, som pladsen svarer til (39 ÷ 200 = 0,195), så ujævnt forbrug koster ikke mere end at købe en plads mere. Loft på 99 € pr. plads pr. måned. Ikke et estimat – opkrævningen stopper dér. Loftet nås ved 500 timer på én plads; derefter kører dine benches uden yderligere betaling. Afregnes pr. sekund og rundes kun af én gang ved periodens udløb. Tyve opvågninger på ti sekunder koster ti sekunder hver, ikke tyve minutter. Forholdsmæssig afregning ved ændringer, ligesom en almindelig plads. 50 GB profildisk pr. bench til din kode, dine værktøjer og dine logins. Den bevares, når benchen er på pause; boot-disken bygges fra et nyt image ved hver opvågning. Samme værktøjer som dine CI-runnere, fra samme image. Dokumentation for benches. Betaling \u0026amp; fakturering Én valuta, én pris EUR på alle selvbetjente planer og alle fakturaer. Ingen lokale prisspil og ingen valutaoverraskelser ved fornyelse. Enterprise-kunder med fakturabetaling kan efter aftale faktureres i DKK.\nOmvendt betalingspligt for moms For B2B-kunder i EU med et gyldigt VIES-momsnummer. Kontrolleres ved oprettelsen.\nBetalingsmetoder Kort (Visa, Mastercard), SEPA Direct Debit, SEPA-bankoverførsel, Google Pay og Apple Pay. Behandles af Mollie (NL).\nIntet minimumsantal pladser. Offentlige eller regulerede købere, der kræver fakturering med 30 dages betalingsfrist mod en indkøbsordre: skriv til hello@frem.sh – vi håndterer de sager individuelt. Se Tillid for den fulde liste over underdatabehandlere og databehandleraftalen for de kontraktlige vilkår. Prøv gratis i 30 dage → Se produktet ","externalUrl":null,"permalink":"/da/pricing/","section":"Priser","summary":" Priser\nÉn plan. Pr. plads. I EUR. Hver plads leveres med suverænitet, Security (scanning, prioritering og rettelser), hostede runnere og fuld ret til eksport. Én pris dækker Actions-minutter, sikker signering, scanning af afhængigheder og dataeksport, når du har brug for den – alt sammen på EU-infrastruktur. ","title":"Priser","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":"Ikrafttrædelsesdato: 2026-04-25 - Version: 1.1\nSenest opdateret: 2026-04-25\nRapportér en sårbarhed # Skriv til security@frem.sh. Krypteret mail er velkommen; fingeraftrykket for vores PGP-nøgle står på Tillid-siden.\nVi kvitterer for rapporter inden for 48 timer på hverdage (se safe harbour-bestemmelsen nedenfor for den formelle forpligtelse). Kritiske problemer i fremforges egne komponenter patches om nødvendigt før upstream Forgejo; fejl i upstream koordineres med Forgejos sikkerhedsteam efter deres politik for offentliggørelse. Vores offentliggjorte frister for patching pr. alvorlighed står på Tillid-siden.\nOffentliggørelse af sårbarheder # Rapportér sårbarheder til security@frem.sh.\nEn maskinlæsbar politik for offentliggørelse findes på frem.sh/.well-known/security.txt efter RFC 9116, med omfang, kontakt, foretrukne sprog og frist for kvittering.\nSafe harbour: Sikkerhedsforskning i god tro inden for det offentliggjorte omfang er omfattet af safe harbour. fremverk anlægger ikke sag mod forskere, der følger politikken for offentliggørelse. Vi forpligter os til at kvittere for rapporter om sårbarheder inden for 48 timer på hverdage og til koordineret offentliggørelse efter en tidsplan, vi aftaler i fællesskab.\nFingeraftrykket for PGP-nøglen til security@frem.sh er offentliggjort på frem.sh/trust#security-contact.\nOmfang # frem.sh - Forgejo-UI, Git-protokol, API, pakkeregistry www.frem.sh, docs.frem.sh, status.frem.sh fremforges produktionsmiljø på T Cloud Public E-mail og transaktionsmails, der sendes fra @frem.sh Uden for omfang # Integrationer med tredjeparter, som du selv sætter op mod fremforge (rapportér til leverandøren) Fund, der kræver en forudgående godkendt, privilegeret brugersession for at blive genskabt, ud over hvad brugeren allerede har adgang til Det offentliggør vi # Sikkerhedsmeddelelser offentliggøres på Tillid-siden og sendes til sikkerhedsmailinglisten. Post mortems for enhver hændelse, der har påvirket kundedata eller tilgængelighed, offentliggøres inden for 14 dage.\nÆndringslog # Version Dato Ændring 1.0 2026-04-25 Første offentliggørelse. 1.1 2026-10-04 Omfang: produktionsmiljøet i skyen beskrives i stedet for at blive nævnt ved sit interne projektnavn. Ingen ændring i omfanget. ","externalUrl":null,"permalink":"/da/security/","section":"Sikkerhed","summary":"Ikrafttrædelsesdato: 2026-04-25 - Version: 1.1\nSenest opdateret: 2026-04-25\nRapportér en sårbarhed # Skriv til security@frem.sh. Krypteret mail er velkommen; fingeraftrykket for vores PGP-nøgle står på Tillid-siden.\n","title":"Sikkerhed","type":"security"},{"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":"Gældende fra: 2026-05-19 – Version: 1.13\nSenest opdateret: 2026-10-07\nOverblik # fremforge er EU-suveræn Git-hosting bygget på upstream Forgejo og drevet af fremverk ApS (Danmark). Alle flader kører i Den Europæiske Union. Ingen kundedata forlader EU’s jurisdiktion.\nAl behandling (repositorier, CI, revision, fakturering, godkendelse, udgående e-mail og indgående korrespondance i fælles postkasser) foregår hos selskaber uden amerikansk moderselskab. Ingen underdatabehandlere med amerikansk moderselskab på nogen vej. Se produktets DPA §11.3 for hele forpligtelsen.\nDenne side er det autoritative sted at se, hvor dine data ligger, hvem der behandler dem, hvilke certificeringer der gælder, og hvordan du får fat i os.\nDataansvarlig # fremverk ApS CVR: 39150689 Ringager 4C, 2. tv, 2605 Brøndby, Danmark E-mail: compliance@frem.sh · info@fremverk.com\nHosting og regioner # Komponent Databehandler Region Forgejo-UI, Git, API, pakkeregistry T Cloud Public (Deutsche Telekom) eu-de (Biere/Magdeburg, DE) Hjemmeside, dokumentation, status Bunny CDN Kun PoP’er i EU Udgående transaktionsmails (systemnotifikationer, fakturering, magiske links) Lettermint B.V. Zwolle, Holland Indgående korrespondance i fælles postkasser (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Heinlein Hosting GmbH (mailbox.org) Berlin, Tyskland Betalinger Mollie Holland Faktureringsmotor fremforges motor i monolitten (selvhostet af fremverk) eu-de (T Cloud Public) Bogføringsintegration (fremverks egen bogføring efter bogføringslovens §10; modtager organisationens juridiske navn, faktureringskontaktens e-mail, momsnummer, fakturalinjer og Mollie-betalings-id. Intet repository-indhold, intet indhold fra revisionsloggen, intet kortnummer (PAN).) Visma Dinero København, Danmark Underdatabehandlere # Den aktuelle liste over underdatabehandlere vedligeholdes her. Enhver ændring varsles 30 dage i forvejen på sikkerhedsmailinglisten og på denne side.\nUnderdatabehandler Formål Placering Certificeringer Deutsche Telekom AG (T Cloud Public) Central compute, lager og netværk Biere/Magdeburg, DE ISO 27001, 27017, 27018; BSI C5 Type 2; TISAX Bunny CDN d.o.o. Edge-levering, TLS-terminering, DDoS-afbødning, rate limiting (der er ikke slået nogen Web Application Firewall til – se §Beskyttelse på edge nedenfor) PoP’er i EU (hovedkontor i Slovenien) ISO 27001 (2025), SOC 2 Type II (2023) Lettermint B.V. Udgående transaktionsmails Zwolle, Holland Leverandørens certificeringer afventer dokumentation (NL – intet amerikansk moderselskab) Heinlein Hosting GmbH (mailbox.org) Hosting af fælles postkasser (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlin, Tyskland ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen (TR 03108) Mollie B.V. Betalingsbehandling Amsterdam, NL PCI-DSS Level 1 Visma Dinero ApS Bogføringsintegration (fremverks egen bogføring efter bogføringslovens §10; modtager organisationens juridiske navn, faktureringskontaktens e-mail, momsnummer, fakturalinjer og Mollie-betalings-id. Intet repository-indhold, intet indhold fra revisionsloggen, intet kortnummer (PAN).) København, DK ISO 27001 (udstedt i DK, intet amerikansk moderselskab) Bot-beskyttelse involverer ingen tredjeparts databehandler. Formularerne til oprettelse og login i produktet bruger selvhostet Altcha (MIT-licens, HMAC-signeret proof-of-work), der kører i processen inde i api-monolitten på samme T Cloud Public-cluster; intet JavaScript-widget fra tredjepart og ingen ekstern underdatabehandler. Derudover gælder kontroller på serversiden (throttling og rate limits pr. IP) på tværs af alle flader. Der er ikke slået nogen Web Application Firewall til på edge; se §Beskyttelse på edge nedenfor.\nBeskyttelse på edge – DDoS-afbødning, ingen WAF # Alle fremforges flader (frem.sh for Forgejo og Git, API’et samt www-, docs-, status- og CLI-sitet) ligger bag Bunny CDN’s edge, som står for afbødning af volumetriske DDoS-angreb og rate limiting pr. IP. Der er ikke slået nogen Web Application Firewall (WAF) til på edge for nogen af fremforges flader, og det har der ikke været siden før lanceringen. Det er et bevidst valg. Under testen før lanceringen gav OWASP Core Rule Set en høj andel falske positiver på Forgejos forespørgsler (stier i Git-protokollen, ruter til diffs i pull requests, hentning af rå blobs med hex-strenge som id’er, query-strenge i signerede URL’er) og på API’ets formulardata. En overivrig WAF, der ødelægger legitime Git-operationer eller forløb i Forgejo-UI’et, ville have været et dårligere resultat for kunderne end den resterende risiko på edge-laget. Beskyttelsen ligger i stedet i applikationen: hemmelighedsscanning i pre-receive, Altcha-proof-of-work ved oprettelse og login, rate limits pr. IP og pr. organisation i API’et, godkendelse med signerede tokens på alle webhook-modtagere og integritetshashen i revisionskæden. Denne tilgang er beskrevet i DPA bilag A.2 og tages op igen ved hver kvartalsvise driftsgennemgang.\nIsolering af hostede runnere – én engangs-ECS-VM pr. commit # De CI-jobs, du pusher til fremforge, kører på T Cloud Public Elastic Cloud Server (ECS): hvert commit eller hver pull request får sin egen virtuelle engangsmaskine, som oprettes på ny og slettes, når jobbene for det commit er færdige. Der er to uafhængige lag af isolering:\nCompute / kerne – en dedikeret VM pr. commit. Jobbene for hvert commit kører i en ECS-VM med sin egen Linux-kerne, isoleret af hypervisoren. To kunder – og to commits – deler aldrig kerne eller maskine, så teknikker til at bryde ud af en container via kernen (cgroup-escape, escape via bind-mount af /proc, eBPF, eksponering af /sys) har ingen grænse mellem organisationer at krydse: der er ingen delt kerne at bryde ud i. Isoleringsenheden er en hel VM, ikke en container – en stærkere grænse end den model med containere på delt kerne, som almindelig Kubernetes (også CCE) bruger til runner-pods. VM’en slettes, når jobbene for det commit er færdige, så intet – build-cache, klonet kode, indsatte secrets – lever videre til et andet commits jobs eller til nogen anden kunde. Inden for ét commit kan jobs dele maskinen. Efterfølgende jobs i samme workflow-kørsel (fx build og derefter deploy på samme commit) kan køre på samme VM, som slettes, når de er færdige. Det er bevidst: det er den samme gennemgåede kode i begge jobs, og en ny maskine pr. job koster omkring 40 sekunders ekstra ventetid ved hvert trin i en pipeline. Konsekvensen, der er værd at sige ligeud, er, at et build-trin, der kører kode fra tredjepartsafhængigheder, deler maskine med et senere trin i samme commit. Behandl derfor en pipeline som ét tillidsdomæne, og afgræns de loginoplysninger, et deploy-trin skal bruge, til den pipeline. Isoleringen mellem organisationer og mellem commits ovenfor påvirkes ikke af dette. Netværk – en VPC Security Group pr. VM. Hver runner-VM ligger bag sin egen VPC Security Group: ingen indgående adgang, trafik mellem VM’er (inden for subnettet) afvises, og udgående trafik er begrænset til den SSRF-beskyttede udgående runner-proxy, Forgejo-API’et og DNS. Isoleringen håndhæves på VPC- og hypervisorlaget, ikke af en NetworkPolicy i clusteret, som afhænger af, at en CNI-agent opfører sig korrekt. Sammen med den tvungne udgående proxy og dens SSRF-blokeringsliste betyder det, at lateral bevægelse fra en runner-VM til noget som helst uden for kundens egen jobkontekst afvises på både VM- og VPC-laget. Hvis T Cloud Publics isoleringsmodel for et af lagene ændres i en retning, der svækker ovenstående (fx hvis VM’er pr. job erstattes af containere på delt kerne, eller hvis grænsen med en Security Group pr. VM fjernes), opdateres denne side inden for 30 dage efter ændringen, og alle aktive kunder underrettes i henhold til DPA §14.\nArvede certificeringer # Gennem T Cloud Public:\nISO/IEC 27001 – ledelsessystem for informationssikkerhed ISO/IEC 27017 – sikkerhedskontroller specifikt for cloud ISO/IEC 27018 – beskyttelse af personoplysninger i cloud BSI C5 Type 2 – den tyske føderale basislinje for cloudsikkerhed TISAX – sikkerhedsvurdering for den tyske bilindustri GDPR-overholdende behandling i datacentre i EU fremverks egen plan for certificering # På ikrafttrædelsesdatoen har fremverk ikke selvstændige ISO 27001-, SOC 2- eller BSI C5-certificeringer. fremverks sikkerhed bygger på (i) de arvede certificeringer hos underdatabehandlerne nævnt ovenfor, (ii) de tekniske og organisatoriske foranstaltninger i sikkerhedsbilaget til databehandleraftalen og (iii) fremverks program for informationssikkerhed og sikkerhedstest, som er beskrevet i samme sikkerhedsbilag.\nfremverk har forpligtet sig til at:\nPåbegynde ISO 27001 Stage 1-audit inden for 18 måneder fra ikrafttrædelsesdatoen og opnå certificering inden for 24 måneder. Påbegynde en SOC 2 Type II-parathedsvurdering inden for 24 måneder. Kunder, der har brug for direkte certificering før disse milepæle, kan indgå aftale under Enterprise-on-Demand med milepælene for certificeringsparathed skrevet ind i ordreformularen. Se DPA §12.1.\nGennemsigtighed om myndigheders adgang # På ikrafttrædelsesdatoen har fremverk modtaget nul anmodninger fra myndigheder om adgang til Kundens personoplysninger. Hele rapporten – herunder erklæringen for den delvise periode, der dækker driften før lanceringen – er offentliggjort på frem.sh/trust/transparency/. De følgende rapporter dækker hele kalenderår og offentliggøres i 1. kvartal året efter.\nNår fremverk modtager et bindende retligt krav fra en myndighed, en domstol eller politiet, gør fremverk følgende:\nGennemgår anmodningen for retlig gyldighed, jurisdiktion og proportionalitet; Anfægter enhver anmodning, der er for vidtgående, mangler retligt grundlag eller er i strid med EU-retten (herunder GDPR art. 48 for anmodninger fra lande uden for EU/EØS); Underretter den berørte kunde inden for 24 timer efter modtagelsen, medmindre det er retligt forbudt; Giver kunden rimelig mulighed for at søge et beskyttelsespåbud eller på anden måde bestride anmodningen. Se DPA §11A.\nDSA-transparensrapport (artikel 15) # fremforge er en hostingtjeneste som defineret i forordning (EU) 2022/2065 (retsakten om digitale tjenester, DSA). Den årlige rapport efter art. 15 om antallet af anmeldelser efter notice-and-action, påbud fra myndigheder i medlemsstaterne, indholdsmoderering på eget initiativ og udfaldet af klager efter art. 20 er offentliggjort på frem.sh/trust/dsa/ – adskilt fra rapporten om myndigheders adgang ovenfor. Samme URL indeholder det halvårlige tal for gennemsnitligt antal modtagere i EU pr. måned, som art. 24, stk. 2, kræver.\nSchrems II – internationale overførsler # Der sker ingen international overførsel af Kundens personoplysninger på nogen behandlingsvej. Al behandling (repository-indhold, CI-kørsler, revisionslogs, metadata om godkendelse, faktureringsposter, data om betalingsmidler, udgående transaktionsmails og indgående korrespondance i fælles postkasser) foregår inden for EU/EØS hos selskaber uden amerikansk moderselskab. Der kræves ingen garanti efter GDPR artikel 46, ingen standardkontraktbestemmelser (SCC) og ingen vurdering af overførselsrisiko (TIA).\nDataophold på edge-PoP’er (Bunny CDN) # Alle Bunny-pullzones foran frem.sh er sat op til kun at levere fra PoP’er i EU – ingen caching i USA, Australien eller Asien. Det håndhæves i OpenTofu på hver pullzone-ressource via routing { zones = [\u0026quot;EU\u0026quot;] }. Opsætningen af pullzones ligger i kildekoden her:\nForgejo-pullzone: fremforge/forgejo/.infrastructure/main.tf – søg efter zones = [\u0026quot;EU\u0026quot;] API-pullzone: fremforge/monolith/.infrastructure/bunny.tf – samme linje Pullzones for de statiske sites (www, docs, status, cli) arver den samme routing-blok fra det fælles modul i fremverk/cloudplatform/modules/static-site/main.tf:103-112. En tofu plan mod en hvilken som helst pullzone-stak viser den aktive værdi af routing.zones, så enhver afvigelse fra [\u0026quot;EU\u0026quot;] ville vise sig som en forskel i planen. Dokumentationen vil kunne gennemses direkte i browseren, når kildekoden er hostet på den kundevendte Forgejo-instans (på https://frem.sh/fremforge/...); indtil da er dokumentationen af revisionskædens anker og integritetsverifikationen offentliggjort på docs.frem.sh/security/audit-chain/.\nOm topdomænet # frem.sh er et ccTLD for Saint Helena (.sh), som administreres af en registry-operatør registreret i Storbritannien. Det er alene et forhold på DNS-niveau. Ingen kundedata, ingen tilstand fra kontrolplanet og ingen backups forlader T Cloud Public EU-DE. Suverænitetsgarantierne (databehandlerens identitet, listen over underdatabehandlere, dataophold) er fastlagt i databehandleraftalen og påvirkes ikke af, hvor DNS hostes.\nIngen eksponering for CLOUD Act på nogen behandlingsvej. Alle Kundens personoplysninger behandles inden for EU/EØS af selskaber uden amerikansk moderselskab. Se DPA §11.3 for hele forpligtelsen.\nFodnote om kortnetværk. Mollies PCI-DSS-attesterede kæde for kortbehandling involverer Visa Europe Services Inc. (britisk filial) og Mastercard Europe SA (Belgien) – driftsselskaber i EU, hvis øverste moderselskaber (Visa Inc., Mastercard Inc.) er registreret i USA. Udsagnet »intet amerikansk moderselskab« gælder fremverks egen kæde af underdatabehandlere på driftsselskabsniveau; kortnetværkene er Mollies under-underdatabehandlere efter PCI-DSS-netværksreglerne. Kunder, der foretrækker nul eksponering for amerikanske moderselskaber på betalingsvejen, kan betale med SEPA Direct Debit (ingen kortnetværk involveret). Se underdatabehandlere – fodnote om kortnetværk.\nVerificér selv revisionskæden # Hver admin-handling, der ændrer tilstand i din organisation, registreres i en SHA-256-hashkæde pr. organisation, og kædens hoved WORM-forankres hvert andet minut i T Cloud Public OBS-lager med Object Lock (opbevaring i 3 år, fysisk umuligt at slette inden for opbevaringsperioden). Du kan gennemgå hele kæden fra ende til anden uden at skulle tage fremverks ord for det.\nMed fremforge-CLI’et:\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 Eller med rå curl mod det samme endpoint, som CLI’et kalder:\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; Et sundt svar indeholder \u0026quot;integrity_status\u0026quot;: \u0026quot;ok\u0026quot; og en worm_anchor-blok, hvor agrees_with_db_walk: true bekræfter, at kæden i databasen stemmer med hovedet, der er forankret i OBS. Et brud (hash_mismatch / prev_hash_mismatch) returnerer id’et på den række, der fejler, og årsagen – lavet til at kunne læses af en revisor. Det fulde skema, exitkoder og trusselsmodellen findes i docs.frem.sh – revisionskædens integritet.\nOpbevaring af operatørens loginoplysninger # Admin-loginoplysningerne til opstart (den domæneafgrænsede root-AK/SK til T Cloud Public, der kun bruges til første oprettelse af IAM, OBS-buckets og service-linked agencies) opbevares på operatørens laptop med fuld diskkryptering via FileVault og filrettighederne chmod 600, roteres hvert kvartal, sendes aldrig via chat eller skærmdeling og kan tilbagekaldes på under 10 minutter via OTC-konsollen. Almindelige udrulninger bruger afgrænsede deployer-nøgler pr. komponent, ikke root-loginoplysningerne.\nSikkerhedskontakt # Rapportér sårbarheder: security@frem.sh Politik for offentliggørelse: sikkerhed PGP-nøglens fingeraftryk: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (offentlig nøgle – RFC 4880 ASCII-armored, RSA-4096, udløber 2031-05-14). Brug den til krypterede sårbarhedsrapporter til security@frem.sh. Nøglen offentliggøres kun fra frem.sh/.well-known/; vi uploader den ikke til offentlige nøgleservere (så vi undgår en tillidsrod hos tredjepart). Spejl på /pgp.txt for nemheds skyld. Offentliggørelse af sårbarheder # En maskinlæsbar politik for offentliggørelse er offentliggjort på frem.sh/.well-known/security.txt i henhold til RFC 9116, herunder safe harbour for research i god tro, omfang og kanal for rapportering. Rapporter fra penetrationstest udført af tredjepart stilles, når de er bestilt, til rådighed for kunder under NDA efter skriftlig anmodning i henhold til DPA §12.1; aftaler under Enterprise-on-Demand kan fastsætte en bestemt testfrekvens i ordreformularen.\nOffentliggørelse af hændelser # Post-mortems for enhver hændelse, der påvirker kundedata eller tilgængelighed, offentliggøres på denne side inden for 14 dage i henhold til vores sikkerhedspolitik.\nSikkerhedsopdateringer # fremforge forpligter sig til følgende maksimale tid til patch af sikkerhedssårbarheder i platformen, målt fra upstreams rettede release eller offentliggørelsen af advisoriet, alt efter hvad der kommer sidst.\nAlvorlighed (CVSS) Maksimal tid til patch Kritisk (≥ 9,0) 48 timer Høj (7,0–8,9) 72 timer Middel (4,0–6,9) 7 dage Lav (\u0026lt; 4,0) Næste planlagte vedligeholdelsesvindue Ekstraordinære nødreleases uden for planen må forventes. Det ugentlige vedligeholdelsesvindue er et loft, ikke et gulv. Sikkerhedspatches udskydes aldrig for at respektere en organisations vedligeholdelsesvindue; det står i AUP’en og citeres ordret i sikkerhedsbilaget til databehandleraftalen.\nExit og dataportabilitet # Alt kan eksporteres – repositorier, issues, pull requests, Actions-logs, revisionsspor og SLSA-attesteringer – via API’et i standardformater. Der er ingen indlåsning via opbevaring og intet gebyr for eksport.\nSelvbetjent eksport, der afslører manipulation. Enhver admin i en organisation kan til enhver tid starte en fuld pakke fra admin-UI’et. Pakken leveres som én zip-fil med et SHA-256-manifest, der dækker hver fil i arkivet (manifest.json + archive.tar.gz.sha256), så kunden kan bekræfte, at indholdet ikke er manipuleret efter download. Pakken indeholder git bundle-filer for repositorierne, LFS-manifester, Actions-logs, udsnit af revisionsloggen og SLSA-attesteringer. Til sammenligning er GitHubs eksport af en organisation en række REST API-kald, som er tilgængelige for organisationens ejere, og som giver et arkiv beregnet til import i GitHub Enterprise Server (GitHub docs, læst 17. oktober 2026). fremforge leverer den på alle planer, til alle kunder, hver dag. Manifestet er signeret med vores SLSA-builder-nøgle (DSSE-envelope, manifest.json.intoto.jsonl); kunderne verificerer med den samme tillidsrod på https://www.frem.sh/.well-known/slsa-trust-root.json, som er offentliggjort til SLSA-build-attesteringer. Verifikation af manifestet kræver slet ikke Sigstore – hverken den offentlige instans eller den selvhostede Fulcio og TSA, som vi bruger som en ekstra signatur på build-attesteringer. Se docs.frem.sh/data-export for pakkens opbygning, opskrifter på verifikation og API-endpoints.\nTidsfrister og procedurer for offboarding af en organisation står i databehandleraftalen.\nCookies og sporing # fremforge sætter kun strengt nødvendige cookies på produktets flader, hvor du er logget ind, og ingen cookies overhovedet på hjemmesiden, dokumentationen, statussiden og sider uden login. Der er ikke brug for et samtykkebanner: ikke fordi vi har gemt spørgsmålet væk, men fordi vi ikke sætter cookies, der ville kræve samtykke.\nProduktets flader med login sætter fire førstepartscookies, som alle er strengt nødvendige efter artikel 5, stk. 3, i e-databeskyttelsesdirektivet:\nCookie Formål Levetid session Forgejos sessionstilstand (login; cookienavnet fra Forgejo 15+, tidligere i_like_gitea) 7 dage (vedvarende) _csrf CSRF-beskyttelse Session lang Sprogvalg, sat af brugeren I praksis permanent fremforge_operator_session (operatørkonsollen) Session i operatørkonsollen 30 min. uden aktivitet, absolut loft på 12 timer Hjemmeside, dokumentation og status (www.frem.sh, docs.frem.sh, status.frem.sh) er statiske sites bygget med Hugo uden cookies, uden analyse, uden indlejringer og uden nogen form for sporing. Det kan du selv tjekke i din browsers udviklerværktøjer.\nKald til tredjepart fra produktets UI er slået fra som standard: ingen Gravatar, ingen fødererede avatarer, ingen skrifttyper eller scripts fra et CDN og ingen analyse fra tredjepart. Avatarer gemmes lokalt; skrifttyper leveres fra samme origin som forgen.\nDet er et bevidst valg i produktet, ikke et minimum for at overholde reglerne. Den fulde oversigt over cookies og de registreredes rettigheder står i produktets privatlivspolitik.\nÆndringer af sikkerhedsforanstaltninger # Bilag A til databehandleraftalen oplister de tekniske og organisatoriske foranstaltninger, fremverk anvender, og fastslår, at væsentlige ændringer af dem meddeles her. Ændringer fra 2026-10-04 og frem står nedenfor med de nyeste øverst; tidligere ændringer findes i databehandleraftalens ændringslog. En ændring, der forringer en forpligtelse, træder i kraft 30 dage efter et varsel til alle kundens administratorer, med opsigelsesretten i §17 i vilkårene; de øvrige træder i kraft ved offentliggørelsen. Hver version linker til sin tekst.\nDPA-version Offentliggjort Gældende fra Bilag A Ændring 1.45 2026-10-07 2026-11-06 A.6 Afhængighedsproxyen er den eneste undtagelse fra, at runtime aldrig henter fra amerikanske værter: den henter fra de upstream-registries, kunden angiver (bilag B §B.9). Varsel til kunderne sendt 2026-10-07. 1.44 2026-10-07 2026-11-06 A.11 Alarmer når frem til vagthavende medarbejdere som e-mail, som de modtager som push-mail; de eksterne oppetidstjek sender SMS. Varsel til kunderne sendt 2026-10-07. 1.41 2026-10-04 2026-11-03 A.5, A.6, A.7, A.9 Præcise kontrolintervaller erstattet af minimumsfrekvenser, fx forankring af revisionskæden mindst hvert 5. minut. Varsel til kunderne sendt 2026-10-04. 1.40 2026-10-04 2026-11-03 A.9 Slettede data kan ligge i de krypterede backups af live-laget i op til 90 dage efter sletning fra det primære system. Varsel til kunderne sendt 2026-10-04. Ændringer af denne side # Ændringer versioneres i Git og annonceres på sikkerhedsmailinglisten. Datoen øverst på siden angiver den seneste indholdsmæssigt betydende ændring.\nÆndringslog # Version Dato Ændring 1.0 2026-04-25 Første offentliggørelse. 1.1 2026-04-27 Heinlein Hosting GmbH (mailbox.org, Berlin DE) tilføjet som underdatabehandler i bilag B for indgående korrespondance i fælles postkasser (migrering fra M365 til mailbox.org; fjerner den sidste databehandler under amerikansk jurisdiktion fra vejen for Kundens personoplysninger). 1.2 2026-05-06 Visma Dinero ApS (København DK) tilføjet som underdatabehandler i bilag B for fremverks bogføringsintegration (erstatter den tidligere interne regnskabskode til fakturering, moms og bogføringsloven). 1.3 2026-05-08 DPA §10.2 om varsling af ændringer af underdatabehandlere via to kanaler præciseret; Bunny Shield-opsætningen beskrevet direkte på siden (Shield Basic på Forgejo- og api-pullzones, Shield Advanced på pullzones for statiske sites); afsnit om isolering af hostede runnere med CCI Kata + Yangtse v2 tilføjet med en udtrykkelig undtagelse for CCI v2 OBT-adgang. 1.4 2026-05-14 Brevo (FR) helt udfaset som underdatabehandler for udgående transaktionsmails; Lettermint B.V. (Zwolle, NL – upstream OVHcloud SAS, FR + UpCloud Ltd, registreret i FI, datacenter i Amsterdam NL) er nu den gældende række i bilag B. Sidefoden på tillidssiden og tabellen i AI-politikken opdateret. 1.5 2026-05-19 Tabellen over datakategorier for Visma Dinero rettet, så den oplister de felter, der faktisk sendes gennem bogføringsintegrationen (organisationens juridiske navn, faktureringskontaktens e-mail, moms, fakturalinjer, Mollie-betalings-id; intet repository-indhold, intet indhold fra revisionsloggen, intet PAN); listen over fælles postkasser udvidet til alle 8 gældende adresser; grænsen for samtidighed i AUP §3.6+§4 bragt i overensstemmelse med »2 jobs/seat, max 100/org« (v1.1); 24/7-overvågning i DPA §8.5 kvalificeret med krydshenvisning til SLA §9+§10 og til EDPB’s retningslinjer 9/2022 om, hvornår fristen begynder at løbe. 1.6 2026-07-01 Afsnittet om isolering af hostede runnere omskrevet efter migreringen til engangs-VM’er på T Cloud Public ECS – én VM pr. job, isoleret af hypervisoren og slettet efter jobbet (afsluttet 2026-06-24). Erstatter den tidligere beskrivelse af »CCI Kata + Yangtse v2« og fjerner undtagelsen med ventelisten til CCI v2 OBT-adgang (ikke længere relevant). Det er en stærkere isoleringsgrænse (hel VM i stedet for container på delt kerne) med samme underdatabehandler (T Cloud Public, eu-de); svarer til DPA v1.16 bilag A.5. 1.7 2026-08-04 Isolering af hostede runnere rettet: VM-grænsen går pr. COMMIT, ikke pr. job. Afsnittet sagde »each job gets its own single-use virtual machine«, »no two jobs \u0026hellip; ever share a kernel or a machine«, og at intet »persists into any subsequent job«. Efterfølgende jobs i én workflow-kørsel på samme commit kan i virkeligheden dele maskinen, som slettes, når de er færdige – en bevidst afvejning (en ny VM pr. job koster omkring 40 s ekstra ventetid ved hvert trin i en pipeline). Isoleringen mellem organisationer og mellem commits er uændret og er stadig de egenskaber, siden forpligter sig til: to kunder og to commits deler aldrig kerne eller maskine. Konsekvensen inden for ét commit står nu udtrykkeligt i stedet for at blive bortforklaret – behandl en pipeline som ét tillidsdomæne. Behandlet som en præcisering og ikke som et varsel om forringelse: tilsagnet efter §14 i dette afsnit er betinget af, at T Cloud Publics isoleringsmodel ændres (»e.g. per-job VMs are replaced with shared-kernel containers«), og det er ikke sket – VM-grænsen og Security Group pr. VM er præcis som beskrevet. Fundet 2026-08-04 under en bevidst gennemgang af de offentliggjorte dokumenter mod det kørende system; samme gennemgang rettede DPA bilag A.5, som stadig beskrev pods i Cloud Container Instance, og som rækken for 1.6 ovenfor fejlagtigt påstod at svare til. 1.8 2026-08-05 To rettelser på denne side, begge fundet ved at holde den op mod de systemer, den beskriver. (a) Levetiden for cookien session stod som »Session«. Den er en vedvarende cookie på 7 dage (SESSION_LIFE_TIME = 604800, tilpasset vinduet på 7 dage for »Husk mig«), bevidst valgt, så brugere, der kommer ind via single sign-on, bevarer sessionen efter en genstart af browseren. Rettet samtidig med cookiepolitik 1.3 og privatlivserklæring 1.14, som har den fulde redegørelse – denne side var den TREDJE flade, der offentliggjorde det samme forkerte tal, og kontrollen, der fangede de to andre, måtte udvides for at se den. Ingen betydning for samtykke: en godkendelsescookie er strengt nødvendig efter ePrivacy art. 5, stk. 3, uanset om den gælder for sessionen eller er vedvarende. (b) Rækken for underdatabehandleren Bunny nævnte »WAF« som en rolle, mens afsnittet om Edge WAF længere nede på samme side siger, at Shield WAF ikke er slået til på Forgejo- og api-pullzones. Rækken beskriver nu, hvad Bunny faktisk gør for fremforge – edge-levering, TLS-terminering, DDoS-afbødning og rate limiting – og henviser til det afsnit. Intet ændres ved Bunnys behandlingsomfang, placering eller certificeringer; rækken beskrev en mulighed og ikke en kontrol, der var i brug. 1.9 2026-08-05 Cookietabellen: cookien lang stod med »1 year«, men er i praksis permanent (Max-Age=2147483647, svarende til Forgejos standard for LangCookieMaxAge). Rettet samtidig med cookiepolitik 1.4 og privatlivserklæring 1.15. Det er den anden levetid i tabellen, der er rettet i dag – rækken for session var forkert i 1.8 – og begge blev kun fanget ved at læse tabellen op mod den kode, der sætter cookierne. Klassificeringen som strengt nødvendig er uændret: ePrivacy betragtning 25 undtager præferencecookies, som brugeren selv sætter, uanset varighed, så der kræves ikke samtykke i nogen af tilfældene; det, der var forkert, er det tal, en læser tjekker. Begge udledes nu af koden via kontrollen cookie-lifetimes-match-the-code, som også dækker denne side. 1.10 2026-08-05 Cookietabellen: den fjerde række lød »fremforge middleware session 1.11 2026-10-04 Beskyttelse på edge rettet: der er ikke slået nogen WAF til på edge for nogen af fremforges flader. Afsnittet om edge sagde, at pullzones for de statiske sites (www, docs, status, cli) »run Shield Advanced with CRS enabled«, og afsnittet om bot-beskyttelse nævnte en »edge WAF« blandt de kontroller, der gælder på tværs af fladerne. Ingen af delene var sandt: siden 2026-05-09, før lanceringen, har alle fremforges pullzones kørt med WAF slået fra, som DPA bilag A.2 har sagt siden DPA 1.25 (2026-08-04). Afsnittet beskriver nu beskyttelsen ud fra, hvad den gør (DDoS-afbødning og rate limiting pr. IP på edge) i stedet for leverandørens abonnementsniveau, siger ligeud, at der ikke er slået nogen WAF til, og dropper den lovede fornyede canary-vurdering, som DPA bilag A.2 har erstattet med den kvartalsvise gennemgang. Versionslinjen øverst på siden stod desuden som 1.5, mens denne tabel var nået til 1.10; den viser nu den aktuelle version. 1.12 2026-10-07 Nyt afsnit: Ændringer af sikkerhedsforanstaltninger. DPA bilag A siger, at væsentlige ændringer af sikkerhedsforanstaltningerne meddeles på denne side, og siden havde ikke noget sted til dem. Afsnittet oplister ændringer af bilag A fra 2026-10-04 og frem, hvor varsler til kunderne om den slags ændringer begyndte (DPA 1.40 og 1.41), begyndende med DPA 1.44 (alarmer når frem til vagthavende medarbejdere som e-mail; varsel sendt 2026-10-07, gældende fra 2026-11-06). Tidligere ændringer står i databehandleraftalens ændringslog. 1.13 2026-10-07 Ændringer af sikkerhedsforanstaltninger: DPA 1.45 tilføjet (bilag A.6, afhængighedsproxyen; varsel sendt 2026-10-07, gældende fra 2026-11-06). DPA 1.44 linker nu til sin egen versionsside. ","externalUrl":null,"permalink":"/da/trust/","section":"Tillid","summary":"Gældende fra: 2026-05-19 – Version: 1.13\nSenest opdateret: 2026-10-07\nOverblik # fremforge er EU-suveræn Git-hosting bygget på upstream Forgejo og drevet af fremverk ApS (Danmark). Alle flader kører i Den Europæiske Union. Ingen kundedata forlader EU’s jurisdiktion.\n","title":"Tillid","type":"trust"},{"content":"Gældende fra: 2026-05-14 – Version: 1.10\nDenne side er det autoritative register over alle underdatabehandlere, som fremverk bruger til at levere tjenesten, og du kan linke direkte til den. Registret er forankret i DPA §10 og DPA bilag B, og indkøbsafdelinger kan henvise direkte til denne URL i deres dokumentation for leverandørvurdering.\nForpligtelse til varsling af ændringer # Enhver tilføjelse, udskiftning eller væsentlig ændring af listen over underdatabehandlere varsles 30 dage i forvejen via to parallelle kanaler i henhold til DPA §10.2: (a) en direkte e-mail til den registrerede faktureringskontakt for hver kundes organisation (den kontraktlige kanal – leveringen registreres i fremverks revisionslog med e-mailudbyderens besked-id pr. modtager), OG (b) et offentligt opslag på denne side og på mailinglisten for sikkerhedsmeddelelser (som en service til adresser uden for faktureringen, fx sikkerhedsteams og compliance-ansvarlige). Kunder, der gør indsigelse mod en ny underdatabehandler med dokumenterede databeskyttelsesmæssige begrundelser, kan bruge opsigelsesretten i DPA §10.2 og få forholdsmæssig refusion af forudbetalte, ubrugte gebyrer.\nVed akut tilføjelse (fx øjeblikkelig udskiftning af en underdatabehandler, der selv er kilden til en sikkerhedshændelse) offentliggør fremverk ændringen inden for 24 timer og forlænger indsigelsesfristen til 30 dage efter tilføjelsen. Se DPA §10.3.\nAbonnér på varsler om ændringer: tilmeld dig mailinglisten for sikkerhedsmeddelelser – svar og andre spørgsmål sendes til security-notices@frem.sh (aliasset videresender til compliance@frem.sh).\nAktuelle underdatabehandlere # Underdatabehandler Formål Placering Certificeringer DPA / SCC’er Deutsche Telekom AG (T Cloud Public) Central compute, lager og netværk – alle kundevendte flader Biere og Magdeburg, DE ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, TISAX T Cloud Public DPA – EU-kontrolleret, intet amerikansk moderselskab Bunny CDN d.o.o. Edge-levering, DDoS-afbødning og rate limiting for frem.sh og statiske filer, som kunderne leverer (ingen Web Application Firewall er slået til) PoP’er i EU (hovedkontor i Slovenien) ISO 27001 (2025), SOC 2 Type II (2023) Bunny DPA – EU-kontrolleret, intet amerikansk moderselskab Lettermint B.V. Udgående transaktionsmails (verifikation, rykkere, sikkerhedsmeddelelser) Zwolle, NL – upstream OVHcloud SAS (FR) + UpCloud Ltd (datacenter i Amsterdam, NL, registreret i Finland) Leverandørens certificeringer afventer dokumentation (NL – intet amerikansk moderselskab) Lettermint DPA – EU-kontrolleret, intet amerikansk moderselskab Mollie B.V. Betalingsbehandling (oprettelse af mandater, tilbagevendende træk, refusioner) Amsterdam, NL PCI-DSS Level 1 Mollie DPA – EU-kontrolleret, intet amerikansk moderselskab Heinlein Hosting GmbH (mailbox.org) Hosting af fælles postkasser (support@, abuse@, security@, compliance@, hello@, ops@, enterprise@, info@fremverk.com) Berlin, Tyskland ISO 27001, BSI C5, BSI IT-Sicherheitskennzeichen (TR 03108) Heinlein Hosting DPA – EU-kontrolleret, intet amerikansk moderselskab Visma Dinero ApS Udstedelse af fakturabilag og lovpligtig opbevaring i 5 år efter bogføringslovens §10 – modtager organisationens juridiske navn, faktureringskontaktens e-mail, momsnummer, fakturalinjer og Mollie-betalings-id. Intet repository-indhold, intet indhold fra revisionsloggen, intet kortnummer (PAN). København, DK ISO 27001 (udstedt i DK, intet amerikansk moderselskab) Visma Dinero DPA – EU-kontrolleret, intet amerikansk moderselskab Oplyst af hensyn til gennemsigtighed – ikke underdatabehandlere efter artikel 28 # Følgende parter berører platformen, men behandler ikke Kundens personoplysninger på fremverks vegne og er derfor ikke underdatabehandlere efter GDPR artikel 28. De står her, så det register, kunderne ser, er fuldstændigt:\nPart Rolle Placering Hvorfor ikke en underdatabehandler Actalis S.p.A. (Aruba Group) Certifikatudsteder for origin-TLS til *-origin.frem.sh (eIDAS QTSP) Italien, EU Certifikatudstederen modtager kun FQDN’er – aldrig personoplysninger – under udstedelsen via ACME-DNS-01. Undtaget fra bilag B i henhold til DPA §A.4. D-TRUST GmbH (Tyskland, eIDAS QTSP) er bibeholdt som navngiven, betalt reserve. Europa-Kommissionens VIES-tjeneste Validering af momsnumre ved oprettelse (betingelse for omvendt betalingspligt) EU-institutionerne Ikke-kommercielt opslag i en offentlig tjeneste; kun momsnummeret (et virksomhedsregistreringsnummer) sendes. Oplyst i privatlivserklæringen §3.3. Simply.com A/S Registrar + DNS for brand-domænerne fremforge.{com,eu,dk}, der omdirigerer (alle 301 → www.frem.sh) Danmark Ingen af Kundens personoplysninger passerer Simply.com – kun DNS-opslag for omdirigeringsmålene. Kundevendte flader bruger BunnyDNS (Bunny CDN d.o.o., Slovenien – samme underdatabehandler som CDN-, WAF- og edge-laget, allerede oplyst i tabellen over underdatabehandlere i bilag B ovenfor). Det bruger vi ikke # Ingen CDN- eller edge-udbyder med amerikansk moderselskab er på vejen for forespørgsler til kundevendte endpoints. Ingen databehandler til analyse eller telemetri. Fase 1 har ingen produktanalyse overhovedet – i overensstemmelse med det, cookiepolitikken og privatlivserklæringen allerede siger (ingen analyse, intet samtykkebanner). Ingen Google Analytics, ingen Mixpanel, ingen Segment, ingen Plausible. Selvhostet Plausible (T Cloud Public eu-de) er på roadmappen efter lanceringen; hvis og når det tages i brug, kommer det til at stå i ændringsloggen nedenfor og som førsteparts-databehandler på niveau 1 i bilag B (data bliver i fremverks T Cloud Public-konto; intet sendes ud til tredjepart). Ingen AI- eller LLM-udbyder bliver kaldt med kundeindhold. Funktioner med agentmandater (jf. DPA §11A) handler efter kundens instruks på kørselstidspunktet og sender ikke indhold gennem en tredjeparts model; fremverk gemmer ikke kundeindhold i noget modelkorpus. Underdatabehandlerne er kontraktligt bundet af samme forbud – se Forbud mod AI-træning hos underdatabehandlere nedenfor. Ingen amerikansk betalingsudbyder. Mollie (NL) håndterer alle betalinger. Ingen leverandør af bot-beskyttelseswidgets. Oprettelse i Forgejo bruger selvhostet Altcha (MIT-licens, HMAC-signeret PoW), der kører i processen inde i api-monolitten på samme T Cloud Public-cluster; ingen Cloudflare Turnstile, ingen hCaptcha, ingen Google reCAPTCHA. CLOUD Act # Alle enheder ovenfor er EU-kontrollerede og har intet amerikansk moderselskab. Ingen eksponering for CLOUD Act på nogen behandlingsvej. Der kræves ingen Schrems II-vurdering af overførselsrisiko (TIA), fordi ingen af Kundens personoplysninger overføres uden for EU/EØS.\nHele forpligtelsen står i DPA §11.3 og i Tillid – afsnittet om Schrems II.\nForbud mod AI-træning hos underdatabehandlere # Forpligtelsen om »ingen AI-træning på kundedata« i DPA §6A binder alle led i kæden af underdatabehandlere. De offentlige forpligtelser fra hver underdatabehandler, som understøtter den, er listet nedenfor til krydsreference. Hvor en underdatabehandler tilbyder at tilvælge modeltræning, har fremverk ikke gjort det.\nUnderdatabehandler Offentlig forpligtelse, vi baserer os på Deutsche Telekom AG (T Cloud Public / T Cloud Public) T Cloud Publics tjenestebeskrivelse og DPA – IaaS-laget; platformen tilgår ikke kundernes indhold. T Cloud Publics AI-principper forpligter til dataminimering og formålsbegrænsning i AI udviklet af Telekom, og IaaS-databehandleraftalen forbyder brug af kundernes data til andet end levering af tjenesten. Bunny CDN d.o.o. Bunnys DPA – Bunny behandler kun trafik til caching, TLS-terminering, DDoS-afbødning og rate limiting; der gives ingen ret til modeltræning. Bunnys oplysning om AI-politik bekræfter, at ingen AI-model trænes på indholdet af kundernes trafik. Lettermint B.V. Lettermints DPA + privatlivspolitik – omfatter transaktionsmails; relæ kun for udgående post. Kundernes modtagerlister bruges ikke til modeltræning på tværs af konti, og der er ikke slået nogen tilvalg af AI eller modeltræning til. Mollie B.V. Mollies privatlivserklæring og omfanget efter PSD2 / PCI-DSS – kun transaktionsbehandling; Mollie træner ikke AI-modeller på forhandlerens transaktionsmetadata. Heinlein Hosting GmbH (mailbox.org) mailbox.orgs privatlivserklæring – en udtrykkelig holdning om »ingen AI-træning, ingen profilering«; mailbox.org skriver gang på gang i sin markedsføring »Wir trainieren keine KI mit Ihren Daten« (»vi træner ikke AI på dine data«). Visma Dinero ApS Visma-koncernens politik for privatliv og AI – omfatter bogføringsintegrationen; ingen træning på Kundens personoplysninger, der passerer integrationen. fremverks bogføringsvej modtager organisationens juridiske navn, faktureringskontaktens e-mail, momsnummer, fakturalinjer og Mollie-betalings-id (personoplysninger om organisationens administrator); intet repository-indhold, intet indhold fra revisionsloggen, intet kortnummer (PAN). Actalis S.p.A. eIDAS QTSP – modtager kun domænenavne under udstedelsen via ACME-DNS-01; en certifikatudsteders rolle udelukker afledt brug af indhold. Europa-Kommissionens VIES-tjeneste Opslag i en offentlig tjeneste; uden for AI-træning (ingen kommerciel ML trænet på trafik til momsregistret). Simply.com A/S Kun registrar / DNS for omdirigeringsdomæner; ingen vej for Kundens personoplysninger. Hvis en underdatabehandler ændrer holdning til AI-træning, er fremverk efter DPA §6 (underdatabehandlere) forpligtet til at varsle kunderne på forhånd og give dem ret til at gøre indsigelse, før den nye behandling begynder. Ændringsloggen nederst på siden registrerer hver sådan overgang.\nFodnote om kortnetværk # Kortbetalinger gennem Mollie føres teknisk via PCI-DSS-attesterede kortnetværk som under-underdatabehandlere: Visa Europe Services Inc. (britisk filial) og Mastercard Europe SA (Belgien). Begge er driftsselskaber i EU, men deres øverste moderselskaber (Visa Inc., Mastercard Inc.) er registreret i USA. fremverk har ingen direkte kontrakt med disse netværk – de er Mollies under-underdatabehandlere efter PCI-DSS-netværksreglerne. Udsagnet »intet amerikansk moderselskab« ovenfor gælder fremverks egen kæde af underdatabehandlere på driftsselskabsniveau. Kunder, der ønsker nul eksponering for amerikanske moderselskaber på betalingsvejen, kan betale med SEPA Direct Debit (Mollies SEPA-vej involverer ingen kortnetværk som under-underdatabehandler). Se DPA §11.3 for den fulde ramme.\nAlternativer på kundens anmodning # Standardsættet af underdatabehandlere har allerede nul eksponering for amerikanske moderselskaber. Under Enterprise-on-Demand kan kunder desuden anmode om:\nRevision af eventuelle ønsker om fastlåsning til bestemte regioner i T Cloud Public (eu-de er standard; andre EU-regioner kan fås efter anmodning, så længe funktionerne er de samme). Strengere forpligtelser om dataophold i en bestemt region end standarden (fx kontraktlig fastlåsning til én enkelt availability zone i eu-de). Kontakt enterprise@frem.sh for at afklare omfanget.\nTidligere ændringer # Dette afsnit viser ændringshistorikken for listen over underdatabehandlere med de nyeste øverst. Listen ovenfor viser altid den aktuelle tilstand.\nDato Ændring Varsel offentliggjort 2026-10-04 Bunny CDN’s formål nævner ikke længere WAF: der har ikke været slået en Web Application Firewall til på edge for nogen af fremforges flader siden 2026-05-09 (DPA bilag A.2). Ingen ændring af underdatabehandler, behandlingsformål eller datakategori; beskrivelsen passer nu med det, Bunny gør. Ikke påkrævet (rettelse, ingen ændring i behandlingen) 2026-05-14 Udgående transaktionsmails flyttet fra Sendinblue SAS (Brevo, FR) til Lettermint B.V. (Zwolle, NL). Brevo udfaset 2026-05-14. Vejen for udgående mail forbliver kun i EU uden databehandlere med amerikansk moderselskab; rækken om forbud mod AI-træning er omskrevet tilsvarende. Svarer til DPA v1.9. n/a (ingen kunder med underskrevet aftale; før lancering) 2026-05-08 Gennemsigtighedsrunde 7: Actalis S.p.A. (certifikatudsteder for origin-TLS, IT, eIDAS QTSP), EU’s VIES-tjeneste (momsvalidering) og Simply.com A/S (DK, DNS for brand-omdirigering) tilføjet i et nyt afsnit »Oplyst af hensyn til gennemsigtighed – ikke underdatabehandlere efter artikel 28«. Ingen af dem modtager Kundens personoplysninger; undtaget fra bilag B i henhold til DPA §A.4. n/a (ingen kunder med underskrevet aftale; før lancering) 2026-05-06 Visma Dinero ApS (Danmark) tilføjet i bilag B som underdatabehandler på faktureringsvejen. Omfang af Kundens personoplysninger: organisationens juridiske navn, faktureringskontakt, momsnummer, fakturalinjer, Mollie-betalings-id. Lovpligtig opbevaring i 5 år efter bogføringslovens §10. Svarer til DPA v1.4 (revideret i v1.5 – den tidligere formulering »ingen vej for Kundens personoplysninger« var forkert). n/a (ingen kunder med underskrevet aftale; før lancering) 2026-04-27 Hosting af indgående fælles postkasser flyttet fra Microsoft Ireland Operations Ltd. til Heinlein Hosting GmbH (mailbox.org), Berlin, Tyskland – fjerner den tidligere underdatabehandler med amerikansk moderselskab på vejen for indgående post n/a (ingen kunder med underskrevet aftale; før lancering) 2026-04-25 Første register Ikrafttrædelsesdato Kontakt # Spørgsmål om underdatabehandlere:\nPrivatliv / databehandleraftalens omfang: compliance@frem.sh Indkøb / leverandørvurdering: enterprise@frem.sh Tilmelding til sikkerhedsmailinglisten: lists.frem.sh/subscription/form (alias: security-notices@frem.sh – videresender til compliance@) Se også: Tillid · Privatlivserklæring\n","externalUrl":null,"permalink":"/da/trust/subprocessors/","section":"Tillid","summary":"Gældende fra: 2026-05-14 – Version: 1.10\nDenne side er det autoritative register over alle underdatabehandlere, som fremverk bruger til at levere tjenesten, og du kan linke direkte til den. Registret er forankret i DPA §10 og DPA bilag B, og indkøbsafdelinger kan henvise direkte til denne URL i deres dokumentation for leverandørvurdering.\n","title":"Underdatabehandlere","type":"trust"},{"content":"","externalUrl":null,"permalink":"/da/vs/","section":"Vs","summary":"","title":"Vs","type":"vs"}]