Specific Terms for Customers and Administrators

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

These Terms apply to anyone who configures an Entrance: whoever decides which Authorised Numbers open it, on which days and in which time slots, whoever approves the requests that come in from the QR codes, and whoever consults and exports the Opening Log.

Whoever does these things exercises a power over people who, in most cases, have no relationship with Business Gates S.r.l. and never chose it. The rules that follow serve to make that power lawful, traceable and reversible. They are not recommendations: they are contractual obligations, and breaching them has the consequences set out in § 19.

These Terms concern the GT PRO 4G model and the related Service. They do not concern the earlier models that work by SMS messages only, nor the Bluetooth channel.

1. Whom they are addressed to

Where the same person holds more than one role — for example an Installer who is also the Customer for a Device of its own — the obligations are cumulative and apply to each Entrance according to the role in which that person operates on it.

If the Customer is a condominium, the Controller is the condominium as a management body; the condominium administrator signs on its behalf and enters the name of the condominium in the customer details.

2. How these Terms fit among the other documents

These Terms are in addition to the Terms of Use and do not replace them. In case of conflict on matters concerning the administration of an Entrance, these Terms prevail.

The documents listed are incorporated by reference and form an integral part of these Terms. A fact that applies to several documents — for example the retention period of the Opening Log — is written in one document only and the others refer to it: that way they do not diverge.

3. Roles in the processing of personal data

3.1 The Customer is the Controller of what it decides

The Customer is the Controller (Art. 4(7) of the GDPR (Regulation (EU) 2016/679)) for:

• which Authorised Numbers may open its Entrance, on which days, in which time slots and with which expiry date;
• the name associated with each number in the list of Authorised Numbers;
• the approval or refusal of the requests that come in from the QR codes;
• the use it makes of its Entrance's Opening Log, including export;
• the Personal Address Book of its own Account, when it uses it for professional purposes.

The legal basis of this processing is, as a rule, the Customer's legitimate interest (Art. 6(1)(f)): protecting the people and property beyond the Entrance and managing in an orderly way who gets in. It is not consent, and could not be: consent belongs to the data subject (Art. 4(11)) and no one can give it on behalf of someone else.

A Customer relying on legitimate interest must be able to demonstrate the balancing between its own interest and the rights of the authorised people. For this purpose BGates provides the guidelines annexed to the Data Processing Agreement; the assessment remains the Customer's.

3.2 BGates is the Processor for that processing

For the processing in § 3.1 Business Gates S.r.l. is the Processor under Art. 28 GDPR: it stores the numbers, transmits them to the Device, delivers the Invites and keeps the Opening Log on the Customer's behalf. The documented instructions, the security measures, the sub-processors, the assistance with data subjects' rights and the rules on erasure at the end of the relationship are in Annex A (§ 22), which is the Data Processing Agreement document (/dpa) in its version in force.

3.3 What BGates is the Controller of instead

Outside a closed list, BGates is the Processor. Within that list it is an independent controller, with its own purposes and its own liability. The list is set out in full in Annex A and comprises: the security of the Service and the prevention of misuse; the technical logs of the infrastructure; network diagnostics, including the location of the Device derived from the mobile cell; the support provided by BGates Operators; legal, accounting and tax compliance; the technical evidence of delivery of the Invites; the improvement of the Service using pseudonymised data; the log of administrative actions.

3.4 There is no joint controllership

BGates and the Customer are not joint controllers. BGates decides the purposes and means of the Platform; the Customer decides, within the Platform, who gets in through its Entrance and when. They are two separate and sequential determinations, not joint ones, and the necessary complementarity required by EDPB Guidelines 07/2020 on the concepts of controller and processor is lacking.

3.5 Distributors and Installers

A Distributor or Installer that enters Authorised Numbers or creates Accounts on behalf of a Customer processes that data on the Customer's behalf and assumes towards the Customer the obligations of these Terms and of Annex A. For the data of its own commercial customers — customer details, offers, its own support — it is an independent controller and is liable in its own right.

4. Lawfulness of entering third parties' numbers

This is the obligation on which all the others depend.

4.1 The number is a key. When a number is authorised on an Entrance, whoever calls from that number opens it, with no further check. The number is also written inside the Device, which is located at the Customer's premises, and every use of it is recorded.

