# 5.1 Incident Response Ownership and Activation

# Goals

Incident response should not begin with confusion over who is in charge.

This section defines who leads the response, who supports them, who makes business decisions, and what types of events activate the response process.

The goal is simple: when a serious security issue appears, the company should know who takes charge and when the incident response process begins.

# Step 1: Assign the Incident Response Lead

Name one person responsible for coordinating the response.

This may be an internal IT lead, security lead, operations manager, senior manager, MSP contact, or other assigned owner.

The incident response lead is responsible for organizing the initial response, assigning actions, tracking decisions, coordinating with technical support, and escalating to leadership when needed.

Also assign a backup lead.

# Step 2: Define the Response Team

Identify the people who may need to support an incident response.

Include:

• Incident response lead
• Backup response lead
• Executive decision-maker
• Internal IT contact
• MSP or external IT provider
• Legal or compliance contact
• Cyber insurance contact
• Communications owner
• HR contact, if employee data or insider activity may be involved
• Finance contact, if fraud, invoice changes, payroll, or payments may be involved
• Business process owner for the affected system or department

Each person should know their role before an incident happens.

# Step 3: Create a Response Contact List

Create a contact list that can be accessed during an incident.

Include names, roles, phone numbers, email addresses, after-hours contact methods, vendor support details, insurance policy contacts, legal contacts, and backup contacts.

Store this list somewhere available even if email, cloud storage, or the main network is unavailable.

Review it regularly - an incident contact list that only exists inside a compromised system may not be useful when needed.

# Step 4: Define Activation Triggers

Define which events activate the incident response process.

Activation triggers should include:

• Confirmed malware
• Ransomware signs
• Compromised email account
• Unauthorized admin access
• Suspicious MFA approval
• Password entered into a fake login page
• Fraudulent payment or bank detail change
• Sensitive data sent to the wrong person
• Public exposure of confidential data
• Lost or stolen device containing company data
• Former employee access
• Vendor or MSP account abuse
• Backup deletion or backup tampering
• Domain, DNS, website, or cloud account compromise

Serious incidents should not sit in normal IT support queues.

# Step 5: Define Who Can Activate Response

Decide who has authority to activate the response process.

This should include the incident response lead, backup lead, executive sponsor, IT lead, MSP lead, or another named role.

Employees should not need to classify incidents themselves. They only need to report quickly.

The response owner decides whether the issue stays in triage or moves into active response.

# Step 6: Record the Activation Decision

When the response process is activated, record the decision.

Capture:

• Date and time
• Who activated the response
• What triggered activation
• Systems, users, or data involved
• Initial severity
• Immediate actions assigned
• People notified
• Evidence location

This creates a timeline and prevents confusion later.

# Expected Outputs from This Section

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

• A named incident response lead.
• A named backup response lead.
• A defined response team.
• A response contact list.
• Clear activation triggers.
• Named roles authorized to activate response.
• A simple record of each activation decision.

# Objective

Response starts with ownership.

A company should leave this section able to say:

“When a serious security issue appears, we know who takes charge, who must be contacted, and what triggers the response process.”

That is incident response ownership and activation.

---