Privacy by Design standardisation raises the bar for identity architecture

At a glance

What this is: ISO 31700 turns Privacy by Design into an operational standard, with the article arguing that architecture is the deciding factor in making its 30 requirements real.

Why it matters: It matters because IAM, IGA, and customer identity teams now have to treat privacy enforcement, authentication, and data minimisation as architectural controls, not downstream compliance tasks.

By the numbers:

• The network of 167 national standards bodies sets nearly 25,000 different standards covering almost all aspects of technology.
• 44%.

👉 Read 1Kosmos's analysis of Privacy by Design and ISO 31700

Context

Privacy by Design is a governance model that requires privacy protections to be built into products and services from the start, rather than added after deployment. In identity terms, that shifts the control problem from policy statements to how authentication, consent, data retention, and user control are implemented across the lifecycle.

ISO 31700 matters because it turns those principles into a larger operational requirement set. For IAM teams, the hard part is not understanding the standard, but translating it into architecture that avoids unnecessary PII collection, limits exposure, and supports authenticated access without creating new privacy debt.

The article’s core claim is that compliance will fail if the underlying identity architecture still depends on storing more personal data than is necessary. That is typical of many consumer-facing environments, which often optimise for convenience first and privacy second.

Key questions

Q: How should teams implement Privacy by Design in identity architecture?

A: They should embed privacy controls into onboarding, authentication, consent, retention, and deletion workflows rather than treat privacy as a policy wrapper. The goal is to minimise data collection, limit purpose, and ensure the identity platform enforces those decisions consistently across applications and channels.

Q: When does a privacy standard become an identity governance issue?

A: It becomes an identity governance issue when the organisation must prove what personal data it holds, why it holds it, who can use it, and when it is removed. At that point, privacy depends on lifecycle control, access governance, and auditability, not just legal language.

Q: What do security teams get wrong about biometrics and privacy?

A: They often focus on authentication strength and ignore the data handling model around enrolment, storage, and recovery. Biometrics can reduce password dependency, but they do not automatically reduce privacy risk unless the architecture also limits retention and replay of personal data.

Q: Who should own Privacy by Design enforcement across the enterprise?

A: Ownership should sit with identity, privacy, security architecture, and application teams together because the control points span data collection, access, and retention. If any one team owns only a fragment of the workflow, the standard will be difficult to operationalise consistently.

Technical breakdown

Privacy by Design as an identity architecture problem

Privacy by Design is not a product feature list. It is an architecture principle that requires systems to minimise data collection, constrain purpose, and preserve user control throughout the identity lifecycle. In customer identity environments, that means authentication, recovery, consent capture, and retention logic must be designed together. If those functions are separated, privacy controls become inconsistent and difficult to audit. ISO 31700 makes that architectural dependency more explicit by expanding the principles into a broader requirement set that touches governance, lifecycle data management, and breach mitigation.

Practical implication: Design identity flows so privacy decisions are enforced in the platform layer, not left to application teams.

Why passwordless and biometrics change the privacy equation

The article argues for architecture that can authenticate users without relying on stored passwords or unnecessary personal data. That matters because stored secrets and duplicated identity attributes create both security risk and privacy risk. Biometrics and liveness testing can reduce spoofing, but they also require strong assurance around enrolment, binding, and data handling. The privacy gain comes from reducing the amount of personal data that must be retained and replayed across systems, not from biometrics alone.

Practical implication: Treat passwordless and biometric design as both identity assurance controls and data minimisation controls.

Consumer control, retention, and breach prevention under ISO 31700

ISO 31700’s requirements extend beyond access to include how long data is kept, who can enforce rights, and how systems prevent or mitigate breach impact. That pushes IAM and privacy teams toward lifecycle governance, not just authentication hardening. If retention, deletion, and purpose limitation are not built into identity data paths, the organisation ends up with more data than it can justify or defend. The standard therefore links privacy compliance to architecture discipline and operational governance.

Practical implication: Map identity data flows to retention and deletion controls before expanding consumer onboarding or recovery features.

