Category Archives: Security

Every Face on the Call Was a Deepfake. 25 Million Dollars Later, Nobody Had Checked.

Posted on by

A finance employee at engineering firm Arup joined a video call with who appeared to be the company’s CFO and several colleagues. Every face on the call was a deepfake. Over 15 transfers, the employee authorised roughly 25 million dollars. That single incident, from Arup’s Hong Kong office, is now one line item in a fraud category that a 2026 Surfshark study puts at 3.7 billion dollars in publicly documented losses worldwide, the current figure at the time of publishing, and that figure almost certainly understates the real total.

A Genuinely Global Fraud Category

The Surfshark research, drawing on the AI Incident Database, Resemble.AI and OECD records, breaks the losses down by country rather than treating this as one region’s problem. The United States accounts for 712 million dollars, 43 per cent of it corporate. Malaysia reports 502 million dollars, driven largely by investment scams. Hong Kong sits at 229 million dollars. Indonesia’s losses come almost entirely from fraudulent loan applications. The United Kingdom reports 149 million dollars, much of it celebrity-impersonation investment scams. No single region owns this problem, and the methods vary by market as much as the targets do.

The Real Number Is Almost Certainly Higher

The study’s authors flag a specific limitation worth taking seriously: fewer than 5 per cent of voice-clone fraud victims ever report their losses. That means 3.7 billion dollars is a floor, not a ceiling, built entirely from cases that became public. For every Arup, a large, sophisticated organisation with the resources to disclose and investigate publicly, there are almost certainly dozens of smaller incidents that never surface in any database.

When the Defence Actually Worked

Not every attempt succeeds, and the near-misses are instructive. At LastPass, an employee received what sounded like a deepfake audio call from the CEO over WhatsApp and grew suspicious specifically because the channel itself was unusual, a legitimate CEO request would not normally arrive that way. That single procedural instinct, noticing the wrong channel rather than scrutinising the voice, stopped the fraud. It is a reminder that detecting deepfakes technically is often less reliable than training people to notice when a request arrives through an unexpected route or bypasses a normal approval step.

What This Means for Finance and PMO Controls

The Arup case succeeded because a live video call was treated as sufficient authorisation on its own for a high-value transfer. That control gap exists in most organisations, a request that looks and sounds right, delivered through what appears to be the normal channel, still gets treated as verified. The practical fix does not require deepfake-detection software as a first line of defence. It requires a callback protocol for any high-value transfer request, verified through a separate, previously agreed channel, regardless of how convincing the original request appeared. A PMO or finance transformation programme introducing new payment or approval workflows should build that callback step into the process design itself, rather than leaving it as a training slide nobody reviews again after induction.

The Setting Was Wrong for Ten Years. 2.15 Million People Paid For It.

Posted on by

Cloud misconfiguration accounted for 14 per cent of confirmed breaches globally in the first quarter of 2026, up from 9 per cent in 2024, according to security analysis built on Verizon’s Data Breach Investigations Report (DBIR). It has not overtaken vulnerability exploitation as the leading cause of breaches overall, but it is the fastest-growing technical vector in the data, and the gap between how many organisations use multiple clouds and how many can actually secure them consistently is the reason why.

 

An Old Problem Getting Worse, Not Better

More than three quarters of organisations now run multiple cloud providers, and 66 per cent of them say maintaining consistent security controls across those environments is genuinely difficult. Nearly a third of cloud resources go unmonitored entirely, carrying an average of 115 unpatched vulnerabilities each, and the average configuration issue sits undetected for around 180 days before anyone finds it. Multi-cloud strategy has become standard practice faster than the tooling and staffing needed to secure it consistently, and 45 per cent of organisations admit they simply do not have adequate staff for the challenge.

 

What This Actually Looks Like

