The value of per-person access is that every open has a name on it. The cost is that you are now processing personal data: who was where, and when. This article explains how EMMTRY handles that data, so that you can answer a tenant or an auditor without guessing.
Where it is stored
All EMMTRY data is stored and processed in Frankfurt, Germany, on EU-based infrastructure. That includes accounts, entrances, schedules, the activity log and device state. Backups stay in the EU as well. Every connection between devices, apps and the platform is encrypted with TLS, and passwords, where used at all, are hashed with bcrypt. Most people never set a password: members sign in with a one-time code sent to their email.
Who can see what
Visibility follows the same roles that decide who can open a door:
- Owners and admins of an account see the activity for the entrances and people they manage.
- Members see their own activity.
- Guests see nothing beyond the page their link opens.
The platform's real-time notifications follow the same rule: a push about an entrance is only delivered to people who are allowed to see that entrance. This is enforced on the server, not in the app, so a modified client cannot widen it.
Consent, export and deletion
Three things the platform does on the person's side:
Consent. On first sign-in, each user accepts the terms and the privacy policy for the version in force, and the acceptance is recorded with its version and date. When a policy changes materially, users are asked again.
Export. A user can request a copy of their data from their profile. It is delivered as a machine-readable file and includes their account details and their own activity.
Deletion. A user can request deletion of their account. After a grace period, during which the request can be cancelled, the account is anonymised: identifying fields are removed, credentials and device registrations are dropped, and memberships are ended. Activity rows that other people have a legitimate interest in (the building's own log of who opened its gate) keep a pseudonymous reference rather than the person's details.
What removing someone does
Revoking a person's access is immediate: their key stops working at the next request, on every entrance. It does not delete history. The building's log still shows what that person did while they had access, because that is the log's purpose, and because deleting it on removal would let anyone erase their own trail by leaving.
If a person then asks for their data to be deleted, the process above applies, and the log entries are anonymised rather than removed.
Your responsibilities as the controller
Under GDPR the building owner or property manager who runs an EMMTRY account is the data controller for their tenants' and guests' data, and EMMTRY (Cigno Systems AB) is the processor acting on their instructions. In practice that means:
- Tell people. Your tenants and regular guests should know that entries are logged and why. A line in the tenancy agreement or house rules is usually enough.
- Grant the minimum. Give people the entrances they need, not everything, and use guest links with schedules for anyone temporary. Roles and groups exist so that the minimum is easy.
- Do not keep former residents. Remove people when they leave. The activity log preserves what you need; their live access does not.
- Answer requests. If a tenant asks what you hold about them, the export gives you the answer; if they ask for deletion after moving out, remove them and let the platform's deletion flow run.
The privacy policy is the binding description of all of this; this article is the plain-language version. If your organisation needs a data-processing agreement or has questions a policy page cannot answer, contact us.