Data Processing Agreement (DPA)

Appointment as processor under Article 28 GDPR

Language versions. This document is drafted in Italian and is also published in English. The English version is a translation provided for convenience only: in the event of any conflict or doubt as to its interpretation, the Italian version shall prevail.

between

the Client identified in the Account, as Controller (hereinafter, the "Controller")

and

SDL Consulting Group S.r.l., VAT number 05991350876, as Processor (hereinafter, the "Processor")

This agreement forms an integral part of the Terms and Conditions and is deemed signed with them. In the event of conflict on the processing of personal data, this agreement prevails; between the body of the agreement and its annexes, the body prevails.

1. Subject matter and roles#

1.1 In providing the Service the Processor processes personal data on behalf of and on the instructions of the Controller.

1.2 The Controller determines the purposes and means of the processing and warrants that it has a suitable legal basis for the data it puts into the Service, including the data of Signers, and that it has given them the required information. The Controller informs the Processor of the national or sector rules that apply to the data it puts into the Service (for example in the health, pharmaceutical, banking or insurance fields) and that affect the way the Processor processes it.

1.3 The Processor does not determine purposes of its own for the data processed on behalf of the Controller. Should it do so, it would be considered a controller for that processing under art. 28(10) GDPR.

1.4 Details of the processing: Annex I.

2. Instructions#

2.1 The Processor processes the data exclusively on the documented instructions of the Controller. The following are documented instructions: this agreement, the Terms, the technical documentation of the Service and the configurations set by the Controller through the API or the console.

2.2 Where Union or Member State law requires the Processor to carry out further processing, it informs the Controller before proceeding, unless the law prohibits this on important grounds of public interest.

2.3 The Processor immediately informs the Controller if it considers that an instruction infringes the GDPR or other data protection rules.

2.4 Requests from authorities. If a judicial, administrative or supervisory authority asks the Processor to disclose or make accessible data processed on behalf of the Controller, the Processor informs the Controller before acting on the request, so that it may object to or challenge it, unless the law prohibits this; it discloses only the data strictly requested and keeps a record of the request and of the answer.

3. Confidentiality#

The Processor ensures that the persons authorised to process the data have committed themselves to confidentiality or are under an appropriate statutory obligation, and that access is limited to what is necessary.

4. Duration and retention#

4.1 The processing lasts as long as the service contract.

4.2 On termination, and once 30 days have passed during which the Controller may export the data, the Processor deletes it. Within the same period the Controller may ask in writing for the data to be returned rather than only deleted: the return takes place through the Service's export functions, and the deletion follows.

4.2-bis Certification of deletion. At the Controller's request, the Processor certifies in writing, within 14 days of completing the deletion, which data has been deleted and which is kept and why (§ 4.3, § 4.3-ter, legal obligations). The encrypted backup copies leave the backup retention cycle at their natural expiry and are not restored except to restore the Service.

4.2-ter Retention required by law. If a rule requires the Processor to keep data it would otherwise delete, the Processor tells the Controller which data, the rule that requires it and the date by which it will be deleted.

4.3 By way of derogation from the previous point, the evidence of completed signing processes is kept for 10 years from the closing of the matter. That retention meets the need to prove the validity and integrity of the signatures collected for as long as they can be challenged, and constitutes a standing instruction of the Controller given by signing this agreement. Once the period has passed, the Processor deletes the sealed document and the record of events and irreversibly anonymises the personal data of the Signers, keeping only the elements that make it possible to attest the existence and integrity of the document (identifier, level of signature, status, cryptographic fingerprints, dates of completion and closing).

4.3-bis Documents uploaded for signature. The Controller may upload PDF files so that they are signed. The Processor keeps them encrypted and isolated in the Controller's account for 30 days from upload (the Controller may ask for a different period, up to 365 days), and, if they have been signed in a signing process, for as long as they are needed for the evidence of that process, that is for the period of § 4.3. The Processor checks their format and size, not their content.

4.3-ter Inactivity of the account. An account archived for inactivity (24 months) is suspended in all processing; the data remains. After 5 years of archiving, or on request, the account is irreversibly anonymised: the deletion of § 4.2 applies to it, with the sole exceptions of § 4.3 and of the accounting and audit records described in the Terms (art. 7-bis.5). The Controller is notified beforehand, as stated in the Terms. An account with a negative credit balance is not anonymised automatically: it is done only on a recorded decision of the Processor (Terms, art. 7-bis.4).

