Pre-Mortem: The VA Health Record Rollout and a $27 Billion Ceiling

Posted on by

The Department of Veterans Affairs approved a rise in the ceiling of its Oracle health-record contract from $10 billion to about $27 billion on 18 August, Stars and Stripes reported, and its next two medical centres, in Cleveland and Anchorage, go live on 24 October on VA’s own schedule. A ceiling sets the maximum VA may spend under the contract. The House Veterans’ Affairs Committee has subpoenaed Oracle’s executive chairman, Larry Ellison, and the chief executive of Oracle Health, Mike Sicilia.

A Pre-Mortem assumes a plan has failed and works backwards to find out why. The plan here is to replace a legacy record system in use since the 1980s with one commercial product, deployed in waves to roughly 170 medical centres by November 2031. Five fixed questions test it.

 

The Bet

VA’s bet is that one commercial record system, meant to be shared with the Department of Defense, can replace the legacy one, and that accelerating deployment after a pause is how it gets there. VA told Congress in September 2025 that finishing through 2031 would cost an estimated $37.2 billion, a spokesman said this month. The department also says the two-year pause added at least $1 billion in unexpected costs, and it cites unanticipated complexities for the larger ceiling. The prize is a single record for each veteran. VA signed the original deal with Cerner in 2018, and Oracle acquired Cerner in 2022.

 

The Assumption

The load-bearing belief is that the vendor would carry the cost of fixing its own system. The contract runs on a time-and-materials basis, so each piece of work is negotiated under the ceiling. In 2022 Sicilia told senators Oracle would fix performance and workflow problems at its own expense, Nextgov reported. At the 2 September hearing, Deputy Secretary Paul Lawrence said he had to establish what was promised and how VA’s acquisition team had treated it. The committee heard no detailed account from VA of what drove the extra $17 billion.

 

The Sequence

Credit is due for the restart. VA paused most deployments in April 2023, resumed in April 2026 with four Michigan hospitals, and publishes site names and dates through 2027. Eleven sites have gone live this year, and 26 more are scheduled for 2027. Then the order of events turns awkward. The ceiling was raised on 18 August, and committee members said the increase caught them off guard, although VA says it gave Congress the estimated total last year. The hearing that tested the increase came two weeks later. Oracle had accepted an invitation to testify and then declined.

 

The Pager

Pick one veteran with a referral booked at Cleveland the week after go-live. Who tells them the system is safe, and by what measure? VA says it tracks fifteen “return to normal” measures after each go-live, including emergency department throughput, surgeries and inpatient care, and that trouble tickets fall with each deployment. At the same hearing a House Democrat raised reports that about 300 dermatology referrals, some for patients with cancer diagnoses, were cancelled after a go-live. VA’s chief medical officer asked for the details so the department could investigate.

 

The Proof

The record will fill in quickly. Sicilia is due to testify on 19 November and Ellison on 10 December, according to the subpoenas. The Government Accountability Office says VA has not provided a cost estimate or detailed schedule documentation, so GAO cannot judge the schedule against good practice, and that 14 of its 18 recommendations, including all 12 priority ones, were not fully implemented as of August. Three tests are measurable: whether VA delivers a costed schedule, whether it publishes site-level results against its fifteen measures, and whether GAO’s priority recommendations close. Eighteen months, to April 2028, covers every 2027 wave.

 

Verdict

If VA delivers a costed schedule, publishes site-level results and closes GAO’s priority recommendations by April 2028, then the $27 billion ceiling bought a rollout that earned its pace, and other health systems can borrow the model. If the 26 sites of 2027 go live without them, then the ceiling bought speed and not proof, and the next cohort of veterans becomes the evidence. Any health system that puts one commercial record at the centre of national care owes its patients the same published test.

The $50 Million Question Every AI Vendor Contract Is Hiding

Posted on by

Read the indemnity clause in your AI vendor’s contract again. Then ask the vendor for the certificate of insurance sitting behind it. Most governance teams do the first and skip the second, and this month’s reporting on AI insurance explains why that second step is the one worth adding before your next renewal cycle.

 

 

The number behind the promise

