How do we authorise testing properly?

In writing, from somebody entitled to grant access to the systems involved. The scope and rules of engagement do that job, and we ask for them to be signed before anything else happens. If your site or system sits on somebody else's infrastructure, their own rules may require notice before testing: we ask for that notice to be given, and confirmed, rather than assuming it.

Could testing take the site offline?

It can, which is why the window, the exclusions and the stop condition exist before testing starts. Techniques that risk availability are listed separately and only used if you authorise them specifically. Where a finding can be demonstrated without that risk, we demonstrate it that way and say so in the report.

Can you provide a report for our auditor or our client?

The report is written to be read by your auditor as well as by the people doing the fixing: it states the scope, the dates, the techniques, the findings and the limits of what was tested. What it is not is a certification. Frameworks such as ISO 27001 or PCI DSS are certified by accredited bodies, not by a testing supplier, and we will say so rather than let a report be mistaken for one.

Cyber security

Penetration testing

A penetration test is an authorised attempt to do what an attacker would do, against one stated goal, inside rules that were agreed in advance. It is carried out by the team that will still be here afterwards to explain what it found, in your terms rather than in jargon.

Businesses holding customer data or taking payments, organisations asked for assurance by a client or a partner, and teams about to put a new system in front of the public.

How we work through penetration testing

One goal, written down, with permission to pursue it

A test that is not aimed at a question produces a long report and no decision. So the goal is agreed in one sentence first — whether somebody outside could reach customer records, whether a former employee's account still works, whether a payment flow can be manipulated — and the scope, the window and the permitted techniques are built around that sentence.

The goal stated in a single sentence you have approved
Systems in scope, and the ones explicitly excluded
The test window, and who may be contacted during it
Techniques that are permitted, and the ones that are not
The condition that stops the test immediately, and who is called

What testing under those rules looks like

Testing works along the paths a real attacker would take: accounts and sessions, the input a system accepts, the boundary between one user's data and another's, the logic of the workflow itself, and the infrastructure underneath it. Anything that could damage data or take a system down is listed separately for explicit authorisation rather than attempted because it looked interesting.

Authentication and sessions, including what still works after signing out
What one customer can reach that belongs to another
Where the application trusts input it should not
Business logic used in ways the designer never intended

If something goes wrong while we are testing

Testing carries risk, and pretending otherwise is how a test becomes an incident. A stop condition is agreed before the first packet, the person who can stop it is named, and anything that looks like real damage is reported immediately. A finding severe enough to matter is told to you during the test, not saved for the report.

Critical findings reported while the test is still running
A named contact who can halt testing at any time
Evidence stored under the agreed rules, and destroyed after handover
A written note of anything that behaved unexpectedly, whether or not it was a finding

The report, and the honesty about its limits

The report states the scope, the dates, the techniques and what could not be tested, so nobody mistakes it for a guarantee. A test shows what was reachable on those days, on those systems, using those methods. Systems change, and a clean report on a system that has since been rebuilt means very little.

Scope, dates, techniques and limits on the first page
Findings reproducible by your own developer
A retest of the agreed fixes, saying what is closed and what is not

What you receive

A written scope, goal and set of rules of engagement, signed before testing
Authorised testing inside the agreed window
Immediate notice of anything critical, in plain language
A report written for developers and for whoever needs assurance
Evidence handled to the agreed storage and deletion rules
A retest of the agreed fixes, with a written result

Questions we are often asked

How do we authorise testing properly?
In writing, from somebody entitled to grant access to the systems involved. The scope and rules of engagement do that job, and we ask for them to be signed before anything else happens. If your site or system sits on somebody else's infrastructure, their own rules may require notice before testing: we ask for that notice to be given, and confirmed, rather than assuming it.
Could testing take the site offline?
It can, which is why the window, the exclusions and the stop condition exist before testing starts. Techniques that risk availability are listed separately and only used if you authorise them specifically. Where a finding can be demonstrated without that risk, we demonstrate it that way and say so in the report.
Can you provide a report for our auditor or our client?
The report is written to be read by your auditor as well as by the people doing the fixing: it states the scope, the dates, the techniques, the findings and the limits of what was tested. What it is not is a certification. Frameworks such as ISO 27001 or PCI DSS are certified by accredited bodies, not by a testing supplier, and we will say so rather than let a report be mistaken for one.

One studio

What this connects to.

The other service lines this one meets on a real project, and what the two of them share.

Vulnerability assessment
The assessment finds the candidate weaknesses; this is where the serious ones are proved rather than assumed.
Security hardening
A finding is only closed when the configuration behind it has changed, which is the work this page leads into.
Software development
Fixes in the product itself belong with whoever builds it, so testing and development are on the same side of the wall.

Next step

Talk to us about penetration testing.

A short description of the project is enough to start. We will reply with how we would approach it, what it needs and what it would take.

Start a project shasaistudio@pm.me 0799 003 003