The age-old IT defense when compliance violations are investigated by regulators is to try and keep a low profile — and hope no one looks too closely. But with enhanced SEC interest in all data breaches encouraging regulators around the globe to take those closer looks at IT, data breach disclosure rules are becoming more strict.

While that might be unsettling for cybersecurity executives, it is also disturbing news for IT admins, who could find themselves under a remarkably uncomfortable spotlight. 

Consider this recent move by the New York State Department of Financial Services against the Delta Dental Insurance Company. State officials hit the insurance company for improper and inconsistent enforcement of its own data retention policies; improper incident response plan protocols; and improper notification of the security incident itself. 

The company was fined more than $2 million.

The data retention violations are perhaps the most problematic. Had that policy been enforced properly, much of the stolen data would have been destroyed long before the attackers could have accessed it. 

It’s not simply a matter of whether the IT rules for retention were sufficiently strict. Some regulators — and especially the US Federal Trade Commission (FTC) — focus extensively on companies who don’t do what they say publicly. If a corporate website promises something to customers, the FTC will hold companies to their word. 

Think about that the next time you assign a summer intern to handle your website’s copy. 

Inconsistent implementation of data retention policies can deliver other legal headaches. Having a good policy approved by the general counsel is fine, but it means nothing if all of your people do not follow it strictly. 

Let’s say one of your business units is being sued for having done something naughty. Opposing counsel subpoenas your business records, including emails from a few years ago. Your attorney responds that those email records no longer exist; they were deleted last year in accordance with corporate policy on data retention that says everything of a certain nature has to be deleted after one year. 

Fair enough. But what if opposing counsel in a deposition asks,“Really? Does that policy apply to all records of that nature?” You say that it does. 

“It might interest you to know that we have sworn testimony from four other employees who showed us emails of the same nature that were more than five years old. So why did you adhere to your policy regarding emails that might prove the fraud but somehow you did not delete others? Sounds a little selective, no? I think the judge would agree.”

In the dental case, the company had a strict policy on retention rules. But corporate software was programmed with “the ability to shorten, extend, or disable MOVEit Transfer’s default retention settings on a folder-by-folder or file-by-file basis.” 

The regulators then swooped in because the insurance company “had no written policy or procedure for requesting, reviewing, or approving such changes to folder retention settings.”

The best retention policy would, in theory, have no exemptions. But if you’re going to allow exemptions, you need a precise policy documenting how and when they can occur. There should be a required form so that a manager can write out the reasons for this specific exemption.

The New York state document is an important one to carefully review; it provides an excellent roadmap to how compliance can go wrong — and useful information on how to keep something similar from  happening to your company.

The European Union has now published a set of measures aimed at boosting Europe’s tech industry to help reduce reliance on US and Chinese suppliers for AI, cloud, and semiconductors. The proposals include rules to restrict the use of US hyperscalers for certain public sector procurement purposes, but stop short of banning them outright.

“Technological sovereignty does not mean protectionism. Europe remains grounded in openness, partnership, and fair competition,” Henna Virkkunen, executive vice president for Tech Sovereignty, Security and Democracy, said in a statement Wednesday. “At the same time, Europe wants to be in the position to make its own choices, avoiding dependence on single dominant suppliers, especially from non-like-minded countries.”

The European Technological Sovereignty Package — released after several delays — includes two legislative proposals: the Cloud and AI Development Act and Chips Act (CAIDA) 2.0 and the Open Source Strategy and Strategic Roadmap for Digitalization and AI in Energy.

CAIDA aims to triple data center capacity in the next five to seven years by easing restrictions for deployments across the EU. It also includes rules that, if enacted, would require EU public bodies to meet certain sovereignty criteria for cloud service procurement related to certain sensitive workloads.

Amid ongoing trans-Atlantic tensions and a long-time deep reliance on US tech providers, European organizations have become increasingly wary of a “kill switch” that would cut off access to digital services. There are also concerns that US hyperscalers could be compelled to share data with US government under the CLOUD Act and Foreign Intelligence Services Act (FISA), even when data centers are located in Europe.

