Penetration testing with findings validated by hand.
A penetration test run by people, with manual exploitation and every finding reproduced before it reaches the report. The goal is not to list what looks vulnerable: it is to demonstrate what an attacker can actually do with what you expose today.
What a pentest answers that a scanner cannot
An automated tool points at what looks vulnerable. A penetration test demonstrates what is genuinely exploitable and how far the access reaches. The difference shows up in chaining: an authorisation flaw that would be rated low on its own becomes critical when it leads to data that user should never touch. No tool builds that path by itself — and it is the path, not the label, that changes how a fix gets prioritised.
- Every finding is reproduced by hand before it enters the report: raw tool output is not a deliverable.
- Risk is described by the impact on your business, not only by a generic score from a public database.
- False positives never reach you — anything we could not reproduce stays out of the document.
- The exploitation path is recorded step by step, so your team can repeat it and confirm the fix.
What's included
The scope below is the default for a typical engagement. Everything is adjustable during scoping, at no cost.
- Authentication, session handling and password recovery
- Horizontal and vertical authorisation per object
- Injection in queries, commands and templates
- Business logic and flows that can be bypassed
- File upload, processing and serving
- Header, cookie and CORS configuration
- Resource enumeration and predictable identifiers
- Access control across accounts and tenants
- Schema validation and unexpected type handling
- Rate, cost and automated abuse limits
- Service-to-service authentication and secret rotation
- Excessive data exposure in responses
- Exposed edge surface and forgotten services
- Unsupported versions and pending patches
- Segmentation between environments and networks
- Internal services reachable from the perimeter
- TLS configuration and traffic termination
- Lateral movement from an initial foothold
- Identity provider and federation flows
- Second factor: coverage, bypass and recovery
- Inherited privilege and permission accumulation
- Service accounts and credentials in code
- Multi-device sessions and revocation
- Sign-up and onboarding of new users
- Android and iOS apps, including local storage
- App-to-API communication and certificate pinning
- Tamper protection and behaviour on a compromised device
- Corporate Wi-Fi, guest network and the separation between them
- On-premises infrastructure and what it reaches in the cloud
- Kiosks, terminals and shared-use devices
- Injection: SQL, NoSQL, LDAP, command and template
- Authentication, authorisation, IDOR and privilege escalation
- SSRF, XXE and insecure deserialisation
- Business logic and payment flow flaws
- XSS, CSRF and clickjacking with demonstrated impact
- Weak cryptography, predictable tokens and fragile JWTs
Modalities
adjustable to scopeBlack box
We start with no privileged information, in the same position as an outside attacker. It measures what your surface hands to a stranger, and it regularly surfaces assets nobody knew were exposed.
Grey box
We receive credentials and an architecture overview. This covers the most ground in the same window, because effort goes into exploitation instead of reconnaissance — and it is where authorisation flaws surface.
White box
Access to code, configuration and documentation. It reaches paths that rarely appear from outside, such as race conditions, error handling and sensitive logic buried under several layers.
When a pentest tends to pay off
This is not an annual box-ticking exercise. There are moments when the test returns more than it costs, because the surface has changed or because someone outside is about to ask.
A rewrite, a new identity provider or an environment migration all move assumptions nobody revisits. Testing before the change is cheaper than discovering afterwards with real traffic on top.
Enterprise contracts, security questionnaires and procurement processes routinely require an independent test. The report answers them objectively, without relying on self-assessment.
New team, new service, new integration. Rapid growth creates surface nobody has fully mapped, and permissions granted as a temporary measure that were never rolled back.
Legacy internal systems, admin panels and old integrations tend to sit outside every scope for years — precisely because they are considered too internal to worry about.
How we conduct it
[pipeline]Scope and rules of engagement
Before a single packet leaves, we put in writing what is in scope, what is out, which windows are allowed and who gets called if anything goes off plan. We also agree the stop criterion for critical findings, so a serious discovery reaches you the same day instead of waiting for the report.
Reconnaissance and mapping
We build the real surface: domains, subdomains, exposed services, technologies, entry points and whatever is already public about the environment. This is the stage that surfaces assets missing from the inventory — a reachable staging environment, a forgotten panel, a service spun up for a test and left running.
Scanning and triage
Automation belongs here, and only here: it covers volume and proposes candidates. Every result goes through manual triage, because most of what a tool flags does not hold up when someone tries to reproduce it. What survives becomes an exploitation hypothesis.
Manual exploitation
This is where a test separates itself from a scan. We chain flaws, probe business logic, attempt privilege escalation and try to reach data that should be protected — always within the agreed rules and without touching production availability.
Post-exploitation and reach
Finding the door is not the point: what matters is where it leads. We measure the reach of an initial foothold, what can be read, changed or persisted from it, and whether another system becomes reachable. That measurement is what turns a technical rating into business risk.
Report and retest
The report carries the reproducible path, the impact and the recommended fix, with the executive reading kept separate from the technical detail. After remediation we retest the treated items and record what closed — because a fixed finding only counts once someone confirms it.
Public references behind the work
We work on open, recognised methodologies. That makes scope comparable between vendors and lets your auditors check what was covered without taking our word for it.
- OWASP WSTG
- The OWASP Web Security Testing Guide organises coverage by category — authentication, session, authorisation, validation, business logic — and gives a clear basis for showing what was verified.
- OWASP API Security
- The API risk list covers what traditional web testing handles poorly: object-level authorisation, excessive data exposure and unrestricted consumption.
- PTES
- The Penetration Testing Execution Standard describes the phases of a test, from pre-engagement through reporting, and it is the backbone of the flow above.
- MITRE ATT&CK
- The catalogue of adversary tactics and techniques names what was executed, so your defence team can line each step up against what detection saw — or missed.
- NIST SP 800-115
- The NIST technical guide to security testing defines planning, execution and post-test activity, and it is the reference most often cited in contractual requirements.
- CVSS
- Scoring standardises technical severity, but it enters as an input: prioritisation follows the impact in your context, spelled out in plain text alongside the number.
Deliverables
dual view · NDAExecutive summary
A short read for whoever owns budget and priority: what was tested, what represents real risk and what needs a decision. Written without jargon, so it holds up in front of a board.
Findings with full reproduction
Each item carries the path step by step, with request, response and evidence. A developer can reproduce it without asking for clarification, and without depending on whoever ran the test.
Impact and priority assessment
Technical severity and business impact appear separately, because they do not always align. The suggested order accounts for remediation effort, so the team does not start with the most expensive and least urgent item.
Specific remediation guidance
Advice applied to your code and your architecture, not a generic paragraph copied from documentation. Where more than one route exists, the report describes the trade-off of each.
Cross-check against your monitoring
A summary of what we executed, mapped by technique, so your detection team can compare it with what logs and alerts captured. It often reveals as much as the vulnerability list.
Retest and closing letter
After remediation we revisit the treated items and record the final state. The letter serves customers, partners and auditors who need evidence that the cycle was closed.
Frequently asked
By default we do not test availability. Denial of service and any high-risk action stay out of scope unless explicitly requested with an agreed window. If a test could affect production, it moves to an equivalent environment or runs in an agreed window, with a direct line open from start to finish.
A defined scope, test credentials for each user role and an available technical contact. If edge protection could block the test, we decide together whether it is in scope or gets an exception — testing the block and testing the application are different objectives.
A scan compares what it finds against a known database and returns a list. A pentest attempts exploitation, chains flaws and measures how far access reaches. Scanning is cheap and works for continuous monitoring; manual testing answers what the list cannot — whether that item is exploitable in your context.
Yes. The executive summary is written for non-technical readers and can be shared with a customer, partner or auditor. Technical detail sits in a separate section, and the closing letter issued after retest is the document typically accepted as evidence in procurement.
It depends on the risk. A staging environment faithful to production is preferable when one exists, because it allows more aggressive testing. When only production exists — the common case — we restrict destructive actions, agree a window and keep a channel open throughout.
The stop criterion agreed at the start applies: a critical finding is reported immediately, with the minimum you need in order to act, without waiting for the final report. If the case calls for it, execution pauses until containment is in place.
It depends on your rate of change. An application shipping continuously changes surface every week, and an annual test looks at a system that no longer exists. A common practice pairs periodic testing of the main scope with targeted testing at each structural change — a new integration, a new identity provider, a new environment.
Ready to uncover your flaws?
First scoping call is free and covered by NDA. Within 48 hours you receive technical proposal, scope and timeline. No bureaucratic forms.