CREST CPSA Study Plan (2026): A Methodical 6-Week Path From Recon to Reporting

The CREST CPSA is not a memory test. It checks whether you can think like a junior penetration tester under time pressure, make sound choices, and explain what you are doing. That is why a good study plan should not be a random list of tools and topics. It should follow the same flow you would use in an assessment: recon, enumeration, analysis, exploitation thinking, and reporting. This 6-week plan is built around that idea. It gives you a methodical path from first contact with a target to writing clear findings. It also includes weekly timed practice, because knowing the material is not enough if you cannot apply it quickly and calmly.

What the CPSA really tests

Before building a plan, it helps to understand the exam’s shape. The CPSA focuses on practical penetration testing knowledge. You are expected to recognize common services, understand how attackers gather information, spot likely weaknesses, and choose sensible next steps. You also need basic reporting judgment. In other words, the exam rewards structured thinking.

Many candidates lose marks because they study topics in isolation. They memorize port numbers, web flaws, or command switches, but they do not practice the sequence. In a real test scenario, the sequence matters:

• Recon tells you what exists.

• Enumeration tells you how it behaves.

• Exploitation reasoning tells you what is worth testing and why.

• Reporting proves you understood the impact.

This study plan mirrors that flow so your preparation feels like real assessment work, not disconnected revision.

How to use this 6-week plan

Treat each week as a focused block with one main objective. Study for five or six days, then do one timed practice set. Keep notes in a single workbook or document. Split it into these sections:

• Commands and syntax

• Service-by-service enumeration notes

• Common vulnerability patterns

• Reporting phrases and finding structure

• Mistakes I made in timed practice

If you want a question bank for timed sessions, use a CREST CPSA practice test once per week. Do not just check the score. Review every wrong answer and write down why the correct option made more sense.

If you have a 6-week pentest planner, use it to schedule exact study blocks. That matters because vague plans fail. “Study web security this week” is weak. “Monday: HTTP methods and headers, Tuesday: auth flaws, Wednesday: input handling, Saturday: 50-minute timed set” is much stronger.

Week 1: Build the pentest workflow in your head

The first week is about structure. You are learning how an assessment unfolds and where each technique fits. This stops you from jumping straight into scans without a reason.

Focus on these areas:

• Assessment phases: scoping, passive recon, active recon, enumeration, vulnerability analysis, controlled exploitation, post-exploitation awareness, reporting.

• Rules of engagement: authorization, safe testing, evidence handling, and why scope matters.

• Common protocols and ports: not just the numbers, but what they usually indicate in practice.

• Tool purpose: what Nmap, Nikto, Burp Suite, dirb/gobuster, enum4linux, smbclient, and netcat are for.

Your goal is simple: for any discovered service, you should be able to answer, What would I do next, and why?

For example:

• If you see port 80 or 443, you think web enumeration, content discovery, headers, authentication, and input handling.

• If you see 21, you think anonymous access, banners, directory listing, weak credentials, file exposure.

• If you see 139/445, you think SMB shares, null sessions, user enumeration, and access control mistakes.

At the end of the week, do one short timed practice set. Limit yourself to 45 minutes. This is not about score. It is about learning how quickly you can map a finding to a likely testing path.

Week 2: Recon and enumeration routines

This week is where many candidates make the biggest gain. Enumeration is the engine of practical testing. If you do it well, the target starts to explain itself. If you do it badly, you miss easy findings and waste time.

Build routines by service. Do not study enumeration as one giant topic. Break it down.

For network recon, practice:

• Host discovery logic

• Port scanning choices and what different scan results suggest

• Service and version detection

• Banner grabbing

• Reading scan output without guessing

For service enumeration, drill these patterns:

• HTTP/HTTPS: titles, headers, methods, cookies, robots.txt, directory brute force, default pages, login forms, admin panels.

• FTP: anonymous login, writable locations, exposed backups, user listing clues.

• SMB: share access, permissions, naming conventions, user information leaks.

• SMTP: banners, user enumeration risk, mail relaying signs.

• DNS: zone transfer checks, records, host naming patterns.

• SSH: version awareness, credential testing logic, why brute force is usually a bad assumption unless permitted.

Make one-page checklists for each service. These are powerful because they reduce hesitation. In the exam, hesitation costs time.

Example of a good checklist for HTTP:

• Load page and inspect title/content

• Check response headers and server details

• Review robots.txt and common paths

• Test directory/file discovery

• Identify login points and error messages

• Look for parameters and user input locations

• Note session cookies and security flags

At the end of Week 2, do a timed set focused only on recon and enumeration. Review not just wrong answers, but slow answers. Slow often means your process is still unclear.

Week 3: Web exploitation reasoning, not just flaw names

The CPSA expects you to understand common web issues, but the stronger skill is reasoning from clues. A login form, verbose error, missing cookie flags, numeric IDs, or reflected input all point in different directions. This week is about learning to read those clues.

Study these areas carefully:

• Authentication weaknesses: default credentials, weak password policy, account enumeration, poor lockout design.

• Authorization problems: insecure direct object references, privilege separation mistakes, forced browsing.

• Input handling: SQL injection signs, command injection hints, reflected versus stored XSS indicators.

• Session security: predictable tokens, missing Secure/HttpOnly flags, poor logout handling.

