Skip to content
Decision-state infrastructure
ende
Applications

Cyber Incident

APPLICATION / CYBER INCIDENT

What must be decided before the full scope of a cyber incident is known?

A serious cyber incident does not wait for the forensic investigation to finish. Systems may need to be isolated, an enterprise crisis state may need to be activated, regulatory notification obligations may need to be assessed, and customers, employees or counterparties may expect information while material parts of the incident scope are still unknown.

In this illustrative case, a large European enterprise group is hit by an enterprise ransomware and double-extortion incident. A privileged account has been abused, several internal systems have been reached, ransomware activity is confirmed and initial services are impaired.

At that point it is not yet fully resolved how far the attacker has progressed, whether and which data has been exfiltrated, which personal data and customers are affected, whether further persistence exists, which backups can be trusted, or which regulatory and contractual reporting states have already been reached.

The central question is not what the organisation knows at the end of the cyber incident. It is what knowledge state existed when a specific escalation, notification, communication or recovery decision had to be made.

EVENT TIMELINE ≠ KNOWLEDGE TIMELINE ≠ DECISION TIMELINE

I / THE INCIDENT

The incident begins before the organisation can know its full scope

01

An enterprise ransomware incident begins with evidence, not complete certainty

Consider an illustrative large European enterprise group. Its industry is intentionally left unspecified. The group operates central identity management, ERP and order-processing systems, file and collaboration platforms, finance and HR systems, customer services, multiple European locations and a centralised Security Operations Centre.

At 07:42 the SOC detects unusual privileged activity outside the expected operating state, suspicious remote execution, credential-access behaviour and connections to multiple servers. Ransomware has not yet been confirmed.

SUSPICIOUS SECURITY EVENT — UNDER ASSESSMENT

A technical event and the organisation's knowledge of that event are not the same thing.

02

Minutes later, the state can change fundamentally

By 08:17, the SOC and Incident Response confirm abusive use of the privileged account, remote execution across several systems, manipulation of a security agent, credential-dumping behaviour, initial encrypted files and a ransomware component.

CYBER INCIDENT — CONFIRMED

MALICIOUS ACTIVITY — CONFIRMED

PRIVILEGED ACCESS ABUSE — CONFIRMED

RANSOMWARE ACTIVITY — CONFIRMED

 

FULL INCIDENT SCOPE — UNKNOWN

DATA EXFILTRATION — UNKNOWN

PERSONAL DATA IMPACT — UNKNOWN

ROOT CAUSE — UNKNOWN

Incomplete knowledge does not mean no incident. A confirmed incident does not mean that every downstream decision is already finalisable.

03

Incident response begins before regulatory finality exists

Once the cyber incident is confirmed, technical response starts: privileged accounts can be disabled, sessions invalidated, hosts isolated, network paths restricted, credentials rotated, backups protected and forensic preservation activated.

Technical response

Detect

Governance decisions

Classify

Technical response

Analyse

Governance decisions

Escalate

Technical response

Contain

Governance decisions

Assess

Technical response

Eradicate

Governance decisions

Report

Technical response

Recover

Governance decisions

Communicate

NIS2 is designed around staged reporting during an ongoing incident. Technical containment, eradication and recovery therefore do not wait for a complete reporting state.

Primary source: Directive (EU) 2022/2555 — NIS2

Epistemis does not make operational containment, eradication or recovery dependent on SEAL.

04

Three timelines describe the same incident

Later forensic work may reconstruct initial access at 03:18, credential theft at 04:06, data staging at 06:10, possible exfiltration at 06:48 and ransomware deployment at 07:36. The organisation first detects relevant activity at 07:42 and makes governance decisions later.

Timeline

EVENT TIMELINE

Question

When did something happen technically?

Timeline

KNOWLEDGE TIMELINE

Question

When did a claim become supportable for the organisation?

Timeline

DECISION TIMELINE

Question

When was a specific decision made on that knowledge?

EVENT TIME

≠

EVIDENCE TIME

≠

DECISION TIME

