Notifications
Clear all
Topic starter
18/08/2026 2:17 pm
TL;DR: CI Fortify reframes critical infrastructure isolation as a data governance problem as much as a network resilience one, because operators must know where sensitive and operational data lives, who can reach it, and whether recovery tooling still works when external connections fail, according to BigID. The real test is whether discovery, classification, and recovery planning can operate inside an air-gapped or degraded environment without losing visibility into third-party flows or AI-driven governance dependencies.
NHIMG editorial — based on content published by BigID: What CI Fortify’s Isolation Steps Actually Require From Your Data
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
Questions worth separating out
Q: How should organisations handle data governance for critical infrastructure isolation plans?
A: They should base isolation planning on a live map of data, access paths, and third-party dependencies, not on network diagrams alone.
Q: Why do standing access paths become more dangerous during isolation events?
A: Because an isolation event changes the environment faster than access reviews can.
Q: How do teams know whether their data governance stack is resilient enough for offline operations?
A: Test whether discovery, classification, and access intelligence still work when outbound connectivity is removed.
Practitioner guidance
- Map data, not just networks Build the isolation baseline from a current inventory of where critical and sensitive data actually resides, including SaaS, cloud, vendor tools, and on-prem systems.
- Trace every third-party data path Document and review every connection from critical services to vendors, remote access tools, contractors, and cloud platforms.
- Test offline governance before a crisis Confirm that discovery, classification, and access intelligence still operate when outbound connectivity is removed.
What's in the full article
BigID's full article covers the operational detail this post intentionally leaves for the source:
- Data discovery and classification workflows across cloud, on-prem, and unstructured sources
- Connection-mapping detail for vendors, contractors, SaaS tools, and remote access paths
- How access intelligence supports isolation sequencing and recovery prioritisation
- Why fully air-gapped operation matters for governance tools that would otherwise depend on external services
👉 Read BigID's analysis of CI Fortify, data mapping, and isolation planning →
CI Fortify and isolation planning: is your data map current enough?
Explore further
18/08/2026 3:10 pm
Data isolation is really identity and access governance with a resilience label. CI Fortify looks like an OT continuity framework, but its execution depends on knowing which systems, people, service accounts, vendors, and tools can reach operational data. That is an identity problem as much as a topology problem, because the wrong access path left standing can undermine a clean isolation event. Practitioners should treat data reachability and entitlement visibility as core inputs to resilience planning.
A question worth separating out:
Q: Who is accountable when an isolation plan fails because data was not mapped accurately?
A: Accountability usually sits across infrastructure, security, data governance, and operational leadership, because the failure is cross-functional. The practical standard is whether the organisation could identify critical data, trace its connections, and recover it in priority order before isolation was needed. If not, the plan was incomplete, not unlucky.
👉 Read our full editorial: CI Fortify makes data mapping a critical infrastructure resilience test
