⚡ The 6 Steps
1. Identify the problem → 2. Establish a theory → 3. Test the theory → 4. Establish a plan of action → 5. Implement the solution → 6. Document findings. This exact sequence appears on every CompTIA certification exam — A+, Network+, and Security+ all test whether you can identify which step is being described in a scenario.
Why CompTIA Has a Standard Methodology
In IT support, the difference between a good technician and a great one is rarely technical knowledge — it's systematic thinking. Without a methodology, technicians guess randomly, make changes without understanding them, and can't explain what they did or why it worked. CompTIA's 6-step model gives every exam candidate (and every IT professional) a repeatable framework that works on hardware, software, network, and security problems alike.
The methodology is deliberately general so it applies to everything from "a user's computer won't start" to "a network segment is unreachable" to "a security incident is in progress." The steps don't change — only the tools and techniques used within each step.
The 6 Steps — In Detail
1
Identify the Problem
Gather information before touching anything. Interview the user — ask what changed, when it started, whether it's happened before. Check error messages, event logs, and system information. Identify symptoms vs. the actual problem (a symptom is "screen is blank"; the problem might be a failed GPU, a loose cable, a dead power supply, or a software crash).
Key actions: Question the user (open-ended and closed questions), review logs, duplicate the issue if possible, identify affected systems, check for recent changes — software installs, updates, hardware swaps, configuration changes.
2
Establish a Theory of Probable Cause
Based on what you've gathered, form a hypothesis. Start with the simplest and most likely cause — this is Occam's Razor in action. If a monitor is blank, check if it's plugged in before diagnosing the GPU. CompTIA calls this "question the obvious."
Key actions: Research the symptoms (knowledge base, documentation, internet). Consider multiple possible causes and rank by likelihood. Start with the most probable, not the most interesting. For network problems — work from Layer 1 up the OSI model.
3
Test the Theory to Determine the Cause
Test your hypothesis. Change one variable at a time. If your theory is confirmed — move to step 4. If it's wrong — go back to step 2 and form a new theory. Never make multiple changes at once; you won't know which one fixed it.
Key actions: Swap known-good components (cable, RAM, power supply). Run diagnostics. Check configurations against known-good baseline. If the theory is disproved, return to step 2. If you cannot determine the cause yourself — escalate to a higher level of support.
4
Establish a Plan of Action to Resolve the Problem and Identify Potential Effects
Before implementing anything, plan the fix. Consider side effects and risks — will your solution affect other systems? Do you need a change management approval? Do you need to back up data first? Is there a maintenance window required?
Key actions: Check change management procedures. Identify potential impacts (downtime, data loss, service disruption). Back up configurations and data. Schedule during a maintenance window if needed. Communicate with affected users.
5
Implement the Solution or Escalate as Necessary
Implement the fix you planned. If the solution is outside your technical scope, authority, or access — escalate. After implementing, verify the fix resolved the original problem and didn't introduce new ones. Test all affected functionality.
Key actions: Apply the fix. Verify the original issue is resolved. Test related functionality (fixing one thing can break another). If the fix didn't work — return to step 2. Escalate if the problem is beyond your level.
6
Verify Full System Functionality and Implement Preventive Measures
Confirm the problem is fully resolved — not just for the original symptom but for the whole system. Implement preventive measures so it doesn't happen again (update policies, patch the system, add monitoring). Document everything.
Key actions: Verify with the user that the problem is resolved. Test related systems. Implement preventive measures (patch management, configuration changes, user training). Document: what the problem was, what caused it, what you did to fix it, and how to prevent recurrence.
⚡ Exam tip — step order matters
CompTIA exam questions often describe a scenario mid-troubleshooting and ask "what should the technician do next?" The answer depends entirely on which step they're on. If they've identified the problem and formed a theory — the next step is test the theory, not implement a fix. If the theory was wrong — go back to step 2, not step 1.
The most common wrong answers on these questions involve skipping steps (going straight from step 1 to step 5) or going backwards incorrectly. Also remember: documentation (step 6) is always last — the exam will try to trick you into picking "document the findings" before the problem is actually solved.
Where Each Step Appears on the Exam
| Step | A+ Scenario Example | Network+ Scenario Example | Security+ Scenario Example |
|---|
| 1 — Identify | User reports "computer is slow" — ask when it started, what changed | Users report intermittent connectivity — check logs, identify affected hosts | Alert fired — gather IOCs, identify affected systems, preserve evidence |
| 2 — Theory | Slow PC — probable cause: malware, failing HDD, insufficient RAM | Intermittent connectivity — probable cause: duplex mismatch, bad cable, overloaded switch | Suspicious traffic — probable cause: malware C2, compromised credential, insider threat |
| 3 — Test | Run Task Manager to check resource usage; run malware scan | Check interface stats for errors; swap cable; check switch port config | Isolate affected host; run EDR scan; check authentication logs |
| 4 — Plan | Schedule after hours reimaging; back up user data first | Plan maintenance window to reconfigure switch port | Draft containment plan; identify scope before eradicating |
| 5 — Implement | Reimage PC, restore data, reinstall software | Reconfigure port speed/duplex; replace cable | Isolate system, remove malware, patch vulnerability, restore from backup |
| 6 — Document | Log ticket: symptoms, cause (malware), fix (reimage), prevention (AV policy) | Update network documentation; add monitoring alert for interface errors | Write incident report; update IR playbook; conduct lessons-learned review |
The OSI Model as a Troubleshooting Framework
For network problems specifically, CompTIA recommends working bottom-up from Layer 1 when establishing your theory of probable cause (step 2). There's no point diagnosing a DNS misconfiguration (Layer 7) if a cable is unplugged (Layer 1).
Network Troubleshooting — Bottom-Up OSI Approach
Layer 1 — Physical: Is the cable connected? Are the link lights on the NIC and switch lit? Try a different cable or port.
Layer 2 — Data Link: Is the NIC getting a MAC assignment? Is the switch port in the right VLAN? Check for duplex/speed mismatches.
Layer 3 — Network: Does the host have a valid IP address (not 169.254.x.x)? Can it ping the default gateway? Check routing table.
Layer 4 — Transport: Is the correct port open? Is a firewall blocking the connection? Run netstat/ss to check listening ports.
Layer 7 — Application: Is the service running? Is the DNS name resolving? Is the application configured correctly?
Change Management and the Troubleshooting Process
Step 4 (establish a plan) connects directly to change management — a critical concept on both Network+ and Security+. In enterprise environments, you cannot simply implement changes without going through a formal approval process. The troubleshooting methodology acknowledges this: if your fix requires a configuration change to a production system, you need to follow change management procedures before step 5.
Key change management elements tested on Network+ and Security+: change request submission, approval by a change advisory board (CAB), scheduling during a maintenance window, rollback plan in case the change causes new problems, and post-implementation review.
Documentation — Why Step 6 Matters Beyond the Exam
Documentation is the step most commonly skipped in real IT environments and the step most often tested on CompTIA exams. Good documentation serves three purposes: it helps the next technician who encounters the same issue, it creates a paper trail for auditing and compliance, and it builds a knowledge base that speeds up future troubleshooting.
What good documentation includes: date and time of the issue, who reported it, the symptoms observed, the cause identified, every step taken to diagnose and fix it, the final resolution, preventive measures applied, and time to resolution.
Exam Scenarios
💬 "A technician has confirmed the theory of probable cause. What should they do next?" → Step 4 — Establish a plan of action. Testing confirms the theory; planning precedes implementation.
💬 "After implementing a fix, the technician notices a new problem appeared. What step should they return to?" → Step 2 — Establish a new theory. The original fix either didn't address the root cause or introduced a new issue.
💬 "A user reports their monitor is blank. The technician's first action should be:" → Step 1 — Identify the problem. Ask when it started, check cables, look for error messages before forming any theory.
💬 "A technician fixes a network connectivity issue but doesn't write it up. Which step did they skip?" → Step 6 — Document findings, full system functionality verification, and preventive measures.
💬 "A technician suspects a bad RAM module. They replace it AND reinstall Windows at the same time. What troubleshooting principle did they violate?" → Change one variable at a time. Making multiple changes simultaneously means you cannot determine which change resolved the problem.
💬 "An issue is beyond the technician's authority to fix. According to the troubleshooting methodology, what should they do?" → Step 5 — Escalate as necessary. The methodology explicitly includes escalation as an option within the implementation step.
💬 "A network technician is troubleshooting connectivity. Ping to 8.8.8.8 works but ping to google.com fails. Which OSI layer does this indicate the problem is at?" → Layer 7 (Application) / DNS — IP connectivity works (Layer 3 OK), but name resolution fails, indicating a DNS issue.
💬 "Before implementing a fix on a production server, what should the technician do first?" → Step 4 — Back up data, identify potential effects, follow change management procedures, schedule a maintenance window if needed.
Ready to pass the A+ exam?
See the study guides, practice exams, and resources that make the difference.
See A+ Study Resources →
Related Articles