How we test, written down before you hire us.

Before anything is touched we agree in writing what is in scope, what is explicitly off limits, when testing will run, and who we call if something breaks. Nothing outside the agreed scope gets tested, ever.

We need from you

Asset list, environment details, points of contact, and written authorisation to test

We agree

Testing window, rules of engagement, escalation path, and whether we test production or a staging copy

Off limits by default

Denial-of-service, physical intrusion, and social engineering of your staff, unless you specifically ask for them

We map what is genuinely reachable from outside, which is regularly more than the asset register says. Forgotten subdomains, a staging server left public, an old admin panel nobody decommissioned.

Covered

Subdomain and service enumeration, exposed ports, technology and version fingerprinting, public credential and code leaks

Method

Automated discovery to establish breadth, then manual review to establish what actually matters

The bulk of the work. Tooling establishes coverage; the findings that matter almost always come from a person working through the application by hand. Anything critical is reported to you the same day — we don’t hold a serious finding back to make the final report look impressive.

Reference standards

OWASP Testing Guide and OWASP Top 10, OWASP MASVS for mobile, CIS Benchmarks for configuration, MITRE ATT&CK for technique coverage

Manual focus

Business logic, access control between accounts, authentication and session handling, payment and form abuse — the classes scanners systematically miss

Evidence

Every finding gets reproduction steps and a screenshot or request capture, so your developers can confirm it themselves

Safety

No destructive testing. If we find something that could cause an outage to exploit, we describe it and stop rather than proving it on your production system

Findings are rated against your context, not a generic scale. An exposed test endpoint on an isolated network is not the same risk as the identical endpoint in front of your customer database, and a report that pretends otherwise wastes your time.

Basis

CVSS as a starting point, then adjusted for exploitability in your actual environment and the sensitivity of what is behind it

Removed

False positives are verified and discarded. We don’t pad a report with unverified scanner output

One document, two audiences. An executive summary that a board can act on without a translator, and a technical section with enough detail for a developer to fix the issue without emailing us first.

Per finding

Severity, plain-language explanation of the business risk, reproduction steps, evidence, and a specific remediation step

Prioritised

A short ordered list of what to fix first, because “forty-one findings” is not an action plan

Formats

PDF report, plus a spreadsheet of findings if your team tracks remediation in a ticket system

We talk the report through with your team, technical and non-technical in the same session where possible, so the fix list is agreed rather than merely delivered. Questions afterwards are included; we don’t bill for explaining our own findings.

Once fixes are in, we verify them and reissue the report showing what has been closed. One retest round is included in every engagement — a finding you believe is fixed but isn’t is arguably worse than one you know about.