The final forensic event timeline cannot by itself show what the organisation knew when an earlier decision was made. Occurrence, knowledge and decision do not share one timestamp.

EVENT TIMELINE

03:18

Initial access — later reconstructed

EVENT TIMELINE

04:06

Credential theft

EVENT TIMELINE

06:10

Data staging

EVENT TIMELINE

06:48

Possible exfiltration

EVENT TIMELINE

07:36

Ransomware deployment

KNOWLEDGE TIMELINE

07:42

Suspicious activity detected

KNOWLEDGE TIMELINE

08:17

Incident confirmed

KNOWLEDGE TIMELINE

09:05

Exfiltration suspected

DECISION TIMELINE

10:10

Enterprise Crisis activated

DECISION TIMELINE

12:15

NIS2 significance resolved — illustrative

KNOWLEDGE TIMELINE

13:40

Personal data breach confirmed

DECISION TIMELINE

17:30

Early Warning released

KNOWLEDGE TIMELINE

21:15

Exfiltration confirmed

DECISION TIMELINE

DAY 2

Privacy reporting decisions

EVENT TIME ≠ EVIDENCE TIME ≠ DECISION TIME

II / WHAT IS KNOWN NOW

The same incident contains facts, inferences, hypotheses, unknowns and conflicts

05

Fact, inference and hypothesis must not collapse into one state

State

CONFIRMED

Meaning

Sufficiently directly supported

State

SUPPORTED INFERENCE

Meaning

Supported by multiple pieces of evidence

State

SUSPECTED

Meaning

Plausible, not yet sufficiently established

State

HYPOTHESIS

Meaning

Active investigative hypothesis

State

UNKNOWN

Meaning

Currently not determinable

State

CONFLICTING

Meaning

Conflicting evidence or professional assessments

State

DISPROVED

Meaning

Refuted by later evidence

FACT

≠

INFERENCE

≠

HYPOTHESIS

≠

ASSUMPTION

≠

UNKNOWN

06

Incident scope does not become known all at once

At 09:05, multiple systems are affected, a central business application is impaired, archives have been created on one server and unusual outbound traffic has been observed.

Time

08:17

Claim

Ransomware Activity

State

CONFIRMED

Time

09:05

Claim

Enterprise Compromise

State

CONFIRMED

Time

09:05

Claim

Data Exfiltration

State

SUSPECTED

Time

11:25

Claim

Personal Data Impact

State

UNDER ASSESSMENT

Time

13:40

Claim

Personal Data Breach

State

CONFIRMED

Time

21:15

Claim

Data Exfiltration

State

CONFIRMED

07

Unknown is a real state, not a negative fact

A personal data breach is not limited to exfiltration. It can involve unauthorised access, alteration, loss, destruction or unavailability of personal data. EDPB guidance explicitly discusses ransomware as a context in which availability can be compromised even without confirmed exfiltration.

Primary source: EDPB — Personal data breach guidance

NOT CONFIRMED

≠

NO

 

UNKNOWN DATA IMPACT

≠

NO DATA IMPACT

 

NO CONFIRMED EXFILTRATION

≠

NO PERSONAL DATA BREACH

08

Every material claim needs provenance and time

Field

Claim

K-04 / 09:05

Customer data exfiltrated

K-09 / 21:15

Customer data exfiltrated

Field

State

K-04 / 09:05

SUSPECTED

K-09 / 21:15

CONFIRMED

Field

Evidence

K-04 / 09:05

Outbound telemetry · archive creation

K-09 / 21:15

Proxy correlation · repository access

Field

Limitation / change

K-04 / 09:05

Payload content not established

K-09 / 21:15

Transmission sufficiently established

The new state does not retrospectively replace the old one. It follows it.

09

Different sources can create a conflict state

  • 01Network Team — no conclusive egress-volume evidence.
  • 02Forensics — archive creation and attack sequence indicate data staging.
  • 03Data Owner — the affected repository contains confidential customer information.

DATA EXFILTRATION — CONFLICTING / UNDER ASSESSMENT