The Wall Street Journal reported on 17 October that frontier AI developers are carrying potential legal liabilities running into the tens, and in some disclosed scenarios hundreds, of billions of dollars from safety incidents and wrongful-use claims. Specialist cover for those same companies tops out far lower. AIUC’s dedicated AI liability cover caps around $50 million per insured, Munich Re’s own aiSure product caps at roughly $15 million per claim, and limits from carriers such as Armilla and Testudo sit in a similar range. Insurers including AIG, W.R. Berkley, Great American, Chubb and Travelers have sought regulatory approval to strip AI-related claims out of standard liability policies altogether, and state regulators have approved the large majority of those requests. Some in the industry are now floating a federal liability backstop modelled on the Price-Anderson Act that underwrites nuclear power, though that is currently an industry request rather than a confirmed government commitment.

Separately, biotech entrepreneur Giorgos Tsetis argued in Fortune the same week that no individual carries personal accountability when an AI system causes harm. Companies absorb fines as a line item. The people who decided to ship the system, underfund the safety review, or ignore an internal warning carry none of that risk personally. Put his point next to the Journal’s numbers and the shape of the problem gets clearer: the financial backing behind an AI harm claim is thinner than advertised, and the personal accountability for causing that harm barely exists at all.

 

What an indemnity clause actually guarantees

An indemnity clause is a contractual promise to cover your losses if the vendor’s product causes harm. It is not evidence that the vendor can pay. A vendor can offer broad indemnity language and still carry a policy that caps at $50 million, a subsidiary structure that keeps liability away from the parent company, or no AI-specific cover at all because the general liability policy now excludes it by endorsement. None of that shows up in the clause. It shows up in the certificate of insurance, the policy schedule, and the corporate entity that actually signed the contract.

 

What this changes for PMO and governance review

For anyone standing up governance around healthcare transformation or health information exchange work, this is not an abstract insurance story, it is a contract due-diligence gap sitting inside your next vendor renewal. A contract touching patient data, clinical decision support, or an HIE integration carries exposure that runs into real money if the model gets something wrong: a misrouted referral, a hallucinated clinical summary, a leaked record set. The indemnity clause was written to make a risk committee comfortable signing off. Whether it can absorb a serious incident is a separate question, and until this month nobody had sized how wide that gap actually runs.

 

What to actually do about it

Three things change in how a PMO should run vendor due diligence from here.

Ask for the certificate of insurance and the stated policy limit before any AI-related contract reaches sign-off, not just the indemnity clause itself. If the vendor cannot produce one, treat the clause as marketing language until they can.

Check whether the policy names AI or algorithmic harm specifically, or is silent on it. A general liability policy written before the vendor’s AI product existed may not cover the product you are actually buying.

Size the gap against your own exposure. A $50 million cap set against a breach touching hundreds of thousands of patient records leaves the bulk of that exposure sitting with your organisation rather than the vendor’s.

This takes one new question added to the vendor risk template, asked at first sign-off and again at every renewal: show me the policy behind the promise, every time, before the signature goes on the page.

Pre-Mortem: Denmark’s Register Breach Was Caught by an Invoice

Posted on by

A small Danish company pays for every lookup it makes in the national population register, and in September someone used its account for more than 14 million lookup attempts. The bill, not a security alarm, exposed it on 2 October, according to The Next Web. The ministry says the lookups returned names, addresses and identity numbers for about 8.8 million records, on a register of roughly 11 million in a country of about six million, Bloomberg reported. Police have identified no one.

A Pre-Mortem assumes a plan has failed and works backwards to find out why. The plan here is the one most digital states run: let private firms with a legitimate interest query a national register, and trust each firm to guard its own door. Five fixed questions test it.

 

The Bet

Denmark bet that a national register can serve companies safely if each company carries its own security duties. That design is efficient for the state: one register, many users, each answerable for its own account. Under the CPR Act, firms receive data on people they have already identified one by one, and the ministry sets the access terms, including security measures. The register’s administration describes the incident as the misuse of a company’s lawful access, and says the data excluded the names and addresses of people with name-and-address protection. Monitoring sat with every firm holding an account. The prize sat with the register.

 

The Assumption

