Summary

A design effort focused on turning cybersecurity incident management into an executable operating capability, not only a compliance document.

The goal was to structure a model that helps a team respond in an orderly way when information is incomplete and time matters:

report → record → classify → respond → preserve evidence → recover → close → learn

The work drew on incident management principles from ISO 27035 and NIST SP 800-61 Rev. 3, connecting them with concrete operational needs: roles, escalation, playbooks, evidence, communications, privacy, exercises, and indicators.

Context

An organization may have security tools, backups, and technical staff and still depend too heavily on improvisation when an incident occurs.

The difficult questions appear quickly:

  • who receives the first report?;
  • where is it recorded?;
  • when does an event become an incident?;
  • who leads the response?;
  • what severity applies?;
  • what evidence should be preserved before taking action?;
  • which operational scenario applies?;
  • when should privacy, legal, or leadership become involved?;
  • who may communicate with third parties?;
  • how is closure determined?;
  • what should change afterward?

The problem was not the absence of isolated procedures. It was the need to connect them into a coherent model for decisions and execution.

Design principle

The model was built around one simple idea:

Incident response should reduce unnecessary improvisation without replacing technical judgment.

That led to separating two types of decisions.

Those that are useful to define in advance:

  • channels;
  • roles;
  • authority;
  • severity criteria;
  • escalation paths;
  • evidence requirements;
  • communications;
  • closure conditions.

And those that necessarily depend on the incident:

  • cause hypotheses;
  • actual scope;
  • containment actions;
  • technical priorities;
  • isolation needs;
  • recovery strategy;
  • residual-risk assessment.

The process should organize the first group so the team has more capacity to apply judgment to the second.

01 — Reporting and activation

The first capability is making sure a relevant event can enter the process consistently.

Two conceptual elements were defined:

an official reporting channel and an official system of record.

The intention is to prevent important incidents from becoming scattered across direct messages, informal conversations, or individual notes.

The initial record should capture enough context to start working:

  • who reported it;
  • what was observed;
  • when;
  • the potentially affected asset, account, or service;
  • known or suspected impact;
  • actions already taken;
  • available evidence;
  • preliminary severity.

02 — Classification and severity

Not every alert is an incident, and not every incident requires the same response.

The model incorporates criteria to distinguish and escalate based on factors such as:

  • scope;
  • potential impact;
  • affected assets or services;
  • privilege level of a compromised account;
  • data involved;
  • propagation potential;
  • disruption of critical processes;
  • legal or privacy obligations.

Severity is not treated as a fixed label. It can change as new information appears.

03 — Roles, authority, and escalation

One of the most dangerous problems during a crisis is confusing participation with authority.

The model distinguishes who:

  • coordinates;
  • investigates;
  • contains;
  • authorizes sensitive changes;
  • assesses privacy or compliance implications;
  • communicates with leadership;
  • approves external communications;
  • validates recovery;
  • approves closure.

The goal is not to create a heavy structure. It is to reduce the time lost asking who is allowed to decide.

Backup roles are also considered so the process does not depend on one person.

04 — Scenario-based playbooks

A playbook library was structured for frequent scenarios, including:

  • phishing and suspicious email;
  • compromised account;
  • malware;
  • lost or stolen device;
  • information leakage;
  • ransomware;
  • service unavailability;
  • incidents involving personal data;
  • backup or restoration problems;
  • unauthorized access.

The library is not intended to cover every possible combination.

One incident may activate several playbooks at once. For example, phishing may evolve into credential compromise and later open a privacy path if the account had access to sensitive information.

The principle is:

playbooks structure the response and the evidence; they do not replace technical judgment.

05 — Timeline and evidence preservation

The response needs to be reconstructable.

For that reason, a set of operational evidence was defined across the incident lifecycle:

  • initial record;
  • timeline;
  • relevant technical evidence;
  • decisions and approvals;
  • impact assessment;
  • containment actions;
  • recovery evidence;
  • closure report;
  • lessons learned;
  • corrective actions.

The timeline acts as the backbone.

It helps explain what the team knew at each point, what it decided, who acted, and how the incident hypothesis changed.

That is useful for operations, post-incident review, and auditability.

06 — Containment and recovery

Containment is not treated as an isolated goal.

