Organizational Processes | Network+ N10-009

Slide 1 of 10 | N10-009 Obj 3.1 | Operations

Organizational Processes:
Documentation & Change Management

Process failures cause more outages than hardware failures.

A junior admin pushed a firewall change to production without approval. Within minutes, the entire sales team lost VPN access. Change management exists to prevent exactly this. Documentation exists so you can fix it when prevention fails. Both are examinable — and both matter in the real world.

10 Slides N10-009 Obj 3.1 Operations & Management Process + Practice

Slide 2 of 10

Documentation Types

Physical and logical diagrams serve different audiences and answer different questions.

Physical Diagram

Shows physical layout: buildings, rooms, racks, cable runs, port connections. Created and maintained by cabling contractors and facilities staff. Critical for on-site troubleshooting and moves/adds/changes.

Logical Diagram

Shows IP addressing, VLAN assignments, routing paths, and protocol relationships. Devices appear as icons, not physical shapes. Updated by network engineers. The NOC uses this diagram when analyzing traffic and planning changes.

Why Both Matter

A physical diagram tells you where the cable is. The logical diagram tells you what the cable carries. To trace a VPN problem, you start with logical. To fix a broken link, you go to physical. They are complementary, not interchangeable.

Slide 3 of 10

Change Management Workflow

Every change to production requires a ticket, a review, an approval, and a rollback plan — before a single command is typed.

CAB — Change Advisory Board

Cross-functional committee that reviews proposed changes. Members: network ops, security, server team, application owners, business stakeholders. Emergency CAB for urgent changes with faster approval path but tighter scope controls.

Change Windows

Scheduled periods for production changes — typically nights and weekends. Standard changes (low risk, pre-approved): can proceed without full CAB review. Emergency changes: separate process, post-hoc documentation. The junior admin skipped all of this.

Rollback Plan Requirement

Every change ticket must include a rollback plan before approval. If the change fails verification, the rollback plan is executed immediately. No rollback plan = ticket rejected. This is the safety net the junior admin had no plan for.

Slide 4 of 10

Configuration Management & Config Drift

The running config diverges from the golden baseline. The diff is your early warning system.

Configuration Types

Golden/Baseline config — the approved, known-good configuration. Stored in version control.
Running config — what is currently active on the device. May drift from baseline through undocumented changes.
Startup config — what loads on boot. If startup differs from running, a reboot causes unexpected behavior.

Config Drift Detection

Tools like RANCID, Oxidized, or commercial DCIM/NMS platforms automatically pull device configs on a schedule and diff them against the stored baseline. Alerts trigger on any deviation. This is how you catch the unauthorized ACL change at 3am instead of during an incident.

Version Control for Configs

Store all configs in Git. Each change is a commit with author, timestamp, and message. Roll back with git revert. Blame with git log. Same discipline as code — because network config IS code.

Slide 5 of 10

Network Diagrams: Layer 1 / 2 / 3

Each OSI layer exposes different information. The right diagram depends on what you are troubleshooting.

Layer 1 — Physical

Layer 2 — Data Link

Layer 3 — Network

Diagram Currency

A diagram that is 6 months out of date is worse than no diagram — it gives false confidence. Require diagram updates as part of every change management ticket. Tie documentation to the change process, not to memory.

Tools in Practice

Visio, Lucidchart, draw.io (free) for manual diagrams. NetBrain, SolarWinds for automated discovery and diagram generation. Export to PDF after every change and store with the change ticket.

Slide 6 of 10

Asset Inventory & CMDB

You cannot secure, patch, or decommission what you do not know exists.

What the CMDB Tracks

Every configuration item (CI): hardware assets (make, model, serial, location), software licenses (version, seat count, expiry), network devices (IP, VLAN, firmware), warranties and support contracts, and relationships between CIs (this server runs on that hypervisor).

Software Licensing

Track per-seat vs. per-core vs. site licenses. Audit against installed software regularly. License audit failures = significant fines. Include software in CMDB, not just a spreadsheet.

Shadow IT Risk

Devices and services deployed without IT's knowledge. They are not in the CMDB, not patched, not secured. Network access control (NAC) and periodic discovery scans help surface them.

Automation

SNMP discovery, Nmap scanning, or agent-based inventory tools populate the CMDB automatically. Manual inventories become stale immediately. Automate the scan, review the exceptions.

Slide 7 of 10

SLA Metrics & IPAM

SLAs define what "good" looks like. IPAM prevents address conflicts from making it look bad.

