Data processing agreement (Article 28).

The Parties

SANFYTECH, a simplified joint-stock company (société par actions simplifiée, SAS) with share capital of 5,000.00 euros, whose registered office is at 173 rue de Courcelles, 75017 Paris, registered with the Paris Trade and Companies Register (registre du commerce et des sociétés, RCS) under number 107 365 249 (SIRET 107 365 249 00013, intra-Community VAT number FR81107365249), represented by Cédric SANTIAGO in his capacity as President, duly authorised for the purposes hereof, hereinafter “SANFYTECH”, the “Provider” or the “Processor”,

of the one part,

and the legal or natural person that has accepted this Agreement under the conditions of Article 4.1, hereinafter the “Client” or the “Controller”, whose identity, representative and contact details are those specified in the Main Contract,

of the other part,

hereinafter referred to individually as a “Party” and collectively as the “Parties”.

Preamble

The “Main Contract” means the quote, purchase order, framework agreement or dedicated contract entered into between the Parties which incorporates this Agreement by reference.

Its performance leads the Provider to process, on behalf of the Client, personal data whose purposes and means the Client determines. Article 28.3 of Regulation (EU) 2016/679 of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data requires that this relationship be governed by a written legal act that is binding on the processor with regard to the controller.

This agreement, hereinafter the “Agreement”, meets that requirement. Article 28.3 requires a written and enforceable legal act; it prescribes neither its form, nor a separate signature, nor physical delivery. The Agreement is accordingly published, versioned and incorporated by reference into the Main Contract, of which it forms an inseparable part, and it prevails over the Main Contract in all matters relating to the processing of personal data.

The Client declares that it is acting for purposes falling within the scope of its professional activity. It acknowledges that it was given the opportunity, before entering into any commitment, to read the version of this Agreement specified in the Main Contract, including the description of the technical and organisational measures in Annex 2 and the statement of limits in A2.20, as well as the list of sub-processors in Annex 3. This acknowledgement neither limits nor excludes the duty to inform under Article 1112-1 of the French Civil Code.

The Controller acknowledges that the descriptions in the annexes to this Agreement, and in particular the statement of limits in A2.20, describe the actual state of the Processor’s arrangements as at the date of the version concerned and prevail over any commercial presentation, brochure, page of the Provider’s website or pre-contractual exchange, none of which has contractual value. Under this Agreement, the Processor gives no quantified availability commitment, no continuous on-call support, no permanent human monitoring and no exclusively French location of the Data, the primary backup copy being located in Germany under the conditions of A1.2.

Now, therefore, it has been agreed as follows.

Article 1. Definitions

The following terms, when capitalised, have the meanings set out below in this Agreement, in both the singular and the plural. Terms defined in Article 4 of the GDPR and not listed below have the meaning given to them in that text.

1.1 “GDPR”: Regulation (EU) 2016/679 of 27 April 2016.

1.1 bis “Applicable Regulations”: the GDPR, Law no. 78-17 of 6 January 1978 on information technology, data files and civil liberties (loi Informatique et Libertés), the texts adopted for their implementation and the guidelines, recommendations and decisions of the Supervisory Authority.

1.2 “Data”: the personal data processed by the Processor on behalf of the Controller under the Main Contract, as described in Annex 1, excluding the data that the Processor processes on its own account.

1.3 “Processing”: the operations described in Annex 1, carried out by the Processor on behalf of the Controller.

1.4 “Data Subjects”: the natural persons to whom the Data relates, as categorised in Annex 1.

1.5 “Documented Instructions”: the Controller’s instructions relating to the Processing, consisting of the Main Contract, this Agreement and its annexes, and any additional instruction given in the manner set out in Article 6.

1.6 “Sub-processor”: any third party to which the Processor entrusts the performance of specific processing activities on behalf of the Controller, within the meaning of Articles 28.2 and 28.4 of the GDPR. Those authorised as at the date of this version are listed in Annex 3.

1.7 “Data Breach”: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Data transmitted, stored or otherwise processed, within the meaning of Article 4.12 of the GDPR.

1.8 “Security Measures”: the technical and organisational measures implemented by the Processor under Article 32 of the GDPR, described in Annex 2.

1.9 “Supervisory Authority”: the CNIL (Commission nationale de l’informatique et des libertés, the French data protection authority) or any other competent authority within the meaning of Article 51 of the GDPR.

1.10 “Terms of Sale”: the Provider’s general terms of sale (conditions générales de vente, CGV), in the version and as at the date identified in the Main Contract, published at https://www.sanfytech.com/legal/cgv. They are not attached to this Agreement and do not constitute any of the three annexes referred to in 3.1. The version binding on the Parties is the one that the Main Contract identifies by its title, version number and date, to the exclusion of any other, including any version subsequently posted at the same address. The Provider keeps a frozen copy and delivers it to the Client on simple request, on paper or on a durable medium. Any reference in this Agreement to a provision of the Terms of Sale is to be understood as a reference to that version.

1.11 “Standard Contractual Clauses”: the clauses adopted by Commission Implementing Decision (EU) 2021/914 of 4 June 2021, in the module applicable to the relationship concerned.

1.12 “Working Day”: any day other than a Saturday, a Sunday or a public holiday in France.

Article 2. Purpose and roles of the Parties

2.1 Purpose. The Agreement sets out the conditions under which the Processor carries out, on behalf of the Controller, the operations described in Article 5, and the respective obligations of the Parties under the GDPR. It does not alter the subject matter, scope or price of the services agreed in the Main Contract, and creates no processing obligation beyond what the Main Contract provides for.

2.2 Roles of the Parties. The Client acts as Controller within the meaning of Article 4.7 of the GDPR and SANFYTECH as Processor within the meaning of Article 4.8. The Client alone remains competent to determine the purposes and means of the processing, the categories of Data collected, the business retention periods, the recipients, the information given to Data Subjects and the responses to their requests to exercise their rights.

2.3 Scope of access. The Processor determines neither the fields collected by the Client’s forms, applications and interfaces, nor the recipients of the Data, nor the business retention periods. It accesses application content only to the extent strictly necessary for an operational task, the resolution of an incident or the execution of a Documented Instruction; such access is traced under the conditions and subject to the reservations described in Annex 2.

2.4 The Processor’s own processing. By way of exception to 2.3, the Processor acts as controller for the technical and security logging of its own infrastructure base, on the basis of its legitimate interest in ensuring the security of networks and information systems within the meaning of Recital 49 of the GDPR and of the obligation in Article 32, and for the management of its business relationship, invoicing and accounting, which it accounts for in its privacy policy published at https://www.sanfytech.com/legal/confidentialite. Logs produced on the systems operated on behalf of the Controller in performance of Article 32 of the GDPR continue to be processed in the capacity of Processor, under the conditions of A2.9 of Annex 2. Where the Main Contract so provides, the Processor deploys on the Controller’s services a self-hosted audience measurement tool, which it operates as Processor, on documented instructions and exclusively on behalf of the Controller, which remains in control of the purpose, the activation of the measurement and its configuration. The statistics produced belong to the Controller, are not cross-referenced with the data of any other site or with any other processing, are not transmitted to any third party and are accessible to the Controller alone, to the exclusion of any other publisher, segregation by site being implemented technically. The Processor makes available to the Controller a configuration meeting the conditions of the consent exemption recognised for audience measurement, provides it with the details in writing and documents it; any configuration request departing from it is handled and recorded as a Documented Instruction. This measurement uses no cookies and involves no access to information stored in the user’s terminal equipment; it truncates the connection address, honours the browser’s opt-out signal and purges raw logs after thirteen (13) months. It is for the Controller to assess, in the light of Article 82 of Law no. 78-17 of 6 January 1978 and the guidelines of the Supervisory Authority, whether the chosen configuration qualifies for the consent exemption, and to mention this in its own privacy policy. Should the Processor determine the purposes and means of an entrusted processing operation, it would be considered a controller in respect of that processing within the meaning of Article 28.10 of the GDPR.

2.5 Point of contact. SANFYTECH is not required to appoint a data protection officer within the meaning of Article 37 of the GDPR, as the conditions of that provision are not met as at the date of this version. It appoints a single point of contact for data protection matters, reachable at rgpd@sanfytech.com, an address dedicated to data protection requests, checked on Working Days and competent for any request falling under this Agreement.

Article 3. Contractual documents and order of precedence

3.1 The Agreement consists of this main body and its three annexes, which form an integral part of it and are published with it: Annex 1, location of the data, documented instructions and points of contact; Annex 2, technical and organisational security measures; Annex 3, list of authorised sub-processors. The elements required by Article 28.3 of the GDPR are defined in Article 5.

3.2 In the event of conflict between the documents binding the Parties, the order of precedence, in decreasing order, is as follows: this Agreement, for any matter relating to personal data; the Main Contract and its annexes; the accepted quote or purchase order; the Terms of Sale. The Client acknowledges that it has read the Terms of Sale in the version in force on the date of signature of the Main Contract.

3.3 In the event of conflict between the main body of the Agreement and one of its annexes, the main body prevails, except for the technical description of the Security Measures and for the list of sub-processors, for which Annexes 2 and 3 are authoritative. The document “Annex. Technical and organisational security measures” reproduces the text of Annex 2 verbatim when it is attached to the Main Contract; it may neither reduce nor extend its scope.

3.4 The provisions of the Main Contract and of the Terms of Sale relating to confidentiality, liability, force majeure, notices and electronic evidence apply to this Agreement, subject to the adaptations it contains. However, reliance on force majeure releases the Processor neither from the notification provided for in Article 14, nor from implementing the Security Measures to the extent that the event allows, nor from the return or destruction of the Data provided for in Article 17. In accordance with Article 28.4 of the GDPR, the failure of a Sub-processor does not release the Processor from its liability to the Controller, regardless of the provisions of the Main Contract or of the Terms of Sale relating to force majeure. Any time limit for bringing proceedings shortened by the Terms of Sale does not apply to actions based on this Agreement, which are governed by 19.7.

Article 4. Term, entry into force and revision

4.1 Acceptance and entry into force. The Agreement is accepted by the signature of the Main Contract that incorporates it by reference, which entails unreserved acceptance of the version it specifies. It takes effect on the effective date of the Main Contract and remains in force throughout its term, and thereafter for as long as the Processor retains Data on behalf of the Controller. No separate signature is required; a Controller that so wishes may nevertheless ask the Processor for an initialled copy of the version in force, which is provided free of charge.

4.1 bis Binding version. The version binding on the Parties is the one that the Main Contract specifies by its number and date; failing such specification, the one published at https://www.sanfytech.com/legal/dpa on the date of signature of the Main Contract. The publication of a later version has no effect on Main Contracts in progress: it applies only to commitments entered into after it, or after written acceptance by the Controller. The Processor keeps a frozen copy of each published version and supplies a copy on simple request.

4.2 Termination of the Main Contract, for whatever reason, entails termination of the Agreement, subject to the survival of the provisions relating to confidentiality, the fate of the Data, documentation, audits and liability, which remain applicable until fully performed.

4.3 The Agreement is reviewed at least once a year, and upon each structural change in architecture, provider, risk level, scope of the Processing or regulatory framework. Any amendment to the main body of the Agreement gives rise to the publication of a new version, bearing its number and date. In accordance with 4.1 bis, such publication does not in itself have any effect on a Main Contract in progress: the new version becomes applicable to it only by written amendment or by written acceptance by the Controller.

4.4 By way of exception, updates to Annex 3 follow the prior information procedure of Article 10 and do not require an amendment if no objection is raised within the time allowed. Updates to Annex 2 resulting from the strengthening of a security measure take effect automatically; the Processor reports on them at the annual review.

