What does privacy by design mean concretely at the point of designing a system, rather than as a principle?

The decisions that actually implement it

• Collect less. Every field collected is a field to secure, retain, disclose, delete and justify. The cheapest privacy control is not having the data — and the question "what decision does this field inform" is the one that removes most of it.
• Derive rather than store. Storing a date of birth to check age is worse than storing a boolean; storing precise location to determine a region is worse than storing the region.
• Separate identity from behaviour. Behavioural data keyed by a pseudonym, with the mapping held separately under tighter control, means a breach of the analytics store is not a breach of identities.
• Default to the private setting. Defaults determine outcomes for the large majority who never change them, which makes the default the actual policy rather than the stated one.
• Bound retention at design time, since retention is easy to extend and impossible to reverse.
• Design for deletion before there is data to delete. Retrofitting deletion across an estate where copies have proliferated is a multi-year programme.

The architectural properties this implies

Purpose recorded with the data, so a later use can be checked against what was collected for. Access boundaries aligned to purpose rather than to department. Sensitive fields tokenised or encrypted at ingestion, so most of the estate never holds the real value.

The framing that makes it happen

Privacy questions asked at design review, not at legal review. A design review is where the collection decision is made and where changing it is free; legal review happens after the design exists, when the same question costs a redesign.

And the honest test: could this system function with less data? If nobody has asked, the answer is almost always yes.