Security & privacy

What we do with the data.

We publish employee information on pages anyone can open. That deserves a plain explanation rather than a wall of clauses — so here is exactly how the system is built, and what it refuses to do.

Last updated 16 July 2026

Who is responsible for what

Under the Nigeria Data Protection Act 2023, your organization is the data controller — it decides what to publish about its own people. We are the data processor: we host the service and act on your instructions. If one of your staff wants their information corrected or removed, that request is exercised against your organization, and we carry out what you instruct.

This split is why the console gives you the switches rather than us: which fields go public, what the wording says, who has an admin seat, and when a record is revoked or erased are your decisions to make and ours to execute.

The database is not publicly readable

There is exactly one public surface: the verification endpoint. It takes a single token, returns a projection of one record, and nothing else. There is no public API over the tables, and anonymous access to the database has no privileges at all — not "restricted" access, none.

The projection is built from a per-organization whitelist. Fields you keep internal are never included in the response — they are not hidden with styling or collapsed behind a toggle, they are simply absent from the data that leaves the server. Payroll identifiers, dates of birth, home addresses and phone numbers stay internal by default, and we advise against publishing them.

Addresses can't be guessed

Each credential's URL ends in a 128-bit random token. It is not the staff number, not sequential, and not derived from anything about the person — so the pages cannot be enumerated, and holding one card tells you nothing about anyone else's. Reissuing a card rotates the token, and the retired page reports only that the card was replaced.

Photographs

Photos are processed in your browser before upload: cropped, re-encoded, and stripped of EXIF metadata — which removes the GPS coordinates phone cameras embed by default. The original file is never stored.

On the verification page, photos are served through links that are signed at the moment of the scan and expire five minutes later. Headshots never sit at permanent public URLs, so an image address cannot be scraped and reused.

What a scan records

Every verification writes an audit entry — this is a feature of the product, and also a privacy question, so here is the whole of it:

  • the time of the scan, and the credential's status at that moment;
  • a hashed IP address — salted with a secret and truncated, so it can group repeat activity and stop abuse, but cannot be reversed into an address;
  • the browser's user-agent string, used to tell phones from terminals.

We do not record who scanned, or where they were. We do not derive location from IP addresses. The scanning member of the public is not identified, tracked, or profiled — they point a camera at a card and read a page.

No trackers on the verification page

The public verification page loads no analytics, no advertising pixels, no third-party fonts, and no JavaScript at all. It is self-contained HTML from our server and nothing else. That started as a performance decision — it has to be instant on 3G — and it happens to be the strongest privacy position available: there is no third party to share anything with.

This marketing site does load fonts from Google Fonts. The console, which only your admins use, is a signed-in application.

Reporting a card

Verification pages carry a link for reporting a problem — a mismatched photo, a tampered card, or a card found and needing return. Reports need no account: holding the card is what proves the reporter was there. If someone reports a found card they may leave a phone number so it can be returned; that number is optional, visible only to the issuing organization, and used only to arrange collection.

Administrator actions are logged and cannot be erased

Changes to records — created, revoked, reissued, deleted, seats added or removed — are written to an audit trail by the database itself, not by the application. Nobody can perform an administrative action that skips the log, and the log cannot be edited or deleted from the console by any user, including us. For an organization publishing claims about its own staff, being able to show who changed what and when is part of the point.

Your data stays yours

You can export your records, scan logs, reports and audit trail as CSV at any time, without asking us. If you leave, you take your data with you.

When an organization closes its account there is a grace period before anything is destroyed, because deletion here has physical consequences: the QR codes are already printed on cards in the real world, and erasing the records stops those cards verifying. After the grace period the data is permanently purged. A minimal record that the deletion happened is retained at platform level — this is the accountability trail, and it deliberately survives the deletion it describes.

What we do with what you send us

If you submit the demo form we receive your name, organization, email, an optional phone number and your message, plus a hashed IP for spam protection. We use it to reply to you. We do not sell it, share it, or add you to a mailing list.

Questions, and the formal paperwork

This page describes how the system actually behaves. For contracted engagements the binding terms and a data-processing agreement are issued with the subscription — ask and we'll send them, including for procurement review.

Anything unclear, or a data-protection question specific to your organization: hello@aidaqr.com.