4.4 Basis of the ten-year period (art. 5(1)(e) GDPR). The period is the time during which a signature may be challenged and the action to enforce it may be brought (the ordinary ten-year limitation period, art. 2946 of the Italian Civil Code): keeping the evidence for a shorter period would deprive the Controller of the ability to defend the validity of an act, and keeping it longer is not necessary. It is a standing instruction of the Controller (§ 4.3). At expiry the personal data is made anonymous. The period is implemented as a parameter and can be changed without structural work.

**4.5 Composition without retention (dataless). The Controller may ask — for a single API call or as a standing setting of its organisation — that a composition leave no trace of the data transmitted. In that case the Processor processes the data in memory for the time strictly necessary to produce the document, returns the document in the response to the same call and keeps neither the input data, nor the document produced, nor the diagnostic messages that would carry the Controller's values. Only the metadata free of personal data needed for invoicing and for the security of the service remains: template and version used, date and time, processing time, number of pages, size in bytes, outcome, and the names of the fields the template required that were not supplied. The document cannot be recovered and cannot be reproduced: the only copy is the one received by the Controller**, who is responsible for any further retention.

The mode does not apply to signing processes: a document started for signature must be kept, and its evidence remains subject to § 4.3. An explicit request for dataless composition together with a signing request is refused, not partly carried out; when the mode derives from the organisation's standing setting, the document is kept, the input data is not, and the response says so expressly.

4.6 The effect of the dataless mode on a request to exercise the data subject's rights (arts. 15-17 GDPR) concerning a document so composed is that the Processor holds no data to provide, rectify or erase. The record of the single processing keeps the fact that that mode was in use: it is the element that makes it possible to prove the circumstance.

4.7 Table of retention periods. Save for different instructions of the Controller within the limits of the Service, the Processor keeps the data processed on its behalf for the following periods; at expiry it deletes them or makes them anonymous with daily automatic procedures. For the data of which the Processor is the controller the Privacy Notice applies.

5. Security#

5.1 The Processor adopts the technical and organisational measures described in Annex II, appropriate under art. 32 GDPR.

5.2 The measures may be updated; changes that reduce the overall level of security are not allowed.

6. Sub-processors#

6.1 The Controller gives general authorisation for the use of sub-processors.

6.2 The up-to-date list, with the service, data, location and safeguards of each, is published at subresponsabili.md; the sub-processors at the date of this version are OVHcloud, Brevo, Openapi and, behind Openapi, Namirial.

6.3 The Processor notifies every addition or replacement with at least 30 days' notice; for the sub-processors of one of its own sub-processors (today those of Openapi and of Namirial, which give us 15 days) the notice is the one the provider grants the Processor, not less than 15 days, and the notice is forwarded on the same day it is received. The Controller may object on reasonable and documented grounds relating to data protection within 15 days; failing agreement, either party may withdraw from the contract without penalty, with a right to a pro-rata refund of what was prepaid and not used.

6.4 The Processor imposes on sub-processors obligations no less onerous than those undertaken here and is liable for their conduct as for its own.

7. Assistance to the Controller#

The Processor assists the Controller, with appropriate technical and organisational measures and within reason:

7.1 in responding to requests to exercise the rights of data subjects (arts. 15-22). If a request reaches the Processor directly, it does not act on it on its own and forwards it without delay to the Controller;

7.2 in the obligations of security, breach notification, impact assessment and prior consultation (arts. 32-36);

7.3 by making available the export and deletion functions of the Service, which cover ordinary requests in general without the need for manual intervention;

7.4 by forwarding to it without delay, and in any case within 5 working days, every request of a data subject, complaint or communication of an authority that concerns the processing carried out on its behalf and that reaches the Processor.

8. Personal data breaches#

8.1 The Processor notifies the Controller of every personal data breach without undue delay and in any case within 48 hours of becoming aware of it.

8.1-bis The Processor becomes aware of a breach also when a sub-processor reports it. It requires sub-processors to inform it without undue delay (at the date of this version, Openapi has undertaken to do so within 48 hours, Brevo and OVHcloud under their respective agreements); the Processor forwards the news to the Controller within the period of § 8.1, which runs from receipt of the report. The 72-hour period of art. 33 GDPR for the Controller runs from when it has been informed.

