Data processing agreement

1. Parties, roles and duration

Customer / instructing party: [CUSTOMER LEGAL NAME], [CUSTOMER ADDRESS], [CUSTOMER COMPANY NUMBER], represented by [NAME AND ROLE]. Privacy contact: [CUSTOMER PRIVACY CONTACT]. The customer is the controller for the supplied personal data, or a processor acting for a controller that has authorised this further processing.

Supplier / processor: [LEGAL NAME], trading as anonimize, [STREET, NUMBER, POSTCODE, MUNICIPALITY, COUNTRY], [COMPANY NUMBER], [VAT NUMBER, IF APPLICABLE], represented by [NAME AND ROLE]. Privacy and security contact: [PRIVACY EMAIL], [SECURITY EMAIL] and [PHONE NUMBER].

This agreement governs the processing of document content and associated personal data for the service in Annex A. When the customer is itself a processor, these obligations also apply as subprocessing arrangements; the customer is responsible for its authority to pass on instructions. Terms such as personal data, data subject and breach have their GDPR meanings.

The agreement applies from recorded acceptance for as long as the processor processes personal data on the customer's behalf, including the agreed winding-down period after termination. It takes precedence over conflicting commercial provisions about this processing. Independent purposes for account management, billing or legally required administration fall outside this processing scope and must be addressed separately, transparently and lawfully.

2. Documented instructions and confidentiality

The processor processes personal data solely for the scope in Annex A and the customer's documented instructions. These include confirmed settings, actions by authorised users and additional instructions agreed in writing. Instructions for transfers to third countries must separately comply with Chapter V GDPR. The processor does not use document content for advertising, sale or training its own or external models.

If Union or Member State law requires processing, the processor informs the customer of that legal requirement before processing, unless that law prohibits this on important public interest grounds. The processor immediately informs the customer if, in its opinion, an instruction infringes the GDPR or other applicable data protection rules. The parties clarify or correct that instruction; the affected processing is suspended where necessary.

Only people who need the data for the processing assignment receive appropriate access. They are bound by contractual or statutory confidentiality obligations, receive appropriate instructions and process the data under the processor's authority. Confidentiality continues after their work ends. Support is not automatically authorised to view document content.

3. Security and assistance to the customer

The processor implements appropriate technical and organisational measures under Article 32 GDPR, taking into account the risk, nature and context of processing, the state of the art and implementation costs. Annex B describes technical capabilities and operational matters to establish before processing. The required level includes confidentiality, integrity, availability, resilience and appropriate restoration after an incident. The effectiveness of the measures is assessed regularly.

The processor does not reduce the agreed security level without prior agreement. A measure may be replaced by a demonstrably equivalent or stronger measure. The processor reports relevant changes needed by the customer for its risk analysis. A source code description does not confirm that all measures are enabled in a specific hosting environment.

Taking account of the nature of processing and the information available, the processor assists with requests for access, rectification, erasure, restriction, portability or objection. A request received directly is forwarded to the customer's privacy contact without undue delay. The processor does not independently respond on the customer's behalf unless instructed to do so or required by law.

The processor provides available technical information and reasonable assistance in a timely manner for the customer's obligations under Articles 32 to 36 GDPR, including security, breach notification, data protection impact assessments and prior consultation with the supervisory authority. Where needed, the parties establish a secure channel, contacts and a response period suited to the statutory deadline. Any fee agreed in advance for exceptional additional support must not prevent or delay statutory assistance.

4. Subprocessors and international transfers

The customer grants general authorisation for the subprocessors identified in Annex C and their described activities only after completion and written or electronic acceptance. A listed brand or outstanding field does not constitute authorisation for an unknown legal entity. The list always states the name, role, country of establishment, processing locations and relevant transfers.

Before adding or replacing a subprocessor, the processor informs the customer directly in writing, with sufficient details and a reasonable period for a substantive objection: [NOTICE AND OBJECTION PERIOD — COMPLETE BEFORE ACCEPTANCE]. The new subprocessor receives no access before this procedure is completed. An objection on data protection grounds is examined together. If no suitable solution is possible, the customer may terminate the affected processing or part of the service before deployment, without charges for future periods that will no longer be supplied.

The processor concludes a binding agreement with each subprocessor imposing the same relevant data protection obligations, including appropriate security. It verifies the safeguards offered and remains responsible to the customer for the subprocessor's performance of its obligations. On request it provides information needed to assess this chain, while protecting other confidential data.

Transfers or access from countries outside the EEA take place only on documented instructions and with a valid basis under Chapter V GDPR, including the required assessment and supplementary measures. A server location in the EEA does not by itself exclude access from other countries. To the extent legally permitted, the processor reports government requests for data and provides only what is lawfully required.

5. Personal data breach notification and response

The processor notifies a personal data breach without undue delay after becoming aware of it to [CUSTOMER INCIDENT CONTACT] through [SECURE REPORTING CHANNEL]. The reporting route and an escalation contact available outside office hours are confirmed before processing. Notification is not postponed until the investigation is complete.

To the extent known, the notification includes the nature of the breach; categories and approximate numbers of data subjects and records; the contact person; likely consequences; and measures taken or proposed to address the breach and mitigate adverse effects. Missing information follows in phases without undue further delay.

The processor immediately takes appropriate measures to contain the incident, investigate its cause and prevent recurrence. It preserves relevant information for investigation and assists the customer with assessment and any notifications to the supervisory authority and data subjects. The customer decides on its statutory notifications. The possible 72-hour period for a controller's notification to the supervisory authority is not a grace period for the processor to alert the customer.

6. Information, checks and audits

