Peter Drucker, known as the father of modern management, wrote that “the daily crisis is indeed the one absolutely predictable event in the working day of the executive.” Whatever the industry, a business is either in the middle of a crisis, coming out of one or headed into the next.
While a company may employ a chief information security officer (CISO) who oversees security, the CIO is still responsible for keeping the business functioning during a security crisis. An ERP application can go down because of a software exploit and every user could get locked out of their files by ransomware.
No matter the situation, the first questions from business leaders are the same:
- What still works?
- How soon can operations resume?
- How will we know everything is now secure?
CIOs must balance security demands with the need to keep IT running. Those responsibilities can become competing priorities during an incident. Sometimes, while a team can isolate a system to clean up a security incident, nobody has agreed on who authorizes the resulting outage.
The ways in which CIOs prepare for a cyberattack should account for these competing demands. Cyber crisis readiness starts with making decisions about authority, priorities and acceptable disruption. Leaders must be able to give technical teams the right instructions, and documenting those decisions in advance also makes them much easier to defend if anyone questions them afterward.
Why CIOs should create a security crisis plan
Organizations too frequently operate without a written and properly tested crisis plan. Production outages can negatively affect revenue, and data exposures can damage customer trust. A third-party compromise can lead to both when a vendor that executives assumed had security handled experiences a cybersecurity crisis.
IT leaders can lose credibility in a single leadership meeting because they couldn't explain the effect of a cybersecurity incident or define their next steps. Planning for the worst case puts the CIO in a much better position when other leaders ask for a security status update.
Companies should plan for more than ransomware. Identity attacks involve hackers misusing legitimate accounts, while AI can expose confidential information through unapproved tools. Meanwhile, cloud misconfigurations grant hackers unauthorized access to data while operations continue as usual. A cybersecurity problem may not cause a SaaS outage, but it requires the same business coordination. Settle the regulatory, contractual and breach notification obligations with legal counsel in advance, because the notification clock starts whether companies know about it or not.
The necessity of creating a plan comes back to the concept of defensibility. A CIO security crisis plan establishes who makes decisions and how those decisions are recorded. During the incident, keep a record of who knew what, who approved each action and why. In every serious incident, attorneys ask for those details at some point.
The CIO's role in a security crisis
A CIO’s security incident responsibilities vary by organization, but the division of labor and overall incident leadership must be agreed on beforehand. The best-prepared CIOs sit down with their CISOs and settle the following questions before a security incident happens.
Where does the CIO lead?
The CIO usually leads business systems recovery and IT service continuity, which includes working with business owners to determine the restoration order, ensuring that unaffected services remain available and activating approved workarounds.
The CIO also coordinates the technology team's updates for executives. These updates should include carefully considered recovery estimates and a scheduled time for the next executive update. They become the record of what leadership knew and when.
CIOs also handle vendor escalations and should establish emergency vendor contacts and support commitments in advance. High-level sales relationships won’t cut it during a cybersecurity incident.
Where does the CISO lead?
The CISO leads threat analysis and containment. Forensics and technical security decisions are also the CISO’s responsibility, including preserving evidence and assessing whether the attacker still has access. Recovery should follow agreed-upon security steps, including checking for compromised accounts and the paths an attacker could use to get back in.
The CISO must give responders the authority to isolate affected systems within approved limits, and major shutdowns should require defined emergency authority and escalation rules that account for operational consequences. The CISO's job during containment is to protect that authority, including when a business unit leader wants a system to be back online.
A company without a CISO must explicitly assign these responsibilities to an internal IT or security leader and arrange for qualified outside support, including an incident response retainer, before that support is needed.
Where do responsibilities overlap?
The CIO and CISO should brief executives together about the incident’s effects, including what is known and what remains uncertain. They must also agree on a recovery process. The CIO should identify which company services should receive recovery priority, while the CISO should assess whether those services can be restored properly and securely. Together, they should document the recovery options and remaining risks, and refer decisions beyond their authority to the appropriate business executive.
That documentation will help with defensibility. A decision made by the right person, with the known risks written down, will hold up much better under questioning. IT is a core business function, and neither the CIO nor the CISO should take on significant business risk for the sake of everyone else.
Build a crisis playbook before an incident occurs
CIOs should keep the crisis playbook short and connect it to the incident response and existing continuity plans. Recovery priorities should already be part of that planning. The playbook should articulate recovery priorities in terms executives understand, so they can follow directions during a crisis without having to assume or figure things out as they go.
Start with a single business function -- for example, payroll that must run on a specific date. Work backward from that date to the application that runs it, then to the identity service and the vendor behind that application.
Work with the business owner to assign a recovery tier to each piece, including how much downtime and data loss the owner will accept. A four-hour recovery target doesn’t mean much if restoring the underlying identity service will realistically take days. Nearly every recovery plan has a mismatch like that somewhere.
Then do the same for customer orders, and keep going until the top tier is mapped and full coverage is achieved.
What to do for manual workarounds
Manual workarounds are too vague in most playbooks. If finance cannot send out employee payments while its systems are unavailable, it's better for the CIO to find out now than later. If possible, the manual workaround should define who runs it and how transactions will be reconciled once the system is back up. Otherwise, no one will follow the workaround when the system is down.
Decision limits are often left out of playbooks. IT and security teams should know which containment and recovery actions they can take under their own authority. That list should also be longer than most executives expect, because every hour spent waiting for approval to isolate a system gives an attacker more time to move on to the next one.
Beyond that, the CEO or a designated executive should approve major disruption, and the CFO should authorize emergency spending, with a preapproved amount to streamline urgent purchases and put them in progress. Meanwhile, legal should review any material about the incident that will be seen by individuals outside the company. Each decision should be assigned an owner, a backup owner and a place where it gets logged in case such details are needed in the future.
The playbook should also define when the company’s board must be notified, and that should be a clearly defined event or number. Some examples of when to notify a board include when losses exceed an agreed-upon figure or when the exposure of sensitive data has been confirmed. The playbook should also define who makes the call to the board.
For a failover or a switch to a backup vendor, the company must confirm whether the compromise is still active and if the alternative runs safely.
The musts for a cybersecurity tabletop exercise
Finally, do a practice run of the playbook with everyone named in it, including legal counsel. Run it without email and single sign-on, as those capabilities are likely to be unavailable during a security incident.
Store the playbook and emergency contacts in a secure location, and test restores on a regular schedule. Tabletop exercises are good for testing decisions, but they won't indicate whether a backup actually works. A backup is often assumed to be functional and isn’t. The only way to confirm is to run the restore.
Assign every newly identified gap in the plan to an owner and set a deadline to fix it. It’s better that a company discover an impossible-to-meet recovery target or a missing decision-maker during a tabletop exercise than deal with the problem while the business is down and explain it to the attorneys once the dust settles.
The two key concepts for all of this are reasonable and defensible. Companies must focus on those two concepts before the crisis hits.
Kevin Beaver is an independent information security consultant, writer and professional speaker with Atlanta-based Principle Logic, LLC. With more than 30 years of experience in the industry, Beaver specializes in performing vulnerability and penetration tests as well as virtual CISO consulting work.
