AI, Data Protection and the Adama Doctrine

Fans of the TV show Battlestar Galactica will know the reference. For those unfamiliar with a show that served as a warning rather than a blueprint for future society, the Adama doctrine is simple: in a world of AI, don't network your computers.

Over the past few decades we have done precisely the opposite, from the earliest days of the internet through to the cloud computing craze that saw CTOs leap with little thought for data ownership, governance, or protection. That trajectory now needs to be questioned, not reversed wholesale, but tested system by system, and increasingly function by function within each system, against two questions. The first is familiar: is this data necessary to collect and hold at all? The second is asked far less often, and matters more: does this system, or this part of it, need a network connection at all? And if it does, for how long does that connection actually need to stay open? "Permanent" understates the point. A connection scheduled to open for thirty seconds once a day is still a connection, and thirty seconds is enough for an opportunistic, AI-augmented attack to find it. Connectivity is routinely treated as a fixed property of a system rather than a design choice with a cost and a duration: something switched on once and never revisited, rather than something that has to keep earning its place, window by window.

The two questions point toward the same underlying discipline. Every cyber defence, however robust, is eventually broken; that is the nature of an arms race between attacker and defender. Layering multiple defences doesn't change that conclusion, it only changes the time and cost it takes an attacker to work through them, and AI-augmented attacks are compressing both. An AI-augmented attacker doesn't just find the first way in faster. It can chain the breach of one layer directly into an attack on the next, far faster than a human-paced intrusion would, shrinking the window in which a defender would ordinarily detect a breach at one layer and reinforce the layers behind it before the next one gives way. The organisations that fare best when that happens will not be the ones who believed most firmly in their perimeter, or in the depth of their layered defence. They will be the ones who assumed every layer would eventually be breached and designed accordingly: limiting what an attacker can reach once inside, including by keeping sensitive data in a form, and on systems, that a successful intrusion cannot simply walk out with. Permanent connectivity is one of the clearest ways that discipline is undermined by default, often for reasons that made sense in isolation and were never revisited once the risk changed.

The Canary, the Alarm, and the Audit

GDPR was the canary in the coal mine: it introduced potentially catastrophic consequences for data mismanagement and for the cybersecurity breaches that exposed such data. It established, for the first time at this scale, that data exposure was not merely a reputational problem but an existential financial one.

The EU AI Act is the emergency alert system. It regulates what can be built and deployed, on the basis that the model itself, not just the data it touches, is now a source of risk. And that risk doesn't disappear once a model is restricted or blocked in one jurisdiction or use case. The model exists, and history has shown that what has been created cannot be uncreated.

Taken together, these regimes describe a shift in what regulators consider adequate. It is no longer enough to protect the data sitting inside a system. Increasingly, organisations, and now, with the Critical Third Party regime, the providers underneath them, must be able to justify the architecture itself, including whether it needed to be connected, and to whom, in the first place.

Damage and Exposure Are Not the Same Risk

It is always the case that defence strategies adapt to meet successful offence: in sport, in conflict, in crime, and in cybersecurity. In a world of AI-augmented attacks, even a short window before a successful defence risks exposure of extreme volumes of critical data. The right response to that isn't a belief that every attack can be prevented. It's a discipline of assuming a breach will eventually happen, and designing so that when it does, the damage is contained rather than total.

It's worth being precise here about what isolation actually defends against, because the example most people reach for doesn't quite fit. Stuxnet, the malware that damaged centrifuges at Natanz, is often cited as proof that air gaps can be crossed and are therefore pointless. But Stuxnet was built to cause physical damage, not to extract information. Its problem was delivery (getting a payload onto an isolated system), and it solved that through infected removable media, nation-state resourcing, and a degree of targeting most organisations will never face as a routine threat. Extraction is a different and generally harder problem. A genuinely air-gapped system, with no removable media path and no network egress, doesn't just raise the cost of delivering an attack into it; it raises the cost of getting anything back out. For data protection specifically, as distinct from sabotage, that distinction matters more than the Stuxnet comparison usually allows for.

