CIM - Preparation: People

Defining Roles & Responsibilities

Who does what when the alarm sounds

Imagine a hospital emergency room without clear roles. No triage nurse, no attending physician, no one knowing who handles what. Chaos would ensue, and patients would suffer. The same applies to incident response. Clear roles aren't bureaucracy: they're the difference between coordinated action and confused paralysis.

At the center of any incident response is the Incident Commander (IC). This is your conductor, the person who ensures everyone is pointed in the right direction and staying in their own lane. The IC must be both a manager and a leader. Management is about getting the work done, tracking progress, and keeping the team moving. Leadership is about inspiring confidence, making decisions under pressure, and ensuring the team has everything they need to succeed.

The IC needs support. A Scribe might sound old-fashioned, but this role is so important it ranks above the deputy IC. The scribe is dedicated to creating meeting minutes, recording decisions, arranging calls and rooms, and drafting reports and diagrams. Every meeting, every call, every decision point needs documentation. During an incident, memories become unreliable and details get lost. The scribe is your organizational memory, and their meeting minutes become the authoritative record of what happened and why.

A Deputy IC extends your coverage, whether that means early and late shifts, or a true follow-the-sun model for global organizations. For longer incidents, having someone who can step in while the primary IC rests is essential for maintaining pace without burning out your leadership.

Project Managers serve both the incident management (IM) team and the incident response (IR) team. For IM, they update dashboards and track tasks. For IR, they track which systems have been worked on, what indicators of compromise have been found, and which logs have been processed. This tracking becomes invaluable when executives ask for status updates or when you need to demonstrate what's been done.

The Incident Response Team itself typically includes specialists: malware reverse engineers, forensic analysts for desktops and servers, network forensics experts, and log analysts. Not every organization has all these skills in-house, and that's fine. What matters is knowing ahead of time who you'll call when you need them.

Finally, don't forget the supporting cast: executive liaisons who can get you access to the board, HR representatives who understand employment implications, legal counsel who can advise on notification requirements, and PR professionals who can help manage external communications.

The RACI Matrix

Who's responsible, accountable, consulted, and informed

Knowing your roles is one thing. Knowing who does what for each specific task is another. A pre-defined RACI matrix removes ambiguity before the incident even starts. RACI stands for Responsible (who does the work), Accountable (who makes the final decision), Consulted (who provides input), and Informed (who needs to know).

Think of it like a restaurant kitchen. The line cook is responsible for preparing a dish, but the head chef is accountable for what goes out to the table. The sous chef might be consulted on technique, and the front-of-house manager is informed when the dish is ready. Everyone knows their role, no one steps on anyone's toes, and the customer gets their meal on time.

For incident response, your RACI should cover at minimum the high-level phases and their key activities:

Preparation Phase

• Incident Response Plan: who maintains it, who approves changes
• Tabletop exercises: who organizes, who participates, who signs off
• Routine backups: who executes, who verifies, who's accountable for restoration capability

Identification Phase

• Initial coordination: who gets the first call, who assembles the team
• Investigation: who leads the technical analysis, who provides support
• Internal reporting: who briefs executives, who informs affected business units

Containment Phase

• Isolation of affected systems: who decides, who executes
• Forensic imaging: who captures evidence, who maintains chain of custody
• Killing or blocking malicious processes: who has authority to act
• Disabling compromised accounts: who in IT, who in Identity Management
• Blocking malicious IPs and domains: who at the firewall level, who at the DNS level
• Emergency software patches: who tests, who deploys, who approves emergency changes
• External stakeholder communication: who drafts, who approves, who sends

Eradication Phase

• Malware removal: who performs, who verifies clean state
• Artifact deletion: who identifies, who removes
• System reimaging: who decides which systems, who performs the work

Recovery Phase

• Backup restoration: who executes, who validates data integrity
• Returning isolated devices to production: who tests, who approves
• Post-incident monitoring: who watches for reinfection, for how long
• Ongoing external communication: who provides updates to customers, regulators, partners 

Build this matrix before you need it. Socialize it with all stakeholders. When an incident hits, no one should be asking "Is that my job?" The RACI tells them.

The Pace: Marathon, Not Sprint

Why your team will burn out in two weeks

Here's what experienced incident responders have observed across countless incidents: when analysts and incident management staff try to surge for days on end, most don't last two weeks before burning out. That's not a character flaw. It's human biology meeting organizational pressure.

Incidents bring extra work and longer hours. Your team is fighting the attacker for control of the network while simultaneously doing their regular jobs. IT staff are asked to pull logs, patch systems, support analysis, deploy new systems, decommission old ones, and change passwords, all on top of keeping the network running. The baseline stress of a modern organization becomes the foundation upon which the incident piles even more pressure.

