My methodology.
A penetration test is judged as much on its frame as on its findings. What follows describes what is fixed before anything starts: which frameworks I work from, in what order I work, what I will not do, and when you hear from me. None of it is renegotiated along the way.
Tools to cover, hands to find.
A serious pentest combines two modes of work that often get conflated. The first is mechanical: inventory the entry points, check versions, run through a list of known checks. A tool does that better and faster than a person, and there is no reason to refuse one.
The second does not automate. It means understanding what your application is meant to do, then hunting for the places where that intent was not correctly translated into code. No tool knows that a user should not be able to approve their own refund request, because that rule exists nowhere but in your business.
My whole method follows from that split. I tool up the first part as much as possible to free time for the second, which is the only one that finds the flaws that genuinely cost money. And no tool output reaches a report without being replayed by hand: on a raw scan, most of the alerts do not survive verification.
What I work from.
Frameworks do not replace research: they guarantee no family of flaws goes quiet while attention is elsewhere.
OWASP WSTG
The web application testing guide. It serves as the coverage list: authentication, session management, authorization, input validation, business logic, configuration. Every category is walked and recorded.
OWASP API Security Top 10
The API-specific ranking, which does not overlap the web one. Object-level and function-level authorization take the top spots, and that is genuinely where most of what I find concentrates.
PTES structure
For running the engagement rather than for technical content: scoping, intelligence gathering, threat modelling, exploitation, post-exploitation, reporting. It is the spine of the process.
How an engagement unfolds.
Scoping and authorization
Written perimeter, addresses in scope, testing window, a reachable contact, accounts provided. The written authorization is signed: without it there is no engagement, whoever the provider is. The NDA comes before any technical exchange.
Reconnaissance
What is genuinely reachable under your name: subdomains, side environments, technologies in play, forgotten entry points. This is the only phase where a larger perimeter than expected can appear, and that is the moment to say so.
Functional mapping
I walk the application as a legitimate user, with each role, noting what each one can do. That map is what later distinguishes a normal request from a boundary being crossed.
Research and exploitation
The core of the engagement. Every hypothesis is checked against the live application, not inferred from a version string. A flaw enters the report only if I exploited it and hold reproducible proof.
Controlled post-exploitation
Once a breach is open, I measure how far it reaches: what data becomes available, what other functions unlock, what chain becomes possible. I stop at demonstration, never extracting or altering real data.
Report, walkthrough, retest
Writing, delivery, then an hour with the people who will do the fixing. Once the fixes ship, I replay the relevant tests and confirm in writing what is closed.
What I will not do.
These rules go into every testing authorization. They exist so the engagement never becomes the incident.
- No denial of service, no load testing, no attempt to exhaust resources, unless you ask for it explicitly and in writing.
- No destructive action on real data: nothing deleted, nothing altered that belongs to your users.
- No extraction of personal data beyond the minimum needed to prove the flaw exists.
- No testing outside the written perimeter, however open a neighbouring door looks. It gets reported, not opened.
- No social engineering aimed at your staff, unless that is a specific engagement agreed in advance.
- Any critical vulnerability is reported the same day, without waiting for the report.
- A timestamped log of the testing is kept, so you can tell my activity apart from a real attack in your own records.
- Engagement data and proofs are destroyed after the agreed retention period.
Black, grey or white box.
How much you tell me changes what the engagement can reach. In practice, one option is nearly always right.
Grey box, the default
You supply accounts, not code. I start where an attacker who managed to sign up starts, which is the real scenario in the vast majority of cases. Best coverage for a given budget.
Black box
No information, no accounts. Realistic for gauging the exposure of a public surface, but expensive: part of the days go to reconnaissance rather than research, and everything behind the login stays out of reach.
White box
Read access to the source. Worth it on a sensitive, specific component: a permissions engine, financial calculation, home-grown cryptography. Poor value across a whole application.
What never changes
Whichever approach, the rules of engagement, the same-day escalation on critical findings and the included retest stay identical.
Common questions.
Do you follow a recognised standard?
I work from the OWASP Web Security Testing Guide and the OWASP API Security Top 10, with the PTES structure for running the engagement. These are coverage frameworks: they guarantee no family of flaws goes unexamined. They do not replace the research specific to your application, which is where most of the work sits.
Black box, grey box or white box: which one?
Grey box in almost every case: you supply accounts, not code. It is the best trade between realism and coverage. Full black box burns days on reconnaissance for a small gain in realism, and white box only earns its keep on sensitive, bespoke code.
Do you test in production?
Yes, that is the most common case, and it is safe once the rules are set: no denial of service, no destructive action, test data created for the occasion, requests spaced out. A faithful staging environment is still preferable where one exists, because it allows manipulations one would not risk elsewhere.
What happens if you find something critical?
You hear from me the same day, without waiting for the report, with enough to understand and contain it immediately. That is a rule set before the engagement starts, and it is why I always ask for a contact who is reachable during the testing window.
Do you use automated tools?
Yes, for what they are good at: inventorying, repeating, measuring, missing nothing mechanical. No tool output reaches the report without being replayed and confirmed by hand. Tooling covers what is already catalogued, which frees time for what is specific to you.
Let's talk about your perimeter.
Describe what you want tested and I will propose a scope: approach, phases, duration and rules of engagement, before you commit to anything. First conversation with no commitment, full confidentiality.