"Damage to a system, however severe, is recoverable. Exposure of data is different in kind, not just degree."

This is also why damage and exposure shouldn't be treated as the same category of risk. Damage to a system, however severe, is recoverable: a rebuild, however costly, however slow, restores function. That is the problem disaster recovery has always been built to solve, and it remains a valid and necessary discipline regardless of how connected or isolated a system is. Exposure of data is different in kind, not just degree. There is no rebuild for information that has already left the estate. The moment of extraction is the moment the harm occurs; everything after that is damage limitation, not recovery. This is precisely the distinction GDPR and DORA are built around: neither regulation asks whether you can restore service, both ask whether you can prevent extraction, and failing that, how fast you can detect and contain it. A resilience strategy built primarily around recovery answers the wrong half of the problem if the actual risk is exposure.

None of this removes the human vector. Phishing, credential theft, insider access, and social engineering work identically whether the target system is connected or isolated, and no architectural decision removes them. What isolation and segmentation change is the blast radius once that vector is exploited. An AI-augmented attack against a connected data estate is opportunistic by nature: it doesn't need to know your organisation exists in advance, it needs to find one route in, and once inside, a connected estate offers near-zero marginal cost to expand across. The same breach against a segmented or isolated system is contained by the same segmentation that made the initial compromise harder to turn into a total loss. The variable that matters isn't whether an attack can succeed: assume, eventually, that it will. It's what the attacker can reach once it has, and in what form. Removing a permanent connection is one lever; the other, working alongside it, is ensuring that data reachable at all sits in a form that isn't immediately usable if it is reached: encrypted at rest, tokenised, or held in a structure that yields little on its own without a key or context the attacker doesn't have. Containment is as much about the state the data is left in as it is about the path used to reach it.

The Default Nobody Chose