A conflict state is not a failure of the decision process. It is part of the decision reality.

III / ONE INCIDENT, MULTIPLE DECISIONS

Shared knowledge can support several decisions with different blockers and finality

10

The shared Incident Space is not itself the decision

All downstream decisions consume a common, versioned Incident Knowledge State. The same knowledge can support Cyber / Crisis, NIS2 Reporting where applicable, GDPR / Personal Data, External Communication and Recovery / Return-to-Service Decision Spaces.

SHARED KNOWLEDGE

≠

SHARED FINALITY

One shared, versioned Knowledge State can support several Decision Spaces with independent blockers and finality. New evidence updates the Knowledge State and only impacted decisions need reassessment.

INCIDENT EVIDENCE

VERSIONED KNOWLEDGE STATE K-07

Shared knowledge does not imply shared finality.

01 / CYBER / CRISIS

ACTIVATED

FINAL

SEAL / DECISION BOUND

02 / NIS2

SIGNIFICANCE RESOLVED

FINAL

SEAL / DECISION BOUND

03 / GDPR / PERSONAL DATA

ART. 33 UNDER ASSESSMENT

OPEN

04 / COMMUNICATION

PARTIALLY AVAILABLE

CLAIM-SPECIFIC

05 / RECOVERY

BLOCKED

OPEN

NEW EVIDENCE

BRIDGE / ADMISSIBLE TRANSITION

Provenance · evidence type · timestamp · scope · conflict · decision impact · authority · version

KNOWLEDGE STATE K-08

Only impacted decisions reassess.

11

Internal severity can be final while data scope remains open

At 10:10 the incident is illustratively escalated to enterprise-crisis level. Confirmed ransomware, privileged compromise, multiple affected systems and material business-service disruption may be sufficient for that decision even while data exfiltration and root cause remain open.

ENTERPRISE CRISIS — ACTIVATED

Incomplete knowledge is not automatically a blocker. An unresolved state becomes a blocker only where it must be resolved for that specific decision.

12

NIS2 creates a separate Decision Space

Where the competent functions have established that the relevant NIS2 implementation applies, the decision is whether the incident has reached the significant-incident state relevant to that entity.

Primary source: Directive (EU) 2022/2555 — NIS2

Dimension

Applicability

Illustrative state

BOUND / KNOWN

Dimension

Cyber Incident

Illustrative state

CONFIRMED

Dimension

Malicious Activity

Illustrative state

CONFIRMED

Dimension

Service Impact

Illustrative state

CONFIRMED / EVOLVING

Dimension

Impact on Others

Illustrative state

POSSIBLE

Dimension

Financial Impact

Illustrative state

UNKNOWN

Dimension

Significance

Illustrative state

UNDER ASSESSMENT

Dimension

Notification Authority

Illustrative state

IDENTIFIED

SIGNIFICANCE ASSESSMENT — UNRESOLVED

13

A reporting state can become final before the investigation is complete

In the illustrative scenario, the competent Legal / Compliance functions reach a sufficient significant-incident state at 12:15. That timestamp is an illustrative internal assessment, not a legal conclusion made by Epistemis.

SIGNIFICANT-INCIDENT AWARENESS — 12:15

Article 23 NIS2 ties staged reporting to awareness of a significant incident. The early warning follows in principle within 24 hours and the incident notification within 72 hours, while later reporting can contain materially more detail.

Primary source: Directive (EU) 2022/2555 — NIS2

A reporting decision can become necessary before root cause, full scope or complete data-impact analysis are available.

14

NIS2 early warning and later reporting are different Decision States

Stage

Early Warning

Illustrative information maturity

Malicious incident and service impact known; full root cause and full data scope may remain unknown.

Stage

72-hour Incident Notification

Illustrative information maturity

Updated severity, impact, available indicators and additional confirmed facts.

Stage

Final / Progress Report

Illustrative information maturity

More complete root-cause, impact and mitigation state.

EARLY WARNING STATE

≠

72-HOUR NOTIFICATION STATE

