Propagated Controls — Managing Controls Over Event Chains

TL;DR

Where this fits in TLCTC: the core taxonomy classifies the cause side of an incident — which cluster, which attack path. This document is about the consequence side — how controls and obligations flow across the causal event chain that follows.

A single incident produces a chain of events — SRE → DRE → BRE₁ → … → BREₙ. Each event has its own NIST CSF container (ID, PR, DE, RS, RC, GV) and its own recovery objective: System Recovery for the SRE, Data Recovery for the DRE, Disaster Recovery / business continuity for the BRE. These objectives are usually owned by different organisations with different clocks.

The obligation to satisfy a downstream Protection Requirement (PR) therefore usually fires earlier in the chain — the GDPR notification clock for a future BRE starts at the DRE; the handover to the enterprise BCM/crisis-management organisation that owns disaster recovery starts at the DRE too. TLCTC models this with a single, generic mechanism: propagation of PR controls backward into the RS (Respond) container of an upstream event.

RS(Eₙ) = { Response } ∪ { Propagated PR(Eₙ₊₁) } ∪ … ∪ { Propagated PR(Eₙ₊ₓ) }

The simplest reading: a propagated control is the upstream RS step that hands an obligation off to whoever owns the downstream recovery objective — a regulator, a contract counterparty, or the BCM organisation. This document lifts the mechanism out of the glossary, names the sources of propagation (regulatory, contractual, BCM, internal policy), and works through two examples — one compliance, one BCM — that share the same structure.

1. The mechanism

The Bow-Tie consequence chain (see glossary: Event Chain, Business Risk Event) is causally directional: an SRE may cause a DRE, which may cause one or more BREs. Controls in the NIST CSF sense are normally placed at the event they protect — PR(BRE_GDPR-violation) would be "do the things that prevent a GDPR violation".

But many of those PR controls only make sense as actions taken earlier in the chain:

• Notify the supervisory authority within 72h prevents the GDPR-violation BRE, but the action is part of responding to the DRE.
• Invoke the continuity plan prevents the prolonged-outage BRE, but the action is part of responding to the SRE.
• Activate the customer-communication SLA prevents the contractual-breach BRE, but the action is part of responding to the DRE.

So the PR for the downstream event is hosted in the RS container of the upstream event. This is propagation backward up the chain. It is purely a placement rule — the control is still semantically a PR for Eₙ₊ₓ; it just executes during RS(Eₙ).

1.1 Why this matters

Without naming the mechanism, IR playbooks degenerate into "reporting checklists" — flat lists of obligations bolted onto the response procedure with no causal grounding. With it, every propagated control has:

1. A source event (which downstream BRE this PR belongs to).
2. A host event (which upstream RS container is the right place to execute it).
3. A timeline anchored to the host event clock, not the source.
4. A trigger condition based on the host event's classification.

Two propagated controls can sit in the same RS container with completely different clocks and authorities (see §5.1).

2. Sources of propagated controls

Compliance is the most visible source of propagation, but not the only one. Four sources cover the practical cases:

All four behave identically: they are PR controls of a downstream BRE that execute as RS steps of an upstream event. The framework is source-agnostic; the source only changes who owns the obligation and what defines "trigger".

3. Worked example A — Compliance (GDPR vs NIS2)

Companion blog: GDPR vs NIS2: Different Trigger Points for Compliance Events — full visual treatment of the example below.

A ransomware incident affects a NIS2-scoped operator whose data includes PII.

SRE (System Compromise)
  └─ DRE [C] (PII confidentiality loss)
        ├─ BRE_GDPR  (notification obligation, Art. 33, 72h)
        └─ BRE_NIS2  (incident report, Art. 23, 24h early warning + 72h report)

Trigger placement:

In notation:

RS(SRE) = { containment, eradication, forensics }
        ∪ { Propagated PR(BRE_NIS2):  notify CSIRT within 24h }

RS(DRE) = { breach assessment, evidence preservation }
        ∪ { Propagated PR(BRE_GDPR): notify DPA within 72h }

4. Worked example B — BCM (business disruption)

Compliance is the visible propagation case. The same mechanism — without any regulator involved — is the BCM/BIA control set.

A ransomware-driven outage of a payment-processing platform:

SRE (System Compromise)
  └─ DRE [Ac] (data present but encrypted, application data inaccessible)
        └─ BRE_disruption  (payment platform unavailable > RTO)
              └─ BRE_revenue_loss / BRE_contract_breach