4.5 Processing prior to entry into force. This Agreement governs the Processing from its effective date, including Processing that began earlier, which becomes subject to it going forward. It cancels and replaces, from that date, any annex, note or compliance document previously provided by the Processor to the Controller describing the chain of sub-processing: the chain binding between the Parties is exclusively the one in Annex 3. This lapse concerns only the descriptive value of those documents; it entails neither their destruction, which the Processor undertakes not to carry out, nor any waiver by the Controller of the rights it holds in respect of the earlier period, and it has no effect on documents drawn up by the Controller itself. This Agreement imposes no obligation on the Processor in respect of any period prior to its registration on 15 July 2026.

Article 5. Description of the processing

5.1 Standing description. The Processor’s services cover a constant scope: custom software development, consulting, integration of artificial intelligence systems, hosting, managed services and keeping systems in working order. The elements that Article 28.3 of the GDPR requires to be defined are accordingly set once and for all as follows, and apply to any Main Contract that incorporates this Agreement:

5.2 Specific features of the engagement. The Main Contract may supplement or set aside a row of the table in 5.1 for the engagement it governs, in particular where the Processing concerns special categories of data, data relating to the residents or users of a public service, health data, or where a specific business retention period is agreed. What it states then prevails over the standing description, for that engagement only. Where nothing is stated, the standing description applies in full.

5.3 Accuracy. The Controller, which alone determines the purposes and means, guarantees the accuracy of the description with regard to the Processing it entrusts. It informs the Processor, without undue delay, of any change affecting it, in particular the introduction of a new category of Data or Data Subjects, and especially of a special category within the meaning of Articles 9 and 10 of the GDPR. The Processor may not rely on the standing description to refuse to take such information into account.

5.4 Periods. The Processor processes the Data only for the period necessary for the performance of the Main Contract and in accordance with the business retention periods set by the Controller. The technical periods specific to the Processor’s operating base, in particular those for logs and backup sets, are described in Annex 2; they do not constitute retention periods for business data.

5.5 Location. The location of the Data is described in A1.2 of Annex 1.

Article 6. Documented instructions

6.1 The Processor processes the Data only on documented instructions from the Controller, including with regard to transfers to a third country or an international organisation, unless required to do so by Union law or French law to which it is subject. In such a case, it informs the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

6.2 The Main Contract, this Agreement and its annexes constitute the Controller’s initial Documented Instructions.

6.3 Any additional instruction is sent in writing to the Processor’s point of contact, an e-mail to rgpd@sanfytech.com constituting writing. It states its subject, the processing concerned and its desired effective date. The Processor acknowledges receipt within five (5) Working Days and indicates, within the same period, whether its execution is technically possible within the framework of the Main Contract and whether it entails additional work or costs. An instruction exceeding the scope of the Main Contract gives rise to a prior quote.

6.4 The Processor immediately informs the Controller if, in its opinion, an instruction infringes the Applicable Regulations or another provision of Union or Member State data protection law. It may suspend execution of the disputed instruction until it is confirmed, amended or withdrawn in writing, without such suspension giving rise to any liability on its part.

6.5 The Processor keeps a written record of the Documented Instructions received and executed for the term of the Agreement plus five (5) years, and makes it available on request.

Article 7. Obligations of the Processor under Article 28.3

The Processor accepts the obligations of Article 28.3 of the GDPR, the conditions for performance of which are set as follows: documented instructions, Article 6; confidentiality of authorised persons, Article 8; security of processing, Article 9 and Annex 2; sub-processing, Article 10; assistance with the exercise of Data Subjects’ rights, Article 12; assistance with security, breaches and impact assessments, Articles 13 and 14; fate of the Data at the end of the service, Article 17; documentation and audits, Article 15.

Article 8. Personnel and confidentiality

8.1 The Processor restricts access to the Data to those persons who need it for the performance of the Main Contract, on a need-to-know basis, and undertakes to extend the principle of least privilege throughout under the conditions and according to the timetable set out in Annex 2.

8.2 The Processor undertakes that any natural person likely to access the Data, whether an officer, employee, agent or external contributor, enters into a written confidentiality obligation before their access is opened, which survives the end of their collaboration. It declares that all persons authorised as at the date of this version have entered into that written undertaking, which it evidences on request. That undertaking includes a reminder of the rule in Article 29 of the GDPR. The list of authorised persons is provided to the Controller on written request.

8.3 The Processor informs the persons whose administrative activity is logged and recorded of the existence, purposes and retention period of such processing. The confidentiality obligation in this article is in addition to, and does not replace, the provisions of the Main Contract and the Terms of Sale relating to confidentiality and trade secrets.

8.4 In accordance with Articles 29 and 32.4 of the GDPR, the Processor ensures that any natural person acting under its authority who has access to the Data does not process it except on instructions from the Controller, unless required to do so by Union or Member State law. The confidentiality undertaking entered into pursuant to 8.2 includes a reminder of this rule.

Article 9. Security of processing

9.1 The Processor implements the Security Measures, which are appropriate to ensure a level of security appropriate to the risk within the meaning of Article 32 of the GDPR, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the Processing, and the risks to the rights and freedoms of Data Subjects.

9.2 These measures are described in Annex 2, which presents them in their actual state as at the date of this version; measures that are not in place are declared as such in A2.20.

9.3 The Processor’s obligations in respect of the Security Measures are enhanced best-efforts obligations (obligations de moyens renforcées). The Processor guarantees neither the absence of vulnerabilities, nor the invulnerability of the systems, nor the impossibility of unauthorised access. It informs the Controller, without undue delay and at the latest within five (5) Working Days, of any adverse change in a measure described in Annex 2, specifying the measure concerned, the cause of the change, the compensating measure put in place and the date by which the described state will be restored. Where that change substantially affects the level of security of the Processing, the Controller may, within thirty (30) days of being so informed, raise a reasoned objection under the conditions of 10.3 and, failing agreement, terminate the service concerned without compensation on either side. No update to Annex 2 may reduce the level of the Security Measures without a written amendment signed by both Parties.

9.4 Truthfulness of statements. Every security statement made by the Processor under this Agreement, or in response to a supplier questionnaire from the Controller, is supported by a dated item of evidence that it keeps and provides on first request. In the absence of such evidence, it declares the actual state of the measure and the date by which it will be implemented. The Processor holds no security certification, qualification or accreditation issued by a third-party body; assessments of its security posture are tool-assisted self-assessments, a summary of which may be provided under the conditions of Article 15.

9.5 Where the Main Contract concerns the provision of infrastructure resources that the Controller administers itself, security responsibilities are allocated as follows, unless the Main Contract provides more precisely. The Processor is responsible for: the hardware, the virtualisation layer, the network and the power supply; filtering at the virtualisation layer and at the upstream operator level; backup of the complete machine image; notifying the Controller, without undue delay and at the latest on the Working Day following its detection, of any incident detected at the infrastructure level, without prejudice to the time limit in Article 14.1 where that incident constitutes a Data Breach. The Controller is responsible for: the guest operating system, its patches and its kernel; the hosting control panel, accounts, sites and databases; the machine’s local firewall and application exposure; application restoration and data consistency; notifying the Processor, without undue delay and at the latest on the Working Day following its detection, of any incident detected inside the machine. The Processor gives no detection commitment inside the guest operating system and has no knowledge of the categories of Data processed there; such Data is nevertheless included in the encrypted backup images that it keeps. Any change to the filtering implemented by the Processor that is likely to affect the availability of one of the Controller’s services requires the Controller’s prior written consent.

Article 10. Sub-processing

10.1 General authorisation. The Controller authorises the Processor, by a general written authorisation within the meaning of Article 28.2 of the GDPR, to engage the Sub-processors listed in Annex 3, which specifies for each its identity, the activity entrusted, the categories of Data concerned, the country of processing and, in the case of a transfer outside the European Union, the applicable appropriate safeguard.

10.2 Prior information. The Processor informs the Controller in writing, at the address given in Annex 1, of any intended addition or replacement of a Sub-processor, as soon as possible after becoming aware of it and, in any event, at least ten (10) days before it is implemented. The information specifies the identity of the new Sub-processor, the activity entrusted, the categories of Data concerned, the country of processing and the applicable transfer safeguard. The Parties agree that this period corresponds to the shortest notice that the Processor itself obtains from its own suppliers: it cannot commit to longer notice than it receives.

10.3 Right to object. The Controller has ten (10) days from such information to raise in writing a reasoned objection based on data protection considerations. If no objection is raised within that period, the change is implemented and Annex 3 is updated; such absence of objection constitutes neither a waiver of the right to challenge the use of that Sub-processor subsequently nor acceptance of a reduction in the level of protection of the Data. In the event of an objection, the Parties consult in good faith to seek an alternative arrangement, in particular keeping the existing Sub-processor, additional measures or excluding the Data from the entrusted scope. If the disagreement persists, the Controller may terminate the service concerned, without charge or compensation on either side, subject only to payment for the services performed.

10.4 Urgency. In the event of the failure, security breach or cessation of business of a Sub-processor making it impossible to observe the notice period, the Processor may replace it with a provider offering at least equivalent guarantees and informs the Controller without delay, and at the latest within seventy-two (72) hours, giving reasons for the urgency. The right to object is then exercised after the event under the conditions of 10.3.

10.5 Flow-down obligations. The Processor imposes by contract on each Sub-processor the same data protection obligations as those set out in this Agreement, in accordance with Article 28.4 of the GDPR, in particular processing on documented instructions, the written confidentiality undertaking of authorised persons, the security measures of Article 32 of the GDPR, notification of breaches without undue delay, assistance with the exercise of rights, control of its own sub-processing, keeping the record required by Article 30.2 of the GDPR, informing the Processor when an instruction appears to it to infringe the Applicable Regulations, and the return or destruction of the data at the end of its service with a written certificate. The Processor keeps a written record of these undertakings and provides it to the Controller on written request.

10.5 bis Sub-processors’ agreements. The Processor entrusts Processing to a Sub-processor only after having entered into with it, or accepted from it, the processing agreement provided for in Article 28.4 of the GDPR, of which it keeps a dated copy. It provides the reference and date of that agreement to the Controller on simple written request.

10.6 Liability and maintenance of the list. The Processor remains fully liable to the Controller for the performance by its Sub-processors of their obligations, in accordance with Article 28.4 of the GDPR. It keeps Annex 3 up to date, provides the version in force on simple request, and reports any change in the location of the data or in the chain of sub-processing announced by one of its suppliers.

10.7 Services subscribed to by the Controller. Services that the Controller subscribes to directly from third parties, in particular a payment platform, a domain name service, a payment collection platform, a social network or a distribution service, are not Sub-processors of the Processor. They are the sole responsibility of the Controller and are identified as such in Annex 3 where they form part of the technical chain.

Article 11. Transfers outside the European Union

11.1 Principle. The Data processed for hosting and backup purposes is hosted and stored exclusively within the territory of the European Union, according to the distribution set out in Annex 1. No transfer of this Data to a third country or an international organisation takes place as a result of hosting or backup. Services ancillary to operations which involve a transfer outside the European Union are exhaustively listed in Annex 3 and governed by 11.2 to 11.6; they concern only the categories of Data designated in that annex.

11.2 Exhaustively listed transfers. The only transfers to a third country are those listed in Annex 3, which specifies for each the Sub-processor concerned, the activity entrusted, the categories of Data transferred, the country of destination and the appropriate safeguard applicable within the meaning of Chapter V of the GDPR.

11.3 Legal basis. Each transfer is governed, in order of priority: by an adequacy decision of the European Commission within the meaning of Article 45 of the GDPR where the country of destination benefits from one and the recipient falls within its scope; failing that, by the Standard Contractual Clauses within the meaning of Article 46.2(c) of the GDPR, entered into between the Processor and the recipient; in all cases, supplemented by the additional measures necessary to ensure a level of protection essentially equivalent to that ensured within the Union, in particular minimisation of the data transmitted, pseudonymisation where practicable, encryption of communications and strict restriction of access.

