Most security leaders struggle with board reporting. Either the report is so technical that board members tune out, or it's so high-level that it's meaningless. Neither outcome helps you.
If you're a founder reporting to investors, a CISO presenting to a board, or a vCISO advising leadership, getting this right matters. A good board security report builds confidence, secures budget, and creates alignment. A bad one wastes everyone's time.
What boards actually want to know
Board members aren't security experts. They don't need to be. They need to understand:
- Are we protected? What is our current security posture? Are the basics in place? Where are the gaps?
- What are the biggest risks? Not all risks. The top three to five that could materially impact the business. Translated into business terms, not technical jargon.
- Are we getting better? Are we making progress on the things we said we'd improve? Is our risk exposure decreasing over time?
- Are we compliant? Where do we stand on our compliance commitments (SOC 2, HIPAA, ISO, etc.)? Are there any issues with our certifications?
- What do you need? Budget, headcount, executive support, a decision. If you're not asking for something, the board wonders why you're presenting.
That's it. Everything else is detail they don't need in the boardroom.
The structure that works
I've seen a lot of board security reports. The ones that work follow a consistent structure:
Executive summary (one paragraph). Overall security posture in plain language. Two or three sentences. "Our security program is maturing on schedule. We completed our SOC 2 Type II audit with zero findings. Our primary risk areas are third-party vendor security and patching speed for critical vulnerabilities."
Key metrics (three to five). Pick metrics that tell a story. Not vanity metrics. Metrics that show whether your security is getting better or worse.
Good metrics:
- Mean time to patch critical vulnerabilities
- Percentage of systems with MFA enabled
- Number of security incidents (severity-weighted)
- Vendor risk assessments completed vs. due
- Compliance certification status
Bad metrics:
- Number of firewall rules
- Total vulnerabilities found
- Phishing simulation click rates (without context)
- Number of security events logged
Top risks (three to five). Each risk should be stated in business terms with a plain-language description, business impact, likelihood, and what you're doing about it.
Example: "Our third-party payment processor has not provided an updated SOC 2 report. If their controls are inadequate, we could be exposed to payment data compromise, which would trigger PCI notification requirements and potential customer loss. We've escalated the request and are evaluating alternative processors."
Not: "Vendor X has a CVSS 8.7 vulnerability in their API gateway that could allow authenticated users to escalate privileges."
Progress update. What did you commit to last quarter? What got done? What didn't? Why? This is where you build credibility. Boards remember what you said you'd do. Show that you did it.
The ask. Budget. Headcount. A policy decision. An approval to pursue a certification. Whatever you need from the board, put it clearly at the end with the business justification.
Common mistakes
Information overload. A 30-slide deck with vulnerability scan results, firewall logs, and technical architecture diagrams. The board doesn't need this. You're demonstrating that you're working hard, not that you're effective.
Fear-based reporting. Leading with worst-case breach scenarios to scare the board into approving the budget. This works once. After that, you've cried wolf. Report risks honestly without catastrophizing.
No business context. Saying "we have 47 critical vulnerabilities" means nothing without context. Are those vulnerabilities in internet-facing systems? How many were there last quarter? What's the trend? What's the remediation plan?
Not asking for anything. If you present and don't ask for a decision or resource, the board assumes everything is fine. When you come back later asking for a budget urgently, they'll wonder what changed.
Reporting compliance as security. "We passed our SOC 2 audit" is great. It's not the same as "we're secure." The board needs to understand both your compliance posture and your operational security posture.
Making it visual
Boards process information visually. A few well-designed charts and dashboards are more effective than pages of text.
A risk heat map showing your top risks by likelihood and impact. A trend line showing your mean time to patch over the last four quarters. A status dashboard showing compliance certification progress. These tell the story quickly and memorably.
Keep the slides clean. One message per slide. No walls of text. Use color intentionally — red for critical issues, green for areas that are on track, yellow for items that need attention.
The cadence
Quarterly is standard. More frequent for companies in a high-risk environment, undergoing an incident, or building their program for the first time.
Between board meetings, send a monthly one-page summary to the CEO or your board liaison. This keeps security on the radar without requiring a full presentation. Include: any incidents, key metrics changes, and any decisions needed before the next board meeting.
The vCISO advantage
One of the things a virtual CISO brings to the table is experience doing this across multiple companies and boards. We know what works, what doesn't, and how to translate technical risk into language that drives decisions.
If you're a founder or technical leader who's been asked to present security to your board and you're not sure where to start, this is exactly the kind of thing we help with at Com-Sec.
Farbod Fakhrai is the founder of Com-Sec, a cybersecurity and compliance consulting firm for startups and growth-stage companies.