Security, Privacy and Compliance by Design

Welcome to Chapter 8, Security, Privacy and Compliance by Design. Most serious breaches are not caused by an exotic attack on cryptography. They come from structural decisions. An internal service that trusted every caller on the network. An administrator API that skipped an authorisation check. An access key committed to a repository. Each was an architectural choice about where trust lies, which component may do what, and where data travels.

This chapter is for developers and architects who know the distributed and data architectures of Chapters 6 and 7, and who must now make them safe. Every service boundary, queue, cache, replica and analytics copy adds to the attack surface. Distribution multiplies the trust boundaries, and data architecture decides how many copies of personal data exist and how long they live. The chapter treats security as a quality attribute designed into the structure, in the sense of Chapter 2's security scenarios, rather than a list of products bought at the end. It also assumes Chapter 0's section on networks, HTTPS and TLS. And it leads to Chapter 9, which keeps the secured system fast and running under stress.

The running example is the food delivery platform used throughout the course: customers, restaurants and couriers, an API gateway, ordering, payments, dispatch and notification services, an event stream and a data warehouse. Section eight point one sets out the vocabulary: confidentiality, integrity and availability, Saltzer and Schroeder's design principles from 1975, such as least privilege, then defence in depth, secure defaults and the OWASP Top 10. Section eight point two turns those principles into a repeatable design activity. You draw a data flow diagram with its trust boundaries, ask what can go wrong using STRIDE and attack trees, rate the risks, and decide on mitigations. Section eight point three covers who is calling: passwords, passkeys, sessions and tokens, OAuth with PKCE, OpenID Connect, and the main models for deciding what each caller may do. Section eight point four covers encryption in transit and at rest, password hashing, key management with envelope encryption, secrets, tokenisation, and the decision about what to encrypt where.

Here is one of the central ideas of Section eight point one, defence in depth, drawn along the path an order takes through the platform. At the top is the customer app, outside the trust boundary. It talks to the platform only over HTTPS, and nothing on the device is trusted by the platform. Inside the boundary, each layer adds its own controls. The edge absorbs floods of traffic, applies rate limits and blocks known attack patterns. The API gateway checks every token and rejects requests that do not match the API schema. The orders service checks that this customer may see this particular order. The database uses an account with least privilege, and it is encrypted at rest, with backups encrypted under separate keys. Security logging, detection and alerting run across every layer. Because each layer has its own controls, a single bypassed control does not expose the data.

The second four sections widen the view. Section eight point five replaces the idea of a trusted internal network with authentication and authorisation on every request between services, using mutual TLS, certificates, and separate points where policy is decided and enforced. Section eight point six treats dependencies, build systems and container images as part of the attack surface, with software bills of materials, signing, and the EU Cyber Resilience Act. Section eight point seven explains how the GDPR and the UK GDPR shape architecture: data minimisation, pseudonymisation, the rights of the people the data is about, retention, and erasure across backups and event logs. And Section eight point eight closes the loop with security logging, detection, vulnerability management, incident response and breach notification.

This diagram from Section eight point five shows what zero trust changes. Before, on a flat internal network, any host can reach any port, and every service shares one database. When the menu service is compromised, the attacker can go straight to payments. After, each service has its own database, and only named identities may make allowed calls. Orders calls payments over mutual TLS, with a policy. When the compromised menu service tries to call payments, it is denied. Notice what zero trust does not do. It does not stop a service being compromised. It limits what the compromised service can reach.

An architect does not need to be a penetration tester or a cryptographer, and should not invent cryptography. The architect makes the decisions that are expensive to change: where the trust boundaries lie, and which identity provider and token model the whole platform uses. Also which data is classified as restricted, and encrypted with which keys, and how services prove their identity to one another. These decisions belong in architecture decision records, like any other significant decision. Developers own an equally important set: validating input, encoding output, using the platform's security libraries correctly, handling errors without failing open, and keeping dependencies up to date. The two meet in threat modelling, in secure design reviews, and in automated checks in the delivery pipeline.

Security and privacy are full of numbered standards and legal provisions. The chapter names them precisely, gives the edition current at the time of writing, October 2026, and points to the authoritative source. The material on regulation explains how the law affects architecture. It is information, not legal advice. For a specific situation, an organisation's own lawyers and data protection officer remain the people to ask.

If you remember one thing from this chapter, make it this. Decide who and what your system trusts, for what, and why. Decide it deliberately, early and in writing, rather than leaving it implicit. And make every one of those trust decisions verifiable. Threat models, least privilege, OAuth scopes, envelope encryption, mutual TLS, signed builds and audit logs are all ways of replacing implicit trust with explicit, checkable trust. A system designed that way limits the damage of the breach that will eventually come, and can show its customers, auditors and regulators how it protects them.

Reading the sections in order works best. But each one also stands on its own, so you can go straight to the section you need. Allow about three and a half hours to read the whole chapter. At the end of each section there are self-check questions. Answer them in your head before you look at the answers. When you are ready, there is an optional chapter test, which takes about forty five minutes. It has twenty multiple choice questions and two written answers. The pass mark is eighty per cent.

That is the shape of the chapter. Start with Section eight point one, security principles for architects, where the vocabulary for everything that follows is set out. See you there.