≠

FINAL REPORT STATE

15

Privacy creates several additional Decision Spaces

At 11:25, the compromised account's access to a repository containing personal data is known, but actual unauthorised access is still under assessment. Later, at 13:40 in the illustrative scenario, additional evidence confirms unauthorised access to personal data.

PERSONAL DATA BREACH — CONFIRMED

EDPB guidance describes awareness in terms of a reasonable degree of certainty that a security incident has occurred which has led to personal data being compromised. A short initial investigation can precede that point while more detailed investigation continues afterwards.

Primary source: EDPB — Personal data breach guidance

16

One incident does not have one awareness time

12:15 — NIS2 SIGNIFICANT-INCIDENT AWARENESS

≠

13:40 — PERSONAL DATA BREACH AWARENESS

ONE INCIDENT ≠ ONE AWARENESS TIME

ONE INCIDENT ≠ ONE CLASSIFICATION ≠ ONE REPORTING CLOCK

17

Personal data breach, Article 33 notification and data-subject communication are different decisions

Article 33 GDPR generally requires supervisory notification without undue delay and, where feasible, within 72 hours after awareness unless the breach is unlikely to result in a risk to rights and freedoms. Article 34 contains a separate high-risk threshold for communication to affected data subjects.

Primary source: Regulation (EU) 2016/679 — GDPR

PERSONAL DATA BREACH?

↓

ARTICLE 33 — SUPERVISORY NOTIFICATION?

↓

ARTICLE 34 — DATA-SUBJECT COMMUNICATION?

18

The incident can contain final and open decisions at the same time

Decision Space

Cyber Incident Confirmation

State

CONFIRMED

Finality

FINAL FOR THIS DECISION

Decision Space

Enterprise Crisis

State

ACTIVATED

Finality

FINAL FOR THIS DECISION

Decision Space

NIS2 Significance

State

RESOLVED

Finality

FINAL FOR THIS DECISION

Decision Space

NIS2 Early Warning

State

AVAILABLE / IN PREPARATION

Finality

PENDING ACTION

Decision Space

Personal Data Breach

State

CONFIRMED

Finality

FINAL FOR THIS DECISION

Decision Space

GDPR Article 33

State

UNDER ASSESSMENT

Finality

OPEN

Decision Space

GDPR Article 34

State

UNDER ASSESSMENT

Finality

OPEN

Decision Space

Customer Communication

State

PARTIALLY AVAILABLE

Finality

CLAIM-SPECIFIC

Decision Space

Data Exfiltration

State

SUSPECTED

Finality

OPEN

Decision Space

Recovery

State

BLOCKED

Finality

OPEN

Decision Space

Root Cause

State

UNKNOWN

Finality

OPEN

Finality belongs to a decision, not to the incident as a whole.

IV / WHEN NEW EVIDENCE ARRIVES

New evidence can change current states without rewriting the states that supported earlier decisions

19

A new fact state creates a new knowledge version

At 21:15 additional proxy and network telemetry, archive timestamps, repository-access evidence, session information and traffic volume are correlated. In the illustrative case this is sufficient to establish data exfiltration.

Knowledge version

K-04 / 09:05

State

EXFILTRATION — SUSPECTED

Evidence

Outbound telemetry · archive creation

Knowledge version

K-09 / 21:15

State

EXFILTRATION — CONFIRMED

Evidence

Proxy correlation · repository access

K-09 does not overwrite K-04. It follows K-04.

20

Reclassification is not automatically a contradiction

Reclassification is not contradiction when new evidence changes the state.

Historical integrity does not mean preserving an earlier assessment forever. It means preserving why the state changed.

21

Only affected decisions need to be reassessed

Decision Space

GDPR Risk Assessment

Effect of confirmed exfiltration

May change

Decision Space

Customer Communication

Effect of confirmed exfiltration

May change

Decision Space

Contractual Notifications

Effect of confirmed exfiltration

May change

Decision Space

Later NIS2 report content

Effect of confirmed exfiltration

May change

Decision Space

