Skip to main content
  1. Legal documents/

fremverk Record of Processing Activities (ROPA)

On this page

title: Records of Processing Activities (Article 30 GDPR) date: 2026-09-06 version: “1.8” status: Active. Reviewed quarterly; updated on every sub-processor change, every new processing activity, and every significant change to legal basis or retention. controller: fremverk ApS, CVR 39150689, Ringager 4C, 2. tv, 2605 Brøndby, Denmark contact: compliance@frem.sh dpo: not appointed (fremverk does not meet the Art. 37(1) mandatory-DPO criteria — not a public authority, core activities are Git hosting + CI infrastructure not large-scale systematic monitoring of data subjects, and Customer Personal Data does not include Art. 9 special-category or Art. 10 criminal-conviction data on a large scale). Assessment dated 2026-05-10; re-evaluated and CONFIRMED UNCHANGED 2026-08-16 against three material processing changes — see §3A. Cadence remains annual with the next §A.9 DR-drill review window (or sooner on material change to processing scope), so the next scheduled re-evaluation is 2027-05-10. compliance@frem.sh handles DSARs and supervisory-authority correspondence. #

Records of Processing Activities #

Last updated: 2026-09-06

Version: 1.8

This document is the controller’s Article 30 record for the fremforge product. It reflects the current state of processing as of the date above and is reviewed at every sub-processor change, every privacy-impacting feature release, and at minimum quarterly.

A separate ROPA exists for fremverk corporate operations (employee data, customer-relationship-management, accounting), which is out of scope here.

1. 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).

2.1 Customer signup + tenant provisioning #

FieldValue
PurposeCreate the customer’s fremforge organisation; verify the customer’s email; route them through the right billing country / VAT-treatment branch.
Lawful basisArticle 6(1)(b) — performance of contract (the Service the customer is signing up for).
Categories of data subjectsProspective customer’s signing-up individual (sole-trader operator OR an authorised employee of a customer entity).
Categories of personal dataEmail; 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 transfersNone. T Cloud Public + Lettermint are EU. VIES is the European Commission.
RetentionFour 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.
TOMsTLS-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 #

FieldValue
PurposeAuthenticate users to fremforge; issue and validate session tokens; maintain audit trail of authentication events.
Lawful basisArticle 6(1)(b) — performance of contract; for security-monitoring traces, Article 6(1)(f) — legitimate interest in fraud + abuse prevention.
Categories of data subjectsAny authenticated fremforge user (org member, admin, or break-glass operator).
Categories of personal dataOIDC/SAML subject identifier; email (if the IdP propagates it); session ID; access-token hash (stored hashed, never plaintext); IP; user agent; timestamp.
Recipients (internal)Operations on-call (audit log review during incident response).
Recipients (sub-processors)T Cloud Public RDS (session-row store); T Cloud Public DCS Redis (ephemeral session cache, see DPA Annex A.4 amendment). Customer-side: the Customer’s own OIDC/SAML IdP (Microsoft Entra, Okta, Google Workspace, Authentik, etc.) — the Customer’s processor, not fremverk’s sub-processor.
International transfersDetermined by the Customer’s IdP location. fremverk-side processing is EU-only.
RetentionActive 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).
TOMsTLS-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 #

