Documentation & Change Management

A+ Core 2 — 220-1102 | Domain 4.1

Documentation &
Change Management

Network diagrams, knowledge bases, ticketing systems, and formal change control. Proper documentation turns tribal knowledge into institutional resilience.

18 Slides Domain 4.1 Tickets • Change Control • Diagrams • Policies Exam 220-1102

Slide 2 of 18

Documentation Lifecycle

All operational documentation follows a create-to-archive pipeline.

Create

Author drafts content based on operational knowledge, change records, or incident findings. Version number assigned at v0.1. Draft status is clearly marked.

Review → Approve

Subject matter experts verify accuracy. Management or change advisory board approves. Without approval, no document is published to the knowledge base or shared with users.

Publish → Update → Archive

Published documents carry a review date. Updated when configurations change. Archived (not deleted) when superseded — old versions must be retained for audit and legal purposes.

Slide 3 of 18

Network Documentation

Diagrams, IP schemas, and asset inventories that describe the current state of the environment.

Network Diagrams

Logical diagrams show IP addressing, VLANs, and routing. Physical diagrams show cable runs, rack layouts, and port-to-port connections. Must reflect current state — outdated diagrams are worse than none because they create false confidence.

IP Address Management (IPAM)

Spreadsheet or dedicated tool tracking every IP assignment: hostname, MAC address, owner, location, and purpose. Prevents duplicate IP conflicts. Critical for troubleshooting and change planning.

Cable Run Documentation

Each cable labeled at both ends with the port-to-port path documented (e.g., Patch Panel 1 Port 3 → Switch-A Gi0/3 → IDF-102). Without this, tracing a fault requires visual inspection of every cable.

Asset Inventory

Every managed device: make, model, serial number, firmware version, location, owner, and support contract. Asset inventory is the foundation of change management — you cannot control what you cannot identify.

Baseline Configuration

Documented "known-good" state of each device type: OS version, patch level, enabled services, firewall rules, and configuration settings. Required for compliance audits and post-incident recovery.

Slide 4 of 18

Ticketing Systems

Every incident, request, and change should have a ticket. If it is not documented, it did not happen.

Incident Tickets

Unplanned interruption or degradation of service. Fields: description, affected user, priority/severity, troubleshooting steps taken, resolution, and close code. Incident history drives problem management.

Service Request Tickets

Formal requests for standard services: new user account, software install, hardware replacement. Tracked separately from incidents. Fulfillment time is a key SLA metric.

Change Request Tickets

Any modification to the environment follows the change management process. Linked to the asset being changed. Includes rollback plan, test plan, and approval chain before work begins.

Required Ticket Field	Purpose
Date / Time opened	Establishes response time baseline for SLA measurement
Affected user / asset	Scopes the impact; identifies affected parties
Priority / Severity	Determines response time commitment from SLA
Steps taken	Prevents repeated troubleshooting; enables handoff between technicians
Resolution / Close code	Enables trend analysis and knowledge base article creation

Slide 5 of 18

Change Management Process

Formal change control prevents uncoordinated modifications that cause outages.

Request for Change (RFC)

Initiates the process. Documents what is being changed, why, when, and who is responsible. Includes risk assessment, back-out plan, and test plan. Submitted before any work begins.

Change Advisory Board (CAB)

Group of stakeholders who review and approve or deny RFCs. May include IT management, business owners, security, and operations. High-impact changes may require CAB; standard changes may be pre-approved.

Change Categories

Standard: pre-approved, low risk, routine (e.g., password reset). Normal: requires RFC and CAB review. Emergency: expedited approval for outage recovery. Emergency changes are documented after the fact if needed for speed.

Rollback Plan

Every change must have a documented rollback procedure that can restore the previous state if the change fails or causes unintended consequences. "We can just undo it" is not a rollback plan. The specific commands, configuration backups, and validation steps must be written down before the maintenance window opens.

Slide 6 of 18

Acceptable Use Policy (AUP)

Defines permitted and prohibited use of organizational IT resources.

What an AUP Covers

Permitted and prohibited website categories. Personal use limits on company equipment. Software installation restrictions. Prohibited data types (confidential, PII, classified). Email and messaging policy. Consequences for violations.

