Domain 7 is the daily running of a security program: monitoring, incident response, patch and change management, backups, disaster recovery and business continuity, and the physical operations that keep systems available.
Case Study: The "Patch Tuesday" Fleet Outage
Global ATM Corp runs 5,000 ATMs. On the second Tuesday of the month its IT operations team approved a critical Windows security patch. To reach compliance quickly, the lead engineer pushed it to the entire fleet at once through SCCM, at 2:00 PM.
The patch conflicted with the cash dispenser driver used on 80% of the fleet. Within thirty minutes 4,000 ATMs had crashed to a blue screen. The team triggered an automated uninstall, but 4,000 machines rebooting and checking in at once saturated the network, and the rollback command never reached them. Technicians drove to each ATM, booted it into safe mode and removed the patch by hand. The network was down for eighteen hours.
The white paper puts patching at the top of its logical controls, rated High against malware and exploit vectors, and it is equally clear about the other side of the trade: an ATM is a multi-vendor stack of operating system, application, XFS middleware and peripheral drivers, and a weakness in any one link affects the whole chain. Service availability is one of its named impact categories. A patch that takes 80% of the fleet offline is an availability incident with a security label on it.
One organization each, three to six questions apiece in the printed examination. Nothing here gives an answer away — the scenario is what the question hands you before it asks.
Global ATM Corp operates 5,000 ATMs. Its service desk logs a report from a branch: an ATM in Toledo displayed a command prompt for a few seconds during a maintenance visit. The fleet runs a standard Windows build with anti-malware and a monthly patch cycle. Each machine writes its own event log locally and keeps thirty days of it. There is no rule about which programs may run. The maintenance vendor's technician says he ran a diagnostic tool he downloaded that morning. By the time an analyst calls back, the machine has been rebooted twice.
Global ATM Corp · 5,000 ATMs
Global ATM Corp has a written disaster recovery plan for the transaction switch behind its 5,000 ATMs, and has run one tabletop against it. The plan names a recovery team of eleven people across three time zones, lists a call tree, and assumes the switch can be brought up at the Columbus site within four hours. Nobody has yet performed any of the steps. The board has approved two exercises this year and will not accept an outage of production. The operations director has asked what the two exercises should be and what evidence each will produce.
Global ATM Corp · 5,000 ATMs
A security patch put every one of Global ATM Corp's 5,000 machines into a reboot loop, and customers could not withdraw cash for eighteen hours. No card data was exposed and no transaction record was altered. The test lab cannot replicate every dispenser hardware variant in the field, and the vendor certifies patches only against a reference build. Business impact analysis sets a four-hour recovery time objective and a twenty-four-hour maximum tolerable downtime for the fleet. An engineer has found a registry fix that would stop the loop, but the change board does not meet for three days.
Global ATM Corp · 5,000 machines
Global ATM Corp's change board is reviewing four backout plans submitted with a proposed dispenser firmware change, and only one of them is a plan at all. An outage review has separately noted that the lead engineer who wrote a deployment change request also approved it in the tracking system and then executed the deployment. A fleet audit found machines running inconsistent settings: some hardened, others with services re-enabled by field technicians, and no record of what any machine is supposed to look like. Operations also want to compare the reliability of two dispenser models over the coming year.
Global ATM Corp · change and configuration management
Change management does the work here. Every change to production carries a tested backout plan, and "tested" means run in a lab that holds every hardware and driver variant in the fleet, including the dispenser population that failed. The vendor's certification of the patch against the ATM application and driver stack is a gate, not a courtesy.
Deploy in rings: lab, then a 1% canary, then a 10% pilot, then the rest, with a soak period long enough to cover a business cycle and a halt trigger in monitoring (a failure rate, not a feeling). Windows are chosen off-peak; 2:00 PM on a weekday is peak. Throttle the deployment so the network can carry a rollback if it comes to that, and keep the recovery runbook current so a site visit takes minutes instead of an afternoon.
Then the continuity side: what is the maximum tolerable downtime for the ATM channel, and what did customers use during the eighteen hours? If the answer is "the branches", the business continuity plan should say so, and the branches should have known.
Eighteen hours of fleet downtime, a technician visit to 4,000 sites, and a change advisory board that now refuses any fleet-wide push without a pilot ring and a demonstrated rollback. The patch went out again, ring by ring, without incident.
Scenarios like this test the change management process end to end, patch management as a lifecycle, configuration baselines, availability as a pillar of the CIA triad, and business continuity terms: maximum tolerable downtime, recovery time objective, and how an eighteen-hour outage measures against them. Expect a question on why the rollback failed and which control would have prevented it.
The operator in this scenario is a composite. The controls are documented in: