Documentation, diagrams and asset records

Why this matters

Objective 3.1 is "explain the purpose of organizational processes and procedures", and it is the objective technical people most often skim. That is a mistake on two counts.

It carries marks — domain 3 is 19% of the exam and this objective is a large part of it. And the content is what separates an estate that can be troubleshot from one that can only be guessed at. At 3 a.m., the difference between a twenty-minute outage and a four-hour one is usually whether someone wrote down how it was built.

The lesson

Documentation, and what it is for

Documentation is the written record of what exists, how it is configured, and why. Its value is entirely in being current — a diagram that is two reorganisations out of date is worse than none, because people trust it and act on it.

The practical rule that makes documentation survive: update it as part of the change, not afterwards. A change that is not documented is not finished. Left as a separate task, it is the one that gets dropped when the next thing arrives.

Physical versus logical diagrams

The single most examined distinction in this objective.

A physical diagram shows the real, tangible layout: which device is in which rack, which port connects to which port, where cables run, which floor and room things are in. It answers where is it and what is it plugged into.

A logical diagram shows how the network behaves: IP subnets, VLANs, routing relationships, traffic flow, trust boundaries. It ignores geography. Two devices side by side in a rack can be on opposite sides of a logical diagram if they are in different security zones.

Both are needed, and they answer different questions. Tracing a dead link is a physical question. Working out why VLAN 20 cannot reach the file server is a logical one. A question describing someone trying to find which patch panel port feeds a desk is asking for the physical diagram.

Rack diagrams are physical documentation at rack level: what occupies each rack unit, front and rear, with power feeds. They matter for planning — knowing you have 6U free and enough power before equipment arrives — and for remote hands, where someone who has never seen the rack needs to identify a device.

Cable maps and diagrams record which cable runs where: the patch panel port, the wall outlet, the room, the switch port. Combined with labelling at both ends, this is what makes moves and changes routine instead of archaeological.

Network diagrams are the general category, and they are usually drawn per layer:

• Layer 1 documents the physical: cabling, media types, ports and runs.
• Layer 2 documents switching: VLANs, trunks, spanning tree topology, link aggregation.
• Layer 3 documents routing: subnets, gateways, routing protocols, WAN links and their addresses.

Drawing them separately keeps each readable. A single diagram that tries to show cable runs and BGP peering at once shows neither.

Asset inventory

An asset inventory is the authoritative list of what the organisation owns and runs. A useful record per asset covers:

• Make, model, serial number and asset tag
• Location, down to the rack and unit
• Purchase date, warranty expiry and end-of-life dates
• Owner, and which service it supports
• Firmware or OS version
• IP and MAC addresses

It underpins nearly everything else in this objective. You cannot plan replacements without knowing ages, cannot assess a vulnerability without knowing which versions you run, cannot renew warranties you do not know about, and cannot investigate an incident on a device nobody recorded.

Hardware and software inventories are both required, and the software side is the one usually neglected — knowing which versions run where is what turns "is this CVE relevant to us?" from a research project into a query.

Keep it automated where possible. A hand-maintained inventory decays the moment someone is busy; discovery-driven inventory, as in the monitoring lesson, stays close to reality.

Life-cycle management

Life-cycle management is the practice of tracking equipment and software from purchase through to disposal, and planning each transition rather than reacting to it.

Two dates matter, and CompTIA names both.

End-of-life (EOL) is the point after which the vendor no longer sells the product. It is an ordering deadline, not a crisis: the product continues to work and continues to be supported for some period after.

End-of-support (EOS) is the point after which the vendor no longer provides support, patches or security updates. This is the one that matters for risk, and it is covered fully in the next lesson.

The distinction is worth having precisely because people use "end of life" loosely for both. An EOL device is fine to keep running while you plan; an EOS device is accumulating unpatched vulnerabilities with no remedy available.

Life-cycle management turns replacement into a budgeted, scheduled activity. The alternative is discovering a device is unsupported at the moment it fails, or at the moment an auditor asks.

Change management

Change management is the formal process for making changes to production systems. It exists because the leading cause of unplanned outages is planned changes.

A recognisable process has:

1. A request, describing what and why.
2. Assessment of risk and impact, including who is affected.
3. A plan — the steps to make the change.
4. A rollback plan — the steps to undo it. A change without one is a bet.
5. Approval by whoever is accountable, at a level matching the risk.
6. A scheduled window, usually outside business hours.
7. Implementation and testing, confirming it worked.
8. Documentation, updating the records the change invalidated.

Most processes distinguish standard changes (pre-approved, routine, low-risk — adding a port to a VLAN), normal changes (full review), and emergency changes (expedited approval to fix an outage, documented retrospectively).

The point the exam wants is that change management is about accountability and reversibility, not bureaucracy. When something breaks, the first question is "what changed?", and a change record answers it in seconds.

Request tracking

Request process tracking/ service request is how work enters and moves through the team. A service request is a formal ask — a new account, a switch port activated, a firewall rule — and tracking it means every request has an identifier, an owner, a status and a history.

The benefits are unglamorous and real: nothing is lost in a corridor conversation, workload is visible, recurring requests reveal what should be automated, and there is a record of who approved what.

It also interacts with change management. A service request is the demand; a change record is the action taken in production. Many requests need a change, and keeping them linked is what lets you trace an outage back to the request that caused it.