Technology Risk in the Boardroom: Are You Asking the Right Questions?

Technology risk sits on almost every board risk register in every regulated organisation. It appears as a line item, it gets a RAG status, and it is reviewed at the appropriate interval. And in many cases, that is where meaningful board engagement with technology risk begins and ends.

Having served as an Executive Director on the board of a regulated financial services organisation, combining technology leadership with board-level governance, I have seen this gap from the inside. The problem is rarely one of intent. Most board members understand that technology risk is important. The problem is one of framing, language, and ownership — and until those three things are addressed, the board cannot discharge its governance responsibilities effectively.

This is what I have observed, and what I believe needs to change.

Three Mistakes Boards Make Consistently

Mistake 01

Treating technology risk as an IT problem

When a cyber incident occurs, the instinct is to ask what the technology team is doing about it. When a system fails, the question is directed at the IT department. This framing, while understandable, fundamentally mischaracterises the nature of technology risk in a modern organisation.

Technology risk is not a technical problem with a technical solution. It is a business risk with technology as both its source and its primary mitigation. A board that delegates technology risk entirely to the IT function is making the same category error as a board that delegates financial risk entirely to the finance team and considers the matter resolved.

What Good Looks Like

Technology risk belongs on the board's risk register as a business risk, owned at board level, with the technology function responsible for its management and the board responsible for its oversight. The distinction matters. Oversight requires the board to ask questions, challenge assumptions, and satisfy itself that risks are being managed appropriately. Delegation requires only that someone else is doing so.

Mistake 02

Confusing compliance with security

Passing an audit does not mean you are secure. Holding a certification does not mean your organisation is protected. Compliance frameworks define a minimum standard at a point in time. The threat landscape moves continuously. An organisation that achieves certification and then treats the work as done has, in effect, stopped the clock on its security posture while the world around it keeps moving.

I have seen boards receive assurance based on compliance status alone, and take genuine comfort from it. That comfort is often misplaced. The question is not whether the organisation has passed its last assessment. The question is whether it is adequately protected today, against the threats that exist today.

What Good Looks Like

Compliance reporting and security reporting should be presented to the board as separate but related items. Compliance tells you where you are against a defined standard. Security tells you whether you are actually protected. A board that receives only compliance reporting is missing half the picture, and in many cases the more important half.

Mistake 03

Not knowing the right questions to ask

This is the most common gap, and the most understandable. Most board members did not build their careers in technology. They are skilled, experienced leaders in their own disciplines. But technology risk requires a different kind of interrogation, and without a framework for asking the right questions, even the most capable board members can find themselves accepting reassurance they are not equipped to properly evaluate.

The result is that technology risk reporting becomes a one-way communication rather than a genuine governance conversation. The technology team presents. The board receives. And the critical challenge that might surface a real issue never quite happens.

What Good Looks Like

Boards benefit enormously from having at least one member with genuine technology literacy, not necessarily a technologist, but someone who understands enough to ask the questions that create productive challenge. In the absence of that, external support to develop the board's technology risk questioning capability is a worthwhile investment.

The Questions Every Board Should Be Asking

Good technology risk governance does not require the board to understand the technical details. It requires the board to ask questions that would expose whether the organisation is managing risk appropriately. Here are the questions I consider essential:

Board-Level Technology Risk Questions
01 If our most critical system failed completely today, how long would it take to restore normal operations, and have we tested that assumption recently?
02 What are the three technology risks that keep our technology leader awake at night, and what would it take to adequately mitigate them?
03 How do we know our cyber security posture is adequate, beyond the compliance certifications we hold?
04 Which of our suppliers has the most access to our critical systems and data, and when did we last formally assess their security practices?
05 If we suffered a significant cyber incident tomorrow, who would make the decision to notify the regulator, and does everyone in that chain know their role?
06 What technology investment are we deferring that represents a growing risk, and what would it cost us if that risk materialised?