4.2 Whoever enters the number represents and warrants that:

1. they are entitled to let that person in through that Entrance (§ 6);
2. the number is that of the person they intend to authorise, and not of someone else;
3. they have informed that person before, or at the latest at the time of, the authorisation (§ 7);
4. that person agrees to receive the Invite message on the number given.

4.3 Point 4 is not consent to the processing of data. The processing is not based on consent and consent is not to be collected: the representation serves a different obligation, of a contractual nature, that BGates has towards the provider of the messaging channel, which allows messages to be sent only to people who have provided their own number and have given permission to be contacted. That permission can exist only with the Customer, because it is to the Customer that the person gave the number.

4.4 What may not be done. The following are not to be authorised: numbers obtained from other parties' directories, lists or archives; numbers of people with whom there is no relationship justifying access; numbers entered to find out whom they belong to or whether they are active. The Service is not to be used to authorise a person without their knowledge for the purpose of watching their movements.

4.5 What cannot be contracted away. The Service, today, allows a number to be authorised without verifying who holds it. This is a feature of the system, and BGates is liable for it under Articles 25 and 32 GDPR. No representation by the Customer shifts that liability: the warranties in § 4.2 concern the choice of the person and the information given, not the way the system is designed.

How authorisation works today. Authorisation is immediate: the number opens from the moment it is authorised, and the Invite is sent at the same time. Opening the Invite is not a condition of the authorisation, and the authorisation does not lapse by itself if the Invite is never opened. If the number is never used, the Customer is required to revoke it.

5. Accuracy and updating of data

Whoever administers an Entrance processes data of people who do not control, and cannot correct, what is written about them in the Service. Hence the following obligations (Art. 5(1)(d) GDPR).

1. Correct numbers. The number is checked before it is saved. A mistyped number authorises a stranger and, in the Opening Log, that stranger's openings appear under the name of the person who was meant to be authorised.
2. True and plain names. The name associated with the number serves to recognise the person, not to describe them. No assessments, unnecessary titles, or information about health or private life are written in it: that field is visible to anyone who administers the Entrance and ends up in the Opening Log entries.
3. Real time slots and expiry dates. Days, time slots and expiry date are set to what is actually needed. Authorising seven days a week with no end date, when access is needed during working hours, is excessive processing.
4. Default expiry date. Every authorisation should have an end date. A mobile number can be reassigned by the telephone operator to another person: if it remains authorised, that person opens, and the Opening Log will show the name of someone who no longer has anything to do with it.
5. Periodic reconfirmation. Numbers that have not been used for a long time must be reviewed and either reconfirmed or revoked.
6. Corrections. When an authorised person asks for the name or number concerning them to be corrected, the correction is made by the Customer: BGates does not change those fields in the Customer's place and merely forwards the request.

6. Entitlement to administer access to that Entrance

Whoever configures an Entrance represents that they are entitled to do so. Entitlement is not presumed: it depends on the relationship with the place.

6.1 Owner or person entitled

The Customer represents that it is the owner of the Entrance and of the installation, or that it holds from the owner or from the person entitled a valid title to decide who has access to it. This representation is also made at the time the Device is activated and applies for the whole duration of the relationship.

6.2 Condominium

When the Entrance belongs to a condominium, three further rules apply:

1. the condominium decides, in the forms provided for condominium decisions; the administrator acts in execution of those decisions;
2. the Opening Log cannot be consulted by all the condominium owners. Access must be limited to whoever administers, and the Opening Log must not become a list of the neighbours' comings and goings available to anyone living in the building;
3. information must also be given collectively, with a notice posted where the condominium owners will read it, as well as to the individual authorised people.

6.3 Workplaces

If the Entrance gives access to a workplace, the Customer declares it and undertakes the following.