BRE_disruption has its own PR set — the business continuity controls: failover capability, alternate-site readiness, RTO/RPO targets, manual-process playbooks, customer-communication SLAs. But none of those execute at BRE time. They execute earlier, propagated backward:

RS(SRE) = { containment, eradication, forensics }
        ∪ { Propagated PR(BRE_disruption): invoke BCP, declare alternate site,
                                            engage crisis-comms within RTO clock }

RS(DRE) = { restore from clean backup, validate data integrity,
            verify application state }
        ∪ { Propagated PR(BRE_disruption): activate manual processing,
                                            execute customer-comms SLA }

The IR playbook for the SRE is the BCM invocation point. The continuity controls that protect the disruption-BRE live inside RS(SRE) and RS(DRE) — exactly the same pattern as GDPR/NIS2, but driven by a BIA rather than a regulation.

This is why mature IR runbooks have BCM hand-off steps baked in: those steps are propagated PR controls in TLCTC terms. The BCM team's RTO/RPO is the timeline; the IR team's SRE/DRE classification is the trigger.

4.1 Control objectives per event — system, data, disaster recovery

The mechanism becomes most natural when you read it from the control-objective side: each event in the chain owns its own recovery objective, and those objectives are typically held by different organizational units. Propagation is what happens at the seams between them.

The DRE is where propagation becomes operationally visible. When data is encrypted by ransomware or known to be exfiltrated, the data-recovery team alone cannot complete the recovery objective — their RS plan must hand the baton over to the overarching emergency organization that owns the BCP/DR machinery. That handover is not a courtesy step; it is the moment where the PR control belonging to BRE_disruption (held by the BCM org) executes as an RS-step inside RS(DRE).

RS(DRE) = { Data-recovery response:
              restore from clean backup, validate integrity, verify state }
        ∪ { Propagated PR(BRE_disruption):
              HANDOVER to BCM emergency org, declare disaster,
              activate DR plan, execute customer-comms SLA }

The handover step belongs, conceptually, to the BCM org — their job is to prevent the disruption-BRE, so any control that does so is their PR. But the handover executes inside the data-event response plan, because RS(DRE) is the earliest point where the data-recovery team can determine that local recovery is insufficient and escalation is warranted. Two organizations, two control objectives, one container.

The same pattern plays out at the SRE level for severe incidents: the IR team's response plan must include an early handover to BCM if the incident classification crosses the threshold — which is exactly the NIS2-style propagation from §3. This is why mature IR runbooks have a step labelled something like "Escalate to BCM / DR organization" near the top: that step is the BCM org's propagated PR control, sitting in the IR team's RS container, gated by a classification threshold.

Read this way, propagation is the formal name for organizational handover. The question "which container does this control belong in?" becomes the question "which org owns the objective this control serves, and which org's RS plan executes it?" — and those two answers do not have to match.

4.2 Two tickers, two questions, two event knots

It is easy to conflate the clocks, because both involve deadlines and both are visible in IR runbooks. They answer different questions, and they anchor to different events:

• The SLA ticker anchors at the DRE and times obligations: when must you notify? when must you hand over? when must customer-comms go out? RPO, customer-comms SLA and regulatory disclosure windows all live here.
• The Service Recovery Time ticker anchors at the BRE and times delivery: when must business operations be restored? RTO for the disruption BRE lives here, with the BIA defining the tolerance.

The DRE fires the handover (SLA clock); the BRE owns the restoration (Service Recovery Time clock). Keeping them apart is what stops an IR team from believing it is accountable for an RTO it does not own.

5. Recovery objectives and the escalation handover

Once propagation is read through the recovery-objective lens, the existing examples and most real propagated controls collapse into two families.

5.1 The two families of propagated controls

Family 1 — Compliance reporting. A notification obligation hosted upstream of the BRE it would otherwise enforce: GDPR Art. 33, NIS2 Art. 23, SEC 8-K cyber, DORA major-incident reporting, contractual disclosure clauses.

Family 2 — Organisational handover. A recovery objective owned by a downstream organisation, triggered by an upstream technical event: BCP/disaster-recovery invocation, crisis-comms activation, executive escalation.

Both families are mechanically identical — Propagated PR(downstream) hosted in RS(upstream). They differ in who owns the downstream recovery objective:

