# 7.3 Response and Recovery Performance Review

# Goals

The response and recovery performance review evaluates how well the company handled the incident after it was detected.

Root cause analysis looks at why the incident happened. This section looks at how well the company responded, contained the damage, communicated, restored operations, and returned the business to a safe working state.

The goal is not to criticize individuals. The goal is to improve the process.

A company should ask:

• Did we detect the incident quickly enough?
• Did the right people know what to do?
• Was evidence preserved?
• Was containment fast and controlled?
• Was communication clear?
• Did outside support work as expected?
• Were systems recovered safely?
• Did business operations return in the right order?
• What slowed us down?
• What should we improve before the next incident?

# Step 1: Review Detection Performance

Start by reviewing how the incident was detected.

Determine whether the first warning came from an employee, monitoring tool, MSP, vendor, customer, bank, external party, law enforcement, insurer, or attacker message.

Ask:

• Was the incident detected internally or externally?
• Was it detected early enough to reduce damage?
• Were the right logs and alerts enabled?
• Did alerts go to a monitored destination?
• Were alerts reviewed quickly?
• Were employee reports handled correctly?
• Were there earlier warning signs that were missed?
• Did the company have enough visibility to understand what happened?

If detection was delayed, identify whether the issue was missing logs, weak alerting, poor ownership, unmonitored inboxes, employee uncertainty, vendor delay, or lack of monitoring coverage.

# Step 2: Review Triage and Classification

Review how the company handled the first report or alert.

Ask:

• Was an incident record opened quickly?
• Was an owner assigned?
• Was the first evidence preserved?
• Was the affected scope identified correctly?
• Was the incident still active when triage began?
• Were the right technical facts collected?
• Was severity classified correctly?
• Was severity updated when new facts appeared?
• Was the issue escalated at the right time?

If triage was slow or inaccurate, identify whether the company needs better intake forms, clearer severity levels, better evidence handling rules, more training, or a stronger handoff from Detect into Respond.

# Step 3: Review Containment Performance

Review whether containment reduced the immediate risk.

Ask:

• Were compromised accounts secured quickly?
• Were suspicious sessions revoked?
• Were affected devices isolated where needed?
• Were malicious mailbox rules, forwarding, or OAuth apps removed?
• Was public data exposure stopped?
• Were unsafe remote access paths closed?
• Were backups protected?
• Were vendor accounts reviewed or suspended where needed?
• Were containment actions verified?
• Were containment actions recorded?
• Did containment create unnecessary business disruption?

Containment should be judged by whether it stopped further damage while preserving evidence and avoiding unnecessary disruption.

# Step 4: Review Evidence Handling

Review whether evidence was preserved and handled properly.

Ask:

• Were suspicious emails, logs, screenshots, alerts, files, URLs, timestamps, and user statements preserved?
• Were devices wiped, rebuilt, or changed before evidence needs were considered?
• Were logs retained long enough?
• Was evidence stored in a controlled location?
• Was access to evidence restricted?
• Were major actions and decisions recorded?
• Was there enough evidence to support root cause analysis, insurance review, legal review, customer questions, or regulatory review if needed?

If evidence was missing, identify whether the company needs better logging, retention, evidence handling rules, incident records, or staff training.

# Step 5: Review Communication and Escalation

Review how communication worked during the incident.

Ask:

• Was leadership notified at the right time?
• Were employee instructions clear?
• Were customers, vendors, or partners contacted appropriately where needed?
• Was communication controlled and approved?
• Were messages factual and consistent?
• Were unsafe channels avoided if email, chat, or identity systems were affected?
• Were legal, insurance, compliance, MSP, vendor, or external responders contacted at the right time?
• Were communication decisions recorded?

Poor communication can increase operational damage, customer concern, legal exposure, and internal confusion. This review should identify where the communication process needs to be clearer.

# Step 6: Review Eradication and Stabilization

Review whether the cause of the incident was removed before recovery began.

Ask:

• Was attacker access removed?
• Were compromised credentials, tokens, keys, and sessions handled?
• Were persistence mechanisms removed?
• Was the exploited weakness patched or mitigated?
• Were affected email, cloud, SaaS, website, endpoint, server, and vendor access areas reviewed?
• Were high-risk systems rebuilt instead of only cleaned where appropriate?
• Were backups checked before use?
• Were core security controls stabilized?
• Was post-eradication monitoring started?

If recovery began before eradication was complete, identify why and whether leadership knowingly accepted the risk.

# Step 7: Review Recovery Performance

Review whether recovery restored operations safely and in the right order.

Ask:

• Was there a recovery lead?
• Were recovery priorities based on business impact?
• Were dependencies understood?
• Were trusted restore sources used?
• Were systems restored in the right order?
• Were high-risk systems rebuilt where needed?
• Was access restored in stages?
• Were credentials rotated where needed?
• Were integrations and vendor access reviewed before restoration?
• Were backups confirmed after restoration?
• Were restored systems monitored closely?

