Malware Removal and System Restore: The Right Order of Operations

CompTIA’s malware removal procedure is a fixed seven-step sequence: investigate and verify symptoms, quarantine the infected system, disable System Restore, remediate (update anti-malware and scan), schedule scans and run updates, re-enable System Restore and create a new restore point, and educate the end user. System Restore appears twice on purpose — you disable it before cleaning so infected restore points can’t resurrect the malware, and you re-enable it after cleaning so the now-healthy machine has a fresh rollback point. Questions on the 220-1202 exam almost always hinge on that ordering — drill it with practice questions until the sequence reorders itself.

The seven steps, and why the order matters

1. Investigate and verify malware symptoms. Confirm you’re actually dealing with malware — pop-ups, redirects, unexplained network traffic, disabled security tools — before taking disruptive action.
2. Quarantine the infected system. Disconnect it from the network (and remove shared drives or USB media) so the infection can’t spread or phone home while you work.
3. Disable System Restore in Windows. Covered in depth below.
4. Remediate the infected system. Update the anti-malware engine and its definitions first, then scan and remove. Stubborn infections may need the scan run from Safe Mode or the Windows Recovery Environment (WinRE), where the malware isn’t running and can’t defend itself.
5. Schedule scans and run updates. Turn on scheduled anti-malware scans and bring Windows and applications fully up to date so the same hole isn’t reopened. If the infection has broken the update mechanism itself, see troubleshooting Windows Update failures.
6. Enable System Restore and create a restore point. Covered in depth below.
7. Educate the end user. Explain what let the malware in — the attachment, the fake download, the pop-up — because the user is the control most likely to prevent a repeat.

The sequence is not a suggestion. Verifying before quarantining avoids disrupting a healthy machine; quarantining before remediating contains spread; updating definitions before scanning is what makes the scan worth running; and the System Restore steps bracket the cleanup for reasons explained next. Exam items that scramble these steps are testing whether you know what each step protects.

Why System Restore gets disabled before cleanup

System Restore is the Windows Home-friendly feature (Control Panel > System > System Protection, or search “Create a restore point”) that snapshots system files, the registry, and installed-program state as restore points, letting you roll the system configuration back to an earlier date. Note what it protects: system state — not personal files, and not a full disk image.

That rollback power is exactly the problem during an infection. Restore points created while the machine was infected can contain copies of the malware’s files and registry entries. If you clean the machine but leave those snapshots intact, two bad outcomes are possible: a later rollback quietly reinstalls the infection, or the malware’s copies simply persist inside the protected snapshot storage where cleanup tools may not reach. Disabling System Restore deletes the existing restore points, guaranteeing no infected snapshot survives the remediation.

So the pre-cleanup logic is: quarantine first, then throw away the contaminated snapshots, then clean.

Why it comes back on afterward — with a fresh restore point

Once the system is verified clean and fully updated, step 6 restores the safety net: re-enable System Protection and manually create a new restore point. This snapshot captures the machine in a known-good state, so the next problem — a failed driver update, a botched application install, a bad Windows patch — can be rolled back in minutes instead of becoming a rebuild.

Skipping this step has a concrete, delayed cost, and the exam likes to make you trace it. If a technician disables System Restore, remediates, and returns the computer without re-enabling protection and creating a point, the machine runs with no restore points at all. Weeks later, when an unrelated driver update fails, the user has no earlier configuration to roll back to — the recovery option that would have fixed it in one click simply isn’t there. Nothing about the malware returns; what’s lost is resilience.

The same logic applies after a reimage. A freshly reimaged Windows machine is clean by definition, but imaging doesn’t automatically leave System Protection enabled with a current snapshot. Before handing the computer back, enable System Restore and create a restore point so the clean baseline is captured. “It was just reimaged” is never a reason to skip the safety net — it’s the ideal moment to set it.

	Before remediation (step 3)	After remediation (step 6)
Action	Disable System Restore	Re-enable System Restore
Restore points	Existing points deleted	New known-good point created manually
Threat addressed	Malware hiding in old snapshots reinfecting the system	Future failures with no rollback available
System assumed to be	Infected	Verified clean and updated

Where the other tools fit

System Restore is one recovery tool among several, and questions sometimes test the boundaries. A restore point rolls back system configuration but does not recover deleted documents — that’s what File History or other backups are for. A full reimage or Reset this PC is the escalation path when remediation fails or trust in the system can’t be reestablished; it replaces the OS wholesale rather than rolling it back. And prevention beats all of it: the scheduled scans and updates from step 5, plus the workstation defenses described in Software Firewalls and Malware Defense on the Workstation, are what keep you out of this procedure in the first place. Remediation also isn’t finished at the OS level alone — clear the browser’s cache, cookies, and site data as described in Clearing Browser Cache, Cookies, and Site Data so malicious scripts and hijacked sessions don’t outlive the scan.

Documentation deserves a mention as the unwritten companion step: record the symptoms, what the scanner found, and what you changed. On a repeat infection, that record turns guessing into pattern recognition, and it feeds the step-7 conversation with the user.

How the 220-1202 exam tests this

• An ordering question: given several remediation actions, pick what comes next, or identify which two steps of the documented procedure involve System Restore specifically — disabling it before cleanup and re-enabling it with a new restore point after.
• A “cleanup is finished, now what?” scenario asking what to do about System Restore once remediation is complete — re-enable it and create a fresh restore point, not leave it off “for safety.”
• A consequence-tracing scenario: the technician forgot step 6, and weeks later an unrelated failure (commonly a bad driver update) can’t be rolled back because no restore points exist.
• A reimaged-machine scenario checking whether you know a rebuilt system still needs System Protection turned on and a baseline restore point created before handoff.

The seven-step procedure anchors the Software Troubleshooting domain — see the full 220-1202 study guide for how that domain fits into the rest of the exam.

Quick reference

• The seven steps: verify symptoms → quarantine → disable System Restore → remediate (update, then scan) → schedule scans/updates → re-enable System Restore + new restore point → educate the user.
• Disabling System Restore deletes existing restore points so infected snapshots can’t reinfect the machine.
• Update anti-malware definitions before scanning; use Safe Mode or WinRE for stubborn infections.
• Quarantine means off the network and away from shared storage — containment before cleanup.
• After a verified clean, re-enable System Protection and manually create a known-good restore point.
• Forgetting the re-enable step leaves zero rollback capability for future failures like bad driver updates.
• Reimaged machines need System Restore enabled and a baseline point created before returning them to the user.
• Restore points roll back system state only — they don’t recover personal files and don’t substitute for backups.
• Step 7 is real work: tell the user how the infection happened and how to avoid a repeat.