Data Breach and Incident Management

Courtesy translation. In case of discrepancy, the Italian text prevails.

This document says what happens when something goes wrong: unauthorised access, data ending up where it should not, a Service that does not respond, a security flaw in the Device. It says whom we notify, how quickly, what we write in the notice, what we ask you to do and what we tell you when it is over.

It concerns the GT PRO 4G model and the related Service. It does not concern the earlier models that work by SMS messages only, nor the Bluetooth channel.

We do not ask you to tick any box for this page. There is nothing to consent to: there are commitments that we make and things that you must do. In the relationship with the Customer, however, this document is not only informative: it is referred to by the Data Processing Agreement (/dpa), and the time limits written here are the time limits that the Agreement adopts. Should this document and the Agreement say different things, the Agreement prevails, and we correct this text.

We address as you those who read for themselves. When the rule changes depending on the role — because whoever administers an Entrance is one thing, and whoever opens it is another — we use the defined terms: Customer, Administrator, User, Distributor, Installer, BGates Operator.

Write to info@bgates.it even if you have no relationship with us and have noticed something. We do not require anyone to register in order to report a problem.

1. The five things that matter

If you read only this section, read these five.

1. Report straight away, even if you are not sure. The first hours count more than any explanation given afterwards. A suspicion that is reported and then disproved costs nobody anything.
2. If you administer an Entrance, the first thing you do is revoke: the Authorised Number, the QR code, the Account of the person who should no longer get in. Revocation is in your hands and does not require us to intervene.
3. If the breach concerns the data of your Entrance, you are the Controller: notification to the Garante per la protezione dei dati personali (Italian Data Protection Authority) is your responsibility, not ours. We inform you within 24 hours of becoming aware of it and give you everything you need to decide.
4. Not everything that goes wrong is a data breach. A Service that does not respond is an availability incident: annoying, sometimes serious, but something else — and it is handled differently (section 9).
5. The Entrance can still be opened with your physical means. Whatever happens to our systems, the key, the remote control and manual opening continue to work. That is why we ask you always to keep one of them (/sicurezza-account).

2. The words we use, and why the difference matters

Three different events, three different sets of rules, three different clocks. Confusing them loses the hours that count.

The point where the first two meet. If personal data are not accessible for a prolonged period, or can no longer be restored, the loss of availability is also a personal data breach: availability is one of the three things the Regulation protects, together with confidentiality and integrity. So the question is not ‘were any data seen?’, but ‘has someone seen them, changed them, lost them, or can we no longer give them back to those entitled to them?’. If the answer to any of these is yes, sections 6, 7 and 8 apply.

An event can be all three things at once. A fault exploited by an outsider who opens an Entrance and reads the Opening Log starts the clock of the GDPR and that of the regulation on the cybersecurity of products, while the Service is down. The three procedures run in parallel: none waits for the other.

What is not a personal data breach, and we say so because you will ask us:

• an unsuccessful opening due to lack of mobile network coverage or to a fault in the Entrance's automation;
• scheduled maintenance announced in advance (section 9.3);
• a number authorised by mistake by whoever administers the Entrance: it is a configuration error, and whoever made it corrects it by revoking. It becomes a breach if that error has exposed other people's data — for example if it has made the Opening Log visible to a stranger;
• the fact that the number of whoever calls remains written in the Opening Log: this is how the Service works, as described in /privacy, not an incident.

3. How we notice

An obligation that runs from an event that no one sees never starts running. That is why we state honestly where reports come from today.

This is how it is designed, and it is not yet live as of 22 September 2026: routing of automatic alerts to a named contact person and to a fallback, with recording of the time at which the alert was seen. Until then detection relies mainly on reports from people, and this document does not state otherwise.

3.1 The ‘time of becoming aware’

This is the moment at which someone at BGates has a reasonable degree of certainty that a security incident has affected personal data. All the time limits in this document run from that moment: the 24 hours towards the Customer as Controller, the 72 hours towards the Garante, the 24 hours for the product early warning.

Two clarifications, because this is the point that gives rise to disputes:

1. an initial suspicion does not start the time limit running, but it requires an immediate check. ‘We did not know’ does not protect those who did not look;
2. the date and time of becoming aware are recorded first, in the breach register (section 12), before any other activity. If the time limit is exceeded, we say so and write down the reason: a delay with reasons is provided for by law; a delay kept quiet is not.

4. What we do in the first hours

In this order, and the order is part of the procedure:

