Step 313. OSCP Retrospective & Next Plan — What to Do Before the Results Come Out

Level 4 — OSCP Preparation & Exam | Difficulty ★★★☆☆ | Estimated time: 1–2 days (half a day of retrospective writing + next-plan design)

Prerequisites: Step 312’s practical exam attempt and report submission are complete. Your exam result does not need to be out yet — in fact, now, before it arrives, is the perfect time.

What you need: the exam-day lab log and score-assessment records, the strategy-finalization document, and Python 3 (the retrospective-skeleton generator). The retrospective examples in this chapter are output examples — replace them with your own actual exam records.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Sharing exam content externally while writing your retrospective may violate the NDA (non-disclosure agreement) — your retrospective is for personal safekeeping, and the specifics of exam problems must not be made public.
This is a concept chapter — it designs the retrospective method that turns exam experience into an asset, and the next routes for both pass and fail outcomes.

Exam results take a few days to arrive. Those few days are this chapter’s stage. Pass or fail, the experience of 24 real hours is an asset money can’t buy — but only if it’s recorded. As the prompt warned, passing tempts you to skip the retrospective out of relief, and failing out of loss. Both end the same way — a blurry memory two weeks later.

Today’s rule is one — whatever the outcome, you write it within 72 hours. Because the resolution of memory is completely different. That judgment call at hour 14 of the exam can be written as sentences now; a month from now it has shrunk to "I think something blocked me."

1. Learning Objectives

By the end of this chapter, you will be able to:

Reconstruct the exam’s hour-by-hour timeline (what you solved when, and where you got stuck)
Turn the strategies that worked, the ones that failed, technical findings, and condition-management lessons into a retrospective document as an asset
Design the pass scenario’s next route (portfolio reflection, the next challenge)
Design the fail scenario’s next route (failure analysis → remediation → retake schedule)
Reflect exam-verified content in the penetration playbook to keep your training assets current

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Markdown (retrospective document), Python 3 (`retro.py` retrospective-skeleton generator), the exam-day lab log
Today’s command	`python retro.py "2026-09-08 21:00"` — deadline calculation from the end time + template generation
Concepts needed	The 72-hour retrospective, timeline reconstruction, the pass/fail dual route, what a certification means and its limits
Today’s deliverable	1 exam retrospective document + 1 next-plan document + an updated penetration playbook

2-1. Why 72 Hours — Memory Gets Down-Saved Every Day

Right after the exam, memory comes in three kinds.

Kind of memory	Content	Lifespan
Event memory	What you solved at what time	Relatively long — already secured in the lab log
Judgment memory	Why you chose that path, and why you abandoned it	Days — whatever isn’t in the log soon evaporates
Sensory memory	The texture of panic, the hunch right before a breakthrough	Days to weeks — fades fastest and is the least reproducible

The lab log secured only the first kind. What the retrospective writes is the second and third — "why did I do that then" and "how did it feel then." Only with those two does a retrospective become not a record but a training asset. It’s a document the future you — whether for a retake or a different exam — will read.

2-2. The Structure of a Retrospective — Four Boxes

The retrospective document divides into four boxes. Each box is one kind of asset.

Hour-by-hour timeline — what you solved when and where you got stuck. The base is re-laying the lab log onto a time axis, overlaid with judgment memory ("the reason I postponed AD at this point").
Strategy accounting — strategies that worked / strategies that failed. The work of attaching ✅/❌ to each line of the strategy-finalization document. Things you believed were verified but that didn’t work in the real exam surface here.
Technical retrospective — the paths of solved machines, the estimated paths of unsolved machines, what you newly learned during the exam. For unsolved machines, there is no walkthrough now that the exam is over, so you record them as estimates — write down the grounds for each estimate, and it becomes the study list for retake preparation.
Condition accounting — the effect of sleep and meals on your score. If a correlation like "I solved the escalation within 90 minutes of waking" is visible, it becomes an operating rule for the next 24-hour job — exam or project.

2-3. The Next Route on a Pass — A Certification Is an Admission Ticket

When you pass, there are three branches of work.

Pass route:
1. Portfolio reflection — reflect the credential in your resume, LinkedIn, blog,
   but do not disclose the exam content itself (NDA — non-disclosure agreement)
   What you may write: "I passed", "the preparation process", "training methodology"
   What you may not: the exam machines' content, the specific solutions to problems
2. Define "me after OSCP" — decide the next direction by distinguishing what the
   credential proves (fundamental hands-on penetration skills) from what it
   does not prove (depth of expertise)
3. Choose the next growth axis — e.g., bug bounty (real-world web), an advanced
   certification (e.g., the OSEP line), competition focus (CTF), or team activities

