Authorised, in scope, every time
No testing starts until the scope is agreed in writing and your authorising signatory has approved it. Our tooling enforces that scope technically: targets outside it are refused, and the refusal is recorded.
Scope can change during an engagement. Removing a target takes effect straight away, but adding one, or lifting an exclusion, puts testing on hold until your signatory authorises the wider scope again.
Every authorisation also has an end date, agreed with your signatory. Once it passes, our tooling refuses to test any further, including scheduled monitoring, until you renew it. We keep a copy of the permission itself, such as your signed scope document or approval email, on file with the engagement, and your report notes that it is held, so there is never any doubt about what was agreed.
Honest coverage
Automated tools fail quietly. A scanner that can’t reach a target, or a check that is missing a dependency, often just returns nothing, and “nothing” looks like a clean result. We treat that as a problem. If a check couldn’t run, your report names it in a Scan Coverage section and explains why, so you always know what was tested and what wasn’t.
That includes depth as well as breadth. A port scan of the most common ports is not a full port scan, and the report says which one you got. If a web service or host couldn’t be reached, it is named rather than left out.
Retests that tell the truth
When we retest, every original finding is placed in one of a few clear categories: unchanged, changed, new, resolved, not retested, or newly covered. A finding is only marked resolved when we’ve actually retested it and confirmed the fix. Anything we couldn’t retest is labelled as such, never counted as fixed.
De-duplicated, triaged findings
Findings are de-duplicated across tools and across repeat scans, so the same issue never appears three times. Findings you’ve accepted, confirmed as false positives or fixed are tracked through their life, and any regression is flagged.
Clear, proportionate reporting
Low-value informational observations are summarised separately, so they don’t bury the issues that matter or inflate your risk score. Severity reflects real risk: a sample configuration file is not rated like a live one full of credentials. Leadership gets a concise executive summary. Your technical team gets reproducible detail.
Evidence without exposure
When we find something sensitive, such as an exposed file of credentials, the report proves it was exposed without repeating the secrets. Your report shouldn’t become a second copy of the problem.
Your data, handled securely
Your findings and reports are stored on our own server, and access to it is restricted to us. They are not uploaded to a third-party reporting platform.
A file and its password never travel by the same route. Your report is delivered encrypted, and the password is given to you separately by phone or text. Test account passwords and other secrets are never sent by email. Once the engagement is over, we delete our copies of any credentials and remind you to disable the test accounts.