1. We contain, without destroying evidence. We revoke the sessions and credentials involved, close off access, isolate the component. We do not delete logs, we do not restart to ‘clean up’, we do not overwrite.
2. We secure the evidence. The web server logs last 14 days and those of the messaging channel and of the processes 60 (/conservazione): if we do not make a copy outside the rotation, they disappear by themselves while we are still working things out.
3. We open the entry in the breach register, with the time of becoming aware.
4. We assess the risk to people: what type of data, how much, who they are, what could happen to them. One circumstance weighs particularly heavily for us: if the event has exposed Authorised Numbers, Invite tokens, QR codes, Device passwords or keys, it is not just a confidentiality problem — it is the key to a real door. In that case the risk is normally high, and direct communication to the people must be seriously considered.
5. We decide whom to notify, using the criteria in sections 6, 7, 8 and 10.
6. We restore, and only then close the case with the analysis in section 11.

Before the assessment we communicate nothing externally. This is not reticence: a wrong notice sent to thousands of people does more harm than three hours of silence, and a detailed notice sent while the flaw is still open is an invitation. Once the assessment is done, we communicate — even if we do not yet know everything (section 6.3).

5. What you must do

5.1 Report, and quickly

Write to info@bgates.it — or use the reporting form in the Private Area and in the app, when it becomes available — as soon as you notice one of these things:

What to write: what you observed, when (even approximately), where (address of the page, serial number of the Device, name of the Entrance), how it can be repeated if you know, and a contact address for our reply. What not to write: passwords, six-digit codes, the content of QR codes. We do not need them, and an email message is not the place to keep them.

This is how it is designed, and it is not yet live as of 22 September 2026: the reporting form inside the Private Area and inside the app. Until then the channel is info@bgates.it, and it is sufficient.

5.2 Revoke, which is the thing only you can do straight away

If you administer an Entrance, revocation does not require us to intervene and does not wait for our reply:

1. revoke the Authorised Number of the person or phone involved;
2. revoke the exposed QR code or have it regenerated; if it is the Permanent QR code displayed at the Entrance, the old code stops being valid and the new one is printed;
3. deactivate the Account of whoever should no longer administer;
4. go back over the Opening Log for the period concerned and report to us the entries you do not recognise;
5. refuse the access requests that arrived from the QR code that you do not recognise: the number given in a request is self-declared and not verified.

If you cannot carry out one of these operations from the Private Area, write to info@bgates.it and we will do it, telling you when it is done.

5.3 Cooperate, if the incident concerns your Entrance

You are the Controller of the data of your Entrance: without you the case cannot be closed. We ask you to:

• not delete messages, notifications and logs concerning the event, even if they seem useless to you: they are needed for the reconstruction;
• answer our questions about what you can see on your side, within times compatible with the 72 hours that the law gives you to notify;
• tell us what you have decided: whether you have notified the Garante, whether you have informed the people, whether you considered that you did not need to. We record it in our register, because your decision too is part of the history of the event;
• coordinate public communications with us, when the event concerns both of us. This does not in any way limit your legal obligations towards the Garante and towards the people: those come before any coordination, and no clause of any BGates document suspends them.

5.4 If you are looking for vulnerabilities

These are the conditions for doing so in good faith: do not test on installations that are not yours, do not access other people's data, do not degrade the Service, do not alter or delete anything, stop as soon as you have proof that the problem exists, and do not make it public before it has been fixed or before we have discussed it. Anything that does not fall within these conditions is governed by the Acceptable Use Rules (/uso-consentito).

6. When the breach concerns the data of your Entrance: what we do for you

This is the most frequent case, because the Authorised Numbers, the On-board Number List, the requests arising from QR codes and the Opening Log are data for which the Customer is the Controller and we are the processor (/dpa).

6.1 Who notifies the Garante: you

You are the Controller, and notification to the Garante is your responsibility. We do not notify in your place and we do not substitute our assessment for yours: the Regulation assigns that decision to the Controller, which is the only one who knows the context in which its own Entrance is used. The time limit the law gives you is 72 hours from when you become aware of it, that is, from when we tell you (Art. 33(1) of the GDPR (Regulation (EU) 2016/679)).

6.2 When we notify you: within 24 hours

We inform you without undue delay and in any case within 24 hours of the time we become aware (Art. 33(2) GDPR). The Regulation does not set a number of hours for the processor: we set that number ourselves, and we set it at 24 for an arithmetical reason — so that of your 72 hours at least 48 remain for you to assess and notify.

We notify you by email, at your Account's address, and with a copy to your PEC (certified email) address if you have given it to us. If the notice does not appear to have been delivered, we call you at the number in your customer details within the same 24-hour time limit: your 72-hour time limit does not stop because a message has not arrived.

