Board members do not need to be technology experts to assess their company’s resilience. They do, however, need to ask the right questions. One principle is particularly useful in conversations about security: I do not want to know whether we are protected. I want to know whether we can continue operating when those protections fail.

This principle changes the nature of the conversation. Asking about security measures invites a presentation of tools and procedures. Asking whether the company can continue operating demands specifics: figures, timeframes and scenarios. The ten questions below put this principle into practice.

The first group concerns dependence on the outside world. Can we continue operating if we lose our primary IT provider? Can we migrate to another environment? Could an administrative or legal decision cut off our access? These three questions reveal how many external decisions the company’s operations depend on. We have discussed elsewhere in this series why dependence on technology providers has become a strategic risk.

The second group concerns data. Do we have a backup of our data outside the primary environment? Do we know that our data is clean, and how do we know? Where exactly is our most critical data stored? The words how do we know in the second question make all the difference. An answer such as we assume it is proves nothing. An answer that explains how this is verified provides actual evidence.

The third group measures the company’s ability to resume operations. How long does it take to restore the company’s operations in full? Do we regularly rehearse a disaster scenario? The answer to the first question should be expressed in hours or days, not as we will find out when it happens. The second separates a plan that exists only on paper from one that works in practice, a distinction we have also discussed in greater detail.

Two questions remain, bringing everything together. What is our most significant single point of failure? And how much does one hour of downtime cost? The first identifies where resilience efforts should begin. The second provides a financial justification for those efforts by comparing the cost of preparation with the cost of being unprepared.

The order of the questions is not set in stone. In practice, it often makes sense to begin with the cost of one hour of downtime, as this answer gives weight to all the others. Once it becomes clear how much the company loses with every hour of unavailability, questions about data backups, disaster scenarios and single points of failure no longer sound like technical details. They become measurable business costs.

The list is most useful when there is no expectation that every answer will be available immediately. The value of the first discussion lies elsewhere. It reveals which answers already exist, which need to be verified and which nobody has ever looked for. Every I do not know is not a failure. It is an item for the agenda of the next meeting.

It is also worth addressing a natural concern within the IT department. These questions are not an examination or an attempt to assign blame. They are an invitation to discuss security in terms of business consequences rather than system parameters. This shared language helps boards and technical teams develop the same understanding of risk.

Ten questions, one meeting and no technical jargon. In return, the board gains something invaluable: a fact-based view of the company’s resilience rather than a general sense that someone is taking care of it. Every good decision starts with such a view.