The consequences are not hypothetical. One documented incident exposed personal data and location details for 2.15 million connected vehicle users, left publicly accessible for nearly a decade because of a single unaddressed misconfiguration. Another exposed 38 million personal records, names, emails and phone numbers, across 47 separate organisations, including government agencies, through one configuration error in shared enterprise software. Neither incident required a sophisticated attacker. Both required someone to notice a setting that had been wrong for years.

 

A Global Technical Problem, Uneven Regulatory Response

This is not a story about one cloud provider or one region. AWS, Azure and Google Cloud environments all appear in the underlying breach data, and the DBIR’s own methodology draws on incidents reported by law enforcement agencies and computer emergency response teams worldwide. The regulatory response so far is patchier than the problem. The US has moved furthest, with Cybersecurity and Infrastructure Security Agency (CISA) mandating federal agencies secure their cloud environments to a defined standard, but most jurisdictions still treat cloud misconfiguration as a subset of general data protection obligations rather than a distinct, named risk category with its own enforcement expectations.

 

What a PMO Should Actually Check

A technology steering committee reviewing cloud risk should ask a narrower, more useful question than whether cloud security policies exist. It should ask what percentage of cloud resources are actively monitored right now, how long a misconfiguration typically sits before detection in this specific environment, and whether that number has ever been measured at all. A policy document proves intent. It does not prove that a setting exposing 2.15 million users has not been sitting open for years. Multi-cloud strategy delivered real flexibility. The security discipline to match it is still, for most organisations, a work in progress rather than a finished job.

Your Data Might Already Be Stolen. Nobody Can Read It Yet.

Posted on by

Somewhere right now, encrypted data belonging to your organisation is very possibly being copied and stored by someone who cannot read it yet. That is the entire premise of harvest now, decrypt later, and two governments have just put binding migration deadlines around the assumption that this is already happening.

 

The Threat Nobody Can See Happening

Harvest now, decrypt later works in three stages: an adversary intercepts and stores encrypted traffic today, holds onto it, and waits for quantum computing to mature enough to break the encryption later. The NSA, CISA and NIST have all warned that this is already happening rather than a future scenario, with government communications, healthcare and genomic records, financial transaction histories and long-lived proprietary research flagged as the categories of data most exposed, precisely because their value does not expire when the encryption eventually does. The unsettling part is that an organisation has no way of knowing whether its own traffic has already been harvested. There is no breach notification for data that was quietly copied rather than stolen outright, years before anyone could do anything with it.

 

Two Governments, Two Deadlines, One Shared Conclusion

The United States moved first. NIST finalised its first post-quantum cryptography standards in August 2024, and the NSA’s CNSA 2.0 framework now requires quantum-safe algorithms on all new national security systems from January 2027, full application migration by 2030, and complete infrastructure migration by 2035. The UK’s National Cyber Security Centre published its own roadmap in March 2025, structured differently but arriving at the same endpoint: identify and plan by 2028, execute high-priority upgrades between 2028 and 2031, and complete migration across all systems, services and products by 2035. Two governments, working independently, converged on the same twenty-year horizon and the same conclusion that this cannot be left until quantum computers actually arrive.

 

Why the Slow Timeline Is the Argument, Not the Excuse

It would be easy to read a 2035 deadline as a reason to defer this for years. That reading gets the risk backwards. Cryptographic migration across a large organisation’s systems, vendors and data stores typically takes five to ten years to execute properly, which means an organisation starting its inventory and planning today is already working to a tight schedule against either government’s timeline, rather than a comfortable one. Industry analysts project the post-quantum cryptography market will exceed 15 billion dollars by 2030, and enterprises are being advised to allocate 2 to 5 per cent of annual security spend to migration over a four-year window. The bottleneck was never algorithm development. NIST has already published the standards. The bottleneck is inventory, sequencing and the unglamorous, multi-year discipline of finding every system that needs to change.

 

What a PMO Should Do With This Now

Post-quantum migration belongs on a technology roadmap as its own workstream, rather than folded quietly into general infrastructure refresh budgets where it will lose priority against anything more visible. The first deliverable is not a pilot project. It is an inventory: which systems, vendors and data categories carry encryption that needs to survive into the 2030s, ranked by how long that data needs to stay confidential. Anything meant to remain secret beyond 2030 is already, by definition, running on borrowed time.

