Security and Data Protection
Verification processes information about people, some of it sensitive. The design keeps your exposure small, but there are decisions only you can make.
Where to find it
Architect Panel → Security:
- User Verification — the console — providers, types, checks and their history
Architect Panel → Security:
- Permissions — who may see verification records
Architect Panel → Data:
- Retention & Disposal — how long check records are kept
Architect Panel → Activity:
- Record Read Log — who has looked at verification data
What you hold
- The outcome and a short evidence summary.
- The provider's reference.
- The e-mail address used.
- Any failure reason.
- Timestamps, the IP address and the browser.
What you do not hold
The passport, the driving licence, the photograph. Those stay with the provider.
This is the single most important thing to understand about your exposure here, and it is worth stating plainly to anybody assessing the system: a breach of your database does not disclose anybody's identity documents, because they were never in it.
What you hold is still personal data
An evidence summary saying somebody is a verified healthcare worker is information about them. A record that an age check failed is information about them. The IP address and browser are personal data.
Treat verification records with the same care as any other personal data: restrict access, set retention, and include them in your record of processing.
Settle the lawful basis first
Before enabling a type, be able to say why you are asking. "It seemed useful" is not a basis, and verification is exactly the kind of processing that attracts scrutiny — you are asking people to prove things about themselves as a condition of using a service.
Ask for the least that answers your actual question: age rather than identity, affiliation rather than identity, a domain check rather than a document.
Set retention deliberately
Check records accumulate, including failures. Decide how long you need them — long enough to evidence that you verified somebody, not indefinitely — and apply it.
Failed checks deserve particular thought. A record that somebody repeatedly failed an age check is sensitive, and there is rarely a reason to keep it for years.
Restrict who can see them
Verification records reveal affiliations and outcomes. Access should be limited to the people who administer verification, not available to anybody who can see a user record.
Where the records are sensitive, consider enabling read auditing so you can answer who has looked.
Tell people what happens
Explain, before they start, what will be checked, by whom, what you will keep and for how long. Sending somebody to an unfamiliar third party to photograph their passport with no explanation is both poor practice and a good way to lose them at the redirect.
Do not repurpose the data
An affiliation established for access control should not quietly become a marketing segment. That is a different purpose, and it needs its own basis.
Worked example
Before enabling verification, an organisation documents why each type is needed, sets retention at two years for successes and six months for failures, restricts the records to three named administrators, and adds a short explanation to the point of redirect. When asked later what identity data it holds, the answer is that it holds none — only outcomes.
Recommendations
- Ask the least intrusive question that answers your need.
- Set retention, with a shorter period for failures.
- Restrict access to verification administrators.
- Explain the process before the redirect.