For a solo practice lab, start with local Markdown, one note per target, and an evidence folder linked by stable IDs. Use Obsidian if you want a searchable interface around those files. Choose a cloud workspace only when the lab or engagement permits that storage and you have checked access, export, and backup behavior. A terminal transcript supports the notebook; it does not replace your explanation.
The useful test for note-taking systems for pentesting is simple: can you resume a permitted task, locate the original evidence, and explain what it proves? Jump to the copyable template, the failure checks, or the OSCP and AI rules.
Use the examples only in independently authorized practice environments. Keep actual exam questions, machine details, reports, and evidence private. This is an independent documentation workflow, not an official exam template or a claim of hands-on testing.
On this page
Table of Contents
Choose note-taking systems for your environment
- Local, individual lab: Markdown keeps notes in ordinary text files. Obsidian can organize a local vault; its storage documentation explains that model. Keep attachments with the record and use relative links where your editor supports them.
- Shared, approved work: a workspace such as Notion can organize records for authorized collaborators. Confirm who can read, invite, export, or publish content before storing sensitive material. Its export guide describes Markdown, CSV, HTML, and PDF options and their limitations.
- Existing OneNote or another notebook: keep it if it meets your permission, retrieval, offline-access, and export needs. Test one representative record instead of moving an entire collection for a cosmetic benefit.
- Terminal-heavy workflow: save relevant command output to evidence files, then link it from a short narrative. Scrollback can disappear and a transcript rarely records why you chose the next action.
Before committing to an app, create a harmless sample with a heading, code block, image, and attachment. Close and reopen it, find it by lab ID, and inspect an exported copy. If offline access matters, test the downloaded record without a connection before the session. App choice alone does not establish confidentiality or exam permission.
Copy this independent lab-note template
Copy this blank outline into one note per independently authorized target. Replace placeholders only with observations you actually made. Keep a separate shared index for the lab scope and a restricted store for secrets; record a reference to that store rather than a password in the note.
AUTHORIZED PRACTICE LAB — [lab ID]
Owner / permission / sharing rules:
Date and timezone:
Target / version / network boundary:
Objective and stop conditions:
OBSERVATION — [evidence ID]
Question being checked:
Starting state / prerequisites:
Actual command or action:
Observed result:
Original evidence file:
Interpretation and limitations:
Status: confirmed / unconfirmed / blocked
Next permitted action:
SESSION HANDOFF
What changed:
What remains unknown:
Where to resume:
Backup and restore check:
REPORT EXPORT
Evidence IDs included:
Redaction and recipient checks:
Export filename / version:An evidence ID such as LAB-A-03 should appear both beside the claim and in the filename. Use a neutral name such as LAB-A-03-service-output.txt. Record the capture time and timezone inside the note or evidence index; do not rely only on a filename or the filesystem modification time.
Use the record during an authorized lab
- Before starting: write the permitted target, network boundary, objective, and stop conditions. For a legacy Kioptrix VM, use an isolated lab you control; a snapshot is a recovery aid, not network isolation.
- During the session: record the question, prerequisites, exact action, meaningful output, and interpretation together. Include tool versions and relevant options when they affect reproducibility. Do not add an attack command merely to fill the template.
- At a dead end: capture the actual error and the conditions in which it occurred. Mark the hypothesis unconfirmed or blocked. A failed connection does not establish that a service is secure or a vulnerability absent.
- Before stopping: leave a resume point: the last confirmed fact, the missing evidence, and the next permitted check. Note any lab reset or configuration change that makes earlier output unsuitable for comparison.
Illustrative example, not a performed test: a lab note might say “The service returned an authentication error; evidence LAB-A-03. Access to the protected resource was not established.” It should not turn that error into “access control is secure.” The limitation tells the next reader what still needs checking.
Capture evidence that supports the claim
Capture enough context to connect the result to the correct target and action. Preserve original output separately from selected excerpts. A screenshot is useful when it shows a state that text alone cannot convey, but it should remain legible at the size used in your report.
- Identify the target, relevant service or interface, time, and starting permissions. Keep unrelated personal or client information outside the capture when possible.
- Link each important result to its command or action and evidence ID. Label hypotheses separately from confirmed observations.
- Keep the original intact. Create a separate redacted derivative only when sharing that material is authorized; inspect the exported file for hidden text, metadata, and attachments.
- For an actual exam, use the current official evidence requirements. This generic lab checklist does not replace OffSec’s proof screenshots, control-panel steps, or submission instructions.
Do not invent missing output, recreate a success screenshot from memory, or treat a tool’s label as proof. If the record cannot support a claim, narrow the claim or mark the result inconclusive.
Verify retrieval and handle missing evidence
Keep a short index containing lab ID, objective, status, and links to the note and evidence folder. Use a small set of descriptive tags, such as the service and the investigation stage. Avoid putting passwords, tokens, or sensitive host details in titles, tags, or filenames.
- Cannot find a result: search for the evidence ID. If it exists only in a screenshot name, add the missing reference to the narrative.
- Attachment opens only on one computer: check whether the link depends on an absolute local path or an authenticated cloud URL. Package the permitted attachment with an export and test it in a separate folder.
- Result cannot be reproduced: compare target identity, version, route, account permissions, and starting state. Record the mismatch before any further authorized check.
- Evidence is missing: mark the claim unsupported. Recapture only if the lab remains available and the action is still permitted; otherwise explain the limitation.
- Export is incomplete: open the exported file itself and inspect code wrapping, images, links, and attachments. An export notification is not a content check.
A practical rehearsal is to close the notebook, reopen one record, and explain the result using only its saved evidence. Fix the first missing prerequisite or broken link you encounter. The number of completed boxes or pages of notes does not establish exam readiness.
Protect notes, secrets, and backups
Treat credentials, hashes, tokens, private configuration, and client data as sensitive even when they appear in a lab transcript. Minimize collection and keep necessary secrets in an approved restricted store. A private Git repository is not a secrets vault: committed content can remain in history and clones after a file is edited.
- Protect the working device and sensitive backups with appropriate encryption and access controls. Encryption at rest does not protect an unlocked session or prevent an authorized app from reading an open file.
- Use only approved storage and sync providers. Review shared links and collaborators, and keep public publishing disabled for restricted material. Local storage is not automatically secure either.
- Keep a recoverable backup separate from the live sync copy. Sync can propagate mistakes and deletions; Obsidian’s backup guidance explicitly distinguishes syncing from backups.
- Test restoration with a harmless sample and document the result. Follow the owner’s retention and deletion requirements for notes, exports, working copies, and backups.
If sensitive material was shared accidentally, stop further sharing and follow the owner’s incident process. Removing a link or deleting a commit may not remove existing copies. Do not promise that redaction or deletion has undone disclosure.
Turn a lab record into a report
Build a report from the confirmed record: scope, prerequisites, reproducible actions, evidence, impact supported by that evidence, limitations, and remediation. Use the report-template and evidence checks when you are ready to turn an independent practice record into a structured document.
After an authorized fix, keep the original finding ID and document the changed conditions. The vulnerability retesting checklist helps distinguish a verified fix, a mitigation, and an inconclusive result. Do not close a finding solely because a later tool run produced no alert.
For a public portfolio, create a fresh report from an independent lab whose owner permits publication. Do not reuse actual exam content or restricted course-lab material, even with names, IP addresses, and proof values removed. Share only with the recipients and through the channels authorized for that material.
OSCP notes, cloud tools, and AI: common questions
Can I use my notes during the OSCP+ exam? The official FAQ permits notes and specified online resources, with activity on the proctored host. It also prohibits chatbots during both the exam and reporting phase. Recheck the current rules before your attempt.
Are Notion, cloud storage, and AI features all treated the same? No. OffSec’s AI policy distinguishes prohibited interactive chatbot or LLM assistance from some non-interactive features, such as note organization, subject to its academic rules. That is not blanket permission to send restricted material to a provider. OffSec’s terms also prohibit inputting its materials, labs, exams, or exam-related materials into third-party AI services. Confirm an uncertain workflow with OffSec before the exam; keep a usable local copy and avoid prompting AI with protected content.
Can I publish a sanitized exam report? No. OffSec’s confidentiality terms cover information in exam reports and restricted lab material, not only identifying details. Use a separately created, shareable practice lab for public examples. Do not upload actual exam evidence to an AI service for rewriting, checking, or redaction.
Does a long notebook or a fixed number of labs mean I am ready? No. Check whether you can explain and reproduce your authorized work, recover the evidence, and export a readable report. These checks reveal documentation gaps; they do not predict a score or guarantee certification.
The existing videos are retained as optional background. They do not replace the current written rules or establish the author’s exam experience.
If an embedded player is unavailable, open the original first video on YouTube or second video on YouTube.
Sources and a practical next step
Sources reviewed October 9, 2026: the linked OffSec exam FAQ, AI policy, terms, and OSCP+ Exam Guide, plus the linked Obsidian and Notion documentation. This revision is based on document review; no scan, exploitation, or hands-on product test was performed.
For your next authorized practice session, copy the blank template, record one real observation, and check its evidence link and export. Keep the system only as elaborate as needed to resume the work and support the report.