Most security teams already have a breach clock memorized. GDPR gives you 72 hours. SEC rules give public companies four business days after determining an incident is material. Those numbers get built into incident response runbooks, tabletop exercises and escalation paths, because the clock starts the moment the team confirms something happened.

Article 73 of the EU AI Act adds a third clock, and in my work advising enterprise clients on AI governance, I have yet to see one with a runbook for it.

The obligation took effect on August 2, and it did so alone. The EU’s Digital Omnibus on AI, in force since late July, pushed the rest of the Act’s high-risk enforcement wave — classification, conformity assessment, technical documentation — back to December 2027. Article 73 was not part of that reprieve, though the extra time elsewhere is worth using to get ready. It requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities within 15 days by default, 10 days if a death is involved and just 2 days for incidents the Act classifies as widespread or as a serious disruption to critical infrastructure. Coverage of Article 73 so far has treated it as a legal filing requirement, handled through the same channel as a data protection filing. That framing misses what the obligation is. It is an incident response deadline, and it runs on a different trigger than the breach clocks most security teams already know.

A client once asked me, almost as an aside, whether their customer-facing AI tool would trigger a reporting duty if it simply gave someone bad information rather than getting hacked. At the time, the honest answer was probably not, under any framework they were tracking. Article 73 changes that, and most organizations building or buying AI for the EU market have not caught up yet.

What counts as a trigger here is broader than most teams expect

GDPR’s 72-hour clock starts when you become aware of a personal data breach. That is a bounded question. Did data leave the environment? Was it accessed without authorization? Article 73 asks something harder. The European Commission’s draft guidance takes the position that an indirect causal link between an AI system and a downstream harm is enough to trigger the reporting duty. Their example is a loan denial that traces back to a flawed AI credit assessment. The AI system does not cause harm the moment it produces the assessment, only once a human acts on it and denies the loan. The fundamental rights category requires the infringement to interfere with Charter-protected rights at scale, which is why the Commission illustrates that threshold with patterns, a recruitment tool that discriminates systematically or a credit system that categorically rejects an entire neighborhood. Under the Commission’s reading, once a pattern like that exists, the clock starts when the provider becomes aware of it, not when the system generated the output.

Here’s a plainer version of that pattern. A public benefits agency uses an AI system to match applicants against its records. A flaw in the matching logic occasionally conflates applicants, and over several weeks it happens to a run of different people, each flagged as already receiving the same benefit elsewhere and suspended. Nobody catches the pattern at the time, because each flag looks unremarkable on its own. Applicants don’t find out until their payments stop arriving, weeks after the first mismatch. The system never malfunctioned in any way security tooling would catch. It just produced bad matches until people started missing payments.

That is a different kind of determination than “Did we get breached?” It requires tracing a causal chain from a model output through a downstream decision to an actual harm, then judging how confident you are in that link before you are required to report it. Most incident response teams have a well-practiced instinct for confirming unauthorized access, but few have one for confirming that an AI system caused a harm that surfaced elsewhere in the business, days or weeks later. I have watched security leaders confidently answer, “Were we breached?” in minutes, then go quiet when asked, “Did our AI system cause this?” because nobody owns that second question yet.

Why this does not fit into an existing IR playbook

Most incident response programs are built around a single moment: detection. Something trips an alert, a SOC analyst confirms it and the clock starts. Article 73 incidents will not look like that at all. The AI system that produced the flawed output may show no signs of compromise. Nothing gets flagged by a SIEM. The first sign might come from a customer complaint, an internal audit finding or a pattern a compliance analyst notices months after the AI system made the decision.

That means the “becoming aware” clause in Article 73 is doing real work, and most organizations have not decided who is responsible for noticing. Is it the team monitoring the AI system’s technical performance, the business unit acting on its outputs, or whoever eventually hears the complaint? Under Article 73, the clock starts when any of them establishes, or suspects, the causal link, and 15 days is not a long runway if the first internal conversation about “is this our incident” does not happen until day six or seven. I have seen governance structures where a business unit head, a model risk team and security each assumed someone else owned this judgment call. In practice nobody did, and that gap is where a 15-day clock burns down to five.