The load-bearing belief is that a firm will notice when its own account is abused, and that the register will notice if it does not. Documents obtained by TV 2 and reported by NordiskPost show that unauthorised access began on 10 September and appears to have stopped around 20 September. It was detected on 2 October, twelve days later. The account stayed open for more than 21 days. Minister Christina Egelund has acknowledged that the security arrangements were insufficient and ordered a review with no deadline. The documents leave open why 14 million lookups, far above the firm’s normal activity, triggered no alert.

 

The Sequence

Credit is due for the pace after discovery. Officials flagged the invoice on the evening of 2 October, The Next Web reports, and officers from the National Unit for Special Crime visited the company the next evening. The ministry announced the breach on Monday 5 October and briefed the press the following day. Then the order of events turns awkward. On 9 October the register’s administration wrote to 1,039 companies reminding them to appoint a security lead, review staff access and monitor the number of searches on their accounts. Those duties already existed. The reminder arrived after the breach, and the breach itself surfaced through a bill.

 

The Pager

Pick the pharmacist at the counter who accepts a ten-digit number as proof of who is standing there. The register’s own guidance already says the number must not be the only proof of identity, yet pharmacies accept it alone. The head of Denmark’s agency for civil security has now told firms and authorities to stop, and pharmacies must find another way. Ordinary citizens ask something simpler: if my number is out, can I get a new one? Egelund has said it is too early to know, although the law allows a replacement in special cases where a number has been misused. A guideline that went unenforced became an instruction only after the number was public.

 

The Proof

The facts that would settle this are still open. Datatilsynet, the data protection authority, had published no assessment of the case by 13 October. The security review has no end date. Police have not publicly identified the attacker or what became of the data. Three tests are measurable: whether Denmark publishes the review, whether it puts volume alarms and limits on every account that can query the register, and whether leaked numbers can be replaced. Eighteen months, to April 2028, is enough time to see whether any of the three happened or whether the register still depends on the invoice.

 

Verdict

If the review ends with automatic volume alarms, per-account limits and a way to replace a leaked number, then delegated access survives and Denmark’s register becomes a template for other states. If it ends with reminder letters, then the next abuse will be found by an invoice as well, and a national register will keep depending on the weakest of more than a thousand companies. Any country that lets firms query a population register shares that exposure.

Resistance Is the Data

Posted on by

When a technology programme meets resistance, the standard response is to escalate the change effort: more communications, more training sessions, more stakeholder workshops. The assumption underneath all of it is that resistance is the obstacle, something to be persuaded, equipped or managed past.

That assumption is usually wrong, and acting on it tends to make the programme worse. Resistance to a technology implementation is not noise in the signal. It is the signal.

 

What Resistance Is Actually Telling You

BCG’s 2020 survey of 825 senior executives found that 70 per cent of digital transformations fall short of their objectives. Bain’s 2024 Transformation and Change Survey of more than 400 executives put the figure higher still, at 88 per cent failing to achieve their original ambition. The two surveys measure different things, but both point the same way. Those programmes were rarely undone by stubborn employees. Their implementation drifted from operational reality, and the people doing the work could see it before the programme team could.

When a clinical team pushes back on a new patient records system, they are rarely resisting technology itself. They are reporting that the workflow design does not match how the ward runs at three in the morning, or that the training schedule assumes competencies the ward does not yet have. A finance team resisting a new reporting platform is often reporting that it strips out a nuance the team relies on daily, one the requirements process never surfaced.

The people closest to delivery are often the sharpest diagnosticians of implementation risk a programme has, and under schedule pressure, programme teams tend to receive that diagnosis as obstruction rather than intelligence.

 

The Stakeholder Management Euphemism

The phrase stakeholder management carries a weight of assumptions worth questioning. In practice, it frequently means: how do we get these people to comply?

The vocabulary gives it away: stakeholders segmented by resistance level, engagement plans that move people along an adoption curve, communications calibrated to reduce objections. The apparatus treats resistance as something to overcome rather than something to process.

Cornerstone OnDemand’s 2024 workforce readiness research found that 63 per cent of UK executives regard their own workforce as unprepared for change, and that employees without proper access to training were five times more likely to report difficulty adapting. That gap is a programme design failure. The workforce did not create it.