AUP Enforcement

Signed by every employee at hire and upon policy updates. Web content filtering enforces browsing restrictions. DLP tools detect prohibited data transfers. HR enforces violations; IT provides the evidence logs.

BYOD Policy

Bring Your Own Device policies govern personal device use on corporate networks. Typically require MDM enrollment, acceptable use agreement, and acknowledgment that the company may remotely wipe the device.

Remote Access Policy

VPN usage requirements, approved devices, approved locations, and security baseline (AV, patching, encryption). Defines when remote work is permitted and what data can be accessed remotely.

Social Media Policy

Governs what employees may post publicly regarding the organization, customers, or colleagues. Employees are often the source of OSINT for attackers — policies limit inadvertent disclosure.

Slide 7 of 18

Knowledge Base & Runbooks

Institutional memory that survives staff turnover and enables consistent service delivery.

Knowledge Base Articles (KBAs)

Step-by-step solutions to known issues, published for technician or end-user reference. Created from resolved incident tickets. Enables Level 1 support to resolve issues that previously escalated. Quality degrades without a review cycle.

Runbooks

Operational procedures for routine tasks: new server provisioning, monthly patch cycle, backup verification. Written at the command level — specific enough that a qualified technician who has never performed the task can follow them without assistance.

Incident Playbooks

Pre-defined response procedures for known incident types: ransomware, DDoS, data breach, hardware failure. Reduce response time and prevent decision paralysis during high-stress events. Reviewed and updated after every activation.

A new Level 1 technician receives a call about Outlook not connecting. Without a KBA they escalate it. With a KBA titled "Outlook AutoDiscover Failure — Steps to Resolve," they check DNS, check Autodiscover, re-enter credentials, and resolve it in 8 minutes. KBAs directly reduce mean time to resolution (MTTR).

Slide 8 of 18

Standard Operating Procedures (SOPs)

Documented step-by-step processes that ensure consistent, repeatable execution.

Why SOPs Matter

Without documented procedures, every technician does things differently. SOPs ensure regulatory compliance, reproducible quality, auditable actions, and survivable operations when key personnel leave or are unavailable during an incident.

SOP vs Runbook vs Policy

Policy: what must be done and why (governance layer). SOP: how it is done, step by step (operational layer). Runbook: specific commands and parameters for a specific system (execution layer). All three levels are needed in a mature IT operation.

SOP Type	Example	Audience
New Employee Onboarding	Account creation, device provisioning, access rights, orientation	IT Onboarding Team
Offboarding	Account disable, device collection, access revocation, badge return	IT Security & HR
Patch Management	Monthly cycle: test, approve, stage, deploy, verify, document	Systems Administration
Backup & Recovery	Scheduled backup validation, restore test procedure, offsite verification	Storage / Backup Team
Incident Escalation	Criteria for escalation from L1 to L2 to L3, contact list, bridge line	All Support Tiers

Slide 9 of 18

Diagram Types

Different diagram types serve different purposes — know when to use each.

Diagram Type	Shows	Tool / Format
Logical Network	IP addressing, VLANs, routing, firewall zones, domain structure	Visio, draw.io, Lucidchart
Physical Network	Cable runs, rack layout, port-to-port connections, building floor plan	Visio, AutoCAD, draw.io
Rack Diagram	U-position of every device, power distribution, cable management	Visio, RackTables, DCIM software
Wiring Diagram	Exact cable path, connector type, termination points, wire colors	AutoCAD Electrical, hand-drawn for simple runs
Process Flowchart	Decision trees for troubleshooting, approval workflows, escalation paths	Visio, draw.io, Lucidchart

Living Documents

Diagrams must be updated whenever the environment changes. Stale diagrams cause incorrect troubleshooting assumptions. Assign diagram ownership and require update as part of every change ticket closure.

Version Control

Store diagrams in a version-controlled repository. Every change should carry a revision number, date, and the name of the person who updated it. Prior versions must be archived for reference during audits.

Slide 10 of 18

Incident Documentation

From first call to post-incident review — every step must be recorded.

