Data Processing Agreement

1. Parties and roles

The customer (the employer using OurTimetable) is the controller. Qfile B.V. is the processor and processes personal data solely on the instructions of, and on behalf of, the customer.

Details of the processor:

• Name: Qfile B.V.
• Address: Europalaan 40, 3526 KS Utrecht, the Netherlands.
• Chamber of Commerce (KvK) number: 97758388.
• Contact for this agreement: Qfile B.V., info@ourtimetable.com.

2. Subject matter and duration

The subject matter of the processing is the provision of OurTimetable: online workforce planning with which the customer builds rosters, records worked hours, administers leave and absence, manages availability and competencies, and produces an export for payroll processing.

The processing lasts for as long as the customer uses the service and ends in accordance with Article 15 (return or deletion). The term follows the term of the underlying agreement between the parties. Provisions that by their nature continue, such as confidentiality and deletion, remain in force afterwards.

3. Nature and purpose of the processing

The processor processes personal data for the purpose of providing and securing the service. This covers:

• planning and publishing rosters, open shifts, base schedules and swap requests;
• recording and correcting worked hours, including through a kiosk or time clock;
• requesting, reviewing and administering leave;
• recording sickness and recovery reports for roster planning and absence support;
• maintaining availability, contract hours, competencies and their expiry dates;
• monitoring rest periods, working times and premium windows based on the collective labour agreement rules configured by the customer;
• producing a period export of hours, days and kilometres per employee for the payroll processing of the customer;
• sending notifications and messages to employees, by email or as a push message;
• providing access based on roles and locations, and recording changes in an audit log;
• securing the service, making backups and providing support.

The processor does not use the data for its own purposes, does not sell data and does not use it for advertising or profiling.

4. Categories of data subjects and personal data

Data subjects are the people whose data the customer enters: the employees of the customer (both own staff and flexible pool, self-employed and agency workers), the administrators and planners who operate the service, and the emergency contact given by an employee.

Categories of personal data that are processed, depending on what the customer fills in and which parts of the service the customer uses:

5. Special category: absence and health

OurTimetable records sickness reports. The fact that someone is ill, and equally the support details that go with it, is data concerning health and therefore a special category of personal data within the meaning of Article 9 GDPR. Processing is prohibited unless an exception under Article 9(2) GDPR applies. In practice, processing by the customer as employer rests on Article 9(2)(b) GDPR in conjunction with Article 30(1)(a) of the Dutch GDPR Implementation Act: processing that is necessary for the reintegration or support of employees in connection with sickness or incapacity for work.

As controller, the customer is responsible for ensuring that no more health data ends up in the service than the law allows. The Dutch Data Protection Authority permits an employer to record that someone is ill and when, but not the nature of the complaints, the diagnosis or the treatment. The processor does not merely point this out: the free-text field on a sickness report has been removed from the service, so there is no longer anywhere for a reason for illness to end up.

The processor applies the following specific safeguards:

• A sickness report no longer has a free-text field. Besides the start and end date and the person who reported it, the service records only four support details, each drawn from a fixed list: the expected duration (unknown, a few days, one to two weeks, longer than two weeks), whether the employee can be reached, whether (adjusted) work is possible, and the date of an agreed contact moment. A complaint, a diagnosis or a treatment cannot be written down there, not even by accident.
• The support details are stored encrypted (AES-256-GCM), as are the date of birth, the bank account number, the telephone number, the address, the postcode and the details of the emergency contact. These are the fields with dedicated field-level encryption, precisely because they are the most sensitive.
• A retention period of two years applies to the support details, counted from the end date of the sickness report or, for a report still open, from its start date. The sickness report itself remains as a bare period, so the absence history stays correct without retaining the content. Article 13 sets out the floor and how the clean-up works.
• Notes entered before the free-text field was withdrawn are no longer returned: that content does not leave the server, not even to HR. The customer can have them counted and erased in a single action; the sickness report itself remains.
• Free-text notes on a shift and on a swap request are also erased after two years, because health context can end up there unintentionally.
• Access to absence data runs through the roles and the per-location restriction of Article 8: a manager only sees the locations that the administrator has assigned to them.
• Every change to an absence record is written to the audit log, so it can be established afterwards who changed what and when.

6. Data the service deliberately does not process

OurTimetable is a planning tool, not a payroll administration. Two categories are therefore deliberately and structurally excluded:

• The Dutch citizen service number (BSN) is not processed. There is no field for it, and the integration with a personnel system rejects this category outright, even if an administrator wanted to enable it.
• The salary, hourly wage or pay scale amount per employee is not processed. This category is likewise hard-blocked in the integration. The service does calculate with an hourly rate per resource class (own staff, flexible pool, self-employed, agency worker) for cost estimates, but that is a rate per class and not the pay of an individual.

If the customer nevertheless wishes to record such data, it belongs in the payroll administration or the personnel file and not in a free-text field of this service.

7. Instructions of the controller

