Isolated Minimum Infrastructure: The Last Line of Defence for Business Continuity

Every enterprise assumes its infrastructure will keep running. Until it doesn't. Ransomware encrypts your Active Directory. A cloud provider has a multi-region outage. A supply chain attack compromises your CI/CD pipeline. The question isn't whether it will happen — it's whether your organisation can still function when it does.

Isolated Minimum Infrastructure (IMI) is the answer: a pre-defined, pre-tested, segmented subset of your systems that can operate independently when everything else is compromised. It's not a product you buy. It's a discipline you build.

What Is Isolated Minimum Infrastructure?

IMI is the smallest set of systems, data, and connectivity required to maintain critical business operations during a catastrophic event. Think of it as a survival kit for your IT estate:

• Identity and access: A standalone identity provider that doesn't depend on your primary Active Directory or cloud IAM
• Communication: Out-of-band communication channels (not dependent on your primary email or Slack)
• Critical data: Immutable, air-gapped backups of the data needed to resume operations
• Core business logic: The minimum compute needed to run essential processes (payments, patient records, trading platforms — whatever keeps the business alive)
• Network segmentation: Physical or logical isolation that prevents lateral movement from compromised zones

Why Traditional DR Isn't Enough

Disaster recovery assumes your backup environment is trustworthy. Modern attacks specifically target that assumption:

• Ransomware targets backups first: Attackers dwell for weeks, discover backup systems, and encrypt them before launching the visible attack
• Cloud DR shares trust boundaries: If your production AWS account is compromised, your DR account with the same IAM trust chain may be too
• Configuration drift: DR environments that aren't regularly tested diverge from production — when you need them, they don't work
• Supply chain attacks: If the compromised component is in your base image or CI pipeline, your DR deployment reproduces the vulnerability

IMI breaks these assumptions by maintaining genuine isolation — separate trust roots, separate supply chains, separate administrative access.

Designing Your Isolated Minimum Infrastructure

Step 1: Identify Critical Services (It Depends on Your Business)

There is no universal template. What counts as "critical" varies enormously:

The exercise of identifying these services is itself valuable. Most organisations discover they don't actually know what's critical until they're forced to decide during an incident — which is the worst possible time to find out.

Step 2: Map Dependencies Ruthlessly

For each critical service, trace every dependency:

• What DNS does it need? Can it function with a local hosts file or dedicated DNS?
• What identity provider authenticates users? Is there a fallback?
• What databases does it read from? Can it operate on a snapshot?
• What network paths are required? Can they be established over a VPN or dedicated link?
• What secrets/certificates does it need? Are they stored independently?

Every dependency you discover is a potential failure point. The goal is to eliminate or isolate each one.

Step 3: Build the Isolation Boundary

True isolation means separate trust roots:

• Separate administrative credentials: IMI admin accounts must not exist in your primary identity system
• Separate network infrastructure: Dedicated switches, firewalls, or physically separate cloud accounts with no peering
• Separate supply chain: Container images, OS packages, and configuration stored in isolated registries
• Immutable storage: Backups on WORM (Write Once Read Many) storage that cannot be modified or deleted, even by administrators
• Out-of-band management: Console access that doesn't traverse the corporate network (IPMI, serial, or dedicated management network)

Step 4: Test It — Really Test It

An untested IMI is just documentation. Regular exercises must validate:

• Can the team actually access the IMI without any primary infrastructure?
• Can critical services start from cold within the target Recovery Time Objective?
• Is the data in immutable backups actually usable and current enough?
• Do the team know the runbooks, or do they depend on systems that might be down?

Schedule tabletop exercises quarterly and full failover tests at least annually. Document every gap found and fix it before the next test.

Compliance Alignment

IMI isn't just good practice — regulators increasingly require it:

• NIS2 Directive (EU): Article 21 requires "business continuity and crisis management" measures, including backup management and disaster recovery
• DORA (EU Financial): Requires ICT risk management frameworks with specific resilience testing obligations
• ISO 27001:2022: Annex A control A.5.30 (ICT readiness for business continuity) explicitly covers this
• NIST CSF: The Recover function maps directly to IMI capabilities

Common Mistakes

• Building it once and forgetting it: IMI must evolve as your critical services change
• Making it too complex: The point is minimum — resist the urge to replicate everything
• Sharing credentials with primary infrastructure: Defeats the purpose of isolation
• Not involving business stakeholders: IT alone cannot determine what's critical to the business
• Treating it as a project instead of a capability: IMI is an ongoing operational discipline, not a one-time deliverable

Getting Started

You don't need to build everything at once. Start with:

1. Week 1: Workshop with business leaders to identify the top 5 critical services
2. Week 2-3: Dependency mapping for those 5 services
3. Week 4: Design the isolation boundary and identify gaps
4. Month 2-3: Build and validate the IMI for the highest-priority service
5. Ongoing: Expand coverage, test regularly, maintain documentation

The first exercise will reveal how much you don't know about your own infrastructure. That's the point.