Enterprise Crisis Escalation

Effect of confirmed exfiltration

May remain unchanged

Decision Space

Recovery Authority

Effect of confirmed exfiltration

May remain unchanged

New evidence does not mean reassess everything. It means identify which Decision Spaces consume the changed state.

22

SIMULATION can examine unresolved Decision States

For a GDPR Article 33 decision, SIMULATION can expose which open evidence classes still prevent the relevant risk state from being assessed: affected data categories, affected persons, sensitivity, exposure, likely consequences and mitigations.

Epistemis exposes the structure of the unresolved Decision State. It does not make the legal assessment.

23

SIMULATION can examine conditional states

Actual knowledge state

DATA EXFILTRATION — SUSPECTED

SIMULATION candidate

IF DATA EXFILTRATION — CONFIRMED

The conditional change may affect GDPR, customer communication, contractual notification and later NIS2 report content while other decisions remain unchanged.

24

A simulated scenario is not evidence

IF EXFILTRATION CONFIRMED

≠

EXFILTRATION CONFIRMED

A simulated conditional state is not evidence.

25

BRIDGE controls real new evidence

  • 01Provenance — where did the information come from?
  • 02Evidence Type — fact, inference, hypothesis, assumption or conflict?
  • 03Timestamp — when did it actually become available?
  • 04Scope — which systems, data, entities or services does it affect?
  • 05Conflict — does it contradict existing evidence?
  • 06Decision Impact — which Decision Spaces consume the state?
  • 07Authority — which competent function may adopt it?
  • 08Version — which historical state remains preserved?
See how SIMULATION, BRIDGE and SEAL separate exploration, new evidence and governed finality

26

New evidence may change the current state, but not the past

New evidence may update the current state, but must not rewrite the state that supported an earlier decision.

V / AUTHORITY & COMMUNICATION

Different authorities act on different states, and external communication remains claim-specific

27

A cyber incident contains several types of authority

Authority type

Evidence Authority

Function

Supplies authoritative technical sources

Authority type

Assessment Authority

Function

Assesses a professional state

Authority type

Classification Authority

Function

Sets internal severity or crisis state

Authority type

Notification Authority

Function

Approves or initiates external notification

Authority type

Recovery Authority

Function

Returns systems or services to production

EVIDENCE AUTHORITY

≠

ASSESSMENT AUTHORITY

≠

CLASSIFICATION AUTHORITY

≠

NOTIFICATION AUTHORITY

≠

RECOVERY AUTHORITY

28

The same incident activates different responsibilities

Function

SOC

Responsible state

Detection Evidence

Function

Incident Response / CSIRT

Responsible state

Investigation and technical Fact States

Function

Identity / Infrastructure Security

Responsible state

Identity and Infrastructure State

Function

Business / Service Owner

Responsible state

Business Impact

Function

Incident Commander

Responsible state

Operational coordination

Function

CISO / Security Leadership

Responsible state

Security Severity and Executive Escalation

Function

Legal / Regulatory Compliance

Responsible state

Regulatory Applicability and Reporting Assessment

Function

Privacy / DPO Function

Responsible state

Personal-Data-Breach and Rights-Risk State

Function

Crisis Authority

Responsible state

Enterprise Crisis

Function

Corporate Communications

Responsible state

External communication

Function

Notification Authority

Responsible state

External reporting

Function

Recovery Authority

Responsible state

Return to Service

Function

Internal Audit

Responsible state

Independent later review

29

External communication needs its own Evidence State

Claim

We are investigating a cyber incident

Communication state

CONFIRMED FOR COMMUNICATION

Claim

Some services are disrupted

Communication state

CONFIRMED FOR COMMUNICATION

Claim

Ransomware activity occurred

Communication state

CONFIRMED FOR COMMUNICATION

Claim

Data impact is under investigation

Communication state

SUPPORTABLE / QUALIFIED

Claim

No customer data was accessed

Communication state

NOT SUPPORTABLE

Claim

Data exfiltration occurred

Communication state

