Exposure Management Is Not a Tool, It’s a Discipline.
by Brad Hibbert, COO & CSO//11 min read/
Brad Hibbert, COO and Chief Strategy Officer at Brinqa, on the 20-year evolution from vulnerability scanning to AI-powered exposure management, and what it means for your security program.
You closed 400 critical vulnerabilities last quarter. So did your competitors. So did the companies that got breached. Closing vulnerabilities isn't the problem, knowing which ones actually threatened your business is. If your program measures success in tickets closed rather than risk removed, you're optimizing for the wrong outcome.
In a recent Cloud Security Podcast episode, Brinqa Chief Operations and Strategy Officer Brad Hibbert joined host Ashish Rajan to trace how vulnerability management has evolved into exposure management, why that shift matters, and how AI is changing the decisioning layer entirely.
“Risk-based vulnerability management is a great first step, but it's very siloed into those individual teams and platforms. Exposure management gets to the next level of diligence. It's not about how many critical vulnerabilities you closed that day. It's about how much risk you took out of the organization.”
– Brad Hibbert, Chief Strategy & Operations Officer, Brinqa
Cloud, Containers, and APIs: How the Attack Surface Outgrew Traditional Vulnerability Management
Hibbert started in vulnerability management years ago, when many considered quarterly server scans a mature program. "They might have done a scan once a quarter to meet their compliance requirement. Then they moved it to monthly." The environment was relatively contained: a data center, some internet-facing web servers, a clear perimeter.
That world no longer exists. Today, a single server might support multiple business services simultaneously, one serving internal employees, another serving external customers. Cloud workloads, containers, and APIs operate in environments that are software-defined and ephemeral. Add in threat intelligence feeds, identity systems, and custom application code, and the scope of what needs to be tracked, prioritized, and remediated has grown exponentially.
"Everything's more interconnected now than it's ever been," Hibbert said. "Context matters a lot more than it did in the past. It's not just about getting the raw findings, it's figuring out, with the context of the business, what to focus on to have the biggest impact on risk reduction."
What Is Exposure Management, and How Is It Different from Risk-Based Vulnerability Management?
Risk-based vulnerability management was a meaningful step forward from raw vulnerability lists. By layering in asset context and threat intelligence, teams could move from "fix everything" to "fix what matters most." But it still operated within silos – each tool, each team, each domain producing its own prioritized view.
Exposure management is the layer above. It connects risk across all domains and all tools, providing a unified, business-aligned view of what actually matters. As opposed to focusing on CVEs to fix, exposure management focuses on which exposures can lead to compromise.
"Risk-based vulnerability management is a great first step," Hibbert explained, "but it's very siloed into those individual teams and platforms. Exposure management gets to the next level of diligence. It's not about how many critical vulnerabilities you closed that day. It's about how much risk you took out of the organization."
The key questions exposure management is designed to answer:
- Is this exposure reachable in my environment?
- Is it exploitable?
- If exploited, what is the blast radius?
- Which business services does it put at risk?
This shifts the program's objective from reporting to remediation, from producing a prioritized list of issues to actually mobilizing the right teams to remove risk from the environment.
The Ownership Problem: Risk Owners vs. Remediation Owners
One of the most persistent challenges in vulnerability management has always been ownership. Who owns the vulnerability? Who owns the fix? In traditional programs, the answer was usually simple: the server team owns the server risk.
But in a world where a single server supports multiple business services, that mapping breaks down. "The server team's not going to know which one of these services is most important to the business," Hibbert said. "It would be the service owners that would understand: am I willing to accept this risk?"
Traditional vulnerability programs lack shared context, so remediation teams (IT, Cloud, App teams), don’t trust the priority coming from security. Exposure management introduces a cleaner ownership model by separating two distinct roles:
- Risk owner: The service owner who understands business context and decides how to respond to risk.
- Remediation owner: The technical team (cloud, server, code, etc.) that performs the actual fix.
Without this distinction, programs stall. "I come to you as the remediation owner, you crack open a spreadsheet and start arguing that your data's different than my data," Hibbert said. "That happens a lot."
How AI Fits Into the Exposure Management Stack
Security teams aren’t lacking data, they're drowning in it. Telemetry from scanners, threat intelligence feeds, asset management platforms, cloud monitoring tools… the volume of inputs has outpaced any human team's ability to process it manually.
This is where AI enters the exposure management picture. According to Hibbert, AI's primary value is in making connections across data sets that are too complex for manual analysis — correlating attacker behavior, exploit techniques, mitigating controls, and asset context to surface what actually matters.
But AI's usefulness depends entirely on the quality of the data foundation underneath it. "You want to make sure that your AI is based on a sound data foundation," Hibbert said. "If you don't believe in the data, if you're suspect of the opinions coming out of the AI, then you're not going to take action based on those outputs."
The evolution Hibbert describes is a three-stage progression:
- Data orchestration: Aggregating, normalizing, and making sense of feeds from multiple tools and CMDBs.
- Decision orchestration: Using AI to produce opinionated, explainable prioritization across teams; telling you what to fix, in what order, and why.
- Action/remediation orchestration: Automating remediation for known patterns with high confidence, while keeping humans in the loop for high-risk changes.
"Automation works well for known patterns," Hibbert noted. "If the AI can look back and say it has 90% confidence this is the right thing to do, you can start to automate those. But if it's a risky change that could impact a critical service, you still might want a human to click the button."
Compliance Proves Activity. Exposure Management Proves Impact.
For organizations operating under regulatory frameworks (PCI DSS, HIPAA, SOC 2, etc.) vulnerability management has historically been compliance-driven. Close your critical vulnerabilities within 30 days. Show the auditor a report. Move on.
Hibbert's view: compliance-driven programs demonstrate activity, not impact. "Hey, I closed my critical vulnerability in 21 days, but it's not tied to the actual risk you're taking out of the environment."
Exposure management reframes the conversation for boards and executive leadership. Instead of SLA adherence metrics, security teams can show quarter-over-quarter risk reduction tied to specific business services — demonstrating not just that work was done, but that the organization's exposure to material risk has measurably decreased.
"One is focused on outcomes and impact. The other is focused on demonstrating that prescribed activity has been performed," Hibbert said.
What It Takes to Transition to Exposure Management
Moving from risk-based vulnerability management to exposure management isn't primarily a technology decision. It's an organizational one.
- Executive commitment. Exposure management needs to be treated as a discipline, not a tool deployment or side project.
- Shared understanding of risk. All teams need to agree on how risk is defined and prioritized before the program can operate effectively.
- Aligned incentives. If different teams are incented differently (e.g., one team optimizing for CVSS-based closure speed, another for uptime) friction and conflict will undermine the program.
- Clear decision authority. Risk ownership and remediation ownership need to be explicitly defined and agreed upon across teams.
- Dedicated resources. The cross-team coordination required for exposure management can't run on the side of someone's desk.
On the practical side, Hibbert recommends starting small. Pick one or two areas (external attack surface, crown jewel applications, a set of critical services) and demonstrate measurable risk reduction before expanding. "You're never going to start with perfect data or perfect systems," he said. "Focus on decisions, not scope."
Preserving Domain Knowledge While Evolving the Program
One concern Hibbert hears frequently: will moving to exposure management mean losing all the domain-specific logic teams have built into their existing tools over years?
His answer: it shouldn't. Exposure management is designed to sit above the tools, normalizing and curating insights from across teams; not to replace them. Domain knowledge that reflects genuine business context should be preserved and carried forward.
The same principle applies to workflows. Security teams don't need to force every development team into a single standardized process. "We have customers who use 20 different flavors of Jira," Hibbert said. "We can accommodate that. We're not asking them all to change the way they develop code, we're showing them where in their code to fix exposures, using a broader, business-aligned prioritization model that's explainable and defensible."
The Bottom Line
The tools have multiplied. The environments have expanded. The attack surface now spans infrastructure, cloud, code, APIs, identities, and AI systems. What hasn't kept pace, in many organizations, is the program-level thinking that ties all of it together.
Exposure management isn't a tool, it's a discipline — one that requires organizational alignment, a shared data foundation, and a shift in how security teams measure their own success. Not by how many vulnerabilities were closed, but by how much risk was actually removed from the business.
"It really wasn't about the tools," Hibbert reflected. "It was about decision clarity and moving beyond the tools."
To learn more about Brinqa's approach to enterprise exposure management, schedule a free consult with a Brinqa Expert.
FAQs
Exposure management is a security discipline that connects risk across all tools, teams, and domains to give organizations a unified, business-aligned view of what actually threatens them. Unlike traditional vulnerability management, which operates within individual tool silos, exposure management focuses on outcomes — specifically, how much risk is being removed from the business — rather than how many vulnerabilities are being closed.
Vulnerability management identifies and prioritizes weaknesses within specific tools or domains. Exposure management sits above those tools, normalizing data across all of them to provide a holistic view of risk tied to business services. The key shift is from reporting — producing prioritized lists of findings — to remediation, actively coordinating fixes across teams based on business impact.
Risk-based vulnerability management improves on raw vulnerability lists by adding asset context and threat intelligence to help prioritize findings. But it still operates within individual tool and team silos. Exposure management takes that a step further, connecting risk across all domains and measuring success not by how many issues were closed, but by how much exposure was eliminated from critical business services.
Exposure management requires more than a technology investment. The prerequisites are largely organizational: executive commitment to treating it as a formal discipline, a shared definition of risk across teams, aligned incentives so teams are working toward the same goal, clear decision authority separating risk owners from remediation owners, and dedicated resources to coordinate activity across teams. On the technical side, organizations should expect to normalize data across multiple CMDBs, scanners, and threat intelligence feeds before meaningful prioritization is possible.
Compliance-driven programs demonstrate activity — closing critical vulnerabilities within a defined SLA, for example. Exposure management demonstrates impact — measurable reduction in risk to the business services that matter most, tracked over time. The distinction matters at the board level: one proves work was done, the other proves the work made a difference.
AI helps exposure management programs process and connect the high volumes of data that security teams can't analyze manually — correlating attacker behavior, exploit techniques, asset context, and mitigating controls to surface what actually matters. Its value depends entirely on the quality of the underlying data foundation. When AI models operate on normalized, trusted data, their outputs become actionable. When the data foundation is fragmented or inconsistent, teams won't trust or act on AI recommendations.
Exposure management separates two distinct roles: the risk owner and the remediation owner. The risk owner is typically the business service owner — the person who understands whether a given exposure threatens something the business depends on, and who decides how to respond. The remediation owner is the technical team responsible for executing the fix, whether that's a server team, cloud team, or development team. Without this distinction, programs stall as teams argue over whose data is correct and who is responsible for action.