Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

  1. Service manual
  2. Technology
  3. Vulnerability and penetration testing

You must use penetration tests and vulnerability assessments on your service to make sure it’s secure.

Vulnerability assessments help you find potential weaknesses in your service. Penetration tests proactively attack your systems to find weaknesses and help you understand how easy they are to exploit.

You should carry out both frequently as you build, not as a one-off check. You should begin testing before you enter public beta.

Government continually reviews its security policies. Check this guide regularly or subscribe to email notifications to hear about changes to technology content in the Service Manual.

Meeting the Digital Service Standard

To pass point 7 (understand security and privacy issues) in your service assessments, you must explain how you test the security of your service.

What to test

When you’re testing for vulnerabilities, your testing scope should be wide enough to include the whole system and not just the software involved.

For example, a wide testing scope could include:

  • the security of the place where you keep equipment
  • the interaction between an online system and a contact centre

It’s important for the service to make sure that people can’t use offline information to exploit an online system. An example of this might involve getting a contact centre team to change a user’s email address, then using a forgotten password function to access that person’s account.

You must get explicit consent from any third-party supplier if you use their software and want to review it as part of your test. Check your legal contract to confirm you have consent.

When to test your service

Your team should regularly assess your service’s security, especially during major changes to your codebase (for example, when introducing a new dependency or integration).

Working with third parties

You should use a third party to test your service before it moves into public beta or uses real user data. They can help you make sure that your internal testing is good enough, but you shouldn’t rely solely on third-party testing.

How to find a third party

If you choose to use a third party, you should use a CHECK certified team or staff accredited to equivalent CHECK levels to carry out penetration testing.

You can also find certified companies through the Digital Marketplace or through the National Cyber Security Centre’s (NCSC’s) list of CHECK companies

If your service handles data classified as SECRET or TOP SECRET, contact the NCSC to find out if any special testing requirements are needed.

Testing third party systems or software

You must agree the details of any third-party penetration tests with your security and legal team, for example:

  • when the tests will happen
  • whether they should focus on staff-related vulnerability, as well as system vulnerabilities
  • whether you have permission from your third-party supplier to look at their systems or services

You might also choose to whitelist a group of the third party’s IP addresses. Marking them as trustworthy means you won’t mistake their work for a genuine malicious attack (unless the test is designed to test your reactive capabilities).

Your agreement with the third party should include confirmation that they’re not liable for any disruption to your service and will stop their work immediately if it does disrupt your service.

After the test, the third party should produce a report that explains how severe the weaknesses are and how easily they can be exploited. They might also provide recommendations on how to protect your service from malicious users.

Handling security reports

Whoever did the vulnerability assessment and penetration tests should produce a report after every round of tests to explain what they did and what they found. This should be shared with the technical team, service manager and any senior managers that need to understand risks to your service.

The report summary should explain the risks in language that a non-technical audience can understand. The rest of the report should contain enough detail that your technical team can review and prioritise actions to fix any issues that have been found.

Building security capability in your team

You should aim to increase security understanding and capability within your team. Running vulnerability assessments and penetration tests yourself is cheaper and can be done more regularly than relying on a third party.

Your team could include experts such as ethical hackers, security engineers or penetration testers to help keep the service secure.

Increasing automated testing

You should try to automate as much of your testing as possible to find basic vulnerabilities, such as features exposed to SQL injection.

There are several open source or commercials tools you can use to test the security of features, for example you can use:

You should also aim to use exploratory testing to find vulnerabilities in your service that could be exploited by more advanced attackers.

If you aren’t sure which tools to use or what to test, speak to a security expert in your organisation or a qualified third party.

Get testing advice

You can contact the National Cyber Security Centre (NCSC) to get standards and advice on information security.

If your tests find vulnerabilities that affect other services or organisations, contact their security lead or pass the information to the NCSC.

You may also find these guides useful:

Published by:
Technology community (technical architecture)
Last update:

Added guidance on when to carry out penetration tests and how to work with third parties.

  1. Updated the list of CREST-certified companies you can hire to test your service.

  2. Guidance first published