The three-lines-of-defence signoff chain

The three-lines-of-defence model (“3LoD”) is not a product feature. It is the governance expectation European prudential supervisors have placed on banks, insurers, investment firms, and payment institutions for roughly two decades. In its modern form the model was formalised by the Institute of Internal Auditors in Three Lines Model (2020), and the European Banking Authority references it in the EBA Guidelines on internal governance (EBA/GL/2021/05). It asks three questions of every control decision: who owns the risk, who independently challenges the owner, and who verifies that the first two did their job.

Applied to regulatory change, those three questions become concrete:

1. A 1LoD business owner (Head of Compliance, Head of Regulatory Affairs, Head of Operational Risk, or Head of Financial Crime, depending on the topic) structures the impact and commits to it: is the change applicable, to whom, by when, with what severity and what evidence.
2. A 2LoD reviewer (independent Compliance or Risk) either countersigns the 1LoD decision — producing a second, linked signoff — or formally challenges it and returns the impact to the 1LoD with a comment. A challenge return is itself a recorded event.
3. A 3LoD auditor (Internal Audit) reviews the chain read-only and can export a tamper-evident snapshot for a supervisor or for periodic assurance work.

Almost every regulatory-ops tool on the market stops at step 1 — or, more charitably, emulates steps 1 and 2 with an email thread and a shared inbox. RegRadar implements the chain in the database with SHA-256 hashes so that the chain can be independently verified, months or years later, from a JSON export. This page describes exactly how.

What a signoff is, physically

A RegRadar DecisionSignoff is a row in Postgres. It links to the impact, records the line of defence, the actor, the decision, the rationale, the evidence references, and a cryptographic hash of the signed payload. Here is the canonical shape, taken directly from migration 0031_enterprise_next_release and the models deployed in production:

{
  "id": 1784,
  "impact_id": 246,
  "impact_version": 3,
  "line_of_defence": "1LoD",
  "signer_id": "usr_b02e…",
  "signer_display_name": "Camille R.",
  "signer_role": "Head of Compliance FR",
  "decision_status": "applicable",
  "decision_rationale": "DORA Art. 17 applies; scope limited to ICT incident reporting.",
  "evidence_refs": [
    "https://eur-lex.europa.eu/eli/reg/2022/2554/oj",
    "internal:/policies/dora-incident-reporting#v3"
  ],
  "signed_at": "2026-04-22T10:14:22Z",
  "profile_hash": "86989e864b139711c5b29e3f8328a6763330b1c8f5178326f713c9d71bfbbc2f",
  "signoff_hash": "3a1b9f24c0...e0d5",
  "previous_signoff_id": null,
  "countersigns_signoff_id": null,
  "challenge_returned": false,
  "delegated_from_user_id": null,
  "delegation_expires_at": null
}

signoff_hash is computed as sha256(canonical_json(payload)) where payload is every field listed above except the hash itself. It is computed inside a single database transaction at signoff time and stored alongside the row. Because the hash includes previous_signoff_id (or countersigns_signoff_id for 2LoD countersignatures), each signoff is cryptographically linked to the one before it, like a tiny private blockchain scoped to a single impact.

The chain, end-to-end

A concrete end-to-end example follows one impact, Impact #246, from ingestion to audit export. The pilot this came from is a French bank provisioned against the fr-bank-group profile preset with DORA in scope.

1. Ingestion and structuring. The underlying document is a published EUR-Lex Regulation. The worker detects the new version, extracts the delta, and the AI produces a structured impact object: applicable, severity medium, due date 2026-06-01, affected perimeter ICT incident reporting. Confidence 92%, six of six fields extracted, zero operator overrides.
2. 1LoD signoff.Camille R., Head of Compliance FR, opens the impact, reads the AI summary, accepts the structured object, fills in rationale and evidence, and clicks “Sign 1LoD”. The DecisionSignoff row above is created. The impact version is locked to 3. An audit event is emitted: impact.signed.1lod.
3. Routing to 2LoD.Because the topic is DORA, the 2LoD queue is Operational Risk (SLA 48h). The impact lands there with a “Signed 1LoD” chip and a due time 48 hours after the 1LoD signoff.
4. 2LoD countersignature.Jonas K., Head of Operational Risk, opens the impact, reads the 1LoD rationale, reviews the evidence, and clicks “Countersign 2LoD”. A second DecisionSignoff row is created with line_of_defence = "2LoD" and countersigns_signoff_id = 1784. Its own signoff hash includes 1784's hash. The impact detail now displays “Signoff #1785 contresigné par #1784”.
5. Or: 2LoD challenge return.Jonas could instead click “Challenge / retour 1LoD” with a comment (“severity should be high given Annex II scope”). The impact routes back to Camille, a signoff record with challenge_returned = true is created, and the chain stays open. This is not a rejection; it is documented disagreement. Camille updates the structured object and re-signs, producing a new 1LoD signoff, and the dance continues until either side countersigns or the impact is escalated to 3LoD.
6. 3LoD oversight. Internal audit has read access to the chain and to the raw journal. 3LoD does not normally sign; it reviews, and it exports. The Snapshot complet pack and the Rapport comité pack both include the full signoff trail for the impacts in scope.