Some security teams are already mapping agent governance to a maturity model, arguing that oversight must scale with autonomy, moving from agent identities that are barely inventoried toward ones that are bounded, monitored and revocable in real time. Article 73 raises the stakes on that model considerably. The less a human reviews an AI system’s output before it reaches a customer, the more likely a downstream harm surfaces without anyone watching for it in real time, which is exactly the blind spot Article 73 is designed to close.

What needs to change

A few additions belong in an existing incident response program before this becomes a live problem instead of a paper requirement.

First, a defined owner for the causal link determination. Data breach response usually has a clear owner: security confirms the technical facts, legal makes the materiality call. Article 73 needs an equivalent split: Someone technical enough to trace an AI system’s output to a downstream decision and someone with authority to make the reporting call once that link looks plausible rather than certain. In practice, I recommend naming this owner in the incident response plan, not leaving it to be sorted out during the first real incident, when the clock is already running.

Second, a lower bar for opening an investigation. If GDPR taught teams to investigate the moment unauthorized access is suspected, Article 73 requires investigating the moment a downstream harm is suspected to trace back to an AI system, when the system looks normal to security monitoring. That means feeding business unit complaints and customer escalations into the same triage process that currently only starts from technical alerts.

Third, a documented decision log for the indirect link judgment call. Given how broadly the Commission has defined what counts as reportable, organizations will make defensible calls not to report many ambiguous situations. Those decisions need to be documented with the reasoning behind them, the way a security team documents a false positive call, because a regulator revisiting that judgment months later will expect to see how it was made rather than take the outcome on faith.

Fourth, controls built into the AI system, not bolted on after the fact. A defined owner and a lower investigation bar help catch a problem once it surfaces, but neither reduces how often a flawed output reaches a customer first. Scoped credentials, tool allowlists and pre-action approval hooks cut down on how many incidents exist to report.

The AI Act’s high-risk obligations have absorbed most of the attention this year, because conformity assessments and technical documentation are heavy lifts with long lead times. Article 73 looks lighter by comparison, a reporting duty rather than a certification process. It is not lighter. It asks security and compliance teams to build a new kind of judgment into their incident response programs, on a clock as tight as anything GDPR or the SEC have required. Treat the deferral on the rest of the high-risk package as what it actually is, extra runway to build that judgment and name its owner, because the conformity paperwork still gives you months and Article 73 still gives you days.

Organizations today are not short of data, particularly in the domain of cyber. What many lack is a timely, trusted assessment that can help leaders act with greater confidence.

When a cyber incident begins, the technical questions surface first. What happened? Which systems are affected? Is the activity contained? But the questions that often shape the outcome are rarely technical alone. Who is behind the activity? What are they trying to achieve? Is this an isolated event or part of a broader campaign? Which customers, suppliers, assets or services are exposed? Is there a sanction, legal, regulatory or reputational dimension? And what is a proportionate immediate response while the facts are still incomplete?

This is why cyber is, in a meaningful sense, as much a human decision-making problem as a technological one. The OECD argues that digital security risk should be integrated into broader decision-making, rather than treated only as a technical issue. Tools can detect signals, spot patterns, correlate events and flag anomalies, but it takes people to decide what those signals mean, when to escalate, which trade-offs matter and what action the organization should take. In Moody’s recent whitepaper on supporting decision dominance through financial, corporate and trade intelligence, we make the case that the decisive moments in a cyber incident belong not only to systems, but to judgement.

That matters for CIOs and other technology decision-makers, because theirs is one of the most demanding decision environments in the enterprise. Reporting lines and structures vary by organization, but common themes tend to recur: technical complexity, compressed timelines, uncertain attribution and fragmented responsibility. Security teams may see indicators before they understand intent. Legal teams may need to assess obligations before the full scope of an incident is known. Communications teams often must prepare for scrutiny while operations are still working through containment. Business leaders may first need to decide when a decision must be made, then whether to pause a service, isolate a supplier, notify a regulator, issue a public statement or accept some temporary disruption to prevent greater harm.

