The 6 CompTIA Troubleshooting Steps, in Order (and How the Exam Tests Them)

CompTIA’s best-practice troubleshooting methodology has six steps, and the exam expects you to know them in this exact order: (1) identify the problem, (2) establish a theory of probable cause, (3) test the theory to determine the cause, (4) establish a plan of action and implement the solution, (5) verify full system functionality and implement preventive measures, and (6) document findings, actions, and outcomes. The sequence matters because each step feeds the next — you cannot test a theory you have not formed, and you should not implement a fix you have not planned.

Hardware and Network Troubleshooting is the heaviest domain on the 220-1201 exam (the full 220-1201 study guide breaks down the domain weights), and this methodology is its backbone. Every troubleshooting objective in that domain — displays, printers, storage, power, connectivity — is written with the assumption that you approach the symptom methodically rather than swapping parts at random.

Step 1: Identify the problem

Identification is information gathering, and it has more moving parts than any other step:

• Question the user. Ask what happened, when it started, and what “broken” actually means. A report of “the computer keeps dying” could be a hard shutdown, a blue screen, or a sleep-mode setting.
• Identify symptoms yourself. Reproduce the failure if you can. A workstation that shuts off only under sustained load points somewhere very different (thermal or power delivery) than one that dies at idle.
• Determine if anything has changed. New drivers, a new power supply, a moved desk, a BIOS update — recent changes are the single best lead a technician gets. A monitor that starts flickering right after a graphics driver update is the textbook example.
• Inquire about environmental or infrastructure changes. Construction on the floor, a new space heater on the same circuit, HVAC failures — the cause is not always inside the case.
• Back up before making changes. If the fix could touch data — reseating drives, flashing firmware, reinstalling an operating system — perform backups first, during this step, not after something goes wrong.

That backup detail is a favorite exam distractor. Backing up belongs to step 1, before any modification, because the whole point is protecting the user from your troubleshooting.

Step 2: Establish a theory of probable cause

With symptoms in hand, form a working hypothesis. CompTIA attaches two sub-instructions here:

• Question the obvious. Check that the cable is seated, the outlet is live, the monitor input is correct. Simple causes are common causes.
• Conduct research based on symptoms. If the obvious checks pass, consult internal documentation, vendor knowledge bases, or error-code references to narrow the list of suspects.

For an under-load shutdown, a reasonable first theory might be CPU overheating triggering thermal protection — it is common, it matches the load-dependent pattern, and it is cheap to check.

Step 3: Test the theory to determine the cause

Now confirm or kill the hypothesis with evidence: watch temperatures during a stress test, listen for fan spin-up, inspect the heatsink mounting. Two outcomes are possible:

• Theory confirmed — move on and determine the next steps to resolve the problem.
• Theory not confirmed — establish a new theory and test again, or escalate to someone with more expertise or authority. Escalation lives in step 3 on the exam; if a question asks where a technician hands off a problem they cannot crack, this is the answer.

Notice what has not happened yet: nothing has been fixed. Testing a theory is diagnosis, not repair.

Step 4: Establish a plan of action and implement the solution

Only after the cause is confirmed do you plan the repair and carry it out. Planning matters because fixes have consequences: replacing a motherboard means downtime, reflowing thermal paste means opening a warrantied machine, and a firmware update can require a maintenance window. CompTIA’s sub-bullet here is to refer to vendor instructions for guidance — service manuals and vendor procedures exist so the fix does not create a second problem.

Step 5: Verify full system functionality and implement preventive measures

A fix is not done when the symptom disappears; it is done when the whole system works. Rerun the workload that exposed the fault, confirm nothing else regressed, and have the user validate normal operation. Then, if applicable, add prevention: clean dust filters on a schedule, enable temperature alerts, move the equipment off the overloaded circuit. Preventive measures are what keep the ticket from reopening in a month.

Step 6: Document findings, actions, and outcomes

Record what the symptom was, what caused it, what you did, and how it ended — in the ticketing system, not in your head. Documentation turns one technician’s afternoon into the whole team’s knowledge base, and it is why the next under-load shutdown gets solved in ten minutes. This step also includes reviewing lessons learned with the team where the organization does that formally.

The six steps at a glance

#	Step	Key actions inside the step
1	Identify the problem	Question users, reproduce symptoms, check recent and environmental changes, back up data
2	Establish a theory of probable cause	Question the obvious; research symptoms
3	Test the theory	Confirm the cause — or form a new theory or escalate
4	Plan of action and implement	Plan the repair; follow vendor instructions; apply the fix
5	Verify full functionality	Retest the whole system; add preventive measures
6	Document	Findings, actions, outcomes; lessons learned

One memory hook that works for many candidates: Identify, Establish, Test, Plan, Verify, Document — “IET-PVD.” Whatever mnemonic you use, drill the order with 220-1201 practice questions until it is automatic, because the exam tests the sequence directly.

How the 220-1201 exam tests this

• Ordering PBQs. A performance-based question (PBQ — an interactive item rather than multiple choice) presents the six steps scrambled and asks you to arrange them first to last, often wrapped in a hardware scenario such as a machine that powers off under load. The scenario is flavor; the answer is the fixed sequence.
• “What should the technician do NEXT?” A stem describes a technician mid-process — say, they have just confirmed a theory — and asks for the next action (here: establish a plan of action). Map the story to a step number, then answer with the following step.
• Misplaced-action traps. Distractors put a real action in the wrong step: backing up after implementing a fix, or escalating during identification. Know which sub-actions live inside which step.
• Applied-domain crossovers. Questions about printer jams or no-signal monitors often hide a methodology test: the “correct” first move is usually the cheapest check that gathers information, not the most decisive repair.

Quick reference

• Order: identify → establish theory → test theory → plan and implement → verify and prevent → document.
• Back up user data during step 1, before any change is made.
• “Question the obvious” and symptom research belong to step 2.
• Escalation happens in step 3, when a theory cannot be confirmed.
• Vendor instructions guide the implementation in step 4.
• Verification means full system functionality, not just the original symptom — and it includes preventive measures.
• Documentation (step 6) covers findings, actions, and outcomes, and it always comes last.