fremverk Controller-side Incident Response

title: Controller-side incident response runbook audience: fremverk on-call + compliance officer (privacy contact per ROPA + privacy-product.md §2; no Art. 37 DPO designation) classification: internal — share under NDA only version: 1.0 date: 2026-05-06 owner: shj@fremverk.com (CTO + Compliance Officer / DPO-equivalent — fremverk is not required to designate a DPO under GDPR Art. 37; see privacy-product.md §2) related:

• dpa.md §8.5
• ropa.md
• sla.md §6 (operational SLA)
• operations.md (incident-response general flow) status: in force

Purpose #

This runbook governs fremverk’s response to Personal Data Breaches affecting fremverk-as-Controller processing activities — that is, breaches where fremverk owes the GDPR Art. 33 (72-hour Datatilsynet notification) and Art. 34 (data-subject communication) duties directly, not as Customer-as-Controller’s processor.

For Customer-Controller breaches (a sub-processor compromise affecting Customer Personal Data, an exposure caused by Customer-tenant misconfiguration, etc.), the processor-side flow in DPA §§8.1–8.2 applies and the customer-notification template at the bottom of this runbook is used. This document covers the controller-side flow only.

This runbook is referenced from DPA §8.5 as fremverk’s commitment to a 72-hour Datatilsynet notification path for fremverk-as-Controller incidents. The single intake point is compliance@frem.sh (mailbox.org-hosted, on-call rota’d into the same Kuma alert channel as oncall@frem.sh). The legacy alias compliance@fremverk.com forwards to the same mailbox for inbound continuity.

When this runbook fires (the four breach classes) #

This runbook fires when ANY of the following four conditions is detected by automation, reported by a fremverk staff member, or reported by a third party:

Class A — Staff IdP compromise #

idp.fremverk.com (Authentik on T Cloud — see fremverk/cloudplatform/platform-identity/) has issued an authentication factor or session that was not initiated by the legitimate account holder. Indicators:

• Authentik audit log shows a successful login from an IP / device-fingerprint not historically associated with the user, especially without the corresponding MFA factor consent in the last 60s.
• WebAuthn enrolment for a new device by an account that did not request enrolment (matched against ServiceDesk ticket history).
• Recovery flow completed for an account whose primary email mailbox.org show no reset request.
• Authentik admin role granted to a non-admin user.

Fremverk-as-Controller exposure: staff personal data, internal-systems administrative actions performed under the compromised identity, and any downstream pivot into Controller-managed data the staff identity has access to (HR records, finance records, internal audit log).

Class B — WORM audit-chain tampering #

The cross-tenant audit-chain-anchors OBS bucket (Object Lock COMPLIANCE-mode, see fremforge/platform-foundation/cce/audit-chain-alarms.tf) shows a checkpoint that contradicts the in-DB chain walk for the same (tenant_id, count), AND the in-DB chain walk for that tenant is internally consistent. Per api-v1.ts /audit/integrity, this is the anchor_disagrees_with_db_walk_investigate mismatch reason returned with anchor_age_seconds < 360.

Fremverk-as-Controller exposure: the integrity attestation fremverk provides to its own staff (and indirectly to Customers) for the internal audit log is no longer trustworthy; an actor with audit_events write access has rewritten history. This is a fremverk-internal-audit-log breach in the controller sense — separate from any Customer Personal Data accessed via the same vector (which is processor-side and follows DPA §8.1).

Class C — Operator-console session hijack #

