Cyber & AI Clarity

A cyber incident doesn’t need to compromise an NHS organisation directly to disrupt patient care.

A critical supplier can be attacked. A shared service can become unavailable. An identity compromise somewhere in the dependency chain can have consequences far beyond the system where the incident began.

That creates an important question for those of us responsible for cyber risk in healthcare:

Where does our security boundary actually end?

I think there are two different boundaries we need to consider.

There is the organisational security boundary — the technology, identities, infrastructure and services we directly own or control.

And then there is the clinical resilience boundary — everything a critical clinical service depends on to continue operating safely.

Those two boundaries are not necessarily the same.

In the video, I explore what that distinction means in practice — from third-party dependency and credible attack paths to identity, detection, AI and recovery.That distinction changes how I think about cyber risk.

Rather than starting with vulnerabilities, threat actors, dashboards or control frameworks, I prefer to start with the clinical service we cannot afford to lose — and work backwards.

What technology enables it?

Which identities and privileged accounts can affect it?

Which suppliers and shared services does it depend on?

What credible attack paths could disrupt it?

Would we detect those paths early enough to respond?

And if prevention and detection both failed, could the clinical service continue operating and recover?

That creates a very different view of cyber risk.

In this episode of Cyber & AI Clarity, I explore that approach using recent healthcare incidents, threat intelligence and practical examples from cybersecurity and assurance work across NHS environments.

The objective isn’t to create another list of NHS cyber threats.

It’s to answer a more useful question:

How could cyber threats actually disrupt the clinical services we’re responsible for protecting — and what should we do differently as a result?

Thanks for reading Cyber & AI Clarity! Subscribe for free to receive new posts and support my work.

I’ve reviewed SOC and MDR reports showing impressive-looking detection coverage.

70%. 80%. Sometimes higher.

My immediate reaction to a number like that is usually:

80% of what?

It sounds like a simple question, but it can lead to a very different conversation about how effective the service actually is.

MITRE ATT&CK mapping is useful. It can help us understand which techniques our detection rules are designed to identify and highlight potential gaps.

But there’s a distinction I think we need to be careful about:

A technique being mapped to a detection rule doesn’t necessarily mean we’ve demonstrated that we can detect it.

And even if we could detect every technique in a framework, I’d still want to know whether we’re particularly good at detecting the techniques and behaviours most relevant to our organisation.

That’s why, when I assess a SOC or MDR capability, I like to work backwards from the threat.

Who is realistically likely to target us?

Why?

How are those threat actors operating?

And what would a credible attack against our organisation actually look like?

From there, I can build scenarios and look at the SOC through three fairly simple lenses:

Visibility. Detection. Response.

Do we have the telemetry to see the activity in the first place?

If we can see it, do we have the capability to recognise it as suspicious?

And if we detect it, can we respond quickly and effectively enough to make a difference?

That last part is important.

A beautifully mapped detection matrix can give us confidence on paper. What I’m really interested in is how much of that capability we’ve actually demonstrated.

This is where validation becomes valuable.

Purple-team exercises, for example, can emulate representative behaviours and show whether the expected telemetry appears, whether detections trigger, and whether the SOC responds as expected.

Sometimes they confirm what we thought.

Sometimes they expose gaps between assumed coverage and demonstrated capability.

Both outcomes are useful.

In this episode, I walk through the approach I use to connect an organisation’s threat profile to its SOC or MDR capability, and why I think coverage percentages need to be treated with a little more care.

The question I ultimately want answered isn’t:

“What percentage of MITRE ATT&CK do we cover?”

It’s:

“Can we detect and respond to the attack scenarios that actually matter to us?”

If I became your CISO tomorrow, I wouldn’t start with your vulnerability count, dashboards or security tools.

I’d start with five questions:

1. What are we actually trying to protect?2. What threats genuinely matter to us?3. Where are we most exposed?4. Could we detect and respond when it matters?5. What decisions are we currently making without enough clarity?

In this episode of Cyber & AI Clarity, I explain why these questions tell me more about where to start than a stack of operational security metrics.

Cybersecurity doesn’t need more complexity. It needs better decisions — and better decisions start with clarity.