Verifying the chain

The chain is verifiable from the JSON export alone. Internal audit (or, for enterprise deployments, the supervisor's own auditor) can run the following check outside RegRadar:

# Pseudo-code for chain verification — runs on an exported JSON file
for signoff in sorted(signoffs, key="id"):
    payload = {**signoff, "signoff_hash": None}  # strip the hash field
    expected = sha256(canonical_json(payload))
    assert expected == signoff["signoff_hash"], (
        f"Tampered signoff id={signoff['id']}"
    )
    if signoff.get("countersigns_signoff_id"):
        parent = by_id[signoff["countersigns_signoff_id"]]
        assert parent["signoff_hash"] in payload_bytes(signoff), (
            "Counter-signoff does not include parent hash"
        )

A single mutated field — change severity from "medium" to "low" in the stored payload after the fact — changes the recomputed hash. A single deleted row breaks the linked-list structure because the next signoff points to a missing parent. Both failure modes are trivial to detect and impossible to hide without also re-signing every downstream node, which requires the private-key capability to act as the signer (which, inside the tenant, means a valid session for that named user).

Delegation and planned absence

Regulated teams go on holiday. RegRadar supports delegation with an explicit expiry date, set in Settings → Rôles et délégations. The delegated signer signs under their own identity, but the signoff records delegated_from_user_id and delegation_expires_at, so inspection can distinguish “Camille signed personally” from “Aminata signed on behalf of Camille during the 12–26 April absence”. Delegations past their expiry are refused at signoff time.

LOB queue SLAs

The model is agnostic about timing; the product is not. Each impact is routed to one of four line-of-business queues after 1LoD signoff, each with a default SLA. Overdue counts surface on the queue header in Settings → Rôles and are the single metric we ask operators to watch in their weekly management review.

What this buys you at inspection time

The sequence inspectors actually walk is narrow. When an on-site team asks for evidence on a specific regulatory change, a RegRadar operator navigates: Audit → chain-integrity statement and review-quality KPIs (impacts relus, decisions consignées, digests envoyés, parties prenantes touchées, temps médian) → Décisions → Registre → the specific decision → the impact detail with signoff hashes and AI transparency panel → the original source document in Sources. The Snapshot complet export packages this entire chain for the regulator's own auditor.

Crucially, the inspector does not have to trust RegRadar, or the AI, or the operator's memory. They have to trust SHA-256, which is a defensible position: the Bundesamt für Sicherheit in der Informationstechnik (BSI), ANSSI, and NIST all list SHA-256 as approved for long-lived integrity evidence.

What this does not buy you

• Opinion-of-fact. The chain proves the sequence happened and has not been tampered with. It does not prove that the 1LoD judgment was correct. Judgment is human.
• Perimeter definition. If the tenant profile is wrong, the applicability verdict will be wrong, and the signoff will be wrong. The profile_hash inside every signoff lets you retroactively identify decisions made against a stale profile — but it does not retroactively fix them.
• Completeness. The chain proves what happened. It does not prove that a change was seen. Source health metrics and the coverage panel are there for that.

Why the chain is not optional

When a supervisor asks why a given DORA obligation was marked non-applicable, the defensible answer has two components. “Our Head of Compliance, Camille R., signed it on 22 April 2026 at 10:14 UTC with rationale X and evidence pack Y, and our Head of Operational Risk, Jonas K., countersigned on 23 April at 08:42 UTC. You can independently verify the integrity of those two signoffs by recomputing SHA-256 over the JSON export we will hand you.”

That is a complete, short, falsifiable answer. A tool that can only say “Camille clicked a button, probably on the 22nd, we think” is not a regulatory-ops tool.