6.3 What the notice says

The content follows Art. 33(3) GDPR, that is, exactly what you will have to write to the Garante, so that you can reuse it:

If we do not yet know everything, we notify you anyway. We send you what we know within the 24 hours and add to it afterwards, in phases. Waiting for the full picture in order to send a tidy notice is the easiest way to let your time limit expire.

6.4 How we assist you

At your request, and at no additional cost (Art. 28(3)(f) GDPR):

• we give you the information in our possession to complete the notification to the Garante;
• we help you estimate how many people are involved, by extracting the data from our systems;
• if you wish, we prepare the draft message to the people;
• we deliver the message on your behalf when the only contact detail available is the telephone number — which is the case for most Users, who do not have an Account: we do so with a short, non-promotional message, and we tell you how many people it reached;
• we suspend as a precaution an Authorised Number or a QR code, if you ask us to, pending your decision. This is a technical measure, not a decision on the merits.

6.5 If you decide to do nothing

We record it in the breach register, with the date and the reasons you give us. We do not take your place. However, if the risk to people is high and also concerns data for which we are the Controller, we decide what to do for that part.

7. When we are the Controller

These are the data we decide about: Accounts and customer details, invoicing and Subscriptions, the technical logs of the infrastructure, SIM data, the cell-based location of the Device, support conversations, and the log of our Operators' actions. The complete list is in the Data Processing Agreement (/dpa) and in the Privacy Notice (/privacy).

In these cases:

1. we notify the Garante per la protezione dei dati personali without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to the rights and freedoms of people (Art. 33(1) GDPR). If we exceed the 72 hours, we notify anyway and give reasons for the delay;
2. if we decide not to notify, the decision and its reason are put in writing in the breach register. Not notifying is a decision that is documented, not a silence;
3. we communicate with the people when the risk is high (section 8);
4. if the same breach also affects data for which a Customer is the Controller, the two procedures run together: we notify for our part, and inform the Customer for its part, within the time limits in section 6.

8. When we notify you directly as someone who uses the Service

When. If the breach is likely to result in a high risk to your rights and freedoms (Art. 34 GDPR). In our Service the typical cases are: exposure of Authorised Numbers together with an indication of the Entrance they open, exposure of the Opening Log, compromise of tokens, QR codes or passwords that open an Entrance, and exposure of the content of support conversations.

How. With a direct message: email if you have an Account, WhatsApp or SMS if the only contact detail we have is your telephone number — these are the same channels we use for Invites. In plain language, without formulas, and with five things in it: what happened, which data concern you, what you are at risk of, what we are doing, what you can do (for example: ask for your number to be revoked, check recent openings, change your password). And a contact address for your reply.

When the law allows us not to do so (Art. 34(3)): if the data were protected in such a way as to remain unintelligible to whoever saw them; if we have taken subsequent measures that ensure the high risk no longer materialises; or if notifying each person would involve disproportionate effort — and in that case we make a public communication that is equally effective, on the website and in the Private Area.

Something that must be said about that first exception. Today the data in our databases are not encrypted at rest: for us, today, the first exception can almost never be relied on. We prefer to write this here rather than find it out together when it matters.

This is how it is designed, and it is not yet live as of 22 September 2026: encryption of data at rest in the databases and on the server disk.

9. When the Service does not work, but the data are where they should be

9.1 What we do

Containment, recovery, and the status communication in section 9.2. The priority, in this order, is: get the opening of the Entrance working again, then the Private Area and the app, then the ancillary features.

What continues to work even if our systems are down. The Device keeps the On-board Number List on board, that is the list of Authorised Numbers with their days, time slots and expiry dates: whoever calls from an Authorised Number continues to open even when there is no connection with the Service. What does not work is opening commanded from the app, management of numbers, the up-to-date Opening Log and notifications.

What we do not promise you. We do not promise an availability percentage, we do not promise a recovery time and we do not promise that the Service is a security or emergency system: it is not, and that is why we ask you always to keep an alternative means of access to the Entrance. What we are liable for, and within what limits, is set out in the Limitations of Liability and Availability of the Service (/responsabilita) and in the Terms (/termini).

9.2 The status communication

Where. Today the notice arrives by email at your Account's address, and notifications in the Private Area reach those who use it from the management system. The app for Customers and Users and the mobile app do not have notifications today: that is why email remains the channel we state.

This is how it is designed, and it is not yet live as of 22 September 2026: the public Service status page and status notifications inside the app. Until they exist, this document states email and nothing else.

9.3 Scheduled interventions

