Data Processing Agreement
Data processing agreement (art. 28 GDPR) with technical and organisational measures.
Draft: this document is still being reviewed by a lawyer. Text in [square brackets] is a placeholder that will be filled in before the final version.
DRAFT v0.1 (2026-10-23). Not legal advice. Based on GDPR art. 28. To be reviewed by a lawyer; consider aligning with the NL "Model Data Pro" format. Placeholders in [BRACKETS].
Parties
- The customer who has accepted the TimeTracking Terms of Service ("Controller" or "Customer"); and
- TimeTracking, 31, 6165 BH Geleen, KvK 84956526 ("Processor" or "TimeTracking").
This Data Processing Agreement ("DPA") forms part of the Terms of Service and is accepted together with them (click-through at sign-up). In case of conflict on personal data, this DPA prevails.
1. Definitions
Terms such as personal data, processing, data subject, personal data breach and supervisory authority have the meaning given in the GDPR (Regulation (EU) 2016/679). "Service" means the TimeTracking web app, mobile apps, kiosk, desktop app, browser extension, API and email ingestion.
2. Subject and instructions
2.1 Processor processes personal data only on behalf of Controller and only on Controller's documented instructions, as described in Annex 1. The configuration Controller sets in the Service (e.g. modules, GPS on/off, GPS retention period, approval mode, export mappings, AI features on/off) counts as documented instructions. 2.2 Processor informs Controller without delay if an instruction in its opinion infringes the GDPR. 2.3 Processor does not use Customer personal data for its own purposes, including training AI models, advertising or sale. Processor may use aggregated, anonymised statistics (e.g. number of entries, AI cost per document) to operate and improve the Service. 2.4 If EU or Member State law requires Processor to process otherwise, it informs Controller before processing, unless that law prohibits this.
3. Controller's responsibilities
Controller is responsible for: a lawful basis for the processing (including GPS/geofencing, for which consent of employees is generally not a valid basis); informing data subjects; a DPIA where required (template: dpia-gps-template.en.md); works-council consent where required (art. 27 WOR — kit: works-council-kit.en.md); and for setting retention periods that fit its legal obligations.
4. Confidentiality
Processor ensures that persons authorised to process the personal data are bound by confidentiality. Staff access to production data is limited to named persons, only for support (at Customer's request) or incident handling, and is logged.
5. Security
Processor implements the technical and organisational measures in Annex 2. Processor may update these measures provided the overall level of security is not reduced.
6. Personal data breaches
6.1 Processor notifies Controller of a personal data breach without undue delay, with a target of 48 hours after discovery, so Controller can meet its 72-hour duty to the supervisory authority (art. 33 GDPR). 6.2 The notification contains, as far as known: nature of the breach, categories and approximate number of data subjects and records, likely consequences, measures taken or proposed, and a contact person. Information may be provided in phases. 6.3 Processor documents all breaches, including those not notifiable. Processor does not notify supervisory authorities or data subjects on Controller's behalf unless Controller instructs so in writing.
7. Sub-processors
7.1 Controller gives general authorisation for the sub-processors listed in Annex 3. 7.2 Processor notifies Controller at least 30 days before adding or replacing a sub-processor. Controller may object on reasonable data-protection grounds within that period. If the parties cannot resolve the objection, Controller may terminate the affected Service without penalty and receive a pro-rata refund of prepaid fees. 7.3 Processor imposes the same data-protection obligations on each sub-processor and remains liable towards Controller for their performance.
8. International transfers
Processor stores Customer data in the EU/EEA. Transfers outside the EEA (including remote access by a non-EEA entity of a sub-processor) take place only with an adequacy decision (incl. the EU-US Data Privacy Framework) or EU Standard Contractual Clauses plus a transfer impact assessment. Annex 3 states the mechanism per sub-processor.
9. Assistance
9.1 Data subject requests: the Service lets Controller export, correct and anonymise a person's data (per-person export and anonymisation in the admin). Processor forwards requests it receives within 5 working days and does not answer them itself. 9.2 Processor assists, taking into account the nature of the processing, with DPIAs and prior consultation, by providing this DPA, Annex 2 and information about the Service. Assistance beyond standard documentation may be charged at [€ RATE]/hour.
10. Audits
10.1 Processor makes available all information necessary to demonstrate compliance: this DPA, Annex 2, sub-processor certifications (e.g. SOC 2 / ISO 27001 reports of Supabase, AWS, Vercel), and answers to a reasonable security questionnaire once per year. 10.2 If that is insufficient, or a supervisory authority requires it, Controller may have an audit performed by an independent auditor bound by confidentiality, at Controller's cost, with 30 days' notice, at most once per year, without access to other customers' data.
11. Duration, return and deletion
11.1 This DPA runs as long as Processor processes personal data for Controller. 11.2 During the term Controller can export its data at any time (CSV/XLSX, API). 11.3 After termination Controller has 30 days to export. Processor then deletes the Customer data from production within 30 days and from backups when the backup retention window expires (Annex 2), unless EU or Member State law requires storage. 11.4 Exception: the append-only audit log [OPEN: technical deletion path for audit log of terminated tenants must be built; see README].
12. Liability
Liability under this DPA is subject to the limitation in the Terms of Service, except where mandatory law provides otherwise. [Lawyer: consider a separate, higher cap for data-protection claims.]
13. Governing law
Dutch law. Disputes: competent court in [Amsterdam / Limburg (Maastricht)] — DECISION OPEN.
Annex 1 — Description of processing
| Item | Description |
|---|---|
| Nature and purpose | Registering, matching, approving and exporting worked hours for payroll and invoicing; planning and placements; optional location check at clock events; optional expense registration; AI-assisted reading of emailed timesheets and anomaly detection; communication (magic links, reminders, nudges); support at Controller's request. |
| Data subjects | (a) Employees and flex workers of Controller; (b) contact persons of Controller's clients (approvers); (c) Controller's own users (office staff, planners, accountants); (d) senders of inbound emails. |
| Categories of personal data | Name, email, phone, employee number, language; placements (client, site, role title, dates, reference), fixed allowances (amounts); hours (date, start/end, minutes, breaks, notes, source, device time, status history); approvals (signer name, role, typed signature, decision, reason, timestamp, IP address, user agent); magic-link metadata (token hash only, expiry, revocation); optional GPS coordinates at clock-in/out and geofence events, and inside/outside status; optional receipts/photos and expense data; inbound emails (sender, subject, attachments) and AI extractions with confidence scores; audit log (actor, action, old/new values, metadata); kiosk selfies [if anti-buddy-punching module is enabled — DECISION OPEN, may involve biometric data if face matching is used: currently NOT planned]. |
| Special categories | None intended. Controller must not store health data in notes or leave reasons. [Leave module: reason "sick" is health data in NL — lawyer: decide whether to store only "absent" without reason.] |
| Frequency | Continuous during the term. |
| Retention | As configured by Controller; defaults in retention-schedule.en.md. GPS coordinates default 30 days (configurable 0–90), then inside/outside only. |
| Location | EU (Ireland primary; Frankfurt for AI). See Annex 3. |
Annex 2 — Technical and organisational measures (TOMs)
Encryption
- In transit: TLS 1.2+ for all connections (web, API, mobile, database); HSTS on timetracking.tech.
- At rest: AES-256 disk encryption for database, file storage and backups (provider-managed keys).
- Magic-link tokens: 256-bit random; only the SHA-256 hash is stored; valid 14 days; revocable; single use for approval.
Tenant isolation and access control
- Every tenant table carries
org_idand is protected by PostgreSQL row-level security; policies are tested per role (owner, admin, office, planner, employee, accountant) in automated tests. - Employees can only read their own placements and hours; client contacts only see the placements in the scope of their link.
- Role-based access in the app; least privilege; service-role key only server-side, never in clients.
- 2FA (TOTP or passkey) mandatory for TimeTracking staff and for owner/admin roles [mandatory vs. optional for Customer admins — DECISION OPEN].
- Staff production access: named persons only, logged, reviewed quarterly.
Integrity and auditability
- Append-only audit log: database triggers record every change to timesheets, claims, placements, periods, approvals, exports and conflicts (who, when, source, old/new value). UPDATE and DELETE on the audit log are blocked by trigger; API roles have no write rights.
- Raw hour inputs (
time_claims) are append-only; locked periods cannot be changed, only corrected with a new reference line. - Exports carry a SHA-256 content hash and are reproducible.
- Clock-tamper detection: device time vs server time, flags > 5 min.
AI safeguards
- Inbound email is treated as data: the model can only fill a fixed extraction schema and cannot trigger actions. SPF/DKIM checks and a per-client sender-domain allowlist; unknown senders go to quarantine.
- Extractions with confidence < 0.85 go to human review.
- Model hosted in EU (AWS Bedrock Frankfurt) [planned]; no training on Customer data.
Availability and backups
- Separate dev / staging / production projects; production data is not used in dev/staging.
- Point-in-time recovery enabled: RPO ≤ 5 minutes, RTO ≤ 4 hours; backup retention [7] days [verify Supabase plan].
- Forward-only, reviewed database migrations; automatic rollback of deployments on error spikes.
Data minimisation
- No screenshots, keystroke logging or app/website monitoring.
- GPS only at clock events and geofence transitions, only if Controller enables it; background location on iOS/Android only when geofencing is on; employee sees when location is captured.
- Push notification payloads contain no hours or names.
- Error monitoring with PII scrubbing.
Incident response
- Documented incident procedure: detect → contain → assess → notify Controller (target 48 h) → remediate → post-mortem.
- Breach register maintained.
Organisational
- Confidentiality obligations for all staff and contractors; security awareness on onboarding.
- Vendor review before engaging sub-processors (DPA, region, certifications).
- Secrets in a secret store, never in the repository.
- This annex is reviewed at least yearly.
Annex 3 — Sub-processors
See subprocessors.en.md (section A), which forms part of this DPA.