How we test
The same sequence on every engagement, so the result is defensible — not dependent on who happened to be testing that week. Testing follows PTES and NIST SP 800-115, application work follows OWASP, and exploitation maps to MITRE ATT&CK.
Five phases, start to retest
Automated tooling enumerates the surface area. A named tester confirms every finding by hand.
The point of a fixed process is not bureaucracy. It is that your auditor, your engineers and your next tester can all see exactly what was done, why, and what was found — without taking our word for it.
What we test against
We do not invent our own methodology. We follow the ones your auditor already recognizes.
PTES
The Penetration Testing Execution Standard — the backbone of every engagement, from pre-engagement through reporting.
NIST SP 800-115
The technical guide to information security testing, the reference US assessors expect testing to align with.
OWASP
The Web Security Testing Guide, Application Security Verification Standard, and API and Mobile Top 10.
MITRE ATT&CK
The adversary tactics and techniques our exploitation and reporting map to, so findings speak your defenders’ language.
Written to be used, not filed
A finding you cannot reproduce is a finding you cannot fix.
- Reproduction stepsEvery finding, repeatable by your team without us.
- CVSS v3.1 in contextBase score plus what it means where it sits in your environment.
- Control mappingTied to the SOC 2, PCI, HIPAA or NIST control it defeats.
- Remediation guidanceWritten against your stack, not copied from a template.
SEVERITY · CRITICAL · CVSS 9.1
Insecure direct object reference exposes cross-tenant records
The /api/v2/invoices/{id} endpoint returns any invoice by numeric id without checking that the authenticated user owns it. Incrementing the id enumerates every tenant’s billing data.
Maps to · SOC 2 CC6.1 · OWASP API1:2023
How the work runs
Do you test in production or staging?
Either, and we agree it in scoping. Most web and API testing runs against a staging environment that mirrors production, which removes any risk to live data. Where only production exists we test with agreed rate limits, a defined window, and destructive actions explicitly out of scope. Internal network and assumed-breach work is almost always against the real environment, because that is the environment being defended.
What do you need from us before starting?
A signed scope and rules of engagement, credentials for each user role in scope, any allow-listing so your WAF does not simply block the test, and a technical contact for escalation. For cloud work we need read-level access to the accounts in scope. We send a short checklist after the scoping call so nothing blocks the start date.
How do you handle a critical finding mid-engagement?
We stop and tell you the same day. A critical finding — something an attacker could exploit now for serious impact — is not held back for the final report. You get the details, a reproduction, and an interim mitigation immediately, so remediation can begin while the rest of the test continues.
Will testing take our systems down?
No. We do not run denial-of-service or load tests unless you specifically ask for them, and destructive actions are out of scope by default. Exploitation is done under controlled conditions with placeholder data. If a system is fragile enough that careful testing risks it, that is itself a finding worth knowing about.
Ready to scope an engagement?
Thirty minutes tells us what to test. You get a fixed price and a start date, usually within the hour.