Prepare before the 3am decision

Cyber incidents do not stay inside the security team. They become leadership, operational, legal, customer, commercial, communications and recovery problems at the same time.

Assume breach, prepare deliberately

“Assume breach” is not a prediction that an incident is inevitable, nor an argument that prevention does not matter. It is a preparedness mindset: work from the possibility that a control may fail, an attacker may gain access or an incident may already be developing when the organisation first becomes aware of it.

Starting from that position changes the quality of preparation. Roles can be agreed in advance, escalation paths understood, decision authority made clear and playbooks rehearsed before people are working under pressure. Every incident will still be different, but the less that has to be invented during the worst moments, the more capacity people have for the genuinely unexpected.

The Cybersecurity Incident Manifesto

This thinking is why JandaSec created The Cybersecurity Incident Manifesto.

A deliberate nod to the Agile Manifesto, it distils lessons learned from managing real-world cyber incidents — including data breaches, ransomware, business email compromise and financial fraud — into practical principles for how organisations should prepare, decide, communicate and recover when an incident becomes real.

The emphasis is on preparedness over reaction, urgency over panic, evidence over speculation, collaboration over isolation and resilience over perfection. The aim is not to script every incident. It is to establish the behaviours, decision-making principles and operating discipline that reduce unnecessary improvisation when people are under the greatest pressure.

Explore the Cybersecurity Incident Manifesto →

Match-fit for the worst day of the job

JandaSec helps organisations prepare before that pressure arrives: clear roles, usable plans, escalation, decision authority, communications, cyber and BCDR dependencies, recovery priorities and rehearsals that test assumptions while there is still time to change them.

Advanced exercises can introduce timed injects, incomplete information and changing conditions to test how executives, technical teams and other stakeholders actually make decisions together.

Exercises can introduce realistic injects — new facts, changing circumstances, customer pressure, media interest, regulatory questions, technical setbacks or recovery constraints — so the organisation has to respond as the situation develops rather than follow a scripted walkthrough.

One example: It is now 04:30. Your lead engineer has been working continuously for 17 hours and is still the only person with deep knowledge of the affected platform. What do you do?

That kind of inject tests deputies, knowledge concentration, handovers, documentation, access, external support, executive judgement and whether the response can be sustained.

A strong rehearsal should test whether the response can be sustained, not just whether it can be started.

The objective is not to catch people out. It is to expose uncertainty, conflicting assumptions and unclear authority while there is still time to improve them.

Rehearse the whole response team

Incident response is not owned by the security team alone. JandaSec encourages rehearsals to include the wider leadership group — CEO, COO, CFO, CTO, CRO, CPO and other relevant executives — because the most important decisions in a serious incident quickly become business decisions rather than purely technical ones.

Not every leader needs to think about security every day. That is the security function’s job. But when an incident happens, senior leaders need to know the plan, understand their role, know where critical information and contact details are held, and know which decisions they may be expected to make.

Different executives bring different responsibilities. The CFO may need to engage insurers and make financial decisions; the CEO may need to manage customers, investors or parent-company stakeholders; the CTO may coordinate technical recovery; and the CPO or HR lead can help protect the welfare and sustainability of the people carrying the response.

Rehearsals should also include important external parties where appropriate: SOC providers, incident-response specialists, cyber insurers, legal advisers, communications partners, investors or parent-company contacts.

The first time people meet, exchange numbers and work out who does what should not be during a real incident. Otherwise, valuable time is being spent improvising the basics when attention should be on containing the incident, making decisions and protecting the business.

Those relationships can be established in advance, authority clarified and communication paths tested before time becomes a constraint.

Micro-rehearsals: test the small things

Incident readiness does not have to mean a large annual or biannual exercise. Short, focused micro-rehearsals can test individual parts of the response plan regularly — often in 10 or 15 minutes.

Regular fire drills are normal because people should not be working out exits, responsibilities and escalation for the first time during a real fire. Cyber and business-continuity micro-rehearsals follow the same philosophy.

They do not replace larger tabletop exercises. They complement them by keeping the plan familiar, exposing small failures early and building practical response muscle memory over time.

• Can the CFO contact the cyber insurer, and can the nominated deputy do the same?
• Do they know the claims process, and is the necessary authority already in place?
• Can the CTO contact the SOC directly if the CISO is unavailable?
• Does the CEO have the right investor or parent-company contacts stored somewhere they can actually reach?
• Can the IT manager retrieve the latest technical recovery plan from the out-of-band location?
• Is it really the latest approved version?
• Are emergency contact lists accurate?
• Do deputies know what they are authorised to do?
• Can key people access what they need if normal email, identity or collaboration systems are unavailable?

These short drills keep the response plan alive, expose stale assumptions and help important actions become familiar rather than being rediscovered under pressure.

They also keep incident readiness fresh in people’s minds rather than allowing the plan to disappear into a document repository until the next annual exercise.

The aim is not to rehearse the exact incident. It is to rehearse the way the organisation responds.

Incident readiness is not about proving that a plan exists. A documented plan may satisfy an audit requirement, but it is not evidence that the organisation has a tried and tested major-incident process that will work under pressure.

Real readiness depends on all of the moving parts working together: people, personalities, decision authority, escalation, communications, technical response, recovery, suppliers, insurers and executive leadership. Rehearsal is how assumptions are exposed before those dependencies are tested for real.

The question is not “do we have a plan?” but “have we proved that the organisation can use it?”

Protect the people doing the work

Major incidents place significant physical and emotional pressure on the people responding to them. Technical specialists, security teams and senior leaders can be drawn into sustained response activity for many hours, and sometimes much longer.

JandaSec encourages incident plans and rehearsals to consider the welfare of responders explicitly: sensible rotations, deputies, handovers, rest, food, access to support and clear authority to bring in additional capability when internal teams are becoming stretched.

This is one reason a Chief People Officer, HR representative or equivalent can be an important part of the wider incident team. Their role is not to direct the technical response, but to help ensure the organisation does not exhaust the people it depends on to make good decisions and recover safely.

Where appropriate, rehearsals should also test when external technical support would be called in. The time to decide who can reinforce the SOC, engineering, infrastructure or incident-response team is before the organisation reaches the point where its key people are exhausted.

People are part of the recovery architecture. Exhaustion, unclear handovers and over-reliance on individuals can become incident risks in their own right.

Prevention still matters. So does limiting the blast radius, detecting quickly, responding calmly and restoring safe trading.

Assume breach. Limit the damage. Respond calmly. Restore safe trading.

Typical coverage

• Cyber incident response plan
• Escalation and decision rights
• Executive and board roles
• Decision-making under uncertainty
• Technical containment and blast-radius reduction
• Legal and regulatory interfaces
• Customer and stakeholder communications
• Cyber insurance coordination
• BCDR dependencies
• Backup and recovery assumptions
• Recovery prioritisation
• Tabletop exercises, progressive injects and crisis simulation
• Micro-rehearsals and targeted control checks
• Responder welfare and sustainable rotations
• Deputies, handovers and succession
• External technical support and surge capacity
• Lessons learned and plan improvement