On this page

title: Records of Processing Activities (Article 30 GDPR) date: 2026-10-10 version: “1.13” 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-10-10

Version: 1.13

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

Field	Value
Purpose	Create the customer’s fremforge organisation; verify the customer’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’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’s own OIDC IdP (Microsoft Entra, Okta, Google Workspace, Authentik, etc.) — the Customer’s processor, not fremverk’s sub-processor.
International transfers	Determined by the Customer’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’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’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’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 “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.
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’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.
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’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’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’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’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-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 “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 #

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’ 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’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’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 “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

Change	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’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’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)

(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 fremverk’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.

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 #

Version	Date	Change
1.0	2026-05-03	Initial publication. Replaces the placeholder reference in Privacy Notice §2 and fremverk’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 “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.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’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.4	2026-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.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: "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.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’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.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’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’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 “14 days”, 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 “OIDC/SAML” 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.