The result can be a gap between signal and action, at a time when many organizations are experiencing a growing volume of cyber signals and alerts. Organizations commonly track mean time to detect and respond. But a less visible but equally consequential metric is decision latency: the time it takes to move from a technical signal to a shared understanding of what matters, and a decision about what to do. An organization can identify a threat quickly and still act too slowly if it cannot interpret the signal, convene the relevant stakeholders or agree on a proportionate response. The challenge is not simply speed — decisions made quickly but poorly can amplify harm. It is reducing decision latency without sacrificing judgement. This urgency is not theoretical and shouldn’t simply be admired. In her 2026 GCHQ Annual Lecture at Bletchley Park, Director Anne Keast-Butler described “a moment of consequence” shaped by the radical uncertainty. Her wider point is key for CIOs and their peers across the board: cyber security is a critical priority, and resilience depends on the ability to act with urgency, judgement and trusted partnerships.

From signal to context

Technical signals tend to become more useful when connected to wider context. A malicious domain, an unusual login, a compromised account or malware signature may tell a security team that something is happening. On its own, that signal rarely tells an executive what the organization should do next. Context reframes the question from “what does this indicator mean?” to “what decision should we make?”

That context can take several forms. Payment flows may provide additional context regarding the financial networks associated with an event or risk scenario. Ownership structures can help identify relationships between suppliers, counterparties or entities that may merit further review. Sanctions exposure may change the legal and compliance implications of a response. Adverse media may provide indicators of potential reputational or integrity concerns. Corporate linkages may reveal that what looks like a narrow technical event is in fact connected to a wider network of actors, assets or interests.

None of this removes uncertainty altogether, and no decision-maker should wait for perfect information before acting. What broader context does is improve the conditions under which judgement is exercised. Two incidents may look similar at the technical level but demand different leadership responses. One may be opportunistic criminal activity with limited broader consequence. Another may involve connections to a sanctioned entity, an organized crime network, a critical supplier or a state-linked ecosystem. The signal may look similar, but the appropriate response is not.

A cross-discipline exercise

This distinction matters because cyber response is often not contained within the security function, especially in a learning organization. A serious incident typically draws in teams from across multiple disciplines, such as security, IT, legal, risk, compliance, finance, procurement, communications and business operations. It may also involve external parties such as law enforcement, intelligence agencies, regulators, financial institutions, infrastructure operators and key suppliers. The CIO will not own every lever in this environment, and organizational structure will influence how close to the centre of the systems they sit, dependencies and information flows that affect the organization’s ability to respond effectively. Is the CIO supported or supporting during an incident? What leeway is afforded the CIO to act when required?

A common challenge in cyber response is not the absence of technical capability, but the absence, or fragility, of a shared decision model. Teams will have data, dashboards and incident playbooks in place, but still lack clarity on who decides, what information is needed, which trade-offs are acceptable and how quickly business context can be brought to bear. Ensuring a common operating picture — one that gives the leadership team a shared understanding of the same facts — tends to be a differentiator between organizations that respond coherently and those that do not.

For CIOs and CEOs, this is an organizational design problem as much as a technology one. Experience suggests that a cyber strategy that stands alone may be less effective than one integrated into the organization’s broader strategy from the outset. Cyber maturity should not be judged only by the number of controls deployed, alerts processed or systems monitored, but also by the quality of the decisions an organization can make under pressure. Using scenarios to test decision making can help refine organizational design, highlight blockers that may emerge at critical times, and improve leaders’ understanding of the potential consequences of poor decision making. That wider coordination challenge is reflected in CISA’s incident response guidance, which treats serious cyber incidents as events requiring coordination across multiple stakeholders.

Where integrated intelligence adds value