Getting the certification’s meaning exactly right matters. OSCP is certified evidence that "alone, within a time limit, you can penetrate a system you’ve never seen and document it" — that is a big thing. At the same time, it is an admission ticket, not a destination. Real work is broader (cloud, mobile, code audit), deeper (evasion, stealth, chain design), and slower (a real penetration test is a weeks-long project). That’s why the plan after passing must be "which axis do I build on the proven foundation."

2-4. The Next Route on a Fail — Retaking Is a Common Path

If you failed, the first sentence is fixed — retaking is common and nothing to be ashamed of. A 24-hour practical has so many variables that passing on the first attempt is rather the rarer case. What matters is not ending the failure as "emotion" but converting it into a "blueprint."

Fail route (order fixed):
1. Give emotions 1–2 days — the retrospective comes after. Feeling upset is normal
2. Failure-type analysis — Step 310's five categories as-is: skill/enumeration/time/stamina/report
3. Remediation plan — a prescription per type + a deadline. A weekly plan until the retake
4. Fix the retake date — not "decide once I see how I feel"; put a date on it
5. Resume training — the remediation list first, plus 1–2 more mock exams

The core is #4 — fix the retake date immediately. A "someday again" without a date mostly never comes. And you already know this route’s whole structure — the very procedure for handling a mock-exam failure from Steps 310–311 works identically on the real exam.

3. Follow Along

3-1. Generating the Retrospective Skeleton — Calculate the Deadline First

Use the chapter’s tool to build the retrospective document’s skeleton and the deadline. Pass the exam end time as the argument. Measured result.

python retro.py "2026-09-08 21:00"

Exam end        : 2026-09-08 21:00
Retro deadline  : 2026-09-11 21:00  (72 hours — memory resolution differs)
Template created: retro_20260908.md

--- Generated skeleton preview (first 12 lines) ---
  # OSCP Exam Retrospective — 2026-09-08

  ## 1. Hour-by-Hour Timeline
  - 00:00~03:00  (what you solved, where you got stuck)
  - 03:00~06:00
  - 06:00~12:00
  - 12:00~18:00
  - 18:00~24:00

  ## 2. Strategies That Worked / Strategies That Failed
  - Worked:
  - Failed:

How to read it: the first thing the tool gives you is not the template but the deadline. A retrospective is never written "when there’s time," so pinning a deadline on the calendar is half the retrospective. The skeleton’s blanks are intentional — blank boxes make you start writing.

3-2. Reconstructing the Timeline — Overlay Judgment on the Log

Spread the lab log on a time axis and add "the judgment of that moment" to each segment.

Screen example (part of a reconstructed timeline):

00:00~03:00  Parallel recon → started Independent 1. Finished at 02:40 (20 pts).
             Judgment: "easy things first" per the finalized doc — early points
             secured my psychology ✅
03:00~08:00  AD set. Credentials at 05:10, finished at 08:20 (40 pts).
             Judgment: the checklist's AS-REP item was the answer. No impatience
             thanks to the 4-hour cap rule ✅
08:00~14:00  3 hours stuck on Independent 2 — circling web paths. Decided to
             postpone at 11:00.
             Judgment: postponing was right but 30 minutes late — the cap alarm
             was on the desk and I forgot to re-arm it after a bathroom break
             ❌ → next time, the alarm goes on two channels: sound + vibration
14:00~19:00  Slept 4 hours 40 minutes. Broke through Independent 2's
             escalation within 90 minutes of waking.
             Judgment: sleep's recovery effect confirmed in data ✅

How to read it: the ❌ items are this document’s value — the event "I turned off the alarm" is not in the lab log and will be forgotten in a week. Details like this become the next 24 hours’ operational improvements. Correlations like "breakthrough within 90 minutes of sleep" are also visible only in this table.

3-3. The Next-Plan Document — Write Two Copies Before the Result

Right now, while waiting for the result, write both the pass plan and the fail plan. So that whichever it is, you don’t freeze on announcement day with "so what do I do now."

Next-plan document (two-box structure):

[Plan A — if passed]
- This week: reflect the credential (resume/profile), decide the sharing scope of the news
- This month: define "me after OSCP" — pick 1 next growth axis + a 3-month plan
- Ongoing: keep the playbook current, attack at least 1 machine a week (keep the feel)

[Plan B — if failed]
- Days 1–2: rest (planned rest)
- Day 3: failure-type analysis (Step 310 procedure)
- Within 1 week: remediation plan + retake date fixed
- Until the retake: work through the remediation list + 1–2 mock exams

Why write both: a plan is not a function of the result but a precondition for it. A plan written after the announcement is written on emotion (elation or loss); a plan written before is written on data. Whichever plan becomes reality, you can move from the day after the announcement.

