Our penetration testing methodology, from scoping to retest.
A penetration test is judged on its framework as much as on its results. Here is what is settled before we start: the references we work from, the order we work in, what we never do, and when you hear from us. None of it gets renegotiated along the way.
At a glance
- FrameworksOWASP WSTG, the OWASP API Security Top 10, and the PTES structure to run the engagement.
- ApproachGrey box in most cases, with test accounts you provide.
- What we never doNo denial of service, no load testing, nothing destructive on real data.
- What triggers an alertAny critical flaw, reported the same day, without waiting for the report.
Our tools to cover, our expertise to find.
Our tools cover everything that can be checked mechanically. The rest takes understanding how your application is meant to work.
A serious penetration test combines two ways of working that often get confused. The first is mechanical: listing entry points, checking versions, running through a list of known checks. Our in-house tools do it better and faster than a person, and going without them would make no sense.
The second cannot be automated. It means understanding what your application is supposed to do, then looking for where that intent was not translated correctly into the code.
Our whole method follows from that split. We tool the first part as far as we can to free up time for the second, the one that finds the flaws a tool cannot see. And no tool result goes into a report without being replayed and confirmed: in a raw scan, a good share of the alerts are false alarms.
Two ways of working. The tools free up time, and that time goes to what is specific to your application.
What we work from.
Frameworks do not replace research: they make sure no family of flaws gets skipped while we dig elsewhere.
OWASP WSTG
Web coverage
The web application security testing guide. It works as a coverage list: authentication, session management, authorization, input validation, business logic, configuration. Every category is reviewed and recorded.
OWASP API Security Top 10
API coverage
The ranking specific to APIs, which does not overlap the web one. Object and function level authorization sit at the top, and that is where we find a large share of API flaws.
PTES structure
Running the engagement
For how the engagement is run rather than for its technical content: scoping, intelligence gathering, threat modeling, exploitation, post-exploitation, reporting. It is the backbone of the process.
How an engagement unfolds.
Six phases, always in this order. Each one has its output, and the next one does not start without it.
See the report it produces- 01
Scoping and authorization
Written scope, URLs covered, test window, a reachable contact, accounts provided. The NDA is signed as soon as we get into technical details. Once the quote is signed, the penetration test authorization agreement is signed in turn: without it there is no engagement, whoever the provider.
- 02
Reconnaissance
What can actually be reached under your name: subdomains, side environments, technologies in place, forgotten entry points. This is the only phase where a wider scope than planned can show up, and the moment to say so.
- 03
Functional mapping
We walk the application as a legitimate user, with each role, and record what each one can do. That map is what later lets us tell a normal request from a boundary being crossed.
- 04
Research and exploitation
The heart of the engagement. Every hypothesis is checked on the real application, never inferred from a displayed version. A flaw only goes into the report if we exploited it and hold reproducible proof.
- 05
Controlled post-exploitation
Once a gap is open, we measure where it leads: what data becomes reachable, which other functions open up, what chain becomes possible. We stop at the demonstration, without ever extracting or altering real data.
- 06
Report, debrief, retest
Writing, hand-off, then an hour with the people who will do the fixing. Once the fixes are deployed, we replay the relevant tests and confirm in writing what is closed.
What we never do.
These rules are written into every penetration test authorization agreement. They exist so the engagement never becomes the incident itself.
No denial of service
No load testing, no attempt at saturation, unless you ask for it explicitly and in writing.
Nothing destructive
No deletions, no changes to content that belongs to your users.
Nothing taken beyond the proof
No personal data extracted beyond the minimum needed to demonstrate the flaw.
Nothing outside the written scope
Even if a neighboring door looks open: it gets reported, not walked through.
No social engineering
Nothing aimed at your staff, unless a specific engagement was agreed in advance.
A same-day alert
Any critical vulnerability is reported the same day, without waiting for the report.
A timestamped log
Kept so you can tell our activity apart from a real attack in your own logs.
Data destroyed
Engagement data and evidence are destroyed after the agreed retention period.
Black, grey or white box.
How much information you give us changes how far the engagement can reach. In practice, one option is almost always the right one.
Black box: nothing up front
- You provide
- No information, no account.
- The test reaches
- The exposure of a public surface. Part of the days go into reconnaissance rather than research, and everything behind authentication stays out of reach.
- Choose it when
- To assess what a stranger sees from the internet.
Grey box, the default Our advice
- You provide
- Test accounts, with no access to the code.
- The test reaches
- The same starting point as an attacker who managed to sign up or get hold of an account, a very common scenario.
- Choose it when
- Almost always: the best coverage for a given budget.
White box: read access to the code
- You provide
- Read access to the source code.
- The test reaches
- Everything above, plus the logic written in a sensitive component: permission engine, financial calculation, home-made cryptography.
- Choose it when
- On a sensitive, specific component. Rarely worth it on a whole application.
Whatever the approach, the rules of engagement, the immediate alert on a critical flaw and the included retest stay the same.
Do you follow a recognized standard?
We work from the OWASP Web Security Testing Guide and the OWASP API Security Top 10, with the PTES structure for running the engagement. They are coverage references: they make sure no family of flaws is forgotten. They do not replace the research specific to your application, which is most of the work.
Black, grey or white box: which should I choose?
Grey box in almost every case: you provide test accounts, with no access to the code. It is the best balance between realism and coverage. A full black box loses days to reconnaissance for little gain in realism, and white box only pays off on sensitive, specific code.
Do you test in production?
Yes, it is even the most common case, and it is safe once the rules are set: no denial of service, nothing destructive, test data created for the occasion, spaced-out requests. A faithful staging environment is still better when there is one, because it allows manipulations we would not risk elsewhere.
What happens if you find something critical?
You hear about it the same day, not at report hand-off: the flaw, its proof and what you need to contain it right away. That rule is written into the authorization agreement, and it is why we ask for a contact who can be reached throughout the test window.
Do you use automated tools?
Yes, our in-house tools, for what they do well: listing, repeating, measuring, forgetting nothing mechanical. No tool result goes into the report without being replayed and confirmed. The tooling covers what is already cataloged, which frees up time for what is specific to you.
Read further.
The method turns into days, a deliverable and services.
What a pentest costs
This method turns into research days: our pricing and what moves the number.
See the pageSample report
What the sixth phase produces: the eight sections of the report, and one flaw end to end.
See the pagePentest or vulnerability scan
Where the tool stops, where research begins, and why the two do not answer the same question.
See the pageAll services
The five services that apply this method.
See the pageLet's talk about your scope.
Describe what you want tested. We will propose a scope with the approach, the phases, the length and the rules of the test. The first call commits you to nothing.