The Ransom Bought Silence. It Never Bought Certainty.

Posted on by

 

On 19 September, the extortion group ShinyHunters broke into the dark web leak site run by Cl0p, one of the most prolific ransomware operations of the past two years, and defaced it. Three days later Cl0p was still trying to regain control, and every company that quietly paid Cl0p to make a breach disappear had a new, uncomfortable question to answer.

What ShinyHunters Actually Took

ShinyHunters exploited an unauthenticated file upload flaw in Grav CMS, the content management software Cl0p used to run its own site, and used the access to claim Cl0p’s source code, its CMS plugins, its system logs, and the private cryptographic keys protecting Cl0p’s Tor hidden service address. The keys matter more than the defacement. As ShinyHunters put it, having Cl0p’s onion keys means it can run the same dark web address from its own infrastructure even if Cl0p regains its server, so if Cl0p kicks the group out, ShinyHunters claims, it would not matter at all.

 

The Demand Escalates by the Day

The initial demand, made on 19 September, was an eight-figure sum, which ShinyHunters described as 2.333% of its own claimed net worth. By 21 September the group had raised the price to everything Cl0p made from its 2025 Oracle E-Business Suite data theft campaign, plus more, and with interest, adding a demand for a public apology and a clause that the total rises every 24 hours Cl0p stays silent. Cl0p’s own response, once it regained partial control of the site, was to remove the defacement and claim ShinyHunters’ contact email did not work, an avoidance move rather than a denial.

 

Why This Should Worry Organisations That Paid Cl0p, Not Just Cl0p

ShinyHunters has also threatened to publish the identities of every company that paid Cl0p a ransom, the amounts involved and the Bitcoin addresses used to pay it, tied directly to Cl0p’s Oracle EBS campaign. That threat has nothing to do with any organisation’s own security posture today. It depends entirely on whether a rival criminal group decides to make good on an extortion demand against a competitor, a decision an affected company has no way to influence and no visibility into. Any organisation that treated a Cl0p ransom payment as a closed incident, in exchange for a deletion promise from a criminal group, is discovering that a criminal’s word was never the same thing as a resolved risk.

 

The Real Governance Lesson Here

None of this is confirmed by Cl0p or by a neutral party. Every figure above comes from ShinyHunters’ own claims, corroborated across multiple independent outlets but not yet verified by Cl0p or a third party. That uncertainty is itself worth carrying into the next risk review. An incident an organisation paid to make disappear can resurface years later, at a time and in a form it does not control, because the decision to disclose sat with a criminal the whole time, not with the organisation that paid. The practical question for this quarter is not whether an organisation is a past Cl0p victim. It is whether legal and the incident response lead have already agreed what happens the day a rival gang publishes that answer for them.

A Handbook in Washington, a Law in Singapore: The Governance Gap PMOs Actually Fill

Posted on by

Two documents delivered in 2026 that both claim to tell a board how to govern cyber risk. One is a handbook. The other is law. The distance between the two is where most PMOs currently sit, translating voluntary best practice into something a director can actually be held to.

The Handbook: Comprehensive, Voluntary, US-Focused

In April 2026, the National Association of Corporate Directors and the Internet Security Alliance released the fifth edition of the Director’s Handbook on Cyber-Risk Oversight. It is thorough. Six principles cover treating cyber security as a strategic risk, monitoring legal and disclosure exposure, building board oversight structures, adopting an enterprise risk framework, guiding measurement and reporting, and encouraging systemic resilience. It cites more than 600 million tracked cyberattacks a day and projected annual cybercrime losses approaching 20 trillion dollars globally. What it does not do, because it is guidance rather than statute, is compel a single board anywhere to act on any of it.

 

The Law: Narrower, Binding, and Personal