8.2 The notification contains, to the extent available: the nature of the breach, the categories and approximate number of data subjects and of records, the likely consequences, the measures taken or proposed, and a contact point. Information not immediately available is provided without further delay, in stages.

8.3 Notification to the supervisory authority and to the data subjects is the Controller's responsibility. The Processor does not make it in its place.

8.4 The internal procedure is described in the internal incident management procedure, available on request.

8.5 After a breach the parties coordinate: the Processor cooperates in the Controller's investigation and takes without delay the reasonable measures to contain its effects.

8.6 The Processor does not disclose to third parties a breach concerning the Controller's data without its written consent, unless the law requires it or the disclosure is necessary to contain it (for example to a sub-processor involved).

9. Audit#

9.1 The Processor makes available to the Controller the information necessary to demonstrate compliance with art. 28, including the internal security documentation, available at the Controller's request.

9.2 The Controller may carry out one audit a year, with 30 days' notice, during working hours, without prejudice to the continuity of the Service and to the confidentiality of other clients. Further audits are allowed after a breach or at the reasoned request of an authority. The auditor appointed by the Controller, if a third party, first signs a confidentiality undertaking: they will see an infrastructure shared by all clients.

9.3 The Processor may meet the obligation through certifications or independent audit reports, where available. At the date of this version it holds no certifications under arts. 42-43 GDPR.

9.4 The costs of audits beyond the first in a year are borne by the Controller, unless the audit finds a breach.

10. Transfers outside the EEA#

10.1 The Processor does not transfer personal data outside the European Economic Area, with the sole exception stated in the list of sub-processors: for the qualified electronic seal only, one of Openapi's sub-processors (Mcloud Ltd) is established in the United Kingdom, for which the European Commission's adequacy decision applies (art. 45 GDPR). The sub-processors that process the data of Signers and of documents are established in the EU and the data is processed on infrastructure located in the EU.

10.2 Should another transfer become necessary, or the adequacy decision cease to apply, it will take place only after notice to the Controller under art. 6.3 and on the basis of one of the instruments of Chapter V of the GDPR (standard contractual clauses included).

11. Liability#

11.1 Art. 82 GDPR applies.

11.2 The limitation of liability of the Terms does not apply to the sums due under art. 82 GDPR nor to the administrative penalties arising from breaches attributable to the Processor.

12. Governing law#

Italian law; the court stated in art. 20.2 of the Terms.

13. Contacts#

Annex I — Details of the processing#

Subject matter: provision of a document composition and simple electronic signature service.

Nature and purpose: collection, recording, organisation, storage, processing, consultation, disclosure by transmission, erasure — for the sole purpose of providing the Service according to the Controller's instructions.

Duration: § 4.

Categories of data subjects

Categories of personal data

Special categories (art. 9) and criminal data (art. 10). The Service is neither designed nor intended for processing such data. The Controller refrains from putting them into the Service without having agreed it beforehand in writing: some security measures — in particular the retention periods and the full recording of messages — have not been sized for those categories.

Annex II — Technical and organisational measures#

Under art. 32 GDPR. It describes measures in operation at the date stated, checked against the system and not declared in the abstract. The items describing a periodic activity state the actual frequency.

II.1 Encryption#

• Data at rest: every file stored by the Service (generated documents, sealed documents, uploaded templates) is encrypted with AES-256-GCM with a key managed by the Processor. There is no plaintext read path.
• Key rotation: supported; the outgoing key remains usable for reading during the migration. No cryptographic material passes through the user interface or is kept in the database.
• Data in transit: TLS on every public connection, with HSTS. Certificates renewed automatically.
• Backups: encrypted with AES-256 before leaving the server.

II.2 Access control#

• User authentication with passwords kept exclusively in hashed form; session cookies with the Secure, HttpOnly, SameSite attributes.
• A second factor is mandatory for every access to the console: a one-time code sent to the account's email address or, at the user's choice, an authenticator app (TOTP, RFC 6238), which can also be set up from a QR code, with one-time recovery codes. The platform administration accounts always use a password and an emailed code. The shared secret is encrypted at rest with the same key as the storage: a TOTP secret in plaintext in a dump would be every account's second factor, which is worse than having none, because one would believe it present. A code already used is refused, and the clock tolerance is a single step.
• API keys kept as hashes with a dedicated pepper: they cannot be recovered, only revoked.
• Authorisation based on roles and capabilities, on the principle of least privilege.
• Isolation between clients applied at the level of data queries. Every attempt to access another client's data receives a 404 and not a 403 response, so as not to reveal even the existence of the data.
• Administrative access to the server by cryptographic key; password authentication disabled.