• Prior information to workers. Art. 4(3) of Law no. 300 of 20 May 1970 (Statuto dei lavoratori, Italian Workers' Statute) (as rewritten by Art. 23 of Legislative Decree no. 151 of 14 September 2015) allows the information collected to be used for all purposes connected with the employment relationship only if the worker has been given adequate information on how the tool is used and on how checks are carried out, and in compliance with data protection law. The information is given in advance, in writing and in an understandable form.
• The exemption in paragraph 2 covers installation, not use. Paragraph 2 exempts tools for recording access and attendance from the safeguard procedure, but does not affect paragraph 3.
• And it covers the tool only for as long as it remains such. A system that records who opens and at what time, with prolonged retention, data export and cross-referencing with time slots, may go beyond the recording of access and fall under paragraph 1 of Art. 4, which requires an agreement with the trade union representatives or, failing that, authorisation from the local Labour Inspectorate (Ispettorato territoriale del lavoro). The Customer checks whether that procedure is necessary in its own case and, if it is, completes it before using the Opening Log for purposes connected with the employment relationship.
• No disciplinary use outside the statutory conditions. The Opening Log is not used to bring disciplinary charges outside the conditions laid down by law, nor to reconstruct workers' presence or punctuality.
• Notice at the entrance. A legible notice must be displayed at the Entrance stating that access is recorded, who the Controller is and where the privacy notice can be found.

A clarification that avoids a needless alarm. The location of the Device derived from the mobile cell is not geolocation of workers: the Device is fixed and that data serves network diagnostics. The Customer may ask for it to be disabled by writing to info@bgates.it.

This is how it is designed, and it is not yet live as of 22 September 2026: a switch that turns off the name-based recording of openings on a single Device, leaving only the event.

6.4 Hospitality and short-term rentals

Anyone who uses the Service to give access to paying guests — accommodation facilities, short-term rentals, spaces made available for temporary use — undertakes to:

1. authorise the guest's number only for the period of the stay, with a start and end date;
2. revoke the authorisation on departure, without waiting for the automatic expiry;
3. inform the guest before arrival that their number will become a key and that openings are recorded, giving them the text referred to in § 7;
4. not use the Opening Log to reconstruct guests' habits, times or frequency of use;
5. comply with the obligations specific to the accommodation or rental business it carries on, which these Terms do not replace.

7. Informing the people who are authorised

7.1 The obligation

The people whose numbers are authorised did not give that number to BGates: if anything, they gave it to the Customer. Towards them the Customer is the Controller and must provide the information required by Art. 14 GDPR, at the latest at the time of the first communication to the data subject (Art. 14(3)(b)) and in any case before the number is disclosed to other recipients (point (c)). In the Service, the number is disclosed to the Device and — when the Invite travels on WhatsApp — to the channel provider: the information cannot arrive afterwards.

7.2 BGates provides the text

The Customer does not have to write anything. BGates makes available the document Notice for people authorised to open an entrance (/informativa-utilizzatori), which says who gave the number, who decides, what is recorded when someone opens, for how long, and how to object.

That text is delivered in three ways, automatically:

A Customer who authorises a person without having an Invite delivered to them — for example by writing the number directly into the Device's On-board Number List — must give them the text by its own means, within one month of obtaining the number (Art. 14(3)(a)). In that case BGates does not know that person and cannot inform them in the Customer's place.

7.3 The representation ‘I have informed the person’

Whoever authorises another person's number represents, at the moment they save it: ‘Ho informato la persona e ha accettato di ricevere il messaggio.’ (I have informed the person and they have agreed to receive the message.) This representation is owed under the contract, whatever the way in which the Service collects it.

This is how it is designed, and it is not yet live as of 22 September 2026: before another person's number is saved, the Service will show a warning and ask for the representation ‘Ho informato la persona e ha accettato di ricevere il messaggio’, recording it with the version of the document, the identity of the person making it, the date, the time and the IP address, and producing an entry in the log of administrative actions. Until then the representation is a contractual obligation of the Customer and is not collected by the Service, and the warranty in § 18.1 remains owed under the contract.

Three things must be understood about that representation.

1. It is not consent to the processing of the authorised person's data, and does not become consent.
2. It is a representation by the Customer to BGates: it attests that an obligation of the Customer has been fulfilled and constitutes evidence of that representation, not of the fulfilment.
3. It does not transfer any obligation to BGates and does not release it from any: in particular, it does not affect BGates's liability for the way the system is designed (§ 4.5).

Making a false representation at that point is a breach of these Terms and gives rise to the warranty in § 18.

8. Proper use of QR codes

8.1 The two QR codes for which whoever administers is responsible

The Activation QR code printed on the Device label is a third item: it serves to put the Device into service the first time, does not authorise anyone to open, and is not dealt with here.

8.2 The allocation of responsibilities

BGates is responsible for randomness, revocability, single use, recording of use and what the code reveals — and, where an expiry is stated, for compliance with it. The Customer is responsible for where the QR code is displayed, to whom it is handed and how much time it lets pass before revoking it.

8.3 The obligations of whoever administers

1. A displayed QR code is public by its very purpose. It gets photographed, forwarded, printed. No technical measure prevents this and these Terms do not promise otherwise: a photographed copy is worth as much as the original.
2. The Permanent QR code is put up where it makes sense: at the Entrance being administered, not in places from which the code reaches people who have nothing to do with that access.
3. Single-use QR codes are handed to a specific person: they are not displayed, not circulated and not forwarded to groups. A Single-use QR code has no time-based expiry: it is valid for a single scan, and remains valid until it is used or until it is revoked. For this reason, if the person does not use it, the QR code must be revoked.
4. They are revoked as soon as the reason for which they were generated ceases to exist, from one's own area, without going through support.
5. Requests that come in from the QR code must be examined one by one. The number given is self-declared and not verified: a person can give someone else's number. Approving a request means handing a key to the Entrance to whoever filled in a form.
6. Whoever prints flyers or passes takes a copy outside the Service: printed material must be kept safe and destroyed when it is no longer needed. This is how it is designed: every print will leave a trace in the log of administrative actions.
7. The IP address of whoever fills in the form is recorded by BGates in order to protect a public form from misuse, and erased together with the request. For that data BGates is an independent controller; the Customer does not see it and has no control over it.

As of 22 September 2026 the generation of QR codes for an Entrance is reserved to BGates Operators: the Customer requests it from support. Revocation, on the other hand, is already in the Customer's area.

9. Management and prompt revocation

When a person should no longer get in, their number is revoked the same day. This is the most important obligation in these Terms, and it applies in every case where the relationship that justified access comes to an end: a staff member who leaves the company, a tenant who moves out, a condominium owner who sells, a guest who leaves, a supplier whose contract expires.

In particular:

1. revocation is an act of the Customer, available in its area, and does not require support to intervene;
2. the theft or loss of an authorised phone must be dealt with by immediate revocation, as soon as it becomes known;
3. revocation also takes effect on the Device: the number is removed from the On-board Number List. Until the Device has received the revocation, the entry remains in the Service to allow reconciliation; the period within which the data is then erased is in the Retention Policy;
4. revocation must be checked. After revoking, the Customer checks that the number no longer appears among the Device's Authorised Numbers, and reports any discrepancy to info@bgates.it;
5. on decommissioning, resale or change of owner of the Device the procedure described in the Account Security Rules is carried out: deletion of the configuration and of the On-board Number List, verification that the On-board Number List is empty and a request for erasure of the history.

10. Credentials

1. The Account is personal and non-transferable. Credentials are not shared, not even within the same company or the same condominium: sharing makes it impossible to attribute openings to the person who made them.
2. One person, one Account. Anyone with several staff members who need to administer an Entrance requests an Account for each of them.
3. Whoever creates another person's Account must have informed that person: the privacy notice is attached to the invitation message.
4. The Accounts of people who no longer work for the Customer must be deactivated at the same time as the relationship ends.
5. Credentials are not written in description fields, in notes, or in support messages.
6. Compromises and suspicions are reported without delay to info@bgates.it, with ‘sicurezza’ (security) in the subject line.

This is how it is designed, and it is not yet live as of 22 September 2026: multi-factor authentication and locking of the Account after a defined number of failed attempts. Until they are live, these Terms do not state that access to the Service is protected by a second factor.

11. Device configuration and factory password

1. The Device password must be changed on handover. The Device leaves the factory with a default numeric password, which is the same for everyone and is known. Anyone who knows it and can reach the Device can read and change its configuration and On-board Number List. Changing it is a blocking step of the commissioning test and is the obligation of the Customer or of the Installer handing over the installation.
2. The new password is not shared and is not left in the handover documents.
3. The configuration is checked after every change. The settings for days, time slots, pulse duration and operating mode must be reviewed after every intervention, including those carried out by the Distributor or the Installer.
4. Default settings are not a choice. When the Service proposes a default value — for example authorisation for every day of the week — it is proposing, not deciding: the choice, and responsibility for the choice, remain with whoever configures.
5. Downloading the Device logs and reading the On-board Number List are operations that extract personal data: they are carried out only when needed and leave a trace.

This is how it is designed, and it is not yet live as of 22 September 2026: the obligation, enforced by the Device, to change the password at first power-on, and the removal of the default password from the cover of the manual.

12. Installation, safety of the Entrance and limits of the Service

BGates does not design, manufacture or install the Entrance's automation. The conformity of the automation and of its safety devices remains the responsibility of whoever manufactures it and whoever installs it. The BGates Service sends a command pulse: it does not replace the safety devices of the automation and does not check that they work.

Consequently:

1. bringing the automation into compliance is the responsibility of the Installer and of the manufacturer of the Entrance, to whom the technical standards on motorised gates and doors apply — in particular EN 12453 on the safety in use of power-operated doors and EN 13241 — and, from 20 January 2027, Regulation (EU) 2023/1230 on machinery;
2. the Customer keeps in working order the automation, the safety devices and the periodic maintenance, or entrusts them to whoever holds the contract for them;
3. remote command is not used when the Entrance is not in sight, if the automation is not fitted with the devices that make the manoeuvre safe without the presence of the person giving the command;
4. whoever installs declares to the Customer what they have installed and what they have not installed, in particular the absence of uninterruptible power supplies or safety devices that the Customer might assume to be present.

13. Alternative emergency access

The Service is not a security system or an emergency system. Remote opening requires mobile network coverage, a working SIM and power supply to the installation: none of these three elements is always available.

Whoever administers an Entrance keeps an alternative means of opening it — a key, a remote control, a manual release — and makes sure it is accessible to those who need it. This is not an exemption from liability: it is the description of what the Service does and what it does not do.

If the Service is suspended under § 19, the Entrance can still be opened with the Customer's physical means: suspension concerns remote command, not access to the place.

14. Liability for authorised Users

Whoever authorises a person is liable towards BGates for the consequences of that choice, and in particular:

1. for the use that person makes of the opening granted to them;
2. for failure to revoke when the relationship that justified it has ended;
3. for authorisations granted to persons who are not entitled to access the place;
4. for the instructions given to its own staff, and to the Distributors and Installers that operate on the Entrance on its behalf, who answer to it.

The Customer informs the authorised people of the rules of use that concern them, contained in the Acceptable Use Rules and in the Account Security Rules.

It remains the case that each party is liable for its own acts: the Customer is not liable for what depends on the design, operation or security of the Platform, which remain BGates's responsibility.

15. Opening Log: how long it is kept, and what exporting it involves

How long it is kept. The Opening Log can be consulted with name and number for 12 months from the event. After that, the name is removed and only the last three digits of the number remain: the event remains, the person does not. The technical entry thus reduced is erased at 24 months. The number of anyone who calls without being authorised is masked from the outset on screen and erased in full after 30 days. These are the same periods as in the Retention Policy (/conservazione), which is the single source: the Customer may request shorter periods for its own Entrance, not longer ones.

Export. The Service allows the Opening Log to be exported to a file.

1. The file contains who opened and when. Exporting it means taking personal data outside the Service and outside the security measures that the Service applies.
2. From that moment whoever exported it is responsible: for the safekeeping of the file, for where it is saved, for whom it is sent to, for how long it is kept and for its deletion when it is no longer needed.
3. Export is done for a specific purpose — a dispute, a check, a request from an authority — and not as a convenience copy.
4. The file is not forwarded to anyone who is not entitled to see it. In a condominium, in particular, a list of who entered and when is not posted up, not attached to the minutes and not distributed to the condominium owners.
5. Export leaves a trace in the log of administrative actions: who did it, when, on which Device.
6. The retention periods of the Opening Log within the Service do not apply to the exported copy. Erasing the data in the Service does not delete the file: that is deleted by whoever holds it.

This is how it is designed, and it is not yet live as of 22 September 2026: server-side recording of the export. Today the file is composed by the program running in the browser and the operation leaves no trace.

16. Further obligations of Distributors and Installers

In addition to the above, the Distributor and the Installer:

1. operate only on the Entrances for which they have received a mandate from the Customer and only within the limits of that mandate;
2. do not use for their own purposes the data of Customers and of authorised people to which they have access in the performance of the mandate, including the numbers in the On-board Number List and the Opening Log;
3. hand over to the Customer, at the end of the installation: the changed Device password, the list of authorised numbers entered, a statement of what has been installed and what has not, and the text of the privacy notice to be given to the authorised people;
4. inform the people whose numbers they enter, or make sure that the Customer has done so, and are liable for this towards BGates;
5. do not keep Customers' credentials and do not use a Customer's Account to operate in the Customer's place;
6. report to the Customer and to BGates any configuration that appears excessive or unintended, in particular authorisations with no expiry date;
7. when they process the data of their own commercial customers for their own purposes act as independent controllers and provide those customers with their own privacy notice.

17. What BGates does

So that the obligations of whoever administers are enforceable, BGates undertakes to:

1. make revocation possible in a single action, from the user's own area, without going through support;
2. show whoever administers who used which QR code and when, and which numbers are authorised on each Device;
3. provide and keep up to date the text of the privacy notice to be given to the authorised people, and deliver it automatically in the three ways set out in § 7.2;
4. give the Customer a copy of the data concerning it, including on termination of the relationship, within 15 days of the request — the same period as in Annex A and in the Retention Policy —, except for the data that BGates must keep to comply with legal obligations;
5. record the actions of its Operators on Customers' data — including reading address books, downloading Device logs, exporting the Opening Log, printing QR codes and reading support correspondence — and keep the trace for 24 months;
6. designate in writing the Operators who may access that data, under Art. 2-quaterdecies of the Codice privacy (Italian Data Protection Code, Legislative Decree 196/2003), with a precise list of the operations permitted;
7. assist the Customer with requests from authorised people and with breach notifications, in the ways set out in Annex A;
8. notify the Customer of changes that concern it, in the ways set out in § 20.

These obligations do not give BGates the power to decide who has access to an Entrance: that decision always remains the Customer's.

18. Warranties and indemnity

18.1 What the Customer warrants

The Customer, and anyone who administers an Entrance, warrants to BGates:

1. that it is entitled to administer access to that Entrance (§ 6);
2. that it has informed the people whose numbers it enters, in the ways set out in § 7;
3. that those people agree to receive the Invite message on the number given (§ 4.2, point 4);
4. that it complies with the rules applicable to its own context, in particular those relating to condominiums, employment and accommodation or rental businesses;
5. that the data it enters is accurate and up to date.

18.2 The indemnity, and its limits

The Customer shall indemnify and hold BGates harmless against claims by third parties arising, directly and immediately, from breach of the warranties in § 18.1, and in particular against claims by the person whose number was authorised on the sole ground that they were not informed.

The indemnity has precise limits, which apply even if the parties wished to agree otherwise:

1. it does not cover BGates's own infringements of personal data protection law. The protection of personal data is a matter of public policy, and Art. 1229(2) of the Codice civile (Italian Civil Code) renders void any agreement that limits in advance liability for breach of obligations arising from it;
2. it does not cover the consequences of design defects in the Platform, including the absence of verification of who holds the numbers (§ 4.5);
3. it does not cover wilful misconduct or gross negligence on the part of BGates (Art. 1229(1) of the Italian Civil Code);
4. it does not apply to the extent that the claim arises from an act of BGates or of one of its suppliers;
5. it does not affect the liability that each party has directly towards the data subjects concerned and towards the supervisory authorities, which remains governed by law.

Each party informs the other without delay of any claim received, cooperates in the defence and does not settle the dispute in a way that prejudices the other without the other's written agreement.

18.3 Limitations of liability

BGates's limitations of liability, their scope and the cases in which the law allows none — wilful misconduct, gross negligence, personal injury, mandatory rules, product liability for defective products, mandatory consumer rights — are in the document Limitations of Liability (/responsabilita). They are not repeated here, and nothing in the above extends them.

19. Breaches, suspension and termination

1. Notice and time limit. When BGates detects a breach of these Terms, it gives written notice of it and sets a time limit for remedying it of not less than 15 days, except in the cases in point 3.
2. Proportionality. The response is proportionate to the breach: an excessive configuration is corrected; it does not justify deactivating an Entrance.
3. Immediate suspension. BGates may suspend the Service without notice only where continuing would expose people to a concrete risk or would breach the law: authorisations obtained by false statements about entitlement to administer the Entrance, use of the Opening Log to watch people, compromise of the Account, an order from an authority.
4. What suspension does not do. The notice of suspension states the reason and what is needed to bring it to an end, and reminds the Customer that the Entrance can still be opened with the Customer's physical means (§ 13).
5. Termination. If the breach continues after the time limit in point 1, BGates may terminate the relationship. The Customer's right to obtain a copy of its data (§ 17, point 4) and the erasure obligations in Annex A remain unaffected.
6. Towards a Consumer Customer, suspension always requires the notice in point 1, except in the cases in point 3, and does not deprive the Consumer of the rights that the law grants on a mandatory basis.
7. Termination by BGates of open-ended relationships with business customers: with 30 days' notice, symmetrical to the notice granted to the other party.

20. Duration, changes, governing law and jurisdiction

1. Duration. These Terms apply for as long as the Customer administers at least one Entrance through the Service. Obligations which by their nature survive — confidentiality, warranties, indemnity, the obligations in Annex A on the return and erasure of data — remain in effect after termination.
2. Changes. Changes are notified in the ways set out at the end of this document. When a change adversely affects the use of the Service, a Consumer Customer may terminate free of charge within 30 days of the notification.
3. Governing law. Italian law. Towards a Consumer Customer, the mandatory and more favourable provisions of the law of the country in which the Consumer resides remain unaffected.
4. Jurisdiction. For disputes with business customers, the courts of Milan have exclusive jurisdiction, subject to the specific approval in § 21. For disputes with a Consumer Customer, the court of the place of the Consumer's residence or elected domicile has jurisdiction, and a clause providing for a different court is not binding (Articles 33 and 36 of the Codice del consumo (Italian Consumer Code, Legislative Decree 206/2005)).

21. Clauses requiring specific approval

Some clauses of these Terms are among those that Art. 1341(2) of the Italian Civil Code regards as effective only if specifically approved in writing:

How approval is collected. From business customers, Distributors and Installers, specific approval is collected with a tick box separate from the one with which these Terms are accepted — ‘I specifically approve the clauses…’, with the list above — in the gate of the dashboard and of the app. The two boxes are separate and neither is pre-ticked. The following are kept from the process: the document and its version, the list of clauses approved, the date and time, the IP address and the browser used.

Towards a Consumer Customer these clauses do not apply to the extent that the law regards them as unfair, and specific approval would not make them valid: the table above applies to business customers only.

22. Annex A — Data Processing Agreement

Annex A to these Terms is the document ‘Data Processing Agreement’ (`/dpa`), in the version in force on the date of acceptance. By accepting these Terms, the Customer accepts that Agreement in full, which serves as the contract between Controller and Processor under Art. 28(3) of the GDPR (Regulation (EU) 2016/679). In case of conflict between these Terms and Annex A on matters concerning the processing of personal data, Annex A prevails.

The Agreement governs, in full:

The list of suppliers (/fornitori), with the role, the country and the basis for the transfer outside the European Economic Area of each, forms part of the Agreement by reference. The suppliers that currently process data on BGates's behalf within the scope of these Terms include, among others, netcup GmbH (Germany, hosting), Meta Platforms Ireland Ltd (Ireland, with onward transfers to the United States, delivery of Invites on WhatsApp), Commify Italia S.r.l., Skebby brand (Italy, fallback SMS), Aruba S.p.A. (Italy, email), Stripe Payments Europe, Limited (Ireland and United States, payments) and Vodafone (SIM connectivity).

The Data Processing Agreement in force on the date of acceptance can be consulted at /dpa and bears the same version as these Terms: as of today, 2026.09.22-1. When the Agreement changes, the version of these Terms also changes, and acceptance is requested again in the cases set out below.

If we change these Terms

The Terms change when the Service changes, when a legal obligation changes or when we correct something that was not well written. Each version has a number and a date of entry into force, below. When the change is substantial we notify it by email to those who have an Account and ask for a new acceptance at the next sign-in; when we correct a comma, we do not. Any clauses in § 21 that change require a new specific approval.

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, a clause that concerns you — we tell you by email and ask you to accept the new version the next time you sign in. Corrections of form do not change the version. Previous versions are available on request from info@bgates.it.