Penetration testing
A test is worth what its findings are worth, and a finding is worth what a developer can do with it on the morning it arrives. Everything below is arranged around that: what gets attacked, under what written authorization, and what comes back in a form your engineers can act on without a translation layer.
Authorization and scope, before anything starts
Nothing is touched until two documents exist. The first is a scope: the exact targets, the dates, the hours, the techniques that are in and out, the accounts provided, and the contact who can stop the test. The second is an authorization signed by whoever owns the systems, which is not always the party buying the test — a hosted application may need the platform owner’s sign-off as well as yours.
Testing and adversary simulation are carried out only with signed authorization. Where an engagement would extend into investigation or forensic work, that part is delivered with appropriately licensed partners where the law requires it. This practice never claims a licence it does not hold, and does not imply one by leaving the question unanswered.
The short version: what is tested, and what comes back
Testing is performed by hand, with tooling used to cover ground rather than to produce the report. The methodology is public: the OWASP Web Security Testing Guide for the procedure and the OWASP Application Security Verification Standard for the requirements a finding is measured against, with defect classes named from the OWASP Top 10:2025. Using published methodology means you can check the coverage claim rather than take it.
What you get back is a report in which every finding can be reproduced from the text, a retest of what you fix, and a debrief with the engineers who have to do the fixing. The structure is shown in the sample report, and what a good one contains generally is set out in what a penetration test report should contain.
What can be tested
Web application testing
Authenticated testing across every role the application defines, because the findings that matter most are almost always horizontal: one customer reaching another customer’s records, one role performing an action reserved for a higher one. Unauthenticated testing alone finds the perimeter and misses the business logic, which is where the damage is.
API testing
Tested against the specification and against what the implementation actually accepts, which differ. Object-level and function-level authorization, mass assignment, rate limiting, token handling and scope enforcement, and the endpoints that exist but are absent from the documentation.
External and internal network testing
External testing establishes what an unauthenticated attacker on the internet can reach and do. Internal testing starts from a position inside — a compromised workstation, a contractor’s access, a visitor on the wrong network — and establishes how far that position travels. Most organizations overestimate the first and have never measured the second.
Cloud testing
Testing inside a cloud environment is constrained by the provider’s own published rules, which bind the customer and anyone the customer hires. Those rules are checked against their current text at scoping and reflected in the scope document. Where what you actually need is a statement of what the environment permits, that is a cloud security configuration review and it is the cheaper and usually more productive purchase.
External attack surface assessment
An enumeration of what your organization exposes to the internet: domains and subdomains, hosts, services, certificates, exposed administrative interfaces, cloud storage, and forgotten infrastructure from projects that ended. It is frequently bought first, because the answer to “what do we even have?” changes the scope of everything after it.
Smart contract security review
Review of on-chain contract source and its deployment and upgrade arrangements, where an engagement calls for it. Work in this area is delivered with vetted specialists brought in for the project, and the scope document says plainly which parts are reviewed and which are not.
How is a finding written?
Four parts, every time, and the report is judged on them:
- Reproduction steps — the request, the account used, the precondition, and the observed result, written so an engineer who was not there can reproduce it and confirm the fix themselves.
- Severity — argued from what it gives an attacker in your environment, not lifted from a generic scale that does not know what your system holds.
- Business impact — what it means in terms a non-technical reader can weigh, because the person approving remediation time is often not the person reading the request.
- Remediation — a specific change, and where a tactical fix differs from the right one, both, labelled as such.
Findings that a scanner would also have flagged are marked as such, because you should not pay a tester for output you could have generated. The difference between the two kinds of work is set out in penetration testing versus a vulnerability scan. Keeping that scanning running and acted on between tests is the job of a vulnerability management programme.
Retest, and the letter that records it
Fixed findings are retested, and the result is written down. The letter records that testing was performed, the scope, the dates and the findings closed on retest. It is the document customers and insurers usually mean when they ask for “proof of testing”.
It is important to be exact about what that letter is not. It is not a certificate of security, and it is none of the three things buyers sometimes hope for: SecHB does not issue certifications, attestations or audit opinions. Those come from bodies constituted to issue them, and a testing letter from anyone — including firms that present one as equivalent — is not one.
How engagements are scoped and quoted
To scope a test we need the target list, what kind of system each target is, roughly how large it is, whether testing is authenticated and with how many roles, and who owns the systems in scope. From that, a proposal states the days, the coverage those days buy, what is excluded, and what you receive. Engagements are quoted in writing before work starts, and no figure appears on this site because a number without a scope attached is not information.
Scoping is a skill in itself, and a badly scoped test is the most common way to spend a budget and learn nothing. The questions worth answering before you approach anyone are in how to scope a penetration test.
Where the question is not “what is broken?” but “would we notice?”, the right purchase is red teaming and adversary simulation instead. And where the code is available, secure code review finds a different and partly non-overlapping set of defects.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
Investigation and forensic work is delivered with appropriately licensed partners where the law requires it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What do you need to scope this?
Where you cannot answer all of it, say so — an unclear inventory is itself a finding, and an external attack surface assessment is often the right first step.
Do you test production or staging?
Either, and the choice is made deliberately rather than by default. A staging environment that genuinely mirrors production is preferred; where none exists or it does not match, testing runs against production under agreed constraints. Constraints are written into the scope: rate limits, excluded destructive techniques, a named contact reachable throughout, and an agreed stop condition.
Will you give us a certificate?
You receive a retest letter recording that testing was performed, what was in scope, when it happened, and which findings were retested and closed. Most customer and insurer requests are satisfied by that letter together with the report summary.
How do we compare two quotes that look different?
Compare the days proposed, the named scope, whether retesting is included, whether findings are reproduced by hand rather than forwarded from a tool, and who performs the work. A proposal that will not name its scope precisely is not cheaper; it is smaller, and you find out which parts were missing after the report arrives.
Start with the scope, not the date
Describe the targets, who owns them and what they hold. The reply says what a test would cover, what authorization is needed and what you would receive — see also all security services.