Finding what an attacker would find, and writing down how to close it.
An automated scanner finds the known signatures and stops. The findings that actually matter, an authorization check that only runs in the browser, a password reset flow that leaks whether an email exists, live in the parts of an application that only a person trying to break it would find.
What this is
A vulnerability scan runs automated tooling against a target and returns a list of known signatures. A penetration test starts with that same tooling to clear the obvious ground quickly, then spends the remaining time with a person actually trying to get in: chaining a low-severity finding into something that matters, testing whether a normal user can reach an admin action by changing an ID in a URL, checking whether a role check that exists in the frontend also exists on the server. A scan with a report wrapped around it and an actual test are different products, and a fair amount of what gets sold as the second is quietly the first.
Scope gets agreed before anything starts, and it's rarely black box. Testing with zero access, like a genuine outside attacker, mostly burns budget failing to get past the front door and misses everything behind it. Gray box, a normal user account provided up front, is what most web application engagements actually use, because it reaches the business-logic bugs that matter without spending the whole engagement on reconnaissance a real attacker would eventually complete anyway. White box, with source access, goes deeper still when the target and the budget justify it. What's explicitly out of bounds, no destructive testing or load testing against production without an agreed window, gets written down at the same time as what's in scope.
Findings come back with a severity, exact reproduction steps, and a specific fix, not a generic remediation paragraph copied across every finding in the same class. After your team makes the fixes, we retest the specific findings, because a report nobody checks against the actual fix is a document, not a security improvement. The retest is part of the engagement, not a follow-up sale.
This covers web applications, APIs, admin interfaces and the infrastructure they run in: the surface a real product actually exposes, tested the way an interested party actually approaches it, not a checklist run against a target nobody looked at closely.
What you get
A scoping document
What's in bounds, what's explicitly out, and which test type, black, gray or white box, agreed before testing starts.
Manual testing beyond the scan
Business logic, authentication and authorization checks, session handling, the parts a signature-based scanner doesn't understand.
A findings report
Each issue with a severity, exact steps to reproduce it, and a specific fix, not a generic paragraph reused across every finding of that class.
An executive summary
Written for a non-technical stakeholder to actually read, separate from the technical detail engineers need to act on.
A retest after fixes land
Confirming each finding is actually closed, not just marked as such in a tracker nobody rechecked.
A debrief call
Walking through the findings with whoever has to decide what gets fixed first, so nothing lands as a cold document.
When this fits, and when it does not
A good fit
- You have a working application or infrastructure to test; there's something real for a person to try against.
- A customer, insurer or compliance requirement is asking for a 'penetration test' by name, and a vulnerability scan with a PDF wrapper won't satisfy them.
- You've shipped something touching authentication, payments or access control and want it looked at by someone other than the team that built it.
- You want the business-logic findings, not just the automated top-ten items a free scanner already caught.
- You want a report a developer can act on directly, without a follow-up call to ask what a finding actually meant.
Not a good fit
- Nothing is built yet. There's nothing for a person to attack; come back once there's a real target and we'll test that.
- You want continuous monitoring or an always-on security operations function. This is a point-in-time assessment, not a subscription, and we'll say so rather than sell a retainer for something else entirely.
- You need a formally accredited assessment for a specific scheme, PCI-DSS by a QSA, for instance. We are not an accredited assessor for any scheme. If your requirement names one, PCI-DSS signed off by a QSA for instance, you need an accredited firm, and we will tell you that on the first call rather than after the report.
- What actually worries you is losing data or being unable to recover from an incident, not whether someone can get in. That's backup and disaster recovery.
- You're mid cloud migration and want the new environment tested before the cutover finishes. Worth doing, but scope it as a separate step once the migration has landed, not layered into the same week.
How it runs
- 01
Scope it
What's in bounds, which test type, and the window it can safely run in, agreed in writing first.
- 02
Recon and automated pass
Map the attack surface and clear the known-signature findings quickly, before the manual work starts.
- 03
Manual testing
Authentication, authorization and business logic, chaining smaller findings into what an attacker would actually do with them.
- 04
Report
Severity, reproduction steps and a fix for each finding, plus a summary for whoever isn't reading the technical detail.
- 05
Retest
Confirm the fixes actually close the findings, once your team has had time to make them.
Questions we get
Is this the same as a vulnerability scan?
No, and it's worth knowing the difference before you buy either. A scan is automated and finds known signatures; we run one as a first pass, then spend the remaining time on what a scanner can't reason about, business logic, chained findings, authorization checks. If a report calls itself a penetration test but was entirely automated, ask for the manual hours behind it.
How long does an engagement take?
Depends on the surface area: a single web application is a different scope from that same application plus its API plus the infrastructure underneath it. We give a time estimate once scope is agreed, not before.
Will testing take our production system down?
Not without an agreed window and your sign-off. Destructive or load-heavy tests are scoped separately and scheduled deliberately; the default engagement is thorough without being reckless with a system people actually depend on.
Do you retest for free after we fix the findings?
Yes. Confirming each finding is closed is part of the engagement, not a separate line item added afterward.
Want to know what an attacker would find first?
Tell us what you'd want tested, including what should stay out of bounds. An engineer scopes it and gives you a straight answer on time and depth.