Digital risk management: 12 questions for supervisory boards

1. What digital risks can our core goals really be affected?

I wouldn't start with a list of a hundred cyber threats.

Start with the organisation.

Which processes are so important that long-term failures have direct consequences for clients, residents, employees, production, services, finance or reputation?

Then ask:

• which systems are necessary for this;
• which data are critical;
• which suppliers are indispensable;
• which digital distortions have the greatest impact;
• What risks does the board consciously accept?

This makes cybersecurity part of normal risk management.

A good supervisory question

.What three digital risks can hit our strategy or continuity the hardest, and why these three?

A board that has a clear answer to that shows that there is prioritisation.

2. Who is the board-level owner of digital risks?

Cybersecurity is often discussed as an IT topic.

I think that is too limited for oversight.

The CIO or IT manager may be responsible for many measures, but the risk itself affects the business operations. Continuity, finance, employees, services and suppliers are all part of this.

So ask:

• who is the board-level owner of the main digital risks;
• which role IT has;
• the role of privacy, risk, control and business operations;
• who takes decisions when risks cannot be fully removed;
• how escalation is taking place.

An external IT partner can carry out work. The board remains the one to explain the risks and reasons for which the organisation is at risk.

3. What do we base our trust on, anyway?

This is a question I like to ask.

Organisations say it all the time:

“Our IT partner has this in place.”

That may be true. For oversight, then relevant which that trust is based on.

Examples include:

• independent audit reports;
• Insurance;
• measurement data;
• repair tests;
• penetration tests;
• vulnerability reports;
• internal controls;
• management reports;
• contractual arrangements;
• evidence of follow-up of findings.

A verbal confirmation is something other than demonstrable control.

A good supervisory question

.What independent or objective evidence do we have that our most important security measures actually work? .

4. Do we only see incidents, or also the quality of control?

Sometimes an RvT or RvC gets information when something goes wrong.

That is too late to be able to monitor properly risk-oriented.

I would also like to have a periodic look at topics such as:

• outstanding high risks;
• critical vulnerabilities;
• delayed improvement measures;
• repair tests;
• severe supplier dependencies;
• exceptions to security policy;
• incident training status;
• access with increased rights;
• important audit findings;
• decisions on risk acceptance.

The goal is not to discuss a technical dashboard in the board.

The question is whether the dashboard shows where board-level attention or decision-making is required.

5. What risks remain conscious?

There is no such thing as complete safety.

There will always be risks. Some measures are too expensive, technically not yet feasible or require time to implement properly.

That doesn't have to be a problem, as long as the balancing is made aware.

Question, for example:

• which high risks are currently accepted;
• who has approved that acceptance;
• on the basis of what information;
• until acceptance is granted;
• the temporary measures in place;
• when re-evaluated.

I find an organisation with some well-founded accepted risks often more credible than an organisation that claims that everything is green.

6. Can we recover when prevention fails?

Many conversations about cybersecurity are about prevention.

As far as I am concerned, oversight should pay at least as much attention to recovery.

So ask:

• which processes should be able to resume first;
• the amount of data loss acceptable;
• the maximum duration of failure;
• where a real restore test was last performed;
• whether a complete recovery chain has been tested;
• which suppliers are required during recovery;
• or governance and crisis organisation know their role.

A successful backup notification does not say much about the time needed to get the business back.

A good supervisory question

. .When was the last time we tested that a critical process can be resumed within our own objective after a major cyber interference? .

7. How dependent are we on suppliers?

For many organisations, this is one of the biggest blind spots.

The IT department can function perfectly, yet a problem with a cloud provider, software supplier or management party can have major consequences.

As a supervisor, I'd like to know:

• which suppliers are critical;
• which services depend on them;
• the access they have;
• which security arrangements are contractually established;
• which assurance is available;
• how incident notifications are conducted;
• what happens when the supplier fails for a long time;
• how to switch or terminate.

Supplier risk goes beyond purchasing.

It is a question of continuity and governance.

8. Are findings actually being resolved?

An audit, risk analysis or security scan often provides a proper list of measures.

The quality of risk management is then shown.

Question:

• who owns any major finding;
• which deadline is linked to it;
• which has now been demonstrated to be completed;
• which points have been postponed;
• why that happened;
• the risks which therefore persist.

I would prefer to see five clear priorities that are clearly resolved than 50 recommendations that no one knows yet.

A good supervisory question

. Which three major cyber findings are already open longest and what prevents completion?

That is often a surprisingly informative question.

9. Do we get any information that fits in with surveillance?

A technical report of forty pages can be very valuable for the IT manager and virtually useless for the RvT.

Good oversight requires translation.

