Security of processing
Measures appropriate to the risk — which in practice means who can reach personal data, with what assurance, and for how long a session remains valid after the conditions that justified it have changed.
GDPR
Prove it is them without learning more about them
At the identity layer, most privacy findings are not about weak protection. They are about data that was collected because it was easy to ask for, kept because nobody set an expiry, and copied into systems nobody can now enumerate.
Where identity meets the regulation
Three obligations that land on the access layer
The regulation is much broader than identity. But three of its principles are decided almost entirely by how identity and access are designed.
Data minimisation
Adequate, relevant and limited to what is necessary. An identity system is where over-collection becomes structural: an attribute added to a registration form is an attribute held about everyone, for years, in every system provisioned from it.
Accountability
Being compliant is not enough; it has to be demonstrable. Access decisions, approvals, grants and revocations are among the few records that can show a control was in force on a given day rather than described in a policy.
Data minimisation
The question, what gets asked, and what would be enough
Four checks that almost every organisation performs. The middle column is what usually happens; the right-hand column is what the same decision needs. The gap between them is personal data that has to be protected, retained, and eventually explained.
The decision
Is this person old enough?
What gets collected
A scan of an identity document, stored indefinitely in a support system
What is enough
A signed attribute stating that an age threshold is met, presented and then discarded
The decision
Does this person work for that company?
What gets collected
A copy of a contract, an email exchange, and a manual check repeated at every renewal
What is enough
A credential issued by the employer, verified against the issuer's key at the moment of access
The decision
Is this the same person who registered?
What gets collected
Date of birth, address and mother's maiden name, collected as a knowledge check
What is enough
A phishing-resistant factor bound to the account, which proves possession without adding data
The decision
Does this person hold a professional qualification?
What gets collected
A PDF certificate uploaded to a portal, verified by whoever happens to open the ticket
What is enough
An attestation from the awarding body, checked by signature rather than by eye
None of the right-hand answers is hypothetical: they are credential presentations and phishing-resistant factors, both of which Monokee performs today as steps inside a journey.
Data subject rights
Every right arrives as an identity problem first
Before any right can be honoured, two questions have to be answered: is this the person they claim to be, and where did their data go. Both are answered by the identity layer or not at all.
Access
“Everything you hold about me”Identity data is rarely in one place. It sits in the directory, in the accounts provisioned from it, and in the access history. Answering completely means knowing which systems received the identity and what they were given.
Rectification
“This attribute is wrong”A correction that lands only in the source of truth is not a correction. It has to propagate to the systems already provisioned from it, and the propagation has to be verifiable.
Erasure
“Delete me”Two hard parts. Reaching every account created downstream, including the ones created outside the process — and identifying the requester well enough to act, without collecting new personal data in order to do it.
Portability
“Give it to me in a usable form”Attributes an organisation holds about a person can be handed back as a signed credential rather than a CSV, which makes them reusable elsewhere instead of merely exported.
Objection and restriction
“Stop using it for that”A preference recorded in a consent screen changes nothing unless the systems reading the profile respect it. Consent has to be a state the access layer can see, not a checkbox in a form.
The paradox sits in the third card. A request for erasure has to be authenticated, and the temptation is to ask for an identity document — creating a new copy of personal data in order to honour a request to delete personal data.
How Monokee approaches it
Fewer attributes, and an inventory of where they went
Consent and notice as steps in a journey
A consent screen, a re-consent after a change of terms, a preference recorded before an attribute is shared: all of them are blocks placed on the canvas, with explicit branches. The people who own the wording — legal, privacy, product — can see the flow they are responsible for instead of reading it back from code.
Verification without accumulation
Monokee acts as a verifier of credentials on open standards, so a request can ask for the two attributes a decision needs rather than the whole document. What is presented is checked against the issuer's signature and does not have to be retained to have been useful.
Deletion that reaches the accounts
Provisioning and reconciliation work in both directions: accounts are created in target systems from an authoritative source, and read back to detect what exists outside the process. That inventory is what makes an erasure request answerable rather than optimistic.
Where the boundary is
Monokee processes identity data on behalf of the organisation that runs it — the controller remains the customer, and lawful basis, retention periods, records of processing and privacy notices remain theirs to define. The platform can be deployed in Monokee Cloud or on the customer's own infrastructure, which is usually the first question a data protection officer asks.
Where it usually goes wrong
Four findings you can predict without an audit
- Attributes collected because they might be useful later, held in the directory long after the reason expired — the most common finding, and the cheapest to avoid.
- Accounts that outlive the relationship: a contractor gone eighteen months ago whose personal data is still in four systems because deprovisioning was manual.
- Access history kept forever because nobody set a retention period on it, in a system whose whole purpose is proving that retention periods are enforced.
- Copies of identity documents stored as evidence of a check that a signed attribute would have proven, and that now have to be protected for years.
This page describes how an identity layer supports obligations under the General Data Protection Regulation. It is not legal advice and not a statement of compliance: lawful basis, retention, records of processing and the response to data subject requests remain the responsibility of the controller.
Bring us the attribute you collect and never use
Every registration form has one. Removing it, or replacing it with a proof that is checked and discarded, is a shorter project than it sounds.
Talk to an expert