One framework, three regulators, three severity scales
A diversified group (EUR 6bn revenue) has three business units: German insurance, subject to works council co-determination and strict consultation before employee monitoring; a Brazilian retail bank under LGPD, where the local regulator expects notification within three working days; and Singapore logistics under the PDPA, with no general breach notification duty. Each unit runs its own severity scheme - P1 to P4, Sev1 to Sev5, and red/amber/green - and its own incident register in a different tool. A Manila-based managed security provider monitors all three under three contracts with differing escalation clauses, and its playbooks assume it can isolate any endpoint without local approval. The group CISO owns policy but not BU operations; BU CIOs own their budgets. Last year a group-wide credential-stuffing campaign was recorded as three unrelated low-severity incidents, and the group board learned about it from a regulator. The CISO must deliver one incident management framework by Q4, with no group-wide ticketing replacement funded.
1. What should be standardised at group level and what should remain local, and why?
Read the worked answer
Standardise what must be comparable:
- Definitions and the event/incident/near-miss boundary. Three vocabularies turned one campaign into three unrelated low-severity entries.
- One five-level severity scale defined on impact dimensions - client and financial, regulatory, safety, reputational, number of records - rather than local intuition. Retain local labels as aliases so units are not publicly overruled.
- Mandatory escalation triggers and maximum times: any suspected regulated-data exposure, any incident above a value threshold, any matter likely to reach a regulator or the press must be visible to the group function within one hour of BU declaration.
- Minimum register data fields, role definitions (incident manager, severity owner, legal contact) and review cadence.
- A common cause-and-control taxonomy; without it, cross-unit trend analysis is impossible.
Leave local:
- Notification content, timing and regulator relationship - LGPD's three days, PDPA's absence of a general duty, German expectations. Set a group minimum and let local law set the rest.
- Technical playbooks, provided they conform to the common escalation triggers.
- Reporting language and the local HR and works council procedure.
Reasoning. The board failure was not local autonomy; it was the absence of a comparability and visibility layer. Standardise the interfaces and the vocabulary. Do not attempt to standardise every runbook from the centre, because you have policy authority but neither operational authority nor a tooling mandate.
2. How would you allocate decision rights between the incident manager, BU CIO, group CISO, legal, and the works council? Address the provider's 'isolate without approval' clause.
Read the worked answer
Allocate by decision type, not by hierarchy.
- Incident manager - one named person per shift, group-qualified: declares severity, directs containment within agreed playbooks, owns the register entry and timeline. Authority to isolate a server or block a domain without BU approval; no authority to stop a business line.
- BU CIO - authority to stop a business process, accept downtime, and authorise restoration. The expensive operational decisions sit here.
- Group CISO - owns the framework, severity definitions, escalation triggers and assurance; can require declaration but does not direct the BU's remediation.
- Legal and compliance - own the notification decision and its timing; the incident manager supplies facts, legal decides.
- Works council (Germany) - consultation is required before monitoring employee endpoints or activity, not before isolating an infected machine from the network. Write that distinction explicitly into the playbook, with a named contact and a target turnaround, or a German incident stalls while Manila waits.
The provider clause. Split the action. Isolation of a host from the network is pre-authorised 24/7 under a written delegation, logged, and notified to the BU incident manager within 15 minutes. Anything that stops a production service, wipes a device, or touches employee monitoring needs BU or works council sign-off. Put that delegation into a single contract schedule appended to all three agreements - the inconsistency between the three contracts is itself the risk.
3. Design a minimal group register and reporting mechanism given that no single tool will be funded.
Read the worked answer
A controlled spreadsheet or shared low-code list is sufficient if the fields and workflow discipline are right. Visibility, not technology, was the failure.
Mandatory fields (about 15): group ID; business unit; detected, reported and declared timestamps; detection source; one-line description; affected assets and records; severity with dimension scores; incident manager; status; regulatory exposure (yes/no/unknown); containment timestamp; closure timestamp; root-cause category; linked corrective action IDs.
Mechanism:
- Each unit keeps its own tool as the system of record for detail; it pushes a row to the group register at declaration and at every severity or status change. A rules-based export or a ten-minute manual entry is acceptable at this scale.
- A weekly 30-minute group synchronisation call over the register: new incidents, overdue actions, cross-unit patterns. This is precisely where a credential-stuffing campaign spanning three units would surface.
- A monthly one-page report to the group risk committee: counts by severity and unit, time to declare, corrective actions past due.
- A quarterly reconciliation: sample BU tickets against the group register to detect under-reporting, and publish the gap.
Guardrail. The register must not become the place where incidents are managed. It is a visibility and assurance instrument; if teams start treating it as their primary workflow it will be abandoned. Keep it thin and make the weekly call the accountability mechanism, not the spreadsheet.