Security programs fail not because of missing tools, but because of misaligned language, poor prioritization, and the inability to translate technical risk into business impact. Chris Hodson, CISO at Cyberhaven and author of the Amazon UK #1 bestselling Cyber Risk Management book, has spent 22 years in security across financial services and Bay Area tech companies including Zscaler, Tanium, and Contentful. In this episode, he shares how to align security in DevOps environments without demanding a one-to-one headcount ratio, why CISOs should stop showing firewall dashboards to executives, and how traditional DLP is fundamentally broken.
You can read the complete transcript of the episode here >
How do you align security responsibilities in DevOps environments?
You cannot ask your CFO for one security hire per engineer. That pitch gets laughed out of the room. The only scalable approach is enabling semi-autonomous engineering teams that understand security themselves.
- Act as a consultant, not a gatekeeper: The security team defines artifacts, processes, and reference material. Engineers then apply those themselves — checking session handling requirements, reviewing encryption standards, running through sample threat models.
- Find your diamonds: Every engineering organization has three or four people who play with Kali Linux in their spare time or attended OWASP meetups. Find them, train them, and develop them into security advocates. This is more effective than a generic “security champions program” label.
- Get engineers to think about what could go wrong: The default engineering mindset is optimistic — ship features, move fast. Security’s job is introducing the complementary question: what could go wrong here? Threat modeling does not need to be formal or heavy to be effective at this stage.
- Accept that it depends: Company size, vertical, culture, hybrid/remote structure — all affect how security integrates with DevOps. There is no one-size-fits-all playbook for DevSecOps.
What are the biggest challenges in building security programs?
Chris identifies two fundamental constraints that every CISO faces:
- Fighting for headcount: Security teams within engineering organizations compete for budget against SREs, frontend developers, and product designers. The macroeconomic environment of 2023 makes this worse — security is under more scrutiny than two or three years ago when companies had more disposable operational budget.
- Proving security’s value: It is hard to prove a negative. You cannot easily show what did not happen because of security investment. The CISO now needs to be a mini-CFO — tracking budget versus actuals, quantifying why specific investments matter, and translating all of it into language the business understands.
The solution to both: stop talking about process injection and DDoS to non-security audiences. Start talking about business impact. If you cannot connect a security initiative to a business problem, go back and rethink your prioritization.
How should CISOs communicate security posture to leadership?
Chris shares a hard-won lesson: technical dashboards and risk scores do not resonate with executives.
- Use OKRs instead of KPIs: Chris defines six objectives per fiscal year — ranging from compliance posture to product security enablement — each with quarterly or monthly key results. OKRs get executive buy-in because they align with how leadership already thinks about company goals.
- Aim for marginal gains, not gold-plated targets: Objectives like “achieve 99% agent health on all endpoints” will never be met and erode credibility. Incremental improvements that compound over time are more honest and more achievable.
- Tie metrics to things the business already cares about: SOC 2 compliance is a sales differentiator. Privacy request response times matter to legal. Supplier due diligence speed matters to partnerships. Frame security metrics around existing business priorities.
- Keep risk scores internal: Your EDR tool’s risk score is useful for the security team’s operations. It means nothing to a CFO. Translate that score into compliance posture, incident readiness, or customer trust impact before presenting it upward.
This approach to executive communication is consistent with what works in security risk management more broadly — speaking the language of business outcomes rather than technical capabilities.
How should organizations approach cyber risk management?
Chris uses a structured framework: actors initiate events, events exploit vulnerabilities, exploitation causes business impact. Working through each component:
- Start on the left — know your adversaries: Do not design your security architecture to defend against nation-state actors if they are not in your threat profile. A company with a $1M annual security budget cannot and should not spend it on seven layers of malware sandboxes for hypothetical APT scenarios.
- Understand the techniques that matter: If intellectual property theft is your primary risk (common in pharma or growth tech), focus on the specific techniques associated with that — insider threats, unauthorized access, data exfiltration paths.
- Get business help on the right side — business impact: Security teams can identify threats and vulnerabilities, but they need business stakeholders to define what is actually important: quarterly results data before public disclosure, personal information, payment data, source code. Data owners must be involved.
- Use common language: Getting executives to understand the difference between a threat actor, a vulnerability, and exploitability is more valuable than any dashboard. This shared lexicon is the foundation everything else builds on.
The key principle: start slow. Set foundations for a wider program rather than going in with the theoretically perfect risk framework on day one. Threat modeling is particularly effective for building this common language early.
Why is traditional DLP broken?
Chris makes a direct case that legacy data loss prevention does not work in modern environments:
- Regex and static pattern matching cannot keep up: Users change file names, copy-paste content out of files, encrypt data, archive it, and move it through paths that DLP rules never anticipated. People are industrious — if motivated, they will find ways around prescriptive file-level controls.
- The real need is understanding data flows: Rather than trying to prescriptively block every egress vector, organizations need to understand how data moves — who touches it, where it goes, and what risky behaviors look like.
- Data detection and response (DDR) is the evolution: Similar to how EDR replaced static signature-based AV because prevention alone was insufficient, DDR focuses on detecting risky data movements and responding quickly. If someone downloads a file, archives it, sends it to a colleague, who then uploads it to an unauthorized channel — that lineage needs to be visible for incident response.
- Classification is still the foundation: If you are not classifying your data, you cannot know which repositories to monitor. But classification alone — without understanding flow and behavior — is insufficient for actual data protection.
Chris recommends the Data Security Maturity Model (DSMM), aligned to NIST CSF, as a framework for elevating data security from a second-class concern to a first-class program.
What role does AI play in security — and what are the risks?
Chris sees generative AI as both a blessing and a curse:
- Where it helps security teams: Static code analysis assistance, false positive reduction, vulnerability exploitability qualification, strategy documentation preambles, and enriching SOC analyst triage at early funnel stages.
- Where it creates new risk: Employees unknowingly upload confidential information into LLMs for productivity — customer emails, internal documentation, patient records. Cyberhaven’s research showed the volume of sensitive data flowing into ChatGPT shocked CISOs and privacy officers who had no visibility into it.
- Will it replace security jobs? No. If ChatGPT can fully replace a security analyst’s job, that job was probably not well-defined. AI enriches and augments existing roles — making analysts faster at triage, helping engineers review code more efficiently — but it does not replace the judgment, context, and authority that humans provide.
- The authority problem: If AI-generated code (GitHub Copilot) is being reviewed by AI (ChatGPT), where does the authoritative decision come from? This cyclical loop of AI marking AI’s homework has no good answer yet.
How does Chris rate common security practices?
- Periodic security audits for vulnerability identification: Super important — rated high. Finding misconfigurations and vulnerabilities quickly is critical because those are what actually get exploited. The scope should extend beyond your own systems into supply chain dependencies.
- Training and awareness programs for employees: Massively important — but not annual click-through compliance training. Real training means brownbag sessions, lunch-and-learns, topical email campaigns, and creating a culture where people feel comfortable reporting mistakes (“I clicked a link”) rather than hiding them. Getting rid of the “I’ll get in trouble” culture is the real goal.
