Competition Checklist · 09 · Documentation
Evidence & Change Log Checklist
Record original state, evidence, exact remediation, reasoning, verification, and unresolved follow-up so the entire team can understand what changed during the round.
A strong change log reduces duplicate work, protects evidence, improves handoffs, and makes it easier to detect accidental breakage later.
Quick Use
Documentation rule
A change is not complete until the reason and verification are recorded
The log should make sense to someone who was not watching your terminal. Record enough context that another teammate can continue the investigation without repeating the work.
Core log fields
Use the same structure for every important change
Time
Record when the finding was observed and when the change was made. Use one consistent time format throughout the round.
System
Identify the exact workstation, server, Linux host, switch, router, or forensic case involved.
Owner
Record which teammate investigated or changed the item so follow-up questions have a clear owner.
Finding
Describe the observed issue precisely instead of writing vague notes like 'fixed security problem.'
Evidence
Include commands, logs, paths, event IDs, usernames, PIDs, ports, ACL entries, hashes, or screenshots that support the finding.
Change
Record the exact command, setting, group membership, service state, ACL edit, or file change that was made.
Reason
Explain why the change was justified by the mission and evidence.
Verification
Record the exact check that confirmed the remediation worked and required functionality still works.
Follow-up
Record unresolved questions, dependencies, or items that another teammate needs to revisit.
Evidence categories
Capture the details that make a finding reproducible
Identity evidence
Service evidence
Process evidence
Persistence evidence
Network evidence
File evidence
Documentation workflow
Observe, preserve, change, verify, record
Observe
Record the current state before changing it. Capture commands, output, paths, accounts, PIDs, ports, or configuration that prove the finding.
Classify
Decide whether the item is required, suspicious, unnecessary, broken, or unresolved.
Preserve
Save the evidence that could disappear after remediation, especially logs, hashes, task details, service state, and network context.
Change
Make the smallest justified correction instead of broad cleanup.
Verify
Repeat the relevant check and confirm the mission-required function still works.
Record
Complete the log entry so another teammate can understand exactly what happened.
Strong notes
Replace vague statements with evidence-supported entries
Too vague
Bad admin account removed.
Better
User 'tempadmin' was present in local Administrators but absent from the approved roster. Security log showed recent privileged logon. Removed tempadmin from Administrators and verified approved admin access remained functional.
Too vague
Suspicious service disabled.
Better
Service 'UpdaterHelper' ran from C:\Temp\updater.exe under LocalSystem and listened on TCP 8089. Recorded path, PID, service account, listener, and install event before disabling the service.
Too vague
Fixed trunk.
Better
VLAN 20 was required on the SW1-R1 trunk but was missing from the allowed VLAN list. Added VLAN 20 only and verified student VLAN reachability afterward.
Too vague
Linux user fixed.
Better
User alex was approved but had unexpected NOPASSWD sudo. Removed only the broad sudoers rule and verified required nonprivileged access still worked.
Quick capture
Useful commands for evidence context
Windows
Get-Date
hostname
whoami
Get-FileHash <Path> -Algorithm SHA256
Linux
date
hostname
whoami
sha256sum <path>
Cisco
show clock
show running-config
show logging
show archive log config all
Team handoff
Every handoff should answer six questions
What was found
What evidence supports it
What was changed
What still needs attention
What must not be broken
What should be verified next
Common documentation mistakes
Avoid notes that cannot be verified later
Writing only the final fix and not the original evidence.
Recording 'fixed' without the exact command or setting changed.
Not writing down which teammate made the change.
Failing to record whether required functionality still worked afterward.
Keeping important evidence only in terminal scrollback.
Using vague labels like suspicious, bad, weird, or hacked without describing the actual observation.
Forgetting to record time and system name.
Deleting or disabling something before capturing the evidence needed to explain it.
Evidence & Change Log final checklist
Finish with a record the whole team can trust
A shared change log was created before major remediation began.
Each high-impact finding includes system, owner, evidence, and time.
Every major change includes the exact command or setting changed.
The reason for each major change is tied to mission requirements or evidence.
Verification results are recorded after remediation.
Important hashes, paths, event IDs, PIDs, ports, and configuration details are preserved.
Observation and interpretation are clearly separated.
Unresolved findings are marked as unresolved instead of guessed.
Platform handoffs include status, open questions, and next verification steps.
The team can reconstruct what changed during the round from the log alone.