The processor processes the personal data solely on the documented instructions of the customer, including this agreement and the normal use of the service. The processor does not process the data for other purposes, unless required to do so by law; in that case the processor informs the customer beforehand, unless the law prohibits this. If the processor considers an instruction to infringe the GDPR or other data protection law, it informs the customer.

This processing on documented instructions applies, pursuant to Article 28(3)(a) GDPR, also to the transfer of personal data to a third country or an international organisation: the processor transfers personal data only on a documented instruction of the customer, unless required to do so by Union or Member State law to which the processor is subject. In that case the processor informs the customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

8. Security measures

The processor takes appropriate technical and organisational measures within the meaning of Article 32 GDPR. The measures currently in place are:

• Separation per organisation. Every record carries the organisation it belongs to, and a guard in the data layer refuses any query that lacks that scoping. On top of that, the service can run each customer environment in a physically separate database, with its own encrypted connection setting per customer; if an environment is unknown, the request is refused rather than falling back to a shared database.
• Encryption at rest of the sensitive fields with AES-256-GCM: date of birth, bank account number, telephone number, address, postcode, the name and telephone number of the emergency contact, and the support details on a sickness report. A boot gate checks on every start whether a new text field has been added to the employee record without being classified; if so, the service does not start. A new field therefore cannot silently remain unencrypted. The GCM authentication tag makes any tampering with a stored value visible, and a key rotation path exists in which old and new keys coexist.
• A key per organisation (available). The service supports a dedicated data encryption key per customer, itself stored encrypted under a master key and binding the organisation identifier as additional authenticated data. A field of one customer is then unreadable with the key of another, and destroying that key renders the associated data irrecoverably unreadable. This mode is enabled per environment; customers can ask us which setting applies to their environment.
• Passwords are never stored in readable form but as a hash. Email addresses are additionally indexed with a keyed HMAC, so that an address can be searched for without having to decrypt it.
• Two-factor authentication with a one-time code (TOTP) and recovery codes, both stored encrypted, plus support for passkeys. The administrator can make two-factor authentication mandatory for HR and administrator roles.
• Encryption in transit through HTTPS with TLS and automatically renewed certificates.
• Sessions run through a cookie that cannot be read by JavaScript and that is tied to a session record in the database, so a session can be revoked immediately and server-side. A session expires after seven days.
• Role-based access (employee, self-employed, manager, planner, HR, administrator, kiosk) with a fixed permission scheme. The right to view the personal data of employees is a separate permission that the manager role deliberately does not hold; it is reserved for HR and the administrator. The permissions for administration and for configuring integrations cannot be widened through a temporary grant.
• Per-location restriction: a manager only sees the locations expressly assigned to them, and without an assignment sees nothing beyond their own data. The service currently has no further restriction per department: within their permissions and locations, a user can see across departments.
• Rate limiting and account lockout on sign-in, two-factor authentication, password recovery and passkey traffic, to slow down guessing and abuse.
• Audit log with a hash chain. Every change produces a row with the old and the new value. Each row contains a hash over the preceding row and over its own immutable fields, plus an HMAC seal. This makes it demonstrable afterwards that no row has been removed or altered. For a decision explicitly confirmed by a person, such as approving leave or releasing a payroll export, a separate sealed attestation is recorded as well.
• Security events (failed sign-in attempts, denied access, exceeded rate limits) are recorded separately and deliberately sparsely: only the event type, a non-identifying actor identifier, the route and the source IP address, never names, email addresses or content.
• Backups. The databases are backed up in encrypted form, with a copy in a separate location. Restores are tested periodically, comparing the restored content against the original by checksum.
• Hosting on a server at TransIP in the Netherlands, within the European Union.

The processor may adjust these measures as long as the level of security is not reduced.

9. Confidentiality

The processor ensures that the persons under its authority who have access to the personal data are bound by confidentiality, either by a statutory duty of confidentiality or by contract. Access is limited to what is necessary for the performance of their duties.

10. Engaging sub-processors

The customer gives the processor general authorisation to engage sub-processors for the provision of the service. The processor imposes on each sub-processor at least the same obligations as set out in this agreement. The current list is:

In addition there are two connections that do not run from our server but from the device of the user. They belong here for completeness:

• Push messages. If an employee turns on push notifications, delivery runs through the push service of their own browser or operating system (for example Google, Mozilla or Apple). The content of the message is end-to-end encrypted and readable only by the device itself; the push service sees the subscription endpoint and the time, not the content. By design, push messages never contain names, health data or pay data.
• Voice input (optional). If someone uses voice input, their browser downloads the speech recognition model once from Hugging Face and a public software archive. The speech itself and the recognised text never leave the device: recognition runs entirely in the browser. Anyone wishing to avoid this connection can simply not use voice input.

The roster assistant and the planning suggestions in OurTimetable run entirely on our own server and are deterministic: no data is sent to an external language model or AI service. There is therefore no AI sub-processor. Should the processor engage an external service for this in future, it will be added to this list beforehand.

