Why I'm writing about this
I'll be honest → I am not one of those people who loves cybersecurity. Shocking, right?
But like many internal PMs, security shows up in my work all the time. Compliance deadlines. Designing products that won't get hacked. Defending why a security feature deserves a sprint when there's a shiny new request waiting.
And the hardest part? Communicating it to leadership.
Because when you frame security as "must do, no value," leadership hears "low impact." They quietly drop you into the maintenance bucket and refocus on the team doing innovation.
That's a framing problem. For both sides.
So let's fix it together.
The mindset shift
Security work is not the absence of value.
It's the protection of every other piece of value your company has built.
→ The customer trust you've spent years earning
→ The revenue running through your systems right now
→ The brand reputation that took a decade to build
→ The regulatory license that lets you operate at all
When you protect those things, you're not "maintaining." You're keeping the entire business running.
I strive to be a great PM, and I am sure you are too, since you are reading this newsletter weekly.
So let's get out of the must-do boring attitude and call this what it really is. We position security as risk management → which is exactly what leadership cares about.
What PMs are actually responsible for in security
Security is not "the security team's job." Here's where you, as the internal PM, own it:
→ Designing with security in mind: making sure new features don't introduce new attack surfaces
→ Prioritizing security debt: deciding when to pay down vulnerabilities vs. ship new things
→ Translating risk to leadership: turning CVE scores into business impact
→ Cross-team coordination: security teams, legal, compliance, and engineering all have a stake
→ Roadmap protection: defending the time and budget needed for security work
You don't need to be a security expert. You need to be the person who makes security visible and understood.
Real attacks. Real costs. Real industries.
Here's what's been happening in 2025 and 2026.
If it feels like a far-away nightmare, let me bring it a bit closer to home. Not to scare you (okay, maybe just a little, because I don't want to be alone here), but to show how you, as a product manager, must be involved to prevent this from happening in your work.
These are not hypotheticals → they are public, documented, and painful.
I've reframed each one from a PM hot-seat angle. Read it as if you owned the product.
Postal & Banking → La Poste, December 2025
Hypothetically: You work for La Poste. You build an API for the web app. You don't think it will be used much, so you don't design for controls or rate limits. And then...
Very real scenario: A DDoS attack hit France's national postal service and its banking arm days before Christmas. Websites and apps went offline. Parcel deliveries slowed during the holiday rush, right when volumes peak.
Read more: La Poste announcement
Retail → Marks & Spencer, April 2025
Hypothetically: You're the PM for the internal customer support tools. The service desk uses an app to reset employee credentials. You never thought to add identity verification beyond a phone call, because who would fake being an employee? And then...
Very real scenario: Attackers used social engineering to trick the service desk into resetting credentials. They deployed ransomware through a third-party contractor and shut down online ordering, click-and-collect, and contactless payments for nearly six weeks during Easter. Pre-tax profits fell from £391.9 million to £3.4 million in six months.
Read more: Integrity360 coverage
Manufacturing → Jaguar Land Rover, August 2025
Hypothetically: You're the PM for the manufacturing execution system. Your factory floor runs on it 24/7. You knew the OT/IT integration had some quick patches that needed cleaning up, but production volume was always the priority. And then...
Very real scenario: JLR detected unusual activity and shut down internal systems to contain it. UK plants in Halewood and Solihull went offline. Workers stayed home. Vehicle production stopped. The ripple effect hit thousands of supply chain businesses.
Read more: CM Alliance coverage
Aviation → Collins Aerospace vMUSE, 2025
Hypothetically: You're the PM for an airport check-in platform. It runs at 20+ airports. Your disaster recovery plan exists on paper but hasn't been tested in 18 months, because rehearsing it would mean downtime. And then...
Very real scenario: A ransomware attack on the vMUSE platform forced airlines back to manual processes. Operations were disrupted at over 20 airports, including Heathrow, Frankfurt, and Amsterdam Schiphol. Thousands of flights delayed or cancelled.
Healthcare → DaVita, 2025
Hypothetically: You're the PM for a patient records system. You know the database holds millions of records. Encryption-at-rest was on the roadmap for "next quarter," for the past three quarters. And then...
Very real scenario: The Interlock ransomware group exposed about 2.7 million patient records in a single attack. Healthcare data breaches now average $9.7 million per incident → the highest of any industry.
The pattern? Every single one of these started small. A third-party vendor. A weak API. A help desk getting socially engineered. A backup that was never tested.
This is the part to bring into your next leadership conversation. Not fear → context.
Translating vulnerabilities into business language
When developers say "critical CVE," leadership hears noise.
Your job is to turn it into numbers and outcomes leadership recognizes.
This is where the FAIR framework comes in.
What FAIR is
FAIR stands for Factor Analysis of Information Risk. It's the only international standard for putting cyber risk into financial terms. Instead of red/yellow/green severity ratings, you get euros and probabilities.
How to calculate with it (the simple version)
The core formula is:
Annual Risk = Loss Event Frequency × Loss Magnitude
Where:
→ Loss Event Frequency (LEF): how many times per year you'd realistically expect this to happen
→ Loss Magnitude: average cost when it does happen (downtime + remediation + fines + reputation hit)
That's it. Two numbers.
A worked example
Let's take "Unprotected internal API" → the La Poste scenario.
→ Frequency: 2 incidents per year (medium-high probability based on how exposed the endpoint is)
→ Magnitude: €150K per incident (downtime, customer support load, remediation, brand hit)
→ Annual risk: €300K
Now compare that to the cost of fixing it. Maybe 3 sprints of engineering time = €60K.
Suddenly your "boring security work" pays itself back in under three months. That's a sentence leadership can act on.
10 common vulnerabilities, mapped
Below are 10 vulnerabilities I see come up most often in internal PM work, with rough FAIR-style numbers attached. The chart further down maps them by likelihood and business impact so you can see which ones to fight for first.
Numbers are illustrative → yours will differ based on your industry, scale, and exposure. Use them as a starting point for the conversation with your security team.
The matrix gives you a one-page view to take into a leadership meeting. Anything in the top-right "Act immediately" zone is your strongest case for budget.
Free resource if you want to go deeper: FAIR Institute
Communication frameworks that actually work
Here are six framings worth keeping in your back pocket:
1. The If/Then framing "If we don't address this by Q3, then we expose ourselves to a Marks & Spencer style outage. Six weeks offline. Pre-tax profits down 99%." → Use for: urgency
2. Risk = Likelihood × Impact Quantify both. Even rough estimates beat vague warnings. → Use for: prioritization decisions
3. Cost of inaction vs cost of action "Fixing this costs us 3 sprints. Not fixing it has a €200K expected annual loss. We pay back the investment in 18 months." → Use for: budget conversations
4. The peer comparison "Three competitors in our space were hit this year. Here's what it cost them." → Use for: getting executive attention
5. The trust narrative "Our growth depends on customer trust. One breach, and the next 12 months of our roadmap stalls because we'll be in remediation mode." → Use for: connecting security to existing leadership priorities
6. The insurance analogy "You don't buy car insurance because you plan to crash. You buy it because the downside is unsurvivable." → Use for: when leadership says "but nothing has happened yet"
Pick the one that matches your audience. Engineering leaders respond to numbers. Commercial leaders respond to peer comparisons and trust narratives.
Can AI do this for me?
I ask myself this question with every task these days. Here's where I landed for security work:
AI is bad at:
→ Influencing stakeholders (it has a reputation for confidently making things up, which is the last thing you want in a security conversation)
→ Reading the room in a leadership meeting
→ Knowing what your specific organization actually cares about
AI is genuinely useful for:
→ Drafting threat models for new features (a real security expert will catch things a generalist AI won't, but the draft saves hours)
→ Scanning code for known vulnerabilities → tools like Snyk, GitHub Advanced Security, and Semgrep do this well
→ Writing the first version of a risk register
→ Translating technical findings into business language (great starting drafts, then you edit)
→ Helping you prep for a leadership conversation by playing devil's advocate
