> **This is a LAB run, not a customer incident.** > The account, the operators and the case reference are from the ITSailor internal lab. It is > published so a buyer can see the artifact the product produces, including the Article 33(3) > answers left open and listed under "Open items", which is what an honest file looks like > before the controller has supplied them. # Incident file LAB-2026-0007 - Organisation: ITSailor internal lab tenant - Affected account: lab-user-118 - Playbook: Compromise - Became aware: 2026-08-12T06:55:00.000Z - Evidence chain: verified, 5 events, hash-chained and append-only. ## Measures taken | Action | Executed | Requested by | Approved by | Target checks | Reversal | |---|---|---|---|---|---| | Revoke sign-in sessions | 2026-08-12T07:19:50.000Z | lab-operator-1 | lab-operator-2 | Protected list state not recorded; parameter check not recorded | User signs in again | The **Target checks** column reports what the engine checked about the account each action pointed at, read from the policy decision recorded at the time and not recomputed since. Three of its phrases are worth reading precisely, because they are different facts. **"Protected list not configured"** means this tenant had named no accounts as off limits when the action ran, so nothing was out of scope for it. **"not recorded"** means the chain says nothing either way, which is not the same as saying there was none: it happens on a record written by an engine build that predates this field. **"could not be identified"** means the engine did not know which parameter named the target, so it made no comparison at all. Each is printed rather than omitted, because a record that says nothing about a control reads exactly like one where the control passed. ## GDPR Article 33 Applicable ### Article 33(3)(a) _Describe the nature of the personal data breach including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned._ A lab account signed in from an unrecognised location after a simulated phishing click. Mailbox access is assumed for the duration of the session. One internal test identity. No real data subjects are involved in this lab run. **Still to supply:** the categories and approximate number of records. ### Article 33(3)(b) _Communicate the name and contact details of the data protection officer or other contact point where more information can be obtained._ info@itsailor.io ### Article 33(3)(c) _Describe the likely consequences of the personal data breach._ **Not supplied.** This field is the organisation's to complete. ### Article 33(3)(d) _Describe the measures taken or proposed to be taken to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects._ Revoke sign-in sessions executed 2026-08-12T07:19:50.000Z, approved by lab-operator-2, requested by lab-operator-1 ### Article 33(5) _Document the personal data breach, comprising the facts, its effects and the remedial action taken, so that the supervisory authority can verify compliance._ This file: a verified hash-chained record of 1 executed remediation action(s) with requester, approver and timestamp for each. ## NIS2 Article 23(4) reporting cascade Undetermined: the organisation has not answered this yet | Reference | Requirement | Due | Measured from | |---|---|---|---| | Article 23(4)(a) | Early warning. | 2026-08-13T06:55:00.000Z | Within 24 hours of becoming aware of the significant incident. | | Article 23(4)(b) | Incident notification. | 2026-08-15T06:55:00.000Z | Within 72 hours of becoming aware of the significant incident. | | Article 23(4)(c) | Intermediate report. | not computable yet | On request of a CSIRT or the competent authority. | | Article 23(4)(d) | Final report. | not computable yet | One month after submission of the incident notification under point (b), which has not been recorded yet. | ## Timeline | Time | Event | Actor | Action | Payload SHA-256 | |---|---|---|---|---| | 2026-08-12T07:14:02.000Z | action_planned | lab-operator-1 | graph.session.revoke | `34a216bbc2620b3e…` | | 2026-08-12T07:14:02.000Z | policy_decided | lab-operator-1 | graph.session.revoke | `efd7c26b822b584a…` | | 2026-08-12T07:14:03.000Z | approval_requested | lab-operator-1 | graph.session.revoke | `c75792737c7c823b…` | | 2026-08-12T07:19:48.000Z | approval_granted | lab-operator-2 | graph.session.revoke | `ac2733079088ff57…` | | 2026-08-12T07:19:50.000Z | action_executed | lab-operator-1 | graph.session.revoke | `13ff1ebeb02f8fdd…` | Payload contents are deliberately not reproduced here. Only their SHA-256 hashes appear, so this file can be checked against the chain without carrying the data it describes. ## Verifying this record The line above says the chain is verified. That is our word for it, and on its own it is worth what any vendor saying so is worth. These are the values that let you check it without us. - Chain head: `d6c97d78171a3fde75b560cd10c04cf3791df6dbb92d0f347d46dc255775b782` - Events: 5 | # | Event | Entry hash | |---|---|---| | 0 | action_planned | `4702390edb2f3f6baee6c6165f355af76ea65b4e146cb0189df50946c25b76d1` | | 1 | policy_decided | `e9ee874584061b0709f13e85f2dd0ad7e72c689b6ec72297a7576c070372c6d6` | | 2 | approval_requested | `fdaf0fc4ca89d0a97f52cc75d71ec7fadd80e4fde70a3af97054876f17040a49` | | 3 | approval_granted | `ca46f2519d6736fdbc8045ce4e4a4feb499bc26ec02bfdd578422660fdaa1226` | | 4 | action_executed | `d6c97d78171a3fde75b560cd10c04cf3791df6dbb92d0f347d46dc255775b782` | Each entry hash binds the one before it, so an edited field, a deleted event or a reordering breaks every link from that point on. Ask for the evidence bundle that accompanies this file. It is a JSON export carrying these hashes and the algorithm that produced them, and it ships with a verifier you can run. You can also write your own: it is SHA-256 over eleven named fields joined by a NUL byte. **What that check establishes, and what it does not.** A passing chain shows nothing in this record was altered after it was written. It does not show who wrote it: a hash chain carries no signature, so it cannot by itself distinguish this record from a consistent one made up by anyone with a SHA-256 implementation. Corroborate it against your own tenant audit log, which is the independent source. ## Open items - Article 33(3)(a) is missing the categories and approximate number of records. - Article 33(3)(c) has no content yet. - Whether the organisation is in scope of NIS2 is undetermined. > This file records what one system did and when. It is not legal advice, and it does not assert that any notification duty applies to this organisation. That determination is the controller's.