Data Retention Policy
Versie 2026.10.20-1 — van kracht sinds 20 oktober 2026
Dit document is niet in het Nederlands vertaald: hieronder staat de Engelse vertaling. De Italiaanse versie is juridisch bindend. Lees het Italiaanse origineel
How long we keep each category of data, why exactly that long, what happens when the period expires and where the technical rule that carries it out is located.
Courtesy translation. In case of discrepancy, the Italian text prevails.
This is the document in which all the retention periods of the BGates Service live. The other documents — the Privacy Notice, the Notice for people authorised to open an entrance, the Data Processing Agreement, the Terms — refer to them and reproduce some of them for ease of reading. If another document should state a figure different from the one written here, the one written here prevails.
We do not use, anywhere, the formula ‘for as long as necessary’. Where there is a period there is a figure, and next to the figure there is the reason.
Controller: Business Gates S.r.l., Via Ripamonti 44, 20141 Milano, P.IVA 05759280968. For any request about this document: info@bgates.it.
1. How to read this document
The tables always have the same six columns.
- Category — which data we are talking about, with the name we use in all documents.
- Why we keep it — the purpose. It is not a list of good intentions: it is what authorises the period in the next column.
- For how long — the figure.
- Why exactly that long — the justification for the figure. A period without a reason is a period that cannot be defended.
- What happens afterwards — the method: erasure, anonymisation or masking. These are three different things and in this document they are never confused (section 2).
- Where the technical rule is — the point in the Service that actually carries out the rule. Almost all the rules are carried out by a nightly job (section 8); some are carried out by the rotation of the system logs; one is carried out by the factory reset of the Device.
The tables are divided in two, because not all the data are ours: section 4 contains the Entrance data, for which the Customer is the controller and we are the processor on its behalf; section 5 contains those for which we are the controller. The distinction is not a formality: it changes who can decide a shorter period and to whom requests should be addressed.
2. The three words we use, and never confuse
Erasure. The entry or field disappears from the live systems. It remains in the backup copies for the rotation period (section 7), and then disappears from there too.
Anonymisation. The entry remains, but loses the data that make it possible to trace it back to a person: the name is removed, and only the last three digits of the telephone number remain. What remains is an event — ‘at 18:42 on 3 March someone opened’ — which is no longer personal data and cannot be reversed.
Masking. The data is still in our records, but on screen only the last three digits can be seen. It is a measure that protects against whoever is looking, not against whoever has access to the database: that is why, wherever there is masking, there is always also an erasure or anonymisation period next to it. Masking on its own is not a retention policy.
When this document says ‘technical entry’ it means the event stripped of name and number, that is, what remains after anonymisation.
3. Two things that apply to all the tables
No period depends on consent. We do not ask your permission to keep the data, and we do not ask it because consent is not the legal basis of this processing: the legal bases are the contract, a legal obligation or a legitimate interest, and they are written one by one in the Privacy Notice (/privacy). Consequently there is no box to tick to lengthen a period, and no box to untick to shorten it: to request early erasure, see section 11.
The periods apply while the relationship is ongoing as well. They are not an effect of termination. The Opening Log of an active Entrance is anonymised at 12 months exactly like that of a decommissioned Entrance.
4. Entrance data: the Customer decides, we keep them on its behalf
For these data the Customer is the controller and BGates is the processor under Art. 28 of the GDPR (Regulation (EU) 2016/679). The Customer may ask us for shorter periods for its own Entrance; it may not ask us for periods longer than those stated here.
| Category | Why we keep it | For how long | Why exactly that long | What happens afterwards | Where the technical rule is |
|---|---|---|---|---|---|
| Opening Log (date and time, command, outcome, channel, and who requested the opening: name and number, or email) | to allow whoever administers the Entrance to check a disputed access | 12 months from the event, consultable with name and number | in condominiums and businesses, disputes about an access arise late: weeks, sometimes months. Beyond one year the benefit no longer grows, while the risk of reconstructing the habits of the people coming and going does | anonymisation at 12 months: the name is removed, and the last three digits of the number remain. The technical entry is erased at 24 months | nightly job, keys app.retention.aperture-anonimizza-giorni (365) and app.retention.aperture-cancella-giorni (730) |
| Number of anyone who calls the Entrance without being authorised | to notice repeated attempts on the same Entrance | masked on screen from the outset; in full in our records for 30 days | to notice a repeated attempt the last three digits and a count are enough: the full number is not necessary for the purpose. Thirty days is the period that Italian law considers proportionate for unanswered calls (Art. 132(1-bis) of the Codice privacy (Italian Data Protection Code, Legislative Decree 196/2003)), used here as a comparison, not as a legal basis | immediate masking on screen; erasure of the full number at 30 days. The event remains with only the last three digits, and follows the periods in the previous row | nightly job, key app.retention.non-abilitati-giorni (30); on-screen masking carried out at the time of display |
| Authorised Numbers (number, name or label, days, time slots, validity) | to make the authorisation decided by the Customer work | for as long as the number is authorised; after revocation, 30 days | the delay is not a convenience margin: it is needed to resynchronise the Device's On-board Number List. Until the Device has received the revocation, the entry in the Service is what allows us to check that it has received it | final erasure of the number and the name | nightly job, key app.retention.phones-cancellati-giorni (30), on entries already revoked |
| On-board Number List (the numbers stored inside the Device; there are no names on board) | to allow the Device to recognise who is calling even when there is no connection with the Service | for as long as the number is authorised | it is the very function of the Device: without the On-board Number List, the Device does not open when there is no network | erasure from the Device's memory on revocation; on decommissioning, factory reset with verification (section 10) | command sent to the Device, not a job: the rule lives in the Service but is carried out on the Device |
| Invites (number, channel, message identifier, delivery outcome) | to deliver the Invite and be able to reconstruct who authorised whom | the link is valid for 30 days; the entry is erased 90 days after use or expiry | reconstruction is needed only if someone disputes an opening, and a dispute about an invite arises early: ninety days cover it with a margin | erasure of the entry, number included | nightly job, key app.retention.inviti-giorni (90) |
| Access requests arising from a Permanent QR code (self-declared name and number, IP address, outcome and date of the decision) | to allow whoever administers the Entrance to decide, and to allow us to protect a form open to anyone from misuse | until the decision, then 90 days | after the decision the request is no longer of use to anyone: it remains only so that we can explain why a person was admitted or refused. The IP address has a security purpose that is exhausted with the decision, and does not outlive the entry | erasure of the entry, IP address included | nightly job, key app.retention.richieste-qr-giorni (90) |
| Permanent QR code and Single-use QR code (identifier, sequence number, date of use, number and name of whoever used it) | to be able to say who got in with which code | 12 months from revocation or use | they describe the same event as the Opening Log and must have the same period: a code that has been used is an opening, and it would be inconsistent to keep its trace longer than the opening itself | erasure of the entry | nightly job, key app.retention.qr-revocati-giorni (365) |
| Personal Address Book (the contacts you save in your Private Area: name, number, note) | so that you can find them again when you authorise someone | for as long as your Account exists | it is yours: you decide about it, and it ends when the Account ends | complete erasure together with the Account | deletion of the Account (section 9), not a job |
| Command reservations (the technical entry that prevents two commands from starting together, and which contains the username of whoever gave the command) | to prevent the same Device from receiving two conflicting commands | 90 days | it is operational data that loses all usefulness as soon as the command has been completed; the ninety days serve only to make it possible to reconstruct a disputed sequence | erasure of the entry | nightly job, key app.retention.prenotazioni-giorni (90) |
| Logs downloaded from the Device for support (date, time, outcome, calling number) | to diagnose a fault or anomalous behaviour at the Customer's request | 90 days from upload, and in any case no later than the close of the intervention | they serve a specific intervention and are exhausted with it; keeping them longer would mean keeping a list of calls with no remaining reason | erasure of the files | deletion on the maintenance server. This is the only row of this table whose technical rule is not yet in operation: see section 14 |
5. The data for which we are the controller
| Category | Why we keep it | For how long | Why exactly that long | What happens afterwards | Where the technical rule is |
|---|---|---|---|---|---|
| Account and customer details (username, name, contact details, address, company name, tax code, VAT number, SDI code) | to provide you with the Service and give you access to the Private Area | duration of the relationship | while the relationship exists, the data are needed to perform it | erasure of the personal data on deletion of the Account, with the exceptions in the next row; the username remains burnt and is never reassigned to anyone | deletion of the Account (section 9) |
| Accounting and tax data (invoices, entries, Subscription data needed to issue them) | to comply with accounting and tax obligations | 10 years from the last entry | it is the period in Art. 2220 of the Codice civile (Italian Civil Code): it is not our choice and we cannot shorten it, even on request | erasure on expiry | kept separately from the deleted Account; the tax archive of invoices is with the payment provider |
| Raw payment event data (the full message we receive from the payment provider, which contains name, email, telephone and billing address) | not to record the same payment twice | 30 days with the personal details | the purpose is technical and is exhausted in days. It is not a tax archive: the tax archive is elsewhere, and that is why thirty days are enough | erasure of the personal details: only the identifier, type and date of the event remain | scheduled task of the activation system (Nest), not the nightly job of the management system |
| Technical records of calls to the SIM operator (request and response, with the SIM and Device identifiers) | to diagnose an activation or deactivation that went wrong | 90 days | it is the time within which an activation problem emerges and is disputed | erasure of the entry | scheduled task of the activation system (Nest) |
| Data of the SIM assigned to a Device (SIM identifiers, number, status) | to make the Device's connection work and manage it with the operator | duration of the relationship | they are the technical prerequisite of the Service | erasure of the link between SIM and Customer on termination | disassociation of the SIM in the decommissioning procedure (section 10) |
| Support correspondence (WhatsApp messages and emails, attachments, voice messages) | to give you support and be able to reconstruct what we said to each other | 24 months from the last message | it is the longest period among content data, and it rests on a precise fact: you wrote the content, knowing whom you were writing to. Below two years, disputes that arise at the end of the guarantee are not covered | erasure of the messages and of the attachments on disk | nightly job, key app.retention.wa-giorni (730) |
| Notifications (title, text, notification data) | to show you what has happened recently at your Entrance | 90 days | ‘recently’ means weeks, not years | erasure | nightly job, key app.retention.notifiche-giorni (90) |
| Push notification subscription (the technical address at which your browser receives notifications) | to deliver notifications to your device | for as long as it is valid | it is purely technical data: without it, the notification does not arrive | erasure on revocation, on signing out of the Account, on deletion of the Account, or when the notification service rejects it | immediate erasure on the event, not a job |
| Sessions and access tokens | to keep you signed in without asking for your password on every page | 7 days | it is the duration of the session: beyond that, the token is just a key left lying around | erasure every night at 04:17 | nightly token clean-up, already in operation today |
| Devices confirmed for opening from the web app (fingerprint of the identifier, description of the device, date of confirmation, method, last use) | to open only from devices that you have confirmed yourself | for as long as the device is confirmed | without the row the device is no longer recognised: it is the condition for opening, not a history | immediate erasure when unlinked | management system, at the time of unlinking |
| Device confirmation codes and requests | to verify the code, limit attempts and sends, and allow the person who administers the Entrance to unlock you | the code fingerprint until use or expiry (10 minutes); description of the device, times and attempts 24 hours | once expired or used, the code is no longer needed; the request is needed for the hourly limits and for unlocking requests made in the last 24 hours | erasure of the fingerprint, then of the row | management system at the time of use; automatic clean-up every minute (fingerprints) and every hour (rows) |
| Location of the Device derived from the mobile cell | to diagnose connection problems and assist you | only the latest value | we do not keep a location history: each measurement overwrites the previous one | overwriting; erasure with the Device. The trace of the queries remains in the Opening Log and follows the periods in section 4 | overwriting at the time of measurement. At the Customer's request the measurement is switched off for its Device |
| Address where the Device is installed | to install, assist and intervene | duration of the relationship | it is contract data | erasure on termination | decommissioning procedure (section 10) |
| Temperature measured, time slots set, status of the Entrance | they are the features that the Service provides | only the latest value | we do not keep a history: each measurement overwrites the previous one | overwriting | overwriting at the time of measurement. |
| Web server logs (IP address, page requested, outcome, browser) | security: to notice attacks and misuse | 14 days | fourteen days are enough to see an attack in progress and to reconstruct it; beyond that, a browsing archive builds up that does not serve that purpose | erasure by rotation | rotation of system logs, already in operation today |
| Logs of the Devices' messaging channel and of the server processes (Device identifiers, connection outcomes, source addresses) | security and continuity of the Service | 60 days | an intermittent connection problem can only be seen over a long window: below two months a fault cannot be distinguished from misuse | erasure by rotation | rotation of system logs, already in operation today |
| Log of our Operators' actions (who read, exported, printed, changed, and when) | to be able to demonstrate who did what with Customers' data | 24 months | here the long period is in favour of the people observed, not of us: it serves to check on whoever has power over the data. For the access logs of system administrators, the Garante sets a minimum of six months; twenty-four months are above that minimum and implement the accountability obligation in Art. 5(2) GDPR | erasure | nightly job, key app.retention.admin-audit-giorni (730) |
| Acceptances and acknowledgements of documents (document, version, date and time, IP address, browser, screen) | to be able to demonstrate what you accepted and when | duration of the relationship + 10 years | it is the evidence of acceptance, and it is needed for as long as it may serve in a dispute about the contract. The acceptances of people with an ongoing relationship do not expire: erasing them would remove the evidence while the contract is alive | erasure | nightly job, key app.retention.accettazioni-anni (10), only on acceptances of deleted Accounts |
| Requests to exercise rights and the related responses | to be able to demonstrate that we acted on a request | 3 years | the response must be kept long enough to demonstrate it to whoever asks | erasure | manual handling recorded in the internal procedure |
| Register of personal data breaches | it is an obligation under Art. 33(5) GDPR, and it applies also to breaches that were not notified | 5 years | it serves to reconstruct a sequence of events that may emerge much later | erasure | manual handling recorded in the internal procedure |
| Encrypted backup copies | to be able to restore the Service after a failure | 14 days | it is the window within which a failure is detected and a restore still makes sense; beyond that, an old copy would roll back more than it saves | erasure by rotation | automatic rotation of the copies, already in operation today (section 7) |
6. What it means that the periods run from today
These periods apply from this version of the document, and from the same date the automatic erasures that carry them out are in operation: the nightly job in section 8, the clean-up of session tokens, and the rotation of the logs and of the backup copies.
It must be said precisely, because the difference between a rule that is written and a rule that is in operation is exactly what matters: before this version the Service kept application data without a stated period. This is not a nuance, and it is the reason why this document exists. Data already present on the date of entry into force follow the same periods, calculated from the moment they were collected.
The only rule in this document not yet in operation is the deletion of the files that the Device uploads to the maintenance server: it is written in section 14 and nowhere else.
7. Backup copies
Every night we make a copy of the databases and of the configuration files. The copy is encrypted with GPG AES-256, is accompanied by a checksum that verifies its integrity, and is kept in a folder readable only by the system user that produces it. Retention is 14 days, by automatic rotation.
What this means for you: when data is erased from the live systems, it may remain in the backup copies for up to 14 days, and then it disappears from there too. We do not restore a copy to recover data erased at someone's request.
Two facts that we state because they are true, not because they suit us:
- the copies are on the same machine that provides the Service. There is no off-site copy today: losing the machine would also mean losing the copies. This is a measure that has been decided and is not yet in operation, and it is recorded as such in our impact assessment;
- the copies do not include the attachments and voice messages of support correspondence, nor the archives of the internal test areas.
8. Where the technical rule is: the nightly job
Almost all the rules in the tables are carried out by a single nightly job of the management system, which starts every night at 04:40 and writes, at each run, an entry with a count of what it has anonymised and erased. Each period is a configuration key, expressed in days, and can only be shortened: lengthening it beyond the value stated in this document would make the document false.
| Key | Value | What it does |
|---|---|---|
app.retention.aperture-anonimizza-giorni | 365 | removes the name from the Opening Log and reduces the numbers to the last three digits |
app.retention.aperture-cancella-giorni | 730 | erases the Opening Log entries |
app.retention.non-abilitati-giorni | 30 | removes the full number of anyone who called without being authorised |
app.retention.phones-cancellati-giorni | 30 | permanently erases revoked Authorised Numbers |
app.retention.inviti-giorni | 90 | erases used or expired Invites |
app.retention.richieste-qr-giorni | 90 | erases access requests that have been decided, IP address included |
app.retention.qr-revocati-giorni | 365 | erases revoked or used QR codes |
app.retention.notifiche-giorni | 90 | erases notifications |
app.retention.wa-giorni | 730 | erases support correspondence and attached files |
app.retention.prenotazioni-giorni | 90 | erases command reservations |
app.retention.admin-audit-giorni | 730 | erases the log of our Operators' actions |
app.retention.accettazioni-anni | 10 | erases the acceptances of Accounts deleted more than ten years ago |
Outside this job are the following, and we say so that you know that not everything is in the same place:
- the clean-up of session tokens, which runs every night at 04:17 and was the only automatic erasure of data already in operation before this document;
- the reduction of raw payment event data and the erasure of the technical records of calls to the SIM operator, carried out by the activation system;
- the on-screen masking of the number of anyone who calls without being authorised, which is not a job: it happens at the moment the entry is displayed, from the outset;
- the rotation of system logs (14 and 60 days) and of backup copies (14 days), which are rules of the operating system and not of the management system;
- the erasure of the On-board Number List, which is carried out on the Device and not on our servers.
9. What happens when you delete your Account
Deletion of the Account from one's own Private Area, and the complete erasure that follows, are in operation from the date of entry into force of this version.
You can delete your Account from your Private Area: in the dashboard, from the profile menu under ‘Legal documents and your data’, or at https://app.bgates.it/profilo. Confirmation is by means of a code sent to your email address. If you prefer, you can always ask us to do it by writing to info@bgates.it.
When you do so:
- we erase your customer details, your Personal Address Book, your notifications, your notification preferences and your push notification subscriptions;
- we replace your number with only its last three digits in the Invites that concern you;
- we revoke the Authorised Numbers that correspond to your number: final erasure takes place after the 30 days needed to resynchronise the On-board Number List;
- we anonymise your name and your number in the Opening Log: the entries remain as events, without you;
- we keep accounting and tax data for the 10 years required by Art. 2220 of the Italian Civil Code, and the records of acceptances for 10 years from the end of the relationship, because they are the evidence of what you accepted;
- we burn your username: it is not reassigned to anyone. This is not done to spite you; it is a security measure — without it, a new Account with the same name would inherit the sessions of the previous one.
Copies of your data remain in the backup copies for up to 14 days (section 7).
What remains is not hidden: it is exactly this list, and the screen asking you to confirm must say the same thing. If you read on screen a statement stronger than this one, report it to us at info@bgates.it: it is the statement on screen that is wrong, not this document.
10. End of the relationship and decommissioning of the Device
On termination of the Subscription, the Customer chooses between return and erasure of the data processed on its behalf. The time limits for that choice — 30 days to communicate it, 15 days to make the export available, 30 days for erasure, 14 days for the rotation of the backup copies, 10 days for the written certification — are in the Data Processing Agreement (/dpa), section ‘End of the relationship’.
When a Device is decommissioned, resold or changes owner, its decommissioning includes: the factory reset with verification that the On-board Number List is actually empty; deletion of any files downloaded from the Device for support; revocation of the QR codes and of the activation links; disassociation of the SIM; and a written record of all this.
11. Requesting erasure before the period expires
You can ask us to erase data before the expiry stated in these tables. Write to info@bgates.it: we will reply within one month.
What we can do, and what we cannot:
- we can erase earlier the data for which we are the controller, when we no longer have a reason to keep them;
- we cannot erase accounting and tax data before the ten years: it is a legal obligation and not within our discretion;
- we cannot decide by ourselves about Entrance data (section 4), because the controller is the Customer: in that case we forward the request to the Customer without delay and tell you that we have done so. If you need to know to whom it was forwarded, ask us;
- we cannot erase selectively from a backup copy: we wait for the 14-day rotation.
You can also object to processing based on a legitimate interest (Art. 21 GDPR). If you object, we must stop unless there are compelling legitimate grounds that override: we carry out the check case by case and write to you to tell you the outcome.
12. A period can be suspended, and we say when
In three cases data is kept beyond the period written in the tables. There are three, they are these, and there are no others:
- a legal obligation requires us to keep it longer;
- an ongoing dispute, in court or out of court, concerns that very data: in that case we keep it for the duration of the dispute and for the time allowed for appeal, and no longer;
- a request from an authority asks us to keep it: we verify the request, record it and keep only what we are asked to keep.
Outside these three cases, a period that has been exceeded means data that should no longer be there.
13. What the suppliers keep, and for how long
Some data pass through suppliers that have their own retention periods, which we do not decide. We write them here because they are part of the honest answer to the question ‘how long does my data remain’. The complete list of suppliers, with their role and country, is in the Suppliers document (/fornitori).
| Supplier | What it receives | How long it keeps it |
|---|---|---|
| Meta Platforms Ireland Limited / WhatsApp Ireland Limited — Invite channel and support | number, message content, delivery status | the terms provide for deletion of residual content within 90 days of the end of use, save for legal obligations. A general retention period for messages during the relationship does not appear in the published contractual pages: it has not been found. |
| Commify Italia S.r.l. (Skebby) — fallback SMS | number and text of the SMS | the contract states that the text is kept only for the time necessary for sending, unless the customer requests otherwise. We have not requested anything different |
| Aruba S.p.A. — email | email address and content of emails | telematic traffic data are kept for 6 years, under a legal obligation on the supplier (Art. 24 of Law 167/2017). It is not a period we can shorten |
| Stripe Payments Europe, Limited — payments and invoices | name, email, telephone, billing address, card details, collected by Stripe on its own page and not by our systems | according to Stripe's privacy notice, which applies to that page. It is also the archive of the invoices issued |
| netcup GmbH — infrastructure, Nuremberg (Germany) | everything on the machine | does not keep anything for purposes of its own. |
| beaconDB — conversion of the mobile cell into coordinates | the identifiers of the cell to which the Device is connected, not the identifier of the Device | the service's information note states that access logs are deleted after 28 days. |
| Browser notification services (Google, Mozilla, Apple) | the technical address to which the notification is delivered, and the text | according to the terms of each service. The telephone number of the person requesting access is to be removed from the text of notifications, and this is a measure that has been decided |
14. What does not yet have a period
This section exists because a document on retention that kept silent about its own gaps would be the most useless of documents. Today the following still have no written rule:
- the files downloaded from the Device for support, stored on the service server (section 4, last row): the period is 90 days, but automatic deletion of those files is not yet in operation and today it is done by hand at the close of the intervention;
- the incoming service mailbox, which today keeps received messages indefinitely, including unsolicited ones sent by third parties: the Service reads them in order to process them, but does not delete them and does not even mark them as read. On the email supplier's side the period is the one stated in section 13; on our side there is not yet any period.
- the machine's security alert log, which today has no rotation. It contains aggregate counts and not personal data, but it grows without limit and must be governed in any case;
- the archives of the internal test areas, which contain sample data.
For each of these points the rule will be written in this document, and the document will change version.
15. Changes to this policy
This policy changes when a period changes or when one of the points in section 14 is closed. Each version has a number and a date of entry into force, at the bottom of the page.
A clarification that applies only to this document: a longer period is always a substantial change, and does not come into force silently. A shorter period comes into force immediately, because it is in your favour and there is nothing to accept.
Version 2026.10.20-1 — in effect from 20 October 2026. When we change something substantial — a new purpose, a new supplier, a longer retention period — we publish the new version here, with its date, and if you have an Account we tell you by email. This document is not accepted: it is read, and we do not ask you to tick any box. Corrections of form do not change the version. Previous versions are available on request from info@bgates.it.
Business Gates S.r.l. · Via Ripamonti 44, 20141 Milano · P.IVA 05759280968 · info@bgates.it
