What we test, how we test it, how findings are rated, and what we deliberately leave out, written so your engineers can hold us to it.
A security assessment is only as trustworthy as the method behind it. This page sets out ours in enough detail to be judged, and to be challenged.
The same sequence every time. Nothing proceeds to testing until authorization and rules of engagement are signed.
We review your assets, architecture, and objective to define what should be tested and why.
A written proposal states the scope, approach, deliverables, and commercial terms.
Authorization, in-scope and out-of-scope assets, dates, techniques, and emergency stop conditions are agreed in writing.
Manual, evidence-led testing within the approved scope, with communication throughout.
Findings with reproduction steps, evidence, business impact, and specific remediation guidance.
A working session with your engineers to walk through findings and answer questions.
Your team fixes issues; we stay available for clarification on any finding.
We verify the fixes and record the resulting status against each original finding.
Automation is used where it is genuinely better than a person (enumerating an attack surface, checking dependency versions, fuzzing an input), and the reasoning is done by a human. The findings that matter most in modern products are authorization and logic failures, and no scanner understands what your application is for.
If we cannot reproduce it, it does not appear as a vulnerability. Suspicions are recorded as observations and clearly labelled, so you can tell the difference between what we proved and what we noticed.
A finding is described in terms of what an attacker gains and what it would mean for you, not only in terms of the technical class it belongs to. That is what makes prioritisation possible.
Real compromises are usually sequences rather than single flaws. Where individually modest issues combine into a serious path, we report the chain and rate it on the outcome.
Reproduction steps precise enough to follow, the affected component identified, and remediation guidance specific to your stack rather than a link to generic advice.
We test what was authorized and nothing else. If we notice something interesting outside scope, we tell you it exists and ask before going near it.
Ratings reflect exploitability and realistic business impact in your environment, not a generic score. The reasoning is written out for every finding, so a rating can be discussed on stated grounds.
| Severity | What it means |
|---|---|
| Critical | Directly exploitable with severe consequence: cross-tenant data access, authentication bypass, remote code execution, or full administrative compromise. Reported to you as soon as it is confirmed rather than held for the report. |
| High | Exploitable with significant consequence, possibly requiring a specific precondition such as an authenticated low-privilege account. Should be scheduled for prompt remediation. |
| Medium | Genuine weakness with meaningful but contained impact, or a serious issue whose exploitation requires conditions that are unlikely though possible in your environment. |
| Low | Limited direct impact. Often valuable to an attacker in combination with other findings, or a defence-in-depth improvement worth making. |
| Informational | Observations, hardening opportunities, and notes on design decisions. Not vulnerabilities, and labelled as such so they do not inflate the finding count. |
These inform our coverage. They do not replace judgement, and we do not claim certification against any of them.
An assessment examines a defined scope during a defined period, using the access and information available at the time. It cannot prove the absence of vulnerabilities, and any provider who implies otherwise is selling reassurance rather than security work.
A clean result means that within that scope and timeframe, this team did not find a particular class of problem. Your product will change after we finish. New research will appear. An attacker with more time, different information, or different motivation may reach a different result. This is precisely why continuous review often serves a fast-moving product better than an annual test.
We state these limits in every report, including which areas the scope or timeframe prevented us from examining. A report that quietly omits its own limitations is less useful than one that names them.
We use recognised references as coverage checklists, listed on this page, so that classes of issue are not missed. We do not claim accreditation, certification, or membership that we do not hold, and we do not issue certificates or seals.
What we offer instead is a documented method you can inspect before you engage us and hold us to afterwards.
It depends on the scope, and we set the duration during scoping once we understand the size of the surface, the number of roles and tenants, and the depth required. It is stated in the proposal before you commit.
We would rather quote a realistic duration for the work than publish a headline figure we would have to qualify afterwards.
You are told promptly, through the escalation route agreed in the rules of engagement, rather than at the end. A critical finding sitting in a draft report while your product remains exposed serves nobody.
We will also agree with you whether to continue testing, pause while you remediate, or adjust the scope in light of what was found.
Yes, and that is a normal part of the debrief. Because every finding has reproduction steps and every rating has stated reasoning, a disagreement can be resolved on evidence; for example, if a mitigating control exists that we could not observe from our position, the rating should change.
Where we agree, the report is corrected. Where we do not, both positions can be recorded so the disagreement is visible rather than buried.
Evidence collection is limited to what is necessary to demonstrate a finding. Evidence is stored securely, shared only through the agreed channel, and disposed of according to the retention terms in the engagement documents.
If we incidentally access personal data during testing, we minimise what we retain, record what happened, and tell you. Handling terms are agreed in writing before testing begins.
Start with a scope review. You will get a written scope, an approach, and a price before committing to anything.
