Privacy Policy

1. Who is responsible for what #

Two different relationships run through this notice, and they carry different duties.

For the data inside a customer's account — their employees, cardholders, visitors, door events, timesheets, leave — the CUSTOMER is the controller. They decide what to record and why. We are the processor: we hold and process it on their instructions in order to run the service for them.

For the data we collect in our own right — a message sent through our contact form, an email to us, the accounts our own staff use to operate the platform — WE are the controller.

So if you work for one of our customers and you want to know what is held about you, your employer is the right place to ask. They can produce a complete file about one person from the console in seconds, and we will help them if they need it.

2. What this notice covers #

It covers the ALL access cloud console, the kiosk and check-in surfaces, the edge agent that runs on a customer's premises, and this website.

It does not cover what a customer does with an export once it has left the service, or the separate systems a customer may choose to connect.

3. What is held about a customer's people #

The categories below are the ones the software actually stores. It is worth saying what is NOT there: the product has no field anywhere for a date of birth, a personal identification number, a passport number, a home address, a photograph, a salary or a bank account.

• People on file — name, employee number, work email, work telephone, hire date and leaving date, department, team, job title, whether they are active, and free-text notes an administrator writes.
• Cardholders and credentials — the cardholder's name and contact details, and the card, fob, PIN, QR or plate number itself, with its status and its validity dates.
• Door events — which credential was presented at which door and reader, at what moment, by what method, whether it was granted or refused, and the message the controller sent verbatim.
• Attendance — punches derived from door events or recorded at a kiosk or on a phone, their direction and source, and, for a phone punch inside a geofence, the coordinates and accuracy the phone reported. Then any correction requested against them, its free-text reason, and who decided it.
• Leave — requests with their dates and a free-text reason, the leave type (which can reveal that an absence was medical), balances, and any document attached in support.
• Visitors — name, company, who they came to see, the purpose of the visit, when they were expected, and when they checked in and out.
• Console accounts — name, work email, chosen language, when the account last signed in, whether two-factor is enabled, and, as a security record, the network address and browser of a session.
• The audit log — for every change: who made it, when, from which address and browser, what changed, and which organisation it belonged to.

Two of these are treated as more sensitive than the rest, in code and not only in prose. A document attached to a leave request is encrypted before it is written to storage and can be downloaded only through a permission-checked, logged route rather than a link. A card number is stripped out of audit parameters, so a credential cannot come to rest inside a record that by design cannot be edited.

4. What we hold in our own right #

When you send us a message or ask us to call, we keep your name, the email address or telephone number you gave us, your company, your message, the language you were reading the site in, the page you came from, and any campaign parameters that were in the link. We keep it in order to answer you and to have a record of the conversation. It is not part of any customer's account.

We also hold accounts for our own staff who operate the platform, containing the same kind of data as any console account.

5. This website #

This website carries no analytics, no advertising pixel, no tag manager and no third-party tracking script of any kind. We do not know who you are while you read it.

It sets a session cookie, and it remembers the language you chose so that you do not have to choose it twice.

There is one exception, and we would rather state it than bury it. The office map on our contact and about pages is a Google Maps frame that loads as soon as the page does, which means Google sees your network address and your browser on those two pages without being asked. We give it as little as we can — no referring URL, a sandboxed frame, loaded late — but we are not going to pretend it is not happening.

6. Where the data comes from #

• From a customer's own administrators, who enter people, cards, groups and schedules.
• From a customer's own employees, who request leave, punch in and out, or ask for a timesheet correction.
• From the door controllers on a customer's premises, which report what happened at a reader.
• From you, when you write to us.

7. What it is used for #

Inside a customer's account: to decide and record who may open which door and when; to keep the record of what actually happened; to derive attendance and leave from it; to produce the reports and statutory forms the customer needs; and to let their administrators run the system.

The lawful basis for all of that belongs to the customer rather than to us, and it is theirs to document. Where a customer is in Georgia the usual grounds are the performance of the employment relationship, the discharge of a statutory duty such as the working-time record, or the employer's legitimate interest in securing the premises.

One transition deserves naming, because it is easy to miss. The moment a door event is used to assess an employee rather than to open a door, the purpose has changed from access control into monitoring, and the notice a customer gives their own staff has to say so. This product does exactly that when it derives attendance from swipes.

We use the data for nothing else. We do not sell it, we do not profile anyone for our own purposes, and we do not use it to train models.

8. Biometrics — what this product deliberately does not do #

There is no biometric template anywhere in this service. No fingerprint, no face, no iris, nothing. A reader may be a biometric reader and a credential may be labelled as a finger or a face, but what reaches us is the decision and the identifier of the credential, never the pattern itself.

Attendance in ALL access is recorded by card or PIN. That is a deliberate design decision, and there is a specific legal reason for it.