Initial Capture

Time received, reported by, symptoms described. Never paraphrase the user's complaint — record exactly what they reported. Initial error messages and affected systems are time-stamped and logged verbatim.

Troubleshooting Log

Each diagnostic step logged with timestamp and outcome: what was tried, what was found, what was ruled out. This prevents duplicate work on shift handoff and forms the basis of the KBA if the issue is novel.

Resolution & Close

Root cause identified, fix applied, user confirmed restoration of service. Close code categorizes the resolution type. A five-minute close writeup saves hours of re-investigation when the same issue recurs.

Post-Incident Review (PIR)

For major incidents, a PIR (also called a post-mortem or root cause analysis) is conducted within 48–72 hours. Attendees: all parties involved in the response. Output: documented root cause, contributing factors, timeline, and action items to prevent recurrence. The PIR is blameless — its purpose is improvement, not punishment.

Slide 11 of 18

Software Licensing Documentation

License compliance is a legal obligation. Undocumented licenses are audit liabilities.

License Types

Per-seat (per device or per user). Site license (unlimited installs within an organization). Open source (varies by license: MIT, GPL, Apache). Subscription (annual renewal, cloud-delivered). OEM (tied to hardware, non-transferable).

License Tracking

Track every software title: vendor, product name, version, license key, quantity purchased, quantity deployed, renewal date, and contract owner. Software Asset Management (SAM) tools automate this. A spreadsheet is a legal minimum but not scalable.

Compliance Risk

Under-licensing exposes the organization to vendor audits and significant fines. Over-licensing wastes budget. Both conditions are caught in a Software Asset Management audit. Regular reconciliation of purchased vs deployed licenses is required.

A vendor audit finds 47 installations of a product for which the company holds 40 licenses. The contract includes an audit clause allowing the vendor to bill at list price for the delta, plus a penalty. The fine is $62,000. Proper SAM would have caught the seven unlicensed installs before the audit.

Slide 12 of 18

Regulatory & Compliance Documentation

Different industries have specific documentation requirements that carry legal weight.

Framework / Regulation	Industry	Key Documentation Requirement
HIPAA	Healthcare	PHI access logs, Business Associate Agreements, Risk Analysis
PCI-DSS	Payment Card	Network diagrams with cardholder data flow, change logs, vulnerability scans
SOX	Public Companies	IT controls documentation, change management records, access reviews
NIST SP 800-171	Federal Contractors	System Security Plan (SSP), policy documentation, incident response plan
ISO 27001	Any Industry	ISMS documentation, risk register, Statement of Applicability

Exam Relevance

The A+ exam does not test compliance frameworks in depth, but expects technicians to understand that documentation is not optional in regulated environments. A technician asked to make a network change in a PCI-scoped segment must follow the change management process and document the change — regardless of urgency.

Slide 13 of 18

Asset Disposal & Data Sanitization

End-of-life assets require documented sanitization to prevent data exposure.

Sanitization Methods

Overwrite (software wipe, DoD 5220.22-M): multiple passes of random data. Degaussing: magnetic field destroys data on HDDs and magnetic tape; ineffective on SSDs. Physical destruction: shredding, crushing, or incineration. Cryptographic erasure: destroy the encryption key; data is permanently inaccessible.

Chain of Custody

Document who had possession of each piece of media from decommission through disposal. Certificate of destruction from an approved vendor. This chain of custody is auditable and legally defensible in the event of a data breach investigation.

When "Delete" Is Not Enough

Deleting files only removes directory entries. Formatting is also recoverable with forensic tools. Only overwrite, degaussing, or physical destruction ensures data cannot be recovered. This is why disposal documentation matters.

Slide 14 of 18

Professionalism & Communication

CompTIA Domain 4 is as much about conduct as it is about documentation systems.

Setting Expectations

Communicate realistic timelines. If an issue will take two hours, say two hours. Under-promise and over-deliver. Never give a resolution time you cannot keep. Follow up proactively — users should hear from you before they ask for an update.

Respecting Privacy

Technicians access private data during legitimate support. Do not look at files beyond what the repair requires. Never discuss customer data outside professional channels. Avoid reading emails or personal files even when visible on the screen.

