Board Cyber Oversight

The One-Page Cyber Dashboard a Board Can Actually Use

Build a one-page board cyber dashboard around decisions, evidence dates and clear thresholds. A fictional ten-indicator specimen shows what to keep and test.

Digital Tablet Displaying Business Reports and Financial Charts on a Desk

A one-page board cyber dashboard should let a director identify the decision, the supporting evidence and the accountable owner without opening a second presentation. The constraint is useful only if the page remains readable.

This is a working specimen and acceptance test, not another list of dashboard design principles. The related board-ready dashboard guide covers the broader approach. Here, the task is to decide whether one proposed page is ready to enter the board pack.

Use the specimen as a starting point, not a universal scorecard. The right indicators depend on the business, its risk strategy and the decisions directors need to make.

Key takeaways

  • Put the decision request and changed exposure above the metrics.

  • Give every indicator a definition, owner, evidence date and action threshold.

  • Use a small number of indicators that cover the business's priority scenarios.

  • Show missing evidence as missing, not as a healthy status.

  • Test readability and decision usefulness before sending the page.

Step 1: Reserve the top of the page for the decision

Use a short decision line: the choice required, the decision owner, the deadline and the consequence of waiting. If no decision is requested, say so and explain what changed enough to warrant attention.

Below it, summarize material changes since the last report. Keep the supporting indicator definitions stable enough for comparison, while flagging scope changes that break the trend. Do not hide a new exclusion inside a footnote.

NIST CSF 2.0 connects oversight, resources and risk strategy. It does not mandate a dashboard layout or a metric count. The page should serve the governance decision, not imply that a chosen design proves compliance.

Step 2: Assemble a ten-indicator specimen

The following is a fictional menu of ten indicators, not a report of actual company performance. It intentionally contains no invented current values. In a real page, each row would include the current result, a comparable trend and the evidence date.

Indicator What the result must mean Decision or escalation route
Critical service recovery Outcome against an approved service target, with test scope. Service owner addresses a failed or untested target.
Privileged access coverage Reviewed population divided by the defined in-scope population. Business owner resolves uncovered critical access.
Priority exposure aging Unresolved priority exposures against the agreed deadline. Risk owner decides treatment or time-bound acceptance.
High-risk exceptions Open exceptions with owner, expiry and changed conditions. Approver revisits expired or altered assumptions.
Incident impact trend Comparable business impact, not just alert volume. Executive owner addresses a worsening scenario.
Supplier concentration Critical services sharing a material dependency. Management assesses substitution or contingency options.
Customer assurance gaps Material claims lacking current supporting evidence. Claim owner corrects or supports the statement.
AI change reviews In-scope material changes awaiting required review. Workflow owner holds or escalates the change.
Remediation outcome tests Completed changes that have passed a relevant test. Control owner demonstrates effect before closure.
Delivery capacity Priority risk responses blocked by capacity or dependencies. Executive owner changes resources, sequence or risk response.

The working evidence register can contain detailed definitions. The page still needs enough context to stop a director misreading the result. If ten rows cannot fit at a readable size, reduce or group them. Do not shrink text until the one-page promise becomes unusable.

Step 3: Define thresholds before assigning colors

A threshold should connect a result to an action. Identify who acts, under what authority and by when. Distinguish a target miss, an accepted exception and a lack of evidence. They can require different decisions even when they all deserve attention.

Define the denominator and exclusions for rates. Include an evidence date and a freshness rule appropriate to the risk and pace of change. If a major system change invalidates the old test, an unexpired calendar date does not automatically make the evidence current.

Use a small comparable trend, with the period and direction labeled. Where definitions changed, show the break rather than drawing a continuous line that implies like-for-like performance.

Step 4: Run the acceptance test

Give the draft page to a director or executive who did not build it. Ask them to identify the decision required, the most important changed exposure and the owner expected to act. If they cannot, improve the page before adding another metric.

Then trace two indicators back to their sources. Check that the population, period and claim match. Use one unfavorable result in the test. A page that is clear only while everything is green is not ready.

The companion article on contradictory dashboard evidence addresses the next step when a source undermines a reported status. This specimen is about preventing ambiguity before distribution.

Step 5: Keep detail available without burying the answer

Attach controlled evidence references and concise definitions outside the one-page summary. Preserve appropriate access restrictions. A link to an assurance report is useful only when its audience is permitted to read it.

Review the metric set periodically. Retire an indicator that no longer informs a decision, but record the change and its reason. The goal is a stable decision tool, not a permanent commitment to ten rows.

Sources

NIST, Cybersecurity Framework 2.0, GV.RM, GV.RR and GV.OV. The ten-indicator menu, page structure and acceptance test are editorial recommendations, not a mandated framework or actual company dashboard.

Frequently asked questions

Must the page contain ten indicators?

No. Ten is the specimen's design choice. Use fewer when that better serves the decisions and keeps the page readable.

Should it include technical metrics?

Only when their meaning and business consequence are clear for this audience. Operational detail can remain in supporting material.

Are traffic-light colors enough?

No. Readers need a defined claim, evidence date, threshold and action. Color without those elements can conceal uncertainty.

What belongs in the decisions-requested line?

The choice needed, accountable decision maker, timing and consequence of delay. Keep it distinct from informational updates and routine project progress.

Closing

Test one draft page with a reader who was not in the reporting meeting. If they can name the decision and trace the evidence, the page is doing useful work. If not, remove ambiguity before adding polish.

Next step

Get Board-Ready on AI and Cyber Risk

A 30-minute call. No charge. You'll leave with a clear read on where your oversight stands and what to do about it.

Stop Guessing. Start Scoring
Tyson Martin

Written by Tyson Martin, NACD.DC

Chief Trust, Security & AI Officer. CISO of record at MIO Partners; former CISO & CTO at Lumber Liquidators and Orvis; advisor to 200+ Fortune 500 boards and C-suites at AWS.

See the track record
Keep reading

More on Board Cyber Oversight

All CISO Insights
Board Cyber Oversight

When a Cyber Risk Exception Should Expire

A cyber risk exception without an expiry date is an unrecorded acceptance of risk. Learn when exceptions should expire, renew, or escalate to the board.

Board Cyber Oversight

What Directors Should Ask After a Near Miss

Use cyber near-miss board questions to identify what worked, what allowed the event and which fixes need evidence. No loss does not mean no lesson.