Under Georgian law biometric data may be processed only where the purpose cannot be achieved by other means, or could be achieved only with disproportionate effort. Consent does not open that door: it is not one of the gateways the biometrics article lists, so even a freely given, properly documented written consent cannot cure a failed necessity test. The supervisory authority has applied this to an employer directly and ordered it to STOP recording shift attendance by fingerprint — reasoning that the company's own willingness to let staff record attendance another way was itself proof that the biometrics were unnecessary.

So a fingerprint time clock in Georgia is not a risk to be managed with a consent form. It is unlawful, and the standard remedy is an order to stop processing, which in practice means decommissioning readers that have already been paid for. If a supplier offers you one, that is what they are selling you.

The written analysis behind this section, with the article numbers and the decision it rests on, is held internally, and we will share it with any customer who asks.

9. Who can see it inside your organisation #

Access is by role. Each organisation builds its own roles from a permission matrix and grants each role only the abilities it needs. Abilities that differ in kind are deliberately separate permissions, so that "may read a timesheet" does not imply "may open a door remotely", and "may view people" does not imply "may delete one".

Each organisation's data is separated from every other organisation's in the database itself. Every table carries the organisation identifier, and the database refuses a row that does not match the organisation the request is running as — the default answer being nothing rather than everything. The account the application connects with cannot override that rule.

Four high-volume time-series tables — door events, attendance punches, the audit log and usage metering — live in a storage engine that the database-level rule does not reach inside. For those the separation is enforced by the application, and it is covered by tests. We would rather write that sentence than imply a guarantee that stops at a boundary you cannot see.

10. Who can see it inside ours #

Support and provisioning give our operator accounts real reach into a customer's account. The console has a page that describes it in the customer's own language, and this notice says the same thing rather than a softer version of it.

An operator with the right permission can sign in to a customer's organisation as one of that customer's users, and then acts with exactly that user's permissions. An operator console can read the audit log of every organisation on the platform.

All of it is recorded in the customer's own audit log: the session starting and ending, every action taken during it marked with the operator account behind it, and an operator's reading of the log recorded in the log. A customer can verify every sentence of this paragraph against their own records, which is the entire point of writing it.

What is not true, and we will not let a nicer sentence stand in for it: an operator signing in as one of your users is not conditional on your consent, is not time-limited, and cannot be switched off by you. You see it afterwards, not as it happens.

The one thing that IS conditional on consent is whether an operator may see whose card was presented at a door. That is off until one of your administrators turns it on; it lasts only for the period they choose and then expires by itself; an operator cannot turn it on, including from inside a session where they are signed in as one of your users, where the attempt is refused and the refusal written to your log; and every name an operator reads is written there too.

11. How it is protected #

• Separation between organisations is enforced by the database, denying by default, using an application account that cannot override it.
• Passwords are hashed. Two-factor secrets are stored encrypted, and two-factor can be made mandatory for a role. Secrets and recovery codes are never returned by the API and never written to the audit log.
• Documents attached to a leave request — the most sensitive category the product holds — are encrypted with the application key before they are written to any disk, so the stored object is encrypted whatever the storage behind it does or does not do. They are served through a permission-checked route, never a public link.
• Secrets are stripped out of audit records before they are written: passwords, tokens, PINs, card numbers, bank details and anything named as biometric. A record that cannot be edited must not be where a secret comes to rest.
• Device and controller secrets are not stored in the cloud at all. The cloud keeps an identity for a controller, not a password for it.
• In production the edge agent reaches us on its own ingress using mutual TLS — a client certificate per agent, verified during the handshake, with revocation enforced at that point. A development stack uses a bearer token instead; the production service refuses to take an agent's identity from any header it has not verified: the only identity it accepts is the subject of a client certificate the ingress checked during that handshake.
• An account can be signed out of every device at once, and sessions can be revoked centrally.

Now the boundary, stated rather than implied: apart from leave documents, the data in the database is not encrypted field by field by the application. It relies on the encryption of the disks and of the managed database underneath it, which is a property of how a particular deployment is hosted rather than something this software does. Please do not read "encrypted at rest" as meaning more than that.

12. The audit log #

Every action that changes something is written to an append-only, hash-chained log. Each entry carries the hash of the entry before it, so removing or altering one breaks the chain and shows. The database account the application uses has been granted the right to insert and to read, and has had the right to update, delete or truncate taken away from it.

There is a command that re-hashes an entire chain and reports any break, and the per-person data file a customer can generate includes the chain hashes so that whoever receives it can check them independently.

The honest limits of that. The log is tamper-EVIDENT rather than tamper-proof: it makes an alteration detectable, not impossible, and a database superuser sits outside its threat model. The chain head is not yet anchored anywhere outside the same database. And it records actions that CHANGE data far more completely than actions that merely READ it — the named exceptions being the operator reads described in section 10. Georgian law expects reads of personal data to be logged as well, and that gap is known, recorded and open.

