.png)
Most cybersecurity conversations with executives start with prevention: are we protected? What are we spending? Did we pass the audit? Those are fair questions. The better question is what happens on Monday morning after prevention fails.
How that week goes is rarely decided by the attacker's actions. It's decided by the preparation your organization made months earlier to define your maximum tolerable downtime, test your backups, and test your incident response and disaster recovery plans.
This preparation, called Business Impact Analysis, plays a critical role in your organization's response planning. Below are six questions every business leader should be able to answer without calling IT. If there are questions you can’t answer, that is worth finding out now rather than during an incident.
1. How Long Can We Run Without Our Core Systems?
Every business has a point where downtime turns into lost customers, missed payroll, or broken contracts. Make sure you can name that point for each critical process.
IT can tell you how long the recovery will take. Only the business can say how long is too long. If those two numbers have never been put side by side, the gap between them is your real exposure.
✅ A good answer sounds like: "Order entry can be down for eight hours. Billing can wait three days. Here is what our continuity and recovery plans deliver for each."
🚩 Red Flag: "IT has that covered," or one answer given to the whole company.
2. Have We Ever Restored From Backup, & How Long Did It Take?
Having backups and being able to restore them are different claims. Common gaps are operational: backups reside on the same network an attacker has compromised; restore testing covers a single server without measuring the time needed to rebuild 50; or data is recovered, but the software configurations and licenses required to resume operations are missing.
Ask for two things: the date of the last full restore test and the time it took, compared to the number from question 1. Then ask whether at least one backup copy is offline or immutable, meaning it cannot be changed or deleted even by an administrator's account, because attackers commonly go after backups first.
✅ A good answer sounds like: "We restored our finance and customer systems in March. It took 19 hours against a 24-hour target, and here is the written result."
🚩 Red Flag: "Our backups run every night." That describes copying, not recovering.
3. In What Order Do We Recover, & Who Decided?
After a major incident, systems come back one at a time. Without an agreed-upon recovery sequence, IT may prioritize what is easiest to restore or whatever someone is shouting about loudest.
Recovery priorities should be established through the business impact analysis exercise. Foundational services, such as identity systems and user directories, usually come first because almost nothing else works without them. From there, the sequence should follow what keeps people safe and revenue flowing. Ask for a ranked recovery list that documents dependencies and has been reviewed and approved by the leaders responsible for each function.
✅ A good answer sounds like: A one-page, ranked recovery list that department heads have seen and agreed to.
🚩Red Flag: Every department head believes their systems are first.
4. What Do We Do By Hand While Systems Are Down?
While systems are being rebuilt, the business must still operate, take orders, ship products, pay people, and answer customers. Most companies discover that their manual process exists only in the head of one long-tenured employee, or that it depends on a spreadsheet stored on the server that is offline.
Across industries, downtime procedures should address the everyday decisions that the technology team usually supports. How will employees process orders without the customer database, confirm shipments without the inventory system, or approve a payment without the usual workflow? The fallback must preserve essential checks and approvals so that new process gaps are not introduced. Without clear instructions and practice, employees are left to improvise under pressure, increasing the risk of errors and unauthorized transactions.
✅ A good answer sounds like: "Printed procedures and forms for our ten critical processes are kept at each site, and we ran through them last quarter."
🚩Red Flag: The downtime procedures are stored on the system that is down.
5. Who Decides, & How Do We Talk To Each Other When Email Is Down?
In the first hours of an incident, a handful of decisions must be made quickly: whether to take systems offline, whom to call, who speaks to employees and customers, and who has the authority to spend money. Any response to an attacker should involve legal counsel, your insurer, and law enforcement; and it should never be improvised.
There are outside clocks to consider as well. Public companies have a short window to disclose a material incident to the SEC. Healthcare organizations, financial institutions, and businesses holding personal data face breach notification duties under federal and state law. Many cyber insurance policies require prompt notice and may limit which forensic firms you can use, so calling the wrong vendor first can complicate a claim.
✅ A good answer sounds like: A written plan that names roles and responsibilities, with phone numbers on paper, identifies outside counsel and a forensic firm in advance, and includes the insurer's incident hotline.
🚩Red Flag: The response plan lives in a shared drive or in Microsoft Teams.
6. What Does The Board See, & Does It Tell Us Whether We Could Recover?
Cybersecurity oversight sits with leadership. The NIST Cybersecurity Framework 2.0 reflects this by adding a dedicated Govern function, which covers strategy, roles, and accountability alongside the technical work.
A board report should answer the questions above, not just count how many attacks were blocked. A short list serves better than a long dashboard.
- How long it takes to detect and contain an incident, and how long it takes to restore critical systems, each against the targets from question 1.
- How quickly critical security patches are applied on internet-facing systems.
- The date and result of the last restore test and the last incident response tabletop exercise.
Trend matters more than any single reading, so use the same measures every quarter.
✅ A good answer sounds like: A one-page report, consistent each quarter, where every measure has a target and an owner.
🚩Red Flag: A dashboard full of green indicators and no targets behind them.
Test The Answers Before You Need Them
The most efficient way to check all six answers is a tabletop exercise. Your leadership team spends a few hours with a facilitator working through a realistic scenario, such as ransomware that takes your core systems offline on a Friday afternoon. The point is to find out where our incident response procedures are well-defined, which assumptions turn out to be wrong, and which plans exist only on paper.
The gaps that surface are easier to fix in a conference room than in the middle of an outage. If you would like help running one for your organization, contact the Business Technology Solutions team.
About GBQ Business Technology Solutions
GBQ's Business Technology Solutions practice empowers the growth of our clients across six disciplines: risk management, cybersecurity, IT governance, AI and automation, data and analytics, and business systems.
If this article raised questions that you cannot yet answer about your own strategy, the first place to start is with a conversation. GBQ’s Business Technology Solutions team can assess where your organization stands today, prioritize use cases worth your investment, and help build the governance that lets you prove what AI is returning.
Net Effect is a biweekly column written by members of GBQ's Business Technology Solutions team and published in the firm's Bottomline newsletter. Let us know if you have a technology question, and we can address it in a future column.
