When Everything Is Green, Boards Should Ask Better Questions

Technology dashboards can provide reassurance without necessarily providing insight. Effective Board oversight requires understanding what sits behind the green.

Board technology and cyber reports have become increasingly sophisticated.

Dashboards contain risk indicators, project status, service availability, cyber metrics, vulnerabilities, incidents, audit findings and remediation programmes. Red, amber and green indicators allow Directors to absorb a large amount of information quickly.

And very often, most of the dashboard is green.

That should be reassuring.

But sometimes it should also prompt another question:

Are things genuinely under control — or are we simply measuring them in a way that makes them look under control?

This is not an argument against dashboards or RAG reporting. Boards need concise information and management needs a practical way of communicating complex technology environments.

The challenge is that a green metric can describe performance against a threshold without necessarily describing the underlying risk.

For Boards, understanding that distinction is increasingly important.

Green means the threshold was met

Consider a hypothetical cyber metric:

98% of critical vulnerabilities remediated within SLA — GREEN

At first glance, that appears positive.

But the Board's real exposure may sit within the remaining 2%.

Imagine those vulnerabilities relate to a small number of internet-facing systems containing sensitive customer information. Perhaps remediation has been delayed because patching requires business downtime.

The aggregate measure is still 98%.

The dashboard remains green.

But the risk represented by the outstanding 2% may be considerably more important than the 98% that has already been remediated.

The issue isn't that the metric is incorrect.

It is answering a different question from the one the Board needs answered.

Management is reporting:

"How effectively are we meeting our vulnerability-management SLA?"

The Board may need to know:

"Where does our most material unresolved cyber exposure currently sit?"

Those are very different questions.

Aggregation can hide material risk

This problem appears repeatedly in technology reporting.

A large technology programme might report:

90% of milestones delivered on time — GREEN

But what if the delayed 10% includes the critical integration needed for launch?

A resilience dashboard might report:

95% of applications successfully recovered during testing — GREEN

But what if one of the unsuccessful applications supports a critical business service?

A technology-risk dashboard might show:

92% of technology risks within appetite — GREEN

But what if the remaining risks include a material dependency on unsupported infrastructure?

The mathematics may be perfectly accurate.

The governance insight may still be inadequate. Boards therefore need to be cautious about averages, percentages and aggregate indicators when the distribution of risk matters more than the aggregate result.

The denominator matters

One of the simplest questions a Director can ask when presented with a percentage is:

“Percentage of what?”

Consider vulnerability management again.

A report might state that critical vulnerabilities outside SLA represent only 1% of scanned hosts.

That sounds small.

But the denominator—scanned hosts—may include thousands of relatively low-risk endpoints.

What matters is not simply how many hosts are affected.

The Board may need to understand:

• Which systems are affected?

• Are any externally accessible?

• Do they support critical operations?

• What data do they contain?

• How exploitable are the vulnerabilities?

• Are compensating controls in place?

• How long have they remained unresolved?

A vulnerability on a low-value internal device and the same vulnerability on a critical externally accessible system should not necessarily have the same governance significance.

Risk is not evenly distributed across the denominator.

Trends often matter more than thresholds

Another weakness in RAG reporting is its tendency to focus attention on whether something has crossed a predefined threshold.

Imagine a risk appetite metric:

Green: fewer than 100 critical vulnerabilities outside SLA

Amber: 100–150

Red: more than 150

The organisation reports:

• January — 38

• February — 52

• March — 67

• April — 81

• May — 96

Every month is technically green.

But the trend tells a very different story.

The Board shouldn't have to wait for June to turn amber before asking what is happening.

Good Board reporting should therefore show not just current status, but also:

direction, velocity and persistence.

A deteriorating green metric can sometimes deserve more attention than a stable amber one.

Age matters too

A further issue is that aggregate reporting can hide how long individual risks have existed.

Suppose management reports:

96% of critical vulnerabilities remediated within 30 days.

Again, potentially reassuring.

But what if several of the outstanding vulnerabilities have remained unresolved for six months?

The Board may need to understand why.

Perhaps remediation requires an outage management has been reluctant to schedule. Perhaps the underlying application is difficult to patch. Perhaps the system is approaching end-of-life.

At that point, the issue is no longer simply vulnerability management.

It may be an investment, resilience or risk-acceptance decision.

And that is precisely where Board governance becomes relevant.

Who accepted the risk?

This leads to one of the most useful questions a Board can ask:

“Who has accepted this risk?”

Technology teams frequently identify vulnerabilities, resilience weaknesses, technical debt or systems requiring remediation.

But fixing them can have consequences.

A critical system may need to be taken offline.

A legacy platform may require substantial investment.

A control improvement may delay a business initiative.

Management then has to balance technology risk against customer impact, revenue, operational disruption and cost.

Those are legitimate business decisions.

The governance issue arises when the decision is effectively made through inaction or

repeated deferral, rather than through explicit risk acceptance.

For material risks, Boards should understand:

Who owns the risk? What decision was made? On what basis? For how long?

A green dashboard should never obscure an important risk decision.

Reporting should drive decisions, not simply describe activity

Technology reporting often contains large amounts of operational information because that information is readily available.

Number of incidents.

Number of vulnerabilities.

Percentage of patches completed.

System availability.

Project milestones.

Audit actions closed.

All are useful management measures.

But Board reporting has a different purpose.

A useful test is:

What decision, challenge or governance action should this information enable the Board to take?

If the answer is unclear, the metric may belong in management reporting rather than the

Board pack.

This doesn't mean Boards need more information.

Usually, they need less information with greater materiality and context.

Five questions to ask when the dashboard is green

When presented with a predominantly green technology dashboard, Directors might ask:

1. What material risks are hidden within the aggregate numbers?

   
   

2. Which green metrics are deteriorating and likely to become amber or red?

   
   

3. Are our thresholds based on genuine risk appetite or simply historical performance?

   
   

4. Where have remediation decisions been deferred because of cost, business disruption or competing priorities — and who accepted that risk?

   
   

5. What technology issue concerns management most that isn't obvious from this dashboard?

That final question can be particularly revealing.

It shifts the conversation away from reporting mechanics towards judgement.

The objective isn't to make the dashboard redder

None of this means Boards should distrust management reporting or encourage organisations to generate more red indicators.

Nor should Directors spend meetings interrogating individual operational metrics.

The objective is better governance.

RAG reporting is useful because it simplifies complexity. The danger comes when the

simplification creates false confidence.

Good technology reporting should help a Board understand:

What matters?

What is changing?

Where are we outside appetite?

What decisions have been deferred?

Where does management need Board support or challenge?

A dashboard that enables those conversations is doing its job.

One that simply demonstrates that most things are green may not be.

Green should be the beginning of the conversation

Boards don't need hundreds of technology metrics.

They need a small number of indicators that illuminate material technology performance, risk, resilience and investment — supported by enough context to exercise judgement.

That sometimes means looking beyond the headline number.

Beyond the percentage.

Beyond the threshold.

And occasionally, beyond the green.

Because one of the most important questions a Director can ask when everything appears to be under control is simply:

“What aren't we seeing?”

Steve Coles
Board Technology Adviser | Non-Executive Director | Former Global Chief

Technology Officer

Steve advises Boards on technology governance, independent assurance, cyber, AI and operational resilience.