SUSPECTED → LATER CONFIRMED

30

Communication finality is claim-specific

Communication finality is claim-specific.

A communication authority cannot substitute for missing evidence. Different material claims in the same statement can have different evidence states.

31

An earlier public statement may later appear wrong even though the earlier Knowledge State was different

Saying “No customer data was accessed” while Data Impact is UNKNOWN is a claim the current state does not support. Saying “We are investigating whether data was affected” can remain historically accurate even if later forensics confirms exfiltration.

32

Decision outputs must not manufacture new facts

NIS2 SIGNIFICANT = YES

≠

DATA EXFILTRATION = CONFIRMED

 

PERSONAL DATA BREACH = YES

≠

CUSTOMER CONTRACT NOTIFICATION = REQUIRED

Decision outputs may consume knowledge; they must not silently manufacture facts.

33

SEAL belongs to the decision, not the incident as a whole

Bound decision

Enterprise Crisis Activation

Knowledge version

K-03

Bound decision

NIS2 Early-Warning Decision

Knowledge version

K-06

Bound decision

GDPR Article 33 Decision

Knowledge version

K-10

SEAL — SPECIFIC DECISION

≠

THE INCIDENT — FINAL

34

SEAL does not freeze the investigation

New facts can emerge after an early-warning decision has been bound. They create a new Knowledge Version and may trigger new or updated decisions while the earlier Decision State remains preserved.

VI / LATER REVIEW

Later scrutiny must compare earlier Knowledge States with later facts rather than collapse them into one final narrative

35

The final report is not the original Decision State

Three weeks later, forensic investigation may reconstruct initial access, credential theft, privilege escalation, lateral movement, data staging, exfiltration, ransomware deployment and root cause. That knowledge state is materially more complete than the state that existed during the first morning.

NIS2 likewise allows later reporting to contain a more detailed incident description, severity and impact, likely threat type or root cause, mitigation and, where applicable, cross-border impact.

Primary source: Directive (EU) 2022/2555 — NIS2

The final report is a later Knowledge State. It is not the information that existed at the time of the early warning.

36

A later reviewer needs more than the technical timeline

  • 01Knowledge — what was actually known at that point?
  • 02Unknown — which material questions were unresolved?
  • 03Evidence — which source supported which claim?
  • 04Confidence — was a claim confirmed, suspected or only a hypothesis?
  • 05Time — since when had the relevant evidence been available?
  • 06Decision — which decision consumed this Knowledge State?
  • 07Requirement — which internal or external requirements applied?
  • 08Authority — who was authorised to make the decision?
  • 09Conflict — which conflicting professional assessments existed?
  • 10Change — which new information changed the state later?

37

Later knowledge must not become the evaluation standard for earlier decisions

If Day-21 forensics establishes that exfiltration began at 06:48, the relevant review question is not why the organisation reacted to confirmed exfiltration at 06:50. It is when sufficiently reliable evidence of exfiltration became available to the organisation.

Later facts must not rewrite earlier decisions.

38

Reclassification is part of a reconstructable incident state

Knowledge version

K-04

State

DATA EXFILTRATION — SUSPECTED

Knowledge version

K-09

State

DATA EXFILTRATION — CONFIRMED

Both can be correct if it remains visible which evidence supported each state and which new evidence triggered the transition.

39

Incident-management systems and Decision States answer different questions

Incident Management

Event Timeline

Decision State

Knowledge Timeline

Incident Management

Alert

Decision State

Claim + Evidence

Incident Management

Severity

Decision State

Classification Basis

Incident Management

Owner

Decision State

Authority by Decision

Incident Management

Notes

Decision State

Versioned Knowledge State

Incident Management

Incident Status

Decision State

Decision-specific Finality

Incident Management

Actions

Decision State

Reasoned Governance Decision

Incident Management

Closed

Decision State

Historical Decision Chain

Incident-management systems preserve events and actions. A Decision State preserves what was known when responsibility was exercised.

40

One shared Knowledge State can serve different later readers

Reader

SOC / CSIRT

