What should you decide before the test starts?
Four things, written down and agreed with your provider.
- The scope. The systems to test, and anything to leave alone.
- Test accounts. One for each role the tester should use.
- Testing windows. When testing may run on your live systems.
- Sign-off and a contact. Written approval from someone entitled to give it, and one named person on your side.
Together they become the written scope that testing starts from. Testing should not begin until that scope is agreed and signed off.
How do you describe the scope?
In the words your team already uses. The scoping conversation turns it into a test. Useful detail to bring:
- the addresses of the applications, APIs or hosts in scope
- the user roles that exist, from an ordinary customer to an administrator
- the parts that matter most: payments, exports, admin tools, anything that holds customer data
- anything that must stay out of scope, such as a third-party service or a fragile older system
- API specifications, architecture diagrams or an earlier report, if you have them
You do not need a finished scope to start. A rough description of what you run, and what worries you, is enough for a first conversation.
Leave passwords, keys and customer data out of that first message. If testing needs access details later, agree a secure way to share them.
Which accounts and roles does the tester need?
One working account for each role you want tested. Many serious findings sit between roles: a customer reaching another customer's data, or an ordinary user reaching an admin action. A tester can only find them by signing in as each side.
If your product has tenants, provide accounts in at least two of them, so the boundary between tenants can be tested.
Before testing starts, sign in with each account yourself and check that it sees what that role should. A locked or misconfigured test account spends testing time that should go on your systems.
How does testing run on live systems?
Carefully, and inside rules you set. GreySurface tests live systems by default, inside windows agreed with you, with a named contact on your side and no destructive actions. Whoever runs your test, agree these points in writing:
- when testing may run, and any times it must pause, such as a release or a busy trading day
- who the named contact is, and how to reach them during the windows
- what counts as destructive and stays off limits
- whether a web application firewall or other filtering should let test traffic through, or whether you want to see what it stops
If you have a reason to prefer another environment, such as staging, raise it during scoping and say how closely it matches production.
What decides how long a test takes?
The scope does. A single web application takes less time than a cloud account with many services, so the timeline is agreed with the scope rather than fixed in advance. The factors that move it:
- the number of roles and tenants to test
- the number of routes, endpoints or hosts in scope
- how many applications or environments are included
- how much of the product sits behind sign-in
- how settled the scope is when testing starts
The same factors set the price. See how we price a penetration test.
What should your team do during testing?
Very little, if the preparation is done. A short list helps:
- Tell your on-call and security teams the windows, so alerts are expected.
- Keep the named contact reachable during the windows.
- Tell the tester about any release planned during the windows.
- Decide who on your side reads the report and the briefing.
- Set engineering time aside for fixes, so they can be checked in good time.
What happens after the report?
Your engineers fix from the proof in the report, the most serious findings first. Each finding carries a fix written for the engineer who makes the change, and leadership gets an executive briefing on what to fix first.
Then comes the retest. With GreySurface, a one-off test includes one retest within 30 days of the report: once your fixes are live, a tester reruns the exploit behind each reported finding and records whether the fix holds. In continuous penetration testing, each quarterly round retests the findings from earlier rounds.
Every step of a test, from scope to retest, is on how a GreySurface test runs. New to testing? Start with what a penetration test is.