Testing methodology

A result is only called confirmed when all six of these are recorded: who could abuse it, where they would enter, which control is missing, which trust boundary is crossed, which resource is affected, and what we actually observed happening. If any part is missing, it is not a finding.

A missing best practice with no demonstrated effect is recorded as hardening advice, not as a vulnerability. That distinction is shown on every result and carried into reports.

Confirmed — we observed the behaviour ourselves and stored the evidence. Likely — strong indicators, one step of proof missing, with the blocker and the plan to close it written down. Possible — worth a human look, nothing proven.

We do not raise an issue because a page returned a response, a header was absent, or a version number looked old. Content has to actually show the problem.

Anything that sends real attack traffic — web and API testing, the autonomous pentester, AI endpoint probing — runs only inside a named engagement with a signed authorisation, ownership re-checked at the moment the run starts, and a fixed time window. Requests are rate limited, capped in total, and kept inside the scope and blocklist you set.

Cloud reviews are read-only. Credentials are encrypted before storage and are never returned to the browser. Anything your key cannot read is reported as "not checked" — never as a pass.

No exploitation beyond proof, no data exfiltration, no destructive actions, no testing of targets you have not authorised, no agents installed on your machines, and no invented results to fill a report. Where a capability is not connected yet, the page says so.

Compliance packs map your testing records to framework controls. They report the evidence you hold — they are not an audit, a certification, or a claim of compliance. Controls that testing cannot prove are listed separately with the documents you need to supply.