CISM Incident Response Planning, Classification and Testing

Incident management readiness is the work an organization does before an incident so that it can respond quickly, consistently and with authority when one happens. In CISM domain 4A it starts with three things this lesson covers: an incident response plan that is approved and aligned with the business continuity and disaster recovery plans, a classification and categorization process that says what kind of incident it is and how much it matters, and a response team that is organized, trained, equipped and tested.

The CISM view is a manager's view. The information security manager establishes and maintains the plan, designs the classification scheme, organizes the team and makes sure the plan is tested at planned intervals. Senior management approves the plan and the authority it grants; business owners say what their processes and data are worth; the response team carries out the work. A recurring theme is that readiness gaps are usually closed where they start: in the definition, the criteria, the plan or the authority behind it.

Three neighbouring areas have their own lessons: the business impact analysis and the continuity and recovery plans themselves (the rest of 4A); detection tools, investigation and containment methods (4B); and incident communications, eradication, recovery and post-incident review (4B). This lesson covers the plan's link to continuity, not continuity planning itself.

A security event is any observable occurrence in a system or network; a security incident is an event, or series of events, that compromises or threatens the confidentiality, integrity or availability of information. Most events are not incidents. An antivirus alert for a file that was blocked, or a firewall denying a connection, is an event; malware that runs and encrypts a file share is an incident. The organization's documented definition of an incident, with criteria and examples, is what lets help desk, monitoring and business staff decide consistently what enters the incident process.

A poor definition fails in two directions, and in both the lasting fix is the definition itself:

• Too broad in practice. When there are no criteria separating events from incidents, routine noise is passed to the response team, which then has less time for the incidents that matter. The volume is a symptom; the missing decision criteria are the cause.
• Too narrow in people's minds. When staff understand "incident" to mean a hacker attack, exposures from other causes go unreported: a box of paper files left on a train, a contractor's file share left open to the internet, a supplier's leak of the organization's data. The definition should cover any compromise or exposure of information, whatever the cause: accidental, physical, insider or third-party, as well as malicious attacks.

The definition belongs in the incident response plan and is applied everywhere, including subsidiaries, business units and service providers that report incidents to the organization.

An incident response plan is the documented, management-approved set of procedures, roles and authorities the organization follows to detect, respond to and recover from information security incidents. Its value in a crisis comes from two things: it has been decided in advance, and it carries management's authority. Good content alone does not make people follow a plan when departments disagree under pressure; formal approval by senior management is what gives it standing and resources.

A sound plan typically contains:

Pre-approved authority is what makes a fast response possible. Containment often cannot wait for the right owner to be found and convinced. The plan therefore states which defined actions, such as disabling an account, blocking a network segment or taking a system offline, the team or incident manager may take at each severity level. Knowing whom to call is not the same as being allowed to act. Because these actions can stop business operations, the authority is approved by the senior managers accountable for those operations, with clear thresholds, and it applies to critical systems too, since that is where speed matters most. Approval given in advance also settles the argument afterwards: the business agreed to the authority before it was used.

The incident response plan must be aligned with the business continuity plan (BCP) and disaster recovery plan (DRP): each plan keeps its own job, and the handover between them is defined. The response plan deals with the security incident: triage, containment, eradication and evidence. The BCP keeps critical business processes running, and the DRP restores technology. A serious incident, such as a destructive attack on a warehouse management system, can become a business disruption while the response team is still working on it.

The weak point between unaligned plans is that handover. Plans written separately and never cross-referenced have no agreed criteria, contacts or decision points for invoking continuity and recovery. The usual result is that recovery starts late: the response team does its own job well, and nobody decides in time that the business disruption needs the other plans. Inconsistent contact lists or role names are lesser symptoms of the same lack of alignment.

The fix is in the response plan itself: impact-based triggers for invoking the BCP or DRP, expressed in business terms (for example, how long a critical process has been unavailable compared with what it can tolerate), together with the contacts and responsibilities at the handover. The plans stay separate documents with cross-references; they are not merged or copied into each other. The BIA itself, and how recovery objectives are set, are covered in the continuity lesson.

When a provider hosts, operates or monitors part of the organization's services, the response plan must cover that provider: who to contact, who at the provider can approve which actions, what the provider must escalate, and how the two teams work together. The organization stays accountable for the incident even when the systems are someone else's.

• Contact is not authority. A phone number gets a ticket opened; it does not get a decision made. The plan should name the provider roles that can approve containment and recovery actions on the organization's behalf.
• Escalation follows the organization's impact. A provider sees its own platform and its own severity scale; it cannot know which of a customer's systems support critical business processes unless it is told. Escalation criteria based on the organization's business impact are agreed in advance and written into both the plan and the contract.
• Exercise jointly. Contract terms, reports and documents give assurance and leverage, but readiness comes from rehearsal. Joint exercises test the handoffs, communications and shared decisions between the two teams.

Bringing in a provider for important data or services is itself a significant change for the plan, because it changes responsibilities, contacts, evidence access and containment options.

Incident classification answers two separate questions: category says what kind of incident it is, and severity says how much it matters to the business. Category (for example malware, credential compromise, data loss, denial of service) points the team at the right procedure and skills. Severity sets priority, resources and escalation. Keeping them as separate fields means each can be right on its own.