For each of the transfers listed in Annex 3, the Processor keeps the applicable appropriate safeguard and provides it to the Controller on written request. It informs the Controller without undue delay of any transfer for which the safeguard can no longer be established and, in such a case, applies 11.5.

11.4 Condition for implementation. No transfer to a third country is implemented or continued until the appropriate safeguard applicable within the meaning of Chapter V of the GDPR has been entered into and archived by the Processor. Failing this, the Processor suspends the flow concerned and informs the Controller. On written request, the Processor describes the additional minimisation, pseudonymisation and encryption measures that it applies to the transfer concerned.

11.5 Invalidation of a mechanism. In the event of the invalidation, suspension or substantial modification of one of the mechanisms referred to in 11.3 by the Court of Justice of the European Union, the European Commission or the Supervisory Authority, the Parties implement without undue delay, and at the latest within sixty (60) days of the decision taking effect, the available replacement mechanism. In the absence of a mechanism ensuring an essentially equivalent level of protection, the Processor suspends the transfer and informs the Controller without delay, which decides either on additional measures or on termination of the service concerned under the conditions of 10.3.

11.6 Requests from third-country authorities and prohibitions. The Processor informs the Controller, to the extent permitted by applicable law, of any binding request for access to the Data from a public authority of a third country, and pursues the remedies reasonably available. It cannot guarantee the absence of any such request with regard to a provider subject to foreign law, in particular under Chapter 121 of Title 18 of the United States Code. It undertakes not to transfer to any Sub-processor, whatever its country of establishment, the Controller’s authentication credentials or cryptographic secrets, and restricts permissions so as to make such transmission technically impossible. It also undertakes not to implement a transfer to a third country not listed in Annex 3 without the prior information provided for in Article 10.

Article 12. Assistance with the exercise of data subjects’ rights

12.1 Taking into account the nature of the Processing, the Processor assists the Controller by appropriate technical and organisational measures, insofar as this is possible, in responding to requests to exercise the rights of access, rectification, erasure, restriction, objection and portability, and to requests relating to automated individual decision-making and post-mortem directives.

12.2 Any request addressed directly to the Processor by a person presenting themselves as a Data Subject is forwarded to the Controller without undue delay and at the latest within three (3) Working Days, without the Processor responding to it itself, unless otherwise instructed in writing. The Controller alone remains competent to assess the admissibility of the request and to respond to it.

12.3 On written request and in the manner agreed in A1.5 of Annex 1, the Processor makes available the extraction, rectification and deletion means at its disposal on the systems it operates on behalf of the Controller, within a reasonable time having regard to the nature of the request. It does not guarantee that every instance of a data item will be located in technical and security logs or in backup sets, whose structure does not allow item-by-item searching; the interaction between erasure and backups is governed by Article 17.

12.4 Routine assistance, consisting of forwarding a request, producing a standard export or carrying out a deletion, a restriction or giving effect to an objection by means of existing functions, is included in the price of the service. In-depth assistance, in particular the development of a specific export function or the manual extraction of data from a system not designed for that purpose, is subject to a prior quote, at the daily rate agreed in the Main Contract. Where the Controller states in writing that failure to act is likely to cause it to miss the time limit in Article 12.3 of the GDPR and confirms its order, the Processor carries out the necessary work without waiting for formal acceptance of the quote, up to a limit of two (2) working days, and then invoices it at the daily rate agreed in the Main Contract; it informs the Controller in writing no later than the day the work is carried out.

Article 13. Impact assessment and prior consultation

13.1 Taking into account the nature of the Processing and the information available to it, the Processor assists the Controller in carrying out the data protection impact assessments provided for in Article 35 of the GDPR and, where applicable, in conducting the prior consultation of the Supervisory Authority provided for in Article 36.

13.2 This assistance consists of providing a description of the operations it carries out, a description of the Security Measures in place and of the planned measures with their timetable, the list of Sub-processors and transfers, a description of the data flows and the technical retention periods. It does not include drafting the impact assessment, which is the Controller’s responsibility; such drafting, like the production of detailed documentation for an external auditor or participation in risk analysis workshops, is subject to a prior quote, at the daily rate agreed in the Main Contract.

13.3 The Processor informs the Controller when it identifies, in the entrusted Processing, a characteristic likely to make an impact assessment mandatory under the guidelines of the Supervisory Authority, in particular large-scale processing of sensitive data, the evaluation or scoring of individuals, or the systematic monitoring of a publicly accessible area.

Article 14. Notification of data breaches

14.1 Time limit. The Processor notifies the Controller of any Data Breach affecting the processing carried out on its behalf without undue delay and at the latest forty-eight (48) hours, non-working days included, from the time it becomes aware of it, in accordance with Article 33.2 of the GDPR. This period is counted in calendar hours and is not suspended by a Saturday, a Sunday or a public holiday: it is stipulated so that the Controller retains a useful part of the seventy-two (72) hour period that Article 33.1 of the GDPR allows it to notify the Breach to the supervisory authority. Becoming aware means the moment at which the Processor acquires a reasonable degree of certainty that a security incident has compromised Data. Where an incident is likely to constitute a Data Breach but that degree of certainty has not yet been reached, the Processor informs the Controller on a preliminary basis within the same period, expressly describing the information as preliminary, and carries out the necessary checks without delay.

14.2 Scope of the commitment. This period runs from actual awareness. It does not constitute a commitment to continuous detection: security events are handled by a person on Working Days, automated detection remaining active outside those hours and events being recorded for handling when work resumes. The Processor gives no commitment to on-call support, standby cover or continuous human monitoring. The Processor’s ability to become aware relies on the detection arrangements described in A2.9 of Annex 2.

14.3 Content. The notification is sent by e-mail to the Controller’s point of contact given in Annex 1, with a request for acknowledgement of receipt, and contains, to the extent of the information known at that date:

• the nature of the Data Breach, and the date and time of its occurrence and of the Processor becoming aware of it, expressed in Coordinated Universal Time;
• the categories and approximate number of Data Subjects concerned, and the categories and approximate number of records concerned;
• the likely consequences of the Data Breach;
• the measures taken or proposed to address it and, where appropriate, to mitigate its possible adverse effects;
• the name and contact details of the Processor’s point of contact.

The entry “unknown at this stage” is accepted for any item not yet established; it does not justify delaying the notification. Where the information cannot be provided all at once, it is provided in phases, without undue delay, as it is established. A late notification is accompanied by the reasons for the delay, in accordance with Article 33.1 of the GDPR.

14.4 Preservation of evidence. As soon as it becomes aware of an incident likely to constitute a Data Breach, the Processor opens a time-stamped incident log, freezes the evidence available to it and excludes backup sets prior to the incident from automatic purging. It refrains from deleting any message, log or file documenting the event.

14.5 Competence of the Controller. The Controller alone remains competent to assess the risk within the meaning of Articles 33 and 34 of the GDPR and to decide on notification to the Supervisory Authority and on informing Data Subjects. The Processor makes no notification and provides no information in its place. It assists the Controller in fulfilling those obligations, in particular by making available the technical information, the time-stamped chronology and the log extracts actually available to it on the date of the request.

14.6 Lessons learned and register. Within fifteen (15) days of the closure of the Data Breach, the Processor sends the Controller a written lessons-learned report setting out the chronology, the identified cause, the corrective measures undertaken and their timetable. It documents every Data Breach in a register comprising the facts, their effects and the measures taken, in accordance with Article 33.5 of the GDPR; the records are kept for five (5) years from closure and the extracts concerning the Controller are provided to it on request.

14.7 Reciprocal alert. The Controller notifies the Processor, within the same period as in 14.1 from its becoming aware, of any security incident within its own scope that is likely to affect the entrusted systems or Data. It undertakes to preserve the evidence of any incident occurring within its scope.

Article 15. Documentation, audits and inspections

15.1 Making information available. The Processor makes available to the Controller the documentation necessary to demonstrate compliance with Article 28 of the GDPR, in particular the extract from the record of categories of processing activities concerning it, the description of the Security Measures, the up-to-date list of Sub-processors and the safeguards governing the transfers listed in Annex 3.

15.2 Documentary audit. Once per calendar year, on thirty (30) days’ written notice, the Controller may request the evidence associated with the commitments in Annex 2. The Processor responds within thirty (30) days of receipt of the request. This frequency limit does not apply where the request is necessary to enable the Controller to demonstrate compliance with its own obligations, in particular in connection with a Data Breach or an inspection by the Supervisory Authority.

15.3 On-site audit. The Controller may have an audit or inspection of the measures implemented carried out, by itself or by an independent third-party auditor it appoints, subject to all of the following conditions: thirty (30) days’ written notice, save in an emergency justified by a proven security incident; one audit per calendar year outside incidents; performance during the Processor’s Working Days and business hours; scope limited to the systems and processing concerning the Controller; a third-party auditor who is not a competitor of the Processor and is bound by a written confidentiality undertaking. An additional audit may be conducted following a Data Breach affecting the Controller.

15.4 Enforceable limits. The Processor may set against an audit request the measures necessary to protect the data of its other clients, the security of its infrastructure and its trade secrets. It discloses no information enabling its other clients to be identified, no authentication secrets, no internal technical addresses and no document whose disclosure would increase the attack surface of its information system. It then proposes an alternative means of effective verification, in particular the production of certificates, anonymised time-stamped records or a verification during a session without any document being handed over. It may not rely on these limits to deny the Controller any means of verifying the performance of an obligation entered into under this Agreement.

15.5 Costs and follow-up. Audit costs are borne by the Controller. The Processor contributes to each audit free of charge up to one (1) working day; time spent beyond that is invoiced at the daily rate agreed in the Main Contract, on the basis of a previously accepted quote, provided that such invoicing may not deprive of effect the right that the Controller derives from Article 28(3)(h) of the GDPR. By way of exception, where the audit reveals a substantial failure by the Processor, the corresponding costs are borne by the Processor, which bears the cost of the remediation work and provides a dated action plan within thirty (30) days. The audit report is provided to the Processor, which has thirty (30) days to submit its observations; it is covered by the confidentiality obligation and may not be passed on to any third party, except to the Supervisory Authority or in compliance with a court decision.

Article 16. Record of categories of processing activities

16.1 The Processor keeps a written record of the categories of processing activities carried out on behalf of the Controller, in accordance with Article 30.2 of the GDPR, containing the name and contact details of the Processor and of each controller on behalf of which it acts, the categories of processing carried out, transfers to a third country with identification of the appropriate safeguards, and a general description of the security measures of Article 32. This record has been drawn up and populated as at the date of this version.

16.2 The extract from the record concerning the Controller is provided to it on written request, within thirty (30) days of receipt of the request, and to the Supervisory Authority on request, in accordance with Article 30.4 of the GDPR. The record is updated at least once a year and whenever there is a change in the scope of the Processing, the chain of sub-processing or the location of the Data.

Article 17. Fate of the data at the end of the service

17.1 Controller’s choice. At the end of the service, for whatever reason, the Controller notifies the Processor in writing, within thirty (30) days of the effective date of the end of the Main Contract, of its choice between the return of all the Data in the formats described in 17.2 or its destruction. If no notification is given within that period, the Processor sends the Controller a written reminder, by registered letter with acknowledgement of receipt, inviting it to make its choice and expressly warning it that, failing a reply, the Data will be destroyed; if that reminder remains unanswered for thirty (30) days from its first presentation, the Processor proceeds with the destruction and informs the Controller under the conditions of 17.5. Until that period expires, the Data remains stored and protected by the measures in Annex 2, without any processing other than its technical storage.