This is where integrated intelligence has a role to play. Its value lies less in the sheer volume of information it provides — most organizations already have more data than they can absorb — and more in its ability to help prioritize, separating signal from noise. It can help distinguish activity that is technically interesting from activity that may be strategically material. Used well, it can help identify enabling networks associated with an attack, inform disruption options and help focus scarce defensive resources on the assets, relationships and dependencies most likely to matter.

The aim is not to know everything. It is to develop sufficient understanding of the most relevant factors early enough to support timely actions while meaningful response options remain available.

CIOs can make this practical by asking five questions:

1. Which cyber decisions must be made in the first moments, the first hour, first day and first week of a serious incident?
2. Who is authorized to make them, what is their availability 24/7 and who deputizes in their absence?
3. Can technical indicators be linked quickly to business impact, financial exposure, legal risk, supplier dependency and external context?
4. Can security teams escalate without creating unnecessary alarm?
5. Can the CEO and board be briefed in decision-ready language, with recommendations rather than technical detail alone?

These questions move the conversation from reporting to leadership, and they reflect the human reality of cyber defence. Employees, analysts, managers and executives are asked to make repeated judgement calls under uncertainty, often with too much noise and too little time. Attackers are often well placed to exploit that reality; resilient organizations tend to design around it

Beyond visibility

Cybersecurity has spent years improving visibility, and that work remains essential. But visibility alone does not create resilience. The next challenge is decision quality.

For CIOs, the strategic shift is that cyber signals become most valuable when connected to real-world consequences: financial, operational, legal, reputational and geopolitical. In a fast-moving incident, the critical question is rarely whether the organization has more data. It is whether leaders can understand what matters, decide what to do and act while meaningful response options remain available.

The organizations that are often most effective in this environment are not necessarily those with the most dashboards. They are often those that have worked to reduce decision latency without sacrificing judgement, often through rehearsal, scenario testing and learning from gaps identified during those exercises. In an environment shaped by ambiguity, compressed timelines and interconnected risk, the ability to make better decisions faster may become one of the defining measures of not just cyber resilience, but of leadership itself.

Ransomware remains one of the most disruptive cyber threats organizations face. Companies have strengthened their cyber defenses over the years, but attackers in 2026 have become faster, more targeted, and increasingly reliant on AI, forcing the need for a change in how organizations approach cyber resilience.

From the rise of AI-enabled attacks and extortion-only campaigns to growing concerns around third-party risk, several trends have emerged over the past several months that are reshaping the ransomware landscape and raising new challenges for enterprise security leaders.

Ransomware attacks today are increasingly designed to disrupt business operations, steal sensitive data, and apply pressure far beyond an organization’s IT environment. Those developments signal that CISOs need to look beyond traditional cybersecurity controls to address operational resilience as well.

Ransomware has become a business disruption strategy

Ransomware has traditionally followed a straightforward model: Attackers encrypt systems and demand payment in exchange for a decryption key.

But today’s attacks are far more complex. Many ransomware groups now combine operational disruption with data theft, extortion, and reputational pressure. Instead of simply locking organizations out of their systems, attackers steal sensitive information before encrypting systems, creating multiple opportunities to pressure victims into paying.

Some campaigns have moved beyond encryption altogether. Rather than deploying ransomware, threat actors exfiltrate sensitive data and threaten to publish it or contact customers, partners, or regulators unless payment is made. These extortion-only attacks are often faster to execute, more difficult to detect, and capable of creating significant business disruption even when systems remain operational.

For IT leaders, this approach changes the conversation. The question is no longer whether systems can be restored. Now the question lies in whether the organization can continue operating while still protecting customer trust, regulatory obligations, and critical business relationships.

AI is changing both sides of the cybersecurity equation

AI expands the volume of valuable enterprise data by increasing the number of connected systems and introducing new third-party dependencies. At the same time, attackers are leveraging AI to accelerate phishing campaigns, identify exposed assets, and make scams that manipulate employees into revealing sensitive information more convincing and difficult to detect. This creates an environment where both defenders and attackers have access to increasingly sophisticated capabilities.