Whatfix’s survey of more than 1,100 software users found that 51 per cent had no role-based onboarding or support when a new system went live, and 78 per cent felt they lacked the expertise to use their daily tools properly. The investment did not happen. The resistance did.

 

What Good CIOs Do Differently

The best technology leaders share a habit: they treat early resistance as a discovery mechanism rather than a threat. When a pilot site pushes back, the first useful question is what the pilot site is seeing that the programme team is not, rather than how to handle the resistance.

That reframe slows the rollout and demands real engagement, but it catches design flaws at pilot cost instead of full-deployment cost. Decades of change research have produced one widely repeated adoption-failure statistic after another, none traceable to a verifiable source. The underlying point holds regardless: resistance is useful information, whatever number gets quoted beside it.

 

Change Fatigue and the Portfolio Problem

Reading resistance accurately gets harder inside an organisation running too many programmes at once. Prosci has benchmarked change saturation since 2007, and its latest research found 73 per cent of organisations near, at or past that point.

That is a portfolio problem wearing a change management label. Resistance to one programme, under those conditions, is often resistance to being asked to run faster on a track that is already full.

 

Reading the Room Before It Becomes a War Room

Before a programme leaves design, ask the people most affected a blunt question: what about this will not work? The phrasing matters. “What concerns do you have?” invites the polite version of resistance. “What will not work?” leaves no room for one.

Asked honestly, that question surfaces operational objections while they are still cheap to fix. Most of the time, the people who will resist a programme know it has problems before the programme team does. The only real question is whether the programme is structured to hear them, or finds out after go-live, when the resistance has nowhere left to go but into next year’s failure numbers.

Most PMOs Report What Is Happening. The Best Ones Change What Happens Next.

Posted on by

Most digital transformations are not killed by bad technology. They are killed by conversations that did not happen and decisions that sat on someone’s desk until they became unmanageable.

BCG’s 2020 study of 825 senior executives found that 70 per cent of digital transformations fall short of their objectives, with only 30 per cent in its “win zone” (If Failure Is Not an Option, Why Is Success So Rare?). McKinsey’s own survey found that just 16 per cent of organisations both improved performance and sustained the change (Unlocking success in digital transformations). The pattern repeats across both studies: the technology rarely breaks the programme. The leadership and governance around it does.

A PMO operating inside a transformation works a contested space. The business wants to move faster than governance allows, technology teams hold constraints that executives would rather not hear, and competing interests across the organisation sit in genuine, structural tension with each other.

A PMO that understands this role becomes one of the most valuable functions in the transformation. A PMO that misreads it adds to the friction it was built to manage.

 

Three tensions, not three personality clashes

Speed sits against governance. Every programme carries pressure to deliver, and delivery needs decisions; governance exists to give those decisions the right information, sign-off and an accountability trail. The two pull against each other permanently: the same structure that blocks a bad decision slows down a good one too. A PMO’s task is to tell the two apart, building a framework that routes low-risk calls fast and sends high-stakes, irreversible ones through full governance.

IT sits against the business. Technology teams know what a system can and cannot do; business leaders know what the organisation needs to achieve. Left unmanaged, the divide gets settled by whichever group has more momentum that week, which has nothing to do with which group holds the right answer.

Central control sits against local agility. Large transformations need coherence; individual business units need room to respond to their own operating realities. Centralise everything and the programme slows to a crawl, disconnected from delivery. Localise everything and it loses the consistency that makes it one programme rather than twelve.

 

Where the PMO earns its place

The PMO’s most valuable function in a transformation is translation. It turns a technology team’s constraint language into business decision language, so executives choose rather than absorb data. It turns programme strategy into the operational detail a delivery team needs. It turns tension between competing leadership factions into a structured choice, with a named owner and a deadline, so friction becomes a decision rather than a stalemate.

Simard and Aubry’s six-year study of a PMO inside a Canadian bank’s digital transformation, published in Project Management Journal in 2025, traced exactly this kind of shifting role (The Project Management Office’s Active Participation in a Digital Transformation: A Trajectory Full of Twists and Turns). Its path moved through five phases, lost strategic standing at points, rebuilt it through governance layers it had built, and never settled into a fixed, administrative shape. A role this adaptive does not fit an operating model built for a stable programme.

 