II.3 Infrastructure security#

• The application service runs in containers without root privileges, with all system capabilities removed and with acquiring new ones forbidden. The application, the proxy and the database run with a read-only system file system.
• The document converters run in a separate service, with no network access and with no secret in their environment nor access to the file storage: they receive each document from the application over a local channel, with limits on time, CPU and file size. A document that tried to make something be downloaded reaches nothing.
• Perimeter firewall; automatic blocking of repeated access attempts.
• Public exposure limited to the reverse proxy.
• Every dependency is pinned to an exact version, transitive ones included.

II.4 Content supplied by the client#

• Templates run in a restricted execution environment; the composition engine cannot access the network or the filesystem.
• A size limit on uploads and refusal of compressed archives that exceed thresholds of expansion, of compression ratio or of number of entries, and of those that contain paths leaving their own folder.
• The URLs supplied by the client for outgoing notifications are checked before being contacted: only https, only publicly routable addresses, no following of redirects.

II.5 Integrity of the signing evidence#

• Append-only recording of the events of each signing process.
• SHA-256 fingerprint of the sealed document, publicly verifiable by recomputing it on an uploaded file.
• A certificate of completion attached to the document, stating for each signer the verification method actually applied.
• Export of the whole evidence file in a single archive.

II.6 Availability and recovery#

• Daily encrypted backup, transferred to object storage in a different country from the server's, kept for 30 days; early deletion is prevented by an object lock (Object Lock, governance mode).
• The backup includes the database, the file storage and the secrets needed to make them readable: a restore without the latter would produce a service unable to read its own data.
• The procedure checks the decryption and the integrity of the archive before transmission: a backup that does not open is a belief, not a copy.
• Restore actually carried out and verified by comparing the table counts with production. Objectives and limits in the internal business continuity plan, available on request.

II.7 Minimisation and deletion#

• Automatic deletion of generated documents once the retention period has passed, carried out by scheduled and verifiable processes.
• Composition mode without retention (§ 4.5): on request, per call or per organisation, the data transmitted is not written to any storage — nor is the document produced. The writing is suppressed at the source, not deleted afterwards, and is verified by a test that inspects the whole database schema in search of the data transmitted.
• Deletion and anonymisation of the signing evidence under § 4.3.
• The export and deletion functions are exposed to the Controller.

II.8 Organisation and governance#

• Log of architectural decisions and of incidents, kept continuously, documenting every relevant change and every anomalous event with its analysis.
• Risk register and periodic review: internal risk register, available on request.
• Incident management procedure with defined times: internal incident management procedure, available on request.
• Asset inventory: internal asset inventory, available on request.
• A suite of automated tests run before every release to production.
• An automatic check of the configuration requirements before every release.

II.9 Measures not yet adopted#

Listing them is unusual in a contractual annex. They are here because a client who discovers them on its own concludes that the previous list is just as optimistic, while it is not.

Date of the last review of Annex II: 2026-11-02. To be reviewed at least annually and at every substantial change of the architecture.

Annex III — What remains of a processing#

For every document composed the Processor records one operational row. The table says what it contains, in the ordinary mode and in composition without retention (§ 4.5). It applies to composition; signing processes follow § 4.3. In the ordinary mode, once 365 days have passed the data transmitted, the warnings, the text of the error messages and the options of the request are deleted together with the document: from then on the row keeps only the elements that in the right-hand column remain even without retention, and the fingerprint of the data.

No HTTP header, no cookie and no session token is recorded in the operational row. The web server logs keep the IP address and the request for 365 days, as stated in the Privacy Notice.

Shared responsibilities#

The protection of the data also depends on what remains in the Controller's hands:

• the API keys: they cannot be recovered by the Processor; an exposed key must be revoked from the console;
• the choice of the mode without retention, per call or for the whole organisation: the Controller decides it, and the only copy of the document is then its own;
• the console users and their roles, and the safekeeping of their authentication factors;
• the data it puts in: the Service is not intended for special categories of data (Annex I) without a written agreement.