3.10.2. Documentation Management
💡 First Principle: Documentation is a living operational system, not a one-time project. Documentation that isn't kept current is worse than no documentation—it creates false confidence and wastes time when people follow outdated procedures.
Key Documentation Types (review from Phase 1, now in operational context)
| Document | When Updated | Critical Content |
|---|---|---|
| Architecture diagrams | When topology changes | Logical relationships between systems |
| Infrastructure diagrams | When physical layout changes | Rack layouts, cable maps |
| Workflow diagrams | When processes change | Procedures, escalation paths |
| Recovery processes | After every DR test | Step-by-step restore procedures |
| Baselines | Quarterly or after major changes | Performance benchmarks |
| Change management records | After every change | What changed, when, who approved, rollback |
| Server configurations | After every configuration change | Current state of each server |
| Company policies | Annually or when regulations change | BIA, SLA, acceptable use |
Business Impact Analysis (BIA)
A BIA identifies which systems and services are most critical to business operations and quantifies the cost of their unavailability. It produces:
- Priority tiers for recovery (which systems are recovered first)
- RTO and RPO requirements per system
- Minimum acceptable service levels
- Dependency mapping (what does each critical system depend on?)
The BIA is the foundation of DR planning—you can't design recovery priorities without knowing which systems matter most.
Secure Storage of Sensitive Documentation
Documentation containing IP addresses, credentials, network diagrams, or system configurations must be protected:
- Stored in access-controlled systems (SharePoint with proper permissions, a PAM vault, or a configuration management database)
- Not emailed in plaintext
- Encrypted at rest when containing sensitive information
- Subject to the same access controls as the systems they describe
⚠️ Exam Trap: Documentation availability matters. A DR runbook stored only on the primary site's server is inaccessible during a site-level disaster. Recovery documentation must be accessible when systems are down—stored off-site or in a cloud-accessible location.
Reflection Question: A disaster recovery runbook is stored on a network share hosted by the server that needs to be recovered. What fundamental problem does this create?