The solution is to plan a sustainable pace from day one. This means establishing a Battle Rhythm: a daily routine that includes a clear shutdown and handover time. When people know they're working until 6:30 PM and then handing over to someone else, they can plan their lives. They can tell their families when they'll be home. They can maintain some normalcy.

A practical daily rhythm might look like this:

Morning Block

08:45: Team arrives, admin tasks
09:00: Agile stand-up (5 minutes, no longer)
09:05 to 10:30: Focused work
10:30 to 11:00: Collaboration time
11:00 to 11:15: Planning for executive sync
11:15 to 11:30: Executive hot sync
11:30 to 12:00: Lunch break (yes, actually take it)

Afternoon Block

Repeat the focused work and collaboration pattern
16:00: Main daily update (the anchor meeting)
18:00 to 18:30: Update briefs and handover preparation
18:30: Hand over to the next shift
Repeat the focused work and collaboration pattern

This structure provides coverage from 9 AM to 10 PM with a pattern that's easy to follow and sustain. 

Written end-of-day handover briefs from one region to the next ensure nothing gets lost between shifts. These handovers don't need to be lengthy: what happened today, what's pending, what needs attention first thing tomorrow.

Before finalizing any roster or battle rhythm in your runbooks, get input from HR and possibly legal. Some jurisdictions require voluntary agreements for extended working hours. The EU Working Time Directive, for instance, has specific requirements that apply even during emergencies.

Follow the Sun vs. Centralize and Focus

Choosing your operating model

There are two main approaches to staffing an incident, and each has trade-offs.

Follow the Sun means distributing work across time zones so analysis continues around the clock. The obvious advantage is continuous progress: you can wake up to results from overnight work. However, there are significant challenges. Work can get stuck waiting for approvals or specialists who are asleep. Resources get spread thinner. Team development slows because people rarely work together. Team bonding suffers because your "colleagues" are names on a handover document rather than people you've faced adversity with.

Centralize and Focus brings the team together, either physically or virtually, during overlapping hours. The team has access to all specializations when needed. They can brief leadership and get decisions in real time. Teamwork and skill-sharing improve naturally. The team bonds through shared experience, becoming colleagues-in-arms who've faced the adversary together.

Most organizations benefit from a hybrid approach: centralized focus during core hours with a reduced follow-the-sun capability for monitoring and specific tasks that can proceed independently.

Team Welfare

Looking wfter the people who look after your business

The IC must be confident and calm in the face of a changing environment, aggressive adversaries, and potentially hostile press. By doing so, they inspire the team. An inspired team is more resilient, more responsive, and more dynamic in their methods.

But inspiration alone isn't enough. The IC must also actively look after their team, both physically and mentally. By keeping an eye on their well-being, the IC will be seen as a caring and considerate leader rather than a soulless taskmaster. When your team knows you're still looking after their interests while delivering on the mission, they will do more for you and trust you to get the best from them without putting them at risk.

What does looking after the team actually mean in practice?

Acknowledge the impact. Incidents affect people's lives. Missed family dinners, cancelled plans, disrupted sleep. Don't pretend this isn't happening. A simple "I know this is hard, and I appreciate what you're giving up" goes a long way.

Enforce breaks. People will work through lunch and dinner if you let them. Don't let them. Tired people make mistakes. Mistakes during an incident create more work. Build breaks into the schedule and make them mandatory.

Watch for signs of strain. Some team members will push themselves too hard. They'll try to prove their value or compensate for perceived failures. The IC needs to watch for this and intervene before it becomes burnout.

Address blame early. Staff can be worried that because they didn't complete all the patching last month, the attacker was able to break in. Some may even be tempted to cover up the attacker's work to avoid looking bad. Create a culture where honest disclosure is rewarded and blame is reserved for those who hide problems.

Prepare mental health support. Longer incidents can be genuinely traumatic. Consider what support resources are available through your organization and make sure people know about them.

Training and Exercises

Building Muscle Memory Before the Crisis

You wouldn't expect a firefighter to learn how to use equipment during an actual fire. The same principle applies to incident response. Training and exercises build the confidence and muscle memory that allow teams to perform under pressure.

Tabletop exercises are the foundation. These discussion-based sessions walk through scenarios without touching actual systems. They're low-cost, low-risk, and excellent for identifying gaps in plans and communication. The best method to test whether your tools and processes work for your organization is to run a tabletop exercise and see what works and what doesn't.

Think of a tabletop platform, like ERIC, as your organization's cyber fire drill platform. It's not gamification. Instead, it provides interactive, engaging, and realistic scenarios with objective-based assessments. Participants work through incidents as they would in real life, making decisions, communicating with stakeholders, and seeing the consequences of their choices unfold. The platform tracks responses against defined objectives, giving you measurable insights into where your team performs well and where they need development. This objectivity is crucial: it removes the subjectivity of "I think that went well" and replaces it with "Here's what we actually did, and here's how it compared to best practice."