The processor informs the customer in advance when it intends to add or replace a sub-processor. The customer may object within a reasonable period. If the parties cannot reach agreement, the customer may terminate the service for the part to which the objection relates.

Where an engaged sub-processor fails to fulfil its data protection obligations, the processor remains fully liable to the customer for the performance of that sub-processor obligations pursuant to Article 28(4) GDPR.

11. Assistance with data subject rights

Data subjects exercise their rights with the customer: access, rectification, erasure, restriction, objection and data portability. The processor assists the customer, insofar as possible and by appropriate technical and organisational measures, in meeting those requests. If the processor receives a request directly from an employee of the customer, it does not respond independently but refers the person to the customer or passes the request on to the customer.

Taking into account the nature of the processing and the information available to it, the processor additionally assists the customer pursuant to Article 28(3)(f) GDPR in complying with the obligations under Articles 32 to 36 GDPR, including assistance with data protection impact assessments (DPIA) and with prior consultation of the supervisory authority.

The service contains two built-in tools for this. For the right of access under Article 15 GDPR, HR or the administrator can compile in a single action a file containing all data the service holds about one person, decrypted and in one place; that action is itself written to the audit log. For the right to erasure, the customer can configure that the data of an employee who has left is anonymised automatically after a chosen number of years: everything not needed for the aggregated history is emptied or replaced, the free-text notes on absence, shifts, swap requests, leave and clock entries are erased, and sessions, push subscriptions, passkeys and two-factor data are deleted. This automatic anonymisation is switched off by default, so nothing happens unless the customer deliberately enables it.

12. Personal data breaches

If the processor becomes aware of a personal data breach, it informs the customer pursuant to Article 33(2) GDPR without undue delay and in any event within 48 hours of becoming aware, so that the customer as controller can meet the notification deadline to the Dutch Data Protection Authority within 72 hours and, where necessary, inform the data subjects.

The notification contains at least: the nature of the breach, the categories of data and the number of data subjects concerned as far as known, the likely consequences, the measures taken and proposed, and a contact point. Where information is not yet available, the processor first reports what is known and supplements it later. The processor assists in the assessment and handling.

13. Retention periods

The processor retains the data on behalf of the customer and no longer than necessary. The service has a retention engine that applies a period per category. The customer may adjust a period per category within the recorded floor; shorter than the floor is not possible.

Automatic clean-up is switched off by default. As long as the customer does not enable it, the engine only writes a proposal to the log containing the counts and the legal basis, and nothing is deleted. Nothing therefore ever disappears unnoticed. Cleaning up a category happens in a single transaction together with the corresponding part of the audit log: if anything fails, the entire category is rolled back.

For data on employees who have left, the customer as employer remains responsible for its own statutory retention periods, such as the Dutch tax retention obligation of seven years for payroll administration.

14. Audit and duty to provide information

The processor makes available to the customer the information necessary to demonstrate compliance with Article 28 GDPR. The customer may, at most once a year and at its own expense, have an audit carried out, provided this is announced in advance and with reasonable notice and does not unnecessarily disrupt operations or confidentiality towards other customers. The processor may refer to available reports or statements evidencing the measures taken.

15. Return or deletion at the end of the agreement

The periods in this article apply on closure of the environment: the agreement ends as a whole and the environment ceases to exist. They do not apply where a paid plan is merely cancelled. On cancellation the environment falls back to the free plan, the data simply stays in place and nothing is deleted; Article 5 of the terms and conditions applies there, with the 14 day period that concerns the old plan ceiling only. Both concepts are defined in Article 1 of those terms.

After closure of the environment it remains available for 60 days for retrieving and exporting the data. Rosters, hours, leave and the payroll export can be downloaded as files during that period.

After the end of the provision of services, all personal data is, at the choice of the customer as controller, deleted or returned to the customer pursuant to Article 28(3)(g) GDPR, and existing copies are deleted, unless storage is required by Union or Member State law. Data in secure backups is permanently removed within 30 days after the personal data has been deleted or returned in accordance with this article.

For the fields encrypted with a dedicated key per organisation, destruction of that key can be used: the associated data is then irrecoverably unreadable, including in a backup that technically still exists.

16. International transfers

The personal data is stored and processed within the Netherlands and the European Union. Transfer to a country outside the EU or the EEA only takes place where an appropriate safeguard applies, such as an adequacy decision or standard contractual clauses. At present no personal data is transferred outside the EU or the EEA.

17. Liability

The liability regime of the terms and conditions applies to this agreement, as set out on the liability page. Pursuant to Article 82 GDPR, a processor is liable for damage caused by processing only where it has not complied with obligations of the GDPR specifically directed to processors, or where it has acted outside or contrary to lawful instructions of the controller.

18. Changes and contact

The processor may amend this agreement when the service, the applicable law or the engaged sub-processors change. The current version is always on this page, with the date of last amendment at the top.

Questions about this data processing agreement? Contact Qfile B.V. at info@ourtimetable.com.