A single IR playbook routinely contains both — a GDPR notification and a BCM handover sit in the same RS container, with different clocks and different recipients.

5.2 Why the DRE is the natural BCM trigger point

The SRE is technical — something is wrong with the system. The BRE is business — the customer cannot transact. The DRE sits between them, and it is the first event in the chain where a business-relevant consequence is established rather than merely feared. That makes RS(DRE) the canonical home for the IR → BCM handover:

1. The SLA ticker starts here. Customer-comms SLAs, RPO commitments and regulatory disclosure windows all anchor to data-impact awareness, not to system compromise.
2. The classification is sufficient. A DRE classification, with its CIA tags, carries enough information to trigger BCM and disclosure obligations. The SRE alone usually does not.
3. Uncertainty is acceptable but bounded. Acting at the SRE risks invoking obligations that may not apply; acting at the BRE is too late. The DRE is the earliest event where the risk of over-escalating is lower than the risk of waiting.

Preemptive SRE-level escalation is still valuable when classification severity alone justifies it — a catastrophic outage, or ransomware on a tier-0 system — but it is the exception, not the pattern.

6. Placement rule

Where does a propagated control belong?

Rule of Propagation: A PR control for event Eₙ₊ₓ is hosted in RS(Eᵢ) where Eᵢ is the earliest event in the chain whose classification suffices to trigger the obligation.

Two practical consequences:

1. GDPR-Art-33-style obligations propagate to the DRE, because they require PII (i.e., a DRE-C classification) to fire — the SRE alone is not enough.
2. NIS2-Art-23-style or BCM-RTO-style obligations propagate all the way back to the SRE, because an incident classification of sufficient severity is the trigger — no downstream event is needed.

Earlier placement = longer reaction time but also more uncertainty (you may invoke obligations that turn out not to apply). The classification quality at each event determines how aggressively propagation can reach upstream.

7. Relationship to existing v2.0 concepts

Already in the glossary:

• Propagated PR (V2.0) — line 1073 of tlctc-glossary.md. Defined for regulatory use. This document generalizes the source to four categories without changing the definition.
• RS Container (Respond Container) (V2.0) — line 1205. The formula RS(Eₙ) = { Response } ∪ { Propagated PR(Eₙ₊₁) } ∪ { Propagated PR(Eₙ₊ₓ) } is the canonical statement.
• Eₙ Event Notation (Regulatory) (V2.0) — line 528. The subscript notation (E3a, E3b) generalizes naturally to non-regulatory branches.
• Event Chain — line 560. The SRE → DRE → BRE₁ → BREₙ chain is the substrate of all propagation.

This document does not introduce new notation, axioms, or classification rules. The “recovery objective per event” mapping (System / Data / Disaster Recovery) is a reading lens on top of the existing RC container, not a new construct. It is a clarification of where existing mechanics apply.

8. Open questions

• JSON representation. Layer 3 attack paths currently model PR/DE/RS/RC controls indirectly. A future schema extension could carry an explicit propagated_controls[] array on each event node, with fields { source_event, source_type (regulatory|contractual|bcm|policy), authority, clock_start, deadline }. Not in scope here.
• Layer 2 registry — regulatory side. A reference list of common propagated controls per source type (a “propagation registry”) would let organizations stamp their IR playbooks without reinventing the mapping each time.
• Layer 2 registry — handover side. Per-organisation BCM invocation procedures — who is the crisis-management duty officer, what is the activation channel, what defines “formal handover” — are the handover-family equivalent, and are organisation-specific rather than standardisable.
• TLCTC+ alignment. The TLCTC+ NCSC/CERT proposal (documentation/tlctc-plus-ncsc-proposal.md) defines a + [BRE: ...] annotation. A propagated control is operationally adjacent — they may or may not warrant explicit linkage. Deferred.

References

• documentation/tlctc-glossary.md (GitHub) — entries: Propagated PR, RS Container, Event Chain, Eₙ Event Notation, Business Risk Event (BRE), Business Impact (BI).
• documentation/tlctc-v2.0-whitepaper.md (GitHub) — §1.4.3.1 (Consequence Chain).
• integrations/cortex-xsoar-8/Playbooks/playbook-sub-rs-container.yml (GitHub) — reference implementation of the RS container concept (regulatory propagation).
• Companion blog: GDPR vs NIS2: Different Trigger Points for Compliance Events (2026-01-24) — /tlctc-gdpr-nis2-triggers.html.