Data processing agreement

This agreement governs the processing of personal data that ABARCANDO, S.L. (Spanish tax ID B88017173, C/ Casuarina 18, 7AD, 28044 Madrid; "the processor") carries out on behalf of each AccessTime client company ("the controller") when providing the service. It is accepted by the person who signs the company up, on its behalf, by ticking the box at sign-up, and is recorded in writing in electronic form for the purposes of art. 28.9 of Regulation (EU) 2016/679 (GDPR). AccessTime keeps a record of the accepted version (document, version, SHA-256 fingerprint, date, IP and browser of the person who accepted). It is part of the terms of service.

1. Subject matter, duration, nature and purpose

• Subject matter: the provision of the AccessTime service (working time record, absences and holidays, schedules and rotas, remote work, approvals, reports and exports).
• Duration: that of the service contract, plus the retention and blocking period of section 10.
• Nature of the processing: collection through the platform, recording, structuring, storage, consultation, export, disclosure to the controller itself (and to whoever it grants access), blocking and erasure.
• Purpose: to enable the controller to meet its working time recording obligations and to manage its workforce's working time and absences.

2. Types of data and categories of data subjects

• Data subjects: the controller's workers and collaborators, and the people to whom it grants access to the platform.
• Identification and contact data: name, email, ID number (NIF/NIE, if the controller records it), language.
• Employment data: role, department, workplace, job title, start date, schedule, shifts, holiday balances, and the monthly hours closures (arts. 35.5 and 12.4.c Workers' Statute) with their acknowledgement of receipt (date, IP, browser, channel and comment).
• Working time record: clock-ins with server date and time, method, workplace, remote work, device IP and user agent, device time for offline clock-ins, and their revisions (previous and new value, author, role, reason, agreement).
• Geolocation: only if the controller enables it, at the moment of clocking.
• Local verification on the phone: if the mobile app sends it, with each clock-in, the method the phone itself used to check the person (its biometrics, a PIN or the unlock code, or none) and whether the check succeeded. The check is done by the phone's operating system: the processor only receives that result and does not process biometric data.
• Absences and supporting documents, which may reveal health data (special category, art. 9 GDPR). This is a foreseeable processing of the service, which the controller bases on art. 9.2.b GDPR and art. 9 LOPDGDD. The controller must prevent other special categories from being entered in free-text fields.
• Traceability: audit log of changes and access log, including access by legal representatives (with their scope) and by the Labour Inspectorate with its temporary link.

3. Controller's instructions

The processor processes the data only on documented instructions from the controller, including with regard to international transfers. Documented instructions are this agreement, the terms of service and the configuration the controller sets on the platform (roles, geolocation, approval flows, exports). By accepting this agreement, the controller also gives these instructions:

1. Keep the working time record, its revisions, workdays, incidents, correction proposals and absences for 5 years (4 as the legal minimum, art. 34.9 Workers' Statute, plus one as a margin for claims and inspections that start at the end of the period); clock-ins, their revisions and proposals by whole calendar years (between 5 and 6 years); monthly closures, 5 years from the month they summarise (or from when the version was generated, if later); the audit log, 5 years (for what is still kept after that period, such as a current schedule, a person's role or an absence that ends later, who did it, only by their identifier, with which role, through which channel and when is kept with that data and erased with it); the access log, 2 years; geolocation coordinates, 30 days; and Labour Inspectorate links, while the company exists. Once the period has passed, erase them with the purge procedure, which the processor launches manually after reviewing the monthly report of what would be purged and which records what was erased and when. The controller may ask for a longer period: a hold for litigation or inspection, during which nothing of its company is purged, not even the coordinates or its support conversations.
2. Never overwrite or delete clock-ins: each correction or cancellation is added as a revision, with author, role, date and reason.
3. Record, for every change, who made it, with which role, when and from where, and why for the actions that ask for a reason (among them, corrections and cancellations of clock-ins), and keep that record in a way that makes any alteration detectable.
4. Keep, after a worker leaves, their read access to their own record, its revisions and their closures for 5 years from their leaving date, unless the controller withdraws it (never before the worker's deadlines to answer pending correction proposals and to confirm receipt of their final closure have ended) or unless this contract ends (section 10); and, once nothing of theirs remains within its retention period, anonymise their identifying data if the controller decides so from their record or, once this contract has ended, with the purge procedure.

If, in the processor's opinion, an instruction infringes the GDPR, the LOPDGDD or other data protection law, it will inform the controller immediately.

4. Confidentiality

The processor ensures that the people authorised to process the data (its technical and support staff) have committed to confidentiality or are under a statutory obligation of confidentiality, also after their relationship ends. Support staff only access a company's data when necessary to provide the service or when the controller asks; every entry is recorded with its reason or ticket, and every entry, exit and change with their role (the exit, when they leave, switch to another company or sign out; if the session ends in another way, for example because it expires, their last request inside the company is recorded).

5. Security measures (art. 32 GDPR)

The processor applies, at least, the measures in annex I, and reviews them periodically. It may replace them with others providing an equal or higher level of security.

6. Sub-processors

The controller gives a general authorisation to use the sub-processors in annex II. The processor will inform the controller of any addition or replacement at least 30 days in advance, by email to the company's administration and on this page, and the controller may object on justified grounds; if no agreement is reached, it may terminate the contract without penalty. The processor imposes on each sub-processor, by contract, the same data protection obligations as in this agreement, in particular sufficient guarantees to implement the measures of art. 32 GDPR, and remains liable to the controller for their compliance (art. 28.4 GDPR).

7. International transfers

The service data is hosted in the European Union. Only the push notification sub-processor (Google) may process data in the US, under the adequacy decision of the EU-US Data Privacy Framework (art. 45 GDPR). Any other transfer will require an appropriate safeguard under chapter V GDPR and an instruction from the controller.

8. Assistance to the controller

The processor assists the controller, taking into account the nature of the processing:

• Data subjects' rights: the platform allows the controller to consult, export and rectify (with its revision) each person's data, and each worker to see and download their own record. If a data subject contacts the processor, it will forward the request to the controller within 5 working days at most and will not answer it on its own.
• Security, security breaches, impact assessments and prior consultations (arts. 32 to 36 GDPR): the processor provides the information available to it, including what the controller needs to carry out an impact assessment when its processing requires one.

9. Security breaches

The processor will notify the controller, without undue delay and within 48 hours at most of becoming aware of it, of any security breach affecting its data, by email to the company's administration, with the available information: nature of the incident, categories and approximate number of data subjects and records affected, likely consequences, measures taken or proposed and a contact point. If it cannot provide all the information at once, it will provide it in phases. The controller decides and, where applicable, notifies the AEPD (72 hours) and the data subjects. To determine the scope, the processor has the platform's access and audit logs.

10. What happens to the data at the end

When the service ends, the processor returns the data to the controller: the controller has at least 30 days to export all of it (full company export, with the per-event working time record and its revisions, reports, absences and supporting documents and the audit log, and the Labour Inspectorate export for any period).

After that, the processor keeps the data blocked (arts. 32 and 33.4 LOPDGDD), only accessible to make it available to courts, the Labour Inspectorate or data protection authorities, until the retention period of each item expires (section 3), and then erases it with the purge procedure, which records what was erased and when; it disappears from backups as they rotate (within 12 months at most). Each worker's identifying data is anonymised as soon as nothing of theirs remains within its retention period, and that of the controller and of anyone still left, 6 years after the end of the contract (art. 30 of the Spanish Commercial Code). While the data is blocked, only the controller's administrators sign in to the platform, and solely to make it available to those authorities: with the full export, the export for the Labour Inspectorate or a link for the Labour Inspectorate, stating each time the request they are responding to, and who did it, when and why is recorded. Nobody else from the controller signs in, not even former workers with read access: the controller handles their rights with the returned data. There is no early erasure: the processor keeps the data blocked while liabilities may arise from its relationship with the controller (art. 33.4 LOPDGDD). Keeping the working time record for 4 years is an obligation of the controller as employer (art. 34.9 Workers' Statute), which it ensures with the returned data (art. 33.3 LOPDGDD). The processor will certify the erasure if the controller asks.

11. Information and audits

The processor makes available to the controller the information needed to demonstrate compliance with this agreement: this documentation, the description of the measures in annex I, the record of processing activities as processor (art. 30.2 GDPR) and the result of the integrity check of the record. It allows and contributes to audits, including inspections, by the controller or an auditor it appoints, with reasonable notice (30 days), without compromising the security or confidentiality of other clients, and as a general rule once a year, unless there are signs of non-compliance or an authority requires it.

12. Controller's obligations

The controller guarantees that it has a legal basis for the processing it entrusts, informs its workforce (art. 13 GDPR) about the recording system and, if it enables geolocation, complies with art. 90 LOPDGDD; configures roles and access so that each person only sees what is necessary; and communicates any additional instruction to the processor in writing.

13. Liability

Each party is liable for its breaches under art. 82 GDPR. If the processor processes the data for its own purposes or in breach of the instructions, it will be considered a controller of that processing (art. 28.10 GDPR).

Annex I · Security measures

• Access: personal accounts; passwords hashed with bcrypt and at least 10 characters; new accounts activated with a single-use link that expires; two-step verification mandatory for administration, HR, workers' legal representatives and AccessTime support; attempt limits per account and IP with lock and notice to the account holder; sessions and app access visible and revocable by the user; app access that expires after 90 days.
• Authorisation: data isolated per company in every query; role-based permissions (a worker sees their own data; their manager, their department; HR and administration, their company; legal representatives, the record within their scope, without ID numbers, contact details or free texts); the type of absence is not shown to colleagues.
• Encryption: HTTPS with HSTS for all communications; encryption at rest (AES-256) of the ID number, absence reasons, supporting documents, second-factor secrets and backups.
• Integrity and traceability: the working time record is never overwritten (insert-only revisions); insert-only audit log with who, role, when, from where, before, after and reason; per-company HMAC-SHA256 fingerprint chains; database triggers that reject changing or deleting those records outside the legal purge; seal of the chains every hour outside the database and every day outside the server; daily check against the latest seal outside the database, with notice of any alteration it finds (the daily seal outside the server also allows a manual check); the application account has no privileges to alter the database structure.
• Availability: encrypted backups (14 daily and 12 monthly) with tested restores, kept on the server and, with the same rotation, outside it, on a server of Arsys Internet, S.L.U. in Spain (annex II), which does not hold the key to decrypt them; the database change log, which allows recovery up to the moment of a failure, is kept for 14 days at most and only leaves the server encrypted; offline clock-ins stored on the device and synchronised without duplicates.
• Web application: content security policy (CSP), protective headers, CSRF and bot protection on public forms, periodic review of dependencies with security advisories.
• Organisation: staff bound by confidentiality; recorded support access; procedure for managing and notifying security breaches; record of processing activities as processor.

Annex II · Authorised sub-processors

Every day the Arsys server fetches from the main server, over an encrypted connection (SSH) and with access that only allows reading them, the backups and the change log, already encrypted; the processor keeps the key that decrypts them outside that server (annex I).

They are not sub-processors, because they do not process workforce data on behalf of the controller: Stripe Payments Europe, Ltd. (subscription payments, independent controller of its payment data) and Google reCAPTCHA (protection of public forms, ABARCANDO's own processing described in the privacy policy).