3-4. Reflecting in the Playbook — Keeping Training Assets Current

Finally, reflect what the exam verified into the penetration playbook built through Levels 3–4.

Examples of what to reflect:
- The command order "actually used in the real thing" — fix differences against
  the playbook's enumeration procedure
- Techniques newly learned during the exam — add to the relevant section with
  their source (exam experience)
- Procedures that didn't work — remove from the playbook or annotate "conditions"
- Operating rules — record the verified results of caps, sleep, evidence order
  at the playbook's front

With this, the playbook goes from "a practice document" to "a document that passed real-world verification." In the real work, competitions, or retakes ahead, this document is your first page as-is.

4. Missions & Exercises

Mission — The Retrospective Document and the Next Plan

Generate the retrospective skeleton with retro.py and pin the deadline (end + 72 hours) on your calendar.
Reconstruct the hour-by-hour timeline — overlay judgment memory and ✅/❌ onto the lab log.
Fill in the strategy accounting (worked/failed) and the technical retrospective (solved paths / estimated unsolved paths / newly learned).
Write the next-plan document in two boxes, pass and fail — the fail plan includes a "retake date fixed" item.
Reflect exam-verified content in the penetration playbook, and attach the list of reflected items to the end of the retrospective document.

Exercises

Exercise 1. Explain why the retrospective must be written "within 72 hours," connecting it to the lifespans of the three kinds of memory (event/judgment/sensory).

Exercise 2. Why write the next plan in two copies (Plan A/B) "before" the result announcement? How is it different from a plan written after?

Exercise 3. In the fail route, why is "immediate confirmation of the retake date" emphasized?

Exercise 4. Explain what "an admission ticket, not a destination" means about passing the OSCP, using the distinction between what the credential proves and what it does not.

5. Model Answers & Completion Criteria

Mission Model Answer

Verify with these criteria.

The deadline exists: was the retrospective completed within 72 hours of the end — if late, record that fact itself in the retrospective (state the memory loss explicitly).
The timeline’s double layer: does each time segment carry both the event (log) and the judgment (why) — events alone are a copy of the log, not a retrospective.
The ❌ exists: is at least one failed strategy or late judgment recorded — an all-✅ retrospective is beautified; rewrite it.
Both plans are concrete: do Plan A and Plan B each have a first action and a timing — "prepare hard" is not a plan.
Playbook-reflection traces: does a list of reflected items exist, and does an actual change exist in the playbook file?

Exercise Answers

Answer 1. Event memory is already externalized in the lab log, but judgment memory ("why I abandoned that path") fades within days, and sensory memory ("the texture of panic, the hunch before the breakthrough") fades first. 72 hours is the window in which those two still become sentences. The retrospective’s value lies in fixing the layers the log doesn’t have — judgment and sensation — into text, so a retrospective written after those layers evaporate is nothing more than a summary of the log. A retrospective written a month later shrinks to "something blocked and something worked," and nothing reaches the next exam’s me.

Answer 2. Because a pre-announcement plan is written on data, and a post-announcement plan on emotion. The elation right after a pass breeds an inflated next goal; the loss right after a fail breeds a shrunken one — both are drafts needing correction. With two plans written beforehand, whichever result arrives, execution follows a design from a calm moment. And the very act of writing "both" changes how you face the result — pass/fail stops being a fork of fate and becomes a junction of two prepared paths.

Answer 3. Because a resolution without a date gets eroded by time. A "decide once I see how I feel" retake usually keeps being postponed even after the loss fades, and while it’s postponed, the real-exam feel — the body memory of running 24 hours — cools quickly. Pin a date immediately and the remediation plan gets a deadline, and only a plan with a deadline gets executed week by week. That retaking is a common path is a comfort, but it’s also operational freedom — "a retake can be designed as part of the schedule."

Answer 4. What the OSCP proves is fundamental hands-on skill — "alone, within a time limit, you can penetrate an unfamiliar system and document it" — and that is the admission ticket that opens the doors of hiring and trust. What it does not prove is depth of expertise — broader domains like cloud, mobile, and code audit; deeper techniques like evasion, stealth, and chain design; and running real weeks-long projects are all outside the exam’s scope. Only with this distinction does the post-pass plan become honest — the next question is not "I’m done" but "which axis do I build on the proven foundation."

Completion Criteria Checklist

[ ] I completed the retrospective document by the 72-hour deadline from the end
[ ] The hour-by-hour timeline records both events and judgments (why)
[ ] Strategies that worked and strategies that failed (at least 1 ❌) are distinguished
[ ] I filled the technical retrospective (solved paths / estimated unsolved paths / newly learned)
[ ] I wrote the next plan for a pass (Plan A)
[ ] I wrote the next plan for a fail (Plan B — including a fixed retake date)
[ ] I recorded the condition-management lesson (the correlation between sleep/meals and score)
[ ] I reflected exam-verified content in the penetration playbook and left the list