Recovery should be judged by whether the company restored operations without restoring the incident.

# Step 8: Review Business Continuity

Review how well the business kept operating during the incident and recovery.

Ask:

• Which processes stopped?
• Which processes continued?
• Which temporary workarounds were used?
• Were workarounds approved and controlled?
• Were customer commitments affected?
• Were payments, payroll, orders, customer support, production, or service delivery delayed?
• Were manual records created and reconciled later?
• Were unsafe workarounds used, such as personal email, unmanaged file sharing, shared passwords, or uncontrolled spreadsheets?
• Were workarounds ended when normal systems returned?

Business continuity review helps the company improve its ability to operate safely during future disruptions.

# Step 9: Review External Support and Vendor Performance

Review how external parties performed.

Include MSPs, IT providers, SaaS vendors, cloud providers, hosting providers, backup providers, domain registrars, DNS providers, endpoint protection vendors, legal counsel, cyber insurance contacts, and incident response providers.

Ask:

• Were the right contacts available?
• Was support timely?
• Did vendors provide needed logs and records?
• Were escalation paths clear?
• Were contracts or support plans sufficient?
• Did the MSP or vendor understand their role?
• Were any vendor delays or access limitations a problem?
• Does the company need updated support terms, better contacts, stronger service levels, or alternate providers?

Many SMEs depend heavily on vendors during incidents. Vendor performance should be reviewed directly.

# Step 10: Record What Worked, What Failed, and What Needs Improvement

Summarize the review in three categories.

What worked well:

Examples may include fast employee reporting, effective MFA, good backup availability, quick MSP response, useful logs, clear leadership decisions, successful containment, or safe recovery.

What did not work well:

Examples may include missing logs, unclear ownership, delayed escalation, poor evidence preservation, outdated contact lists, backup uncertainty, weak vendor support, noisy alerts, poor documentation, or unsafe workarounds.

What needs improvement:

Convert findings into specific improvement actions for the next Review subsection.

Each improvement should have an owner, due date, expected result, priority, and leadership approval where needed.

# Performance Review Areas

Use these areas to structure the review:

• Detection
• Employee reporting
• Alert handling
• Triage
• Evidence handling
• Incident classification
• Containment
• Communication
• Leadership escalation
• Legal, insurance, or compliance escalation
• External technical support
• Vendor support
• Eradication
• Backup readiness
• Recovery priority
• System restoration
• Business process validation
• Temporary workarounds
• Documentation
• Decision tracking

# Simple Performance Rating

Use a simple rating for each area:

• Strong: Worked as intended and needs only minor improvement.

• Acceptable: Worked, but with some gaps or delays.

• Weak: Worked partially and needs clear improvement.

• Missing: No defined process, owner, evidence, or working control.

• Unknown: Not enough information to judge.

This rating should not be used to blame teams. It should help prioritize improvement work.

# Response and Recovery Performance Review Template

Use a simple template with these fields:

• Incident ID
• Review date
• Review owner
• Area reviewed
• What happened
• What worked well
• What did not work well
• Evidence available
• Delay or gap identified
• Business impact
• Root cause link
• Improvement needed
• Priority
• Owner
• Due date
• Leadership approval required
• Status

# Questions for Leadership

Leadership should be able to answer:

• Did we know who was in charge?
• Did we understand the business impact quickly enough?
• Did we make decisions at the right level?
• Did we communicate clearly?
• Did we have the right vendors and support?
• Did we spend too much time because of missing preparation?
• Did recovery priorities match business needs?
• What investment or policy change is now justified?

# Questions for IT, MSP, or Technical Owners

Technical owners should be able to answer:

• Were the right logs available?
• Were alerts useful?
• Was containment effective?
• Were credentials and sessions handled correctly?
• Were affected systems fully reviewed?
• Were backups clean and usable?
• Were systems restored safely?
• Were security controls working after restoration?
• What technical gaps slowed response or recovery?

# Questions for Business Process Owners

Business owners should be able to answer:

• Could the department continue operating?
• Were temporary workarounds clear and controlled?
• Was important data available?
• Were customers or vendors affected?
• Did restored systems support the real business process?
• Were manual records reconciled?
• What would help the department recover faster next time?

# Expected Outputs from This Section

At the end of this section, the company should have:

• A review of detection performance.
• A review of triage and classification.
• A review of containment performance.
• A review of evidence handling.
• A review of communication and escalation.
• A review of eradication and stabilization.
• A review of recovery performance.
• A review of business continuity.
• A review of external support and vendor performance.
• A list of what worked well.
• A list of what failed or slowed the response.
• A list of performance gaps ready to become improvement actions.

# Objective

A response is not successful only because the incident ended.

A company should leave this section able to say:

“We know how well we performed under pressure, where the response slowed down, where recovery was harder than expected, and what must change before the next incident.”

That is response and recovery performance review.

---