FieldValue
PurposeHost the customer’s source code, run Git operations (clone, push, pull), display issues + PRs, deliver webhooks.
Lawful basisArticle 6(1)(b) — performance of contract.
Categories of data subjectsCustomer’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 dataCommit 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’s metadata DB — issues, PRs, users, hooks).
International transfersNone. T Cloud Public eu-de only.
RetentionActive repository content: lifetime of the tenancy. After cancellation: 90 days post-cancellation hard-delete window (DPA §9). After repository deletion within an active tenancy: 14 days backup-retention grace before purge from snapshot tier (the same 14-day window the live-tier backup lifecycle in DPA §9 + Annex A.9 enforces — audit P2-27 fixed the broken cross-reference; the previous “DPA Annex A.10” 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’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’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’s own platform SBOMs are retained for the product support period per EU CRA (Reg 2024/2847) Annex I.
TOMsKMS-encrypted-at-rest (SFS Turbo + OBS); per-tenant access control (Forgejo orgs); webhook-egress filtered through outbound proxy when implemented (currently /32-allowlisted via auto-refresh CronJob, see fremverk’s internal egress-refresh manifest).

2.4 Billing + payment processing #

FieldValue
PurposeCharge subscription Fees; issue invoices; reconcile payment failures; send payment-receipt emails.
Lawful basisArticle 6(1)(b) — performance of contract; Article 6(1)(c) — legal obligation (Bogføringsloven §10 retention).
Categories of data subjectsAuthorised billing contact for the customer organisation (typically the operator who signed up).
Categories of personal dataBilling 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 transfersNone at fremverk’s scope. Mollie’s card-network sub-processors (Visa Europe Services Inc. UK branch; Mastercard Europe SA Belgium) are PCI-DSS-attested; per DPA Annex B note.
RetentionActive 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’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.
TOMsTLS-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 #

FieldValue
PurposeDiagnose product errors; trace incidents; meet audit obligations under DPA Annex A.7.
Lawful basisArticle 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 subjectsAny user whose request transits the fremforge stack (request-path traces include user identifier + IP).
Categories of personal dataRequest 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 transfersNone.
RetentionOperational logs (fremforge-api-prd-api, which carries the HTTP access log — request path, user-agent, IP — and fremforge-api-prd-audit-operational): 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 monolith .infrastructure/main.tf on 2026-09-06 so the hot tier matches the disclosed period. The three groups this row named until then (api/forgejo/jobs) were fremforge-prd-lts-*, deleted in platform-foundation#1078 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 (platform-foundation#1084) 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’s own diagnostic record only; the audit trail a Customer or regulator would ask for lives in audit_events and is archived in full by audit-events-worm-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; the CHECK constraint at migration 0146 enforces BETWEEN 1 AND 730). After the per-tenant cutoff, the audit-payload-reaper redacts actor and fields_json to null while the SHA-256 chain hashes are retained for the full 3-year window. Hash-chain anchor objects under the WORM bucket prefix chain-anchors/<stream>/: 3 years (locked by the same compliance-mode WORM policy). The retention split is the primary mitigation in DPIA §5.1 and the DPIA’s Art-6(1)(f) balancing has been re-run with the 730-day worst-case (DPIA v1.2, 2026-05-25).
Processing flowsFour in-cluster CronJobs touch this data:
(a) lts-quota-guard (every 6h) — lists LTS streams via the LTS API, computes per-stream byte-rate over a 6-hour window, alerts SMN if the extrapolated daily volume crosses the 5 GiB/day threshold. No content read; only metadata (stream id, byte size of API response).
(b) audit-chain-anchor-verifier (hourly) — walks each tenant’s anchor objects in timestamp order, checks that every anchor’s prev_anchor_head matches the preceding anchor’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-events-worm-export (daily, 02:40 UTC) — writes the audit-event rows themselves to s3://fremforge-prd-lts-worm-archive/audit-events/<YYYY>/<MM>/<DD>.jsonl.gz with a .sha256 sidecar, 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-anchor (every 2min) — per-tenant integrity flow committed in DPA Annex A.7. For each tenant with new audit_events rows since the last anchor, the job walks the rows in primary-key order, computes a running SHA256(prev_row_hash || canonical_row_bytes) chain hash, and writes a small anchor object {tenant_id, chain_hash, event_count, ts} to s3://fremforge-prd-lts-worm-archive/audit-chain-anchors/<tenant>/<ts>.json. Event payloads themselves are NOT copied — only the hash + count + identifier triple. This is the cadence commitment surfaced in DPA Annex A.7 and anchors the per-tenant audit_events row history so tenants can independently verify their own slice of the audit chain via the self-service export bundle (docs.frem.sh/data-export). Pseudonymous tenant identifiers + chain hashes only — no direct Customer Personal Data crosses the WORM-bucket boundary on this path.
Retired flow, recorded for completeness. Until 2026-08-02 a per-stream pair (lts-archive-and-anchor, every 5min, and lts-anchor-verifier, hourly) anchored four LTS log streams under s3://fremforge-prd-lts-worm-archive/chain-anchors/<stream>/. 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 audit_events in Postgres and is now archived in full by (c). The 104,510 objects already written under chain-anchors/ 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.
TOMsKMS-encrypted-at-rest on both LTS hot and WORM archive (DEW CMK, annual rotation enabled); WORM compliance-mode lock on the OBS bucket prevents tamper-with-or-delete inside the 3-year retention window; least-privilege IAM scope on the read paths. The fremforge-lts-quota-guard IAM user is bound to five project-scoped roles: lts_full (read LTS streams + content query), smn_adm (publish to SMN oncall topics — note the documented Tenant Guest dependency), tenant_guest (read-only across services, the Tenant Guest dependency role required by smn_adm), obs_operate (PUT/GET on the WORM bucket’s chain-anchors/* prefix only — bucket policy restricts), kms_admin (datakey ops on the WORM CMK so KMS-encrypted PUTs succeed). The credential is provisioned by the platform-foundation IAM stack and lands as the lts-quota-guard-creds Secret in the fremforge-prd namespace. It is a shared platform credential rather than a per-job one: as of 2026-08-05 roughly 35 in-cluster CronJobs mount it, the large majority using only its smn_adm scope to publish alerts. The jobs that use it to reach the WORM bucket on the paths described above are audit-chain-anchor, audit-chain-anchor-verifier, audit-events-worm-export and worm-readback-drill (the last a weekly restore rehearsal that reads one archived object back). This record previously named only the two retired per-stream jobs plus bunny-edge-refresher and asserted that “no other automated read-paths exist”, 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 #

FieldValue
PurposeHandle support tickets, security disclosures, abuse reports.
Lawful basisArticle 6(1)(b) — performance of contract; Article 6(1)(f) — legitimate interest in security/abuse handling.
Categories of data subjectsAnyone 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 dataEmail 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 transfersNone.
RetentionSupport 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).
TOMsTLS-in-transit; mailbox.org server-side encryption; access via SSO + 2FA for operators.

2.7 Marketing + waitlist #

FieldValue
PurposePrivate-beta signup capture; product-update communication.
Lawful basisArticle 6(1)(a) — consent (for marketing emails); Article 6(1)(f) — legitimate interest (transactional product-update emails to existing customers).
Categories of data subjectsPrivate-beta signup requesters; existing customers’ billing contacts.
Categories of personal dataEmail; 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 transfersNone.
RetentionEmail 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.
TOMsLettermint TLS-only; APIG per-IP throttle; per-IP rate limit on submit; Bunny Shield Basic DDoS protection at the edge (Block mode). The edge WAF available in Shield Advanced is deliberately not enabled — 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 read “Bunny Shield Advanced WAF”, which was never the posture on any fremforge surface during the paying-Customer period.

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 G1Actalis 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 “annually … or sooner on material change to processing scope.” 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.

Processing added since 2026-05-10

ChangeEffectiveWhat it adds
Customer-configured AI vendors (BYOK)DPA v1.13 Annex B §B.8, 2026-05-24Repository content and PR diffs transit fremverk’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 programme2026-08Partner company and signatory data, cross-tenant by design; electronic execution of fremverk’s own counterparty agreements via Addo Sign, using national eID (MitID Erhverv, FrejaOrg, Norwegian BankID, FTN).
fremai2026-08Separate product on the shared cluster, separate namespace and database.

Assessment against Art. 37(1)

  • (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’s instruction and under the Customer’s own vendor contract; it does not monitor data subjects’ 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.

The 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.

Determined by the Compliance Officer (shj@fremverk.com) on 2026-08-16, having considered each of the three processing changes above against all three Art. 37(1) limbs.

Next 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.

4. Change-log #

VersionDateChange
1.02026-05-03Initial publication. Replaces the placeholder reference in Privacy Notice §2 and fremverk’s internal product plan.
1.12026-05-04Audit 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.22026-05-04Origin-TLS workstream activated. §3 “Encryption-in-transit” 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.32026-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’s keep_non_release_days (default: not retained), all purged on tenancy termination; fremverk’s own platform SBOMs kept for the CRA Annex I support period. Reconciles the previously-undocumented (and over-broad “retain forever”) SBOM storage.
1.42026-08-04§2 technical-measures row for the signup activity corrected: it read “Bunny Shield Advanced WAF”. 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.52026-08-05Editorial: 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: "1.5" plus a **Version:** line under the heading, matching the other six published documents. Deliberately NOT added to the monolith’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.62026-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’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 “no other automated read-paths exist”, where ~35 CronJobs in fact mount that credential. Editorial accuracy correction to a register, not a change to processing; effective on publication.
1.72026-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.82026-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’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.