EEssential SkillsGeneral

Taking Notes During Engagements

Foundationsbeginner12 min

Learn to take structured, real-time engagement notes that support reporting, evidence review, and team collaboration. Covers what to capture, when to capture it, and how to keep notes useful without turning them into unstructured command dumps.

Theory

Skill Goal

Take real-time engagement notes that are structured enough to support report writing, timestamped enough to reconstruct a timeline, and clear enough that a teammate who was not present could understand what happened and why.

Why It Matters

Every downstream deliverable in a security engagement depends on the quality of your notes. Reports, debriefs, evidence packages, and timeline reconstructions are only as good as what you wrote down while the work was happening. Trying to reconstruct an engagement from memory — even a few hours later — introduces gaps, inaccuracies, and missing context that weaken every artifact built on top of it.

Note-taking is also the skill that scales the least intuitively. On a short engagement, you might get away with messy notes. On a two-week engagement with multiple testers, a pivoting attack chain, and a client expecting a detailed timeline, undisciplined notes become an expensive liability.

Key Concepts

Notes must be taken in real time during execution — reconstructing from memory after the fact loses context, timing, and decision rationale that you will need later

Communication

Interview Answer

When asked about your engagement methodology or workflow, being able to describe your documentation practice signals professionalism.

The key differentiator is showing that you treat notes as a first-class work product, not an afterthought. A good response:I take timestamped notes in real time throughout the engagement. Every action gets a timestamp, the command or step, and a note on why I chose that approach and what the result was. I tag findings as I discover them and reference screenshots inline so nothing gets orphaned. At the end of each phase I write a brief status summary. The goal is that anyone on the team could pick up my notes and know exactly where the engagement stands without asking me.

Common Weak Answers

Waiting until after a testing phase to write notes — even thirty minutes of delay causes you to forget decision context, exact timing, and small observations that matter during reporting

Study Kit

Every note entry needs a timestamp — without timestamps, you cannot reconstruct the engagement timeline, correlate your actions with defender logs, or prove when something happened

Separate what you observed from what you ran from what you concluded — mixing raw output, commands, and interpretation in the same block makes notes impossible to review cleanly later

Notes are team artifacts, not personal journals — write them so a teammate joining the engagement midway could pick them up and understand the current state without asking you to explain

Capture the why alongside the what — recording that you ran a command is far less useful than recording why you chose that approach, what you expected, and what the result told you

Recommended Workflow

1.Set up your note structure before the engagement begins. Create sections for each major activity area. You should never be deciding where to write something while actively testing.
2.Log each action with a timestamp as you work. Record the command or step you took, and a one-line note on why you took it and what the result was.
3.Tag significant discoveries clearly. When you find a vulnerability, an access path, or a credential, mark it so you can find it during report writing without re-reading every line.
4.Reference screenshots and saved output in your notes immediately. Add a descriptive label when you capture them. Orphaned screenshots with no context are almost worthless during reporting.
5.Write a brief status summary at natural breakpoints. At the end of a testing phase, before pivoting to a new target, or at end of day, note what you accomplished, what is still open, and what you plan to do next.
6.Note why when you change your approach or abandon a path. This context is valuable for reporting and for the next tester who might revisit the same target.

Strong vs Weak Execution

Strong engagement notes read like a structured log of decisions. Each entry has a timestamp. Commands and their output are recorded alongside a brief note explaining intent: 14:32 — Ran BloodHound collection against acme.local. Looking for shortest path from current user to Domain Admins. Result: found a three-hop path through the ITSupport group via WriteDACL on the AdminSDHolder object. Findings are tagged. Screenshots are referenced with descriptive names. Status summaries appear at natural breakpoints. A teammate picking up these notes would know exactly where the engagement stands.

Weak engagement notes read like a terminal history pasted into a text file. Commands appear without timestamps, without context, and without results. There is no separation between what was run, what was observed, and what it means. When a significant finding appears, it is buried in a wall of undifferentiated text. Screenshots exist somewhere on the filesystem but are not referenced. The clearest sign of weak notes is that even the person who wrote them struggles to reconstruct what happened two days later.

