The CISOs I have worked with in the last year are facing the same conversation in their board meetings. The board has read about another supply chain incident, has heard about AI in security, and wants to know what the security team is doing about discovery rather than just response. The CISO has a budget request to make, and the request is for a discovery pipeline that does something new. The slide deck has to explain the value in language the board uses, in numbers the CFO will accept, and in framing that holds up when a director asks a follow-up question that goes beyond the script.
Most of the decks I have seen for this conversation fail in predictable ways. They overpromise on coverage. They confuse findings with defensible findings. They quote vendor marketing as if it were independent benchmarks. They leave the board with a vague sense that "AI is finding more bugs" without articulating the operational impact. This piece is what I have learned about doing the conversation honestly.
Lead with the gap, not the tool
The first slide should frame the problem the board already understands. The dependency graph that ships in your applications contains code your team did not write, was not reviewed by your security team, and is not covered by published CVEs until somebody else finds the bug. The default vulnerability programme is downstream of public disclosure, which means by the time your scanners flag a problem, the attackers have already had time to exploit it.
This framing is honest, the board can verify it from public reporting, and it does not require the CISO to make any claims about specific technologies. It establishes that there is a category of risk the current programme does not address.
The slide should not name a vendor yet. If you start with the tool, you sound like you are selling. If you start with the gap, you sound like you are diagnosing.
Define what zero-day discovery actually does
The second slide is a definition. A zero-day discovery pipeline surfaces vulnerabilities in your code and your transitive dependencies that have no public CVE. It does this by reasoning about reachability and exploitability rather than matching against known patterns. The output is a defensible finding accompanied by evidence: a taint path, a CWE-grounded hypothesis, a disproof attempt, and a proof-of-concept payload.
Boards respond well to definitions because they are accustomed to risk frameworks where each category has an owner and a measurable outcome. Defining zero-day discovery as a distinct category, separate from CVE matching, gives them a place to put it on the risk register.
Present the metrics that matter
The third slide is the metrics. Not the vendor's marketing metrics. The metrics the security programme will be measured by.
Defensible findings per quarter. Cost per defensible find. Time from discovery to disclosure. Time from disclosure to upstream patch. Percentage of findings that are net new (no public CVE). Triage queue health (median time to first touch, acceptance rate, repeat false positive rate).
Each of these has a baseline (zero, in most cases, because the existing programme does not produce any of them) and a target (an honest projection based on comparable deployments). The projections should be cautious. A CISO who promises 200 zero-day discoveries a year and delivers 40 is in a worse position than one who promises 30 and delivers 50.
The metrics should be presented as a leading indicator slide. The lagging indicators (incidents avoided, breach probability) are harder to attribute to discovery work specifically and should not be the centrepiece. They appear in the appendix.
The economics slide
The fourth slide is the cost. Platform cost, compute cost, and the operational cost of the security team running the pipeline. The number should be transparent, including the engineer time required for triage and disclosure.
The comparison the board cares about is cost per defensible find versus the alternatives. The alternatives are: doing nothing (cost zero, value zero), continuing with the current CVE-driven pipeline (cost paid, value bounded by what others disclose first), running a pure-LLM bug hunter (cost paid, value drowned in noise), and running an engine-plus-LLM pipeline like Safeguard's (cost paid, value tracked through the metric stack).
Boards understand cost-effectiveness comparisons because they evaluate every other capital allocation that way. The slide should not be defensive about the cost. It should be precise about what the cost buys.
The "what could go wrong" slide
This is the slide most decks omit, and the slide that builds the most credibility with skeptical directors. The pipeline can be wrong. The disproof pass can fail to drop a hypothesis it should have dropped, producing a false positive. The reachability analysis can miss a flow, producing a false negative. The disclosure process can break down, leaving an unfixed bug in the field.
For each failure mode, the slide names the mitigation. False positives are bounded by triage acceptance rates and tracked over time. False negatives are mitigated by complementary tooling (the pipeline does not replace SCA, it adds an upstream stage). Disclosure failures are mitigated by the embargo discipline and the relationship with maintainers.
A board that hears the failure modes and the mitigations is a board that trusts the CISO. A board that hears only the upside is a board that will be unsettled the first time something goes wrong.
The compliance slide
The fifth slide is the compliance posture. SOC 2, ISO 27001, PCI-DSS, and the new sector-specific regulations all expect the organisation to be monitoring vulnerabilities. They are increasingly happy to see evidence that the organisation is also discovering them. The discovery pipeline produces audit-friendly artefacts (the finding reports, the disclosure timelines, the remediation traces) that strengthen the compliance posture rather than complicating it.
This slide answers the director who asks whether the new programme creates compliance exposure. The honest answer is no, it reduces it.
The implementation timeline
The sixth slide is the timeline. Most discovery pipelines take six to twelve weeks to integrate meaningfully, depending on the size of the codebase and the maturity of the existing security tooling. The slide should show the phases (initial integration, pipeline tuning, triage workflow, disclosure operations) with realistic milestones for each.
A CISO who promises results in two weeks is setting themselves up for the meeting where they have to explain why the results are not there. A CISO who shows a six-month rollout with quarterly checkpoints is presenting a plan that the board can hold them to.
Anticipating the follow-up questions
The board will ask follow-up questions. The ones I have seen most often are: How does this compare to penetration testing? What happens if the vendor goes out of business? How do we know the AI is not hallucinating findings? What is the legal exposure of disclosing zero-days in third-party packages? Each of these has a real answer, and the deck should have a backup slide ready. Penetration testing is complementary, not redundant. Vendor risk is mitigated by data portability. The hallucination question is addressed by the disproof pass and the artefact bundle.
The closing slide
The closing slide is the ask. The budget number, the team headcount, the platform decision, and the success criteria for the first year. It should be specific. Vague asks do not survive contact with the CFO.
The success criteria should be the metrics from the third slide. The CISO is not asking the board to trust them on faith. They are asking the board to fund a programme that will be measured against named numbers, on a named timeline, by a named team.
How Safeguard Helps
Safeguard provides the metric stack, the artefacts, and the operational tooling that the conversation above depends on. The platform reports defensible findings per quarter, cost per find, time-to-disclosure, time-to-patch, percentage net-new, and triage queue health out of the box, in a board-ready format. The disclosure lifecycle, the disproof traces, and the remediation evidence are all auditable, which gives the CISO the artefacts they need to defend the programme to the board, the auditor, and the regulator on the same set of slides.