Authorisation and scope
How we engage
We test systems only with written authorisation from the people who own them, inside a scope and rules of engagement both sides have signed. These are the rules every engagement runs on.
Written authorisation comes first
We carry out penetration testing and red teaming only with prior written authorisation from a person who has the authority to grant it for every system in scope. Before any work starts we confirm who that person is and that the authority is theirs to give.
A verbal go-ahead is not authorisation. Nor is an email from someone who does not control the systems, or a request to test systems the requester does not own.
A signed scope
Every offensive engagement has a written scope, signed before testing begins. It sets out:
- Targets: the named applications, hosts, address ranges, accounts or environments we may test.
- Exclusions: anything we must not touch, even if it is reachable from a target.
- Testing windows: the dates and times when testing may take place.
If the scope needs to change during an engagement, the change is agreed and signed in the same way before we act on it.
Rules of engagement
Alongside the scope, signed rules of engagement set out how the testing is done:
- The techniques that are allowed, and the techniques that are forbidden.
- How we handle any data we can see or reach during testing.
- Emergency stop contacts on both sides, available throughout the testing windows.
- How we report a critical finding while testing is still under way.
- Any conditions that apply to testing production systems.
Either side can stop testing at any time through the emergency contacts. If the client asks us to stop, we stop.
Third-party permission
Many systems run on infrastructure someone else owns, such as cloud providers, hosting companies and SaaS vendors. Where their terms require notice or permission before testing, we confirm it is in place before we start and we stay within those terms. If a provider does not allow something to be tested, it is out of scope.
Staying in scope
We do not test anything outside the agreed scope, and we do not use access gained during an engagement to reach systems that are not in it.
If we find we have touched an out-of-scope or third-party system by accident, we stop that activity and notify the client’s contact, then record what happened in the report.
Red-team control group
Every red-team engagement runs with a named control group on the client’s side, often called the white cell. Its members know the engagement is running, approve its objectives and rules of engagement, are kept informed throughout, and can halt activity at any time.
The control group is also our point of contact if we come across signs of a real intrusion, or if our activity is mistaken for one, so the two can be told apart quickly.
Findings and client data
- We access only what the engagement needs.
- Findings, evidence and client data are available only to the people working on the engagement.
- We use client data only for the engagement it was collected for.
- We share findings only with the people the client names.
- At the end of the engagement, we remove or return client data as agreed in the contract.
Reporting, debrief and retest
Each engagement ends with a written report covering the scope, the method, every finding with its evidence and remediation guidance, and anything we could not test. We walk the client’s team through it on a debrief call. Fixed findings are retested within the window agreed in the contract, and the results are recorded in writing.
Work we decline
We decline work we cannot verify is authorised. We test systems only for their owner, or for someone acting with the owner’s written permission. We do not test systems on anyone else’s behalf, and we do not take on work whose aim is to get into systems without their owner’s consent.
Defensive engagements
Managed detection and response, incident response, threat hunting and detection engineering run on the access the client grants us, and only that access.
Containment actions, such as isolating a host or disabling an account, follow the playbooks the client has approved. Anything outside an approved playbook goes to the client’s named contact for a decision first.
Questions about an engagement
If you want to know how we would run a particular engagement, or check whether a request is something we would take on, get in touch before anything else.