The US Federal Bureau of Investigation has removed an Accenture contractor working on its PeopleSoft installation over their role in a data breach that exposed personal details of FBI employees, Reuters reported Monday.

This is the first time that anyone other than the hacker group Shinyhunters that claimed responsibility for the breach has linked it to PeopleSoft.

“To date, our review has determined that the incident occurred as the result of a security failure of a platform managed by a third-party organization — after a contractor failed to implement a security patch explicitly issued to secure the platform,” FBI Cyber Division Assistant Director Brett Leatherman told Reuters. “As such, the FBI has removed the contractor and taken all necessary steps to both mitigate any further risk and protect our workforce.”

Accenture was the third-party organization Leatherman would not identify, “two sources familiar with the matter” told Reuters.

As for the unnamed, unpatched platform, Reuters’ sources said that was Oracle PeopleSoft, the HR system that hacker group ShinyHunters claimed to have exploited in last month’s break-in.

This article first appeared on CSO.

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.

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.