Preparing Your Organisation for the First 24 Hours After a Cyber IncidentThe first 24 hours of a cyber incident will test far more than your technology.
They will test your leadership. Your governance. Your communication. Your culture. Your decision-making. And ultimately, your organisation's resilience. When a serious cyber incident occurs, information is rarely complete. Nobody immediately knows the full extent of the problem. Systems may be unavailable. Customers may be affected. Employees want answers. Suppliers may be involved. Regulatory obligations need to be considered. Social media speculation can begin before management understands what has happened. And somewhere in the middle of all this, leaders must make decisions. This is why cyber incident preparedness cannot simply be an IT responsibility. The first 24 hours are a business leadership challenge. The Incident Starts Before the Board Knows About It Most cyber incidents don't begin with a dramatic announcement. They begin quietly. An employee clicks something suspicious. Someone notices unusual activity. A customer reports something strange. A supplier calls with bad news. A system behaves unexpectedly. An employee realises they may have shared information they shouldn't have. What happens next can significantly influence what follows. At Cyberplanz, we believe in a simple principle: The Cyberplanz Five-Minute Rule The most important five minutes in any cyber incident are the five minutes after someone realises something might be wrong. People should not waste those minutes worrying about blame. They should not attempt to hide a mistake. They should not spend half an hour trying to determine whether the problem is serious enough to report. They should know exactly how to raise the alarm. Early reporting creates options. Delay removes them. This is why incident preparedness starts with culture. 0–1 Hour: Establish What You Know The first hour is about creating clarity without pretending you have certainty. The immediate priorities should include:
Someone believes customer data has been stolen. Someone else believes it hasn't. Another person thinks the incident originated with a supplier. An executive wants to tell customers immediately. The technical team is still investigating. Leadership needs to distinguish clearly between: What we know. What we think. What we don't yet know. That discipline becomes critical throughout the incident. Who Is Actually in Charge? This sounds like a simple question. During a real incident, it often isn't. The CISO may lead the technical response. The CIO may own affected systems. The CEO may lead the organisational response. Legal advisers may guide regulatory decisions. Communications teams manage stakeholders. Business continuity leaders focus on operations. The Board provides governance and oversight. If these roles have not been established before the incident, valuable time can be lost deciding who has authority to do what. A good incident response plan should therefore define more than technical responsibilities. It should establish decision rights. Who can disconnect a critical system? Who can authorise emergency expenditure? Who decides whether customers are notified? Who engages external specialists? Who communicates with regulators? Who speaks publicly? Who briefs the Board? During a crisis, ambiguity creates delay. 1–4 Hours: Understand the Business Impact Once the immediate response is underway, leadership needs to move beyond the technical question: "What has been compromised?" and begin asking: "What does this mean for the organisation?" Which critical services are affected? Can customers still transact with us? Can employees work? Can we access essential information? Are payment systems functioning? Could sensitive information have been exposed? Are suppliers affected? Do we need to invoke business continuity arrangements? This is where cybersecurity and business resilience become inseparable. A technically serious incident may have limited business impact. A relatively simple technical failure may stop the organisation operating. Boards and executives need visibility of both. Protect the Organisation—But Preserve the Evidence There can be enormous pressure to get systems operating again as quickly as possible. That is understandable. But poorly coordinated recovery can destroy valuable evidence or make it harder to understand how the incident occurred. Technical specialists may need to preserve logs, devices, communications and other evidence before systems are rebuilt or restored. This can create tension between: "Get us operating again." and "We need to understand what happened." Those decisions should be anticipated before a crisis occurs. The organisation may also need external forensic, legal, insurance or specialist incident-response support. Knowing whom to call before the incident saves precious time afterwards. 4–8 Hours: Communication Becomes Critical Cyber incidents create an information vacuum. And information vacuums are quickly filled by rumours. Employees speculate. Customers ask questions. Suppliers become concerned. Journalists may make enquiries. Social media can amplify incomplete information. Good crisis communication therefore matters enormously. But speed must be balanced with accuracy. The organisation should communicate what it knows without pretending to know what it doesn't. A useful principle is: Be early. Be factual. Be consistent. Internal communication matters just as much as external communication. Employees should know:
Don't Forget Your Customers When organisations experience cyber incidents, there is an understandable tendency to focus inward. Systems. Investigations. Legal advice. Technical recovery. But customers are experiencing the incident too. They may be unable to access services. They may be worried about their information. They may not understand what is happening. And silence can quickly damage trust. Customers do not necessarily expect an organisation to have every answer immediately. They do expect honesty, competence and communication. How an organisation communicates during uncertainty can influence its reputation long after the technical incident has been resolved. 8–12 Hours: Governance and Regulatory Decisions As more information becomes available, the governance implications become clearer. Leadership may need to consider:
This is another reason Boards should not wait for an incident before discussing cyber response. The first time directors consider these questions should not be during a crisis. What Should the Board Be Doing? The Board's role during a cyber incident is important—but it must be clearly understood. Directors should provide oversight, challenge and support. They should not become the incident response team. A Board that begins directing technical recovery can create additional confusion. Instead, directors should focus on questions such as:
Is management making decisions based on evidence—or pressure? Good governance during a crisis provides clarity rather than additional noise. 12–24 Hours: From Response to Resilience By this stage, the organisation should be developing a clearer understanding of the incident. The priorities begin expanding from immediate containment towards:
This is important. Twenty-four hours after a sophisticated cyber incident, the organisation may still not know everything. Boards should resist demanding certainty where certainty does not yet exist. Instead, leadership should demonstrate that: The response is structured. Responsibilities are clear. Evidence is being gathered. Customers are being considered. Critical operations are being prioritised. Decisions are being documented. And the organisation is adapting as new information emerges. That is what resilient leadership looks like. Third Parties Must Be Part of the Plan Not every cyber incident will begin inside your organisation. A critical supplier may be compromised. A cloud platform may fail. A software provider may experience an attack. A payroll provider may lose access to its systems. This creates an additional challenge because your organisation may not control the investigation. You may depend on someone else to tell you what happened. Your incident response plans should therefore include third-party scenarios. As we've discussed previously in the Boardroom Guide: You can outsource the service. You cannot outsource accountability for the risk. If a supplier's cyber incident affects your customers or your ability to operate, it becomes your resilience issue too. AI Is Changing Incident Response Artificial Intelligence adds another dimension. An incident may involve:
But organisations should be careful not to outsource critical judgement to AI during a crisis. AI can support decisions. Accountability remains human. Don't Wait for an Incident to Discover Your Plan Doesn't Work A beautifully written incident response plan provides very little assurance if nobody has tested it. Tabletop exercises are one of the most valuable tools available to Boards and executive teams. Imagine beginning a Board exercise with: 8:07am Monday Your CFO receives a call. Several critical systems are unavailable. IT believes ransomware may be involved. A journalist has emailed asking whether customer information has been stolen. Your largest customer wants an explanation. And your technical team cannot yet confirm what happened. What do you do next? That conversation will reveal more about your preparedness than another policy review. Who takes control? Who contacts whom? Who has authority? What information does the Board need? How do you communicate? Where are the gaps? Exercises turn theoretical plans into organisational capability. After 24 Hours, Start Asking What We Are Learning Recovery may take days, weeks or even months. But learning should begin early. What worked? What caused delays? Were responsibilities clear? Did employees report quickly? Were communications effective? Did suppliers respond as expected? Did the Board receive the information it needed? What should change? A resilient organisation does not simply survive an incident. It becomes stronger because of what it learns. The First 24 Hours Are Built Before the Incident This may be the most important point. You cannot manufacture trust during a crisis. You cannot suddenly create clear governance. You cannot instantly build leadership capability. You cannot introduce a reporting culture after the attack begins. And you cannot properly test an incident response plan while you are using it for the first time. The quality of your first 24 hours is determined by the preparation undertaken during the previous 12 months. Strong governance. Clear responsibilities. Practised leadership. Trusted relationships. Engaged employees. Tested plans. Reliable suppliers. Good communication. These are what create resilience. The Question Every Board Should Ask At your next Board meeting, don't simply ask: "Do we have a cyber incident response plan?" Ask: "If a serious cyber incident began at 8am tomorrow, would we know what to do by 8:05?" Then ask: Who would lead? Who would make the critical decisions? When would the Board become involved? How would we communicate? Could we continue operating? Have we actually practised it? If those questions are difficult to answer, another policy may not be the solution. Practice may be. Because when a serious cyber incident occurs, your organisation will not rise to the quality of the document sitting in a folder. It will depend on the quality of the decisions its people can make under pressure. And those decisions are built long before the crisis begins. Cyber resilience isn't built by technology. It's built by leadership, enabled by governance, and delivered by people.
0 Comments
Leave a Reply. |
AuthorPatrick – Founder of Cyberplanz | Business Strategist | Cyber Governance Advocate Archives
September 2026
Categories |
RSS Feed