9. Create a secure service which protects users' privacy

This guidance will help you apply standard point 9.

Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:

Data architectsDelivery managersProduct managersFrontend developersSoftware developers

Why it's important

DfE handles personal and sensitive information (opens in new tab, DfE SharePoint users only) about users, children's services, and education.

We have a legal duty to protect personal and sensitive information. Failing to do so would undermine public trust in DfE services.

DfE service and project teams must understand the importance of protecting the confidentiality, integrity, and availability of sensitive information. This includes being aware of risks that reduce the security of the information, and taking action to mitigate.

Discovery

Things to consider:

Things to avoid in discovery

Alpha

Things to consider:

  • continue to work on the DPIA, where relevant
  • demonstrable evidence that your service you want to build is technically feasible and meets required security standards
  • if delivery and security are two competing risks, speak to your Senior Responsible Officer (SRO) to discuss impact and requirements
  • explore security anti-personas or bad actors for your service, if relevant
  • tech choices and common components you might use when you build your service
  • a plan for how the findings from checking technical feasibility and security compliance will be addressed in beta
  • how to protect users and your service from fraud
  • the use of cookies in your service
  • how you will manage and own risks through risk registers and applying information assurance best practices

Things to avoid in alpha

  • ignoring the importance of balancing delivery speed with security

  • overlooking the technical feasibility of security requirements

Beta and live

Things to consider:

  • evidence of addressing findings from alpha
  • findings of DPIA are being addressed
  • before going into private beta, do a penetration test if your service is a new service or a significant change is made to a new service. A significant change could be a change in scope, storing more data, or opening up to customers
  • residual security risks and mitigations have been raised and assigned
  • demonstrable evidence of how services and data storage will be secured to prevent data loss, corruption, and availability concerns, among others
  • how you've tested your service to ensure it doesn't expose security risks, for example, testing against OWASP Top 10
  • use of common components, such as DfE Sign-in if authentication is required, to secure your service
  • creating an asset register for your service
  • evidence that all risks to security have been addressed when moving from beta to live
  • evidence that the security controls implemented are compliant with department standards
  • how you will eventually decommission your service. Consider if your service is needed for a specific time, or whether it's needed for longer
  • consider archive or retention policies and access requirements
  • how to support Freedom of Information (FOI) requests or Subject Access Requests (SARs)
  • security and vulnerability issues with any systems that aren't being actively monitored or maintained

Things to avoid in beta and live

  • not addressing all security findings before moving to the next phase

  • failing to plan for the decommissioning and long-term management of your service