Singapore closed that gap for its own critical infrastructure operators in 2026 with an updated Cybersecurity Code of Practice. Boards of operators across eleven sectors, energy, telecommunications, water, healthcare, banking, aviation, maritime, government and more, must now maintain a documented resilience framework covering risk tolerance, mitigation, transfer and recovery, reviewed at least annually. Certification deadlines follow in December 2026 and December 2027. Directors can face personal liability where a company fails to prevent or properly respond to an incident because of a lack of the skill, care or diligence the role required. That is a materially different proposition from reading a handbook. It converts board oversight from a best-practice expectation into a standard a director can be judged against.

 

The Gap Between Them Is Where PMOs Live

Most organisations operating internationally will encounter both models at once, comprehensive American guidance describing what good oversight looks like, and a narrower but binding Asian regulatory standard describing what oversight is legally required to look like. Neither one, on its own, tells a PMO what to actually build. The handbook is too broad to implement directly. The code is too sector-specific to generalise from. The practical work, translating six abstract principles into a working reporting cadence, a named accountable owner, and evidence a board can point to if asked, sits squarely inside the PMO’s remit rather than the CISO’s alone or the board’s alone.

 

What a PMO Should Build From Both

A credible cyber governance structure borrows the handbook’s breadth and the code’s specificity. That means a documented framework reviewed at a fixed interval, not an annual slide nobody revisits, a named board-level owner who can answer for the organisation’s posture in plain language, and evidence, tested and dated, that oversight was real rather than assumed. Boards do not need another handbook to read. They need proof that what the last one said actually happened.

Four Countries, Four Health Systems, the Same Cyber Risk Tier

Posted on by

By August 2026, four European countries, Poland, the UK, France and Germany, had entered the critical tier of a healthcare cyber risk index covering 30 nations. France was still rebuilding more than 1,000 workstations and roughly 200 applications, five months after an October 2025 attack hit eight sites. Germany’s Unimed incident had disrupted care for more than 135,000 people across connected institutions. Every one of these countries has invested heavily in hospital cyber security. None of that investment, on its own, has been enough.

 

The Diagnosis Is Cultural, Not Technical

Research published by King’s College London in March 2026 offers a specific explanation for why. Reviewing NHS Trust cyber resilience, the researchers concluded that ransomware remains the most acute threat facing hospitals not primarily because of a technology gap, but because of inconsistent governance maturity and, more pointedly, a cultural rather than technical or financial constraint. Trusts with comparable budgets and comparable tooling still show wildly different resilience outcomes, which points toward leadership and accountability structures as the actual variable rather than the size of the security budget.

 

A Framework Built Around Ownership, Not Just Controls

The KCL research proposes what it calls a Cyber Leadership Framework, built on board-level ownership of cyber risk, an empowered CIO or CISO with real authority rather than a title, and a deliberate effort to connect technical controls to what actually happens in a ward or a clinic rather than treating cyber security as a parallel IT concern. Its most structurally significant recommendation is greater centralisation of core cyber capabilities and shared services across otherwise fragmented Trusts, replacing dozens of individually under-resourced security functions with fewer, better-resourced shared ones.

 

The Same Fragmentation Problem Shows Up Across Borders

That fragmentation is not a uniquely British problem. The Black Book Europe-30 Healthcare Cyber Risk Pressure Index, measuring attack pressure, clinical digital dependence, supplier concentration and recovery friction across 30 countries, found 13 of them sitting in the two highest risk bands, with Poland, the UK, France and Germany specifically flagged as critical. Each of these health systems is organised differently, some more centralised than the NHS, some more fragmented, and all four still ended up in the same risk category. Centralisation on its own is not a guaranteed fix. What the KCL research adds is the missing piece, shared capability paired with genuine board-level accountability, rather than shared capability alone.

 

What This Means for Healthcare Programme Governance

