Simon Glairy has spent his career at the intersection of insurance, risk management, and Insurtech. He helps boards and security leaders translate technical threats into business decisions, and his work on AI-driven risk assessment has shaped how companies evaluate and transfer cyber risk. In this conversation with Abigail Kai, he unpacks rising UK concerns, why cloud and vendor exposure still surprise executives, and how to thread prevention, preparation, protection, and response into a program that actually reduces loss severity and downtime.
Cyber ranks third globally in your Future Risks Report, with 69% of UK experts placing it in their top five. What’s driving that sentiment on the ground, and how does it differ by sector? Walk me through a recent UK incident, the timeline, and the key lessons learned.
The 69% figure reflects what I hear daily in UK boardrooms: cyber is now a business-continuity and reputation risk, not just an IT problem. Financial services worry about real-time payment fraud and regulatory scrutiny; healthcare worries about care disruption; manufacturers fear operational downtime and safety. Across sectors, a surge in high-profile UK incidents has sharpened awareness and shortened executive patience for half-measures. In a recent UK case, the timeline was brutally familiar: an initial foothold through a compromised vendor account late on a Friday, lateral movement overnight in the cloud console, and ransomware detonation before Monday’s stand-up. What changed the outcome was disciplined preparation—runbooks that actually matched production, segmented backups, and a tested crisis comms plan. The lesson was clear: prevention shrinks the blast radius, but rehearsed recovery protects the brand and restores revenue flow.
IBM pegs the average breach at $4.9 million in 2024 while SoSafe forecasts $10 trillion in cybercrime costs this year. Where do you see companies overspending or underspending? Share a case that shows how targeted investments cut loss severity and downtime.
Too many firms overspend on tools that don’t talk to each other and underspend on integration, hardening, and response readiness. I see shelfware licenses humming along while identity governance, backup immutability, and cloud configuration management lag behind. In one client case, we trimmed overlapping endpoint tools and redirected budget into identity: granular role design, privileged access controls, and conditional access policies. When an attacker tried to pivot, the identity stack throttled session risk and denied token reuse; the incident cost a fraction of the $4.9 million average and avoided prolonged downtime. The emotional shift inside the company was striking—teams went from panic to purpose because the controls they’d invested in actually changed the attacker’s math. That’s where ROI becomes tangible.
You warned we haven’t seen the full scale of AI in cyberattacks, including potential reverse engineering of patches. What scenarios worry you most? Describe one plausible attack path, the detection signals you’d expect, and the specific controls that would break the kill chain.
I worry about AI accelerating exploit development the moment a patch is released—diff the binaries, weaponize in hours, and target those who patch late or incompletely. A plausible path: the attacker scrapes a newly published patch, reverse engineers the vulnerable code path, and uses generative tooling to craft payload variants that evade basic signatures. They combine this with AI-driven phishing that mimics internal tone and cadence, tricking staff into approving access or pushing a malicious “hotfix.” Detection signals I’d expect include unusual service-to-service authentication requests, short-lived spikes in failed MFA followed by a successful login at an odd time, and cloud API calls chaining rarely used permissions. The kill chain breaks with layered controls: strict least privilege and just-in-time admin access, code-integrity enforcement, egress filtering that blocks command-and-control, and behavioral analytics tuned to identity and API anomalies. Above all, rapid validation of patches in a canary environment prevents rushed, misconfigured rollouts that attackers love to exploit.
Attackers are getting better at bypassing MFA. How should firms move to contextual MFA using location, time, and behavior? Outline the implementation steps, the metrics that prove it’s working, and a story where contextual signals blocked a real attempt.
Start by mapping critical access journeys—who needs what, from where, and when. Then implement risk-based policies: challenge or step-up authentication if the request appears from a new geography, an unusual time window, or deviates from learned behavior. Pilot with a subset of apps, iteratively tune false positives, then expand to privileged roles and third-party access. Metrics that matter include a visible decline in risky sign-ins reaching sensitive apps, lower help desk friction over time as policies stabilize, and fewer account takeovers despite increased probing. In one rollout, a finance user’s login attempt came from a plausible device but at a time they’d never worked and via a path they’d never used. Behavioral risk scored it high, triggered step-up, and the attacker failed the added checks. The user later said the prompt felt like a seatbelt click—momentarily noticeable, then reassuring.
You called cloud attacks a growing concern. What are the most common missteps you’re seeing in cloud configurations? Give a step-by-step hardening checklist, the telemetry teams should monitor daily, and an example where layered controls prevented lateral movement.
The big missteps are permissive roles, public exposure of storage by default, unmanaged service principals, and inconsistent guardrails across accounts and regions. A practical hardening checklist: baseline identity with least privilege; enforce MFA and conditional access; lock down storage access; enable logging at control plane and data plane; require encryption at rest and in transit; standardize network segmentation; implement key rotation; and block risky default settings with policy-as-code. Daily telemetry should include identity events, failed and anomalous logins, changes to security groups and route tables, privilege escalations, creation of new keys or service accounts, and data exfil indicators. In one case, an attacker obtained low-level access through a misconfigured token. Because segmentation and deny-by-default policies were in place, their lateral movement attempts hit walls, and cloud trail logs lit up a clear breadcrumb trail. The team contained quickly and rotated credentials before the attacker could touch sensitive data.
Zero-day exposure remains a pressure point. How do you structure a zero-day patching strategy when no fix exists? Walk through intake, triage, compensating controls, and validation, and share metrics that define acceptable risk during the window of exposure.
Intake starts with a cross-functional alert: threat intel, vendor advisories, and internal detections feed a single queue with clear ownership. Triage assesses exploitability in your environment—where the component runs, what privileges it holds, and whether it faces the internet. Compensating controls might include isolating services, disabling vulnerable features, tightening WAF rules, increasing inspection on relevant ports, and restricting outbound traffic. Validation relies on targeted detections for known indicators, controlled attack simulations in a safe environment, and documented sign-off that measures residual exposure. Acceptable risk during the window is defined by qualitative thresholds: critical assets isolated, monitoring heightened with no unexplained anomalies, and business processes confirmed to function with temporary restrictions. When the vendor releases a patch, you still stage, test, and roll out in waves to avoid self-inflicted outages.
Vendor attacks continue to bite. What does a thorough vendor assessment look like beyond a questionnaire? Detail the control evidence you require, continuous monitoring signals you trust, and an anecdote where proactive offboarding or segmentation saved a client.
Beyond questionnaires, I ask for evidence: architecture diagrams showing data flows, identity models, RBAC matrices, MFA enforcement proofs, and recent pen test or red-team summaries with remediation notes. I want to see backup posture and recovery testing logs, plus incident response playbooks that include notification timelines. Continuous monitoring signals I trust are identity anomalies tied to vendor accounts, changes in API behavior, drift in their IP reputation, and verification that their access adheres to least privilege. In one memorable case, we proactively segmented a vendor’s access to a single application gateway and enforced contextual MFA. When that vendor’s credentials were phished, the attacker hit a ring-fence and couldn’t hop to back-end systems. Offboarding was clean because we had a catalog of entitlements; within minutes, we revoked access and rotated keys without scrambling.
Your four pillars span prevent, prepare, protect, and respond/recover. Can you map these to a typical 12-month program? Share milestone examples, expected KPIs at each phase, and a case where the respond-and-recover pillar shortened business interruption.
Months 0–3 focus on prevent: maturity assessment, strategy definition, and prioritization of identity, cloud guardrails, and backup hardening. The KPI is clarity—documented gaps with owners, and the first wave of high-impact controls live. Months 4–6 shift to prepare: threat modeling, playbook creation, tabletop exercises, and tuning detection content. Success looks like faster escalation routes and cleaner handoffs across teams. Months 7–9 emphasize protect: deploy contextual MFA widely, finalize segmentation, and lock down third-party access. You want fewer risky sign-ins and tighter change control. Months 10–12 double down on respond/recover: run a full simulation, test restoration from backups, and refine crisis communications. In one engagement, that last pillar paid off when a weekend attack hit: the team followed the playbook, restored prioritized services in sequence, and avoided a prolonged outage that would’ve damaged customer trust. The air in the war room felt tense but composed; muscle memory replaced chaos.
Inside-out scanning is gaining traction over outside-in snapshots. What extra visibility does it unlock in practice? Describe the data sources you rely on, the cadence that works, and a story where inside-out findings averted a material incident.
Inside-out scanning sees what attackers will see after the first foothold—misconfigurations, overprivileged roles, unpatched internal services, and shadow assets. I rely on identity graphs, cloud configuration baselines, workload inventories, and application dependency maps, all correlated with endpoint and network telemetry. A weekly cadence for deep scans, with daily change diffs, keeps drift under control without overwhelming teams. In one case, inside-out scanning flagged a newly exposed management interface tied to a forgotten pilot. We shut it down the same day and tightened policy-as-code to prevent recurrence. That single catch likely prevented a cascade because the interface sat adjacent to critical data paths.
The proposed UK Cyber Security & Resilience Bill (introduced Nov 12) would regulate medium and large IT providers with mandatory reporting. How should service providers and their clients get audit-ready? Lay out the top five controls, evidence to gather, and a mock walkthrough.
Audit readiness starts with clarity on obligations and a repeatable evidence trail. Top five controls: robust incident detection and reporting, strong identity and MFA for staff and clients, secure configuration baselines for cloud and on-prem, vendor and supply chain oversight, and tested response and recovery. Evidence includes alerting runbooks, sample incident tickets with timelines, access control logs, configuration policies and exceptions, vendor assessment artifacts, and recovery test reports. A mock walkthrough goes like this: the auditor asks for a recent incident—show the detection, triage notes, escalation timing, and notification steps. Next, they review an access change—produce approval, implementation, and verification logs. Then, they sample a vendor with privileged access—present segmentation diagrams and continuous monitoring results. Finally, they ask for proof of a recovery test—show the plan, execution notes, issues found, and improvements made. Keep it narrative, not just artifacts; auditors appreciate context.
As deepfakes become more convincing, how do you design training that actually changes behavior? Share real-world examples used in simulations, the policy updates that support them, and the reporting process that helps staff flag suspected deepfakes quickly.
Effective training uses uncomfortable realism: a voicemail with a familiar voice asking for an urgent funds release, a video message that looks like a senior leader pushing a last-minute “deal,” or a chat that mirrors internal slang. We pair these with clear policies: no financial or credential changes based on voice or video alone, mandatory out-of-band verification, and use of unique passwords and MFA as standard practice. The reporting process must be muscle memory—one-click reporting in mail and chat, a hotline for suspicious voice messages, and a promise of rapid, judgment-free follow-up. After simulations, we run debriefs highlighting what worked and where instincts misfired. Staff tell me the sensory details—the slight audio lag, the unnatural blink—stick with them. That stickiness is the point.
You mentioned the London market’s focus on sustainability, underwriting discipline, and aggregation management. What data most improves underwriting quality today? Explain your evaluation flow from submission to bind, and cite metrics that indicate healthy portfolio diversification.
The strongest underwriting lift comes from operational controls data—identity governance posture, cloud configuration baselines, backup and recovery practices, MFA coverage, and continuous monitoring methods like inside-out scanning. My flow is simple: ingest the control story, validate with evidence, align it to the four pillars, and judge insurability based on discipline and consistency. Aggregation is managed by mapping shared exposures—cloud regions, key vendors, and critical software. Healthy diversification looks like balanced sector spread, controlled concentrations in major cloud environments, and a portfolio where resilience practices are not just stated but demonstrated. In the London market, that discipline creates sustainability for clients and carriers alike.
With breach costs rising, how should boards measure cyber ROI beyond compliance? Offer a simple scorecard, show how to tie controls to loss frequency and severity, and give an example where board oversight shifted funding and moved risk materially.
I advise a scorecard aligned to business outcomes: time to detect and contain, integrity of backups and restoration readiness, identity assurance across key roles, and vendor access hygiene. Tie controls to frequency by tracking how often risky authentications and misconfigurations reach production; tie to severity by mapping how segmentation and recovery speed reduce business interruption. In one board, we reframed spend from “more tools” to “fewer, better integrated controls” around identity and recovery. Funding shifted toward contextual MFA, privileged access, and tested restoration. When an attack came knocking, the event was contained quickly, and the board saw in real time how those choices converted into reduced loss severity compared to the $4.9 million average.
For organizations modernizing MFA, cloud defenses, and vendor controls at once, what’s the smartest sequencing? Outline a 90-day plan, the top dependencies to resolve first, and a war story where getting the order right made the difference during an attack.
Sequence identity first, then cloud guardrails, then vendor hardening, with continuous detection tuning threaded through. In the first 30 days, deploy contextual MFA to critical apps and privileged roles, catalog third-party access, and set baseline cloud policies. Days 31–60, expand conditional access, enforce storage and network controls, and begin segmenting vendor connections. Days 61–90, finalize least-privilege models, tighten API permissions, and run a full playbook exercise. The key dependencies are identity inventory accuracy, functioning logging, and a business-backed exception process. In one “war room” weekend, the attacker tried to ride a vendor’s access to jump across environments. Because identity policies were solid and cloud guardrails were already in place, their path collapsed. By Monday, operations were steady, and the vendor’s tokens were rotated without drama.
Do you have any advice for our readers?
Treat cyber as a living system, not a project with an end date. Anchor your program in the four pillars—prevent, prepare, protect, and respond/recover—and measure progress in how smoothly you can execute under stress. Lean into controls that change attacker economics: contextual MFA, least privilege, segmentation, and tested recovery. And remember, we haven’t seen the full scale of AI-enabled attacks yet; the time to build resilience is before the sirens start, not after.
