About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Put recovered workloads on a network with no access to production services. Stage backup data through a controlled recovery service or media transfer; any necessary infrastructure exception must be narrowly authorised and kept separate from the recovered workloads. Give the recovered system names and addresses that exist only on that network. Then run the functional check there.
That arrangement supports one claim: this backup can be brought up and can perform the test's function without a path into the live service. It does not support a second claim: users, partners, or upstream systems on the production network will reach it, or it will reach them. The second claim is a connectivity test. Mixing the two claims is how a safe drill gets described as a cutover.
No network was built for this article. The patterns below are design choices. They are not switch configuration and they were not lab-tested.
Why it matters
The controls discussed here apply where your organisation has selected or is required to meet them. They are not a blanket legal requirement for every business.
NIST SP 800-84 is plain about tests that touch real systems. Operational systems and networks need to be protected so the test does not damage them. The organisation's core function should not be disrupted to the point where it can no longer provide its services. The test director watches for that, and the test documents include a way to stop early. A recovered server that still believes it is the production server, placed on a network that can reach production, is exactly the situation that rule is trying to prevent. It can answer production names, collect production traffic, or send production traffic, while the real server is also alive. The drill has become two copies of a service that was supposed to have one.
SP 800-34 pulls in the other direction, and the tension is the point of the design. It says testing should be conducted as close to an operating environment as possible, and that a test validates operability in an operational environment. A network with no path to production is not the production network. A test there is closer to what SP 800-84 calls a functional exercise in a simulated operational environment, and closer to what SP 800-53 CP-4's discussion calls a parallel simulation, than it is to a full-interrupt test. CP-4 lists both parallel and full-interrupt simulations as methods. They are not the same method. Isolation is how you keep a parallel test parallel.
There is a second, narrower separation already required for backup infrastructure. Information Security Manual control ISM-2152, added in the September 2026 manual, says backup infrastructure, including backup servers, repositories and management consoles, is segregated from production environments and uses a separate authentication mechanism for administrative access. That control is about the systems that hold and manage backups. It is not, by itself, a design for the network where a restored application runs. You can satisfy ISM-2152 and still restore a virtual machine onto the production subnet. The restore network is an additional choice, made so the test obeys SP 800-84's protection rule.
ASD Essentials action PRO-18, published 15 October 2026, says systems are isolated in network zones according to criticality and trust, and that inbound and outbound access is restricted to explicitly approved paths. A restore zone is a zone with a trust level of "unproved copy." PRO-18 does not name restore tests. Using it as the reason to deny a default route from that zone into production is an editorial application of the action's own words: approved paths only. The path you may still need is the path that reads the backup. That path is explicit, limited, and recorded. A general route is not.
PRO-10 still asks the test to be capable of speaking to recovery time and recovery point. Isolation does not remove the clock. It changes which path the clock measures.
How it works
What "no path" has to cover
A VLAN name is not isolation. Isolation here means enforced separation from production workloads, including routes, bridging, management access and shared services. It can be physical or logical; any approved infrastructure exceptions must be explicit. For a restore test, decide each of the following and write the answer in the test plan. These are design questions. This article does not give device commands.
- Can the recovered systems reach production addresses at all, by any route, including a default route someone left in place?
- Can production reach the recovered systems, including by a management network that is "just for administrators"?
- Do the recovered systems use production addresses? If addresses overlap, an unintended connection can create address conflicts or reach the wrong system; routing, bridging and translation must all be considered. Prefer addresses that are valid only inside the test network.
- Which name service do they use? A recovered system pointed at production DNS will learn production destinations and may register its own name back into production. Point it at a name service that exists only for the test, or at static test names, unless the thing you are testing is DNS itself.
- Which directory or identity service do they use? Joining a recovered domain member to the live directory, or letting it authenticate against production, couples the test to production even when the application subnet looks separate.
- Which time source do they use? A guest that cannot reach an allowed time source may fail certificate checks and look "broken" for a reason outside the backup. Allow a time source on purpose, inside the test network or as a named exception, and record it. Do not discover it by opening a path to every production host.
The backup read is the usual exception. CP-9(1)'s discussion of a real retrieval starts at the alternate or backup site, not at a convenience copy on the production array. The restore network needs a path to that backup store, or the restore has to be staged onto media that is carried in. SP 800-34 and CP-9(5) both treat physical transfer as a real method. If network retrieval is required, restrict it to a dedicated recovery service using narrowly scoped permissions. Do not give an untrusted recovered guest repository credentials or direct backup-management access. Verify that permitted paths cannot bridge back into production, and retain the original backup unchanged. ISM-2152's separate authentication for backup administration is relevant here: the credentials that can administer the repository should not be the credentials the recovered application uses to talk to its users. The test plan names which account reads the backup.
What you can honestly claim afterwards
After a clean isolated run you can claim:
- The named backup generation was read from the named store.
- The systems in scope reached the functional criterion without a route to production.
- The elapsed time is the time for this path, including whatever staging the isolation forced.
- Name resolution, identity, and addresses were the test copies you listed, or were explicit exceptions.
You cannot claim:
- Production clients can reach the service. They were not asked to.
- Production upstream systems accept the recovered system. They were not on the path.
- A cutover would work. A cutover removes isolation on purpose. SP 800-34's full-scale exercise for high-impact systems includes failover and reconstitution in a way that familiarises people with the alternate facility. That is a different event, with SP 800-84's early-termination rule in the documents the test director is holding.
- The production network equipment is correctly configured for this service. You did not use it.
CP-4(2) is the control enhancement for testing the contingency plan at the alternate processing site, to familiarise people with the facility and to evaluate whether the site can support contingency operations. An isolated restore network can sit inside that alternate site. Passing the isolated test evaluates the restore and the local function. Evaluating the site's ability to connect onward to whoever must be served after a disaster is a further test, and it should be named as further.
Parallel versus interrupt
CP-4's discussion distinguishes simulations that are parallel from simulations that are full interrupt. A parallel test builds and checks the recovered system while production continues. Isolation is what keeps "parallel" from becoming an accidental interrupt. A full interrupt stops the production service and moves the work. SP 800-84 says the core service must remain protected. Any planned interruption needs separate business authorisation and a controlled recovery path; reversibility does not create an exception to that protection rule. For most scheduled assurance work, the isolated parallel test is the one that can be repeated. The interrupt test is rare, authorised, and aborted by a written rule.
Record which of the two you ran in the first line of the after-action report. SP 800-34 expects that report. A later reader who sees "recovery tested" will assume the stronger meaning if you do not deny it.
Evidence that the isolation held
A successful functional check does not prove isolation. The function can pass on a leaky network. During the test, record evidence that the path was absent. Because this article was not lab-validated, it does not prescribe a packet capture or a firewall log format. Record the enforced boundary configuration and validate representative allowed and denied paths in both directions using authorised, nondisruptive checks. Include IPv4 and IPv6, routing and bridging, DNS, identity, outbound messages, management interfaces and dual-connected hosts where present. A failed ping or one unreachable address is not proof that other protocols or destinations are blocked. Save the scope, observations and time, and retain the configuration evidence. If either check fails, SP 800-84's instruction is to stop before the core service is harmed, not to finish the functional script and discuss the route next week.
Also record any exception you opened: the backup-read path, the time source, a jump host. An exception that was used is part of the design. An exception you find only because traffic flowed is a failed isolation, even if the application test passed.
What to choose and why
Choose isolation for every restore whose purpose is to learn whether a copy opens and a function runs, whenever production is still serving that function. That is the normal case for CP-9(2) samples and for functional exercises. SP 800-34's moderate-impact exercise is a recovery component such as a restore from backup, not an instruction to seize the production IP address.
Choose production addresses only inside the isolated network, and only if something about the application will not start without them. If you do, the "no path" checks become mandatory rather than best efforts. An unintended connection may expose duplicate addresses or identities; stop and investigate it before continuing.
Choose a test name service and a test identity source for the same reason. Borrowing production DNS or the production directory is an explicit assumption, as in a group restore that depends on them. Write the assumption. Do not let a virtual machine's original settings silently keep the production resolvers. The original settings are what the backup correctly preserved. The test has to override them on purpose or accept the coupling.
Choose to leave isolation only when the question has changed to connectivity or cutover. Do that in a separate test with its own criterion, its own authority, and the early-termination text SP 800-84 wants in the test guide and again in the test plan. Do not remove isolation at the end of a successful functional test "just to see." That is a second test, started without a plan.
If the recovery site is the alternate processing site in the contingency plan, use CP-4(2)'s purpose as the agenda: people learn the facility, and you evaluate whether the facility can support the operation. An isolated network that only works because an engineer brought a laptop full of exceptions has not evaluated the site. It has evaluated the laptop.
Risks and limits
The first risk is paper isolation. A VLAN label alone does not prove separation. Trunks and shared infrastructure can carry properly isolated networks, but routing, bridging or permissive rules can also defeat that isolation. Boundary configuration and scoped reachability evidence must agree. A diagram is the intention.
The second risk is isolation so complete that the test cannot see the backup. Someone then copies the backup onto the production datastore "temporarily," and the retrieval CP-9(1) describes never happens. Keep the one path to the repository, or move media. Record which you did. A restore from a copy that never left production storage does not speak for the offsite copy.
The third risk is production identity leaking through settings the backup faithfully restored. That is the backup working. The test procedure has to expect it. This article does not provide the commands to change an address or a resolver. It says the test is not isolated until those settings have been confirmed against the test plan.
The fourth risk is claiming the production recovery time from an isolated drill. The isolated path can be slower because of staging, or faster because it avoided production congestion. PRO-10's recovery time has to be the time on the path you will use. An isolated timing is valid for the isolated path. Say so in the same sentence as the number.
The fifth risk is treating PRO-18 or ISM-2152 as if they were a finished restore-network design. PRO-18 is a zoning and approved-path action. ISM-2152 is segregation and separate authentication for backup infrastructure. Both support the direction of this article. Neither specifies a restore test topology, a product, or a certification. SP 800-84 remains the text that tells you not to damage operational systems while you test.
SP 800-34 still wants tests as close to the real environment as you can safely get. Isolation is a retreat from closeness, taken to satisfy the safety rule. After the isolated test is reliable, the plan should say which closer test, if any, you will run, under what authority, and how it stops. A programme that never leaves the island has not done the full-interrupt or the production-connectivity question. A programme that omits isolation needs other verified safeguards against accidental production interaction.
This article was written with AI assistance. It is source research only. The factual claims have been independently checked against the cited sources. It contains no switch, firewall, or hypervisor commands, and none were run.
Sources
- NIST SP 800-84, September 2006, https://doi.org/10.6028/NIST.SP.800-84 — section 6 on protecting operational systems and networks, avoiding disruption of the core service, and early termination. Section 2 on functional exercises as simulated operations. Opened 11 November 2026.
- NIST SP 800-34 Rev. 1, 11 November 2010, https://doi.org/10.6028/NIST.SP.800-34r1 — section 3.5 on testing close to the operating environment, Table 3-6 on full-scale exercises, and the after-action report. Opened 11 November 2026.
- NIST SP 800-53 Rev. 5, https://doi.org/10.6028/NIST.SP.800-53r5 — CP-4 discussion (parallel or full interrupt), CP-4(2), CP-9(1), CP-9(5). Opened 11 November 2026.
- ASD, Information security manual, September 2026, https://www.cyber.gov.au/ism/2026-09 — ISM-2152, updated Sep-26. Opened 11 November 2026.
- ASD, Essentials for enterprise IT, 15 October 2026, https://www.cyber.gov.au/publication/essentials-for-enterprise-it — PRO-18 and PRO-10. Opened 11 November 2026.
This article was originally published on .