17.2 Return. The Data is returned in usable formats, described below; the Processor does not guarantee that all of these formats are standardised open formats. Return takes place within thirty (30) days of receipt of the instruction, or within fifteen (15) days where the Main Contract expressly so stipulates. It covers application data, delivered in the form of database exports reviewed and checked before delivery, files and documents delivered in their original format in a readable folder structure, and the configuration elements necessary to redeploy the service, excluding elements specific to the Processor’s infrastructure, its operating secrets and its internal tools. A complete virtual machine image may be delivered on express request and subject to technical feasibility; produced in the format of the Processor’s backup software, it requires a compatible environment in order to be used. Delivery takes place through a secure channel agreed between the Parties and gives rise to a record of return.

17.3 Destruction in the active database. The Data is destroyed in the active database and on production systems within thirty (30) days of, as the case may be, acceptance of the record of return or receipt of the destruction instruction.

17.4 Backups. Backup sets are neither modified nor extracted from, since altering a backup destroys its integrity and evidential value. Data remaining in them disappears through automatic purging, when the retention period in force expires, which may not exceed twelve (12) months from destruction in the active database. During that interval, such Data is not subject to any processing other than its technical storage and remains protected by the measures in Annex 2. If a restoration takes place within that interval, the destruction is immediately reapplied after restoration.

17.5 Certificate. The Processor provides a dated certificate of destruction, specifying the scope concerned, the date of erasure from the active database, the expiry date of the last backup containing the Data and the means used.

17.6 Retention required by law. By way of exception, the Processor retains Data whose retention is required of it by Union law or French law, in particular accounting records within the meaning of Article L123-22 of the French Commercial Code, only for the prescribed period and solely for the purpose of complying with that obligation; it informs the Controller, specifying the category of data, the legal basis and the period.

17.7 Reversibility assistance. The return provided for in 17.2 is carried out free of charge up to the assistance allowance provided for in the Main Contract or, failing any such provision, four (4) hours of work. Beyond that, any migration assistance is invoiced at the daily rate agreed in the Main Contract, on the basis of a quote provided within five (5) working days of the request and accepted. Operational reversibility arrangements exceeding this return are governed by the Main Contract; failing any such provision, they are those provided for in the Terms of Sale in respect of reversibility and include in particular the handover of the access rights, administration accounts, domain names and certificates needed for continuity that are held on behalf of the Controller. This paragraph does not reduce any reversibility obligation entered into in the Main Contract or the Terms of Sale.

17.8 Continuity of return. The Processor keeps up to date operating documentation enabling the service to be taken over by a competent third party. It designates a standby contributor by means of a delegation of powers granted by a written and dated decision of the Processor’s President. That decision defines the scope of the delegation (access to the relevant environments only, protective measures and communication with the Controller, limited to what is necessary to maintain and return the Data and configurations) and its activation conditions, namely the Processor’s incapacity or unavailability exceeding thirty (30) days. Since it emanates from the company and not from the person of its President, the delegation survives the latter’s incapacity. The Controller is informed of it and the decision is provided to it on written request. The Processor delivers to the Controller, on written request, the emergency access means enabling the Data to be recovered, in a sealed envelope or by deposit in a safe whose release does not depend solely on the Processor’s will. In the event of the Processor’s actual cessation of business, the incapacity of the natural person responsible for operations or the lasting unavailability of its resources, the return provided for in 17.2 is carried out without delay; failing this, the Controller may have it carried out by the standby contributor. The opening of insolvency proceedings in respect of a Party neither terminates this Agreement automatically nor accelerates any obligation, and does not in itself constitute a triggering event within the meaning of this paragraph; the powers of the administrator and the liquidator to require the continuation of contracts in progress are reserved, without prejudice to the obligation to delete or return the Data. The designation of this contributor, the adoption of the decision delegating these powers to them and the making of the deposit have been completed as at the date of this version.

Article 18. Obligations of the Controller

18.1 The Controller undertakes to have, for each processing operation entrusted, a valid legal basis within the meaning of Article 6 of the GDPR and, where applicable, an exception within the meaning of Article 9.2, to comply with the Applicable Regulations for all processing whose purposes and means it determines, and to provide evidence of this on request.

18.2 It informs Data Subjects in accordance with Articles 12 to 14 of the GDPR, collects and manages consents where they are required, and responds to requests to exercise rights addressed to it.

18.3 It documents in writing any instruction relating to the Processing, in the manner set out in Article 6, and guarantees the lawfulness of its instructions.

18.4 It designates in Annex 1 a data protection point of contact who is reachable throughout the term of the Agreement and informs the Processor of any change without undue delay. If no contact is reachable, notifications sent to the address given in Annex 1 are deemed validly delivered.

18.5 It transmits to the Processor, and places on the systems operated by the Processor, only the Data necessary for the performance of the Main Contract. In particular, it undertakes not to place production data in a development, test or demonstration environment, test data sets having to be synthetic or anonymised. As a counterpart to this obligation, the Processor undertakes not to keep a copy of Data on its administration workstation beyond the time strictly necessary for the operation in progress.

18.6 It ensures the security of the access rights it holds on the systems operated by the Processor, the management and revocation of the permissions it grants to its own staff and service providers, and the security of the equipment from which it connects.

18.7 It informs the Processor when it is subject to specific sectoral obligations, in particular under Directive (EU) 2022/2555 or Regulation (EU) 2022/2554, so that the Parties can agree on the cooperation arrangements and time limits enabling it to comply with its own notification obligations. Having regard to the size criteria in Article 2 of Directive (EU) 2022/2555 and to the state of French law as at the date of this version, that directive not yet having been transposed, the Processor does not qualify as an essential or important entity on that basis. It informs the Controller, without undue delay, of any change in that qualification resulting from the transposing law, an implementing act or a change in its own situation.

18.8 It remains fully responsible, vis-à-vis Data Subjects and the Supervisory Authority, for the compliance of the processing whose purposes and means it determines.

18.9 Special data. This paragraph applies where the Main Contract states, pursuant to 5.2, that the Processing concerns special categories of data within the meaning of Articles 9 and 10 of the GDPR. The Controller then guarantees that it has an exception within the meaning of Article 9.2 of the GDPR or, in the case of data relating to criminal convictions and offences, the basis required by Article 10. The Parties agree on the following enhanced measures: named restriction of the Processor’s access, enhanced logging of consultations, pseudonymisation of extracts used for diagnostic purposes and exclusion of such data from the operations assistance tools mentioned in Annex 3. The Controller is expressly informed that this exclusion relies on a usage rule and not on a technical restriction, the assistance tool’s technical account having extended rights over the Processor’s base. Accordingly, the Processor undertakes not to use that tool on systems holding the data referred to in this paragraph and carries out the corresponding diagnostics without it. The Controller is further informed that encryption of the storage volumes of production systems is not implemented as at the date of this version, under the conditions of A2.2 and point 1 of A2.20 of Annex 2. Processing of special categories of data is commenced only after encryption at rest of the volume holding them has been implemented or, failing that, after the express written consent of the Controller expressly mentioning this limit and the compensating measures adopted.

Article 19. Liability and allocation of damage

19.1 Each Party is liable for the damage caused by processing where it has not complied with the obligations of the GDPR incumbent on it specifically, or where it has acted outside or contrary to the Documented Instructions, in accordance with Article 82.2 of the GDPR.

19.2 Where both Parties are involved in the same processing and are responsible for damage caused by it, the final burden of compensation is allocated between them in proportion to each Party’s share of responsibility, in accordance with Article 82.5 of the GDPR. The Party that has paid full compensation for the damage has a right of recourse against the other to the extent of that share. This article does not prevent Data Subjects from obtaining full compensation for their loss from either Party, in accordance with Article 82.4 of the GDPR.

19.3 Cap. As between the Parties, the Processor’s financial liability under this Agreement and the Main Contract, for all causes combined, is limited to the cap stipulated in the Main Contract or, failing a specific provision, in the Provider’s general terms of sale in the version incorporated into that contract. The Parties expressly agree that there is only one cap between them, that of the Main Contract, and that this Agreement does not create a second one. This cap is single and global: it covers all claims made under this Agreement and the Main Contract relating to the same triggering event, without aggregation, and applies in particular to damage resulting from a breach of the Security Measures, of the obligations in Article 32 of the GDPR or of the Documented Instructions, including in respect of the recourse provided for in 19.2. The Parties expressly acknowledge that this cap, having regard to the nature of the services, the price level charged, the limits declared in A2.20 of Annex 2 and the allocation of risks they intended, preserves the substance of the essential security obligation within the meaning of Article 1170 of the French Civil Code and creates no significant imbalance within the meaning of Article 1171 of the same code.

19.4 Exceptions. This cap does not apply in the event of fraud, gross negligence, personal injury or wilful breach of confidentiality, in respect of the warranty against eviction under the intellectual property clause of the Main Contract, or in cases where the law prohibits limitation. Administrative fines imposed under Article 83 of the GDPR are personal in nature: they remain the exclusive responsibility of the Party penalised and give rise to no indemnification or recourse between the Parties. The recourse provided for in 19.2 concerns only compensation for damage caused to Data Subjects within the meaning of Article 82 of the GDPR and is exercised within the limit of the cap in 19.3.

19.5 Indirect and non-material damage is excluded, in particular loss of turnover, margin, clientele or reputation, loss of profit and loss of data that the Controller has not backed up on its side where backup is not covered by the Main Contract. By way of exception, this exclusion applies neither to compensation for damage, including non-material damage, suffered by a Data Subject under Article 82 of the GDPR, nor to the recourse between the Parties organised in 19.2, which are exercised within the limit of the cap in 19.3.

19.6 The Processor declares that it holds a valid professional liability insurance policy taken out with Hiscox SA, French branch (49 avenue de l’Opéra, 75002 Paris, RCS Paris 833 546 989), covering hosting and managed services activities and including cover for the financial consequences of cyber events and administrative penalties under the conditions of the policy. It maintains this cover throughout the term of the Agreement and provides evidence of it on written request by producing an up-to-date certificate stating the activities covered, the amounts of cover and the period of validity. The activities and territorial scope actually covered are those stated in that certificate; under this Agreement, the Processor makes no statement on the extent of its cover other than what results from it and gives no direct indemnification undertaking in favour of the Controller. Taking out this insurance does not extend the caps in Article 19.

19.7 Limitation period. By way of derogation from any contrary provision of the Main Contract or of the Terms of Sale, and pursuant to Article 2254 of the French Civil Code, actions based on this Agreement, including the recourse provided for in 19.2, are time-barred after three (3) years from the day on which the Party bringing the action knew or ought to have known the facts enabling it to bring its action. This period has no effect on the rights that Data Subjects derive from Article 82 of the GDPR, or on mandatory limitation periods.

Article 20. General provisions

20.1 Notices. Unless otherwise stipulated, the notices provided for in this Agreement are validly given by e-mail sent to the points of contact given in Annex 1, with a request for acknowledgement of receipt. Those relating to termination, formal notice or an objection within the meaning of Article 10 are confirmed by registered letter with acknowledgement of receipt.

20.2 Evidence. E-mails, technical logs, recordings of administration sessions and timestamps produced by the Processor’s systems are binding as evidence between the Parties, in accordance with Articles 1366 and 1367 of the French Civil Code, unless proven otherwise. This evidence agreement, made pursuant to Article 1356 of the French Civil Code, operates for the benefit of both Parties: the Controller may rely on the same items against the Processor and, on written request made in the context of a dispute, the Processor provides it with the extracts of logs, session recordings and timestamps relating to the disputed facts, within the limits and according to the alternative arrangements of 15.4. An electronic signature compliant with Regulation (EU) No 910/2014 is accepted for the signature of this Agreement.

20.3 Partial invalidity and no waiver. If any provision is declared void or unenforceable, the others will remain in full force and effect and the Parties will negotiate in good faith a replacement provision of equivalent effect. A Party’s failure to rely on a breach by the other does not constitute a waiver of the right to rely on it subsequently.