The very threat that often served as a principal reason for moving into managed cloud environments (cyber threats, and the promise of consolidating cybersecurity expertise into the cloud provider's hands) starts to look weaker in an age where AI models are themselves treated as a security risk requiring restriction. Consolidation was meant to concentrate expertise. It also concentrated the target.

Major software providers have channelled the move to constant connectivity, and it is worth naming the mechanisms plainly rather than treating this as a vague drift. Automatic update cycles now assume an always-on connection as a baseline, to the point where offline operation is treated as the exception requiring configuration, not the default requiring justification. Licensing models increasingly depend on periodic online activation or continuous verification against a vendor's servers, which means a system's ability to keep functioning is no longer entirely within the operator's control. And the efficiency case for connectivity (real-time telemetry, remote support, continuous feature delivery) is genuinely persuasive on its own terms. None of this is a criticism of any single vendor's motives. It is a description of how the default assumption shifted, incrementally and for reasons that each made sense in isolation, until connectivity became the starting position for almost every system rather than a decision made deliberately for each one.

Connecting processes, functions, and systems to make data more accessible has, for most of that history, been a straightforwardly good engineering decision: it works, and efficiency has been the metric organisations were optimising for. That calculation hasn't disappeared. What has changed is the other side of the ledger: the risk sitting opposite that efficiency has grown sharply enough that it now needs to be weighed as a first-order resilience decision, not an implicit default nobody actively chose.

A Gradation, Not a Binary

None of this is an argument for ripping out connectivity wholesale. Operational technology and critical infrastructure environments (power generation, water treatment, rail signalling) have been working through exactly this problem for years, out of necessity rather than choice, because the consequences of getting it wrong are physical rather than merely financial. The logic those sectors use is instructive: treat connectivity as a spectrum to be assessed system by system, not a single switch to be thrown organisation-wide. Standards such as IEC 62443 formalise this through the idea of zones and conduits: grouping systems by function and risk profile into zones, then explicitly defining and controlling the conduits that connect one zone to another, rather than assuming any two systems that could usefully talk to each other should be allowed to. The value of that model isn't the specific standard. It's the underlying discipline: every connection between systems is a decision that has to be justified on its own terms, not an inherited default. Most organisations outside OT environments have never been required to think this way, because the consequences of a breach have historically been treated as recoverable in a way that operators of a water treatment plant or a rail network have never been able to assume.

A useful working version of that spectrum runs roughly as follows: fully air-gapped systems with no external path at all; air-gapped systems with a controlled, one-way transfer mechanism for the rare cases where data genuinely needs to move; internally segmented networks with no external route out; and internet-facing systems with tightly controlled egress. None of these is inherently right. Each is an answer to the same question, applied to a specific system: does this need to be connected, and if so, how much, for how long, and to what?

It's worth pausing on the second point on that list, because "controlled, one-way transfer mechanism" can quietly reintroduce the very risk the rest of the spectrum exists to avoid. A scheduled sync, a USB handoff, a data diode: each is genuinely lower-risk than a permanent link, but each still opens a connection for some window, however brief and however tightly controlled, and a brief window is still a window an opportunistic attacker can be waiting for. The only transfer method that removes the window entirely is one with no electronic link at all: a person reading data from a screen on one system and keying it into a second, permanently offline system by hand. It's slow, it doesn't scale, and it introduces its own error risk in exchange for removing the connection risk. But for the genuinely small, genuinely rare movements of data that some fully air-gapped systems require, it is the only method that closes the gap completely rather than narrowing it. Where that trade-off is worth making is specific to the data and the system in question. The point is that it belongs on the spectrum as its own, harder-edged option, not folded into "controlled transfer" as though every controlled transfer carries the same level of risk.

Where to Start: Sequenced by Consequence, Not Convenience

None of this is workable as a single overnight reclassification exercise, and it shouldn't be attempted as one. The spectrum above answers "how" a system's connectivity should be shaped; it says nothing about the order in which systems get evaluated, and order matters, because no organisation has the capacity to run this test against its entire estate at once. The graduated approach that runs through this whole piece applies as much to the rollout as it does to the architecture itself: staged, not all-or-nothing, with the systems capable of doing the most damage assessed first.

That means ranking systems, before anything else, against what a compromise would actually cost: not the size of the system, not how interesting it looks technically, but the consequence of exposure. Three questions do most of the work: what would be exposed (client data, personal data, commercially sensitive material); how sensitive is it in isolation, since a small amount of the wrong data can cause disproportionate harm regardless of volume; and what is the realistic commercial or reputational cost of that specific exposure, as distinct from the technical cost of the breach itself. On that basis, a system holding a modest volume of client financial records or an unreleased commercial position will often rank well above a system holding a large volume of low-sensitivity operational logs, even though the second looks like the bigger target by traffic or scale alone.

Once that ranking exists, the two-question test earlier in this piece gets applied top-down. The systems that would do the most damage if compromised are evaluated first, moved along the spectrum first, and revisited most often as the threat picture changes. Systems lower on the ranking can reasonably keep a more permissive connectivity posture for longer: that's a deliberate sequencing decision, not an oversight. A graduated approach is only a discipline, rather than an excuse for inertia, if the order in which it's applied is as deliberate as the destination.

The System That Has to Work When Everything Else Doesn't

There is one category of system that tends to rank at or near the top of that consequence-led ordering, and it sits close to home for anyone in operational resilience: the platforms that hold the BCMS itself, and the tooling used to coordinate an active incident response. Compromise here doesn't just expose data: it can degrade the organisation's ability to respond to whatever incident is already underway, which is a harder cost to quantify than a data-protection fine but arguably a more severe one. These systems present a genuine paradox. They are needed most precisely at the moment a disruption is underway, which may be exactly the moment the organisation's primary network is degraded, unavailable, or itself the target of the incident being responded to. A BCMS platform that depends entirely on the same corporate network and connectivity as everything else is, in effect, betting that the infrastructure it exists to provide continuity for will still be functioning when it is called upon. That is not always a safe bet, and organisations have known this for a long time in one specific respect: it is precisely why printed, physical copies of BCPs remain standard practice, to cover the scenario where no computer access is possible at all. The paper copy is an admission, made without much fanfare, that a connected system cannot be relied upon to be there when it is needed most.

The interesting question is why that same logic has not, in most organisations, been extended to the digital tooling around it. BCMS platforms and incident response systems typically hold sensitive corporate data rather than personal data (escalation trees, crisis decision logs, regulatory notification templates, recovery runbooks), so the regulatory driver is different from the GDPR-centred argument elsewhere in this piece, but the exposure and availability risks are, if anything, more acute. If such a system needs to be reachable in the middle of an active incident, does it need to be reachable over the same external connection that may have been compromised, degraded, or is itself under attack? Does day-to-day convenience (remote access, distributed teams, ease of updating plans) genuinely outweigh the risk that the tool built to coordinate a response to a disruption becomes a casualty of the same disruption?

Applying the test to a typical BCMS platform tends to produce a split decision rather than a single verdict, which is a more useful outcome than either extreme. A crisis communications module, which has to reach email systems and external parties in real time, needs its external connection without qualification: there is no disconnected version of that function that would work. Evacuation and travel-documentation functionality is a different answer entirely: it does not require live external connectivity at all, and could sit on a disconnected system whose only point of contact with the outside world is a single controlled, one-way transfer at the moment a manifest is actually needed, or, for the version of that system holding the most sensitive detail, no electronic transfer at all, with the finished manifest read off screen and rekeyed into the external system by hand. Two functions within the same platform, supporting the same incident, arrive at two different correct answers once the question is put to each in turn.

That points to something more demanding than it first appears. The evaluation this article is arguing for cannot stop at the level of the whole system; it has to go further, to the level of the individual function or component within it, because a single platform can quite legitimately need a fully connected element and a fully disconnected one at the same time. That is a materially harder architectural challenge than choosing one connectivity posture for a system as a whole: it means designing platforms from the outset to support genuinely different postures for different parts of themselves, with deliberate, controlled points of contact between them, rather than assuming every function inherits the exposure of the system it sits inside. The more granular the threat, the more granular the design decision needs to become.

Taken to a practical conclusion, this argues for something more deliberate than most organisations currently hold: dedicated, disconnected laptops, preloaded with the tools and information a crisis actually requires, that BC and crisis management professionals can operate with no network dependency at all. Such a device carries no connectivity risk whatsoever, because it has no connection to lose or to be exploited through. But it still depends on power, and that dependency has its own limit: a laptop's battery, and any UPS provision behind it, will eventually run down in a sufficiently prolonged event. This is why the fallback beneath even that layer still matters: printed plans, which depend on nothing beyond the light to read them by, remain the appropriate answer to a scenario involving an EMP, extended power loss, or any failure that outlasts the batteries in the room. The result is a genuine hierarchy rather than a single choice: printed plans as the layer that survives total power loss, dedicated disconnected devices as the layer that survives loss of network while still depending on power, and connected tooling as the most capable layer and, correspondingly, the one carrying the most exposure and the most dependency. Each layer trades capability for resilience in a different place, and knowing which layer a given function belongs on is, again, exactly the question this article is arguing every system and every function within it should be asked.

The Question Every Organisation Should Be Able to Answer

Rather than jumping ever further into cloud by default, CIOs and CTOs should be applying a different test to every system and every process: does this system, or parts of it, need online access, not just the data, the system itself? And if it does, do the benefits of that connectivity genuinely outweigh the exposure it creates once an AI-augmented attacker gets a single credential inside the perimeter?

Asking that question doesn't mean every answer will be no. It means the answer stops being assumed. We need to be thinking in terms of firebreaks, data silos, and offline-by-default systems wherever there is no definitive need for online access, not as a rejection of connectivity, but as the discipline of only accepting the risk it carries where the benefit has actually been shown to justify it.

"The question is no longer whether a system can be protected. It's whether it needed to be exposed at all."