A request to the operator console (/_admin/* on frem.sh — served behind the /_app/ Bunny strip-prefix mount, i.e. frem.sh/_app/_admin/*) was authenticated under a session cookie not minted by the legitimate operator’s OIDC flow. Indicators:

• IP-asn change mid-session beyond what the operator-session idle-timeout allows.
• Operator-action audit event without a corresponding OIDC-callback event in the same session window.
• Operator action performed during a window where the legitimate operator’s calendar shows them in transit / offline (cross-checked manually after the fact).

Fremverk-as-Controller exposure: operator actions can affect Customer-tenant state but the operator-action log is fremverk-internal data — see ROPA §2.5. The Customer-side impact is processor-side and follows DPA §8.1; the operator-log integrity impact is controller-side and follows this runbook.

Class D — Annex B sub-processor compromise where fremverk is the affected Controller #

A confirmed security incident at one of the sub-processors named in DPA Annex B where fremverk is the affected Controller, not the Customer. Worked example: a compromise at mailbox.org that exposes fremverk’s internal compliance@, enterprise@, or info@ mailbox contents containing fremverk staff or counterparty personal data — distinct from a customer-mailbox compromise (which is covered by the customer’s own DPA with mailbox.org or our processor-side flow).

Fremverk-as-Controller exposure: the controllership-mapping is in ROPA §2. When in doubt, the breach falls into Class D if the Personal Data exposed at the sub-processor is data fremverk processes for fremverk-internal purposes (HR, finance, marketing-to-prospect, internal compliance) rather than data fremverk processes on behalf of a Customer.

The 72-hour clock #

Per GDPR Art. 33(1), the notification clock starts when fremverk becomes aware of the breach — interpreted by Datatilsynet (and by EDPB Guidelines 9/2022) as the moment fremverk has a reasonable degree of certainty that a security incident has occurred AND that personal data is affected.

In practice for this runbook:

• T+0h is when either (a) automation pages the on-call channel with one of the four-class detection signals, or (b) the compliance officer logs a determination that an internal report or external tip-off rises to “reasonable degree of certainty.” Whichever is earlier.
• T+24h is the internal triage gate: by this point the affected data, scope, and root cause must be characterised at first-pass. If they are not, the gap itself is documented in the Datatilsynet notification per Art. 33(4) (information may be provided in phases).
• T+72h is the regulatory deadline: notification submitted to Datatilsynet via datatilsynet.dk anmeld sikkerhedsbrud, in Danish. (URL verified 2026-05-12; the earlier path /borger/digital-selvbetjening/anmeld-brud-paa-persondatasikkerheden now returns HTTP 404.)

If the 72-hour deadline cannot be met for substantive (not procedural) reasons, the notification is filed late with the reasons-for-delay statement Datatilsynet’s form requires — a late-but-substantive report is preferable to an on-time empty report. Not notifying is never the right answer.

Triage workflow #

Roles:

• On-call (rotating, see Kuma roster): receives the page, makes the initial four-class call, opens the incident channel.
• Incident commander (IC): shj@fremverk.com by default, hand-off documented in the channel topic. IC owns the timeline, the notification text, and the post-incident review.
• Compliance officer (privacy contact): shj@fremverk.com. fremverk has not designated a GDPR Art. 37 DPO (see privacy-product.md §2 + ropa.md); the Compliance Officer is the DPO-equivalent role for breach-notification and supervisory-authority correspondence. Dual-role with IC until headcount allows separation; conflict-managed by recusal where the IC role would be substantively biased — escalates to fremverk legal counsel listed in counsel.md.
• Comms: shj@fremverk.com (single-person company posture; expanded when org grows).

Step 0 — Page receipt (T+0) #

On-call confirms the page in the #incident-{YYYY-MM-DD} channel within the SLA P1 acknowledgement window. Posts:

[INCIDENT OPEN] Class {A|B|C|D} — {one-line summary}
T+0: {timestamp UTC}
On-call: {name}
IC handing-off-to (if not on-call): {name}
Awareness basis: {automation alert | staff report | external tip-off}
Pinging compliance officer: {name}@fremverk.com

Step 1 — Containment (T+0 to T+4h) #

Goal: stop the breach from continuing while preserving forensic state. Class-specific:

• Class A: Disable the suspected Authentik account (/admin/users/<id> → Disable, do NOT delete — keep for forensics). Force-revoke all active sessions for that user across Forgejo + monolith api + Authentik. Rotate the user’s recovery codes. If admin role compromised: rotate Authentik admin recovery secret, revoke all admin sessions, issue new recovery codes through out-of-band channel (call, not email).
• Class B: Freeze the audit-chain-anchor CronJob (scale to 0 replicas: kubectl -n fremforge-prd scale cronjob/audit-chain-anchor --replicas=0 — but the CronJob doesn’t have replicas attribute; correct command is to suspend: kubectl -n fremforge-prd patch cronjob/audit-chain-anchor -p '{"spec":{"suspend":true}}'). Snapshot the OBS bucket via boto3 list_object_versions to a forensic prefix. Snapshot audit_events for the affected tenant via pg_dump -t audit_events --where="tenant_id='...'" to a forensic OBS bucket with Object Lock 5y.
• Class C: Force-revoke the suspected operator session (delete the cookie row from operator_sessions and rotate the OPERATOR_OIDC_CLIENT_SECRET so the session-binding key changes). Rotate the operator’s Authentik password + WebAuthn factors out-of-band.
• Class D: Notify the sub-processor (using the contact in DPA Annex B). Pause any active integration that depends on the compromised sub-processor. Document the sub-processor’s confirmation timestamp.

Step 2 — Scope characterisation (T+4h to T+24h) #

What data was affected? How many data subjects? How many records? Likely consequences? IC fills out the Datatilsynet form fields below in draft, even before the substantive answer is final — drafting forces the gap analysis.

Datatilsynet notification fields (Danish form, English here for drafting):

1. Identification of the controller — fremverk ApS, CVR 39150689, registered office Ringager 4C, 2. tv, 2605 Brøndby, Denmark. Full controller-identification block in legal-meta.md §Identity (single source of truth).
2. Contact for the data protection officer — compliance@frem.sh.
3. Description of the nature of the breach — what happened, which systems involved, when detected vs when occurred.
4. Categories of data subjects — staff, contractors, prospects, counterparty contacts, etc.
5. Approximate number of data subjects — conservative upper bound; if unknown, say so.
6. Categories of personal data records — identification, contact, authentication credentials, financial, special-category, etc.
7. Approximate number of personal-data records — same.
8. Likely consequences of the breach — credential abuse, identity theft, financial loss, reputational, etc.
9. Measures taken or proposed — containment so far + remediation plan.
10. Reason for delay (if filed late) — substantive only, never procedural.

Step 3 — Notification (T+24h to T+72h) #

When 9/10 fields are reasonably populated, the IC + Compliance Officer hold a 30-minute review call, finalise the text in Danish, and submit to Datatilsynet. The submission receipt is logged in the incident channel and copied to compliance@frem.sh with the Datatilsynet case number.

Step 4 — Data-subject communication (Art. 34, where applicable) #

If the breach is likely to result in a high risk to the rights and freedoms of natural persons (Art. 34(1)), affected data subjects are notified individually without undue delay. Triggers (non-exhaustive):

• Authentication credentials in cleartext to an unauthorised party.
• Special-category data (health, political, biometric) exposed.
• Sufficient identification + contact data to mount a targeted phishing or social-engineering campaign.

Communication is in the data subject’s working language (Danish for DK staff, English for international counterparties), via direct email + signed letter for staff. Template at the bottom of this runbook.

Exceptions per Art. 34(3) (encryption-rendered-unintelligible, subsequent-mitigation-rendering-high-risk-no-longer-likely, disproportionate-effort-→-public-communication) are documented in the incident timeline with the reasoning.

Step 5 — Post-incident review (T+5d) #

Within 5 business days of containment, the IC publishes a post-incident review to the incident channel covering: timeline, root cause, what worked, what didn’t, action items with owners + due dates. If the incident affected Customer Personal Data, a customer-facing summary is also drafted (separate document, posted to status.frem.sh per DPA §8.1 if applicable).

The Art. 33(5) record (record of all personal-data breaches) is updated with the post-incident review timestamp.

Out-of-band escalation paths #

If the on-call channel is itself compromised (suspected Class A involving an admin who can manipulate Kuma alerts, or suspected mailbox.org compromise of oncall@):

1. Personal phone tree, in this order: shj +45 [redacted from runbook — see counsel.md], legal counsel.
2. fremverk’s primary mobile carrier customer service (Telia DK) for SMS-based out-of-band confirmation — never as the only channel.
3. In-person at the registered address — last resort.

The phone tree is rehearsed quarterly in a tabletop exercise (next: 2026-08-01).

Datatilsynet notification template (in Danish) #

TIL: Datatilsynet
EMNE: Anmeldelse af brud på persondatasikkerheden — fremverk ApS, CVR 39150689

Identifikation af den dataansvarlige:
fremverk ApS
CVR: 39150689
Adresse: Ringager 4C, 2. tv, 2605 Brøndby, Danmark (CVR 39150689 — single-source-of-truth: legal-meta.md §Identity)
Privacy-contact / DPO-equivalent: compliance@frem.sh

Beskrivelse af bruddet:
{Karakter af bruddet — hvad er sket, hvilke systemer er berørt, hvornår blev det opdaget vs hvornår fandt det sted.}

Kategorier af berørte registrerede:
{f.eks. medarbejdere, samarbejdspartnere, kunder hos en underdatabehandler.}

Omtrentligt antal berørte registrerede:
{Konservativt skøn. Hvis ukendt: angiv "ukendt på anmeldelsestidspunktet, opdateres i opfølgning".}

Kategorier af berørte persondatakategorier:
{f.eks. identifikation, kontaktoplysninger, autentifikationsoplysninger, særlige kategorier.}

Omtrentligt antal berørte persondataposter:
{Som ovenfor.}

Sandsynlige konsekvenser:
{Hvad kan bruddet føre til for de registrerede.}

Foranstaltninger:
{Indkredsning, afhjælpning, varsling — hvad er der gjort + hvad er planlagt.}

Begrundelse for forsinkelse (hvis indberetning > 72 timer efter kendskab):
{Substantielt — aldrig proceduremæssigt.}

Data-subject communication template (English, adapt to language as needed) #

Subject: Important notice: a security incident at fremverk affecting your personal data

Dear {name},

We are writing to inform you that on {discovery date}, fremverk became aware of a security incident affecting personal data we process about you in our role as data controller. This notification meets our obligation under Article 34 of the GDPR.

What happened:
{Brief, factual description.}

What information was affected:
{Specific categories. Be concrete.}

What we have done:
{Containment + mitigation steps already taken.}

What you should do:
{Concrete steps the data subject can take — change a password, enable MFA on a related account, watch for phishing, etc.}

What we are doing next:
{Remediation in progress + the regulator notification.}

Contact:
For questions about this incident, contact compliance@frem.sh. The Danish supervisory authority — Datatilsynet — has been notified and the case number is {Datatilsynet case number}. You may also contact Datatilsynet directly via datatilsynet.dk.

Sincerely,
{Name + role}
fremverk ApS

Rehearsal cadence #

• Tabletop exercise: every 6 months, rotating through the four classes. Next: 2026-08-01 (Class B — WORM tamper).
• Live drill: once annually, smallest credible scope (e.g. simulated Class A on a test account in a non-production Authentik instance). Next: 2026-Q4.
• Documentation review: every 12 months minimum, or after any incident that exposed a runbook gap. Owner: Compliance Officer.

Change-log #