AI is also expanding the number of potential entry points attackers can target. Organizations are rapidly deploying generative AI assistants, integrating large language models into internal workflows, and connecting AI applications to enterprise data repositories. Each new integration introduces additional identities, APIs, and permissions that must be secured.

Without strong governance, these tools can inadvertently expose sensitive information or create new pathways for attackers to exploit. As AI adoption accelerates, CISOs should inventory where AI is being used, understand what data those systems access, and ensure security controls evolve alongside innovation. Technology leaders should evaluate not only how AI systems improve operations but also how these same systems affect identity management, data governance, access controls, and incident response planning.

Third-party risk expands the threat landscape

Enterprise organizations rarely operate in isolation. Cloud providers, software vendors, managed service providers, and AI platforms all have varying levels of access to corporate systems and sensitive information. As organizations become more interconnected, attackers increasingly view trusted third parties as potential entry points.

This means ransomware preparedness extends beyond internal infrastructure. Vendor risk assessments should evaluate cybersecurity maturity, incident response capabilities, and contractual obligations around breach notification. Organizations should also understand how quickly business partners can detect, contain, and communicate cyber incidents, particularly when shared systems or data are involved. A resilient security strategy depends on protecting your own environment and understanding the risks introduced by the broader technology ecosystem.

Cyber resilience has become a board-level priority

Ransomware is no longer viewed solely as an IT issue. Extended outages can interrupt revenue, halt operations, affect customer service, damage brand reputations, and trigger regulatory scrutiny. As cyber incidents become more consequential, boards are asking different questions. Rather than focusing exclusively on security tools, they want to understand recovery capabilities, operational dependencies, and the organization’s ability to maintain business continuity during an attack.

This shift places CIOs and CISOs in more strategic roles. In addition to overseeing technology and cybersecurity, they are increasingly responsible for helping executive leadership understand cyber risk in business terms. That includes communicating the potential operational impact of ransomware, prioritizing technology investments based on enterprise risk, and ensuring cybersecurity aligns with broader business resilience objectives.

Recovery time objectives, business continuity planning, and executive communication protocols are becoming just as important as endpoint protection and network monitoring. Organizations that regularly test recovery procedures, validate backup integrity, and conduct simulated cyber incident exercises with executive leadership are often better positioned to respond effectively when an incident occurs.

What CIOs and CISOs should prioritize now

While no organization can eliminate cyber risk entirely, several foundational practices can strengthen resilience against ransomware and improve an organization’s ability to respond when an incident occurs.

Technology leaders should prioritize the following:

• Maintain and test offline backups. Store critical data in encrypted, offline environments and regularly test restoration procedures to ensure systems can be recovered quickly if production environments are compromised.
• Strengthen identity and access controls. Require multifactor authentication for privileged accounts, limit employee access to only the systems and data they need to do their jobs and continuously monitor for unusual authentication activity.
• Prioritize vulnerability management. Establish a disciplined patch management program to identify and remediate known vulnerabilities before they can be exploited by threat actors.
• Develop a comprehensive incident response plan. Go beyond technical recovery by clearly defining executive decision-making, communications protocols, legal coordination, and stakeholder responsibilities before an incident occurs.
• Evaluate third-party and AI-related risks. Regularly assess the security posture of cloud providers, technology vendors, and AI-enabled platforms to ensure security controls keep pace with an increasingly interconnected digital ecosystem.

Looking ahead

Ransomware is continuing to evolve faster than many organizations’ security strategies and the benchmark for victory can no longer be preventing every attack.

Future success will depend on treating ransomware as an enterprise resilience challenge rather than a purely technical problem. The organizations best positioned for the future won’t necessarily be those with the largest security budgets, but those that have embedded cyber resilience into every aspect of technology strategy. In an environment where both technology and threats continue to evolve rapidly, resilience will increasingly be measured by whether organizations can prevent every attack and by how effectively they can anticipate, respond to, and recover from the incidents that inevitably occur.

