Data processing agreement (DPA)

under Article 28 of Regulation (EU) 2016/679 ("GDPR")

Version 1 of [[TO BE DECIDED: effective date]] · PDF of this version

Between

• the Customer, meaning the company, professional, organisation or public body that has accepted the General Terms of the service ("Controller");
• Virtual Solution S.r.l., registered office at Via San Mama 113, 48121 Ravenna (RA), VAT no. IT01480930393, REA RA-162537, share capital € 10.000 i.v., certified email (PEC) virtualsolution@pec.it ("Provider" or "Processor").

Recitals

A. The Provider offers the Customer a subscription email service: mailboxes, calendars, contacts, an AI assistant working on metadata, large files sent as links, an optional legal archive and related services (the "Service").

B. To provide the Service the Provider processes personal data on behalf of the Customer. For this data the Customer is the controller and the Provider is the processor.

C. This Agreement is accepted together with the General Terms and forms part of them. On matters of personal data protection, this Agreement prevails in case of conflict.

D. [[TO BE DECIDED: chain with white-label resellers. Proposal: when the Service is sold by a reseller, the reseller is the processor of its customer and the Provider is the reseller's sub-processor; the same text applies, with the reseller in place of the "Customer", and the reseller imposes an equivalent agreement on its customer]]

E. This Agreement does not apply to a Consumer using the Service for purely personal or household purposes: the customer privacy notice applies to them (Art. 19.4 of the General Terms).

Art. 1 – Definitions

1.1 "Personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "sub-processor" have the meaning given in Art. 4 GDPR.

1.2 "Customer Data": the personal data the Provider processes on behalf of the Customer as part of the Service.

1.3 "Panel": the web administration interface of the Service.

1.4 "Tenant": the Customer's logical space on the platform, separated from those of other customers.

1.5 "Metadata": data about email that is not the message body or attachments: sender, recipients, date, size, subject (in the delivery log; can be turned off per tenant), delivery outcome, SMTP codes, remote hosts, spam verdicts, DNS configuration. It is still personal data.

Art. 2 – Subject matter and duration

2.1 The Provider processes Customer Data only to provide the Service under the contract, in line with this Agreement.

2.2 This Agreement lasts as long as the contract and, after it ends, for as long as the Provider holds Customer Data (Arts. 14 and 15).

Art. 3 – Nature and purpose of processing

3.1 The processing carried out on behalf of the Customer is the following:

3.2 The Provider does not use Customer Data for its own purposes, such as profiling, advertising, sale to third parties or training third-party models.

3.3 [[TO BE DECIDED: use of messages reported as spam or not spam to improve the Provider's spam filter. If this is done, it must be listed here as an authorised purpose, with its limits (local models only, no transfers); otherwise it must be expressly excluded. Until decided: excluded]]

3.4 Click tracking in the Email Delivery module is off by default. If the Customer enables it, the Customer must inform recipients and collect consent where the law requires it.

Art. 4 – Categories of data and data subjects

4.1 Data subjects: users of the Customer's mailboxes (employees, contractors, administrators), their correspondents (external senders and recipients), recipients of Email Delivery messages, people in contacts, calendars and message content, and people who receive file links.

4.2 Data:

• identification and contact data: name, email address, phone number if entered;
• login credentials, stored in protected form (Annex 1);
• content of messages, attachments, events, contacts and files;
• Metadata and delivery logs, including client IP addresses;
• questions and answers in AI assistant conversations;
• usage data: last login, storage used.

4.3 Email and file content may include special categories of data (Art. 9 GDPR) or criminal-offence data (Art. 10). The Provider does not look for them and does not treat them differently from other content. The Customer decides whether processing them through the Service is lawful.

Art. 5 – Customer instructions

5.1 The Provider processes Customer Data only on the Customer's documented instructions, including for transfers to third countries. Instructions are:

• the contract and this Agreement;
• the settings chosen in the Panel: for example retention periods, enabling the legal archive or click tracking, a user's consent to plaintext sending for the AI assistant;
• written requests from the Customer that the Provider has accepted.

5.2 If Union or Member State law requires the Provider to process the data differently, the Provider informs the Customer beforehand, unless the law prohibits this on important grounds of public interest.

5.3 If the Provider considers that an instruction infringes the GDPR or other data protection rules, it tells the Customer immediately and may suspend carrying it out until the Customer confirms or changes it.

Art. 6 – Confidentiality

6.1 The Provider authorises only the people who need it to process the data. These people are bound to confidentiality by contract or by law.

6.2 The Provider's staff access the content of emails or files only:

• at the Customer's request, for support;
• to comply with a legal obligation or an authority's order;
• to handle a security incident or an abuse report.

Every access to content by staff requires a reason and is recorded in the audit log.

Art. 7 – Security measures

7.1 The Provider applies the technical and organisational measures in Annex 1, appropriate to the risk (Art. 32 GDPR).

7.2 The Provider may update the measures without lowering their overall level of protection.

7.3 Some measures depend on the Customer: passwords, enabling the second factor, user management, choice of retention periods in the Panel. They remain the Customer's responsibility.

Art. 8 – Sub-processors

8.1 The Customer gives the Provider a general written authorisation to engage the sub-processors listed in Annex 2. The current list is published at [[TO BE DECIDED: URL, e.g. https://stg.qmail365.com/en/sub-processors/]].

8.2 Before adding or replacing a sub-processor, the Provider notifies the Customer at least [[TO BE DECIDED: 30]] days in advance, at the email address of the Customer's administrator and on the list page.

8.3 Within [[TO BE DECIDED: 15]] days of the notice the Customer may object on reasonable data protection grounds. If the parties do not find a solution, the Provider does not use the new sub-processor for Customer Data, or the Customer may terminate the affected part of the Service without penalty and with a pro-rata refund of fees paid in advance [[TO BE DECIDED]].

8.4 The Provider imposes on every sub-processor, by contract, data protection obligations no less protective than those in this Agreement (Art. 28(4) GDPR).

8.5 The Provider remains liable to the Customer for its sub-processors' failures.

8.6 Functions that use a sub-processor only when enabled are marked as such in Annex 2.

Art. 9 – Assistance with data subject rights

9.1 The Provider helps the Customer, through appropriate technical and organisational measures, respond to data subject requests (Arts. 15–22 GDPR). The Panel and the standard protocols already provide some tools:

• access to and copies of email via IMAP;
• calendars and contacts via CalDAV and CardDAV;
• deletion of mailboxes, messages and files;
• search in the delivery log.

9.2 If a data subject writes directly to the Provider, the Provider forwards the request to the Customer without delay and does not answer it on the merits, unless instructed otherwise.

9.3 [[TO BE DECIDED: assistance beyond the Panel tools, free or charged, and at what rate]]

Art. 10 – Assistance with security, impact assessments and prior consultation

10.1 The Provider gives the Customer the information about the Service that it needs for security of processing (Art. 32), data protection impact assessments (Art. 35) and any prior consultation with the supervisory authority (Art. 36).

Art. 11 – Personal data breaches

11.1 The Provider notifies the Customer of any breach of Customer Data without undue delay, and in any case within [[TO BE DECIDED: 48]] hours of becoming aware of it.

11.2 The notice contains, as far as known at that time, the information listed in Art. 33(3) GDPR: nature of the breach, categories and approximate number of data subjects and records involved; a contact point; likely consequences; measures taken or proposed. Information not yet available is provided later, in phases.

11.3 The Provider takes immediate steps to contain the breach and limit its effects, and keeps records of it.

11.4 Notifying the supervisory authority and informing data subjects is the Customer's task. The Provider assists.

11.5 Notifying a breach is not an admission of liability.

11.6 The Provider's own obligations to report incidents to the CSIRT under NIS2 (Legislative Decree 138/2024) remain unaffected. [[TO BE VERIFIED: NIS2 status and registration on the ACN platform]]

Art. 12 – AI assistant and automated processing

12.1 The AI assistant answers using Metadata. It reads the body of an email only when the user expressly asks it to for that email. Every such reading is recorded in the audit log.

12.2 Permissions are decided by the Service, not by the model. The assistant sees only data the user can already see. The model can propose actions, not carry them out: the user must confirm them.

12.3 Before sending any text to an external model, the Service pseudonymises it: addresses, names, domains, IP addresses and identification numbers (tax code, VAT number, IBAN, phone) are replaced with placeholders; the answer is then put back together. Technical codes stay in clear: SMTP codes, statuses, anti-spam symbols, hosts of well-known providers. Pseudonymised data is still personal data and is treated as such, including for transfers (Art. 13).

12.4 The Service uses only the AI providers listed in Annex 2, with the safeguards stated there. Plaintext sending to an external model happens only if both conditions are met:

• the Provider has enabled that model for plaintext sending;
• the user has given consent in the Service.

Excluded in any case, even for pseudonymised data: the gateway's free routes; providers without an Art. 28 GDPR agreement and, outside the EEA, without a Chapter V GDPR safeguard. [[TO BE DECIDED: exclusion of DeepSeek's original API even for pseudonymised data; today it is the default provider in production, with its DPA "in progress"]]

12.5 If no permitted external provider is available, the assistant does not answer or uses a model running on the Provider's infrastructure [[TO BE VERIFIED: local model available in production]]; it never falls back automatically to a provider outside the EU. The spam filter uses only models running on the Provider's infrastructure.

12.6 Conversations with the assistant are encrypted in the database and deleted 30 days after creation [[TO BUILD: deletion together with the user and per-tenant retention from 7 to 90 days (ADR-0021); today expiry is fixed at 30 days]].

12.7 Every assistant interface states that the user is interacting with an artificial intelligence system (Art. 50 Regulation (EU) 2024/1689).

12.8 [[TO BE DECIDED: whether the Customer can turn off the assistant or external providers for its tenant, leaving only the local model]]

Art. 13 – Transfers outside the European Economic Area

13.1 The Provider stores Customer Data on its own infrastructure in Italy. [[TO BE DECIDED: EU country of the second site for backup copies]]

13.2 Customer Data, including pseudonymised data, leaves the EEA only towards sub-processors in Annex 2 that provide for it, and only with one of these safeguards:

• an adequacy decision (Art. 45 GDPR), including the EU-US Data Privacy Framework for certified entities;
• the standard contractual clauses of Decision (EU) 2021/914, Module 3, together with a transfer impact assessment.

13.3 On request, the Provider gives the Customer the essential information about these safeguards and a copy of the standard clauses, with commercial terms redacted.

Art. 14 – Retention during the Service

14.1 The Customer decides how long to keep the content of mailboxes, calendars, contacts and files: the Provider keeps it until the Customer deletes it. For other data the following periods apply:

14.2 Data deleted by the Customer is no longer visible in the Service. Residual copies remain in backups and previous versions until they expire (table 14.1). Only authorised technical staff can access them, and only for a restore.

14.3 [[TO BE VERIFIED with counsel: traffic data retention obligations (Art. 132 Italian Privacy Code) that might require different periods]]

Art. 15 – Return and deletion at the end of the contract

15.1 The Customer can retrieve its data through standard protocols: email via IMAP; calendars and contacts via CalDAV and CardDAV; active files from the Panel; the legal archive with the signed export.

15.2 After termination, the 30-day transition period and the following retrieval period of at least 30 days in Art. 21.3 of the General Terms apply, during which the data remains accessible at least read-only [[TO BUILD: today the tenant is suspended and access stops at once]].

15.3 When that period ends, or earlier on the Customer's written instruction, the Provider deletes Customer Data in two stages:

• first stage: the tenant is marked for deletion, and for 30 days the deletion can be cancelled;
• second stage: the Provider permanently deletes mailboxes, calendars, contacts, aliases, domains, files and Documents, credentials and users; file encryption keys are destroyed.

[[TO BUILD: today the procedure starts only at the request of a platform operator]]

15.4 Only the following data remains, and only until the expiry stated in Art. 14:

• backups and previous versions;
• the delivery log;
• the legal archive, if enabled: it stays immutable until the end of the period chosen by the Customer and is then deleted automatically [[TO BE DECIDED: early deletion of the archive on the Customer's instruction, e.g. by destroying the keys (existing capability, ADR-0023)]];
• the audit log and billing data, which the Provider keeps for its own obligations.

15.5 On request, the Provider confirms the deletion in writing.

Art. 16 – Information and audits

16.1 The Provider makes available the information needed to show compliance with Art. 28 GDPR: this Agreement, its annexes and answers to reasonable questionnaires.

16.2 The Customer, or an auditor it appoints who is bound to confidentiality, may carry out an audit, including inspections, with at least [[TO BE DECIDED: 30]] days' notice, no more than [[TO BE DECIDED: once a year]] except after a breach or at the request of a supervisory authority. The audit is carried out so as not to compromise the security and confidentiality of other customers. [[TO BE DECIDED: allocation of costs]]

16.3 [[TO BUILD: viewing the tenant's audit log in the Panel (ADR-0044, code not yet in production)]]

Art. 17 – Requests from authorities

17.1 If an authority asks the Provider for access to Customer Data, the Provider checks that the request is lawful, discloses only the data strictly requested and informs the Customer, where the law allows. A request from a non-EU authority not based on an international agreement or a Chapter V GDPR safeguard is refused or challenged.

17.2 [[TO BE VERIFIED: contact point for European production and preservation orders (Regulation (EU) 2023/1543, Legislative Decree 216/2025) and for DSA orders (Arts. 9–11 Regulation (EU) 2022/2065)]]

Art. 18 – Liability

18.1 Each party is liable under Art. 82 GDPR.

18.2 Otherwise, the limitations in the General Terms apply, as specifically approved (Art. 29 of the General Terms). [[TO BE DECIDED: liability cap for breaches of this Agreement]]

Art. 19 – Final provisions

19.1 The Provider may amend this Agreement to bring it in line with the law or the Service, with [[TO BE DECIDED: 30]] days' notice. An amendment that reduces the Customer's protection requires its consent, or gives it the right to terminate without penalty.

19.2 Governing law: Italian. Jurisdiction: as in Art. 27.2 of the General Terms.

19.3 This text is drafted in Italian and English. In case of conflict, the Italian version prevails.

Annex 1 – Technical and organisational measures

1. Separation between customers

• Each customer has a separate tenant.
• Separation is applied directly in the database queries (PostgreSQL and ClickHouse), including counts and statistics, not by filtering results afterwards.
• Automated tests check that one tenant cannot see another tenant's data.

2. Authentication and access

• Identity system run by the Provider on its own infrastructure (Zitadel).
• Customer and reseller administrators: password with a mandatory second factor (TOTP or security key), or a passkey.
• Platform staff: security key or passkey only.
• Identity confirmation (fresh login) before sensitive actions, such as deleting a tenant or changing a subscription.
• Mailbox passwords stored as hashes, never in clear.
• Limits on login attempts and on sending for authenticated sending services.

3. Encryption in transit

• Client access to email only over encrypted connections: IMAPS and POP3S, TLS 1.2 or higher; plaintext ports are disabled.
• Authenticated sending only over an encrypted connection (STARTTLS or implicit TLS).
• Panel and webmail over HTTPS only.
• Encrypted database connections (TLS 1.3).
• Between mail servers: TLS when the remote server supports it (not mandatory towards the Internet); MTA-STS policy published for customer domains.

4. Application-level encryption (AES-256-GCM)

• Quarantined messages.
• DKIM keys.
• AI assistant conversations.
• Migration credentials.
• External provider keys.
• Tax data.
• Large files and Documents: one key per file, itself encrypted with the platform key.
• Legal archive: separate keys per tenant.
• Encrypted backup repository; encrypted backup copies of the delivery log.
• Mailbox, calendar and contact content is not encrypted at application level [[TO BE DECIDED: introduce disk or volume encryption; none found in /infra today]].

5. Pseudonymisation and minimisation

• Pseudonymisation of text sent to external AI models (Art. 12).
• The assistant uses Metadata, not content, unless explicitly asked.
• In operational logs, email addresses, names and IPs appear only as hashes or redacted values; email content never ends up in logs. The delivery log the Customer can consult, by contrast, contains addresses and subject in clear (Art. 14).

6. Control of administrative access

• Access to content only with a reason.
• Audit log of administrative actions.
• Least-privilege access.
• Secrets kept in an encrypted vault or sealed in the database with a key held outside the database and the backups, never in source code.
• Sessions impersonated by resellers have no access to the audit log or to destructive actions.

7. Email security

• Anti-spam (Rspamd) and anti-virus (ClamAV) on messages [[TO BE VERIFIED: anti-virus on all outgoing mail]].
• Encrypted quarantine.
• Anti-virus scanning of large files before public sharing.
• DKIM signing and SPF, DKIM and DMARC checks.

8. Backup and restore

• Daily encrypted, incremental backups (restic): 14 daily, 8 weekly, 12 monthly copies.
• Databases with point-in-time recovery (pgBackRest).
• Backup storage with versioning and object lock for at least 30 days.
• Weekly sample integrity check and automated restore test.
• Alerts on missed or failed backups.
• [[TO BE DECIDED: copy in a second EU site; today data and backups are on the same site]]

9. Legal archive (optional)

• Immutable copy (Object Lock in COMPLIANCE mode) for the period chosen by the Customer.
• Signed daily manifests to verify integrity.
• Signed export.
• It is not legally compliant preservation under the Italian Digital Administration Code (CAD).

10. Infrastructure

• Virtual machines on a Proxmox cluster run by the Provider in Italy.
• Firewall and network anti-spoofing; internal services not exposed to the Internet.
• Software images pinned by digest; configuration declared as code (OpenTofu, Ansible).
• High-availability database (Patroni); replicated delivery log.

11. Monitoring

• Metrics and alerts (Prometheus); logs and error collection on systems run by the Provider.

12. Development and deletion

• Automated tests before each release; security reviews of sensitive areas.
• Two-stage tenant deletion, with destruction of file keys.

13. Organisation

• [[TO BE DECIDED: security officer or DPO, staff training, written incident procedure, any certifications]]

Annex 2 – Sub-processors

A. Sub-processors that process Customer Data

The gateway's free AI routes are excluded for Customer Data.

The AI gateway (OmniRoute), the local model, the identity system, the databases, object storage and monitoring are run by the Provider on its own infrastructure. They are not sub-processors.

B. Providers that are not sub-processors (they process data for the Provider's own purposes, or by direct choice of the Customer or the user)