13. How long it is kept #

Two things have a real, enforced expiry today. A generated export — the file and its record together — is deleted 7 days after it is produced. A document attached to a leave request is deleted after 365 days by default, and an administrator can change that period for their own organisation.

Everything else is kept for as long as the account exists. Door events, attendance punches, visitor records, notifications and the audit log have no expiry in the software today. Part of that is a deliberate product position — a customer's history is frequently the only copy of it that exists, and we would rather be their archive than lose it on their behalf — but a position is not a retention policy, and it is not what the storage-limitation principle asks for.

So please do not read this section as a promise that data is erased. Read it as: exports and leave documents expire; everything else is retained and remains exportable; and a customer who needs a shorter period should ask us for one.

14. The rights of the people this data is about #

If you work for one of our customers, the rights below are exercised against your employer, who decides what is recorded about you. Ask them; if they need us, they will ask us.

• To be told what is held about you, and why.
• To receive a copy of it, free of charge, in a usable form. The console produces one file covering the person's record, their login, their cards and access, their leave, their punches and corrections, the door events matched to their cards, and the audit entries about them, with the chain hashes included. Passwords and two-factor secrets are excluded from it.
• To have inaccurate data corrected, or incomplete data completed.
• To ask for processing to stop, or for data to be erased or blocked, where the law allows it.
• To receive the data in a portable form, and to object to a decision taken automatically about you.
• To withdraw a consent that was the basis for something, at any time and without giving a reason.
• To complain to the supervisory authority, or to go to court.

One honest caveat about erasure. Suspending a person's access is immediate and reversible, and deleting their record is possible. But their door events and attendance punches are stored against a credential and a moment in time rather than against a link to the person, so deleting the person does not automatically remove them; and entries in the hash-chained audit log cannot be removed at all without breaking the chain that is the reason the log is worth anything. A request to erase therefore needs a conversation about what can be erased, what can be de-linked, and what has to be kept and why.

Georgian law generally gives a controller ten working days to answer a request, extendable once by a further ten with a stated reason. Our customers are the controllers; where they need something from us, we answer them fast enough for them to meet it.

15. Who else touches it, and where it is hosted #

The service uses a small number of outside services, and the list is deliberately short. Outbound email carries names, addresses and the content of notifications and invitations. Object storage holds generated exports and encrypted leave documents. An optional browser-push service delivers a notification, seeing the device endpoint but not the content, which is encrypted the whole way to the browser. An optional payment provider sees the amount and the order, not your people; if you pay by card, the card details are entered on the provider's own page and we store a masked number and an expiry date, never the full number and never a security code.

There is no analytics provider, no advertising network, no error-reporting service, no third-party script on the console and no artificial-intelligence or language-model service anywhere in this product. That is verified in the code rather than asserted in prose.

The one uninvited third party is the Google Maps frame on our public contact and about pages, described in section 5.

16. Sending data to another country #

Whether personal data in this service leaves Georgia depends on where a given deployment is hosted and which of the optional services in section 15 are switched on. We will state that plainly, per class of data, rather than in the abstract.

Why it matters, in one paragraph. Georgian law does not require data to stay in Georgia, but it does regulate leaving. A transfer to one of the countries the supervisory authority has listed as adequate — a list that includes every European Union member state individually, the United Kingdom, Switzerland, Norway, Iceland and Liechtenstein — needs nothing extra. A transfer anywhere else needs adequate safeguards in a contract AND the authority's prior permission, obtained before the data moves. That prior permission is not the same thing as the standard contractual clauses used under European law, and the authority does refuse it.

17. If something goes wrong #

If we discover a security incident affecting a customer's data, we tell the customer. They are the controller: the decision to notify the supervisory authority and the affected people is theirs, and Georgian law gives them 72 hours from the moment they discover it.

We keep a record of what happened, what it affected and what we did about it, and we give the customer what they need in order to make their own notification.

18. Children #

This is a workplace product and it is not intended for children. We do not knowingly hold data about anyone below the working age of the country a customer operates in. Where a customer's use of the service does involve a minor — an apprentice, for instance — the additional protections their law gives that person are the customer's responsibility as controller.

19. Changes to this notice #

The date at the top of this page is the date this notice last changed.

We will not quietly widen what we do with data. A change in what is collected, in why, or in who can reach it will appear here and be dated, and where a change matters we will tell our customers rather than waiting for them to re-read the page.

20. Contact and complaints #

Write to us first — our contact page reaches a person, and our about page carries the registered entity, its registration number, its address and its telephone number.

If you are not satisfied, the supervisory authority for personal data protection in Georgia can be complained to. Since December 2025 those functions have sat with the State Audit Office, exercised by the Auditor General; decisions published earlier by the Personal Data Protection Service remain good law on their substance. You can also go to court.