6. Common Pitfalls & Fixes

Wall 1. I think I’ll pass / I think I failed, so I can’t bring myself to write the retrospective

Symptom: relief or loss turns it into "later."

Cause: exactly the point the prompt flagged — retrospective avoidance happens regardless of the result; only the emotion’s direction differs.

Fix: change the retrospective from "reflection" to "filling" — the work of filling the blanks of the skeleton retro.py made, from the top. Ten minutes per box and the draft is done within an hour. Emotions sort themselves out while you fill — a record is often an emotion’s drain.

Wall 2. I passed a time to retro.py and got an error

Symptom:

ValueError: time data '2026-09-08 9pm' does not match format '%Y-%m-%d %H:%M'

Cause: the tool only accepts 24-hour format (%Y-%m-%d %H:%M) — notations like "9pm" won’t parse.

Fix: enter in 24-hour format, like python retro.py "2026-09-08 21:00". If you omit the time it runs with an example time, so you must pass the actual end time for the deadline calculation to be correct.

Wall 3. My retrospective ended up containing specifics of the exam problems — can I share it?

Symptom: I want to write an "exam review" on my blog.

Cause: the exam content (machine composition, vulnerabilities, solutions) may be protected by the NDA — the agreement’s scope is defined by the documents you consented to at registration and the official guidance.

Fix: write in full detail in the personal-safekeeping retrospective, but separate principles for anything public — what you may write is the preparation process, training methodology, and operating strategy; you do not write identifiable content of the exam problems. When in doubt, the safe side is not publishing. What makes your retrospective valuable is not the problems but the record of judgments — methodology alone makes a perfectly good review.

Wall 4. I failed and I don’t know what was lacking — it feels like everything

Symptom: the deduction breakdown alone doesn’t show the cause.

Cause: the real exam has no walkthrough, so Step 310’s comparison procedure can’t be used as-is — which is why "estimation" is needed.

Fix: go back to the retrospective’s technical box — writing the "estimated path and its grounds" for unsolved machines is the real-exam version of walkthrough comparison. A machine you can’t even estimate is itself a signal of ① missing skill. And type analysis is done with the exam-day log — did you break the cap (③), did you unfold the checklist (②), did you sleep (④)? For the operational types, the answers are in the log.

Wall 5. I passed but can’t decide what’s next — bug bounty? Advanced cert? Competitions?

Symptom: too many options, so you freeze instead.

Cause: the axes prove different things — bug bounty proves real-world web and income, an advanced cert proves depth, competitions prove speed and teamwork.

Fix: reduce the criteria to one — "which stretch of the exam was the most fun." Find the time segment of deepest immersion in the retrospective’s timeline, and the axis that segment’s activity points to is the answer. If it was the web-penetration stretch, bug bounty; if it was the AD internal expansion, the advanced-cert line; if it was the time fight itself, competitions. Enjoyment is the most accurate predictor of sustainability.

7. Summary

Today’s Concepts

Concept	One-line explanation
72-hour retrospective	The window in which judgment/sensory memory still becomes sentences — after it, only a summary of the log remains
Three kinds of memory	Event (log) / judgment (days) / sensory (fades first) — the retrospective fixes the second and third
Timeline reconstruction	The work of overlaying "why" on the log — the ❌ items are the retrospective’s value
Dual plan (A/B)	Two copies before the announcement — designed on data, not emotion
Immediate retake confirmation	A "someday again" without a date mostly never comes
Certification = admission ticket	The distinction between what’s proven (fundamental hands-on) and what isn’t (depth) creates the next question

Today’s Commands & Documents

Command/document	What it does
`python retro.py "end time"`	Calculate the retrospective deadline (72 hours) + generate the skeleton
Retrospective document	4 boxes: timeline / strategy accounting / technical retrospective / condition accounting
Next-plan document	Pass plan and fail plan — two copies before the announcement
Penetration playbook	Where exam-verified content is reflected — from practice doc to field doc
NDA principle	Public goes as far as methodology — exam content stays personal

The Core Instinct

The exam isn’t over until the retrospective is. If the 24-hour attempt is the raw stone, the retrospective is the cutting — the same experience is worth several times more recorded than unrecorded. And whichever way the result goes, you have already proven something harder than the certification — that you are a person who can solve a 24-hour problem through operations. That ability gets reused beyond the exam, in every long project you’ll meet.

Once every box is checked, Step 313 is complete.