A senior leadership report on vulnerability management should say what is covered, how timely fixes are, what risk has been knowingly accepted, what is not covered, and what resources are needed. New York's financial services rule expects at least annual written reporting, plus prompt reporting of material issues. This is not legal advice.
What the rule text asks for
New York's rule says the CISO must report in writing at least annually to the senior governing body on the cybersecurity program, including to the extent applicable the confidentiality of nonpublic information and the integrity and security of systems, policies and procedures, material cybersecurity risks, overall effectiveness of the program, material events in the period, and plans for remediating material inadequacies. The CISO must also report timely on material issues such as significant events and significant program changes.
The same rule asks the senior governing body to exercise oversight, including by regularly receiving and reviewing management reports and confirming that management has allocated sufficient resources.
Other governance regimes differ, but the shape is similar: leaders receive reports, ask questions and decide on resources.
What the vulnerability section should contain
- Scope. What systems and software are covered, and what is not. Name the blind spots.
- Cadence. How often scanning and monitoring run, and any changes since the last report.
- Timeliness. On-time remediation by asset importance and severity, with trend.
- Aging. The count and age of overdue high-importance items, with owners.
- Exceptions. Number of accepted risks, with expiry dates and compensating controls.
- Exploited vulnerabilities. Any known exploited flaws that affected you, time to respond.
- Testing. Latest penetration test and retest status.
- Gaps and asks. Material inadequacies and the resources needed to fix them.
NIST's patch management guide notes that different audiences, from board to engineers, need different metrics, and that simple counts of vulnerabilities or percent patched are not actionable without asset and severity context.
Make it readable
| Do | Avoid |
|---|---|
| One page with a grid and three sentences | Forty pages of raw scan output |
| Compare to policy targets | Compare only to last quarter |
| Name owners and dates | Passive phrases such as "efforts are ongoing" |
| Explain scope changes | Let better coverage look like worse risk |
| State uncertainty | Imply completeness |
Questions leaders can ask
- Which important systems are we not scanning?
- What have we decided to leave open, and who approved it?
- How quickly did we respond to the last exploited flaw that affected us?
- Is the team resourced to meet the policy deadlines?
- What would change your answer in the next quarter?
Record the oversight
Keep the report, the date it was presented, and minutes or notes showing discussion and decisions. If leaders asked for follow-up, track it to closure. That record is the evidence of oversight.
Between reports
Do not wait for the annual cycle for something material. Define in advance what triggers an interim note: a known exploited flaw in a critical system, a significant gap found in testing, or a major change to scope.
Where tooling helps
Safeguard consolidates findings with policy and deadline tracking, which helps produce the numbers above from one source. Leaders still need the narrative and judgment that only your team can supply.
Quick check
Does every company need an annual written report?
It depends on the rules that apply to you. Even if none does, an annual written review is good practice and gives you a record.
Should the report include individual CVEs?
Usually only for material cases, such as a known exploited flaw in a critical system. Keep routine detail in the tracker.
Sources
Last reviewed: 19 October 2026.