These questions are not designed to catch anyone out. They are designed to create a genuine governance conversation, one where the board and the technology leadership team are jointly interrogating the organisation's risk position rather than simply exchanging reports.

A board that cannot challenge its technology risk position is not governing it. It is endorsing it.

From the Boardroom

From Experience

Serving as a board director at a regulated offshore financial services organisation, I inherited an IT Disaster Recovery (DR) setup that was, to be direct about it, largely cosmetic. It existed on paper, it satisfied the minimum regulatory requirement for an annual test, and it would almost certainly have failed in a real incident. The board's appetite for investment was limited. The attitude, not uncommon, was that DR was an insurance policy nobody expected to use.

I made the case for change, but I did not make it by asking for a large budget. I made it by showing what was possible with what we already had. Using repurposed hardware, Microsoft DFS for file replication, SQL log shipping with a fifteen-minute recovery interval, and eventually Veeam Backup and Replication to a low-cost NAS solution replacing ageing backup tapes, we built a genuinely functional warm recovery site. Amazon S3 handled archived backups. The total investment was a fraction of what a conventional approach would have cost.

One area where the board pushed back hardest was the workplace recovery suite. The thinking was straightforward: if people can work from home, why pay for a dedicated recovery site? It is a reasonable question on the surface, but it misses the reality of how organisations actually operate. Not every role can function from a kitchen table. A receptionist needs a reception. A staff member handling client document printing, company stamps, official letterheads, and regulated correspondence needs the physical equipment to do so. If the main building had suffered a fire rather than a flood, replacing that equipment would have taken weeks. The workplace recovery suite was not a luxury. It was the difference between the business being able to operate and it not being able to.

Then March 2020 arrived. COVID-19 lockdown protocols mandated everyone to work from home. That was a challenge in itself. Our workforce demographic meant that working from home was unfamiliar territory for many of our staff, but we managed it.

What nobody planned for was what happened on 15 April 2020.

A flood hit the building that housed our primary server room. The office was empty. I received a call informing me that the local electricity provider would be cutting power to the building within thirty minutes. No generators. A UPS that would carry the load for a couple of hours at best. I convened an emergency BCM meeting over Microsoft Teams, initiated a graceful shutdown of all production services and servers at 11am, and by 1pm we were fully operational at our DR site. No data loss. No client service interruption. Two staff members worked permanently from the recovery site for what turned out to be four months and fifteen days.

When we eventually returned to the primary site, we did so again without a single disruption to IT services.

I tell this story not to celebrate the incident, but to make a point about what DR investment actually means. The board that had been reluctant to spend the money got its answer in the most unambiguous way possible. Not because we spent a fortune, but because someone had thought carefully about what we actually needed, tested it properly, and made sure it would work when it had to.

Good DR does not have to be expensive. It has to be honest. The most dangerous DR plan is one that looks adequate on paper but has never been genuinely tested against a realistic scenario. The second most dangerous is one that was tested once, three years ago, and has not been reviewed since.

The question every board should ask is not "do we have a DR plan?" It is: "are we confident it would actually work today, under real conditions, with the people and systems we currently have?"

What Good Board Technology Governance Looks Like

The boards that handle technology risk well share a small number of characteristics that have nothing to do with the technical sophistication of their members.

That last point deserves emphasis. One of the most damaging dynamics I have observed is a board culture where bad news is unwelcome. When technology leaders learn that raising risks leads to difficult questions and implicit criticism, they stop raising risks early. Problems that could have been addressed at a manageable stage instead surface at crisis point. The board's attitude to risk escalation shapes the information it receives, often without the board realising it.

Technology risk governance is ultimately a leadership challenge, not a technical one. The boards that get it right are the ones that create the conditions for honest, informed conversations about risk, and then act on what those conversations reveal.

Is your board getting the technology risk oversight it needs?

I work with boards and leadership teams to strengthen technology risk governance: from improving reporting and questioning frameworks to building the organisational capability to manage risk proactively rather than reactively. If this resonates, I would welcome a conversation.

Start a Conversation