Chapter 15 — Documentation and change records
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Documentation"]
N2["15.2 Change records"]
N3["15.3 Tickets"]
N4["15.4 Standards"]
N5["Where passwords live"]
N6["Knowledge base and templates"]
N7["Reviewing documents and changes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Documentation"]
N2["15.2 Change records"]
N3["15.3 Tickets"]
N4["15.4 Standards"]
N5["Where passwords live"]
N6["Knowledge base and templates"]
N7["Reviewing documents and changes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 Documentation]
|
v
[15.2 Change records]
|
v
[15.3 Tickets]
|
v
[15.4 Standards]
|
v
[Where passwords live]
|
v
[Knowledge base and templates]
|
v
[Reviewing documents and changes]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) document setups; (2) record changes; (3) write useful tickets.
15.1 Documentation
Each system has a short page: what it is, how it is set up, who looks after it and where passwords are stored. Short pages mean someone new, such as a different supplier technician, can understand a system quickly. Before Nadia's work, nobody knew who had set up the router or where its password was. Each page is stored in a shared folder that the supplier and Lena can reach. Passwords themselves stay in the password manager, and the page says only where to find them.
15.2 Change records
Every change is noted with date, who, what and why. A change record lets someone trace a problem back to the change that caused it. For example, if a setting stops the old tax tool working, the record shows when the setting changed and why. Nadia and the supplier keep records in the same place, using a short template. Changes made in an emergency are recorded afterwards. Lena reviews the change records monthly to see what has changed in the office.
15.3 Tickets
Good tickets describe the problem, steps taken and outcome, so others can learn. A ticket that only says "fixed" teaches nothing. Nadia's ticket on the broken update service listed the error, the repair steps and the result, so the next technician facing the same problem can follow it. Good tickets also show patterns, such as repeated problems with one PC. The supplier reviews tickets monthly with Nadia, and recurring problems become tasks. Nadia uses a short template with fields for problem, steps and outcome, and Sam reviews a sample of her tickets to check they would let another technician repeat the fix.
15.4 Standards
NIST SP 800-128 links configuration management with documentation and change control. The guidance explains why configuration, documentation and change records belong together: a setting that is not documented cannot be checked, and a change that is not recorded cannot be traced. Nadia uses it to explain to Lena why the firm keeps system pages and change records. The supplier's own processes follow the same ideas, so they fit easily with the firm's records. Nadia also cites SP 800-128 in her project report and condenses that explanation into a one-paragraph summary Lena can keep.
Where passwords live
System pages record where a password is stored, never the password itself. Router, printer, firmware and storage box passwords are kept in the password manager's IT vault, which only Nadia and the supplier can open, and access is logged. This replaces a paper notebook in Lena's drawer that held every admin password in one place. Once its contents are moved and the passwords changed, the notebook is shredded. Changing the passwords matters, because anyone who had seen the notebook could still know them. The vault also records when each password was last changed, which helps plan rotations.
Knowledge base and templates
Common fixes become short knowledge base articles: how to reset MFA, reconnect the VPN or request software. Staff can solve simple problems themselves and new technicians learn faster; Nadia writes eight articles, each checked by the supplier. She also creates templates for system pages, tickets and change records, so every entry has the same fields and nothing important is left out. Templates make reviews faster, because reviewers know where to look for each detail, and they make gaps obvious: an empty field in a change record stands out in a way that a missing sentence in free text does not.
Reviewing documents and changes
Documentation drifts like settings, and out-of-date documentation can mislead someone during an outage, when accuracy matters most. Nadia adds a yearly review date to every system page, and the supplier checks pages after any major change. Changes themselves get a lighter weekly review: each Friday, Nadia and the supplier spend five minutes going through the week's change records together. The aim is to spot anything unexpected, such as a change with no reason recorded, or a change that should have triggered a documentation update.
Worked example
Nadia's ticket on the broken update service lists the error, the repair steps and the result.
Synthetic case. Tickets are synthetic.
Errors and limits
Undocumented fixes are repeated from scratch next time.
Exercises
- EX057 — System page. What goes on a system page? Rubric: 3 = four items;; 2 = three;; 1 = fewer;; 0 = none.
- EX058 — Ticket quality. What makes a ticket useful later? Rubric: 3 = problem, steps, outcome;; 2 = detail;; 1 = vague;; 0 = none.
- EX059 — Change fields. List change record fields. Rubric: 3 = date, who, what, why;; 2 = three;; 1 = fewer;; 0 = none.
- EX060 — Standard reference. Which NIST publication covers configuration change control? Rubric: 3 = SP 800-128;; 2 = NIST;; 1 = wrong;; 0 = none.
Synthesis
Clear documentation saves time and supports security.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →