priceq data processing agreement

Form: the standard contractual clauses of the European Commission, with completed annexes.

About this agreement

The European Commission has adopted model clauses for the relationship between controller and processor: Implementing Decision (EU) 2021/915 of 4 June 2021, on the basis of article 28(7) GDPR. We adopt those clauses in full instead of drafting our own.

That means two things for you. The clauses have been adopted by the Commission itself and therefore comply with article 28. And your legal department will recognise the text and does not have to assess it line by line.

The substantive work is in the annexes. The decision requires the security measures to be described concretely; a general description does not suffice. Annex III is therefore a description of what the system actually does.

The agreement

Parties

Article 1: What applies

The standard contractual clauses in the annex to Implementing Decision (EU) 2021/915 apply in full to the processing of personal data that the processor carries out on behalf of the controller. Those clauses form part of this agreement as if they were set out here in full.

Article 2: Choices within those clauses

• Engagement of sub-processors (clause 7.7): general written authorisation. The processor keeps the list in Annex IV up to date and notifies any intended change at least thirty days in advance. The controller may object within that period; if the parties fail to reach agreement, the controller may terminate the agreement with effect from the date on which the change takes effect.
• On termination of the processing (clause 8.5): the processor deletes the personal data, unless the controller requests their return in writing before the end of the agreement. A full export can be retrieved by the controller at any time in the application.
• Notification of a breach (clause 9): the processor notifies a personal data breach without undue delay and at the latest within 24 hours after becoming aware of it, with the information available at that time; missing information follows as soon as it is available.
• Governing law and forum (clauses 12 and 13): Dutch law, competent court: Rechtbank Noord-Holland (the District Court of Noord-Holland, the Netherlands).

Article 3: Audits (clause 7.6)

The controller may verify compliance. This is done in the first instance on the basis of the information supplied by the processor. An on-site inspection is possible, at most once a year, announced with reasonable notice, during office hours and in such a manner that the service is not disrupted for other customers. The costs of an inspection that does not demonstrate a shortcoming are borne by the controller.

Annex I: Parties

This agreement is not signed by hand. It is concluded at the moment the customer accepts it when signing up. We record which document, which version, the fingerprint (SHA-256) of the text as it was shown at that moment, the time, the IP address and the browser. Anyone who wants their own signed copy can request it through the contact address at /legal/bedrijfsgegevens.

Annex II: Description of the processing

Data subjects

Employees of the controller who have an account in the application, and persons whom the controller contacts on behalf of the organisation via the application.

Categories of personal data

• Name and business e-mail address
• Role within the organisation (administrator, supervisor, employee, reader)
• An Argon2id-hashed representation of the password, and a version number by which a session can be revoked
• Personal settings: language, display, which alerts a person receives
• In the audit log: user ID, time, action, IP address and browser, and the data the action concerned, such as the e-mail address of the person invited
• Time and IP address of the most recent login
• Whether e-mail to a person's address bounced: the time and the reason the receiving mail server gave

Special categories

None. The service is not set up for them and there is no field in which they fit.

What is expressly not personal data

The prices, availability and product designations retrieved from public shop pages, and the catalogue supplied by the customer. Those are market and product data. They do not fall under this agreement and are mentioned here only to prevent misunderstandings.

Nature and purpose of the processing

Granting access to the application, assigning rights, sending the alerts and overviews that the user sets up, securing the service (login restriction, session management, audit log) and resolving malfunctions.

Duration

For the duration of the agreement. After termination, personal data is anonymised upon closure of the file, no later than thirty days after termination. If an administrator of the controller requests deletion himself in the application, a cooling-off period of thirty days first applies, during which the account keeps working and the request can be withdrawn; after that the data is erased. Earlier erasure takes place at the express request of the controller.

The audit log follows its own period: each entry is deleted automatically twelve months after it was written, even if the agreement ended earlier. Until that moment the personal data in it is retained, because the log serves precisely to establish afterwards what has happened.

Frequency

Continuous, for as long as the application is used.

Annex III: Technical and organisational measures

Described concretely, as the decision requires.

Separation between customers The database enforces per row to which customer a data item belongs (row-level security), on every table with customer data, with one deliberate exception: the tables holding user accounts and one-time codes for invitations and password recovery. Those are looked up by e-mail address at login, before it is known which customer a person belongs to. There the application safeguards the separation: every account belongs to exactly one customer, and the application looks accounts up by the customer number or user number from the logged-in session, never by a number from the request. The application filters explicitly in addition, and on every change the build pipeline runs a test that attempts to retrieve the data of another customer; if that attempt succeeds, the change does not go through. The application runs with a database role that cannot circumvent this separation. Cache keys and storage paths are separated per customer as well.

Access and authentication Passwords are stored hashed with Argon2id. Two-factor authentication is available. Passwords are checked against known leaked passwords when they are set. Repeated failed login attempts are blocked. Sessions can be revoked immediately per user. Rights are divided into four roles; the most far-reaching actions (full export, changing the subscription, deleting an account) are reserved for an administrator.

Looking along in the customer's account For support purposes, an employee of the processor can see the application as the customer sees it. That is possible only from his own logged-in account (not with a system key) and only after he has entered a reason. That reason is recorded and shown to the customer. Such a session is read-only: the server refuses every action that changes anything, whichever screen the employee opens. It lasts thirty minutes and cannot be extended; anyone who needs longer starts again and records a reason again. In the log the employee remains himself: what he does is never attributed to an employee of the customer. Four screens stay closed during a look-along as well: the list of team members, the activity log, the full export and the API keys.

Confidentiality in transit and at rest All traffic runs over TLS. The servers are not directly reachable from the internet. Backups are stored encrypted.

Availability and recovery Every night a full backup is made and written encrypted to object storage, in paths separated per customer. The encryption takes place before writing, so that the storage provider receives ciphertext only. The recovery procedure is documented and is tested; the date and outcome of the last test are available on request.

Logging and auditability Actions relating to accounts and access (inviting someone, withdrawing an invitation, changing a role, deactivating or reactivating an account, and an employee of the processor starting to look along) are recorded in an audit log that the application cannot modify or delete. That restriction is enforced at database level: the application has no right to modify or delete rows in the log. Entries that are twelve months old are deleted by a separate maintenance task with its own database role. The customer can view the log himself in the application.

The entry for a look-along session states the reason, the time and the moment at which the access expires, and it is written before the access is granted: if that write fails, no look-along takes place. A look-along session without an entry in the log therefore does not exist.

Security of development Source code is held in a private repository. On every change, automated checks run for secrets in the code, known vulnerabilities in dependencies, and the separation test mentioned above. Secrets are held in a key vault and not in the code.

Error monitoring The application reports errors to an external service in the EU region. It is configured so that no personal data and no content of requests are transmitted.

Access to production Limited to the administrator of the processor, over a private network, with key authentication. Actions carried out directly on the production environment are recorded afterwards.

Deletion When an account is terminated, user data is anonymised and all keys and tokens are deleted. The audit log is not altered in the process: the entries remain with the personal data they contain (user ID, IP address, browser and, for example, the e-mail address of a person invited) until they are twelve months old and are deleted automatically.

Annex IV: Sub-processors

Parties that may process personal data in the course of performance:

The same sub-processors are listed, with more detail per party, in the sub-processor list.

Fingerprint of this text (SHA-256): 9c211b4f5d0ad0c294bbb492945b0a31997ca8780ed0f730372939251ef16799