Updates and planned interventions are not incidents, but they must be announced in advance:

• we announce them to you in advance, stating the window and what will not be available;
• during a Device firmware update there is a window in which the Device does not execute commands: in that window remote opening does not work, while opening by calling from an Authorised Number resumes as soon as the update is complete;
• where we can, we choose low-usage time slots.

10. The second clock: product security

The GT PRO 4G Device is a product with digital elements within the meaning of Regulation (EU) 2024/2847 on the cybersecurity of products (Cyber Resilience Act). The reporting obligations in its Art. 14 have applied since 11 September 2026 and, as expressly provided by Art. 69(3), they apply also to Devices already installed before that date.

This means that, in addition to what is written above:

Why we write this in a document addressed to you. Because the recipients, the triggers and the time limits are different from those of data protection, and a real incident triggers both: do not be surprised if, for the same event, you receive two different communications from us and if the Garante is not the only authority involved.

Security updates. We provide them for the period stated in the Terms of Sale (/condizioni-vendita), and when an update closes a flaw we tell you, together with what happens if you do not install it.

11. What happens afterwards: analysis and corrections

Closing an incident does not mean getting the Service working again. After recovery, for every personal data breach and every significant incident:

1. we reconstruct the sequence: what happened, when, what made it possible, what made it last longer than necessary;
2. we identify the cause, distinguishing it from the symptom. ‘Human error’ is not a cause: the cause is what allowed a human error to produce that effect;
3. we decide the corrective measures, with a person responsible and a date for each;
4. we check that they have been carried out, and not only decided;
5. where necessary, we update the Service documents: if an incident shows that a sentence in these texts was not true, the sentence is corrected as well as the system.

What you receive. If the incident concerned the data of your Entrance or interrupted the Service significantly, we send you a final report within 30 days of closure, with points 1, 2 and 3 above and the status of the corrections. It is the same document that, if you are a business customer, you can attach to your accountability documentation.

What it does not contain. Technical details that would allow the attack to be repeated, other customers' data, credentials. If you need more detail for a compliance obligation of your own, ask at info@bgates.it and we will assess how to give it to you.

One exercise a year. At least once a year we simulate a realistic incident and time detection, taking charge, assessment and the draft notification. This serves to discover beforehand, and not during an incident, the point at which the procedure jams.

12. The breach register

We document every personal data breach that concerns us, including those that are not notified to anyone: it is an obligation under Art. 33(5) GDPR, and the decision not to notify is itself something to be justified in writing.

For each event the following are recorded: the reference number and opening date, the date and time of becoming aware, how it came to light, the facts, the data and people involved, our role (controller or processor, and for which Customer), the risk assessment, whether it was notified to the Garante and when or why not, whether it was communicated to the people, when we informed the Customers as Controllers, whether it was reported under the regulation on the cybersecurity of products, the measures taken and the closing date.

How long we keep it: this is written in the Data Retention Policy (/conservazione), which is the document where all the retention periods live. If you are a business customer you can request an extract for the part concerning you, under the conditions of the Data Processing Agreement.

13. If the incident originates with a Supplier

Part of the Service runs on third parties' systems. The Suppliers are listed one by one, with what they receive and where they are, in `/fornitori`. Those whose compromise would have the most direct effect on you are netcup GmbH (hosts the entire Platform), Meta Platforms Ireland Limited (delivery of Invites and WhatsApp support channel), Commify Italia S.r.l., Skebby brand (fallback SMS), Aruba S.p.A. (email), Stripe Payments Europe, Limited (payments) and the notification services of Google, Mozilla and Apple.

When the breach originates with one of them:

• the Supplier must inform us without undue delay; from that moment our time limits towards you run, exactly as if we had noticed by ourselves;
• the time limits in this document do not change: the fact that the cause lies elsewhere does not move the 24 hours or the 72 hours for us;
• we tell you which Supplier is involved and what it was processing for us, unless saying so would expose people to a further risk while the incident is still open.

14. What we do not promise

• We do not promise that it will not happen. No BGates document will ever say that security is absolute, total, guaranteed or one hundred per cent: it is not, for anyone.
• We do not promise a recovery time. We promise the order of priorities, the communication and the notification time limits in this document.
• We do not promise to notify in your place when you are the Controller: the decision, and the responsibility, remain where the law places them.
• We do not have ourselves indemnified for infringements of personal data protection law, and no clause of the BGates documents limits our liability for wilful misconduct or gross negligence, for personal injury or for breach of mandatory rules (/termini, section 13.4).

15. Where to find the rest

Version 2026.09.22-1 — in effect from 22 September 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.