A healthcare PMO reviewing cyber resilience investment should treat the KCL framework as a diagnostic tool rather than an NHS-specific recommendation. The practical test is straightforward: can a board member currently name who owns cyber risk for their organisation, describe what shared capability actually exists beyond their own site, and point to when that capability was last tested under real pressure rather than reviewed on paper. France’s five-month rebuild and Germany’s 135,000-person incident both suggest that answering those questions honestly, before an attack rather than after one, is the entire point of the exercise.

One Token, Three Tools Deep, 2,500 Companies Across Five Continents

Posted on by

One leaked automation token. Three tools deep. Over 2,500 organisations across five continents exposed. That is the entire anatomy of 2026’s largest AI supply chain breach, and it took roughly forty minutes to happen.

How a Security Scanner Became the Weapon

In March 2026, a threat group tracked as TeamPCP compromised Trivy, a widely used open-source security scanner, through a leaked automation token. From there the attackers force-pushed malicious code into Trivy’s own version tags. When LiteLLM, a popular AI gateway that routes traffic between applications and model providers, pulled the poisoned scanner into its build pipeline, it published two compromised releases to PyPI, versions 1.82.7 and 1.82.8. A hidden file inside those packages executed automatically the moment Python started, no import required, harvesting cloud keys, repository tokens, SSH credentials, Kubernetes secrets and AI provider API keys from anyone who installed it. The malicious packages were live for roughly forty minutes before removal. That was enough.

 

A Genuinely Global Exposure List

CloudSEK’s analysis, later corroborated by an FBI advisory in July, identified more than 2,500 affected organisations and 434,000 exposed CI/CD pipelines. The named companies span the world rather than one region: AWS, Nvidia, Salesforce and Airbus’s US Space and Defense division from the US, Samsung Electronics and MediaTek from Asia, Siemens, Volkswagen and Munich Re from Germany, Thales and Orange from France, Roche from Switzerland, Philips from the Netherlands, Vodafone and the London Stock Exchange Group from the UK, and Thomson Reuters from Canada, alongside Cisco, FedEx, Deloitte and dozens more. This was never a story about one country’s technology sector. It was a demonstration of how deeply a single open-source dependency now sits underneath enterprise infrastructure everywhere.

 

The Same Argument, a Different Layer

This publication has already made the case that The September AI Outage Had Two Real Causes. Almost Everyone Reported One. LiteLLM extends that argument one layer deeper, into the software supply chain feeding the infrastructure itself. A vendor risk register that lists which cloud provider or model vendor an organisation depends on is no longer sufficient. It also needs to account for the open-source scanners, build tools and CI pipelines every one of those vendors quietly depends on, tools most procurement processes never ask about because nobody signed a contract for them.

 

What a PMO Should Actually Check

Three questions belong on every technology steering committee agenda this quarter. First, does anyone in the organisation maintain a current list of the open-source build and security tooling embedded in critical CI/CD pipelines, not just the paid vendors. Second, when was a leaked or rotated credential last tested as an actual incident scenario, rather than a line item in a policy document. Third, if a dependency three layers removed from a primary vendor were compromised tomorrow, how long would it take anyone to notice. The organisations named in the LiteLLM breach were not careless. They were exposed by a dependency most of them did not know they had, which is precisely the risk a vendor register built only around visible, contracted suppliers will always miss.

Three Regulators, Three Continents, One 72-Hour Deadline Nobody Is Ready For

Posted on by

Three regulators, on three different continents, converged on almost the same number this year, entirely independently. Washington set 72 hours. Brussels set 72 hours, after an initial 24-hour early warning. Abu Dhabi’s own financial free zones set 24 to 72 hours, depending on which one is asking. None of them coordinated on this. All three concluded, at roughly the same time, that a cyber incident report cannot wait for an organisation to feel ready to send it.

 

What Each Regime Actually Requires

