A penetration tester is paid to find security weaknesses in systems an organisation owns, with its written permission, and to explain them clearly enough that someone can fix them. Hands-on testing is only part of a typical week. The rest goes on scoping, careful note-taking, talking to clients, retesting old findings and writing the report, which is the part the client actually pays for.
That ratio surprises people who picture a hoodie and a green terminal. Below is a realistic, composite week for a tester at a security consultancy, followed by how the job differs in other settings. It describes the work in general terms, not any real engagement. The commands are run against lab addresses.
Legal note: only test systems you own or have written permission to test. Everything in a real engagement starts with a signed scope and authorisation.
The shape of a week
Most consultancy testers work on one or two engagements at a time, each lasting anywhere from a few days to several weeks. A common pattern for a one-week web application and API test looks like this:
| Day | Main focus | Output by end of day |
|---|---|---|
| Monday | Kick-off, scope check, access check, reconnaissance | Confirmed scope, working test accounts, attack-surface map |
| Tuesday | Authentication, session handling, access control | First confirmed findings with evidence |
| Wednesday | Business logic, input handling, APIs | More findings; anything critical reported to the client straight away |
| Thursday | Remaining test cases, retest of last quarter’s findings for another client | Coverage checklist complete |
| Friday | Report writing, peer review, debrief prep | Draft report into quality review |
Real weeks are messier. A scoping call for next month’s job lands on Tuesday. A client’s test environment goes down on Wednesday afternoon. Someone asks you to sanity-check a colleague’s finding. That’s normal.
Monday: scope, access and reconnaissance
The week starts with a kick-off call with the client’s technical contact. You confirm the in-scope targets, the testing window, who to call if something breaks, and whether any systems are fragile or off-limits. This all comes from the rules of engagement document signed before the test. NIST SP 800-115, the US government’s technical guide to security testing, stresses this planning phase for good reason: testing the wrong IP address is not a technical mistake, it’s an unauthorised attack.
Next you check that you can actually work. Do the test accounts log in? Is your source IP on the allowlist? Does the VPN connect? A surprising amount of Monday morning goes on this.
Then reconnaissance on the confirmed scope. On a lab network, an initial service scan might look like this:
$ nmap -sV -sC -p- --min-rate 1000 -oA scans/acme-app 10.10.20.15
Starting Nmap 7.95 ( https://nmap.org )
Nmap scan report for 10.10.20.15
Host is up (0.0021s latency).
Not shown: 65531 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to https://app.acme-fintech.test/
443/tcp open ssl/http nginx 1.18.0 (Ubuntu)
|_http-title: Acme Fintech | Sign in
8080/tcp open http Apache Tomcat (language: en)
|_http-title: Apache Tomcat
Nmap done: 1 IP address (1 host up) scanned in 41.27 seconds
The -oA flag saves output in all three Nmap formats, which matters later: everything you claim in the report needs evidence. The Nmap reference guide explains every option used here. That Tomcat page on port 8080 goes into the notes as “investigate: is this meant to be exposed?”
For a web app, reconnaissance also means browsing every feature through an intercepting proxy such as Burp Suite while logged in as each test role, so you build a map of endpoints, parameters and who is allowed to do what.
Tuesday: authentication and access control
Most testers work from a methodology rather than from memory. For web applications, the OWASP Web Security Testing Guide is the common reference. Its test IDs give you a checklist and a shared vocabulary with the client.
Tuesday might go on questions like:
- Can a normal user reach admin functions by calling the endpoint directly?
- Can user A read user B’s records by changing an ID in the request?
- Do password reset tokens expire, and can they be reused?
- Does logging out actually invalidate the session on the server?
A typical access-control check in a lab looks like this. Log in as one test user and request a record that belongs to another:
GET /api/v1/accounts/100482/statements HTTP/2
Host: app.acme-fintech.test
Authorization: Bearer eyJhbGciOi...<test user A token>
HTTP/2 200 OK
Content-Type: application/json
{“account_id”:100482,“owner”:“Test User B”,“statements”:[...]}
If that returns user B’s data, you have a finding. Now the discipline starts. You screenshot it, save the raw request and response, note the time, and repeat it once to confirm it’s reproducible. You don’t go and pull a thousand other customers' statements to “show impact”. Two test accounts prove the point.
Wednesday: logic, APIs and the “stop and call” moment
Business logic is where experienced testers earn their keep, because scanners can’t find it. In a fintech app that might mean:
- Submitting a transfer, then replaying the request to see whether it debits once or twice.
- Sending a negative amount.
- Changing the currency field mid-flow.
- Approving your own request in a maker-checker workflow.
If you find something critical, such as exposed credentials or a way to move money between accounts, you don’t wait for the report. The rules of engagement usually say who to contact, and you tell them the same day. This is one of the clearest differences between professional testing and hacking for fun.
Testers also map what they find to recognised frameworks so defenders can act on it. On infrastructure or red-team-style work, techniques are often referenced against MITRE ATT&CK, which helps the client’s SOC see which of their detections should have fired.
Thursday: coverage, retests and the unglamorous middle
By Thursday you are working through the remaining checklist items. Many of them come back clean, and that’s a result too: the report should say what was tested and found sound, not only what failed.
Thursday is also a common day for retests. A client from a previous engagement says they’ve fixed three findings. You check each fix against the original evidence and confirm it’s resolved, partly resolved or still open. Retests are short, but they matter: often the first fix only blocks the exact payload in the report, not the underlying flaw.
Friday: writing the report
Writing usually takes a full day for a one-week test, sometimes more. Each finding needs:
- a clear title
- a severity rating, usually with a CVSS score
- the affected assets
- a plain-English description of the risk
- step-by-step reproduction with evidence
- specific remediation advice
The executive summary has to make sense to someone who will never read the technical section.
If you take notes properly all week, Friday is assembly and editing. If you don’t, it’s a nightmare. We cover structure and a worked sample in how to write a penetration testing report.
Most consultancies then send the draft through peer review, where another tester checks the findings, severity ratings and wording before the client sees it. After delivery there’s often a debrief call to walk the client’s developers through the issues.
What does a penetration tester do day to day, beyond testing?
Across the week, these tasks take real time:
- Note-taking: timestamps, commands, requests, screenshots. One folder per engagement, kept in the same structure every time.
- Client communication: scoping calls, status updates, urgent-finding notifications, debriefs.
- Research: reading about a framework or product you haven’t tested before, often the evening before.
- Tool maintenance: updating tools, keeping wordlists current, fixing your testing VM.
- Learning: labs, CTFs, certifications. The field moves fast enough that testers who stop studying fall behind.
Where do penetration testers work?
The same core work looks different depending on the employer. If you’re browsing penetration testing jobs, it helps to know which setting you’re applying to:
| Setting | What changes |
|---|---|
| Security consultancy (penetration testing companies) | Many clients, short engagements, lots of variety and report writing, frequent context switching |
| In-house security team | One organisation’s systems in depth; more retesting, secure design review and working with developers |
| Government-assured schemes | In the UK, for example, the NCSC publishes guidance on penetration testing and how to get good value from it; some public-sector work requires approved providers |
| Bug bounty (self-employed) | You choose targets within each programme’s published rules; paid per valid finding, not per day |
Is penetration testing a good career for a beginner?
It’s a reachable goal, but rarely a first job. Most testers arrive after time in IT support, networking, development or a SOC, because the work assumes you already understand how systems are built and run. The honest route is: learn the fundamentals, build a lab, practise on legal platforms, write up what you do, then aim for junior tester or adjacent roles. Our step-by-step guide on how to become a penetration tester lays that out, and if you’re starting from zero, begin with how to get into cybersecurity with no experience.