Frequently asked questions

A penetration test asks what is vulnerable: it works through an agreed scope and reports the weaknesses found in it. A red team engagement asks whether your detection and response actually work. It is objective-based rather than scope-based, reach a specific system, obtain a specific dataset, and it is scoped across people, process and technology rather than a fixed list of hosts. If you have never had a test, start with a penetration test; a red team engagement is most useful once you have a security team whose response you want to measure.

A technical report with reproduction steps for every finding, so an engineer can confirm and fix each one, and a separate summary written for people who will not read the technical detail. Findings are ranked by what they let an attacker do rather than by raw CVSS score, because a medium-severity issue that chains into domain admin matters more than an unreachable high.

Yes. A report you cannot verify against is only half the work, retesting confirms the fix actually closes the path, rather than moving it.

Testing is scoped with you before anything starts, and destructive techniques are agreed explicitly rather than assumed. Denial-of-service testing is excluded by default. Where a system is too sensitive to test live, the usual answer is a staging environment that matches production, or a tightly agreed window with someone from your team on call.

Findings and any data encountered are treated as confidential, handled only as far as is needed to demonstrate impact, and not retained beyond the engagement and its reporting. If evidence needs to include sensitive records, it is redacted to the minimum that proves the finding.

A description of the environment and what matters most in it, the scope you want covered, written authorisation to test, and a technical contact who can be reached if something needs stopping. For authenticated testing, credentials at the privilege levels you want assessed.

Yes. Cloud testing follows the privilege paths through your account the way an attacker with an initial foothold would, rather than linting configuration in isolation. Most cloud compromise is an identity problem rather than an exploit. API testing covers object- and function-level authorisation, undocumented endpoints still serving traffic, and abuse of the endpoints that cost you money.

Yes. An LLM feature widens your trust boundary: text from a document, a web page or another user becomes something the system acts on. Testing covers direct and indirect prompt injection, including via retrieved content, what the model can be persuaded to disclose, and what any connected tools or function calls can be made to do.

Incident response is one of the services offered. The immediate priority is containment without destroying the evidence needed afterwards, then eviction and recovery, then a root-cause account of the entry point, the dwell time and the spread, because that is what stops it happening a second time. Get in touch and say clearly that it is active.

Engagements are scoped to your estate and your risk rather than sold as package tiers, so cost follows scope. Describe what you want tested and we will scope it with you before any commitment.