Independent offensive security practice
Every finding proven. Nothing asserted.
- Practice
- Independent, single operator
- Disciplines
- Web · API · Network · Cloud · Mobile
- Standards
- PTES · OWASP ASVS · MITRE ATT&CK
- Authorisation
- Written, before any packet
We test your applications, networks and cloud the way an attacker would — then hand your engineers evidence, reproduction steps and a fix, instead of a scanner export with the false positives left in.
Cross-tenant order takeover via unauthorised object reference on /api/v2/orders/{id}
- Evidence
- Sequential ID sweep returned 1,204 order records belonging to other tenants, including delivery addresses and partial card data. No session token required. Full request and response pairs attached.
- Impact
- Any unauthenticated party on the internet can enumerate the entire order history of every customer on the platform.
- Remediation
- Enforce tenant scoping in the order repository layer rather than the controller, and add an authorisation test per endpoint to the CI suite.
Every finding we report is presented like this. If it cannot be reproduced by hand from a clean session, it does not ship as a finding — it ships as an observation, with the uncertainty stated.
01 — Services
Testing that matches how you were actually built.
Six engagements cover most of what teams need. Scope is agreed before anything is quoted — we would rather test one surface properly than four of them shallowly.
02 — Deliverables
What lands in your inbox.
A report is only useful if two very different people can act on it: the executive who signs off on the risk, and the engineer who writes the patch on Monday.
- Executive summary
- Two pages: what we found, what it means commercially, what to fix first. No vector strings, no tool names.
- Evidence pack
- Raw requests and responses, screenshots and exact reproduction steps, so your team can confirm each issue before touching code.
- CVSS 3.1 scoring
- Every metric in the vector justified in writing. Where we deviate from the base score for your environment, we say so and explain why.
- Remediation
- Written against your stack. If you run Django behind Cloudflare, you get the Django fix — not a link to a generic advisory.
- Findings export
- JSON and CSV of every finding, ready to import into Jira, Linear or your GRC platform without retyping.
- Retest & attestation
- One round of verification after you remediate, plus a summary letter for customers, auditors or your insurer.
03 — Next step
Start with a scoping call, not a quote.
Thirty minutes, no charge, no obligation. We work out what actually needs testing, what it will cost and when it can run. If a penetration test is not the right spend for you right now, we will tell you that too.
Services
Six engagements. Scoped honestly.
Every engagement includes a scoping call, a signed rules-of-engagement document, out-of-band alerting for critical findings, a full report and one retest. Pricing is fixed once scope is agreed — no hourly overruns.
Web application & API testing
Role-aware, authenticated testing of your product. We test the business logic a scanner has no concept of: can a trial user reach paid features, can tenant A read tenant B's data, can a refund be issued twice, can a workflow be skipped by calling step three directly.
External network & perimeter
We map what you actually expose, not what the asset register claims. Subdomain discovery, forgotten staging hosts, exposed admin panels, expired certificates and unpatched edge services — then we test what we find, safely, and in daylight hours if you prefer.
Internal network & Active Directory
We assume one laptop is already compromised — because that is how it happens — and work outwards. Credential harvesting, Kerberos abuse, share enumeration, misconfigured delegation, and the shortest realistic path from standard user to domain admin.
Cloud configuration review
A read-only review of AWS, Azure or GCP: over-permissive IAM roles, public storage, unrestricted security groups, secrets in build logs, and CI/CD pipelines that can be made to deploy code they should not. Delivered as prioritised, copy-pasteable policy changes.
iOS & Android application testing
Static analysis of the binary, dynamic testing on a rooted or jailbroken device, and full testing of the backing API. Covers local data storage, certificate pinning, deep-link handling and whether client-side controls can simply be removed.
Phishing & social engineering
A controlled campaign against an agreed employee group, run with your HR and communications teams informed. We measure click rate, credential submission and — the number that matters — how quickly somebody reported it. No individual is ever named in the report.
07 — Models
Three ways to buy it.
| Model | How it runs | Cadence | Suits |
|---|---|---|---|
| Point-in-time | A single scoped engagement with a fixed start and end date, full report and one retest. | Once | Compliance deadlines, customer security reviews, board assurance. |
| Pre-launch | Testing folded into your release schedule, with findings raised in your tracker as they are confirmed rather than held to the end. | Per release | Teams shipping a major version or entering a regulated market. |
| Continuous | A recurring block of testing days each quarter, aimed wherever your risk moved, with a rolling findings register. | Quarterly | Products that change weekly, where an annual test goes stale in a month. |
Method
The same seven phases, every engagement.
We run the Penetration Testing Execution Standard end to end. It is not the only good methodology, but it is a published one — which means you can audit our work against something other than our word for it.
Pre-engagement interaction
Scope, timing, escalation contacts and the rules of engagement, all in writing. We agree what is in scope, what is explicitly out, what happens if we find something critical at 11pm, and who is authorised to stop the test. Nothing is touched before this is signed.
Intelligence gathering
Passive and active reconnaissance of your real footprint: DNS and certificate transparency, exposed services, technology fingerprints, code and credentials leaked to public repositories, and staff information relevant to a social engineering path.
Threat modelling
Before testing, we decide who realistically attacks you and what they want. A payments platform and an internal HR tool have entirely different threat actors, and testing both against the same generic checklist wastes your budget.
Vulnerability analysis
Automated tooling runs first, because it is cheap and fast — but its output is treated as a list of leads, never as findings. Every candidate is then examined by hand against the actual application behaviour.
Exploitation
We prove the issue is real by exploiting it, within the limits set in the rules of engagement. We take the minimum action needed to demonstrate impact — enough records to prove access, never the whole table; a proof of code execution, never a persistent implant.
Post-exploitation
From each foothold: what else becomes reachable, what data is exposed, and what an attacker could do with persistence. This is where a medium-rated issue often turns out to be the first step in a critical chain.
Reporting & retest
Draft report within five business days of test close, a walkthrough call with your engineers, then a retest once you have remediated. Anything that fails retest goes back on the register — it does not quietly disappear.
08 — Verification
Nothing is reported until it is reproduced.
The most common complaint about penetration test reports is that engineers waste a week disproving findings that were never real. So there is a gate between "the tool said so" and "it is in your report."
- Gate 1 — Reproduce
- The issue must be triggered by hand, at least twice, from a clean session. Anything that appeared once under an unusual state is investigated further, not reported.
- Gate 2 — Impact
- We must be able to state what an attacker gains in concrete terms. "Could theoretically allow" is not an impact statement; it is a guess, and it gets downgraded.
- Gate 3 — Evidence
- Request, response, screenshot and exact steps go in the appendix before the finding is written up — so you can verify our claim without taking our word for it.
A candidate that fails any gate is still disclosed to you, but as an Informational observation with the uncertainty stated plainly. It never inflates the severity counts on your summary page.
09 — Severity
How severity is decided.
Base scores come from CVSS 3.1. We then adjust for your environment — a critical on an internet-facing payment path is not the same risk as the identical bug on an isolated internal tool — and we always show both numbers.
| Rating | CVSS | What it means for you | Our response |
|---|---|---|---|
| Critical | 9.0–10.0 | Exploitable now, from the internet, with serious data or financial consequence. | Called within 24h |
| High | 7.0–8.9 | Significant compromise, but needs a precondition such as an account or adjacent access. | Called within 48h |
| Medium | 4.0–6.9 | Real but limited impact, or a strong link in a larger attack chain. | Final report |
| Low | 0.1–3.9 | Minor exposure or hardening gap with little standalone consequence. | Final report |
| Informational | 0.0 | No direct security impact, or unproven. Worth knowing, not worth panicking about. | Appendix |
10 — Coverage
Coverage, shown as coverage.
Each report opens with this: every test case in the applicable standard, and whether we ran it. Solid means tested, hollow means not applicable to your scope — and the report says why for each one.
Illustrative figures from a representative web application engagement. Your coverage map is generated from your agreed scope.
Practice
A small practice, deliberately.
The person who scopes your engagement is the person who tests it and the person who writes your report. Nothing is passed to a junior after the sale.
11 — The name
Why "Full Check".
Most testing stops early. A scanner finishes, a report is generated, boxes get ticked — and the interesting half of the attack surface is never looked at, because looking at it takes a person and time.
A full check means the methodology is run to the end, every finding is proven before it reaches you, and the things we did not test are written down as plainly as the things we did. You should finish reading a report from us knowing exactly where the edges of your assurance are. That is the whole idea, and the name is there to keep us honest about it.
12 — Commitments
Four commitments.
- Authorisation first
- No packet is sent until scope and written permission are signed, and we test only what that document names. If we spot something interesting just outside scope, we tell you — we do not go and look.
- Minimum force
- We prove impact with the smallest action that demonstrates it. No destructive testing, no denial of service unless you have explicitly commissioned it, no data taken beyond what evidences the finding.
- Your data stays yours
- Evidence is stored encrypted, kept only as long as the engagement and retest require, then destroyed on a documented schedule. Client names are never used as references without written permission.
- We will talk you out of it
- If a penetration test is not the right next spend — because you have no logging, no patching process, or no asset inventory — we will say so on the scoping call and tell you what to fix first.
13 — Standards
What we test against.
Published standards, so the work can be checked against something external. Where your auditor or customer requires a specific framework, we map findings to it in the report at no extra cost.
Enquire
Book a scoping call.
Thirty minutes, no charge. Submit the brief below and we reply within one business day — or use "Email directly" if you'd rather not use the form.
Your scoping brief
Before the call
- Asset list
- Domains, applications or IP ranges you think are in scope. Approximate is fine — refining it is part of the call.
- Authoriser
- We need written authorisation from someone who owns the systems. Knowing who that is early avoids a two-week delay.
- Hard dates
- Audit deadlines, release windows, change freezes — anything the test has to fit around.
- Fragile systems
- Anything that must not be touched, third parties needing notice, or hosting providers with their own authorisation process.