Common Mistakes · Guide 09 · Evidence & Documentation
Evidence & Documentation Mistakes
Good technical work can still become unreliable if the team cannot explain what was found, what evidence supported it, what changed, and whether the system still worked afterward.
Documentation should reduce duplicate work, protect evidence, support handoffs, and make the team's decisions reproducible.
Quick Use
Documentation rule
A teammate should be able to trust your notes without repeating your work
Strong notes preserve the original condition, support the finding with evidence, record the exact change, and show how the team verified the result.
10 documentation mistakes
What goes wrong and the safer replacement
Writing vague notes like 'fixed' or 'secured'
What goes wrong
A change log entry may say only that an issue was fixed without recording the original state, evidence, exact change, or verification.
Why it hurts
Another teammate cannot reproduce the work, confirm what changed, or tell whether the issue is actually resolved.
Stronger replacement
Record the finding, supporting evidence, exact remediation, reason, verification, and any unresolved follow-up.
Documenting only after the round is nearly over
What goes wrong
Teams may postpone notes until the end because they want to keep moving.
Why it hurts
Commands, paths, event IDs, timestamps, reasons, and unresolved questions are forgotten.
Stronger replacement
Update the shared log while the context is still fresh, especially after high-impact findings and changes.
Failing to capture the original state
What goes wrong
The team may record what was changed but not what existed before remediation.
Why it hurts
It becomes difficult to prove the change was justified or reconstruct the original condition.
Stronger replacement
Record the before state first: account membership, service state, path, listener, ACL entry, file hash, configuration, or relevant log evidence.
Keeping evidence only in terminal scrollback
What goes wrong
Important commands and output may be visible temporarily but never copied into notes or exported.
Why it hurts
The evidence can disappear when the terminal closes, scrolls, reconnects, or the system changes.
Stronger replacement
Save the key output, screenshots, hashes, paths, event IDs, or configuration snippets that support the finding.
Recording a conclusion without the evidence
What goes wrong
A note may state that a user was unauthorized, a service was suspicious, or an ACL was wrong without showing why.
Why it hurts
The team cannot distinguish a justified finding from an assumption.
Stronger replacement
Tie every major conclusion to the mission, logs, configuration, or observed behavior that supports it.
Failing to record verification
What goes wrong
The team logs the change but not whether required functionality still worked afterward.
Why it hurts
A hidden regression may remain until much later in the round.
Stronger replacement
Record the verification step and the result for every high-impact remediation.
Mixing observation and interpretation
What goes wrong
Notes may describe assumptions as facts, especially during forensic or suspicious-activity investigations.
Why it hurts
Later decisions can be based on a story that the evidence never actually proved.
Stronger replacement
Write the observed fact first, then separately record the interpretation and confidence level.
Forgetting system, owner, or time
What goes wrong
A log entry may describe a finding but omit which host, network device, teammate, or time it belongs to.
Why it hurts
The team may duplicate work, confuse evidence across systems, or lose accountability for follow-up.
Stronger replacement
Use consistent fields for time, system, owner, finding, evidence, change, verification, and next step.
Not recording unresolved questions
What goes wrong
Teams may document only completed work and leave uncertain findings in memory.
Why it hurts
Important open issues can disappear during handoffs or be mistaken for resolved items.
Stronger replacement
Mark unresolved findings clearly, assign an owner when appropriate, and state the safest next verification step.
Letting teammates maintain separate private notes
What goes wrong
Each person may track changes independently without a shared team view.
Why it hurts
The team can make conflicting changes, repeat investigations, and miss dependencies.
Stronger replacement
Use a shared change log or a clearly synchronized handoff process so the team has one trusted operational record.
Core log fields
Use the same structure for important work
Time
Shows when the finding and change occurred and supports timeline reconstruction.
System
Identifies the exact workstation, server, Linux host, switch, router, or case.
Owner
Shows who investigated or changed the item and who can answer follow-up questions.
Finding
Describes the observed issue precisely.
Evidence
Connects the conclusion to logs, paths, hashes, event IDs, configuration, users, PIDs, ports, or other artifacts.
Change
Records the exact command, setting, membership, service state, ACL edit, or file change.
Reason
Explains why the change was justified by the mission or evidence.
Verification
Shows that the security result and required functionality were both rechecked.
Follow-up
Preserves unresolved questions, dependencies, or next actions.
Strong notes
Replace vague statements with evidence-supported entries
Too vague
Removed bad admin.
Better
User tempadmin was in local Administrators but absent from the approved roster. Security logs showed recent privileged use. Removed tempadmin from Administrators and verified approved admin access still worked.
Too vague
Disabled suspicious service.
Better
Service UpdaterHelper ran from C:\Temp\updater.exe under LocalSystem and listened on TCP 8089. Recorded service path, PID, account, listener, and install evidence before disabling it.
Too vague
Fixed VLAN.
Better
VLAN 20 was required on the SW1-R1 trunk but missing from the allowed list. Added VLAN 20 only and verified required reachability afterward.
Too vague
Linux permissions fixed.
Better
Found /srv/app/config.sh world-writable. Confirmed expected owner and service dependency, changed only the incorrect mode, then verified the application still started.
Evidence examples
Capture the details that make a finding reproducible
Full file path
SHA-256 hash
Event ID
PID / parent PID
Service name and account
Listening port and owning process
Username and group membership
ACL entry and direction
Route or VLAN state
Exact command used
Screenshot or exported output
Timestamp and time-zone context
Team handoff
Every handoff should answer six questions
What was found?
What evidence supports it?
What was changed?
What required function was verified?
What remains unresolved?
What should the next teammate check or avoid changing?
Weak habit vs better habit
Replace vague notes with operational records
Weak habit
Fixed account issue.
Better habit
Record the account, original privilege, supporting evidence, exact change, and access verification.
Weak habit
Saved screenshot, no notes needed.
Better habit
Keep the screenshot but also record system, time, context, and what the screenshot proves.
Weak habit
We can write the log at the end.
Better habit
Document major findings and changes while the details are still fresh.
Weak habit
Everyone can keep their own notes.
Better habit
Use one shared operational record or synchronized handoff process.
Weak habit
The change command completed successfully.
Better habit
Record the command and then verify the intended security result plus required functionality.
Weak habit
This proves the account was compromised.
Better habit
Record the observed login evidence first, then state the interpretation and confidence separately.
Verification
Check whether the documentation is actually useful
Can another teammate understand the finding without repeating the investigation?
Does every major change include the original state?
Is the supporting evidence preserved?
Is the exact remediation recorded?
Is the reason for the change clear?
Is required functionality verification recorded?
Are unresolved findings clearly marked?
Does every important entry identify system, owner, and time?
Evidence & Documentation final checklist
Leave a record the whole team can trust
The team used a shared change log or synchronized handoff process.
Major findings include system, owner, and time.
The original state was recorded before high-impact remediation.
Evidence was preserved outside temporary terminal scrollback.
Major conclusions are tied to specific evidence.
The exact remediation was recorded.
The reason for each major change is clear.
Verification results were documented after high-impact changes.
Observation and interpretation were kept separate where needed.
Unresolved questions were explicitly recorded.
Handoffs include status, evidence, changes, and next actions.
Another teammate could reconstruct the important work from the notes alone.