Records held in Salesforce and ServiceNow systems are under attack leaving user data exposed, according to researchers at Reco.

The attack appears similar to those perpetrated by the extortion group ShinyHunters, Reco said. ShinyHunters has been particularly active this year, attacking dating sites in January and Oracle in June, and there are fears that they could have found a new target.

Reco has named the latest campaign of attacks “City-Forum,” after a domain name associated with the attackers’ IP address. While it bears similarities to Shiny Hunters’ past exploits, there are also differences. This time around the attacker penetrated the systems through the UI-API layer, an attack point that Reco had not seen used before, and had also created its own toolset to carry out the attack. It is also targeting a native ServiceNow Service Portal search endpoint that has almost no online documentation or well-known open-source tools.

The threat is particularly noteworthy, Reco said, as the attackers have studied the services to map different common data-leak vectors, a sign of an advanced approach.

A Salesforce spokesperson said that it was aware of the campaign in which malicious actors are exploiting customers’ overly permissive Experience Cloud guest user configurations in the campaign to potentially access more data than targeted organizations intended.

“This issue highlights risks stemming from misconfigurations, such as overly permissive guest user profiles, and not from a Salesforce vulnerability,” the spokesperson said.

Regardless of who the attackers were and how the attack was carried out, one thing should be clear: Organizations should be increasingly careful about who they give login credentials to.

This article first appeared on CSO.

Organizations have spent years and billions of dollars hardening their defenses against cyberattacks, but prevention alone no longer settles the question that matters most to a board. Accenture’s State of Cybersecurity Resilience 2025 report stated that organizations had faced an average of 1,876 cyberattacks in a single quarter, a 75% increase over the prior year. What’s more, 63% of the surveyed executives cited a rapidly evolving threat landscape as their biggest challenge. In such a dangerous environment, organizations must assume that eventually an attack will succeed, so IT has to be able to prove that it can recover cleanly once an attacker gets in.

Attackers already understand this shift. Mandiant, a Google subsidiary, reported in its M-Trends 2026 Report that “adversaries are systematically targeting infrastructure such as backups, identity services, and virtualization layers to deny recovery, putting immense pressure on organizations to pay ransom demands or risk losing the ability to recover.” Backup systems have become a primary target.

Demonstrating recoverability has been difficult for IT, because backup, recovery, cybersecurity, and disaster recovery all evolved as separate disciplines, with each solving its own piece of the problem essentially independently. That fragmentation leaves organizations unable to answer basic questions about their own ability to bounce back.

A new discipline, resilience operations (ResOps) has emerged to close the gap between performing backups and proving that an organization can actually use them to recover. ResOps functions as an operating discipline that focuses business, security, and infrastructure teams on recovering critical functions quickly while avoiding reinfection. This discipline also provides the teams with a common framework so they can pivot away from assumptions and anecdotes to instead quantify resilience in a repeatable, sustainable way. Spot-testing of discrete systems is not enough. Organizations need to perform regular tests of the entire system if it is to pivot away from assumptions and anecdotes to quantify resilience in a repeatable, sustainable way.

Additionally, to measure the effectiveness of recovery, the industry needs an updated resilience metric, mean time to clean recovery (MTCR). Metrics such as recovery time objective (RTO) and recovery point objective (RPO) still matter, but neither confirms that restored data is free of compromise. MTCR closes that gap, by measuring how long it takes to validate that a recovered system is both online and clean, giving CIOs, CISOs, and boards a single evidence-based answer during an attack.

Building that kind of resilience starts with architecture. Depending on a single vendor or platform across multiple heterogeneous environments introduces a single point of failure. Diversity is a strength, especially when it comes to the identity infrastructure. Recovery systems that share the same identity layer with production will fail if the identity systems are compromised, so more and more organizations now stand up an independent identity infrastructure solely for recovery. Immutable air-gapped storage rounds out the picture, but it remains rare among organizations, even for their most critical workloads. Finally, during recovery execution, backups should be paired with clean room validation of workloads before anything returns to production.