In the United States, the Cyber Incident Reporting for Critical Infrastructure Act, CIRCIA, is expected to be finalised this month. It will require covered entities across 16 critical infrastructure sectors, an estimated 300,000 organisations in total, to report a significant cyber incident within 72 hours and a ransomware payment within 24. In the European Union, the NIS2 Directive is already live. Essential entities, those with 250 or more staff or turnover above 50 million euros, across energy, healthcare, banking, water and digital infrastructure, must send an early warning within 24 hours, a full assessment within 72, and a final report within a month. In the UAE, the pattern repeats at the free zone level. Firms regulated by Abu Dhabi Global Market must report a material cyber incident to the regulator within 24 hours, weekends and public holidays included. Firms in the Dubai International Financial Centre generally work to a 72-hour window. Three jurisdictions, three legal systems, the same rough number.

 

Why This Is a Delivery Problem, Not a Legal One

Most organisations have handed this requirement to legal or compliance to interpret, which is the wrong owner. A 72-hour reporting deadline is not primarily a question of what the law says. It is a question of whether an organisation can detect an incident, assess its materiality, assemble the right people, and produce an accurate report, all inside three days, under pressure, without the benefit of hindsight. That is a programme capability, not a policy position. Legal can tell you what the deadline is. Legal cannot build the operating rhythm that hits it.

 

The Capability Most Organisations Are Missing

The gap rarely shows up in the reporting template. It shows up upstream, in whether anyone can say, inside the first few hours, what actually happened. A US hospital system’s own social media accounts were hijacked by the ransomware group that had already breached it, which posted ransom demands directly to the public before the organisation regained control, a case study in how quickly a slow, uncoordinated response becomes the story itself. A reporting deadline assumes an organisation already knows what it is looking at. Most of the work that determines whether a report is accurate, or even possible, happens before anyone opens the compliance template.

 

What a Real Programme Looks Like

A credible response to any of these three regimes looks less like a legal memo and more like a programme: a named incident commander, a materiality assessment framework agreed before an incident rather than during one, a communications protocol that assumes attackers may control channels an organisation thinks are its own, and a rehearsal cadence, not a policy filed away and never tested. None of that is jurisdiction-specific. An organisation that builds this properly for NIS2 has, with minor adjustment, built it for CIRCIA and for ADGM as well.

The interesting part of this story is not which country moved first. Three regulators, working independently on three continents, arrived at the same conclusion, that organisations cannot be trusted to disclose on their own timeline, so a timeline was imposed. Whichever regime applies, the question worth asking this quarter is simple. Could the organisation hit the deadline today, if the incident happened this afternoon?

93% Have Been Breached by Vulnerable AI Code. 30% Still Ship It Anyway.

Posted on by


Seventy per cent of developers believe AI-generated code carries more vulnerabilities than the code they write themselves. Thirty per cent ship it into production anyway, knowingly. Ninety-three per cent of the same respondents report at least one breach traced back to a vulnerable application. Awareness of the risk and action on the risk are not the same thing. They rarely are, according to every major AI risk study published so far this year.

 

The Core Finding Repeats Across Every Study That Looks

The Purple Book Community’s State of AI Risk Management 2026 report, surveying more than 650 senior cybersecurity leaders across North America and Europe between December 2025 and February 2026, found 59 per cent of organisations acknowledging shadow AI within their own environment, despite 90 per cent claiming confidence in their AI visibility. Seventy-eight per cent are already piloting or deploying agentic AI systems, and 73 per cent say AI-assisted development is outpacing their security review cycles. Fifty-one per cent run 11 or more separate security scanning tools, and 46 per cent of teams spend significant time triaging vulnerabilities that turn out not to matter. Governance has not kept pace with adoption. It has fallen further behind with each new AI capability organisations switch on.

 

The Global Maturity Picture Is Worse Than Any Single Region’s

The World Economic Forum’s Advancing Responsible AI Innovation research, covering 1,500 organisations worldwide, found 81 per cent still sitting in the earliest two stages of responsible AI maturity. Regional breakdowns make that global figure look almost optimistic. In Asia-Pacific, only 1 per cent of organisations have fully operationalised responsible AI practices, a gap researchers describe as more pronounced than the global average. Separate research from Dataiku found 94 per cent of CEOs suspect employees are already using generative AI tools without authorisation, while 75 per cent of data leaders admit low trust in their own organisation’s AI agent deployments.

 

