Good paperwork turns a messy ticket into a fast fix, because it captures what happened, what changed, and what comes next, so teams make fewer mistakes and hand work off safely. In CompTIA A+ Core 2 (220-1202), Domain 4.1, Objective 4.1 Types of documents, you're tested on the records and references that keep support work consistent under pressure. When documentation is missing or vague, techs repeat steps, overlook risks, and lose time rebuilding context. On the other hand, a clear incident report can preserve key facts, while a well-written standard operating procedure (SOP), including a software package custom installation procedure, can prevent guesswork during common tasks. Checklists also matter, since new user and onboarding setup checklists reduce missed steps, and user off-boarding checklists protect access control during departures. Service-level agreements (SLAs), both internal and external or third-party, set expectations for response and resolution, so accountability stays clear. Finally, knowledge base articles shorten future troubleshooting by turning one solution into many. After reading, you'll be able to identify and use each document type correctly, so you can support faster resolutions, cleaner handoffs, and more reliable outcomes.
Incident Reports
In CompTIA A+ Core 2 (220-1202), Domain 4.1, Objective 4.1 (Types of documents), incident reports matter because they preserve a clean record of what happened and what you did next. A good report reads like a reliable timeline, not a mystery novel. It helps the next technician avoid rework, supports audits, and protects the business if the incident becomes a dispute.
Treat the report as a factual "snapshot" taken close to the event. When you write it well, you reduce noise, keep decisions defensible, and make follow-up work easier to assign and verify.
What to include in an incident report so it helps later
Start with core identifiers so anyone can connect the report to related work. Record the reporter's name and role, the date and time reported, and the incident start time if known. Use a consistent time zone, and note it once (for example, "All times in UTC"). Also include any ticket numbers, alert IDs, or case references that tie the incident to monitoring, help desk, or vendor threads.
Next, describe impact and scope in plain terms. List impacted users (count, departments, locations), the systems and services affected (hostnames, IPs, application names), and what stayed normal. Scope is your boundary line. Without it, people assume the issue was bigger, or smaller, than it really was.
Then capture what you observed, not what you suspect. Document symptoms as facts, such as error messages, failed logins, slow response times, or antivirus detections. When you include evidence, name it clearly, for example, "EDR alert: Suspicious PowerShell, severity high." If you have screenshots or logs, reference where they are stored and label them with dates.
After that, write the work performed in a way someone else could repeat. Include:
- Steps taken in order, including checks that ruled things out.
- Tools used (for example, Event Viewer, syslog, EDR console, packet capture, password reset portal).
- Changes made (config edits, firewall rules, patches, reboots, account actions), including who approved them if required.
- Final resolution and how you verified it (tests run, monitoring status, user confirmation).
- Follow-up tasks with owners and due dates, such as root cause review, user coaching, or control improvements.
Accuracy matters more than a perfect narrative. If a detail is unknown, write "unknown" and state what you did to confirm it. Guessing turns a report into a rumor, and rumors age poorly.
Incident report best practices, clarity, privacy, and chain of custody
Write for a reader who did not see the incident. Use short sentences, a neutral tone, and clear labels (Impact, Timeline, Actions, Resolution). Avoid blame. Focus on events and decisions, because people rotate, but records stay. Keep timestamps consistent and specific, and avoid vague phrases like "later" or "shortly after." If you need to estimate, mark it as an estimate.
A simple structure improves peer review. Many teams use a timeline with one event per line, followed by a concise actions summary. Also, define acronyms once. If your audience includes non-security staff, spell out key terms to prevent misreading.
Treat an incident report like lab notes, write what you observed, when you observed it, and what you changed.
Privacy must shape what you include. Store only the least detail needed to support troubleshooting and compliance. Avoid copying sensitive content into the report body when a reference will do. In practice, that means:
- PII: Don't paste full names with personal identifiers, home addresses, personal phone numbers, or full ID numbers. Use usernames or employee IDs if policy allows.
- PHI (health data): Don't include it unless your role and policy require it, then limit access and follow retention rules.
- Credentials and secrets: Never include passwords, API keys, recovery codes, or full authentication tokens.
Where you store the report matters as much as what you write. Use approved systems (ticketing platforms, secured document repositories, or incident management tools) with role-based access. Avoid personal drives, email threads, or chat logs as the system of record.
Finally, handle evidence carefully. Don't edit raw logs or overwrite files during collection. Instead, export copies when possible, record where they came from, and limit access to those who need it. Some organizations also record file hashes to show integrity; if your team uses hashes, record the hash value and the method used, and keep the original evidence unchanged.
Quick example, a short incident report that would pass a peer review
Incident: Phishing email reported by user (Ticket INC-18422)
Reporter: J. Patel, Finance
Times (local, ET): 09:12 user reported, 09:18 triage started, 09:27 containment complete, 09:41 verification complete
Impact: 1 mailbox targeted, no confirmed account compromise
Systems: Microsoft 365 Exchange Online, EDR console, DNS filter
Symptoms: User received "Invoice Overdue" email from external sender, link led to lookalike login page. User clicked link but did not enter password.
Actions taken: Reviewed message headers, confirmed spoofed domain. Searched tenant for matching subject and sender, quarantined 17 copies. Blocked sender domain in email policy. Pulled URL from email, added to DNS filter blocklist. Checked Azure sign-in logs for user, no abnormal logins. Ran EDR scan on user device, no detections.
Resolution: Email removed from mailboxes, sender and URL blocked, user advised to reset password as a precaution and complete phishing awareness module (Task FUP-552).
Standard Operating Procedures
For CompTIA A+ Core 2 (220-1202), Domain 4.1, Objective 4.1 (Types of documents), standard operating procedures (SOPs) matter because they turn repeat work into repeatable results. An SOP is a step-by-step playbook for a task you expect to do again, such as onboarding a device, resetting a service, or restoring access after an outage. Unlike a knowledge base article, which often explains options and context, an SOP tells you exactly what to do, in what order, and how to confirm you did it right.
A strong SOP reduces guesswork, shortens handoffs, and lowers risk. It also helps new staff perform at the same level as experienced staff, because the process lives on the page, not in someone's memory.
What makes an SOP easy to follow under pressure
When systems fail, attention narrows and time matters. Therefore, an SOP should read like a clear map with signposts, not a long narrative. Start by giving the reader quick context, then guide them through actions with built-in safety and proof points.
A practical SOP structure includes:
- Purpose: State the outcome in one sentence (for example, "Restore printing for Floor 3 without losing queued jobs").
- Scope: Define what systems, sites, or users it covers, plus what it does not cover.
- Prerequisites: List required access, accounts, network location (on-site or VPN), and any approvals needed before you begin.
- Tools: Name exact consoles, utilities, or portals, including where to find them (URL, app name, admin jump box).
- Roles and approvals: Clarify who performs steps and who signs off (help desk, sysadmin, security, manager).
- Safety notes: Put high-risk warnings early (data loss, service interruption, electrical hazards).
- Step list: Use short, numbered actions written as commands. Keep each step to one action when possible.
- Decision points: Add "if/then" branches where the path can change (for example, "If the service won't start, check X; if it starts, continue to Y").
- Rollback steps: Explain how to undo changes, including where configs were backed up and what "restore" looks like.
- Verification checks: Require proof, such as a test login, a monitored metric returning to normal, or a user confirmation.
Clarity also depends on maintenance metadata. Include version control basics at the top or bottom: document owner, version number, last updated date, change history (what changed and why), and the next review date. If your team uses approvals, record the approver and date, so changes remain accountable.
Under pressure, the best SOPs replace memory with checkpoints, because they tell you what "done" looks like.
Software package custom install procedures, when defaults are not enough
A software package custom installation procedure is a specialized SOP used when a standard "Next, Next, Finish" install creates problems. In CompTIA A+ documentation terms, "custom installation" means you intentionally choose settings instead of accepting defaults. As a result, the procedure must capture every choice that affects behavior, security, or supportability.
Custom installation commonly includes:
- Features: Selecting required modules and excluding optional ones.
- Install paths: Setting the install directory, data directory, or cache location (often for storage planning).
- Settings: Choosing default file associations, service accounts, ports, or encryption options.
- License keys and activation: Entering a key, linking to a tenant, or pointing to a license server.
- Add-ons and plugins: Installing extensions, language packs, drivers, or integrations.
Concrete examples make this SOP useful in real life. For instance, you might disable unwanted components to reduce attack surface (such as removing bundled toolbars, legacy runtimes, or sample services). You may also set update channels (stable vs. rapid) so production devices do not change unexpectedly. In managed environments, the SOP should document silent install switches used by deployment tools, because consistency matters more than convenience during a single install.
After installation, the procedure should require post-install checks, not "looks good" statements. Good checks include verifying the app launches, confirming the correct version, validating services run under the right account, and ensuring firewall rules match the chosen ports. If the install includes drivers, confirm Device Manager shows no errors and that required peripherals work.
Testing belongs in the SOP, not as an afterthought. First test the procedure on a lab machine, then on a pilot group, and only then move to broader deployment.