20.4 Assignment and language. The Agreement follows the fate of the Main Contract and may not be assigned independently of it. It is drafted in French, which is the only version authoritative between the Parties.

Article 21. Governing law and jurisdiction

21.1 This Agreement is governed by French law and by the Applicable Regulations.

21.2 Prior amicable resolution. In the event of a dispute concerning the formation, interpretation, performance or termination of this Agreement, the first Party to act refers the matter to the other in writing, setting out the subject of the dispute and the proposed resolution. The Parties endeavour in good faith to reach a negotiated settlement. The amicable attempt is deemed closed on the expiry of a period of thirty (30) days from that written referral, unless extended by written agreement. It does not prevent recourse to the judge hearing urgent applications (juge des référés), the taking of protective or evidential measures, an order for payment procedure, or the exercise by a Data Subject of the rights it derives from Articles 77 to 79 of the GDPR.

21.3 The Parties do not agree on any jurisdiction clause: failing amicable resolution under the conditions of 21.2, the dispute is brought before the competent court in accordance with the ordinary rules of law. Where the Controller is a legal person governed by public law and the Main Contract falls under the French Public Procurement Code (Code de la commande publique), disputes fall within the jurisdiction of the administrative courts, such contracts being administrative contracts pursuant to Article L6 of that code.

21.4 The provisions of this article are without prejudice to the competence of the Supervisory Authority, the right of Data Subjects to lodge a complaint with a supervisory authority within the meaning of Article 77 of the GDPR and their right to an effective judicial remedy within the meaning of Articles 78 and 79 of the same regulation.

Published by SANFYTECH, represented by Cédric SANTIAGO, President. The Provider keeps a frozen copy of each published version and supplies a copy to the Controller, on paper or on a durable medium, on simple request.

Annex 1. Location, documented instructions and points of contact

This annex is referred to in Articles 5 and 6 of the Agreement. It is published with the Agreement and is not issued in the name of a specific party: the elements of Article 28.3 of the GDPR are set in Article 5, and what is specific to an engagement is set out in the Main Contract, under the conditions of 5.2.

A1.2 Location of the data

The applicable arrangements are as follows: backups are encrypted at source before transfer; the primary copy is kept in the European Union (Germany) and a mirror copy is kept in France. The Controller acknowledges that it has been informed that the primary backup copy is located in Germany and not in France, and undertakes to pass this information on in its own privacy policy where it mentions the location of the hosting. Any change in the location of any of these sites is notified with thirty (30) days’ notice.

A1.3 Initial documented instructions

The Controller gives the Processor the following standing instructions, which supplement those resulting from the main body of the Agreement and the Main Contract.

1. Host, run, back up and restore the Data within the framework of the services described in the Main Contract, and make no other use of it.
2. Access application content only for an operational task, the resolution of an incident, the execution of a written instruction or a legal obligation, and trace that access.
3. Apply the business retention periods set by the Controller and not modify them on its own initiative.
4. Carry out no transfer of Data outside the European Union other than those listed in Annex 3.
5. Transmit to an operations assistance tool no Data beyond what the diagnosis of the incident being handled makes strictly necessary, and no authentication secrets.
6. Not use the Data to train, fine-tune or evaluate a machine learning model, and obtain from the providers of its tools an undertaking that the content submitted is not used for that purpose.
7. Forward to the Controller, within three (3) Working Days, any request to exercise rights received directly, without responding to it.
8. Notify any Data Breach under the conditions of Article 14.

A1.4 Data protection points of contact

A1.5 Arrangements for assistance with the exercise of rights

Technical and security logs and backup sets do not allow item-by-item searching; their fate is governed by Article 17. Any operation exceeding the means above falls within the in-depth assistance of Article 12.4.

Annex 2. Technical and organisational measures

This annex is referred to in Article 9 of the Agreement. It describes the measures implemented under Article 32 of the GDPR in their actual state as at the date of this version. It describes these measures both at the level of the commitments enforceable by the Controller and in their technical detail. Measures that are not in place are declared as such in A2.20.

A2.1 Purpose, definitions and scope

A2.1.1 Purpose. This annex describes the technical and organisational measures implemented by SANFYTECH, hereinafter the “Provider”, to ensure a level of security appropriate to the risk, pursuant to Article 32 of Regulation (EU) 2016/679. It constitutes the description of the measures within the meaning of Article 28(3)(c) of the same regulation. It describes these measures in their actual state as at the date of signature: measures that are not in place are declared as such in the body of each article and, in summary form, in A2.20.

A2.1.2 Definitions. “Contract”: as the case may be, the data processing agreement entered into pursuant to Article 28 of Regulation (EU) 2016/679, hereinafter the “DPA”, the hosting contract, the managed services contract or any other contract to which this annex is attached. “Client”: the Provider’s contracting party, the controller. “Data”: the personal data processed by the Provider on behalf of the Client. “Hosted Systems”: the servers, virtual machines, containers and services operated by the Provider for the provision of the service. “Delegated Zone”: the systems for which the Provider supplies the infrastructure, the virtualisation layer and network filtering, but whose guest system, accounts and applications the Client administers itself. “Bastion”: the gateway through which the Provider authenticates, authorises and records human administration sessions. “Front End”: the single entry point providing encrypted termination and publication of the Hosted Systems placed on a private network. “Working Day”: any day other than a Saturday, a Sunday or a public holiday in France. Where this annex is attached to the DPA, the “Provider” means the Processor and the “Client” means the Controller within the meaning of that document.

A2.1.3 Nature of the obligation. The Provider’s security obligations are enhanced best-efforts obligations. The Provider guarantees neither the absence of vulnerabilities in the software components it operates, nor the invulnerability of the Hosted Systems, nor the impossibility of unauthorised access. This annex creates no liability regime distinct from that of the Contract: compensation for a breach of any of the measures it describes is governed by the liability provisions of the Contract and, for the Data, by those of the DPA, including as regards the agreed cap, its single and global nature and the exceptions that apply to it. In accordance with Article 1170 of the French Civil Code, none of these provisions may deprive the Provider’s essential security obligation of its substance.

A2.1.4 Truthfulness and changes. Every security statement made by the Provider, including in response to a supplier questionnaire, is supported by a dated item of evidence that it provides on first request; failing that, it declares the actual state of the measure. It informs the Client in writing of any adverse change in a measure described below, without undue delay where that change creates an immediate risk to the security of the Client’s Data, indicating the replacement measure implemented in the meantime. The Provider holds no security certification or qualification and does not claim any.

A2.1.5 Scope and revision. This annex constitutes Annex 2 of the DPA; the document “Annex. Technical and organisational security measures” reproduces its text verbatim when it is attached to another contract, without being able to reduce its scope. In the event of conflict with the main body of the DPA, the latter prevails; in the event of divergence from its other annexes, the provision most favourable to the Client prevails. In the absence of a DPA, this annex is interpreted in accordance with the contract to which it is attached and, on a supplementary basis, with the Provider’s general terms of sale available at https://www.sanfytech.com/legal/cgv. The Provider may not rely on the absence of a DPA to deny the Client the exercise of the rights granted to it by Article 28(3) of Regulation (EU) 2016/679. This annex creates no availability commitment and no guarantee of response or restoration time: any such commitments appear only in the special conditions of the contract and in the service levels annex. It is updated before each signature to which it is attached and upon each structural change in architecture, provider or risk level.

A2.2 Governance, organisation and derogations

A2.2.1 Organisation. The Provider is a small organisation whose operations rely on a limited number of contributors; the number of authorised natural persons is structurally limited. It has not appointed a data protection officer, as none of the conditions of Article 37(1) of Regulation (EU) 2016/679 is met: it is neither a public authority nor a public body, and its core activities consist neither of regular and systematic monitoring of data subjects on a large scale, nor of large-scale processing of data referred to in Articles 9 and 10 of the same regulation. It designates a single point of contact for security and data protection matters, reachable at rgpd@sanfytech.com. Declared gaps: no segregation of duties, no dual approval, no independent internal audit function.

A2.2.2 No certification or external audit. The Provider holds no security certification, qualification or accreditation issued by a third-party body. Assessments of its security posture are tool-assisted self-assessments; they constitute neither an independent audit, nor a penetration test, nor an accreditation. Declared gap: no independent audit and no external penetration test has been carried out.

A2.2.3 Regulatory position. As at the date of this annex, Directive (EU) 2022/2555 has not been transposed into French law. Having regard to the size criteria in its Article 2, the Provider does not fall within the scope of essential or important entities and does not fall within the categories that the directive covers irrespective of their size either. It informs the Client of any change in its status as a regulated entity within thirty (30) days of the entry into force of the transposing text or of the change in its situation. It is fully subject to Regulation (EU) 2016/679 as a processor.

A2.2.4 Derogations. Any derogation from the measures described is written, reasoned, accompanied by a compensating measure, dated, and bears a review date no later than twelve (12) months ahead; if that date passes without review, the derogation lapses and the measure becomes fully applicable again. The register of derogations is provided to the Client on written request.

A2.3 Access control and permission management

A2.3.1 Permissions. Access rights to the Hosted Systems are granted according to the principles of need to know and least privilege. Each client’s environments are segregated in roles specific to them, with no visibility of other clients’ environments or of the Provider’s infrastructure base, this exclusivity being checked target by target and documented; it concerns permissions and not network flows between guests. Technical backup and virtualisation accounts are confined to a least-privilege role, with no right to modify configuration.

A2.3.2 Access lifecycle. Any departure or change of role results in the closure of the corresponding access rights on all of the Provider’s identity systems.

A2.3.3 Attribution. Human access is individually named up to the Bastion, which records the session; attribution of actions relies on that recording. Declared gaps: a shared system administration account remains on some of the systems, compensated by exclusive key-based authentication, session recording and an alert on use of the emergency access; human administration accounts have extended rights over the base operated by the Provider, the principle of least privilege not being applied to them across the board.

A2.4 Authentication

A2.4.1 Technical access. Access to the Hosted Systems takes place exclusively over an encrypted protocol, with authentication by ed25519 cryptographic key, password authentication being refused by the configuration of all the administered servers within the Client’s scope, deployed automatically from a single file. The set of algorithms is consistent across the fleet and includes a hybrid key exchange resistant to quantum analysis. The Provider does not use text messages, voice calls or secret questions as an authentication factor under any circumstances.

A2.4.2 Multi-factor authentication. Declared gap: none of the Provider’s administration systems enforces a second factor. The compensation adopted is exclusive authentication by cryptographic key, origin restriction on the Bastion and session recording.

A2.4.3 Passwords. The Provider’s policy sets the following minimum lengths: fifteen (15) characters for base accounts, fourteen (14) for service accounts, twelve (12) for an unprivileged account, twenty-four (24) random characters for a non-memorised secret and a passphrase of at least seven (7) words for protecting a private key.

A2.4.4 Applications developed for the Client. The Provider requires end users’ passwords to be stored as a hash produced by a memory-hard key derivation function such as Argon2id, with a unique random salt per account of at least one hundred and twenty-eight (128) bits, to the exclusion of any simple hash or reversible encoding. This rule applies to any application developed or taken over by the Provider. Declared gap: its verification application by application has not been completed for applications already delivered.

A2.4.5 Emergency access. An emergency access mechanism independent of the Bastion is installed on exposed machines, its private key being kept offline; system containers are excluded from it by documented decision and have an emergency path through the console of the virtualisation platform. Each use triggers a high-severity detection rule and a written report.

A2.5 Secrets management

A2.5.1 Vault. Operating secrets, namely technical passwords, tokens and keys, are kept in a self-hosted vault which constitutes their single source of truth and are injected into applications at runtime; no secret is written into a code repository, a container image or a versioned configuration file.

