Methodology

Every engagement runs the same five stages, against the same published standards, with the same rules about what we will and won’t do to a production environment. You should know all of it before you sign anything.

What we test against

We don’t invent our own methodology and ask you to take it on faith. Testing maps to the public standards your auditor already recognizes, which is what makes the results defensible when someone else reviews them.

  • PTES, the Penetration Testing Execution Standard, for overall engagement structure.
  • NIST SP 800-115, the technical guide to information security testing and assessment.
  • OWASP Web Security Testing Guide and the OWASP Top 10 / API Security Top 10 for application work.
  • MITRE ATT&CK for describing the techniques used, so your detection team can map what we did to what they saw.
  • CIS Benchmarks as the configuration baseline for cloud and host review.

Stage 1: Scope

Nothing gets touched until scope is agreed in writing. We settle target ranges and domains, which techniques are in and out of play, the testing window, and who to call at 2am if something breaks. You get a written authorization to sign, and we keep a copy for the duration of the engagement.

This is also where we tell you if you’re buying the wrong thing. If the honest answer is that a configuration review would serve you better than a full penetration test, we’d rather say so now than take the larger invoice.

Stage 2: Reconnaissance

Passive collection first. DNS, certificate transparency logs, public code repositories, breach corpora, and anything else an attacker would gather without ever sending you a packet. Then active enumeration inside the agreed scope: host discovery, port and service identification, technology fingerprinting, and content discovery on web assets.

This stage routinely surfaces assets nobody remembered to mention. A staging box with a public IP. An expired subdomain still pointing at a live service. A forgotten VPN appliance two versions behind. Those findings are often the most valuable part of the engagement, and they show up before any exploitation starts.

Stage 3: Exploitation

Every candidate finding gets manually verified. If a scanner flags something and we can’t reproduce it by hand, it doesn’t go in the report. It goes in a separate list of things we checked and ruled out, so you can see the work and not just the conclusion.

Confirmed findings then get chained the way a real attacker would chain them. A medium-severity information disclosure that leads to a credential that leads to domain administrator isn’t three medium findings. It’s one critical attack path, and we report it as one.

What we won’t do

  • No denial-of-service testing, and no exploits known to be unstable against production, unless you explicitly ask for it in writing.
  • No destructive actions. We prove access. We don’t delete, encrypt, or modify your data to make a point.
  • No exfiltration of real sensitive data. Where we need to prove we could read a database, we take the minimum sample needed to demonstrate it and record exactly what we took.
  • No pivoting outside the agreed scope, even when a path presents itself. We document that the path exists and stop.

Critical findings don’t wait for the report

If we find something that puts you at immediate risk, you hear about it that day, by phone, with enough detail to act on before we’ve written a word of the report. An unauthenticated path to sensitive data. An active compromise that predates us. Credentials already exposed publicly.

Stage 4: Reporting

One document, two audiences, no padding.

  • Executive summary. What was tested, what an attacker could achieve, and what it means in business terms. Written to be read by someone who isn’t an engineer.
  • Attack narrative. The path we actually took, start to finish, so your team can follow the reasoning and not just the findings list.
  • Technical findings. Each one with reproduction steps, evidence, affected assets, and a specific remediation. Not a link to a vendor advisory.
  • Risk ratings in your context. CVSS is included because auditors expect it, but the rating we argue for accounts for your compensating controls, your exposure, and your data. A critical CVSS on an isolated lab host isn’t a critical finding.
  • What we ruled out. The checks that came back clean, so the report evidences coverage and not only failure.

Stage 5: Retest

Once you’ve remediated, we verify the fixes and reissue the report with findings marked resolved. It’s included in the original price, because a test that tells you what’s broken without confirming you fixed it is only half the job.

The reissued report is what you hand to your auditor or your customer. It’s the version that shows the finding was closed, not merely reported.

Evidence handling

Findings, screenshots, captured credentials, and any data samples are held encrypted for the duration of the engagement and destroyed at the end of the retention period set in your contract. Credentials recovered during testing get reported to you and never reused. Full detail is in our privacy policy.

Questions worth asking any tester

Including us. If a firm can’t answer these plainly, that tells you something.

  • How much of the testing is manual, and what proportion of findings came from a scanner?
  • Will you show me what you ruled out, or only what you found?
  • Who specifically is doing the testing, and what have they done before?
  • Is a retest included, or is it billed separately?
  • What happens to my data when the engagement ends?

Ready to scope something? Tell us what’s in scope and we’ll come back with a fixed price and a testing window.