Secure by Design: Why UK Data Sovereignty Is More Than Where Your Data Is Hosted
For sensitive UK projects, secure software is only one part of the security boundary. True assurance also depends on hosting, privileged access, development, support, incident response and the operational supply chain.
What does Secure by Design mean for sensitive UK projects?
Secure by Design means considering security across the complete service from the outset: the application, hosting environment, identity and access controls, deployment architecture, development practices, support model, privileged access, monitoring, backup, recovery and third party services. For sensitive projects, the security boundary is therefore wider than the software itself.
That distinction matters because a system can be securely coded and hosted in the UK while still depending on people, processes or third parties outside the expected assurance boundary. Data residency tells you where information is stored. A fuller data sovereignty discussion also asks who can access it, from where, under what circumstances and with what controls.
Sterling Secure by Design
Sterling's Secure by Design approach brings together UK based development and support, UK data residency, strong access controls, tenant isolation, encryption, monitoring, resilient hosting, backups and recovery as part of a wider operational security model.
Sterling Secure by Design infographic: security across the platform, hosting, development, support and operational model.
Is UK data residency the same as data sovereignty?
No. UK data residency describes where data is stored. Data sovereignty is a broader assurance question that also considers the legal, organisational and operational controls surrounding that data, including who may obtain access to production systems and information.
A platform may legitimately be hosted in a UK data centre, but organisations should still understand where Level 2 and Level 3 support teams are located, who can obtain privileged access, whether support personnel can view live project information, and whether production data can be copied or extracted during an investigation.
Why does privileged access matter?
Privileged access can allow administrators, database specialists, support engineers or developers to perform actions that ordinary users cannot. For sensitive programmes, the principle of least privilege should therefore apply to the software supplier's own operational teams as well as to customer users.
MFA, SSO and role based access controls are important for project teams, but assurance should also cover how supplier access is requested, approved, time limited, monitored and audited.
The 2am test: what happens during a real incident?
One of the simplest ways to assess an operational security model is to ask what happens when a production problem occurs outside normal working hours.
Who receives the initial escalation?
Where are the Level 2 and Level 3 support teams located?
Can an engineer, developer or database administrator obtain access to the live environment?
Can they view production databases, documents, attachments, logs or backups?
Who approves elevated access and how long does it remain active?
Is every privileged action recorded and available for audit?
Does live project information ever need to be copied into another environment to investigate the issue?
A strong security model needs to remain strong during an incident, when speed of resolution can otherwise become the overriding priority. Incident response should not create an uncontrolled exception to the normal security model.
Why the operational supply chain is part of the security perimeter
Modern cloud services are delivered through an ecosystem. The effective security perimeter can include the hosting provider, software supplier, development organisation, DevOps function, support operation, subcontractors, integration partners and third party technology services.
Each organisation or service that can influence the production environment should be considered as part of the overall assurance picture. Secure by Design should therefore extend beyond application security into the way the service is built, deployed, operated and supported.
What should organisations ask software suppliers?
When evaluating software for defence, nuclear, energy, transport, critical infrastructure or other commercially sensitive projects, the following questions help create a more complete view of security:
Where is our production data stored and backed up?
Who can access the production environment?
Where are the development, DevOps and support teams located?
What happens when an issue reaches Level 2 or Level 3 support?
Can supplier personnel access live databases, documents, logs, attachments or backups?
How is privileged access requested, approved, restricted, monitored and audited?
Can production data be extracted or copied for support or troubleshooting purposes?
Which subcontractors and third party services form part of the operational service?
How are customers separated from one another at the tenant and data level?
What happens to access rights when support activity is complete?
How does Sterling approach Secure by Design?
At Sterling, security is treated as part of the complete service rather than as an add on around the application. The Secure by Design model described in Sterling's security material includes UK based development and support teams, UK data residency and UK data centres, strong authentication and access controls, separate client databases, tenant level isolation, encryption in transit and at rest, continuous vulnerability management, regular penetration testing and monitoring, encrypted backups and tested recovery.
The same material identifies Cyber Essentials certification, ISO 27001 aligned policies and controls, UK GDPR compliance, Two Factor Authentication, Multi Factor Authentication, Single Sign On through Azure AD (Entra ID), role based access and least privilege.
For secure project teams, Sterling also describes separate portfolios, granular permissions at portfolio, project and module level, invite only access and a full audit trail.
Why this matters for complex project delivery
Security on complex programmes is not only about protecting information from external threats. It can also require carefully controlled information sharing between authorities, prime contractors, delivery partners and sub tier suppliers that may collaborate in one context while remaining commercially separated in another.
Sterling's submarine delivery material specifically considers scenarios where different parties need different levels of visibility into shared cost information, including protecting commercially sensitive underlying rates while still enabling appropriate information to flow through the programme.
Frequently asked questions
What is Secure by Design?
Secure by Design is an approach where security is considered from the beginning across the software, architecture, hosting, access controls, deployment, support and operational processes rather than being added later as a separate control layer.
Why is UK hosting not enough on its own?
UK hosting confirms where the infrastructure or data is located, but it does not by itself explain who can access the environment. Buyers should also understand the location and privileges of support, engineering, database and operational teams.
What is the difference between data residency and data sovereignty?
Data residency is primarily about where data is stored. Data sovereignty is broader and considers the legal and operational controls governing the data, including access, jurisdiction, support and the organisations involved in delivering the service.
What is privileged access?
Privileged access is elevated system access that allows administrators or technical personnel to perform actions unavailable to normal users. It should be restricted, approved, monitored and auditable.
Should software support teams be included in a security assessment?
Yes. If support personnel can access production systems, logs, databases, documents or backups, the support model forms part of the effective security boundary and should be considered during assurance.
What should happen when Level 2 or Level 3 support needs production access?
The organisation should understand who is granted access, why it is required, who approves it, what information can be viewed, how long the access lasts and how the activity is recorded and audited.
Does least privilege apply to software suppliers?
It should. Least privilege is not only an end user control. The same principle should apply to administrators, developers, DevOps personnel, database specialists and support engineers operating the service.
What sectors benefit from this approach?
The principles are particularly relevant to defence, nuclear, energy, transport, critical infrastructure and other projects where project, commercial or operational information requires a high degree of assurance.
Secure software is only part of a secure service
For sensitive programmes, assurance should cover the complete service that surrounds the application. That means understanding not only where data is hosted, but also who can access it, how the platform is developed and supported, how incidents are handled and which organisations form part of the operational supply chain.
Secure by Design should therefore apply to the whole service: software, hosting, people, processes and operations.
Secure by Design from day one. Trusted where security matters most.
Secure by Design has been part of Sterling’s backbone from day one. It is not a feature we have added later, nor a layer applied around the platform. It has shaped how Sterling is developed, hosted, deployed, supported and operated from the outset. That foundation is why organisations can trust Sterling on secure, sensitive and nationally important projects, where protecting data, controlling access and reducing operational risk are fundamental requirements, not optional extras.