A2.5.2 Exposure. Any appearance of a secret outside the vault, even internal and even brief, is classified as a security incident: the secret is renewed immediately, the medium is destroyed and the event is traced, masking in an output never removing the need for renewal.

A2.5.3 Escrow. Backup encryption keys are held in escrow in the vault, which is separate from the backup repository and its secondary site. Declared gap: the key protecting the backups of the virtualisation cluster is not held in escrow; its loss would make the corresponding backups unrecoverable.

A2.6 Administration through a bastion and traceability

A2.6.1 Administration path. The Hosted Systems are administered through a dedicated Bastion, hosted outside the cluster it administers, which acts as a breaking relay and records each session. This Bastion cannot be reached from any address outside the Provider’s allow list, which has been verified from a third-party host not on that list: the administration services do not respond there. Administration flows are encrypted and authenticated end to end; no clear-text administration protocol is used.

A2.6.2 Parallel paths. Declared gap: unrecorded direct connections remain from the origins declared by the Provider; completeness of the recording of administration sessions is not guaranteed.

A2.6.3 Traceability. Authentications, privilege escalations and changes to access key files are logged and centralised, with real-time integrity monitoring of authorised key files. Recordings of administration sessions constitute, for the Client, an item of evidence for the purposes of Article 28(3)(h) of Regulation (EU) 2016/679. The extracts concerning the Client are provided to it on written request, redacted of elements relating to other clients, authentication secrets, internal technical addresses and any element whose disclosure would increase the attack surface of the Provider’s information system; where redaction deprives the extract of its evidential value, the Provider substitutes a detailed certificate or a consultation during a session without any document being handed over. The persons whose sessions are recorded are informed of the existence, purposes and retention period of this processing. Declared gap: no retention period is set for these recordings and no commitment as to depth of history is given.

A2.6.4 Automated processes and administration workstation. Automated deployment, backup and monitoring processes each have their own identity and key, restricted to the origin of the automated process and, where the command is fixed, to that command alone; no human key is used by an automated process. Declared gap: the administration workstation is not a dedicated, hardened workstation; it is also used for browsing and development and its disk is not encrypted.

A2.7 Network segregation and filtering

A2.7.1 Segregation. The Systems hosted on behalf of the Client are placed in a private network with no public addressing and cannot be reached directly from the Internet: they are published through the Front End, which provides encrypted termination, filtering of known reconnaissance paths and application of address reputation rules. The principle adopted is “one application, one machine”, one service per container. Segregation between the environments of different clients relies on the absence of public addressing for the machines on the private network, on this principle and on the separate access roles described in A2.3.1.

A2.7.2 Filtering. Every machine with a public address governed by the Provider carries, at the virtualisation layer, an explicit-deny inbound policy, whose consistency with the rules actually loaded in the kernel can be and is verified. Declared gap: the private network is not segmented by filtering rules between guests and the local firewall is not deployed consistently across all hosts.

A2.7.3 Delegated Zone. Filtering at the virtualisation layer is the Provider’s responsibility, including where the Client administers the guest system itself. Declared gap: this filtering is not effective across the entire Delegated Zone, and no filtering is applied at the upstream operator level; for these machines, the Provider does not guarantee the absence of direct exposure on the Internet of an application, administration or database service. Any filtering change likely to affect the availability of one of the Client’s services requires its prior written consent: for that purpose, the Provider sends it the list of the proposed rules and the Client has ten (10) Working Days to accept or refuse it in writing; if no reply is received within that period, consent is deemed given. In the event of refusal, the gap remains, the Provider records the reason in the register of derogations provided for in A2.2.4 and the Client bears the residual exposure risk, of which it declares that it has been informed. By way of exception, the Provider may apply without prior consent a filtering rule made necessary by an ongoing attack or by a vulnerability being actively exploited, under the conditions of A2.13.2.

A2.7.4 Application filtering and forms. An intrusion detection engine operated in standalone mode feeds the blocking of malicious origins; it runs on the Provider’s infrastructure and sends no signal to any third party. A web application firewall is deployed on the front ends; declared gap: it operates in blocking mode on some of them and in detection-only mode on the others, by dated decision recorded in the register of derogations. The public forms of sites developed or operated by the Provider are protected against automated abuse by a self-hosted mechanism, without cookies and without transfer outside the European Union.

A2.8 Encryption in transit and at rest

A2.8.1 In transit. All services published on behalf of the Client are accessible exclusively over an encrypted channel, using at least version 1.2 of the Transport Layer Security protocol, with valid certificates renewed automatically; administration flows are encrypted and authenticated end to end.

A2.8.2 Naming. Declared gap: cryptographic signing of domain name zones, certification authority restriction and strict mail transport security policy are not enabled, this derogation being justified by the risk of unavailability resulting from an orphaned signature and recorded in the register of derogations.

A2.8.3 Backups. Backups of the Data are encrypted by the Provider before their transmission to the backup repository and its secondary copy; the keys are not held by any repository operator.

A2.8.4 Production volumes. Declared gap: the storage volumes of production systems and of the administration workstation are not encrypted at rest. The risk is mitigated by the segregation described in A2.7, by filtering of exposed systems, by encryption of backups and by the physical security of the media, provided by OVHcloud SAS, 2 rue Kellermann, 59100 Roubaix, France (RCS Lille Métropole 424 761 419) in its data centres located in the European Union.

A2.9 Logging, monitoring and detection

A2.9.1 Collection. The Provider collects and centralises the security logs of all the systems it administers: authentications, privilege escalations, administration actions, access to the Front End, events from the identity provider and the virtualisation platform. Collection is carried out by an agent installed on each host, whose deployment is a condition for release to production, and real-time integrity monitoring covers access key files.

A2.9.2 Protection. Logs are kept segregated from the main system, on a dedicated, segregated machine whose collection ports are restricted to named sources; agents have write-only rights and no application account can delete a log. No secret, no authentication element and no data falling under Article 9 of Regulation (EU) 2016/679 is written into a log, which carries the reference of the data concerned and not its content.

A2.9.3 Retention periods. The policy applied is as follows: centralised security events, twelve (12) months; local system logs, six (6) months; Front End access logs, approximately fourteen (14) days, according to the configured rotation. These periods fall within the range of six months to one year recommended by the CNIL (Commission nationale de l’informatique et des libertés) for logging. This policy has been applied since 2 September 2026 and the depth of history actually available has been growing since that date: no commitment as to earlier depth is given and the Provider provides on request a statement of the depth actually available. Logs relating to a data breach or to litigation are excluded from purging and kept for five (5) years from the closure of the file.

A2.9.4 Monitoring and detection. The Provider carries out permanent automated monitoring of the availability of the Hosted Systems by means of probes and metrics collectors, with automatic notification to operational points of contact. It operates a detection platform covering all the hosts it administers, with correlation rules dedicated in particular to use of the emergency access and to changes to access key files.

A2.9.5 Alerting. High-severity security alerts are routed automatically to a notification channel for the Provider’s technical staff, and no notification output may be disabled without a written reactivation date. This technical routing constitutes neither an alert time commitment, nor a commitment to human handling, nor on-call support. The Provider claims no continuous human monitoring: the scope of its notification commitment is that defined in Article 14.2 of the data processing agreement. Extracts of the logs concerning the Client are provided to it on written request, and to supervisory authorities and incident response teams in the context of a notification or a legal requisition.

A2.10 Vulnerability and patch management

A2.10.1 Watch and tracking. On Working Days, the Provider carries out a daily watch of the advisories of the competent national authority and of the publications of the vendors of the components it operates. The administered hosts are enrolled in a fleet management tool which reports patch status, produces a periodic report, flags any silent host and raises an alert when a security patch remains pending.

A2.10.2 Patching deadlines. The Provider applies security patches within the following deadlines, counted from the date the patch is made available by the vendor, or from the publication of the national authority’s advisory if earlier.

Effective severity is determined by the intrinsic severity, raised by one level in the event of observed exploitation or a high probability of exploitation, and weighted by the actual exposure of the system. The identity provider, the Bastion, the secrets vault and the Front End automatically fall under the regime for Internet-facing systems, the applicable deadline being capped at seven (7) days whatever the severity, without this cap being able to extend a shorter deadline. These deadlines apply to vulnerabilities brought to the Provider’s attention from the effective date of the Contract; previously identified vulnerabilities, consisting essentially of components for which no upstream patch has been published, are subject to a remediation plan whose progress is provided to the Client on written request.

A2.10.3 No patch available. Where no upstream patch has been published, the Provider implements a mitigation measure without delay if the vulnerability is being exploited, and records the residual risk in writing in the register of derogations. The Provider does not guarantee the absence of vulnerabilities in the third-party components it deploys.

A2.10.4 Supply chain. The patches and tools installed come exclusively from the vendors’ official repositories, with signature verification, or from an official release whose cryptographic hash is verified; no tool is installed by directly executing a downloaded script or by adding an unsigned third-party repository.

A2.10.5 Delegated Zone. The Provider notifies the Client in writing, within three (3) Working Days, of any vulnerability brought to its attention affecting a guest system that the Client administers, with the recommended measure, and where appropriate applies a compensating measure at the infrastructure level. It provides neither monitoring, nor patch tracking, nor incident detection inside that system.

A2.11 System hardening and physical security

A2.11.1 Base. The Hosted Systems rely on a single base, provisioned and maintained by automation, any machine outside the base being a documented exception. The remote access service is hardened by a single configuration file deployed across the whole fleet, refusing password authentication and direct password login to the system account.

A2.11.2 Containers. The runtime rules provide for a dedicated network per application, a prohibition on mounting a sensitive host directory, limitation of capabilities, a read-only root filesystem where the application allows it, memory and processor limits expressed in absolute values and never as a percentage, and exported, capped logs. Declared gap: these rules are not applied across the whole fleet and mutable image tags remain in production.

A2.11.3 Physical and environmental security. The Provider does not operate any data centre of its own. The Hosted Systems run on servers installed in the data centres of OVHcloud SAS, 2 rue Kellermann, 59100 Roubaix, France (RCS Lille Métropole 424 761 419), located in Strasbourg, Roubaix and Gravelines (France): physical access control to the premises, site security, power supply, cooling and disposal of media are the responsibility of that hosting provider, whose commitments are set out in its own terms and are provided to the Client on request. The site where the secondary copy of the backups is made is placed under the exclusive control of the Provider, in France, and receives only encrypted Data whose keys are held by the Provider alone; it is located in locked premises, access to which is restricted to individually named authorised persons, the storage medium there is dedicated to that sole use and no service there is exposed on the Internet. The Parties expressly acknowledge that this site is not a professional data centre and that it has neither a backed-up power supply, nor fire detection and suppression equipment, nor logged physical access control; the corresponding risk is mitigated by encryption of the Data, by the merely secondary nature of this copy and by the primary copy being kept in a data centre of OVHcloud SAS, 2 rue Kellermann, 59100 Roubaix, France (RCS Lille Métropole 424 761 419). Declared gap: this site is not connected to the fleet’s detection platform.

A2.12 Backups, restoration and continuity

A2.12.1 Frequency and encryption. All Hosted Systems are subject to an automated daily backup run outside business hours, databases giving rise to a consistent application export produced before the image backup. Backups are encrypted before transmission and the repository operator holds no decryption key. Location arrangements: backups are encrypted at source before transfer; the primary copy is kept in the European Union (Germany) and a mirror copy is kept in France.

A2.12.2 Relative immutability. Production systems have write and read rights on the backup repository, to the exclusion of any deletion right, this refusal having been verified under real conditions: compromise of a production system therefore does not make it possible to erase its own backups. The secondary copy is made by pulling at the initiative of the secondary site, with no access possible from the repository to that site. Declared gap: no offline or immutable copy is made.

