Every assessment we run follows the same documented structure: a scope agreed in writing, coverage mapped to public standards, controlled exploitation, and findings your team can reproduce without us in the room. This page describes that structure end to end, so you know what you are buying before you sign.
Our test plans are built on public methodologies, so coverage is defined before testing starts and auditable after it ends.
Standards matter for two reasons. The first is repeatability: when a test plan maps to OWASP WSTG or NIST SP 800-115, two testers working the same scope check the same classes of weakness, and a retest next year measures against the same baseline. The second is coverage you can audit. Each report states which sections of the relevant framework were exercised, which were out of scope, and why, so an auditor or a customer can verify depth instead of taking our word for it. We treat these frameworks as working references that structure the assessment, not as badges. Experienced testers go beyond any checklist, but the checklist guarantees the floor.
Six phases, run in the same order on every assessment. The names vary slightly by discipline; the discipline behind them does not.
Before any traffic is sent, we agree in writing on what is in scope, what is explicitly out, and what a realistic adversary would target first. We review your architecture, identify the assets whose compromise would actually hurt, and shape the test plan around them rather than spreading hours evenly across everything with an IP address. Scoping also settles the practical details: written authorization, test windows, credentials and roles for authenticated coverage, and named escalation contacts on both sides.
We enumerate the attack surface as an outsider would see it and as your documentation says it should be, then reconcile the two. For applications that means walking every workflow, cataloging endpoints, parameters, and roles; for networks it means host discovery, service fingerprinting, and trust relationship mapping; for external work it includes exposed services, DNS records, and credential exposure relevant to the scope. The gap between the surface you think you expose and the surface you actually expose is where a large share of findings originate.
Suspected weaknesses are confirmed by manual exploitation under controls agreed at scoping. We prove that a vulnerability is real and reachable, not that a scanner flagged a version string. Exploitation is deliberate and measured: payloads are chosen to demonstrate the flaw with the smallest possible footprint, availability-threatening techniques are excluded unless you have requested them, and anything with uncertain side effects on a production system is discussed with your team before we proceed. Where individual findings chain into a longer attack path, we follow the chain, because that composite path is usually the finding that changes your priorities.
Access by itself is not impact. Once a foothold is confirmed, we establish what it is actually worth: which data becomes readable, which privileges can be escalated, which adjacent systems become reachable, and how far lateral movement extends within the authorized scope. Impact is demonstrated with restraint. We access the minimum data needed to prove the point, record evidence, and go no further. The result is a defensible statement of blast radius that lets you rank remediation by consequence instead of by raw CVSS arithmetic.
Findings are written up as they are confirmed, not reconstructed from memory at the end. Critical issues are reported to you the day we validate them, with an interim writeup sufficient to start remediation immediately. The full report follows within five business days of testing completion and is reviewed by a second senior practitioner before delivery. Every engagement closes with a debrief call where the testers walk your team through the findings, answer implementation questions, and discuss what the results say about your wider posture.
Every assessment includes one retest of fixed findings at no additional cost. When your team reports issues resolved, the original tester verifies each fix against the original reproduction path, checks for common incomplete-fix patterns such as filters that block one payload variant but not another, and issues an updated report reflecting verified status. Between report delivery and retest, your engineers can contact us with remediation questions and reach the person who wrote the finding.
Each finding carries a CVSS v3.1 base score with the full vector string, so your team can recompute the rating and challenge any component of it. We publish the vector rather than a bare number because the reasoning is the useful part: whether an attack requires authentication, user interaction, or adjacency changes what you should do about it.
Base scores are then read against your business context. A server-side request forgery that reaches a cloud metadata service in your production account is a different problem from the same bug in an isolated staging network, and the report says so explicitly. Where our contextual severity departs from the raw CVSS output, both figures appear with the rationale, so your risk register stays consistent and defensible.
Reports are written for two audiences at once. The executive summary gives leadership an honest picture of posture in plain language. The technical body gives engineers everything needed to reproduce, understand, and fix each issue without a call to us, although the call is always available.
Offensive work on production systems demands operating discipline. These rules are written into every engagement agreement and hold regardless of deadline pressure.
Our default posture is non-destructive. Denial-of-service techniques, resource exhaustion, and destructive payloads are excluded unless you explicitly commission them against a system you designate. Exploitation payloads are selected to demonstrate a vulnerability with minimal side effects, test artifacts are tagged so your team can identify them, and any change we make to a target state is recorded and reversed where possible.
Fragile systems get special handling. Legacy platforms, operational technology, medical devices, and anything your team flags as brittle are tested under coordination agreed at scoping, in defined windows, sometimes with your engineers on a call while specific tests run. We also maintain deconfliction with your defensive side: source IP addresses are shared in advance where you want them, testing windows are logged, and your SOC or MDR provider can confirm within minutes whether observed activity is ours. If you prefer to test detection, we can withhold that notice by agreement instead.
Data encountered during testing is treated as radioactive. We extract the minimum needed as evidence, redact sensitive values in reports, store engagement material encrypted with access limited to the assigned team, and destroy it on the schedule defined in your agreement. Communication follows a fixed cadence: a kickoff call before testing, standing status updates on the agreed rhythm, immediate notification when a critical finding is confirmed, and a closing debrief. You are never guessing what phase the engagement is in.
Knowledge level is a test parameter, not a price tier. What we know at the start determines where testing hours go and which classes of flaw the assessment can reach, so we set it deliberately at scoping.
No credentials, no documentation, no internal contacts beyond the escalation path. We assemble the target picture ourselves, exactly as an outside attacker would, so the results show what is reachable without any insider advantage and how much of your environment can be reconstructed from public sources. The methodological cost is depth: hours spent discovering what you could have handed us are hours not spent testing behind authentication.
We receive standard user credentials and basic environmental context, then operate as an authenticated attacker or a compromised account would. Gray box is the default we recommend for most application and internal network work: it reaches authorization flaws, privilege escalation paths, and cross-tenant issues that black box testing rarely touches, while preserving a realistic attacker perspective on everything beyond the initial access.
Discovery is removed from the equation. With source code, architecture documentation, admin-level access, and time with your engineers, testing effort goes straight to verification. The result is the highest defect density per hour of any model, plus coverage of flaws that are effectively invisible from the outside, such as logic errors buried in code paths an attacker would need months to reach blind. It is the right model for security-critical components and pre-release reviews.
Any model can run as a one-time assessment or as part of a continuous program. One-time engagements answer point-in-time questions such as a release gate, a customer requirement, or a due diligence deadline. Continuous programs repeat this same lifecycle on a schedule, which changes the economics of every phase: context persists between cycles, rediscovery shrinks, and testing hours migrate toward whatever changed since the last pass.
A scoping conversation takes less than an hour and produces a concrete test plan with defined coverage. If we are not the right fit for the work, we will say so.