Consulting and program design4 min read

How to report compliance and cyber risk to your board on one page

A one page format for reporting compliance and cyber risk to a board: the five blocks to include, what to leave out, and what RBI, ISO 27001 and the SEC expect.

Vaishnavi Sharma · Founder, VASUIST

Steppe illustration: stepped terraces in purple, periwinkle and lime with a signal line, for the article How to report compliance and cyber risk to your board on one page

Board reporting on compliance tends to swing between two extremes. One is the 40 slide deck full of control counts, maturity scores and heat maps, presented in eight minutes at the end of the meeting. The other is a single line in the CEO's update that says "compliance on track".

Both fail for the same reason. Neither asks the board to do anything. A compliance report to a board should fit on one page and end with the decisions only the board can make.

I've prepared management review and board material for ISO 27001 and regulated financial services programs, and the reports that worked were always the shortest ones.

What boards are expected to do

The expectation of board oversight is getting more explicit. The RBI's Master Direction on IT governance requires regulated entities to have a board level IT strategy committee overseeing IT and cyber risk. SEBI's CSCRF puts cybersecurity policy approval and oversight with the board for its regulated entities. In the US, the SEC's 2023 cybersecurity disclosure rules require listed companies to describe the board's oversight of cyber risk.

ISO 27001 clause 9.3 asks top management to review the program at planned intervals, with set inputs: status of previous actions, changes in context, nonconformities, monitoring results, audit results, and opportunities for improvement. That's already most of a one page report.

The five blocks

Status by framework and regulator. One line each: where you are, the next milestone, the date, and whether you're on track. ISO 27001 surveillance audit in February, on track. DPDP readiness by May 2027, at risk. That's enough.

Top five risks. The owner, whether the risk moved since last quarter, and what's being done about it. Five, not fifty.

What changed. Incidents, audit findings, regulator letters, new laws or rules that apply, major new vendors.

Commitments. What you've promised customers in contracts, what regulators expect and by when, the next audit dates. Boards are often surprised by what sales has signed.

Decisions needed. Risks you're asking the board to accept, budget you need, people you need. Make each one a clear yes or no question.

What to leave out

Control counts. "212 of 240 controls implemented" tells a board nothing about which 28 matter.

Percentages without context. A readiness score of 87% is meaningless unless the board knows what the missing 13% contains.

Anything the board can't act on. Operational detail belongs in the management review, not the board pack.

Watch a board member nod politely at a heat map and then ask "so are we fine?", and you'll know what a deck full of charts communicates.

A heat map shown to a board mostly communicates that someone owns a heat map.

Making it repeatable

Produce the page from the same records you use to run the program, so it takes an hour, not a week. Keep the format fixed quarter to quarter so trends are visible. Send it ahead of the meeting and use the time for the decisions.

Board reporting is one of the outputs we built into Steppe for that reason: the page comes out of the records the team already keeps, so nobody builds a deck by hand the night before.

A compliance report that doesn't end in a decision for the board is a briefing, and boards are very good at ignoring briefings.

Frequently asked questions

What should a board cyber risk report include?

Status against commitments, top risks with owners and trends, what changed, obligations to customers and regulators, and decisions needed from the board.

How often should compliance be reported to the board?

Quarterly is common, with immediate escalation for significant incidents or regulatory actions.

References