Zum Inhalt springen

What CI Fortify’s Isolation Steps Actually Require From Your Data

What CI Fortify’s Isolation Steps Actually Require From Your Data

CISA’s new CI Fortify initiative, built jointly with the Australian Signals Directorate, the UK’s NCSC, and Canada’s Cyber Centre, puts a question in front of critical infrastructure operators that most have never had to answer under real pressure: if you had to cut the cord to your cloud vendors, telecom providers, and third-party networks tomorrow, and keep essential services running that way for weeks or months, could you?

The guidance treats this as the planning baseline, not the edge case. Operators are told to assume third-party connections go unreliable in a conflict scenario and that adversaries may already be sitting inside OT networks. Two capabilities carry the weight of the response: isolation and recovery.

The isolation path itself runs six steps. Identify the minimum systems needed to deliver a critical service. Map every connection those systems have to the outside world. Classify systems by criticality and trust. Build separation and isolation points. Create and test a graduated isolation plan. Recover anything an adversary compromises before that plan gets used for real.

That’s a strong framework for OT engineers thinking about network topology. It says almost nothing about the data sitting inside the enabling systems around OT, the corporate applications, cloud platforms, and vendor-connected tools holding the sensitive and operational data an organization actually needs during and after isolation. That gap is where BigID does real work.

The data map CI Fortify assumes already exists

Every step in the isolation path leans on an organization already knowing where its critical data lives, who and what can reach it, and which systems it flows through. CISA’s own guidance calls for documenting every connection between vital systems and corporate networks, remote access tools, cloud environments, vendors, and contractors. Read closely, that’s a data mapping exercise wearing a network engineering label. Plenty of organizations can produce a network diagram. Far fewer can produce an accurate, current map of where sensitive and operational data actually sits, especially after years of SaaS sprawl, shadow cloud storage, and vendor integrations nobody fully inventoried.

Where BigID fits each of the six steps

Identify the minimum systems for a critical service. BigID discovers and classifies data across structured and unstructured sources, cloud and on-prem, so an organization can see which systems genuinely hold the data behind a critical service instead of relying on an architecture diagram that’s three reorgs out of date.

Map every connection to the outside world. Data mapping shows where data actually moves, including flows to third-party vendors, SaaS tools, and cloud platforms. CI Fortify’s connection-mapping requirement stops being a manual audit and becomes something an organization can query on demand and keep current.

Classify systems by criticality and trust. Sensitivity classification gives an organization the actual basis for CI Fortify’s criticality tiers. A system holding regulated customer data earns a different isolation priority than one holding marketing collateral, and that distinction only means anything if the data underneath has been classified in the first place.

Build separation and isolation points. Access intelligence shows who and what has standing access to sensitive data, including vendors, remote access tools, and service accounts. That’s the same access surface CI Fortify wants hardened and segmented ahead of an incident, not mapped for the first time in the middle of one.

Create and test a graduated isolation plan. A living data inventory means the isolation plan gets tested against the real environment, not a snapshot from last year’s audit. Data environments shift constantly. A plan tested against stale mapping is a plan that breaks the first time it’s needed.

Recover compromised systems. Recovery starts with one question: what gets rebuilt first. A classified, prioritized data inventory answers that directly, restore the systems holding the most sensitive and highest-impact data first, rather than working through a queue in whatever order systems happen to come back online.

The sovereignty exposure CI Fortify doesn’t name

CI Fortify assumes a conflict scenario where cloud platforms and telecom providers go unreliable. There’s a quieter version of the same problem that doesn’t need a geopolitical crisis to matter: if the AI doing your data classification and governance work has to call out to a third-party model hosted outside your control, your sensitive data, or metadata about it, is leaving your environment on every scan, on a normal Tuesday, crisis or not. CI Fortify’s isolation scenario just turns that standing exposure into a hard operational failure.

BigID’s approach runs data intelligence, classification, and AI-driven analysis without a dependency on an external LLM provider. Processing happens inside the customer’s environment. That matters for two separate reasons that CI Fortify happens to bring together: it keeps sensitive data from transiting to a third party as a matter of routine, and it means the platform doing this work doesn’t disappear the moment connectivity to that third party is cut.

Air-gapped, from federal edge case to baseline requirement

Most vendors treat air-gapped and fully offline deployment as a rare ask from a handful of federal or defense customers. CI Fortify turns that into a baseline requirement for anyone running critical infrastructure. An isolation event doesn’t pause selectively, it takes down every cloud dependency at once, including whatever tool an organization relies on to see its own data.

BigID can run fully on-prem and air-gapped, with discovery, classification, and governance operating with zero outbound connectivity required. No phone-home telemetry, no dependency on a hosted API to function, no silent failure mode where the security tooling goes dark right alongside the systems it’s supposed to help isolate. An organization can run its full data governance program inside a sealed environment for the entire duration of an isolation event, then reconnect and reconcile once the incident is over.

What organizations need to do

  • Inventory where sensitive and operational data actually lives, not where it’s documented to live
  • Map data flows to every third party, cloud platform, and remote access tool touching that data
  • Classify data and systems by criticality so isolation and recovery priorities are based on real risk, not guesswork
  • Check whether any AI-driven tooling in that stack depends on an external model provider, and treat that as a sovereignty gap even outside a crisis
  • Confirm the platform doing this mapping can run fully air-gapped, not just “cloud-optional”
  • Build a recovery sequence based on data sensitivity and business impact, tested before it’s needed

CI Fortify is asking critical infrastructure operators to prove they can run blind to the outside world for months at a stretch. The organizations that can actually do that will be the ones that already know, in specific and current detail, what data they’re protecting, where it lives, and whether the tool watching over it needs the outside world to keep working.

Inhalt