The CAIDA proposals include four levels of criteria for suppliers; the most basic includes data center infrastructure located and operated in the region – something  many US cloud suppliers already provide – with stricter rules around supplier ownership, full control over the software stack, and more stringent cybersecurity certification.

The majority of existing EU public sector workloads (70%) fall under the first level, with 20% at level 2, and 9% at level 3. Only a small proportion (1%) of the most sensitive workloads would require level 4.

Other proposals include the Chips Act 2.0, a follow-up to the 2023 legislation that sought to improve semiconductor production capabilities; the updated version now aims to boost research and spur demand for domestically produced processors. 

The legislative proposals must be negotiated by the European Parliament and Council of the European Union before adoption.

IBM has launched a tool designed to help customers assess cloud-sovereignty risks and meet regulatory compliance requirements. 

The Sovereignty Risk Profile launch comes as digital sovereignty becomes a higher priority for organizations concerned about where data is stored and processed. According to an IBM survey, 93% of executives believe sovereignty needs to be part of their business strategy.  

Via the new tool, customers can set up policies related to regulatory and business requirements — such as where data resides and how it’s protected, for instance. These policies can be applied to specific cloud workloads, regions, or zones in the Sovereignty Risk Profile tool, allowing users to track sovereignty requirements “in real time,” IBM Cloud product manager Janet Van said in a blog post, with “visibility into configurations, encryption posture, and environmental controls.” 

It’s then possible to assess compliance and decide what workloads meet sovereignty requirements. 

Tracking the factors that contribute to sovereignty is a challenge for many organizations, said Holger Mueller, vice president and principal analyst at Constellation Research. “It is very difficult, as you don’t know about the details of the stacks; sometimes, even the location of data is not fully transparent,” he said.

The Sovereignty Risk Profile “addresses many of the compliance-related requirements associated with data residency and encryption, while also tackling sovereignty from a resilience and concentration-risk perspective,” said Dario Maisto, senior analyst at Forrester.

However, the monitoring tool can only do so much to address digital sovereignty concerns, he said. While it can help organizations identify and report on potential issues, it “does not help [make] clients more or less sovereign, per se: it has only the potential to tell that a sovereignty problem is there.”

Broader questions around digital sovereignty remain difficult to address, he said, as there’s no universally accepted definition of the concept and limited legislation to establish clear requirements. 

Mueller described a spectrum of sovereignty issues that depend on factors such as whether data is stored, processed, and backed up in a customer’s own country, as well as whether staff that operate the data are domestic nationals. “Then there is the sovereignty of the software supply chain — but here everybody is dependent,” he said.

To further complicate matters, while several US hyperscalers sell sovereign-branded cloud services to European customers — with local staff and infrastructure —  concerns remain about the potential for extra-jurisdictional access to data, due to the US CLOUD Act and the US Foreign Intelligence Surveillance Act (FISA).

The Sovereignty Risk Profile is available within IBM’s Security and Compliance Center Workload Protection. It’s the latest in a range of IBM Cloud products aimed at addressing customers’ sovereignty concerns, including the recently launched IBM Sovereign Core software platform. 

T

All of the big AI models violate EU rules on AI and data protection to varying degrees, according to the nonprofit research foundation Aithos.

Aithos tested the models using its own tool, LARA (Legal Assessment for Real-world Agents), which simulates real-world situations where AI assistants may find themselves in legally questionable situations, according to The Register. The tests measure compliance with the GDPR and the EU’s AI Regulation, among other things and found the models collected user data without proper consent, attempted to manipulate vulnerable individuals, or created psychological profiles of users.

According to the results, all major language models failed to meet EU legal requirements; some violated the rules in up to 93% of cases. The best result was achieved by the Anthropic model Claude Opus 4.7, which was in compliance about 54% of the time.

Aithos warned that responsibility for the shortcomings does not lie solely with AI companies. Companies that build their own AI agents on top of these models could also be held legally liable.