As a seasoned CISO, one of the things I've learned over the years is that application security and board reporting often feel like two completely different worlds.
On the AppSec side, you have security teams discussing vulnerabilities, attack paths, exploitability, insecure APIs, prompt injection risks, model exposure, and remediation timelines. On the board side, you have directors and executives focused on growth, reputation, shareholder value, regulatory obligations, and strategic risk.
Somewhere in the middle sits the CISO, trying to bridge that gap.

The challenge has become even more complex with the rise of AI. It's no longer enough to explain application security risks. Today, security leaders are increasingly being asked to explain the risks associated with AI adoption. Every board meeting seems to include questions about AI. How are we using it? Are we exposing sensitive data? What are the risks? Are we protected?
What's interesting is that many organizations are approaching AI risk the same way they historically approached cybersecurity risk: by focusing on the technology rather than the business implications. The result is often a discussion filled with technical terminology that creates more confusion than clarity.
I've come to believe that boards don't actually care about vulnerabilities, and they certainly don't care about the technical intricacies of large language models.
What they care about is exposure. They care about how technology decisions might impact the organization, its customers, its operations, and its reputation.
That distinction fundamentally changes how we communicate risk.
Early in my career, I spent countless hours building security dashboards filled with vulnerability counts, severity ratings, remediation metrics, and coverage statistics. While useful for security teams, they rarely answered the question that boards were actually asking:
Are we becoming more or less exposed?
The same dynamic is emerging with AI. Security teams are discussing hallucinations, model poisoning, prompt injection, and shadow AI. Boards are asking a much simpler question: What could go wrong, and what would it mean for the business?
That's why the most effective board reporting starts with business impact and works backward.
When discussing application security, I focus less on the number of vulnerabilities and more on where risk exists. Which applications support critical business functions? Which systems process sensitive data? Which assets, if compromised, would have the greatest impact on customers or operations?
The conversation becomes even more important when AI enters the picture.
Many organizations are embedding AI into customer experiences, internal processes, and software development workflows. Yet very few boards have a clear understanding of where AI is actually being used. Before discussing AI risk, leaders need visibility into AI adoption across the business.
One of the first questions every board should be asking is surprisingly simple: Where are we using AI today?
The answer is often less clear than expected. Business units experiment with generative AI tools. Employees upload information into public platforms. Developers integrate AI-powered services into applications. AI adoption frequently moves faster than governance.
The greatest AI risk isn't necessarily the technology itself. The risk is not fully understanding where and how it is being used.
Data exposure is often the most immediate concern. Boards quickly understand the implications of sensitive information being shared with external AI systems. Intellectual property, customer information, source code, and strategic business data all represent potential risks if proper controls are not in place.
Another area is decision integrity. As AI becomes embedded into business workflows, organizations need confidence that outputs are reliable, accurate, and appropriate. What starts as a technical issue can quickly become a business issue when AI influences customer communications, operational decisions, or regulatory obligations.
AI is also changing the broader application security landscape. Developers are producing software faster than ever before, while attackers are increasingly using AI to automate reconnaissance, identify weaknesses, and accelerate attacks. The result is a threat environment that is moving faster on both sides.
This is why traditional security reporting is becoming less effective. Reporting how many applications were scanned or how many vulnerabilities were discovered tells the board very little about actual business risk. What matters is understanding exposure, potential impact, and whether the organization's most important assets are becoming more resilient over time.
Perhaps the most important lesson I've learned is that boards care far more about trends than snapshots. They want to know whether risk is increasing or decreasing. They want confidence that leadership understands the organization's exposure and has a clear plan to manage it.
The best board discussions I've participated in were never about technical details. They were conversations about confidence.
Confidence that critical applications are protected. Confidence that AI adoption is governed responsibly. Confidence that risks are understood and actively managed.
The role of security leaders is not to overwhelm directors with technical complexity – it’s to help them understand where technology creates risk, where it creates opportunity, and how the organization is balancing the two.
Application security and AI may feel like separate conversations today, but they are rapidly converging. AI is accelerating software development, reshaping business processes, and changing the threat landscape. The organizations that succeed will be those that learn to manage both through the same lens: business risk.
Because at the board level, the question has never really been about vulnerabilities or AI models. The question is whether the organization can confidently embrace innovation while maintaining trust.
