The only thing that separates them

Testing a system and attacking one look identical from the wire. Authorisation is the difference, and it is a criminal boundary.

A typical week Mon Enquiry Tue Scope Wed Authorise Thu Work Fri Report
How we work

Why nothing starts before a signature

There is no technical property that distinguishes a security assessment from an attack. The same tools, the same commands, the same traffic, often the same person capable of either. The distinction is legal rather than technical, and under the Computer Misuse Act it rests on authorisation. Causing a computer to perform a function with intent to secure access to a program or data is an offence where the access is unauthorised and the person knows it to be unauthorised. An aggravated offence applies where such access is obtained with intent to commit a further offence, and unauthorised acts intended to impair a system's operation, or committed recklessly as to that, are offences in their own right. None of this turns on how constructive the motive was.

That produces two disciplines which a careful practice treats as absolute. The first concerns who may authorise. Authorisation must come from a person with authority to give it in respect of the system concerned, and a request from somebody inside an organisation does not by itself establish that they can permit testing of that organisation's infrastructure. Checking is the provider's responsibility rather than the requester's, and occasionally costs a day at the start of an engagement. The second concerns scope. The agreed scope is the limit of the authorisation, which means activity beyond it is unauthorised even inside an engagement that is otherwise entirely proper. Scope creep is therefore not the contractual nuisance it is in other fields; it is a step outside the thing that makes the work lawful. Assets discovered during an engagement get reported, not explored.

A third situation catches people acting in complete good faith. Where a client's systems are hosted or operated by a third party, the client often cannot validly authorise testing of that infrastructure, because it is not theirs to authorise. The consent of the party entitled to give it is required, along with compliance with whatever testing policy that party imposes. Beyond authorisation, the same instinct governs what happens to the output: findings go to the client and are not published or passed on, credentials and data encountered are handled only as far as the work requires, and access is closed at the end rather than left in place for convenience. And no assessment concludes that a system is secure. It describes what was found, within a stated scope, by stated methods, during a stated period. The absence of a finding is not evidence of the absence of a vulnerability.

Our principles

Three beliefs behind the method

Written, then access

Never the other way round.

Scope is the boundary

Outside it is unauthorised.

Never call it secure

Only what was found, and when.

Want something assessed properly?

A free first conversation, with no obligation.