Most attendance RFPs are written by copying a feature list from a vendor website, which guarantees that the vendor who wrote it scores highest. A better RFP asks about behaviour under stress: what happens when the network drops, when someone leaves, when a regulator asks where the data is. These are the questions that separate products once they are in production. Use them as a scoring sheet, or paste them straight into your tender document.

Section 1 — Deployment and data residency

  1. Can the system run entirely on infrastructure we control, with no outbound internet connection?
  2. Is the on-premise product the same software as the cloud product, or a separate build?
  3. If we start in the cloud and move on-premises later, do employees need to re-enrol?
  4. In which countries are your cloud data centres located, and can we pin data to one region?
  5. What are the minimum server specifications, and which databases are supported?
  6. What is your documented backup and disaster-recovery procedure for biometric data?

Question 2 is the one that matters most and is most often dodged. Separate codebases mean a migration is a re-implementation. Our on-premise attendance software page explains why.

Section 2 — Biometric accuracy and security

  1. Who developed the recognition algorithms — you, or a licensed third party?
  2. Have those algorithms been evaluated independently, and can you share the results?
  3. What anti-spoofing is implemented, and does it run on the device or the server?
  4. Which presentation attacks has it been tested against: printed photo, phone screen, video replay, mask?
  5. What is stored at enrolment — an image, a template, or both?
  6. Are templates reversible, and how are they encrypted at rest and in transit?
  7. How does accuracy change with masks, safety glasses, hard hats, gloves or dirty hands?
  8. What happens when recognition fails — what is the documented fallback?

Question 11 deserves a precise answer. “We store a template, not an image” is the answer you want, and it should be verifiable in the product, not just in the sales deck.

Section 3 — Devices and check-in points

  1. Which devices can act as a check-in point without purchasing hardware from you?
  2. Is there any per-device fee, now or on renewal?
  3. Can IP cameras already installed on site be used?
  4. Can one device serve multiple employees in sequence at shift change, and how fast?
  5. Is group or crew check-in supported by a supervisor on one device?
  6. What is the offline behaviour — how long can a device operate disconnected, and how does it reconcile?

Section 4 — Compliance and data subject rights

  1. How is employee consent captured and recorded at enrolment?
  2. Can retention periods be configured, and does deletion happen automatically when they expire?
  3. If an employee requests erasure, what exactly is deleted, and is it deleted from backups?
  4. Can you produce an audit log showing who accessed biometric records and when?
  5. What documentation do you provide to support a data protection impact assessment?
  6. Which regulations have you deployed under — GDPR, BIPA and other US state laws, India’s DPDP, KVKK, the Gulf’s PDPL?

Cross-check the answers against our compliance hub, which covers each of these regimes for attendance specifically.

Section 5 — Integration and operations

  1. What payroll exports are standard, and which systems are supported natively?
  2. Is there a documented REST API, and is it included or licensed separately?
  3. Can the same enrolment drive door access and visitor management?
  4. How are shifts, breaks, overtime rules and public holidays configured?
  5. What reporting is standard, and can reports be customised without professional services?
  6. What are your support hours, response targets, and escalation path — and what does support cost after year one?

How to score the answers

Weight three areas double: deployment model, anti-spoofing, and device freedom. These are structural — you can add a report or an export later, but you cannot retrofit a self-hosted architecture or undo hardware lock-in without starting again.

Treat vague answers as failures rather than neutral. “Enterprise-grade security” in response to question 12 is a non-answer; “AES-256 at rest, TLS in transit, templates are one-way” is an answer. Vendors who cannot be specific about storage and deletion will not become specific after you sign.

Three things to require as evidence, not assertions

  • A live deletion demonstration. Ask them to enrol a test user during the demo and delete them while you watch, then show the record is gone.
  • A spoof attempt. Hold up a phone showing a photograph of an enrolled face. This takes ten seconds and is remarkably revealing.
  • An offline test. Turn off the network mid-demo and clock someone in.

Any vendor confident in their product will welcome all three. See how it works for the architecture these questions are probing.

Frequently asked questions

How long should an attendance RFP be?

Shorter than most. Thirty well-chosen questions produce more differentiation than two hundred feature checkboxes, because checkboxes are all answered “yes”.

Should we require an on-premise option even if we plan to use cloud?

It is worth asking, because the answer reveals architecture. A vendor who can self-host has usually built for data isolation throughout.

What is the single most predictive question?

“Show me deletion working.” It tests the data model, the compliance posture and the honesty of the sales process in one request.

Structuring the evaluation itself

The questions are only half the exercise; how you run the process determines whether the answers are comparable.

Send the same document to everyone, and require written answers. Verbal answers in a demo cannot be compared afterwards and cannot be attached to a contract. Written responses can be, and vendors are noticeably more precise in writing.

Score before you meet. Read and score the written responses before any demo. Demos are persuasion exercises; scoring afterwards means scoring the presenter.

Give the technical sections real weight. A common failure is letting the person who will use the reports outvote the person who will secure the data. Deployment model, storage and deletion belong to IT and legal, and should carry at least as much weight as reporting features.

Reference calls with a similar profile. Ask for a customer of comparable size, in a comparable environment — not the vendor’s favourite reference. Ask that customer two questions: what surprised you after go-live, and what would you do differently? Both answers are consistently more informative than anything in the RFP response.

The shortlist trap

Organisations frequently shortlist on features and then discover in month two that the architectural answer was wrong — data must stay in country, or every door needs a purchased terminal. Features can be added by a vendor in a release; architecture cannot be changed at all without a migration and a re-enrolment.

So if a product fails questions 1, 2, 9 or 15 — self-hosting, shared codebase, on-device anti-spoofing, device freedom — treat it as disqualified rather than as scoring poorly on four lines. Structural answers are pass or fail. Everything else is a score.

After the decision: what to put in the contract

Answers given during an RFP are only binding if they reach the agreement. Three of them should: the deployment commitment (that the product will run self-hosted, if that is what you were promised), the device policy (that units not billable today cannot become billable mid-term), and the deletion commitment (that individual records can be deleted on request, including confirmation that templates are destroyed on termination).

Add a data export right in a documented, non-proprietary format, available at any time rather than only at exit. Attendance history is often required for years after a system is retired, and negotiating access to your own records after a relationship has ended is a poor position to be in.

NCheck is a biometric attendance system by Neurotechnology that runs on-premises or in the cloud, supports face, fingerprint and iris recognition, and works on phones, tablets, IP cameras and biometric terminals. Free forever for up to 5 employees.