The Middle East Shows a Different Symptom of the Same Disease

Middle Eastern enterprises are not struggling with pilots. Multiple regional AI advisory reports this year describe successful proof-of-concept projects stalling the moment organisations attempt enterprise-wide rollout, blocked by exactly the governance gap the global data points to: no clear ownership of AI risk decisions, inconsistent access controls, and the added complexity of navigating different data protection and AI-specific regulations across Gulf jurisdictions simultaneously. The technology performs in the pilot. The governance structure needed to scale it safely usually does not exist yet.

 

What This Means for How Organisations Govern AI Risk

Every regional variant of this research points to the same structural gap rather than three unrelated problems. A risk committee should treat confidence surveys as a warning sign rather than reassurance, ask specifically what percentage of AI-generated code has been reviewed rather than whether a review process exists on paper, and confirm who owns AI risk decisions before the next agentic AI pilot moves toward production. The pattern holding across North America, Europe, Asia-Pacific and the Gulf is consistent enough to stop treating it as one company’s oversight and start treating it as this year’s defining governance failure.

A Tenfold Attack Surge in London, a Governance Mandate in Abu Dhabi

Posted on by

In January to May 2026, UK healthcare providers logged 264,000 attack events, against 27,000 for the whole of 2025. That is a tenfold jump in five months, according to SonicWall’s telemetry across NHS-linked sensors, and it occurred on a sector where the gap between what boards think they know and what is actually protected has never been wider.

 

The Long Tail of a Single Attack

The clearest illustration of what that gap costs sits two years in the past and is still unresolved. The June 2024 ransomware attack on Synnovis, the pathology provider serving South East London hospitals, exposed data from roughly a million NHS patients and forced more than 10,000 outpatient appointments and 1,700 elective procedures to be postponed. As of April 2026, South London and Maudsley NHS Foundation Trust was still processing pathology results without fully restored systems, and the incident has been linked to a patient death at King’s College Hospital. Nearly two years is not a recovery timeline any board signed off on. It is what happens when governance treats cyber resilience as an IT programme rather than a clinical safety issue.

 

Reactive Versus Mandated: Two Governance Models

The UK’s surge sits inside a largely reactive governance model, where boards respond to incidents and regulators tighten guidance after the fact. Abu Dhabi has taken the opposite route. Its Healthcare Information and Cyber Security standard, now in its second version, is built around six pillars, and governance is listed first, ahead of resilience, capability, partnerships, maturity and innovation. Every hospital, insurer and medical device maker operating in the emirate has to comply, and the standard explicitly frames cyber security as an organisation-wide responsibility covering people and process rather than a narrow technology control bolted onto IT. It is a mandated structure built before the incident, rather than a review commissioned after one.

 

Why the Stakes Keep Rising

The economics make the governance question harder to defer. Healthcare ransom demands have climbed sharply, with one widely cited industry analysis putting the average demand at $16.9 million, up from $577,800 the prior quarter, and healthcare remains one of the most targeted sectors globally, with 77 per cent of organisations reporting a ransomware attempt in the past twelve months, because attackers know disrupted care creates leverage no other industry carries. A board that treats a green status on a cyber dashboard as sufficient assurance is trusting a number it has usually never interrogated.

 

What Boards Should Actually Be Asking

Two different regulatory paths, one shared conclusion. Cyber governance in healthcare cannot sit exclusively with a CISO or an IT director reporting up through a technical channel. It needs a named board-level owner who can answer, in plain terms, three questions: which clinical services stop if this system fails, how long the organisation can run on manual process before patient safety is affected, and when that assumption was last tested rather than assumed. The Synnovis timeline suggests most boards do not currently have confident answers. The Abu Dhabi model suggests what building toward one actually looks like, governance treated as the first pillar of resilience rather than the last line of a post-incident report.