Property & Workspace

Treat customer hardware and workspace with care. Replace any components removed during repair. Leave the workspace as clean as it was found. Document any pre-existing damage before starting work to avoid liability disputes.

Avoid These

Arguing with customers. Using jargon without explanation. Interrupting. Making assumptions about what the user did wrong. Dismissing a problem because you cannot immediately reproduce it. Fixing one thing and breaking another without disclosure. All of these appear as scenarios on the A+ exam.

Slide 15 of 18

Escalation Procedures

Knowing when and how to escalate is a core technician competency.

When to Escalate

Beyond your technical expertise. Requires access or permissions you do not have. Issue has exceeded your allotted resolution time. Problem is impacting multiple users or business-critical systems. Security incident is suspected.

How to Escalate Properly

Transfer all ticket notes, steps taken, and findings to the next tier. Verbally brief the receiving technician if possible. Never dump a ticket without context — that forces re-investigation and delays resolution. Stay available for questions during the handoff period.

Escalation Tiers

L1: First contact, known-issue resolution via KBA. L2: Deeper technical investigation, configuration changes. L3: Engineering, vendor escalation, root cause analysis. Some organizations add L4 for vendor support or specialized subject matter experts.

Slide 16 of 18

Backup & Recovery Documentation

An untested backup is not a backup — it is a hope. Document everything around the process.

Backup Documentation Requirements

What is backed up, how often, and by what method (full, incremental, differential). Where backups are stored (on-site, off-site, cloud). Retention period. Who is responsible for verification. RTO and RPO targets that the backup strategy must support.

Restore Testing

Backups are tested by performing actual restores to a test environment on a scheduled basis (at minimum quarterly). Results are documented: what was restored, how long it took, whether data integrity was confirmed. Failed restores trigger immediate remediation.

Term	Definition	Example
RPO	Recovery Point Objective: maximum acceptable data loss	"We can lose no more than 4 hours of transaction data"
RTO	Recovery Time Objective: maximum acceptable downtime	"System must be restored within 2 hours of an incident"
MTTR	Mean Time to Repair: average time to resolve an incident	Tracked from ticket open to resolution; drives staffing decisions

Slide 17 of 18

Privacy Policy & Data Handling

Technicians encounter sensitive data daily. Policy defines how it must be handled.

Data Classification

Public: freely shareable. Internal: for employees only. Confidential: limited distribution, business-sensitive. Restricted / Regulated: PII, PHI, PCI data — governed by law, requires encryption at rest and in transit, strict access control, and documented handling procedures.

Personally Identifiable Information (PII)

Any data that can identify an individual: name, SSN, DOB, address, email, biometrics, IP address in some jurisdictions. Technicians must report any unauthorized PII exposure to their supervisor and security team immediately.

Data Handling Violations

Sending unencrypted PII via email. Storing confidential data on personal devices. Discussing customer data in public spaces. Screenshots of sensitive screens shared in personal messaging apps. Each of these is a reportable incident.

Slide 18 of 18

Domain 4.1 Key Facts

Documentation & Change Management — condensed for exam review.

1

Documentation lifecycle: Create → Review → Approve → Publish → Update → Archive. Old versions are archived, not deleted.

2

Ticket fields: date/time, affected user/asset, priority, steps taken, resolution, and close code are all required.

3

Change categories: Standard (pre-approved), Normal (CAB review required), Emergency (expedited approval; document after if needed).

4

Every RFC must have a rollback plan. "We can undo it" is not acceptable — specific steps must be documented before the change window opens.

5

AUP defines permitted/prohibited use of IT resources. Signed at hire and on policy updates. Enforced by content filtering and DLP tools.

6

RPO = maximum acceptable data loss. RTO = maximum acceptable downtime. Both drive backup strategy and DR design.

7

Data classification: Public, Internal, Confidential, Restricted. PII and PHI are restricted categories requiring encryption and documented handling.

8

Professionalism: set realistic expectations, respect user privacy, document pre-existing damage, escalate with full context transferred.

Documentation & Change Management | A+ Core 2