Rules of engagement
How we agree to behave, in writing, before we touch anything.
Most testing firms have rules of engagement and keep them in the contract. Ours are published, because the terms a tester will agree to are something you should be able to compare between suppliers — and because publishing them is the only way they constrain us in a way you can check.
Authorisation comes first, and it comes in writing
No testing starts until someone with the authority to permit it has said so, in writing, naming the scope.
- Who signsAuthorisation has to come from someone who can actually grant it — the system owner, or someone with delegated authority over it. A project manager's enthusiasm is not authorisation.
- Third-party systemsIf a system in scope is hosted, operated or owned by someone else, their permission is needed too. We will ask you to confirm it, and we will not test a third party's infrastructure on your say-so alone. Most cloud providers publish what they permit; some require notification.
- What the authorisation namesThe scope, the window, the techniques excluded, and the people on both sides who can stop the test. If it is not written down before the engagement, it is not agreed.
- Our own identificationOn request we confirm the source addresses our testing originates from, so your team can distinguish us from a real attacker in their logs.
Scope is explicit, and so is what sits outside it
An ambiguous scope is how production incidents and awkward invoices happen. We write down both halves.
- In scopeNamed hosts, applications, APIs, accounts, tenants and environments. Where a scope is defined by a range, we confirm what is live inside it before we touch anything.
- Out of scopeWritten down explicitly rather than left implied. Anything not named is out of scope until it is added in writing.
- Scope changes mid-engagementTesting reveals systems nobody mentioned — a forgotten subdomain, a shared service, an unexpected integration. We stop, tell you what we found, and ask before extending. We do not quietly widen the scope and we do not quietly ignore it.
- Discovery beyond the boundaryIf we can reach something outside scope from inside it, that is itself a finding. We report the reachability without exploiting the thing we were not authorised to touch.
Testing windows and production safety
Most testing is safe to run against production. The exceptions are predictable, and we agree them in advance.
- When we testAn agreed window, with the time zone stated. If you need testing confined to out-of-hours, say so at scoping rather than afterwards — it changes the plan, not just the clock.
- Production versus stagingWe will test production where that is what you need assured, because a staging environment with different data, different configuration and different scale answers a different question. Where production genuinely cannot absorb a class of test, we say so and we test it elsewhere.
- Rate and volumeWe control request rates deliberately. Where a test could plausibly degrade a service, it is throttled, scheduled or run against a non-production copy.
- What we do not do by defaultDenial-of-service testing, load testing and anything whose purpose is to exhaust a resource are excluded unless you specifically ask for them and we agree how.
Destructive and high-impact techniques need a separate yes
A general authorisation to test is not authorisation to do anything. Certain techniques get their own approval, named in advance.
- Named approval, per techniqueAnything that modifies or destroys data, interrupts a service, locks accounts, sends mail to real people, or persists on a system is agreed individually — not covered by the blanket authorisation.
- What we write, we recordWhere a test requires writing data, we write inert marker values, we record exactly what was written and where, and we itemise it for removal at handover. You should never be left discovering our test data months later.
- Credentials and accessWe do not change passwords, disable accounts or alter permissions on systems in use. Where demonstrating impact would require it, we describe the step and stop rather than take it.
- Social engineeringWhere people are in scope, the rules are agreed separately: who may be targeted, who may not, what pretexts are acceptable, and how anyone who reports it is treated afterwards. Nobody should be disciplined for failing a test they were never told about.
Stop conditions, and who can invoke them
Both sides can stop the engagement. The conditions are agreed before it starts, not negotiated during an incident.
- Your stopA named person on your side can halt testing at any time, for any reason, through a channel agreed at kickoff. We stop immediately and confirm that we have.
- Our stopWe stop on our own initiative if we find evidence of a prior compromise, if we believe testing is causing instability, or if we reach something the authorisation plainly did not contemplate.
- A live communication channelAn agreed channel — not a ticket queue — staffed on both sides for the duration, so a stop takes minutes rather than a working day.
- ResumingTesting resumes only when the reason for the stop has been addressed and both sides have said so.
Serious findings do not wait for the report
Two situations get handled immediately, and they are handled differently from each other.
- A critical finding in our testingIf we find something critical and actively exploitable, you hear about it the same day, by phone or the agreed channel — with enough detail to act, before the written finding is complete. Holding a critical back so it lands with impact in a final presentation is indefensible.
- Evidence of an existing compromiseIf we find indications that someone else has already been in the environment, that is not a finding to write up. We stop testing in that area, preserve what we have observed, notify you immediately, and hand over to your incident response. We are not your incident responders unless you separately engage us as such.
- Who we tellOnly the people you have named. We do not notify your customers, your regulator or anyone else — those are your obligations and your decisions.
Your data during and after the engagement
Testing produces evidence, and evidence contains your data. How it is handled is part of the rules, not an afterthought.
- Minimum necessaryWe take the evidence needed to prove a finding and no more. Where proving access to a record set is the point, we demonstrate it with a sample and a count rather than extracting the set.
- Personal dataWhere a finding exposes personal data, we evidence it in a way that proves the exposure without reproducing the data — redacted screenshots, record counts, field names rather than field contents.
- Where it livesEngagement data is held encrypted, access-restricted to the people on the engagement, and transferred over channels agreed with you.
- AfterwardsEngagement data is retained for an agreed period and then deleted. The period belongs in the contract, and we will confirm deletion in writing if you ask.
What you get, and what it will and will not say
The deliverable is the product. Its shape should be agreed before the testing starts, not discovered at handover.
- The reportEvery finding with its severity, the evidence, the steps to reproduce it, the business impact and a specific fix. Written so an engineer can act on it and a non-specialist can understand what is at risk.
- Severity, and how it was decidedOur severity model and the reasoning behind each rating are in the report. Where we disagree with a raw CVSS score because the context in your environment changes the risk, we say so and explain why.
- Findings we could not reproduceReported as such, honestly, rather than dropped or inflated. A finding we saw once and cannot reproduce is more useful to you as an open question than as silence.
- A clean resultIf we find little, the report says so and shows the coverage that supports the claim. We do not pad a report with informational noise to justify the invoice.
- RetestWe retest remediated findings and confirm in writing what is closed. A fix we cannot verify is reported as unverified, not quietly marked done.
- What a report is notA penetration test report is not a certificate and not an attestation. It describes what we found, in a defined scope, during a defined window. Anyone presenting one as a guarantee of security is misrepresenting it — including us.
Use this, including against us
This page is deliberately reusable. Take it into your next procurement, compare it against what another supplier will put in writing, and ask us the same questions you ask them. A rule that only applies when it is convenient is not a rule.
FAQ
Questions we get about this
Can we reuse this for a test by someone else?
Yes. That is why it is a page rather than a PDF behind a form. Lift what is useful into your own statement of work and hold whoever you hire to it. If a prospective supplier will not agree to something here, that is worth knowing before you sign rather than after.
What if our requirements are stricter than this?
Then yours apply. This is a floor, not a ceiling. We routinely work to a client's own rules of engagement, change-management process and testing windows.
Do you sign our rules of engagement instead?
Usually, yes. Most organisations with a mature security function have their own, and we would rather work to a document your team already understands than impose ours.
Is this legal advice?
No. It is how we run engagements. Your obligations under contract, regulation and local law are yours to take advice on.
Want to test these against your requirements?
Tell us what you want to protect. A senior tester will help you agree the scope and next steps. We usually reply within one business day.
Confidential from the first conversation
We can sign your NDA before you share sensitive details. Your enquiry is covered by our privacy policy.
How we protect your information · Privacy policy