A fast action may reduce exposure but also destroy evidence, affect a critical service, or complicate recovery.

That is why the model connects:

immediate risk + evidence + continuity + recoverability.

Depending on the scenario, this may include:

  • revoking sessions;
  • isolating assets;
  • blocking indicators;
  • changing credentials;
  • disabling access;
  • preserving data before modifying systems;
  • recovering from valid copies;
  • verifying state before returning to service.

Recovery needs acceptance criteria, not only the objective of “bringing the service back.”

07 — Personal data and compliance

Incidents that may involve personal data need a specific path.

The model separates technical investigation from compliance decisions.

The technical team provides context and evidence:

  • what data may be affected;
  • what access was observed;
  • what controls existed;
  • what containment actions were performed;
  • what level of certainty exists.

The function responsible for privacy or compliance evaluates the applicable obligations and communications.

This prevents the technical team from making legal or regulatory decisions on its own.

08 — Controlled communications

Incorrect communication can amplify an incident.

The model includes criteria for communications:

  • within the response team;
  • to leadership;
  • to affected users;
  • to suppliers or third parties;
  • externally when required.

The general rule is to limit messages to sufficiently confirmed facts and ensure that third parties or external audiences receive information only through an authorized path.

Not every member of the response team should be able to communicate externally.

09 — Closure and lessons learned

Closing an incident is a decision, not an automatic status change.

Closure should verify that:

  • the threat is contained;
  • required recovery has been completed or accepted;
  • scope is reasonably understood;
  • required evidence was preserved;
  • additional obligations were evaluated;
  • pending actions have owners;
  • learning has been documented.

The post-incident review asks:

  • what worked?;
  • what failed?;
  • what was confusing?;
  • which control failed to detect or contain?;
  • which documentation needs to change?;
  • which corrective action should be opened?;
  • how will we verify that the problem was actually corrected?

10 — Exercises before relying on the process

The model includes tabletop exercises as a validation mechanism.

A scenario can begin with a small signal and introduce new information gradually to observe how the response evolves.

For example:

  1. a suspicious email is reported;
  2. the user confirms an interaction;
  3. credential compromise becomes possible;
  4. unusual authentication activity appears;
  5. possible access to sensitive information emerges.

The objective is not to evaluate people as if they were taking an exam.

It is to test the system:

  • was it reported correctly?;
  • was it recorded in time?;
  • did severity change?;
  • was the right scenario activated?;
  • was evidence preserved?;
  • were the right roles involved?;
  • was communication controlled?;
  • did closure produce improvements?

11 — Indicators that support improvement

Metrics were treated as signals of effectiveness, not numbers to fill a report.

Useful dimensions include:

  • events reported;
  • incidents confirmed;
  • distribution by severity;
  • time to record;
  • time to contain;
  • time to close;
  • incidents involving personal data;
  • corrective actions opened and closed;
  • recurring scenarios;
  • exercise results.

The objective is to turn operational experience into decisions:

  • strengthen controls;
  • modify playbooks;
  • improve training;
  • adjust escalation;
  • improve visibility;
  • test recovery;
  • close documentation gaps.

Role

My work in this initiative focused on:

  • structuring the operating model;
  • connecting governance and technical response;
  • defining the logic for reporting, recording, and escalation;
  • organizing scenarios into playbooks;
  • designing evidence and traceability;
  • incorporating the privacy and compliance path;
  • structuring communications and closure;
  • defining exercises and effectiveness indicators;
  • preparing the model for internal socialization and progressive improvement.

Result

The result was an operational architecture that helps move from a collection of documents to a more consistent and verifiable response.

The most important conceptual improvement was changing the question from:

“do we have an incident response plan?”

to:

“can the team activate, execute, document, and improve the response when information is incomplete?”

That shift turns documentary compliance into a conversation about capability and resilience.

Lessons learned

  • response is prepared before the incident;
  • clear roles reduce time lost under pressure;
  • the system of record is operational memory, not bureaucracy;
  • playbooks should guide without replacing judgment;
  • evidence preservation requires prior design;
  • privacy, legal, and communications need explicit paths;
  • technical closure does not mean all work is finished;
  • an exercise reveals ambiguity that documentation does not;
  • metrics create value when they trigger an improvement decision;
  • resilience improves when each incident leaves the organization with a stronger capability than before.