A2.12.3 Verification. The integrity of backups is verified by a daily automated check, the time to detect an alteration being less than twenty-four (24) hours for a newly created backup set; purges are automated. Reports are provided to the Client on written request.

A2.12.4 Retention. The retention applied to production systems is at least seven (7) daily backups, two (2) weekly and one (1) monthly, giving a depth of approximately five (5) weeks.

A2.12.5 Restoration. Restoration is carried out to a new environment, without overwriting the original environment, so as to allow a joint check before return to service. A full restoration of a virtual machine was successfully carried out on 7 August 2026, in two hundred and forty-one (241) seconds, together with a file-level restoration in which the hash of the restored content was identical to the original. This fact is mentioned as evidence of capability and does not constitute any restoration time commitment. Declared gaps: the Provider does not commit to any programme of periodic restoration tests and no restoration from the secondary copy has been tested.

A2.12.6 Emergency isolation. In the event of suspected compromise, the Provider implements a written procedure for isolating the backup system: suspension of synchronisations, revocation of the repository tokens of the suspected sources, tightening of repository filtering and suspension of purges. Declared gap: this procedure has not been tested in an exercise.

A2.12.7 Redundancy and continuity. The Hosted Systems run on the infrastructure described in the special conditions of the Contract. Where these provide for a virtualisation cluster spread across several physical servers, the resources of a failed server are restarted on a surviving server from their periodic replica; failing such a provision, no hardware redundancy is provided and recovery takes place by restoring a backup. The Parties expressly acknowledge that this mechanism constitutes automated recovery with interruption, and not uninterrupted service continuity: no guarantee of transparent failover, of recovery without outage or of active load distribution across several sites is given. The Provider does not guarantee any quantified restoration time and does not commit to any recovery time objective or maximum tolerable data loss other than in an annex to the main contract signed for that purpose. Declared gaps: no failover test has been conducted; there is no formalised business continuity and disaster recovery plan, nor any quantified objective for maximum tolerable data loss or maximum tolerable downtime.

A2.12.8 Dependencies. Declared gap: compute, name resolution, domain name registration and part of the backups rely on a single infrastructure provider, OVHcloud SAS, 2 rue Kellermann, 59100 Roubaix, France (RCS Lille Métropole 424 761 419), and the Provider’s e-mail delivery route also relies on a single provider.

A2.12.9 Unavailability of the Provider. The Provider maintains, offline and outside its information system, a recovery file containing the contact details of its critical suppliers, the location of the means of decrypting the backups, the emergency access procedure, the order of restoration of services and the list of client contacts. It designates a standby contributor by means of a delegation of powers granted by a written and dated decision of the company’s President, which defines its scope (access to the relevant environments only, protective measures and communication with the Client, limited to what is necessary to maintain and return the Data and configurations) and its activation conditions, foremost among which are the Provider’s incapacity or lasting unavailability. Since it emanates from the company and not from the person of its President, this delegation survives the latter’s incapacity. The Client is informed of it and the decision is provided to it on written request. The Provider delivers to the Client, in a sealed envelope or by deposit in a safe agreed between the Parties, only the elements necessary to recover the Client’s Data and to resume the services specific to it: emergency access means for the Hosted Systems dedicated to it, means of decrypting the backups concerning it, transfer codes for its domain names and private keys for its certificates. No identifier, token or means of access to the Provider’s account with OVHcloud SAS, 2 rue Kellermann, 59100 Roubaix, France (RCS Lille Métropole 424 761 419), or to a shared system hosting other clients’ data, is delivered to the Client: access to the upstream infrastructure is, where applicable, exercised by the standby contributor. This deposit is updated upon each substantial change to the access rights concerned.

A2.13 Development, software supply chain and change management

A2.13.1 Delivery chain. The source code of the applications developed by the Provider resides in a code forge that it self-hosts. Images are built by a continuous integration runner which holds no access key to the production systems: it publishes the image to an internal registry and triggers a deployment controller through a constrained command. Deployment targets an exact version reference, never a branch, and is deemed successful only after a blocking health check of the service. Declared gap: the Provider claims neither mandatory code review, nor automated security analysis of the code, nor systematic provision of a software bill of materials.

A2.13.2 Prior confirmation and information of the Client. Any intervention modifying one of the Client’s Hosted Systems or an application intended for it is subject to explicit prior human confirmation. That confirmation is given by a person, never by an automated process, never inferred from silence, relates to a named and bounded change, and is recorded with its timestamp. It is given by an authorised member of the Provider’s staff and is distinct both from informing the Client and from the Client’s prior consent, which is required only where this annex or the Contract expressly so stipulates. The Client is informed at least five (5) Working Days before any structural change affecting its service, with the nature of the change, the maintenance window, the expected interruption and the point of contact. By way of exception, the application of a security patch within the deadlines of A2.10.2, the implementation of a mitigation measure within the meaning of A2.10.3 and the execution of a protective measure may be carried out without prior confirmation or information where urgency so requires; the Client is then informed, with the result of the intervention and the reason for the derogation, no later than the following Working Day.

A2.13.3 Rollback and traceability. No change is executed unless its rollback method, its rollback point and its estimated duration have been determined and verified beforehand. Any structural change is preceded by a backup whose success is verified. A change whose health check fails gives rise to an immediate rollback, without any fix-forward on production. The Provider records each intervention with its date, subject, reason, the systems concerned, the rollback method, the confirmation obtained and the result; the entries concerning the Client are provided to it on written request.

A2.13.4 Test data. No production data, and in particular no Data, is used in a development, test or pre-production environment: test data sets are synthetic or anonymised. Declared gap: the Provider does not have a complete pre-production environment, the compensating measure being to carry out tests on a system restored from a backup.

Remediated gap. A working copy of a database operated for a Client existed outside the production environment, on an administration workstation. It remained encrypted at all times, and no clear-text extraction was carried out. The service and its volumes have been deleted and the absence of any other copy has been verified. The applicable rule is now that of the first subparagraph of this paragraph: development, debugging and test environments are rebuilt on data sets containing no real data.

A2.13.5 Components and cryptography. The form abuse protection and audience measurement mechanisms implemented on the Client’s sites are self-hosted, cookie-free and involve no transfer outside the European Union, the audience measurement anonymising the connection address. Audience data from different sites is not cross-referenced and each publisher accesses only the statistics of its own site, to the exclusion of those of any other. The Provider operates this measurement as processor, on the Client’s documented instructions and exclusively on the Client’s behalf. The Client remains the controller for the audience measurement carried out on its site: it is for the Client to assess, in the light of Article 82 of Law no. 78-17 of 6 January 1978 and the guidelines of the CNIL, whether the chosen configuration qualifies for the consent exemption, and accordingly to ensure that data subjects are informed and, where applicable, that their consent is collected. The Provider does not guarantee that the configuration delivered is exempt from consent; it provides the Client, on written request, with the actual settings, the data collected and their retention period. Cryptographic mechanisms are never reimplemented, only recognised and maintained libraries being used.

A2.13.6 Data protection by design. Any application developed or taken over by the Provider on behalf of the Client is subject, before its release to production, to a description of the path of the Data it processes and to a limitation of the fields collected to what is strictly necessary having regard to Article 5(1)(c) of Regulation (EU) 2016/679. The Provider technically implements, by means of a scheduled purge, the retention periods that the Client gives it, and provides for the possibility of fulfilling a request to exercise rights without manual intervention in the database.

A2.14 System lifecycle, end of life and erasure

A2.14.1 Commissioning. No system goes into production without having been connected to all of the Provider’s mandatory mechanisms: Bastion, configuration automation, log collection, patch management, metrics, availability monitoring with notification, backup, internal name resolution and inventory documentation. The base of a new machine provides for access keys to be placed on an unprivileged account, the system account password to be locked and the console secret to be stored in the vault.

A2.14.2 Decommissioning. The withdrawal of a system gives rise to unpublishing, stopping monitoring, closing access, destroying the system and erasing residual traces, followed by a check that it has disappeared and a dated report. The decision on the fate of the backups is taken expressly and in writing, absence of a decision being equivalent to retention. Declared gap: residual data from systems previously withdrawn remains; the server media are, moreover, under the physical control of OVHcloud SAS, 2 rue Kellermann, 59100 Roubaix, France (RCS Lille Métropole 424 761 419) and subject to its disposal procedures.

A2.14.3 End of the Contract. At the end of the service, for whatever reason, the Client notifies the Provider of its choice between the return of all the Data concerning it and its destruction, in accordance with Article 28(3)(g) of Regulation (EU) 2016/679 and according to the arrangements and time limits provided for in the DPA. Return takes place in a usable format; deletion from the active database and from production systems takes place within thirty (30) days of, as the case may be, acceptance of the record of return or receipt of the destruction instruction. Backup copies are neither modified nor extracted from, in order to preserve their integrity; they disappear through automatic purging when the applicable retention period expires, which may not exceed twelve (12) months from deletion from the active database. Where a restoration takes place within that interval and reintroduces data whose erasure had been requested, the Provider reapplies the erasure without delay. A dated certificate of destruction is issued, specifying the scope, the date of erasure from production, the expiry date of the last backup and the means used.

A2.15 Sub-processors, suppliers and location of the Data

A2.15.1 Sub-processors. The list of sub-processors appears in an annex to the DPA, with, for each, the activity entrusted, the country of processing and the applicable safeguard in the event of a transfer outside the European Union. The Provider informs the Client in writing of any addition or replacement as soon as possible and, in any event, at least ten (10) days before its implementation; the Client has ten (10) days from such information to raise in writing a reasoned objection based on data protection considerations. This period corresponds to the shortest notice that the Provider itself obtains from its own suppliers. In the event of an objection, the Parties consult in good faith to seek an alternative arrangement; if the disagreement persists, the Client may terminate the service concerned without charge or compensation on either side, subject only to payment for the services performed. In the event of the failure, security breach or cessation of business of a sub-processor making it impossible to observe the notice period, the Provider may replace it with a provider offering at least equivalent guarantees and informs the Client without delay, giving reasons for the urgency; the right to object is then exercised after the event. The Provider remains fully liable for the performance by the sub-processor of its obligations.

A2.15.2 Location. The Data is hosted and backed up within the European Union according to the following distribution.

The Client acknowledges that it has been informed that the primary backup copy is located in Germany and not in France, and undertakes to pass this information on in its own privacy policy where it mentions the location of the hosting. Any change of location is notified to the Client with thirty (30) days’ notice.

A2.15.3 Transfers outside the European Union. The Data processed for hosting and backup purposes is hosted and stored exclusively within the territory of the European Union: no transfer outside the Union takes place as a result of hosting or backup. However, the operations assistance tool mentioned in A2.15.4 and, where the service includes them, the execution of inference calls with a provider established outside the Union involve a transfer. These services are exhaustively listed in an annex to the DPA, which specifies for each the categories of Data transferred, the country of destination and the applicable appropriate safeguard, being an adequacy decision within the meaning of Article 45 of Regulation (EU) 2016/679 or the standard contractual clauses of Commission Implementing Decision (EU) 2021/914, supplemented by the necessary additional measures. No new transfer of Data is implemented without prior information to the Client.

A2.15.4 Operations assistance tool. The Provider expressly informs the Client that an automated assistance tool, identified in an annex to the DPA, is used for operations and diagnostic assistance: the material submitted to it is limited to the configuration elements and extracts of logs and files strictly necessary for the intervention in progress, which may include connection addresses and technical identifiers. The Provider undertakes not to transmit to it authentication secrets or cryptographic keys, nor to transmit to it Data beyond what the incident being handled makes necessary; it minimises the material submitted, in particular by truncating logs and masking direct identifiers where the diagnosis allows. Any modification to a Hosted System is subject to the prior human confirmation provided for in A2.13.2. The Client may, by written instruction, exclude its systems from the scope of this tool; the Provider does so within thirty (30) days and informs the Client of the impact of that exclusion on diagnostic times. Declared gap: the technical account of this tool has extended rights over the Provider’s base and the scope of the access token for the infrastructure provider is not restricted.

