Most questions about identity verification are really questions about storage. Not whether the check works, but where the passport photograph ends up and who can still reach it next year.
Data minimisation, applied to a passport
The GDPR asks for two things that sound abstract until you apply them to an identity document: collect only what the purpose needs, and keep it no longer than the purpose needs. Checking a passport needs the image for a few seconds. Proving later that the check happened needs a record of the result, not the image. The design below follows that line literally.
A single verification passes through three places. Each one has a different job, and each one gives the document back.
The device
Capture happens where the person is: a phone, a kiosk, a thin client at a counter. The device reads the document, checks the security features it can check on its own, and holds the image only while the check is running.
Nothing is written to the device's storage. When the session closes, the frame is gone with it.
The cloud
What the device cannot decide alone travels encrypted to the processing layer, which compares the document against the reference for its type and country, and the face against the document.
The processing layer is transit, not a filing cabinet. It holds the payload for the duration of the request and releases it when the answer is produced.
The image is evidence during the check and a liability afterwards. Only the outcome is worth keeping.
The audit record
What survives is the record: which checks ran, what each one returned, when, and against which reference. It is what your compliance team reads and what a regulator asks for.
It contains no document image. A record that had to carry the passport photograph to be useful would put the risk back exactly where the rest of this design took it out.
Why it is split this way
Because the three places fail differently. A lost device, a breached server and a leaked archive are three separate incidents, and a design that keeps the document in all three turns any one of them into the same headline.
Keeping the document in none of them means each incident stays what it is. A lost device is a hardware problem. A breached server holds requests in flight, encrypted, and nothing from last year. An archive that leaks contains outcomes and timestamps, not passports.
How it travels between them
All personal and biometric data is encrypted at rest and in transit. The capture leaves the device already encrypted, reaches the processing layer in a hardened AWS environment, and the answer comes back the same way. At no point does the image cross a network in the clear.
The questions your team can now answer
- Where is the customer's passport image? Nowhere, once the check has returned.
- What did we check, and when? The audit record, with the reference each check used.
- What happens if a counter device is stolen? It holds nothing to lose.
- Who can reach last year's verifications? Only the records, never the documents.
Questions about where the data goes
Does 247IQ keep a copy of the passport image?
No. The image exists on the device while it is captured and in the processing layer while the request runs. Once the verdict is returned, only the audit record remains, and it contains no document image.
Is the data encrypted?
All personal and biometric data is encrypted at rest and in transit, from the moment of capture to the moment the answer comes back.
Where does the processing happen?
Server-side, in a hardened AWS environment. The devices at the counter, at the kiosk and in the customer's hand only capture and encrypt.
What can an auditor see afterwards?
Which checks ran, what each returned, when, and against which reference. That is the evidence a compliance review asks for, without the personal data a leak would expose.