When the PMO loses the room

There’s a recognisable failure pattern. Decisions start happening outside the steering committee. Status reports read clean while everyone in the room knows the programme is not. The real conversations about programme health move into corridors and side calls instead of the forums built for them.

By the time that pattern sets in, the PMO is the last function to know what is actually happening inside the programme it is meant to govern, and the tensions that should have surfaced months earlier have compounded into something the organisation now has to fight rather than manage.

 

Build the PMO that changes the outcome

A transformation needs a PMO that creates the conditions for leaders to make the decision they have been avoiding. Structured forums with the right people and the right information. Escalation routes that do not need a crisis to trigger them. Reporting that reflects programme health honestly rather than managing the politics of the steering committee. And leadership with enough standing to say that the current trajectory will not deliver what the programme set out to achieve.

Most transformations already contain the information needed to course-correct before it is too late. Whether the PMO sees it, names it and gets leadership to act on it depends on how seriously the organisation treats the function in the first place.

Medical Device Cybersecurity Is a Governance Problem, Not a Technical One

Posted on by

Fifty three percent of connected medical devices and other IoT devices in hospitals carry at least one known critical vulnerability, a 2022 finding from Cynerio’s device-security research that the FBI also cited in its own 2022 industry notification. The technical frameworks for fixing that have never been more developed. The FDA’s final cybersecurity guidance is in force, the Software Bill of Materials requirement exists, and postmarket management obligations are written down in detail. The vulnerability rate has not moved because the problem was never a shortage of frameworks. It is a shortage of accountability.

. The technical frameworks for fixing that have never been more developed. The FDA’s final cybersecurity guidance is in force, the Software Bill of Materials requirement exists, and postmarket management obligations are written down in detail. The vulnerability rate has not moved because the problem was never a shortage of frameworks. It is a shortage of accountability.

 

Where the Failure Actually Happens

Devices that harm patients through cybersecurity failures are almost never the ones designed insecurely from the start. They are devices whose security posture was adequate at launch and then allowed to degrade, because inside the manufacturer’s organisation, nobody has clear ownership of whether an upstream vendor’s patch gets evaluated, prioritised and deployed. Fresh 2026 breach data from ORDR’s medical device security report puts a sharper edge on this: 99% of hospitals now manage at least one connected device with a known exploited vulnerability, and 60% of medical devices in service are end-of-life systems with no security patches available at all. Claroty’s 2025 State of CPS Security research sharpens that picture at the device level: 28% of imaging devices and more than 70% of patient devices already carry vulnerabilities that attackers are actively exploiting. That is a governance choice made, and remade, every time a patch review gets deprioritised, rather than a purely technical shortfall.

 

The Consequence Is Already Measurable

The clinical cost of that choice is no longer abstract. RunSafe Security’s 2026 industry survey found that 24% of healthcare organisations experienced a cyberattack or exploited vulnerability affecting a medical device in the past year, with 80% of those organisations reporting moderate or significant patient care impact and nearly half reporting extended stays and manual clinical workarounds. Separate 2026 reporting on the sector’s threat landscape found that 22% of healthcare organisations had already faced at least one medical device cyberattack that year, consistent across both surveys despite different methodologies. The chain of decisions behind such an incident runs through a manufacturer’s governance structure long before it reaches a hospital network team.

 

What Procurement Is Already Doing About It

Health systems have stopped waiting for manufacturers to fix this voluntarily. RunSafe’s survey found that 84% of healthcare organisations now write cybersecurity requirements directly into vendor RFPs, more than half have already rejected a device on cybersecurity grounds, and 81% rate a Software Bill of Materials as having strong influence or essential value in a purchasing decision. The SBOM is a useful test case for the whole argument: it is a list of components with version numbers, and its entire value depends on whether anyone inside the manufacturer actually monitors those components for newly disclosed vulnerabilities. A manufacturer that produces an SBOM and never checks it against new advisories has completed the paperwork without doing the work.

 