“For years the industry measured resilience by how fast we could restore data,” says Bill O’Connell, chief security officer at Commvault. “Now the measure that matters is whether we can prove, with evidence, that what we restored is actually clean.”

Vendors such as Commvault are building the infrastructure to support this shift, giving organizations the tools for testing recovery as a complete system rather than a collection of individual failure scenarios and to walk into the boardroom with proof instead of assumptions. But whatever the underlying backup-and-recovery infrastructure in this increasingly dangerous threat environment, organizations need to make attaining clean recovery their goal.

Build real resilience
Learn how organizations are proving recoverability and achieving clean recovery when it matters most.

A Canadian hacker has admitted being part of a group responsible for several major cyberattacks. Connor Riley Moucka pleaded guilty to being part of a coterie of hackers that hit 165 organizations, resulting in the theft of customer records and the extortion of millions of dollars.

Industry sources have identified Moucka as one of the main players in attacks on data hosted by cloud data warehouse Snowflake. Companies affected by the hacks include the likes of AT&T, Ticketmaster and the Neiman Marcus Group.

He worked with two other hackers: John Edward Binns and Cameron John Wagenius. Binns was not in US custody as of April 2026, while Wagenius, going by the name of Kiberphant0m, was arrested in January 2025 and pleaded guilty in July that year

Moucka and other members of the group used stolen login credentials to compromise data belonging to at least 165 customers of a US-based software-as-a-service company. This unauthorized access was used to steal billions of sensitive customer records and download terabytes of information,

“Connor Moucka hacked over 150 companies and organizations, obtained extremely sensitive information, and extorted the victims for millions of dollars. Today’s guilty plea serves as a reminder to all cybercriminals, regardless of where they live, that they cannot hide behind a wall of anonymity. You will be found and brought to justice,” said assistant attorney general A. Tysen Duva of the Justice Department’s Criminal Division

The trial is the result of a coordinated worldwide action against the Snowflake group. The investigation was led by the FBI but benefited from contributions from the Royal Canadian Mounted Police, the Australian Federal Police, Spain’s Guardia Civil, the Security Service of Ukraine and the Turkish National Police.

This article first appeared on CSO.

Two years ago, I sat across from a chief financial officer who had just spent forty minutes on a video call authorizing what he believed was a legitimate acquisition payment. The call included his CEO and two board members, all speaking in familiar voices, all making the kind of small unscripted comments that make a meeting feel real. None of them were real. The audio had been cloned from earnings call recordings, and the video was built from conference footage pulled off YouTube.

What gave it away wasn’t a glitch or a blurred hand. It was a pause. The CFO asked about a side conversation from the previous week that only the real CEO would have known, and the voice on the other end hesitated half a second too long before answering. That hesitation stopped a seven-figure transfer.

It also taught me something I have carried into every engagement since. Executive impersonation has moved from a theoretical AI risk category into an active enterprise security problem, and detection and response capability lags materially behind attacker capability.

The detection tooling gap

When clients ask me what to buy first, I tell them to slow down. The tooling landscape for synthetic media is real, but it is not mature, and treating it as solved creates false confidence at exactly the moment confidence gets tested.

Audio and video forensics tools scan a file after the fact for artifacts synthetic generation tends to leave behind. They are genuinely useful in a post-incident review, where there is time to run deeper analysis. They are far less useful in the middle of a live call, where a decision has to get made in seconds rather than hours.

Liveness detection tries to solve that timing problem by checking for signs of life during the interaction itself, rather than analyzing a file afterward. The trouble is that these systems were mostly built for identity verification at onboarding, a single controlled check at a fixed point in time. Retrofitting them into an unplanned executive call is still mostly aspirational, and most vendors will tell you the same thing privately even while marketing otherwise.

