Data Processing Agreement — standard template
This document is a standard form for a separate Data Processing Agreement. Publication alone does not execute it for a customer or amend an existing signed agreement. Before entrusted processing starts, the relevant parties must put a binding agreement and completed instructions in place, identifying the applicable operations, data and data-subject categories, authorised recipients, duration and return or deletion arrangements. A customer that acts as a processor must establish the controller’s required authorisation and the appropriate contractual chain. Instructions may be expressed through authorised Platform actions within the agreed scope; an access setting does not override legal restrictions or extend that scope.
1. Parties, references and definitions
1.1. This Data Processing Agreement (“DPA”) is made between [full legal name, registered address, registration/tax identifiers and authorised representative] (“Controller”) and BidFinance spółka z ograniczoną odpowiedzialnością, ul. Kącik 4, 30-549 Kraków, Poland, KRS 0000975000, NIP 6793240675, REGON 522206447, represented by [authorised signatory and authority] (“Processor” or “BidFinance”).
1.2. This DPA concerns the services identified in [service agreement/order title, parties, date, identifier, applicable Terms version and any existing DPA or agreed order of precedence] (“Service Agreement”). The four annexes form part of this DPA. GDPR means Regulation (EU) 2016/679. GDPR definitions apply; “Entrusted Data” means personal data processed by BidFinance on the Controller's behalf within Annex 1. A “Subprocessor” is another processor engaged by BidFinance for those operations.
1.3. This standard form assumes the customer is a controller for the identified operations. If the customer acts as a processor for another controller, the parties must identify that controller, the authority to appoint BidFinance as a subprocessor and the corresponding instruction chain before using an appropriately adapted agreement. Signing this form does not itself establish the factual roles.
1.4. Approval of a subsidiary to use the Platform does not automatically make it a party to this DPA or authorise its parent to instruct on its behalf. Each relevant controller must be identified and bound by the appropriate agreement or an express accession, acting itself or through a duly authorised representative. Annex 4 must specify each such relationship and authority.
2. Subject matter, purpose and role boundaries
2.1. The Controller instructs BidFinance to provide the agreed debt-portfolio auction and transaction-workspace services, including storage, controlled availability and handling of the specific documents and personal data listed in Annex 1. Processing may include receipt, recording, organisation, storage, retrieval, display, instructed disclosure, correction, export, restriction and deletion, only as needed for the agreed service and documented instructions.
2.2. The Controller determines the purposes, permitted data, recipients and essential rules for its Entrusted Data. BidFinance may select practical technical means within those instructions and the agreed safeguards. It must not use Entrusted Data for its own marketing, sale of data, unrelated analytics or training of general-purpose models. A new purpose or material expansion of scope requires a lawful, documented arrangement; a website policy change is insufficient.
2.3. Separate operations for which BidFinance determines its own purposes, such as its own customer-representative relationship, Account administration, service security and legally required records, are described in the Privacy Policy. They are outside this DPA only to that justified extent. A document containing a representative's name is not automatically removed from the entrusted scope. Copying an entire entrusted portfolio into BidFinance's own claims archive is not authorised by this clause.
2.4. Buyers, sellers and advisers receiving data for their own purposes are not automatically Subprocessors. Disclosure to them must have its own role assessment, lawful basis, instructions and access conditions. Sections 8.9 and 12.22 of the applicable Terms, anonymity requirements and banking secrecy remain relevant. This DPA does not authorise identification of debtors in materials that must be anonymous or grant every Platform user access to confidential data.
3. Duration
3.1. This DPA becomes effective on the agreed execution date entered below and applies while BidFinance processes Entrusted Data for the Controller. New processing begins only after the necessary scope, instructions, safeguards and authorisations have been agreed. It continues through the restricted return/deletion phase in section 12. Confidentiality, assistance, accountability and restrictions on retained copies survive for as long as relevant data remains.
3.2. A portfolio or workspace retention event may precede termination of the Service Agreement. Annex 4 must identify these events and the authorised return/deletion instructions. Service duration is not permission to retain every document until the last possible date.
4. Controller's responsibilities
4.1. The Controller is responsible for the lawfulness, necessity and accuracy of the data and instructions it supplies, its legal bases and information duties, its decisions on access and recipients, and any banking secrecy or other confidentiality requirements. It shall provide only the data necessary for the agreed operation, apply the agreed anonymisation or pseudonymisation before disclosure, keep recipient permissions current and communicate corrections, restrictions and lawful erasure instructions.
4.2. Special-category data under Article 9 GDPR and data covered by Article 10 are not included by default. Before such data is intentionally supplied, the Controller must identify the relevant categories and legal conditions and agree the additional safeguards in Annex 1. Unexpected discovery requires prompt notification, restricted access and a documented decision on lawful handling or deletion; it is not permission for further use.
4.3. These duties do not release BidFinance from its own GDPR duties or its obligations under this DPA.
5. Documented instructions
5.1. Instructions consist of the executed DPA and completed annexes, authorised settings/actions in the agreed Platform workflows, and subsequent instructions from the authorised contacts through the channels in Annex 4. BidFinance shall preserve a record identifying the instruction, origin, date, scope and implementation. A person with document-upload permission is not automatically authorised to amend the DPA, approve a new recipient class or authorise a third-country transfer.
5.2. BidFinance shall process Entrusted Data only on documented instructions, including regarding transfers, unless Union or Member State law applicable to it requires otherwise. In that case it shall inform the Controller of the legal requirement before processing unless that law prohibits the information on important grounds of public interest. It shall limit the processing to the legal requirement and document the basis and scope.
5.3. BidFinance shall immediately inform the Controller if, in its opinion, an instruction infringes GDPR or other applicable Union or Member State data-protection provisions. It shall suspend the disputed operation while the issue is resolved, protect the data and cooperate on a lawful instruction. Neither silence nor commercial urgency authorises unlawful processing.
6. Personnel and security
6.1. Access shall be limited to authorised personnel who need it for the agreed task and are bound by confidentiality before access, under an undertaking or an appropriate statutory duty. Confidentiality continues after their assignment ends. BidFinance shall maintain an authorisation process, revoke access when no longer needed and provide instruction appropriate to each person's role.
6.2. BidFinance shall implement and maintain technical and organisational measures appropriate to the risk under Article 32 GDPR, considering the state of the art, implementation costs, and the nature, scope, context, purposes and risks of the processing. The agreed measures in Annex 2 cover confidentiality, integrity, availability, resilience, recovery and regular evaluation. Measures must be operational before the relevant Entrusted Data is processed; code presence alone is not evidence that a control is enabled.
6.3. BidFinance may improve measures without reducing the agreed level of protection. It shall document material changes, inform the Controller where its risk assessment or instructions are affected and agree necessary changes before any material reduction. New threats, incidents or changes in the data scope require reassessment. No certification, penetration-test result, recovery target or hosting region is warranted by this DPA without the supporting evidence identified in Annex 2.
7. Subprocessors
7.1. By executing the completed DPA, the Controller grants general written authorisation for Subprocessors under this section, initially limited to the actual legal entities and operations identified and approved in Annex 3. Blank rows and names of possible integrations are not authorisation. BidFinance shall assess sufficient guarantees and bind each Subprocessor, before access, to data-protection obligations equivalent to those applicable to its entrusted task, including instructions, security, confidentiality, assistance and deletion.
7.2. Before adding or replacing a Subprocessor engaged directly by BidFinance, BidFinance shall actively notify the Controller’s designated email contact. The complete notice must give the legal entity, service, data scope, locations and relevant remote access, transfer safeguards, intended start date and information needed to assess protection. The Controller shall have 14 calendar days beginning on the day after delivery of the complete notice to object on data-protection grounds. This is a contractual period for direct engagements. For intended additions or replacements further in the processing chain, BidFinance shall provide the relevant information without undue delay after receiving it and before the affected processing begins, preserving a real opportunity to assess and object. No uniform 14-day upstream period is agreed. If that opportunity cannot be provided before the affected processing, BidFinance shall prevent it, obtain specific prior written authorisation or agree another lawful solution. Objections may be made by replying to the notice or emailing info@bidfinance.pl. A website update alone is insufficient. A change in the structure or level of the chain shall not circumvent the notice, authorisation or responsibility obligations.
7.3. A direct new or replacement Subprocessor may not receive Entrusted Data until the direct-engagement period in section 7.2 expires without objection, or the Controller gives specific earlier written approval. An upstream change must satisfy the separate prior-information and effective-objection requirements in section 7.2. A timely objection prevents the disputed engagement while the parties assess a compliant alternative. If none is feasible, the affected processing shall be suspended or ended under section 13 with secure return/deletion. An urgent change does not bypass authorisation; BidFinance shall seek specific approval or protect the data by suspending the affected operation.
7.4. BidFinance remains responsible to the Controller for its Subprocessor's performance of the data-protection obligations under Article 28(4) GDPR. It shall keep the register current, make compliance information available and ensure relevant return/deletion instructions reach the whole chain. Any new commercial terms require separate agreement.
8. Locations, access and international transfers
8.1. Approved processing and storage locations, support access and actual onward transfers shall be recorded in Annex 3. BidFinance shall not initiate a transfer to a third country or international organisation without the Controller's documented instruction or authorisation and compliance with Chapter V GDPR, subject to section 5.2. Permission to use a Subprocessor is not by itself a transfer mechanism.
8.2. For each actual transfer, the parties shall identify the applicable adequacy decision and its scope or the specific safeguards used, such as the applicable standard contractual clauses, required assessment and supplementary measures. BidFinance shall supply the relevant information and copies, with justified redactions, and notify the Controller if safeguards can no longer be met. The affected transfer must then be suspended until a lawful solution is established.
8.3. This individually drafted DPA is not the Commission's standard contractual clauses and does not itself constitute a Chapter V transfer instrument. An EEA server location alone does not establish the location of support access. Annex 3 must distinguish actual transfers from other access scenarios rather than assume every foreign brand or travelling employee constitutes a transfer.
9. Assistance with individuals' rights
9.1. Taking into account the nature of processing, BidFinance shall assist the Controller, using appropriate technical and organisational measures insofar as possible, with requests under Chapter III GDPR, including finding and exporting relevant data and implementing authorised correction, restriction or deletion. It shall promptly forward requests relating to Entrusted Data to the contact in Annex 4 and preserve the date and scope received.
9.2. BidFinance shall not decide the Controller's substantive response or disclose data to a requester without instruction, except to comply with a binding legal duty. It may acknowledge receipt and direct the person to the Controller. It shall verify the authority of instructions and use a secure response channel. Assistance must be timely enough for the Controller to meet applicable deadlines; operational escalation and any agreed response targets are specified in Annex 4 and do not extend statutory time limits.
10. Incidents and assistance under Articles 32–36
10.1. BidFinance shall notify the Controller without undue delay after becoming aware of a personal-data breach affecting Entrusted Data. It shall use the incident contacts in Annex 4 and escalate by the agreed fallback if delivery or acknowledgement fails. It shall not wait for a complete investigation or apply the Controller's 72-hour authority-notification period as its own reporting allowance.
10.2. The initial notice shall contain the information then available: the nature and timing of the breach; affected systems and data; categories and approximate numbers of individuals and records where ascertainable; likely consequences; containment and mitigation steps; and a contact for follow-up. Missing information and its expected update shall be identified. BidFinance shall provide further information in stages without undue delay, preserve relevant evidence, contain the incident and cooperate on remediation.
10.3. Taking account of the nature of processing and information available to it, BidFinance shall assist the Controller with security assessment, breach documentation and notifications, DPIAs and prior consultation under Articles 32–36 GDPR. It shall provide relevant descriptions, risks, safeguards and investigation findings. The Controller determines notifications concerning its own processing; BidFinance remains responsible for duties directly imposed on it. This clause does not prohibit either party from making a legally required notification or cooperating with a supervisory authority. Where lawful, BidFinance shall coordinate and inform the Controller before such a disclosure.
11. Information, audit and accountability
11.1. BidFinance shall make available all information necessary to demonstrate compliance with Article 28 and this DPA and allow and contribute to audits, including inspections, by the Controller or an auditor it mandates. Information includes the relevant measures, Subprocessor arrangements, instruction/deletion records and incident response evidence. It shall maintain the records required of it under Article 30(2), where applicable, and cooperate with competent supervisory authorities.
11.2. The parties shall arrange a proportionate audit scope, secure access, confidentiality and reasonable advance notice, accounting for other customers' data and service continuity. Documentary evidence may be used first where sufficient. These arrangements must not make audit rights ineffective or prevent an urgent investigation, legally required inspection or necessary follow-up. No certificate is a complete substitute for the right to obtain adequate information.
11.3. Findings shall be documented and material gaps addressed promptly under a risk-based corrective plan with owners and dates. This standard form introduces no audit tariff, liability cap or automatic reimbursement obligation; existing agreed commercial terms apply only insofar as compatible with mandatory duties and effective exercise of these rights.
12. Return, deletion and remaining copies
12.1. When an instructed retention event or the end of the processing service occurs, the Controller shall choose either deletion of all relevant Entrusted Data or its secure return followed by deletion of remaining copies. BidFinance shall request that choice before the planned end, using Annex 4. The return format, secure delivery and permitted verification interval must be agreed without creating indefinite retention. A default deletion instruction may apply only if expressly selected in the executed Annex 4; an uncompleted template field is not such an instruction.
12.2. BidFinance shall complete the instructed return/deletion, including copies held by Subprocessors and backups, within the deadlines specified for the relevant data and copy classes in Annex 4, consistently with the applicable obligations under section 12.21 of the Terms and any binding agreement. The parties shall set practical steps and final dates before the relevant processing starts. A longer backup cycle may not be hidden behind a statement that live data was deleted; any permitted staged deletion requires an expressly agreed, lawful and bounded schedule. Annex 4 does not by itself extend an existing binding deadline.
12.3. Pending scheduled deletion, residual backup copies must be isolated, unavailable for ordinary use and accessed only for the agreed recovery need, subject to the same safeguards. If restored, the deletion/restriction instructions must be re-applied before normal use. The agreed final deletion deadline remains binding. A technical limitation is not itself a legal exception to deletion.
12.4. Retention contrary to the deletion instruction is permitted only where Union or Member State law requires storage. BidFinance shall identify the provision, data scope and period, notify the Controller unless legally prohibited, restrict access and processing to the required storage and delete when that obligation ends. A general possibility of future claims does not justify retaining the whole entrusted dataset. Any separate, necessary BidFinance controller record needs its own lawful basis, minimised scope and retention rule and is not created by relabelling a backup.
12.5. On request, BidFinance shall provide written confirmation of completion, including relevant Subprocessor confirmation, the data categories, dates and any specifically justified remaining legal exception. It shall not certify completed deletion before the agreed copies have actually been handled.
13. Inability to comply and termination
13.1. BidFinance shall promptly inform the Controller if it cannot comply with this DPA. The parties shall restrict the affected processing and agree a lawful remedial plan. The Controller may require suspension while compliance is restored and end the affected processing where the breach cannot be remedied or the lawful solution is not achieved within the agreed remediation period. Immediate action remains available where required by law or the severity of risk.
13.2. Ending or suspending processing does not release either party from protection, assistance and return/deletion obligations. The effect on the rest of the Service Agreement and any commercial settlement follows the applicable agreement and mandatory law; this DPA does not create new fees or change auction outcomes.
14. Relationship to other agreements and changes
14.1. Once expressly executed, this DPA governs the entrusted operations in Annex 1 and prevails over conflicting provisions on that processing within the agreed hierarchy of the Service Agreement and section 3.3 of the Platform Terms. Mandatory law and applicable standard contractual clauses retain their required precedence. Any existing separately signed agreement, DPA or express hierarchy must be identified in Annex 4. Its amendment or replacement requires express agreement identifying the affected provisions; publication or acceptance of a general website update does not silently replace it.
14.2. The parties shall record changes to this DPA and its scope in writing, including a binding electronic form. The agreed Subprocessor change process and ordinary documented operational instructions remain available within their scope. Instructions cannot unilaterally remove a safeguard or alter the agreed contractual hierarchy.
14.3. Governing law, dispute arrangements and any prevailing language follow the identified Service Agreement to the extent applicable and lawful. Any agreed resolution of an existing-contract conflict or language precedence shall be recorded in Annex 4 before execution. Invalidity of a provision does not excuse mandatory GDPR obligations.
15. Execution
Execution date and agreement identifier: [complete for this agreement]. Annex versions approved with this DPA: [approved annex versions]. The parties confirm that all required fields have been completed before signing.
| Controller | BidFinance / Processor |
|---|---|
| Legal name: [complete for this agreement] Representative and authority: [complete for this agreement] Signature / binding electronic acceptance reference: ____________________ Date: ____________________ | BidFinance sp. z o.o. Representative and authority: [complete for this agreement] Signature / binding electronic acceptance reference: ____________________ Date: ____________________ |
Annex 1. Processing specification and operation/role map
The parties complete this Annex for the agreed service, customer and portfolio before processing starts. Specify the workspaces/portfolios, source, data and data-subject categories, authorised recipients and necessity. The examples below identify possible agreed scope; they do not authorise every listed category. Do not insert actual debtor records into this standard form.
| Operation / purpose | Data and individuals | Role, permitted action and limit |
|---|---|---|
| Customer-controlled portfolio preparation and confidential document storage | Where needed: debtor/guarantor identifiers and contact details, contractual and claim references, balances, repayment/default information and relevant documentary evidence. Individuals: debtors, guarantors and natural-person parties/representatives named in the approved documents. Exact fields and excluded data: [customer-specific agreed scope]. | Controller decides scope and purpose; BidFinance stores and handles only on its behalf. Access is limited to the designated staff/recipients, with an approved anonymisation or pseudonymisation stage. |
| Auction materials and VDR display, questions, correction and export | Approved document content and necessary metadata; persons named in documents and correspondence only to the extent relevant. Exact workspaces, users and recipient categories: [customer-specific agreed scope]. | Processor only for identified entrusted operations. Buyer-facing files required to be anonymous remain anonymous; personal-data disclosure requires a separate authorised confidential route and satisfaction of banking-secrecy rules. No blanket access. |
| Technical maintenance, recovery, instructed deletion and approved scanning of entrusted files | Entrusted content, limited metadata and copies strictly needed for the operation. File scanning may involve the entire uploaded file. | Processor task only within approved safeguards, locations and Subprocessors. Recovery does not create a new purpose or extend the agreed retention period. |
| BidFinance's own company-representative relationship, authentication, Account administration, its own service security and necessary legal records | Necessary representative, authentication, activity and limited evidence data, as specified in the Privacy Policy. | Separate controller operations where BidFinance actually determines its own purposes. Not blanket authority to reuse entrusted content. The same person may be present in both distinct operations. |
| Buyer/seller/adviser receives data for its own transaction decision or legal duty | Only the specifically authorised disclosure; categories and receiving controller: [customer-specific agreed scope]. | Determine the recipient's own role and basis separately. It does not become BidFinance's Subprocessor merely by using the Platform. |
Frequency: ongoing only during the approved workspace/service operations; one-off export or deletion as instructed. Article 9/10 data: excluded unless an express annex identifies categories, legal conditions and enhanced measures. Geographic scope, volume and vulnerable-person risks: [customer-specific agreed scope]. Processing start/end and intermediate retention events: Annex 4.
Annex 2. Technical and organisational measures
For the processing specified in Annex 1, BidFinance shall implement and maintain the measures below in accordance with section 6 and Article 32 GDPR. The parties shall specify any additional measures and the operational parameters necessary for that processing in the security specification identified below before the relevant processing begins. The measures shall be proportionate to the data, authorised operations and risks. This annex does not establish a certification, guaranteed recovery time or particular encryption-at-rest configuration unless expressly specified in the agreed security specification.
| Control area | Contractual requirement |
|---|---|
| Authentication and credentials | Identify authorised users, protect authentication credentials, prevent unauthorised access and revoke access when no longer authorised. Specify any required multi-factor authentication and privileged-access conditions for the agreed processing. |
| Access control and separation | Limit access to the persons, purposes and operations authorised for the service. Apply least privilege, appropriate separation of customer workspaces and checks on file access. Review access rights and control administrative or support access. |
| Transmission and session protection | Protect personal data and credentials in transmission; secure authenticated sessions and protect against unauthorised or forged requests. Specify any additional encryption, key-management and interface requirements appropriate to the processing. |
| File handling | Restrict permitted file operations and apply the file-security checks agreed for the service. Where a scanning service receives Entrusted Data, identify its scope and provider in Annex 3 and limit its access, retention and use to the authorised purpose. |
| Availability, recovery and copies | Protect the availability, integrity and resilience of the agreed service and its recovery copies. Maintain recovery arrangements appropriate to the risk, restrict access to copies and evaluate recovery capability. Record any agreed recovery objectives, verification frequency and copy-deletion deadlines in the security specification and Annex 4. |
| Logging and accountability | Record the security and access events necessary for the agreed processing, protect logs from unauthorised access and alteration, and limit their content and retention to the defined purpose. Distinguish the customer's document/workflow evidence from BidFinance's separate, minimised controller records. |
| Personnel and incident management | Authorise personnel on a need-to-know basis, ensure confidentiality, provide instruction appropriate to their duties and maintain the incident communication and escalation arrangements in Annex 4. Assess relevant vulnerabilities and changes, address identified risks and regularly evaluate the effectiveness of the measures. |
| Minimisation, return and deletion | Process only the agreed data scope, control exports and recipients, and carry out authorised correction, restriction, return and deletion under section 12 and Annex 4. Include relevant copies and Subprocessors; reapply restrictions and deletion instructions after restoration before ordinary use resumes. |
Agreed security specification: [document identifier and version]. Relevant systems and processing scope: [identify]. Additional measures and agreed review/recovery parameters: [specify or refer to the completed specification]. Responsible contacts and approval date: [complete for this agreement]. Confidential security evidence may be supplied through an agreed secure channel; credentials and actual customer records shall not be included in this annex.
Annex 3. Approved Subprocessor and transfer register
Before the relevant entrusted processing, the parties complete and approve this register with the actual legal entities, operations, locations and safeguards for that customer’s data. Only completed and authorised entries constitute the initial approved list under section 7.1. Services used solely for BidFinance’s separate controller operations are outside this customer Subprocessor register. A service category or brand alone is not approval of an unidentified entity.
| Service / approved legal entity | Entrusted task and data | Storage, processing and support locations | Binding processing terms, onward chain and transfer safeguards |
|---|---|---|---|
| Application/database hosting — [legal entity] | [agreed databases, data categories and necessary logs] | [storage and access countries] | [agreement/version, onward chain and applicable safeguard] |
| File storage/recovery — [legal entity] | [agreed files, metadata and recovery copies] | [storage and access countries] | [agreement/version, onward chain and applicable safeguard] |
| File security/scanning, where engaged — [legal entity] | [file content/metadata, purpose, retention and reuse restrictions] | [processing and access countries] | [agreement/version, onward chain and applicable safeguard] |
| Other services processing this customer’s Entrusted Data — [legal entity/service] | [exact instructed task, content and permitted access] | [processing and access countries] | [agreement/version, onward chain and applicable safeguard] |
Approved register version/date: [version and date]. Authorised parties and approval reference: [details]. Changes follow section 7 and the contacts in Annex 4. Empty fields do not authorise access. EEA storage alone does not establish the location of all support or operational access.
Annex 4. Instructions, contacts and exit arrangements
| Agreement item | Customer-specific instruction / agreed value |
|---|---|
| Service, portfolio/workspace references; existing contracts and hierarchy | [identify the applicable agreement, service/workspaces, versions, any existing DPA and express replacement or amendment; no automatic replacement] |
| Controller’s authorised contacts and notice delivery | [name/role, controlled email, authority scope and agreed fallback channel; procedure for verifying contact changes] |
| BidFinance contact and escalation | BidFinance’s owner coordinates privacy, incident matters and Subprocessor objections through info@bidfinance.pl. Any customer-specific escalation channel or agreed coverage: [details, if agreed]. |
| Instruction record and rights-request assistance | [authorised Platform/email channel, instruction reference, responsible contacts and agreed response/escalation arrangements consistent with statutory deadlines] |
| Subprocessor notice | Direct Subprocessor changes: 14 calendar days beginning on the day after delivery of the complete notice. Upstream changes: information without undue delay after receipt and before the affected processing, with a real opportunity to object; no uniform 14-day upstream term. Section 7.2 governs prevention/suspension, specific prior approval and lawful alternatives. Objections: reply to the notice or info@bidfinance.pl; handling is coordinated by BidFinance’s owner. The chain must not be restructured to bypass these obligations. |
| Scope and access | [exact document/data fields, start event, authorised users/recipient categories, anonymisation stage, secrecy safeguards and any separately agreed Article 9/10 processing] |
| Intermediate retention events | [retention event and period for each agreed workspace or document category; identify necessary evidence separately] |
| Exit choice, format and deadlines | [choose secure return followed by deletion OR deletion; specify export format/channel, verification interval and deadlines for active data and each copy class, consistent with section 12.2 and applicable binding obligations] |
| Express default exit instruction | [if agreed: deletion after a defined request/response process, or another lawful and bounded instruction]. An uncompleted field is neither an automatic deletion instruction nor permission for indefinite retention. |
| Backups, Subprocessors and legal exceptions | [applicable copy classes and cycles, restricted recovery, reapplication of erasure/restriction after restore, final deletion deadlines and evidence; identify any mandatory-law retention exception by law, data, period and controls] |
| Governing contract and language | [identify applicable contractual law/dispute provisions and any agreed prevailing language; record explicit conflict resolution where required] |
Approval by authorised representatives: [date, names/roles and signature or binding electronic approval reference]. The parties complete and approve the required customer-specific fields and annexes before the relevant processing; publication or download of this standard form does not constitute that approval.