Central question

Which technical evidence supports the current state?

Reader

CISO

Central question

Why was a particular severity or crisis state set?

Reader

Legal / Compliance

Central question

Which facts and requirements supported the reporting decision?

Reader

Privacy / DPO Function

Central question

When did the personal-data-breach state become sufficiently determined?

Reader

Corporate Communications

Central question

Which claims were supportable at which time?

Reader

Management

Central question

On what basis were enterprise decisions made?

Reader

Internal Audit

Central question

How did Knowledge → Decision → Reclassification evolve?

Reader

Authorised external reviewer

Central question

Which historical view supports the decision made at the time?

See how later institutional readers examine an earlier Decision State

41

Real professional and legal authority remains outside Epistemis

  • 01Epistemis does not determine whether a security event is in fact an incident.
  • 02Epistemis does not determine how ransomware should technically be contained.
  • 03Epistemis does not set the correct internal severity.
  • 04Epistemis does not determine whether NIS2 applies to a particular entity or when a statutory awareness threshold has legally been reached.
  • 05Epistemis does not determine whether a personal data breach exists as a matter of law or whether Articles 33 or 34 GDPR apply.
  • 06Epistemis does not determine which contractual notifications are triggered or which external statement may legally be released.
  • 07Epistemis does not determine when a system is technically safe to return to production.

Epistemis preserves which Knowledge State existed, which requirements were applied, which authority acted and which open or final states existed at that point in time.

42

Why this case goes beyond conventional incident logging

An organisation may already operate SIEM, EDR, SOAR, ticketing, incident management, forensic tools, IAM, crisis management, privacy workflows, GRC, audit logs and regulatory reporting tools. Epistemis does not replace them.

The Decision-State layer connects technical evidence, Knowledge States, business impact, data impact, requirements, uncertainty, authorities and parallel decisions so that it remains reconstructable which responsibility was assumed on which basis.

43

The Epistemis mechanism for a live cyber incident

  • 01The Incident Space holds the shared, versioned Knowledge State.
  • 02Each bounded Decision Space determines which Knowledge and Requirement States must be resolved for its own decision.
  • 03SIMULATION examines unresolved decisions or consequences of possible future states without turning hypotheses into facts.
  • 04BRIDGE evaluates real new evidence for provenance, timestamp, scope, conflict, authority and affected Decision Spaces.
  • 05SEAL binds specific decisions — never the entire incident as though it had one global final state.

A cyber incident has no single global finality. It has a graph of open, bound, reclassified and later reassessed Decision States.

SOURCES / METHOD

Source and methodology note

Real regulatory context

The regulatory basis used here is primarily NIS2 Article 23 for staged significant-incident reporting, GDPR Articles 33 and 34 for personal-data-breach notification and data-subject communication, and EDPB guidance on breach awareness and ransomware-related data breaches. In Germany, § 32 BSIG is referenced only as a national example of NIS2 implementation, not as a universal European process.

Primary source: Directive (EU) 2022/2555 — NIS2Primary source: Regulation (EU) 2016/679 — GDPRPrimary source: EDPB — Personal data breach guidancePrimary source: Germany — BSIG § 32

Illustrative scenario

The European Enterprise Group, enterprise architecture, privileged account, ransomware attack chain, timestamps, technical findings, incident scope, affected data, internal roles, NIS2 and GDPR decision timestamps, communication states and recovery states are illustrative and do not describe a real customer or cyber incident.

Epistemis modelling

Incident Space, Knowledge State, Decision State, Decision Space, blocker, SIMULATION, BRIDGE, SEAL, Knowledge Version and Evidence Pack views are Epistemis concepts. They are not terminology defined by NIS2, GDPR or EDPB guidance.

Which cyber decision would your organisation need to explain later?

An Enterprise Pilot starts with one clearly bounded incident decision and defines which evidence, knowledge states, requirements, authorities, blockers, communication claims and later reader views must remain reconstructable.

Discuss this Incident Decision Space in an Enterprise PilotExplore other applications