Summary

Understand what data and information your service will be collecting from users, and how this will be stored and used. Identify and address security threats, legal responsibilities, confidentiality, privacy issues and risks associated with the service. Consult experts where you need to.

A secure service also includes, but is not limited to, consideration of how to handle policy, money, safeguarding and future DfE strategy information.

Why it's important

DfE handles personal and sensitive information (opens in new tab) 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.

How to meet this standard in every phase

You'll be assessed on what you've done to meet this standard at service assessments. However, even if the service you're working on is not being assessed, it's good practice to consider how you'll meet this standard point.

In discovery

Things to consider:

In alpha

Things to consider:

  • continue to work on the DPIA, where relevant
  • demonstrable evidence that the 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 requirement
  • explore security anti-personas or bad actors for the 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 the service from fraud (opens in new tab)
  • the use of cookies (opens in new tab) in the service
  • how you will manage and own risks through risk registers and applying information assurance best practice

In 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 the 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 security have been raised and assigned
  • demonstrable evidence of how services and data storage will be secured (opens in new tab) to prevent data loss, corruption and availability concerns, among others
  • how you've tested your service to ensure it doesn't expose security risk, for example, testing against OWASP Top 10 (opens in new tab)
  • use of common components, such as DfE Sign-in if authentification is required, to secure your service
  • creating an asset register for the 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 the service. Consider if the 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

Profession specific guidance

Each DDaT profession in DfE has their own community and guidance.

Architecture

Technical Guidance