What exactly do you need to test? Black box tests external access, grey box tests logged-in features, and white box adds code review.
⬇ Download PDF No sign-up, no contact details required. Need a print version? ↓
PDF · 8 pagesRead the brief. Is it clear what needs testing: external access, other users' data, user permissions or code flaws?
→ Name the specific risk and use the decision guide to choose an approach.
This is a first step, not a replacement for all the checks.
Select a check to see the instructions: what good looks like, how to check, the red flag and what to do.
The owner identified the risk, and the technical lead included it in the test brief.
Read the brief. Is it clear what needs testing: external access, other users' data, user permissions or code flaws?
The brief only says 'check the website for vulnerabilities'.
Name the specific risk and use the decision guide to choose an approach.
The technical lead has listed the system addresses and features the pentester needs to test.
Compare the brief with the application. Does it cover the customer portal, payments, admin pages and data exchange between systems?
The brief only includes the homepage address.
Add the required addresses and features. Agree on the list with the provider.
The technical lead has prepared two independent customer accounts and accounts for other required roles.
Log in to each account. Check that the two customers have different test data and all required roles are available.
There is only one customer account. Access between customers cannot be compared.
Create the missing accounts. Check logins and test data.
The technical lead has documented which data each user role can view and change.
Read the permissions guide. Is it clear who can view invoices, change payments and manage other users?
Nobody knows who is allowed to see other customers' invoices.
List the permitted actions for each role. Share this with the provider.
The provider received required materials. Both sides agreed on boundaries, restrictions, contacts and secure access sharing.
Compare the materials with the brief. Are prohibited actions, the main contact and a secure way to share access defined?
The provider does not know the restrictions or has no contact person.
Agree on restrictions and a contact person. Share access securely.
Use the document as the basis for your rules. Tick the checks for 30 working days until they become a habit.
The owner or manager decides which checks are mandatory and who owns them.
Who performs a check and who confirms it. Where possible, two different people.
Print the A4 sheet and keep it where the process happens.
Tick the checks daily, record exceptions and refine the rules when needed.
After 30 days you have an agreed rule, owners and a record of checks. Not a guarantee of security, a working practice.
We can independently test whether these controls work in practice, not only on paper.
Penetration testing specialist. Helps companies find vulnerabilities in web applications, APIs and infrastructure and decide which risks to fix first.
About Veiltrack → Questions about the security of your processes? Discuss your situation →
This guide contains general recommendations. The controls available to you depend on your company and the services you use.