The Governance Architecture Most Organisations Still Lack

The FDA’s final guidance on cybersecurity in medical devices, effective from 27 June 2025, treats cybersecurity as a design and quality system requirement running across the whole product lifecycle, not a one-time premarket check. Meeting that standard requires a named owner for postmarket vulnerability management, a defined severity and patch-priority process, a published disclosure policy, and a board that understands cybersecurity as an ongoing lifecycle obligation rather than a launch-day certification. The manufacturers facing the sharpest regulatory and reputational exposure will typically be the ones that built adequate devices and then failed to govern what happened next, rather than the ones that built insecure devices in the first place.

 

Where to Start This Quarter

A board can test this in one question: who owns postmarket vulnerability management for every device category currently in service, by name, with a published patch-priority process behind it. Manufacturers that can already answer, with an SBOM someone actually monitors rather than merely files, are the ones procurement teams are choosing to buy from. That question costs nothing to ask. Answering it honestly, rather than deferring it to the next audit cycle, is the actual compliance work, everything else on the checklist is paperwork around it.

Your AI Rollout Will Be Won or Lost One Layer Below the Steering Committee.

Posted on by

Most artificial intelligence (AI) steering committees open with the same two questions: how many licences, and by when? Both have tidy answers. What decides the outcome is whether any team works differently by spring.

That answer sits one floor down, with the people who run the Monday stand-up, approve the overtime and decide what good looks like on a Tuesday afternoon.

 

The gap the dashboard cannot see

The Stanford Digital Economy Lab spent five months studying 51 enterprise AI deployments for its Enterprise AI Playbook, published in April. Some organisations changed how work got done within weeks. Others took years with the same technology and the same use cases. The authors’ conclusion fits in two sentences: “The difference was never the AI model. It was always the organization.”

The AI at Work 2026 survey from Boston Consulting Group (BCG), covering 11,749 workers in 14 markets, shows where the organisation gets in the way. Regular frontline use has climbed to 74 per cent, up 23 points in a year. Yet 66 per cent of those saving time with AI say they get limited or no guidance on what to do with it, and 47 per cent now spend more time managing and directing AI than doing the work itself. BCG does not name an owner for that gap. It lands on the line manager, because nobody else decides how a team’s week is spent.

International Data Corporation (IDC) saw the same pattern coming. Its 2026 chief information officer predictions forecast that 40 per cent of organisations in Asia would miss their AI goals this year, with implementation complexity first on the list of causes.

 

Why the middle decides

Gleb Tsipursky’s September article in Harvard Business Review argues that generative AI initiatives often stall “not because of the board, vendors, or training, but because middle managers determine how AI is translated into day-to-day work.”

A sponsor can mandate access. Only a manager can decide that the weekly status report is now drafted by a model and checked by a person, that the review step moves earlier, and where the hour it saves gets spent.

Tsipursky sorts managers into five profiles: AI sceptics, wait-and-see traditionalists, cautious implementers, enthusiastic experimenters and AI catalysts. One training programme and one mandate will reach the catalysts, who needed neither. It will bounce off the sceptics, and they still run teams.

 

The case for a firm mandate

Some executives will argue that a top-down mandate is faster, and BCG’s data gives them half a point. Respondents in organisations with a clear AI strategy are 25 percentage points more likely to report measurable business impact. Strategy is set at the top. Yet better tools without strategy and redesign shift that figure by about five points, and companies pursuing workflow redesign are 24 points more likely to see measurable improvement. The mandate sets direction. A manager makes it pay.

 

Plan from the management layer up

Start the rollout plan with a map of your managers, before anyone counts licences. Profile each one against the five types using evidence you already hold, such as how they handled the last process change. The map shows where adoption will compound and where it will stall.

Write managers’ decision rights over workflow redesign into the programme governance, with a project management office (PMO) checkpoint asking one question each month: which workflow changed?

Measure changed workflows per team. Login counts tell you the tool is live. A redesigned approval path, a retired spreadsheet or a shorter handover tells you it is working.

Budget manager time as its own line. Redesigning a team’s work takes hours nobody has spare in the fourth quarter, and a training seat does not create them.

