At 2 a.m., an incident responder isolates the network segment that the diagram shows hosting a compromised web server. The attack continues. The server had moved to a new subnet behind a cloud load balancer eight months earlier, and the change was approved, tested and closed without anyone updating the diagram.
On the CompTIA Security+ SY0-801 exam, objective 1.2 ends with documentation and version control, the records that make a change understandable after it's done. This lesson covers why updating documentation is part of every change, which documents usually need it, and how version control tracks configurations and code so every revision can be explained and reversed.
A change isn't complete until the documentation matches the system
Documentation describes how systems are supposed to look and work. Every change makes some of it wrong. If closing a change doesn't include updating that documentation, the documents drift away from reality one change at a time, and every decision based on them inherits the error. The next impact analysis misses a dependency, an auditor tests against an obsolete baseline, a new administrator follows a retired procedure, and responders isolate the wrong segment.
The documents a change most often affects are:
- Network diagrams and data flow diagrams.
- Asset inventory and configuration management database (CMDB) entries.
- Configuration baselines.
- Firewall rule documentation, recording each rule's purpose, owner and change number.
- Runbooks and standard operating procedures.
- Policies.
- Disaster recovery plans and contact lists.
A well-run change process lists the affected documents in the change record and checks during closure that each one was updated. Some standards require it. PCI DSS, for example, expects documentation to be updated after significant changes to systems in its scope.
Documentation is also sensitive. Network diagrams, IP address plans and firewall rule sets tell an attacker where the valuable systems are and how to reach them. They should be classified and access-controlled like any other internal data, not left on an open file share.
Diagrams must change whenever the network, data flows, or trust boundaries change
Security work relies on three kinds of diagram. Physical diagrams show racks, cabling and switch ports. Logical diagrams show subnets, VLANs, security zones, routing and where security devices sit. Data flow diagrams show where sensitive data moves, where it is stored and which trust boundaries it crosses.
Any change to those things should trigger a diagram update: a new subnet, VLAN or cloud virtual network, a firewall, VPN gateway or load balancer added or replaced, a workload moved to the cloud, a new third-party integration, or a system decommissioned and removed.
Data flow changes are the ones most often missed, because no hardware moves. Suppose the sales team connects the CRM to a new marketing platform that receives customer names and email addresses. No device changed, but customer data now crosses a trust boundary to a third party. That affects privacy obligations, the vendor risk review and data loss prevention rules. If the data flow diagram doesn't show it, the next person assessing privacy risk won't know it exists.
Each diagram should carry an owner, a version number and a last-updated date, so anyone reading it can judge whether it is current. Diagrams generated from live data, such as cloud console exports or network discovery tools, drift less than hand-drawn ones, but they still need review, because a tool shows what is connected, not what was intended.
On the exam, a scenario where responders or auditors worked from a diagram that didn't match the environment is pointing at a change that closed without updating diagrams.