— Sandeep Jaryal

Also Available On:

* Spotify

* YouTube

* Amazon Music

If you prefer listening to podcasts on these platforms, we'd be delighted if you subscribed there as well. Your support helps us reach more cybersecurity professionals with these critical insights.

Why This Matters Now

In 2025, as AI becomes increasingly embedded in critical business operations, a new breed of sophisticated attacks has emerged targeting these systems. Unlike traditional cybersecurity threats, AI-specific vulnerabilities can remain undetected for months while causing devastating damage.

The recent NeuroToxin attack demonstrated just how vulnerable enterprise AI systems can be when proper security posture management isn't in place. Several major financial institutions lost over £30 million to fraudulent transactions because attackers had poisoned their AI training data—and their monitoring systems never detected the compromise.

Is your organisation prepared for this new threat landscape?

Episode Highlights

In this technical deep dive, we explore:

* Introduction to AI Security Posture Management — What AISPM is and why it has become critical in 2025

* The NeuroToxin attack — Real-world consequences when AI security fails and how attackers compromised systems without detection

* AI vs. Traditional Security — Why securing AI requires different approaches than conventional cybersecurity

* AISPM Framework Components — The five essential pillars of effective AI security management

* Technical Implementation — Specific controls and measures to protect AI systems throughout their lifecycle

* Industry-Specific Approaches — How healthcare and financial services should adapt their AI security strategies

* Documentation Standards — The importance of AI Bills of Materials (ABOMs) and what they should contain

* Regulatory Landscape — How the EU AI Act and UK's AI Safety Framework are shaping security requirements

* Emerging Threats — Future challenges in AI security including quantum computing implications

* Practical First Steps — Three essential recommendations for organisations just beginning their AISPM journey

Key Takeaways

1. AI Systems Create Unique Security Challenges

Traditional security approaches fall short for AI systems because they:

* Operate probabilistically rather than deterministically

* Learn from data, creating new vulnerabilities in the training pipeline

* May appear to function normally even when compromised

* Have complex, often opaque decision-making processes

2. The Five Pillars of AI Security Posture Management

Effective AISPM requires:

* Comprehensive inventory of all AI systems, including those embedded in third-party tools

* Risk classification based on each system's potential impact

* Technical controls across the entire AI lifecycle

* Governance frameworks for development, deployment, and incident response

* Continuous monitoring for statistical anomalies and suspicious patterns

3. Technical Implementation Priorities

For organisations beginning their AISPM journey, focus on these areas first:

* Cryptographic verification of training data integrity

* Statistical anomaly detection in AI outputs

* Strict access controls for AI development environments

* Basic monitoring for unusual patterns or behaviours

* Clear documentation of AI components using ABOM standards

Actionable Advice

If you're just starting to address AI security in your organisation:

* Conduct a thorough AI inventory Identify every AI system in your environment, including those embedded in third-party tools or developed without central oversight.

* Implement basic monitoring Focus on your most critical AI systems first. Look for statistical anomalies in outputs and unusual access patterns.

* Establish clear governance policies Define who can approve new AI models, what security testing is required before deployment, and how incidents involving AI systems will be handled.

Remember that effective AISPM is an ongoing programme, not a one-time project. Start with these fundamentals, then build your capabilities incrementally.

Resources Mentioned

* NCSC Guidance on AI Security — Practical advice without overwhelming technical jargon

* OWASP AI Security and Privacy Guide

* NIST AI Risk Management Framework — Comprehensive guidance on securing AI systems

* CISCO — Open-source tools for implementing AI security controls

Next Week's Episode

Join us next week as we explore post-quantum cryptography and its implications for enterprise security. Learn how quantum computing advancements will impact your current encryption methods and what you should be doing now to prepare.

Subscribe to this newsletter to get notified when the episode drops!

Share Your Thoughts

Are you concerned about AI security in your organisation? What challenges are you facing in securing your AI systems? Share your thoughts in the comments—I read and respond to all of them.

Remember, in cybersecurity, every treat can hide a trick. Stay vigilant!

Disclaimer: Please do your own research before following any advice.