Hot-seat exercises put individuals in the incident commander role while others play the parts of executives, attackers, media, and team members. This is where you discover whether someone can make decisions under pressure and communicate effectively when stressed.

Technical exercises test whether your IR team can actually perform the forensics, analysis, and remediation tasks they'll need to execute. These might involve deliberately compromised systems in a lab environment.

The goal isn't to run exercises once and check a box. It's to build experience. Experience builds confidence. Confidence inspires others to help and try harder, which increases capacity and reduces the load on key individuals. This lowers everyone's stress levels and calms the situation. Good training and experience create a positive feedback loop.

When planning exercises, set clear objectives. What are you testing? What do you hope to learn? After each exercise, conduct a thorough debrief. What worked? What didn't? What needs to change in your plans, playbooks, or team structure?

Building your Bench

Succession & Redundancy

What happens if your incident commander gets sick during a major incident? What if your best forensic analyst is on holiday when ransomware hits? Organizations need depth, not just stars.

Cross-functional representation is your starting point. Your incident response capability should draw from IT, security, legal, HR, and communications. No single department has all the skills needed for a complete response. Building relationships across these functions before an incident means you're not making introductions during a crisis.

Cross-training within your core team is equally essential. Every critical role should have at least one person who can step in. This doesn't mean everyone needs to be equally expert at everything, but there should be enough overlap that the loss of any single person doesn't cripple the response.

Availability and rotation planning ensures you can maintain coverage when incidents extend beyond normal hours. Establish on-call rotations or dedicated shifts for 24/7 coverage during active incidents. Know who's available, when, and how to reach them.

Document tribal knowledge. Those shortcuts and tricks that experienced responders carry in their heads need to be written down. Runbooks, playbooks, and knowledge bases capture institutional wisdom so it survives staff turnover.

External relationships are a critical extension of your bench:

• Third-party specialists: Incident response retainers with specialist firms mean you can call in reinforcements for digital forensics, threat intelligence, or specialized technical skills your team lacks.
• Legal counsel: Retain external counsel with expertise in cybersecurity and data privacy law. They'll guide you on compliance, disclosure requirements, and represent you in any legal proceedings.
• Law enforcement: Establish relationships with relevant agencies before you need them. This facilitates cooperation and information sharing during investigations.
• Industry collaboration: Participate in sector-specific cybersecurity forums and information sharing groups. Exchanging threat intelligence with peers keeps you informed of emerging threats.

Wrapping Up

The people side of preparation comes down to three questions: 

1. Do we know who does what? (Roles) 
2. Can we sustain the pace? (Battle rhythm and welfare) 
3. Have we practiced? (Training and exercises)

None of this requires exotic resources. It requires thought, planning, and the recognition that incidents are ultimately human events. Technology is just the battlefield. The people are what determine whether you win or lose.

With Governance, Technology, Communication, and People in place, your organization has built a solid foundation for incident response. The next posts in the Incident Management Roadmap will move from preparation into action: Detection and Analysis.

Five Questions Every C-Level Executive Should Ask

Before your next board meeting or security review, consider asking your CISO or IT leadership these five questions. The answers will tell you whether your organization is truly prepared on the people side, or just hoping for the best.

1. If our incident commander were unreachable tomorrow, does everyone know who takes over and how decisions get made?

→ Do we have a documented chain of command with named alternates? Has the deputy IC actually practiced leading a response, or would they be figuring it out in real time?

2. Can we show a RACI matrix that defines who is responsible, accountable, consulted, and informed for each phase of incident response? 

→ When containment decisions need to be made at 2 AM, does everyone know who has authority to isolate systems, disable accounts, or approve emergency changes? Or will we lose hours figuring out who needs to sign off?

3. If this incident runs for three weeks, what's our plan for sustaining the team without burning them out? 

→ Do we have shift schedules, handover procedures, and welfare support documented? Have we actually told our people what pace we expect, or are we assuming everyone will just work until they drop?

4. When did we last run an incident response exercise that tested our people and processes, not just our technical tools?

→ Tabletop exercises and platforms like ERIC give us objective, measurable insights into how our team performs under pressure. If we haven't practiced in the last twelve months, we're essentially hoping our first real test goes well.

5. Do we have incident response retainers already signed with external forensics, legal, and crisis communications specialists?

→ When a major incident hits, procurement timelines become unacceptable. Are contracts in place? Do we know who to call? Have we actually spoken to these people before, or will we be introducing ourselves during a crisis?