• File handling: upload restrictions, path traversal clues, backup file exposure.

• Misconfiguration: directory listing, debug pages, default admin interfaces.

The key is to pair every flaw with a trigger and a consequence.

For example:

• If changing a numeric ID loads another user’s record, that suggests an authorization flaw because access control is missing on the server side.

• If an input breaks a query or changes page behavior after a quote mark, SQL injection becomes a reasonable next hypothesis because the application may be mixing data with a database command.

• If a cookie lacks the Secure flag on HTTPS, it matters because the browser might send it over an insecure channel in some conditions, increasing session theft risk.

This week, stop trying to memorize giant lists of web vulnerabilities. Instead, ask two questions for each scenario:

• What evidence points to this issue?

• What safer next test would confirm it?

Finish the week with a 60-minute timed set focused on web scenarios.

Week 4: Network services and exploitation judgment

Week 4 shifts from web-heavy thinking to broader infrastructure logic. This is where you practice identifying likely weaknesses in common services without making reckless assumptions.

Focus on these service types:

• SMB and Windows exposure: weak share permissions, null sessions, leaked usernames, accessible files.

• FTP and TFTP: anonymous access, file retrieval, misused writable locations.

• SMTP and mail services: user enumeration, version clues, open relay awareness.

• Database services: exposed ports, default credentials, dangerous trust assumptions.

• Remote admin services: SSH, RDP, VNC, and what banner/version information suggests.

The phrase to keep in mind this week is exploitation judgment. The exam is not asking whether you can launch every exploit. It is asking whether you can identify what is plausible, useful, and proportionate from the evidence.

For example:

• An old service version does not always mean “exploit now.” It means “verify whether the version is accurate, assess exposure, and consider known weakness classes.”

• An open share does not automatically mean critical risk. You need to ask what data is exposed, whether write access exists, and how that affects confidentiality or integrity.

• A login prompt is not a finding by itself. Weak authentication controls or valid unauthorized access would be.

Practice writing short justifications like this: “Anonymous FTP access is significant because it may allow unauthorized users to obtain sensitive files without authentication.” That style of reasoning helps in both answers and reporting.

End the week with a mixed timed set on web and network services.

Week 5: Reporting and evidence handling

Many candidates leave reporting too late. That is a mistake. Reporting sharpens your technical thinking because it forces you to explain cause, effect, and remediation. If you cannot explain a flaw clearly, you may not fully understand it.

This week, practice turning technical observations into short findings. Each finding should answer five things:

• What was observed?

• Why is it a security issue?

• What is the likely impact?

• What evidence supports it?

• What should be fixed?

Use plain language. Good reporting is not dramatic. It is clear.

Here is a simple finding structure to drill:

• Title: specific and factual

• Description: one short paragraph

• Impact: explain the business or technical risk

• Evidence: screenshot, response, file path, command output

• Recommendation: concrete action

Example:

• Title: Anonymous FTP Access Enabled

• Description: The FTP service accepted login using the anonymous account and allowed listing of files in the public directory.

• Impact: Unauthenticated users may obtain exposed files. If sensitive information is present, this could lead to data leakage.

• Evidence: Successful anonymous login and directory listing shown during testing.

• Recommendation: Disable anonymous access unless there is a documented business need, and restrict exposed content to intended public files only.

This week also review note-taking. During practical testing, weak notes lead to weak findings. Record enough detail that another tester could follow what you did.

Do one timed practice set, then write short findings for three questions you got wrong or guessed. This is an excellent way to connect technical judgment with reporting clarity.

Week 6: Full exam rehearsal and gap fixing

The final week is about integration. By now, you should not be studying topics as separate boxes. You should be moving from discovery to explanation in one smooth chain.

Run at least two timed sessions under realistic conditions. Sit somewhere quiet. Do not pause. Do not look up answers. After each session, review using three labels:

• Knowledge gap: you did not know the concept.

• Process gap: you knew the concept but chose the wrong next step.

• Speed gap: you knew it but took too long.

This matters because each gap needs a different fix. Knowledge gaps need revision. Process gaps need more scenario practice. Speed gaps need checklists and repetition.

In the last few days, review:

• Your service enumeration checklists

• Common web flaw indicators

• Protocol purpose and likely risks

• Finding structure and remediation wording

• All mistakes from earlier timed sets

Do not cram brand-new material at the end. That usually creates confusion. Tighten what you already studied.

A simple weekly rhythm that works

If you want a practical routine, use this pattern each week:

• Day 1: Learn the core concepts

• Day 2: Study tools and outputs

• Day 3: Drill service-specific routines

• Day 4: Work through scenarios and reasoning

• Day 5: Make notes and summary sheets

• Day 6: Timed practice set

• Day 7: Review mistakes and fix weak areas

This works because it combines knowledge, repetition, and pressure. Most failed study plans miss one of those three.

Final advice for the last stretch

The best CPSA preparation is steady and procedural. Think like a tester, not a crammer. When you see a host, service, parameter, or login form, train yourself to ask: What does this tell me? What should I test next? What would count as evidence? How would I explain the risk?

That habit is what this 6-week plan is trying to build. If you follow it closely, use a 6-week pentest planner to stay disciplined, and complete a timed practice set every week, you will be preparing in the same way the exam expects you to think. And that is the point. Passing the CPSA is not about collecting facts. It is about applying a method.