Security programs built on compliance alone will only take an organization so far. The real maturity comes from understanding and quantifying risk. Aakash Yadav, Security Analyst at LaunchDarkly, designs and manages enterprise information security risk programs, performs supply chain risk assessments, and supports security and privacy compliance efforts. In this episode, he makes the case for why risk should drive your security program, not the other way around.
You can read the complete transcript of the episode here >
How should organizations quantify and prioritize security risks?
The traditional two-dimensional risk matrix (likelihood vs. impact) is a starting point, but it lacks the quantitative depth needed for real prioritization. When multiple risks land in the same “high” category, teams struggle to decide what to tackle first.
Aakash recommends adding more context to the matrix:
- Define what “high” actually means: A severity label without quantification adds little value. Specify the financial impact, the blast radius, and the time period over which the risk materializes.
- Plot probabilities over time: Rather than a static snapshot, model how the likelihood of exploitation changes as the threat landscape evolves.
- Reduce the unknown: Every risk has more information available than teams assume. The question is not whether data exists, but whether the team has sought it out.
He recommends the book How to Measure Anything in Cybersecurity as a practical guide to prioritizing vulnerabilities based on business risk. The core principle: risk is a moving target that requires continuous reevaluation, not a one-time classification exercise.
What is security debt and can it ever reach zero?
Security debt is the accumulation of unaddressed vulnerabilities and findings that pile up when teams lack the resources to fix everything. Aakash is direct: it will never reach zero, and anyone claiming otherwise is not being honest.
The key to managing security debt is continuous reevaluation:
- Risks change over time: A vulnerability classified as “low” six months ago may now be actively exploited in the wild. The severity must be reassessed.
- Use risk registers: Track all debt in a risk register and revisit it regularly. Ensure that lows remain lows and have not quietly become highs.
- Treat it like engineering debt: Just as product teams reprioritize backlog items when customer demand shifts, security teams must reprioritize when the threat landscape shifts.
The parallel to technical debt is exact. You will never eliminate it entirely, but you can prevent it from becoming unmanageable through disciplined, ongoing review.
What challenges arise when setting up security programs across M&A integrations?
The biggest challenge Aakash faced during M&A was the assumption that the acquiring company’s security program is automatically superior. This mindset creates friction and misses opportunities.
His recommendations for security leaders navigating M&A:
- Keep an open mind: The acquired company may have better processes in certain areas. Be willing to learn from them.
- Do not force immediate alignment: Expecting 100% compliance with your program from day one is unrealistic and counterproductive. Let programs run in parallel until a thoughtful merge is possible.
- Make the combined program better: The goal is not to override one program with another. It is to take the best elements of both and create something stronger.
A practical example: change controls differ across every organization. Forcing an acquired company onto your change control process immediately will break their workflows and jeopardize compliance timelines. A phased approach works better, similar to the enterprise risk management challenges other security leaders have navigated.
How should organizations approach supply chain security for open source software?
Supply chain security sits right behind phishing as a top concern, and Aakash acknowledges that the industry does not do a great job addressing it. Open source software powers critical infrastructure, but it introduces significant risk if not managed properly.
Before adopting any open source component, evaluate:
- Community support: Is it maintained by a healthy community or a single individual who could abandon it?
- Release frequency: Regular updates indicate active maintenance and security patching.
- Change management: When updating versions, review what changed. Do not blindly upgrade.
- Ongoing monitoring: Install and forget is a recipe for disaster. Continuously track the health of your dependencies.
The balance is important: restricting engineers from using open source stifles growth. The answer is allowing it with vigilance, proper review processes, and continuous monitoring. Organizations looking to formalize this should explore software composition analysis tools and practices, and understand how supply chain security, SBOMs, and vulnerability management fit together.
Why should security programs be risk-driven rather than compliance-driven?
This is the central thesis of the episode. Aakash identifies compliance-driven security as the single biggest mistake organizations make, and it manifests in three ways:
- Unaware: Organizations build their entire security program on compliance frameworks without realizing it limits their maturity.
- Aware but ignoring: They know compliance alone does not secure their product, but the program “works” so they avoid changing it.
- Hoping not to get caught: They understand the gap but bet that passing audits is sufficient.
The problem with compliance-driven programs:
- A SOC 2 report tells you an organization passed an audit. It does not tell you how their controls align with their actual infrastructure or business operations.
- Compliance frameworks ask you to do risk reviews, but few organizations actually use those reviews as inputs to create new projects or reduce risk.
- Compliance will take a program to a certain maturity level, but the next step requires risk quantification to produce actionable, prioritized results.
The shift from compliance-driven to risk-driven is what separates organizations that check boxes from those that genuinely reduce their attack surface. It aligns with how third-party risk management should work as well: assessing actual risk posture rather than collecting audit reports.