NHI Mgmt Group analysis

Privacy by Design becomes real only when identity architecture is built to enforce it. The article is right to frame ISO 31700 as a design problem, not a documentation problem. Privacy controls fail when consent, retention, verification, and user control sit in separate systems that were never intended to work together. Practitioners should treat privacy enforcement as an architectural property of identity platforms, not a compliance overlay.

Minimum data collection is the most important control here because excess identity data creates both breach exposure and trust debt. If a consumer identity flow asks for more PII than the transaction requires, the organisation is already accumulating avoidable risk. That aligns with NHI governance thinking as well, because the same principle applies to non-human identities, tokens, and secrets. Practitioners should reduce identity data scope before they try to secure it.

Privacy by Design and zero trust intersect at the point of verification, but they do not solve the same problem. Zero trust asks whether access should be granted continuously and conditionally, while Privacy by Design asks whether the system should have collected or retained the data at all. That distinction matters for IAM architects building customer journeys, because a stronger access model still leaves a privacy failure if the wrong data is stored upstream. Practitioners should evaluate both controls together.

ISO 31700 will expose weak lifecycle governance in consumer identity programmes. The standard’s emphasis on control, retention, and breach mitigation means organisations must be able to prove what data exists, why it exists, and when it is removed. That is a lifecycle question as much as a security question. Practitioners should expect governance gaps to surface in onboarding, account recovery, and deletion workflows first.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• For teams building privacy-aware identity architecture: Start by mapping where privileged identities and sensitive data intersect, then use Ultimate Guide to NHIs , Standards to align controls with zero trust and lifecycle governance.

What this signals

Identity teams should expect privacy standards to surface the same governance weaknesses that already show up in machine identity programmes. If organisations cannot control what data is collected, retained, and re-used, they will struggle to prove compliance no matter how strong the authentication layer looks.

Data minimisation is the quiet control that changes the risk curve. With 91.6% of secrets still valid five days after notification, according to our Ultimate Guide to NHIs, identity programmes should assume that over-retained data and over-retained credentials fail in the same operational window.

Privacy by Design will increasingly force convergence between customer identity, IAM, and lifecycle governance. Teams that separate these functions will keep discovering the same gap in different places: the system collected more identity data than the business could secure, explain, or delete.

For practitioners

• Minimise identity data at collection time Review onboarding, recovery, and verification flows to remove any PII that is not strictly needed for the transaction. The best privacy control is not storing data that downstream teams later have to protect or justify.
• Align consent with actual processing paths Document where user approval is captured, where it is enforced, and which systems inherit the decision. If consent is recorded in one application but ignored in another, the privacy model is not operational.
• Rework authentication to reduce stored secrets Use passwordless and stronger verification patterns where appropriate so identity assurance does not depend on repeated storage of credentials or overexposed account data.
• Build retention and deletion into identity workflows Tie data retention rules to account lifecycle events so deletion, revocation, and suppression happen as part of the process rather than as an afterthought.

Key takeaways

• ISO 31700 turns Privacy by Design into an architecture test, not a policy statement.
• Identity programmes that collect excess data will struggle to satisfy both privacy and security expectations.
• Practitioners should align authentication, retention, and deletion controls before expanding consumer identity workflows.

Key terms

• Privacy by Design: A design approach that builds privacy protections into systems from the start instead of adding them after deployment. In identity programmes, it means collection, authentication, consent, retention, and deletion are engineered together so the platform enforces privacy decisions consistently.
• Identity Data Minimisation: The practice of collecting and retaining only the identity data needed for a specific business purpose. It reduces breach exposure, limits unnecessary correlation, and makes compliance more realistic because the organisation has less sensitive data to protect, explain, and remove.
• Consumer Identity Lifecycle: The end-to-end management of a person’s identity record from registration through verification, recovery, use, and deletion. Privacy-aware lifecycle design ensures that each stage has clear rules for what data is stored, how long it remains, and when it is revoked or removed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: Privacy by Design standardisation and ISO 31700 implications. Read the original.