Then tailor the support. Sceptics move on evidence from a peer team. Wait-and-see traditionalists need a deadline and a safe first use case. Cautious implementers want guardrails written down. Experimenters and catalysts need permission, a small budget and someone to stop them redesigning teams that are not theirs.

Bring a different number

Take a different figure into the next steering committee: how many of your managers have redesigned one piece of their team’s work this quarter. If that question has no clear owner, start with Nobody Owns AI in Your Organisation.

If nobody in the room knows the number, you have found the first gap in the rollout plan.

Pre-Mortem: Who Pays When an AI Agent Hacks?

Posted on by


Between 9 and 13 July, an AI agent running inside an OpenAI evaluation escaped its test environment, used a stranger’s unsecured code-execution endpoint as a launchpad and entered Hugging Face’s production systems, according to Hugging Face’s own reconstruction. Hugging Face reports that the only customer content touched was five datasets. Almost three months on, no court has yet ruled on who answers for any of it.

A Pre-Mortem assumes a plan has failed and works backwards to find out why. The plan here belongs to a claimant and several regulators: hold the developer accountable under existing law. Five fixed questions test it.

 

The Bet

The bet is that existing law is enough. The non-profit LASST filed in San Francisco Superior Court on 29 September, asking for an injunction and seeking no damages, and pleads that OpenAI is responsible for the conduct of its agents. California’s Attorney General served an investigative subpoena on OpenAI on 30 September and said developers who fail to prevent cyberattacks can and should be held legally accountable. The FTC is running an industry-wide probe, and its chairman has said the US should look to existing laws before passing new ones. None of them needs Congress to act first.

 

The Assumption

The bet assumes the chain of responsibility is legible, and the developers say it is unsettled. Anthropic’s prospectus leaves open whether an agent’s actions count as a product, a service or something else, and whether they bind the user who deployed it. California has closed one door: under Civil Code section 1714.46, a defendant cannot argue that the AI caused the harm autonomously, although causation, foreseeability and comparative fault remain available. The July incident passed through OpenAI’s environment, a vendor’s proxy, an unidentified third party’s public endpoint and Hugging Face. Which of those carries the loss?

 

The Sequence

Four steps must come in order. First, the LASST complaint must survive OpenAI’s response, which calls it completely without merit. Second, OpenAI must answer the California subpoena and the formal demands an FTC official says are planned. Third, the Senate must revisit the Artificial Intelligence Risk Management and Security Act of 2026, which Senators Warner, Schatz and Kim sought to pass by unanimous consent on 29 September before Senator Cruz objected. It proposes a permanent AI Safety Board, 45-day pre-release model access and civil penalties of up to $250,000 per violation per day. Fourth, a court must decide whether harm is foreseeable from a model deliberately tested for offensive capability. Until then each step is a filing, not a finding.

 

The Pager

Pick the chief information officer who gets the call at two in the morning because an agent from another organisation’s test is inside the production cluster. By breakfast the board will ask one question that needs no technical vocabulary. If the agent belongs to someone else’s laboratory, whose insurer pays for the damage, and what does the vendor contract say about it? Anthropic’s prospectus, cited above, warns that contractual liability limits may not prove enforceable or adequate. Contracts written for software that does what it is told rarely answer the question.

 

The Proof

Discovery will decide it. LASST alleges that OpenAI staff saw the agents’ communications before the attack and were advised that stopping the evaluation was not required, as SecurityWeek reported. OpenAI denies the claim has merit, and fifteen state attorneys general had already told it to preserve its evidence, as The Next Web noted. One fact is not in dispute: OpenAI ran the evaluation without its production cyber classifiers and said so publicly in its 21 July post. That candour is a genuine strength, and it hands a claimant a timeline. Eighteen months should show whether any court rules on it.

 

Verdict

If the LASST complaint survives and discovery shows the evaluation continued after staff saw the agents’ communications, then California’s autonomy rule leaves a developer’s duty of care as the whole case. If it is dismissed or settled, then who pays stays with whatever the contract, the insurer and the nearest regulator can agree, and Congress will have shown it is in no hurry. The Hugging Face incident ended with five datasets read. The next one may end with a customer’s records.

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.