When making security decisions for a digital service, the goals of the organisation and the needs of users should be considered so a service can be delivered that’s both secure and fit for purpose.
By understanding the security requirements of your organisation and your users, you will be able to:
A summary of security issues related to business and user needs should have been included within your project’s business case. This activity is designed to expand on that information as part of the discovery or requirement gathering phase.
It’s important to understand the user behaviour and why they do things they do, working backwards to design security that is suitable for them. You should continually review the needs of your users against the security decisions you make.
Completing this activity will help you to achieve the outcomes included in the Secure by Design principle to design usable security controls.
Business and user needs provide context that your Senior Responsible Owner (SRO), service owner, delivery manager and product manager will need to consider when making security design decisions.
Business analysts working on your project should collaborate with security professionals to understand and translate the business goals of the project into high level security requirements. They should also seek the support of user researchers, technical architects and development teams to ensure security controls and the processes for implementing them are fully understood across all aspects of delivery.
The following steps explain how to find the right balance between usability and security, and how you can create appropriate security controls that are seen as an enabler rather than an obstacle.
There is no single output or artefact that will be produced from completing this activity. Successful adoption of the approach will be user research and service delivery teams consulting with security professionals and including security needs throughout the design and build phases.
Review the project business case for all the objectives that need to be considered from a security perspective. This includes why the service is required, what the service is being designed to achieve, who is involved in the delivery, and when it needs to be delivered.
Work with security professionals and business analysts to assess the business goals and create a list of security requirements that will need to be considered throughout the delivery lifecycle.
Part of this list will include elements included within your security risk appetite statement. For example, if your service requires users to submit personal information, a business objective will be not allowing unauthorised access to that data.
Service owners and product managers will have listed user needs as part of the business planning process, describing how the service will be designed to meet them.
Using this as a guide, make a list of points within the service map where security considerations need to be made. If the service has not yet been designed and there is no visual representation of how it works, consult with business analysts, product managers and user researchers to make assumptions based on anticipated user behaviour.
For each point where security is relevant, outline the motivations and barriers involved, as well as the potential threats that need to be considered.
For example, if a service needs to send email reminders to a user's inbox, considerations need to be made regarding whether details are included directly in the email, or whether they need to log in to view the information. The motivation for the user is to get the reminder as easily as possible, while the threat is that sensitive information may be delivered to an insecure inbox.
As part of the service development process your user research team will be conducting interviews, surveys, tests and other studies designed to identify typical user habits. Work with them to incorporate activities and questions that will assess security attitudes and behaviours related to the business goals and user needs you have identified.
Particular attention should be on understanding areas of friction or resistance that could undermine the effectiveness of security, as well as identifying where users may require further guidance or explanation on necessary security controls.
In a live service, analytics teams should assess user data related to security controls to understand common behaviour. For example, reporting on the levels of traffic drop-off where greater security is required.
These processes should happen continually throughout the lifecycle of a service, not just during the initial design and build phase.
The following questions will help you to confirm that those involved in conducting user research understand security considerations and can effectively include them within their work:
What accessibility needs do users have that may prevent them from being able to pass service security? What are the alternative routes available to them?
Security insights related to user needs should be made available to the delivery team responsible for designing the service.
Decisions about security should be closely aligned with the findings of user research so controls and processes can achieve the right outcome for the people who will be using them. This may include educating users to help them understand non-negotiable security protections such as secure authentication.
These considerations should be interdependent. Security controls that have an impact on the user experience should not be implemented without first conducting user research, and changes that improve the user experience should not be made without first assessing the security implications.
For example, implementing improved security controls could be found to have a detrimental impact on users with accessibility needs. Colleagues need to work together to find a mutually acceptable solution, whether that’s keeping the existing controls, or implementing the improvements with accessible alternatives.
The responsibility for these decisions ultimately lies with the SRO who will be able to make an assessment based on the project’s security risk appetite.
This activity is part of the ‘Understand the security landscape’ stage of Secure by Design, which also includes:
Read the Secure by Design activities
The Secure by Design approach will evolve to reflect the needs of government digital services. Your feedback will help us to improve it.
Last update: 31 January 2024
OFFICIAL