A2.16 Personnel and confidentiality

A2.16.1 Any person authorised to access the Data is subject to a contractual confidentiality obligation, written and signed before any access, pursuant to Article 28(3)(b) of Regulation (EU) 2016/679. The list of authorised persons is provided to the Client on written request.

A2.16.2 Declared gap: the Provider has no signed IT resources acceptable use policy, no tracked awareness programme and no crisis exercise. Staff remain bound by secrecy by virtue of the Contract, the provisions of the general terms of sale relating to confidentiality and trade secrets and, in the case of officers, their duty of loyalty.

A2.17 Management of incidents and data breaches

A2.17.1 Assessment. Every security event detected is assessed by the Provider, which determines whether it constitutes a personal data breach within the meaning of Article 4(12) of Regulation (EU) 2016/679.

A2.17.2 Notification to the Client. The Provider notifies the Client of any Data breach of which it becomes aware without undue delay and at the latest forty-eight (48) hours, non-working days included, from becoming aware of it, by e-mail sent to the point of contact designated by the Client, and provides it with the information referred to in Article 33(3) of Regulation (EU) 2016/679 to the extent that it is available. Becoming aware means, in the same terms as in the DPA, the moment at which the Provider acquires a reasonable degree of certainty that a security incident has compromised Data. This period is counted in calendar hours and is not suspended by a Saturday, a Sunday or a public holiday: it is stipulated so that the Client retains a useful part of the seventy-two (72) hours available to it to notify the breach to the supervisory authority. It does not, however, constitute a commitment to continuous detection: security events are handled by a person on Working Days, automated detection remaining active outside those hours and events being recorded for handling when work resumes; the Provider gives no commitment to on-call support, standby cover or continuous human monitoring. Where the information cannot be provided all at once, it is provided in phases, without undue delay; a late notification is accompanied by the reasons for the delay.

A2.17.3 Assistance. Taking into account the nature of the processing and the information available to it, the Provider assists the Client in complying with its obligations under Articles 33 and 34 of Regulation (EU) 2016/679 and, where applicable, those arising from Directive (EU) 2022/2555 or Regulation (EU) 2022/2554 where the Client is subject to them, without the Provider itself qualifying as an essential or important entity.

A2.17.4 Register, lessons learned and protective measures. The Provider keeps a register of data breaches and provides it to the Client insofar as it concerns the Client. It sends the Client a written lessons-learned report within fifteen (15) days of the closure of the incident, setting out the chronology, the identified cause, the corrective measures applied and the preventive measures decided upon. In the event of suspected compromise, it implements without delay proportionate protective measures, in particular network isolation of the system concerned, revocation of exposed access rights and secrets, preservation of traces and isolation of the backup system described in A2.12.6.

A2.18 Special categories of data

A2.18.1 Under the Contract, the Provider processes no data falling within the special categories referred to in Article 9 of Regulation (EU) 2016/679, unless otherwise stipulated in the DPA.

A2.18.2 Where the Main Contract states, pursuant to Article 5.2 of the DPA, that the processing concerns such data, the Provider implements, on the Client’s documented instructions and after written agreement of the Parties, the following enhanced measures: systematic pseudonymisation, additional application-level encryption of the fields concerned, named logging of access, restriction of permissions to an up-to-date named list, restriction of backups to what is strictly necessary, reduction of retention periods and exclusion of such data from the scope of the operations assistance tool mentioned in A2.15.4.

A2.18.3 Health data. The Provider does not hold the certificate of compliance required, under paragraph II of Article L. 1111-8 of the French Public Health Code (code de la santé publique), of anyone who hosts on an electronic medium personal health data collected in the course of prevention, diagnosis, care or social and medico-social monitoring activities, on behalf of the person who produced or collected them, or of the patient themselves. Accordingly, it carries out no service subject to that certificate, that is to say none of the activities listed in Article R. 1111-9 of the same code (provision and keeping in working order of physical sites, of the hardware or virtual infrastructure or of the application hosting platform, administration and operation of the information system containing the data, backup of that data) where those activities concern an information system storing such data on behalf of others. Recourse to a certified sub-host does not exempt it from this where its own involvement falls within one of those activities.

Express reservation. The foregoing concerns only the storage of health data on behalf of others. Accordingly, the incidental, transient and non-persistent mention of a health-related item in a free-text field or an address in a form not intended to collect such data is not a service subject to certification, where that form contains no structured health field, no database stores its content and the request is forwarded to the Client without any storage by the Provider other than for the time strictly necessary for its forwarding. In that case the Provider does not store any health data on behalf of others; such data remains the Client’s data.

Creating a database storing the content of such fields, adding a structured health-related field, indexing or any cross-referencing of such information changes the qualification and requires a prior review. Any service then concerning personal health data is subject either to obtaining the required certificate beforehand, or to an allocation of roles formalised by amendment placing outside the Provider’s scope any activity subject to certification. The Client guarantees to the Provider that no personal health data is introduced into the Hosted Systems outside the express reservation above or such an amendment, and informs it without delay if it finds that such data has been introduced.

A2.19 Evidence and the Client’s audit right

A2.19.1 Provision of evidence. The Client may request, on thirty (30) days’ written notice, the evidence corresponding to the measures described in this annex; such disclosure is not subject to any frequency limit where it is necessary to enable the Client to demonstrate compliance with its own obligations under Articles 28 and 32 of Regulation (EU) 2016/679, in particular in connection with a data breach, an inspection by the supervisory authority or a data protection impact assessment.

A2.19.2 Audit. The Client may have an audit or inspection within the meaning of Article 28(3)(h) of Regulation (EU) 2016/679 carried out, by itself or by an independent third-party auditor it appoints, under the conditions provided for in the DPA or, in the absence of a DPA, under the following conditions: thirty (30) days’ written notice, save in an emergency justified by a proven security incident; one audit per calendar year outside incidents; performance during the Provider’s Working Days and business hours; scope limited to the systems and processing concerning the Client; an auditor who is not a competitor of the Provider and is bound by a written confidentiality undertaking provided in advance. An additional audit may be conducted following a Data breach affecting the Client.

A2.19.3 Enforceable limits. The Provider discloses neither the detailed map of its exposure, nor the list of its privileged accounts, nor any element whose disclosure would increase the attack surface of its information system; it then substitutes an alternative means of effective verification, in particular a detailed certificate, an anonymised time-stamped record or a verification during a session without any document being handed over. It may not rely on these limits to deny the Client any means of verifying the performance of an obligation entered into under this annex.

A2.19.4 Scope of the description. The Provider may not present a measure as being in place until its implementation has been verified and documented. This annex describes the state of the measures as at the version date shown at the top; where a declared gap has been remediated, the version attached to the Contract mentions its remediation with the date of the record that evidences it. In the absence of such mention, the gap is deemed to remain and the Client may, without compensation, refuse to sign or make signature conditional on the prior update of the annex.

A2.20 Limits expressly brought to the Client’s attention

Under its duty of truthfulness, the Provider declares that the following measures are not in place as at the date of signature and that the following limits affect the entrusted scope:

1. encryption of the storage volumes of production systems and of the administration workstation, only backups being encrypted; the administration workstation is, moreover, a multi-purpose workstation, not dedicated to administration alone;
2. enforcement of a second authentication factor on all administration systems;
3. completeness of the recording of administration sessions, administration paths parallel to the Bastion remaining;
4. the actual availability of a twelve-month log history, the retention policy having been applied only since 2 September 2026, and the retention of Front End access logs for six months;
5. the existence of on-call support, standby cover, continuous human monitoring or a dedicated incident response team;
6. the existence of a formalised and tested business continuity and disaster recovery plan, and consequently of any enforceable recovery objective or maximum tolerable data loss;
7. detection inside the systems that the Client administers itself;
8. any security certification, qualification or accreditation issued by a third-party body, and any independent audit or external penetration test;
9. filtering, at the virtualisation layer and at the upstream operator level, of machines with a public address administered by the Client itself; the Provider does not guarantee, for these machines, the absence of direct exposure on the Internet of an application, administration or database service;
10. segmentation of the private network by filtering rules between guests and deployment of a consistent local firewall across all hosts;
11. extension of the principle of least privilege to human administration accounts, which have extended rights over the base operated by the Provider;
12. escrow of the encryption key protecting the images of the virtualisation base, the loss of which would make the corresponding backups unrecoverable;
13. limitation to least privilege of the permissions of the operations assistance tool’s technical account and restriction of the scope of the access token for the infrastructure provider;
14. the making of an offline or immutable backup copy, and testing of a restoration from the secondary copy and of the emergency isolation procedure;
15. the holding of periodic security reviews, supplier reviews, scheduled restoration tests and crisis exercises, which the Provider does not commit to and does not present as being held.

Annex 3. Authorised sub-processors

This annex is referred to in Articles 10 and 11 of the Agreement. It exhaustively lists the Sub-processors authorised as at the date of this version. Any change follows the prior information procedure and the ten (10) day right to object in Article 10. A Sub-processor specific to a particular engagement is mentioned in the Main Contract, under the conditions of 5.2.

A3.1 Common base, used for all services

A3.2 Language model providers and operations assistance tool

This section applies where the Main Contract includes a consulting, integration or operations service based on an artificial intelligence system, and to the Processor’s operations assistance tool. It deals only with the status of the providers concerned as Sub-processors and with the safeguards for the Data transmitted to them; the allocation of roles between the Parties in respect of artificial intelligence systems is a matter for the Main Contract and the annex attached to it.

Components run on the Processor’s infrastructure, in particular an open-weight model, the audience measurement instance, the intrusion detection engine operated in standalone mode and the form protection mechanism, are not Sub-processors within the meaning of Article 28.4 of the GDPR: no Data is transmitted to any third party as a result. Their replacement by a third-party service follows the prior information procedure and right to object in Article 10.

No provider is used until four conditions are met and documented: written exclusion of training on submitted content; zero retention or retention limited in writing; a processing agreement entered into under Article 28 of the GDPR; an appropriate safeguard within the meaning of Chapter V of the GDPR for any processing outside the European Union. The Processor informs the Controller, without undue delay and at the latest within five (5) Working Days of becoming aware of it, of any adverse change affecting one of these providers, in particular the removal of the training exclusion, the introduction of retention or a change in the location of processing, and suspends use of the provider concerned for the Controller’s Data pending the Controller’s decision.

The operations assistance tool accesses the Controller’s application content only to the extent strictly necessary for an operational intervention or the resolution of an incident. Before any transmission, the Processor minimises the content submitted: truncation of connection addresses, removal of direct identifiers of Data Subjects, authentication secrets and access tokens, and replacement of technical identifiers with non-meaningful references. Any modification to a production system or to an application of the Controller is subject to prior human approval, and the corresponding sessions are recorded under the conditions of Annex 2. The Controller may, by written instruction, exclude its systems from the scope of this tool; the Processor does so within thirty (30) days and informs the Controller of the impact of that exclusion on diagnostic times. As at the date of this version, the technical account of this tool has extended administration rights over the Processor’s base, under the conditions of point 13 of A2.20 of Annex 2.

A3.3 Services subscribed to directly by the Controller

The following services, where they form part of the technical chain of the Processing, are subscribed to directly by the Controller from their publisher: online payment platform, payment collection platform for associations, social networks and social messaging services, music or video content distribution services, third-party audience measurement services. They do not constitute Sub-processors of the Processor within the meaning of Article 28.4 of the GDPR. The Controller is responsible for their legal framework, for entering them in its own record, for informing Data Subjects and, where applicable, for the safeguards governing the transfers outside the European Union that they involve.