I would have board-level information answered at least:

• what is the risk;
• which critical process can be affected;
• the impact of the project;
• which control already exists;
• which is detectable;
• the uncertainty that persists;
• who owns it;
• what is the improvement period;
• what decision is necessary if necessary.

The technique remains available for deepening, but the main reporting should be manageable.

10. How do we know that internal control really works?

Internal control is more than policies and procedures.

In security measures, I like to look at three simple concepts:

design, existence and operation.

Design

Is the measure designed to be appropriate?

Existence

Has the measure actually been implemented?

Operation

Does the measure function over time?

An example.

On paper, access rights can be checked quarterly.

The following oversight questions are relevant:

• that control is actually carried out;
• who's going to execute him;
• any deviations found;
• the solutions to these deviations;
• Is there any evidence available?

That makes internal control concrete.

11. Do management and organisation practice with disruption?

An incident response plan is useful. A trained incident response plan gives more certainty.

I would therefore like to know:

• when the last exercise took place;
• the scenario used;
• or board/direction;
• which suppliers were involved;
• which bottlenecks became apparent;
• the improvements that were made afterwards.

A drill does not always have to be technically complicated.

A good boardroom scenario exercise can already reveal that there is uncertainty about powers, communication, decision-making, recovery priorities or contact with suppliers.

You'd rather discover that kind of ambiguity during an exercise than during a real crisis.

12. Is our risk management demonstrable to be better than it was a year ago?

This last question prevents cybersecurity from becoming a recurring item on the agenda without visible development.

Question, for example:

• which major risks have been reduced;
• which measures are more demonstrably effective;
• which dependencies have been reduced;
• the new risks which have arisen;
• the lessons learned from incidents and audits;
• where the organisation will be able to see its way to next year.

This separates oversight from individual projects and creates an improvement cycle.

What information should I periodically give to the RvT or RvC?

I wouldn't prescribe a solid universal dashboard. The information must fit the organisation.

For many organisations, I would at least think of:

The power is not in the number of indicators.

The information should help the council to: by asking, recognizing patterns and having the conversation with the board at the right level.

Where is the boundary between oversight and implementation?

That is a frontier that deserves attention.

The RvT or RvC does not have to design the security program themselves. I would also be reluctant to monitor the direct assignment of operational tasks to the IT manager.

The part is different.

The Board shall decide whether to:

• has risks;
• make appropriate choices;
• organise responsibilities;
• make sufficient funds available;
• receives reliable information;
• monitoring;
• is transparent about uncertainties.

When the board itself decides which firewall or security tool to purchase, oversight shifts towards execution.

If the supervisory board simply accepts that “IT says everything is fine”, its oversight remains too superficial.

The art is in between.

What do you do when the council isn't sufficiently visible?

Don't start with 20 new KPIs.

My preference is to first establish what information is missing to form a responsible judgment.

This may be the reason for:

• a targeted risk analysis;
• a boardroom cyber session;
• an assessment of internal control;
• an independent Cyber Security Audit;
• deepening of supplier risk;
• an incident exercise.

The form follows from the question.

For an RvT or RvC, independent research is especially valuable when it helps to replace assumptions with demonstrable information.

Five signals I would ask as a supervisor

There are a few answers where a follow-up question arises directly from me.

“There's our IT supplier responsible for.”

Then I want to know how the organisation checks that responsibility is properly implemented.

♪ We've never had a major incident. ♪

Then I want to know what evidence There's prevention and recovery working.

“Everything is green.”

Then I want to see the definitions of green and know which exceptions are outside the dashboard.

“We're ISO certified.”

Then I want to know what scope the certificate has and what board-level risks may be excluded.

“We performed a penetration test last year.”

Then I want to know which environment has been tested, which findings have been resolved and which other risks have not been investigated.

- I don't think asking.

It's precisely what oversight is meant for.

Risk-based oversight starts with a good conversation

Cybersecurity becomes manageable for an RvT or RvC once the conversation is no longer about loose technology.

Talk about:

• continuity;
• dependencies;
• risk acceptance;
• evidence;
• responsibility;
• recovery;
• progress.

This will link digital risk management with the way a board looks at other strategic risks.

If I chose one question to ask at the next meeting, it would be this:

.Where are we most dependent at the moment on an assumption that we have not yet demonstrated how it works? .

The answer often gives more insight than a dashboard full of green ticks.

Continue to deepen

Also read:

• Internal control in practice
• the Kynexis article on cybersecurity governance
• the page about Information security risk analysis

Internal control in practice · Cybersecurity governance · Information security risk assessment

When governance and oversight together seek to strengthen the current risk picture, a Boardroom Cyber Session be a practical first step.