Service Level Agreement Metrics

Metric	Definition	Typical SLA
Uptime %	Available / total time	99.9% = 8.7h/yr down
MTTR	Mean Time to Repair	Avg time to restore service
MTBF	Mean Time Between Failures	Reliability indicator
RTO	Recovery Time Objective	Max acceptable downtime
RPO	Recovery Point Objective	Max acceptable data loss

IPAM — IP Address Management

Centralized database of all IP address allocations. Tracks what address is assigned to what device, subnet utilization, DHCP scope usage, and DNS records. Prevents duplicate IP conflicts before they cause outages. Tools: InfoBlox, SolarWinds IPAM, phpIPAM (free).

IPAM — Subnet Utilization

10.1.0.0/24 — Engineering

198 / 254 addresses used (78%)

10.2.0.0/24 — Servers

89 / 254 addresses used (35%)

10.3.0.0/24 — VoIP

241 / 254 used (95%) — plan expansion

Slide 8 of 10

Network Baselines & Anomaly Detection

You cannot spot abnormal without first knowing what normal looks like.

Establishing a Baseline

Measure network traffic, CPU, memory, and error rates during normal operations for at least 30 days. Capture peak hours, off-hours, and weekly cycles. This becomes the reference for what "normal" looks like. Document it formally.

Anomaly Detection

Any sustained deviation above the baseline triggers investigation. The spike at 21:43 could be: a backup job, a DDoS, malware exfiltration, or a misconfigured application. The baseline makes it visible. Without it, the spike blends into the noise.

Capacity Planning

Baselines reveal growth trends. If the average WAN utilization grows 5% per quarter, you can project when the link will saturate and order an upgrade before users notice. Reactive procurement is always more expensive than planned.

Slide 9 of 10

Life-Cycle Management: EOL / EOS & Patching

Unpatched and end-of-life equipment is one of the most common vectors for network compromise.

End of Life vs End of Sale vs End of Support

End of Sale (EOS): vendor stops selling the product. You can still buy used, but the clock is ticking.
End of Maintenance (EoSM): no more security patches released. Any new CVE is permanently unpatched.
End of Life (EOL): vendor stops all support, including hardware replacement. If it breaks, you are on your own.

The EOL Security Problem

WannaCry (2017) exploited Windows XP — out of support since 2014. EternalBlue affected 200,000 systems in 150 countries in one day. The organizations running EOL equipment had no patch available, and no recourse. Track EOL dates in the CMDB. Budget for replacements before the date arrives.

Decommissioning Process

Removing a device from the network is a change — it requires a ticket. Sanitize storage media (NIST SP 800-88). Remove from CMDB, IPAM, and DNS. Revoke certificates. Update network diagrams. Physically label as decommissioned before disposal. Chain of custody documentation for regulated industries.

Slide 10 of 10 | Summary

Organizational Processes: What You Now Know

1Physical diagrams show cable and hardware layout. Logical diagrams show IP, VLAN, and routing. Both must be current and stored where engineers can find them at 2am.

2Change management: Request → Review (CAB) → Approve → Schedule → Implement → Verify → Document. No undocumented production changes. Ever.

3Config drift detection: compare running config to golden baseline. Version control configs in Git. Roll back on deviation.

4CMDB tracks all CIs — hardware, software, licenses, warranties. IPAM prevents address conflicts. Both must be automated and current.

5SLA metrics: uptime %, MTTR, MTBF, RTO, RPO. Know the definitions and what each measures.

6Baselines establish normal. Anomalies become visible only against a known baseline. Capture at least 30 days of data across peaks and valleys.

7EOL/EOS devices have no security patches. Track dates in CMDB, budget replacements before EoSM. Decommissioning is a formal change process.

The firewall incident is resolved. The junior admin's unauthorized change was caught within 15 minutes by config drift detection, compared against the golden config in version control, and rolled back by the on-call engineer using the documented rollback procedure. A post-incident review resulted in tighter RBAC on the firewall management console and a mandatory change ticket requirement for all ACL modifications.

Documentation and process are not bureaucracy — they are how networks survive contact with human error.

N10-009 Obj 3.1 Coverage

Physical/logical diagrams, change management (CAB, rollback), configuration management (golden config, drift), network diagrams (L1/L2/L3), asset inventory, CMDB, IPAM, SLA (MTTR/MTBF/RTO/RPO), baselines, EOL/EOS, patch management, decommissioning.

Organizational Processes N10-009