Severity is assigned by business impact, not by technical features. The sophistication of the attack, the number of alerts, the suspected threat actor, the incident type or a vulnerability score are useful facts for investigation, but none of them says what this incident does to this organization. The same malware on a lobby information kiosk and on the server that holds signed customer contracts is one category and two very different severities. A scheme that derives severity from a technical attribute will rate some incidents too high and others too low, and patching individual cases does not stop it; rating each incident from its impact does.

Because the two dimensions are independent, a correct category says nothing about whether the severity is right, and each is checked against its own basis.

Each severity level should carry predefined actions: who is notified, how quickly, which response steps apply and what authority the team has. Without them, people decide on the spot whether to involve management, and senior management tends to hear about high-impact incidents late.

Classification follows the facts. An incident is classified first on limited information, and the process expects reclassification. When new facts change the impact, for example an incident first logged as a lost USB stick turns out to involve unencrypted payroll data, the classification is updated immediately and the notification and response steps for the new level apply from that point. The incident stays one record with a changed classification.

One organization needs one severity scale. Severity ratings are only comparable, and escalation only consistent, when every unit rates against the same impact-based criteria at the time it classifies. Local teams can still handle their own incidents; what they share is the scale. The same applies to service providers, whose escalation must reflect the organization's impact criteria.

The incident response team is organized to fit the organization, trained for its roles and equipped before an incident: its structure, sourcing and composition follow the organization's size, spread and skills and the type of incident. Common team models are:

Outsource the work, never the accountability. A managed security provider adds speed and coverage, but decisions that disrupt the business belong to the organization. The plan and contract say which actions the provider may take on its own and which, on critical systems, need the organization's approval first, so the provider stays fast on routine containment without making business decisions. The incident manager role, which makes those decisions, stays with the organization; handing it to a party that is not accountable for the business is the most serious outsourcing risk. Practical concerns such as onboarding, capacity and tooling are real but manageable through contract terms.

Composition depends on the incident. A core technical team is not enough for every case. Incidents involving the conduct of employees or contractors bring in human resources for the employment process and legal counsel for evidence handling and legal obligations. Business owners, communications staff and technical specialists join as the incident requires. Internal audit is not a member: it stays independent so that it can review the response afterwards.

One incident, one person in charge. The plan names a single incident manager with authority, defined in advance, to direct responders. Specialists such as legal counsel, technical leads and communications advise the incident manager, who decides; responders take direction from one place.

Training and equipping cannot be arranged during an incident. Technical skill is not the same as response experience. Responders also need practice at making decisions under pressure, handing work over and following the plan as a team, and the best way to build that is realistic, scenario-based exercises in which each member performs their assigned role.

Equipping means the access, tools and resources the team needs, arranged before they are needed: controlled privileged access to the systems responders must examine, forensic and evidence-capture tools, an out-of-band communication channel in case normal email or chat is compromised, and current contact and escalation details. When an exercise exposes a missing capability of this kind, providing it in advance is the first fix. Access granted for incident response is itself controlled and monitored.

Incident response plans are tested at planned intervals with methods that range from discussion-based reviews to live operational tests, chosen by what the test must prove and how much disruption the organization can accept. The primary purpose of testing is to find gaps in the plan and in the team's ability to apply it; other outcomes, such as evidence for auditors, are by-products.

Parallel and full interruption tests are recovery tests: they are normally run with the business continuity and disaster recovery plans (covered in the continuity lesson), and incident response takes part through the handover.

Start simple and build up. A new plan is first tested with low-risk, discussion-based methods, which find gaps in content and understanding cheaply. Operational tests come later, once the plan and the team are mature enough that a failure tells you something about capability rather than about a draft.

Match the test to two constraints. The first is what must be proved: discussion shows understanding, while capability needs people to perform. The second is what disruption is acceptable: when live services must not be put at risk, tests that touch production are excluded regardless of timing. Where both constraints apply, a test that performs the work away from production is the one that fits.

A test is only useful when it has defined objectives, its results are analysed for root cause, and the findings change the plan, the classification scheme or the training. A missed target is a symptom; the review asks why it was missed. If people followed the plan and still failed, the defect is in the plan or its criteria, and that is what gets changed. For example, if an exercise shows the on-call list was wrong because no one owns it, the fix is to assign ownership and a review step, not to remind people to check it.

Tests that never fail while real incidents do are testing the wrong things. Exercise scenarios should reflect current threats and the organization's real weaknesses, and each exercise should have objectives it can pass or fail. Repeating an exercise that finds nothing does not change what it measures.

The plan is reviewed at planned intervals and whenever a significant change occurs. Scheduled reviews catch drift late, however often they run. Significant changes to the business, technology or threat environment trigger a review between schedules: mergers, acquisitions and divestments, outsourcing or moving important services to a provider, reorganizations, new regulations and new critical systems. Changes that do not alter how an incident would be handled, such as like-for-like hardware replacement, do not. The most reliable way to catch the changes that matter is to build incident plan review into the organization's change management, so that significant changes cannot be approved without considering the plan.

When a change has already left the plan out of date, update the plan first (scope, contacts, priorities, authority) and then test the updated version; testing a plan known to be wrong mostly confirms what is already known. One organization's network is best served by one plan with one line of command.