The processor makes available the information needed to demonstrate compliance with Article 28 GDPR. The customer or an independent auditor authorised by it may conduct appropriate audits and inspections. The parties agree on scope, safe execution and reasonable scheduling to protect other customers and confidential information.

An existing report or document review may be an initial means of verification but does not automatically replace a necessary inspection. A specific breach, indication of non-compliance or request from a supervisory authority may justify an expedited check. Any arrangements about costs, confidentiality or scheduling must not make effective exercise of this right impossible. Identified shortcomings are followed up with an appropriate remediation plan.

7. Retention periods, return and deletion

The customer determines retention and deletion instructions within the service. Results and reversal keys have separate configurable periods. The current default is no automatic deletion; deliberately choose a suitable period. Shorter settings may also expire existing content. The absence of an automatic period does not authorise retaining data longer than lawfully necessary.

At the end of service provision, the customer chooses either the return of still-available personal data in a usable agreed format followed by deletion, or direct deletion. The export window, deadline for active systems and deletion confirmation are completed before acceptance: [EXPORT WINDOW], [ACTIVE SYSTEM DELETION PERIOD] and [CONFIRMATION METHOD]. The processor also deletes its copies unless a specific statutory retention obligation prevents this. In that case, it reports the legal basis and remaining duration and limits use to that obligation.

Backups and snapshots require a separately established policy: [MAXIMUM BACKUP RETENTION], [SECURITY AND ACCESS], [DELETION PROCEDURE]. During an agreed winding-down period, personal data remains protected and is not used for ordinary service provision. On restoration, previous deletion instructions are reapplied. Automatic app cleanup does not itself erase existing backups or copies downloaded by the customer.

After completion, the processor confirms which data has been deleted and which remains restricted solely because of a statutory retention obligation or agreed backup expiry period. Confidentiality, security, audit information and statutory assistance continue for as long as personal data remains present.

Annex A — Processing instructions

Annex B — Technical and organisational measures

The technical operation below is based on the application code. The actual production setup and outstanding operational arrangements must be verified and completed before processing. The security page provides an accessible explanation.

• Processing on the application server. Presidio, spaCy and Tesseract perform detection, extraction and OCR within the application environment. Document text is not sent to an external generative AI service for this purpose. The original text does reach the server and is readable there during processing; processing does not take place solely on the customer's device.
• Encryption of stored content. The app uses Fernet for stored document results, reversal keys and project memory. This does not encrypt the entire database: account details and certain technical metadata remain server-managed. Production key management, access restrictions and backup protection: [TO BE CONFIRMED].
• Optional customer-managed vault key. When BYOK is enabled, the browser encrypts the designated stored content with AES-256-GCM. The server does not store the customer's key; authorised users must manage it securely themselves. Detection and OCR still see the source text on the server. This is not complete end-to-end encryption and does not protect against every risk from altered browser code or a compromised device.
• Separation and access. Organisation, workspace and document permissions are checked on the server. Users authenticate; passwords are hashed and sessions use an HttpOnly cookie. Two-factor authentication and restricted API permissions are available. Mandatory use, access reviews and administrator procedure: [TO BE CONFIRMED].
• Limiting source storage. Source files and complete source text are used for processing and temporary review and are not stored as permanent source files. With pseudonymisation, restorable original values may remain in the encrypted reversal key and project memory. Exact temporary processing periods and cleanup configuration: [TO BE CONFIRMED].
• Retention and deletion. Separate periods can be set for results and keys. Without configuration, automatic deletion is not active. Deletion of active data must be supplemented by the backup, export and snapshot arrangements in Article 7.
• Transport and infrastructure. HTTPS with a valid certificate, infrastructure access restrictions, network security, data volumes and secrets management must be configured and verified in production: [PRODUCTION CONFIGURATION AND RESPONSIBLE PERSON]. The intended infrastructure is listed in Annex C; a domain or source code setting does not prove that a live environment is correctly secured.
• Operational safeguards. The parties establish the patch and update policy, incident procedure, confidentiality arrangements, logging without unnecessary document content, recovery objectives, backup regime, restoration tests and periodic security evaluation: [POLICY, FREQUENCIES, CONTACTS AND EVIDENCE]. Without such evidence, no certification, penetration test, continuous monitoring or guaranteed recovery time is claimed.

Annex C — Infrastructure and subprocessors

Intended infrastructure: Zerops, region prg1, Prague, Czechia. This is the chosen setup; actual resources, contracting parties, access locations and backup settings still need confirmation. Region selection alone is insufficient to establish all legal and operational processing locations.

Payment services for account and billing data are not automatically part of the document processing assignment. Their precise role and processing must appear in the agreement and privacy information for those purposes. No document content or reversal keys are sent to the payment provider for billing.

Completion, changes and acceptance

The parties complete all placeholders and annexes and confirm the chosen version, their representatives, date and method of acceptance: [VERSION], [DATE], [AUTHORISED REPRESENTATIVES], [SIGNATURE OR ELECTRONIC ACCEPTANCE EVIDENCE]. An instructing party that is itself a processor also records its controller's authorisation.

Changes are communicated directly and agreed under the applicable written or electronic procedure; merely publishing new text on the website does not amend the agreement. The specific procedure for subprocessors appears in Article 4. Liability and disputes follow the terms and conditions and the law. This agreement does not restrict data subjects' rights, supervisory authorities' powers or GDPR obligations.

Official sources

Legal basis: GDPR, particularly Articles 28 and 32 to 36. Useful references for the contractual provisions include the European Commission's standard clauses for controllers and processors and the EDPB explanation of roles and processing agreements . This original draft is not an unchanged application of the standard contractual clauses and does not itself constitute a transfer mechanism.