The practical test: could you hand your notes to a teammate at the end of the day and have them write an accurate status report without calling you? If the answer is no, your notes are not structured enough.

Common Mistakes

Waiting until after a testing phase to write notes — even thirty minutes of delay causes you to forget decision context, exact timing, and small observations that matter during reporting
Dumping raw terminal output into notes without annotation — a page of Nmap output or BloodHound queries with no explanation of what you were looking for or what you found is noise, not documentation
Writing notes in personal shorthand that only you can decode — abbreviations, inside references, and unnamed screenshots become meaningless to anyone else and often to you after enough time passes
Capturing commands but not decisions — knowing that you ran crackmapexec tells the reader nothing; knowing that you chose it because SMB signing was disabled and you needed to verify local admin access tells them everything

Quality Bar

A teammate who was not on the engagement should be able to read your notes, reconstruct the timeline, identify every finding, and understand why you made the decisions you made — without asking you a single question.

What Good Output Looks Like

Engagement Notes — ACME Corp Internal Pentest — 2026-03-15

Phase: Internal Network — Initial Enumeration

09:15— Started from WS-JSMITH (10.10.14.22). Domain user context:jsmith@acme.local. Running initial domain enumeration to map attack surface before targeting specific systems.

09:18— Ran BloodHound collection (SharpHound, all collection methods). Looking for shortest paths to Domain Admins and high-value targets. Output saved:evidence/bloodhound/acme_collection_20260315.zip

09:31— BloodHound analysis complete. Key finding:svc_backup account has DCSync rights via membership in a nested group chain. The account also has an SPN registered, making it Kerberoastable. [FINDING-01: Kerberoastable service account with DCSync rights]

09:35— Requested TGS forsvc_backupSPN. Ticket saved toevidence/kerberoast/svc_backup.kirbi. Sending to offline cracking. Chose to target only this account rather than bulk-requesting all SPNs — environment has Kerberos logging enabled and bulk requests would likely trigger an alert.

09:42 — While waiting on crack results, checking domain password policy to evaluate spray viability. Policy: 5 attempts, 30-min lockout, 8-char minimum with complexity. Spray is viable at 1 attempt per 35 minutes.

10:15— Crack succeeded:svc_backuppassword isBackup2024!. Testing access.

10:18— Confirmed:svc_backuphas local admin onFS01(10.10.14.50) via SMB. Screenshot saved:evidence/screenshots/svc_backup_admin_fileserver.png

--- Status Summary — End of Morning Session

Completed: Initial enumeration, BloodHound analysis, Kerberoasting of svc_backup. Have local admin on FS01.

Open: Need to test DCSync rights for svc_backup. Password spray queued as fallback if DCSync path does not work.

Next: Attempt DCSync from FS01 using svc_backup credentials.

Practice Prompt

Run a short practice session in your lab — even fifteen minutes of enumeration is enough. Take notes using the structure from this lesson: timestamp every action, annotate every command with intent and result, tag anything significant, and reference any saved output. At the end, read your notes as if you were a teammate who was not there. Can you reconstruct what happened, what was found, and what the next steps are? If anything is unclear, that is the gap to close.

Dumping raw terminal output into notes without annotation

— a page of Nmap output or BloodHound queries with no explanation of what you were looking for or what you found is noise, not documentation

Writing notes in personal shorthand that only you can decode — abbreviations, inside references, and unnamed screenshots become meaningless to anyone else and often to you after enough time passes

Capturing commands but not decisions — knowing that you ran crackmapexec tells the reader nothing; knowing that you chose it because SMB signing was disabled and you needed to verify local admin access tells them everything

Likely Follow-Up Questions

You are testing a complex multi-host attack chain and need to move fast before a maintenance window closes. How do you balance speed with note-taking discipline?
A teammate asks to take over your portion of the engagement while you handle a different target. What do your notes need to contain for the handoff to work cleanly?
After the engagement, you discover that a finding you reported cannot be reproduced using your notes alone. What went wrong and how do you prevent it next time?