Service 01 · Penetration testing
Could someone get in today?
A penetration test answers the question with evidence instead of assurance: a qualified engineer, authorized in writing, tries to get in the way an attacker would, and reports what worked, what it reached, and what to fix first. This page says what is true outside, what the question means inside, and how the work is put in order.
Start with a measurement Read the sample penetration test report
01 / The world outside
The world outside: what an attacker sees
Every organization with a public web application or an API is tested every day, by people who were not invited. The OWASP Top 10, revised in 2025, names the classes of weakness they use, and the first of them is still broken access control: the application checks who you are and then forgets to check what you may see. In one test on this site, five of the fourteen findings were High, and all five had that single root cause: a token was authenticated, the record it asked for was not authorized, and a resident’s personal data could be read by changing a number in the address.
Regulators have stopped treating this as optional. New York’s financial services regulation requires an annual penetration test of covered entities from inside and outside; the payment card standard requires one each year and after any significant change; the SEC requires a public company to disclose a material incident within four business days of deciding it is material. The test is no longer only a technical exercise; it is the evidence a board can point to when asked what it knew, and when.
02 / The world inside
The world inside: the question behind the question
When a board asks whether someone could get in today, it is rarely asking for a vulnerability count. It is asking whether the people responsible know, and whether what they know is current. A security team can be competent and still blind to its own application: the people who built it test the paths they designed, and an attacker takes the ones they did not. The honest answer most executives carry is not "no" but "we have not looked the way an attacker would, recently, with someone who did not build it."
There is a second weight: the fear that looking will find something, and that finding it creates an obligation. It does, and that is the point. A finding discovered by your own test is a decision; the same finding discovered by someone else is an incident. The test moves the discovery to the side of the table where it can be ranked, budgeted and fixed, with a named owner and a date, before it has a cost that cannot be planned.
03 / Putting it in order
Putting it in order: how the work is done
The order is fixed and written down before anything is touched. Scope and written authorization first: which applications, APIs and networks, from which perspectives (anonymous, a user, an administrator), in which window, with whose contact for an emergency stop. Then the surface is mapped from a recorded session of the application in use; then the tests, following OWASP for applications and APIs and PTES for networks, read-only wherever reading suffices, every write test named and reversed. Nothing is exploited further than proving the point.
What comes back is a report built to be acted on: each finding with its severity, the exact route or host, the proof that it worked, the fix and the effort, ranked by what to do first; an executive summary that names the one change carrying most of the gain; a risk matrix of severity against effort. A retest of every fixed finding is included, so the report’s last page is the one the board keeps: what was found, what was fixed, verified. A typical application and API test takes two to three weeks from authorization to the retest.
What comes back
- A scope and authorization letter, signed before any testing
- An executive summary with the overall rating and the one change that carries most of the gain
- Every finding with severity, route or host, proof of concept, remediation and effort, ranked
- A risk matrix of severity against effort to fix; vulnerability and exploitability overviews
- A retest of every fixed finding, with the verified result
- The findings in the open medet.ink report format: read in a browser, printed to PDF
The work, as delivered
Pages and screens from the samples on this site. Read the sample penetration test report.
The executive summary and the overall rating
The risk matrix: severity against effort
A High finding: routes, radar, remediation
Its proof of concept, values masked
The first step
Tell us the application or the host. We begin with what can be observed from outside and answer within one business day.