The MITRE ATLAS knowledge base, which catalogs real-world adversarial attacks against AI systems, now documents deepfake-based identity verification bypass as an established attack pattern rather than an edge case. That matters for CISOs because it confirms this is not a hypothetical gap security vendors invented to sell tools. It is a documented technique with case studies attached.

What senior executives specifically need, and what the market still doesn’t reliably offer, is verification that works in the moment a request is made rather than after the fact. Until that exists at scale, the tooling has to sit inside a broader protocol rather than stand in for one.

A framework enterprise teams can deploy now

Tooling alone will not close this gap, so the operational framework matters more than any single product. Here is what I put in place with clients, organized around five actions.

1. Verify. Multi-factor human verification for executive-level communications means more than a callback. It means a pre-agreed authentication phrase for the small circle of people who can approve high-sensitivity or high-value actions, changed on a schedule and never guessable from a public LinkedIn bio. It means out-of-band confirmation as a hard requirement, not a courtesy, for any request involving money, credentials or a change to standing instructions. I watched this stop an attack outright. A caller using a cloned voice of an executive asked a colleague for help with a confidential wire. The colleague asked for the agreed phrase, and the line went dead within seconds.
2. Detect. This is not about buying a detection tool. It is about continuously monitoring the executive’s digital identity surface before an attacker even builds the deepfake. That includes tracking domain squatting on the executive’s name, watching for social profile impersonation, and knowing where voice samples are already sitting in public conference recordings and podcast appearances that an attacker could pull from tomorrow. Most security teams monitor the network. Very few monitor the raw material an attacker needs to build a convincing fake in the first place.
3. Respond. When an impersonation attempt is identified or succeeds, the response playbook needs to specify who freezes a transaction, who pulls the call recording before it disappears, and who brings in forensics immediately so there is a documented basis for every decision that follows. It needs a defined escalation path that does not depend on the target believing something is wrong, because most executives will not report a strange call themselves. Build the reporting habit around the transaction, not the suspicion.
4. Train. Executive protection training has to include impersonation awareness now, and not just for the executive. Assistants, chiefs of staff and family office contacts are frequently the actual point of contact an attacker targets, since they often have more standing authority to approve something quickly than the executive expects them to use. This has to be a working habit, not a slide deck people sit through once a year.
5. Integrate. Executive impersonation cannot sit inside a single team’s silo. It needs coordination between security operations, communications, legal and executive protection, because a voice clone built from a podcast appearance does not touch a single system any one of those functions monitors on its own. A CSO Online feature on deepfake defense documented an almost identical wire fraud case and reached a similar conclusion that the organizations recovering fastest were the ones that had already rehearsed the coordination across teams before an incident forced it.

Where the market hasn’t caught up

Even programs built around all five of those actions still run into gaps that no enterprise has fully closed.

The first is the personal exposure gap. Most protocols assume the target is inside a corporate communication channel. Attackers are increasingly working the other direction, reaching family members or personal devices where none of the corporate verification steps apply at all.

The second is the public-facing gap. Livestreams of major corporate events have been hijacked by deepfakes of the company’s own executives, often promoting cryptocurrency scams, with fake feeds sometimes drawing sizeable audiences before takedown. That is not an internal fraud scenario a SOC playbook was built for. It is a brand and platform-level impersonation that needed coordination with a video platform in real time, and almost nobody has that relationship pre-built. The security team needing to reach a platform’s off-hours trust and safety escalation path in the middle of a live event is functionally starting from zero every time, and the incident is often over by the time the right internal owner on the platform side is even identified.

The third is measurement. Very few security teams can currently tell their board how prepared they actually are for this category of risk, because the tabletop exercises that would surface the gaps are still rare. Boards are starting to ask the question anyway, often after reading about another company’s incident rather than their own, and a security leader without a rehearsed answer is at a real disadvantage in that conversation.

Back to that CFO on the video call. What saved him was not a tool. It was a habit, built well before the attack, of treating a hesitation as reason enough to stop. That is still the most reliable control available, and it will remain the most reliable control until the rest of this framework catches up to it.