What it is
A deliberate attack on a defined part of your environment, carried out the way a real attacker would: under written authorisation, inside agreed rules, and within an agreed window. You get the proof, the path the attack took, and a fix list ordered by real business impact rather than raw CVSS score.
A penetration test is not a vulnerability scan. A scanner produces a list of possibilities; a test produces a list of facts. The value is in what a person does after the scanner stops: chaining three "medium" findings into domain admin, or turning a "low" information leak into a full account takeover.
What I test
Two engagement families. Both run on the same methodology backbone. The difference is the target, and where the depth goes.
| Test type | What it covers, and what it is tested against | The question it answers |
|---|---|---|
| Infrastructure penetration test | Networks, servers, endpoints, identity and cloud configuration: on-premise, cloud (Azure / Microsoft 365 / AWS), or hybrid. Run external (from the internet against your perimeter) or internal (assumed breach, from inside the network). Tested against: PTES, NIST SP 800-115 and CIS Benchmarks, with every technique used mapped to MITRE ATT&CK. | If someone reaches your network, from the outside or from one compromised laptop, where do they end up, and how quickly? |
| Application penetration test | Web applications and the APIs behind them. Tested unauthenticated first, then authenticated at every privilege level the product has, including the roles nobody thinks about, like the trial user and the deactivated account. Tested against: the OWASP Top 10, the OWASP API Security Top 10 and the full OWASP Web Security Testing Guide (WSTG). Coverage that goes well past the Top 10, which is an awareness list rather than a test plan. | Can one user become another user, or an admin? Can data be reached, changed or exported by someone who shouldn't have it? |
Black box, grey box, white box
The second choice, after the target, is how much I am told before I start. The industry calls these the knowledge-based test types. It is a scoping decision, not a quality one: it decides how much of the budget goes to discovery, and how much goes to depth.
| Approach | What you give me | Best when |
|---|---|---|
| Black box | A target list and nothing else | You want realism, or a first test to see what an outsider can find unaided |
| Grey box | Credentials for each role, architecture notes, API documentation | The default, and what most standards assume. Best coverage per day: no budget burned rediscovering what you already know |
| White box | The above plus source code, configuration, and read-only cloud access | Regulated or business-critical systems, where missing something is the expensive outcome |
When you are obliged to test
| Driver | What it requires |
|---|---|
| ISO/IEC 27001:2022 | Controls A.8.8 (technical vulnerability management) and A.8.29 (security testing in development and acceptance). No clause says "penetration test", but it is the evidence auditors expect to see. |
| SOC 2 | Same story: no explicit clause, but a current report is what auditors and enterprise customers look for under the monitoring and change-management criteria. |
| DORA (EU), Regulation 2022/2554 | Network penetration testing at least annually for all in-scope financial entities (Art. 24–25), and threat-led penetration testing (TLPT) at least every three years for entities designated by the national authority (Art. 26–27). |
| NIS2 (EU), Directive 2022/2555 | Security testing and effectiveness assessment as part of the mandated risk-management measures, for essential and important entities. |
| PCI DSS v4.x, requirement 11.4 | Internal (11.4.2) and external (11.4.3) penetration tests at least every 12 months and after any significant change; exploitable findings corrected and retested (11.4.4); segmentation controls tested every 12 months (11.4.5), and every 6 months for service providers (11.4.6). |
| Customer contracts, security questionnaires and tenders | Not regulation, but binding all the same. "An annual penetration test by an independent third party, with an attestation letter on request" is now standard language in enterprise contracts and in public tenders in Israel and the EU. |
When it is recommended, even though nobody is forcing you
- A new product or a major feature is about to go live. The cheapest moment to find an authorisation flaw is before the first customer does
- You migrated to the cloud, changed architecture, or moved hosting provider. The controls that protected the old design rarely map cleanly onto the new one
- You have just been through an incident. A test is how you confirm the way in is genuinely closed, rather than assumed closed
- Due diligence is coming. A funding round or an acquisition, where a clean report shortens the security conversation
- You have just acquired a company. You inherited an attack surface nobody in your team has ever looked at
- AI-assisted code shipped faster than review could keep up. Generated code tends to fail in patterns, and those patterns are testable
- A large enterprise customer is about to ask. Better to answer with a report than with a promise
- Your internal network has never been tested from the inside. External hardening says nothing about what one phished laptop reaches
- You have never had a test at all. The first one always finds the most, and it is the one that tells you where you actually stand
- Annually, in a stable environment. As routine hygiene, alongside the retest of last year's findings
How it works
Seven phases, the same for both test types. These are the PTES phases and the NIST SP 800-115 discovery–attack–report cycle: a recognised process you can point an auditor at, not a methodology I invented. What changes between infrastructure and application work is what happens inside each phase, not the order of them.
- 1 · Scoping and authorisation
- 2 · Discovery
- 3 · Threat modelling and analysis
- 4 · Exploitation
- 5 · Post-exploitation
- 6 · Reporting
- 7 · Retest
| Phase | What happens |
|---|---|
| 1 · Scoping and authorisation | Target list, rules of engagement, test window, emergency contact, and an agreed answer to "what if something breaks". Written authorisation is signed before anything else happens. No exceptions. |
| 2 · Discovery: reconnaissance, scanning and enumeration | One phase, not three: mapping the real attack surface, which is almost never the one on the diagram. Passive reconnaissance, automated scanning and manual enumeration feed the same picture, and every automated finding is verified by hand, so false positives do not reach your report. Infrastructure: live hosts, exposed services, cloud tenants, identities, forgotten test environments. Application: routes, parameters, roles, the technology stack and its third-party components. |
| 3 · Threat modelling and vulnerability analysis | Deciding what is genuinely exploitable in your context, what an attacker would actually want here, and which findings can be chained. Three unremarkable issues that combine into full compromise outrank one loud high-severity finding that leads nowhere. |
| 4 · Exploitation | Proving it rather than claiming it. Infrastructure: gaining access, escalating privileges, moving laterally, abusing identity and cloud misconfiguration. Application: authentication and authorisation bypass, injection, insecure direct object references, session handling, business logic abuse. |
| 5 · Post-exploitation | How far the access actually reaches: the domain, the cloud tenant, the data. Depth is agreed in advance and stops exactly where you say it stops. Nothing is left behind in your environment. |
| 6 · Reporting | Draft report, a walkthrough with your technical team, a separate session for management, then the final version. Critical findings are not held back for the report. You hear about those the day they are found. |
| 7 · Retest | Verification that the fixes actually fixed it, and an updated report reflecting what is genuinely closed. This is the version an auditor, a customer or a regulator will ask to see. |
What you get
- Findings ranked by business impact. Not sorted by raw CVSS score, which routinely puts an unreachable "high" above the "medium" that ends your business
- Reproduction steps. Precise enough that your developer or sysadmin can reproduce the issue without me
- Proof of exploitation. Screenshots, requests and responses, the actual path taken
- The attack narrative. How the individual findings chain together into a real compromise
- Remediation guidance for your stack. The actual fix in your framework, cloud or product, not a link to a generic article
- Executive summary. Written so a non-technical board or a customer can read it and decide
- Attestation letter. For procurement, security questionnaires and tenders
- Retest and an updated report. The version you can actually show someone
What is out of scope (Can be done in addition by hodsec)
- Denial of service and load testing
- Social engineering and phishing simulation: a separate engagement, not part of this one
- Physical intrusion
- Third-party systems you do not own or cannot authorise testing against
- Fixing the findings. I tell you what to fix and how; the fixing is yours, or a separate engagement
What I need from you
It varies from engagement to engagement, but in practice it comes down to three things:
- Scope and access. The exact targets in writing (IP ranges, domains, application URLs), signed authorisation to test them, and the access the test needs: test accounts at every privilege level, the environment I am testing against, and any VPN, jump host or WAF allowlisting required to reach it
- One technical contact on your side. Someone who can grant that access, approve the rules of engagement, and stay reachable during the test window if something breaks or a critical finding needs an immediate decision
- A decision on whether your monitoring team is told. Either they know the test is coming, or they deliberately do not, so the test measures your detection as well. Both are fine; it only has to be agreed in advance, so a real incident during the window is not mistaken for me
Who does the work
I run the engagement myself. You deal with one person from start to finish. When the work needs extra hands or a specific specialism, I bring in professionals I have worked with before, under the same confidentiality terms, and you always know who is touching your systems.
Confidentiality
What you tell me, and what I find, stays between us. Full confidentiality is guaranteed during the engagement and after it, and an NDA can be signed before we discuss any detail.
Standards the work follows
- PTES. Penetration Testing Execution Standard, for overall methodology
- NIST SP 800-115. Technical Guide to Information Security Testing and Assessment
- OWASP Top 10, API Security Top 10 and WSTG. The baseline every stakeholder recognises, plus the testing guide that gives web application coverage its actual depth
- MITRE ATT&CK. For describing the techniques used, in the same language your defenders use
Follow-on work
An annual test cycle with the retest built in; secure development consulting to fix the class of bug rather than the individual instance; developer training on the issues that actually appeared in your code; a compromise assessment if the test suggests someone got there first; or incident response, if it turns out they did. None of it is a condition of the test.
What happens next
- A scoping call. What you have, what worries you, and what deadline you are working to. No charge, and no obligation.
- A written scope, and a quote based on the scope of work. Targets, approach, depth, and what you will receive, in writing, so there is nothing to interpret later.
- Paperwork. NDA, authorisation to test, rules of engagement.
- Dates in the calendar. Your window, agreed around your release schedule and your business hours.
- I start.
If you already know what you need tested, the call is short. If you don't, that is exactly what the call is for.