Data Processing Agreement (DPA)

1. Parties and definitions

• Controller: the Subscriber — the business using OPEREX — which determines the purposes and means of processing the operational data.
• Processor: Mészáros János egyéni vállalkozó, the operator of OPEREX, processing data on behalf of and per the instructions of the Controller.
• Data subject: the Controller's employees and operators (appearing in the shift log, event log and tasks), the Controller's account users, and — if the Controller switches on sign-in-free field reporting — its external reporters (see section 3).
• Sub-processor: a third party engaged by the Processor (see section 6).
• Other terms are to be interpreted in accordance with Article 4 GDPR.

2. Subject matter, nature, purpose and duration

• Subject matter: processing the Controller's operational data on the OPEREX platform.
• Nature: storage, recording, retrieval, organisation, backup, anonymised statistical aggregation.
• Purpose: technical provision of the shift-log, event and task-management service to the Controller.
• Duration: the term of the subscription + the retention/deletion period under section 11.

3. Categories of data subjects and data

Data subjects:

• The Controller's employees and operators (shift supervisors, operators, maintenance staff)
• The Controller's account users (who receive accounts in the tenant)
• If the Controller switches on sign-in-free field reporting: external reporters using the posted QR code (e.g. contractors, visitors — anyone who scans the code), who are not the Controller's account users

Categories of personal data:

• Identifiers: name, email, job title/role, account ID
• Shift-log and event-log entries, authorship and timestamps
• Photos attached to diary items (event, shift handover, maintenance, task, image field), with the uploader's identifier and the upload time
• Acknowledgements of management orders, task statuses and justifications
• Audit trail (who, what, when) — append-only
• Technical logs: IP address, session events
• Access-security data: the time of last sign-in and the sign-in history (time + name of browser/device, without IP address) — behind a separate, individually grantable permission at the Controller, by default visible to administrators only
• Attendance and roster: who was present in a given shift (as part of the shift diary)
• Shift Planner (if used): rosters, absences, and the date taken and expiry date of mandatory examinations/training (e.g. medical fitness) — not the outcome
• Training module (if used): the qualification register of the Controller’s own employees (qualification type, date, content, exam/record, trainer/assessor, validity) and, for an own employee’s external document, its number, validity and — if the type allows — a photo or PDF of it. For medical fitness only the OUTCOME (fit / fit with restrictions / unfit) and the validity are stored; the examiner (occupational health service or specialist care) and any revocation reason can only be picked from a closed list; no attachment and no free text can be recorded
• Field reports (only when the feature is switched on): the report text; the name and contact details (phone or email) given voluntarily by the reporter — visible only to users authorised to manage field reports; the optional photo, which the system re-encodes on upload without keeping the image metadata (e.g. EXIF or location data); the time and place of receipt (plant and, optionally, technical location — from the QR code). The application stores no IP address with the report; the anti-abuse rate limit uses the IP address only transiently, in the server memory.

Special category data — three distinct cases: (1) an incident or near-miss entry may EXCEPTIONALLY contain health-related data (e.g. an injury); (2) the Shift Planner examination register handles occupational-health data ROUTINELY. For the latter the system is built to be data-minimising: the record stores the date the examination was taken and its expiry, there is no result or finding field, and the free-text note field on screen explicitly warns that no medical finding may be entered there; (3) the medical-fitness qualification of the Training module stores ONLY the outcome (fit / fit with restrictions / unfit) and the validity (the examiner and the revocation reason from a closed list) — no attachment and no free text can be recorded in the system, and the record is visible only with a separate permission distinct from viewing the register. In all three cases the Controller is responsible for the legal basis (GDPR Article 9(2), typically an employment-law obligation); the Processor handles such data solely on instruction, as a technical service provider.

The Processor does NOT handle card or payment data; this is handled by the (yet to be selected) payment processor as an independent controller, under its own terms.

4. Controller obligations

• Ensures an appropriate legal basis for the data entered into the system (Article 6 GDPR).
• Provides privacy information to its own data subjects (employees), covering the involvement of the Processor and sub-processors.
• Is responsible for the accuracy and currency of the data it records.
• Is responsible for the personal data in uploaded photos: it is the uploader's responsibility that no person is recognisable in the image (the system warns on upload); at a data subject's request the Controller's administrator can delete the photo — the deletion leaves a trace (who, when, with what reason). Deletion removes the photo from the application, and shift-log PDFs produced afterwards show the deletion trace in its place; shift-log PDFs already generated (and sent) before the deletion keep the photo, as they are immutable records of the state at generation time.
• If the Controller switches on the diary's dictation feature, the user's browser sends the audio to the browser vendor to turn it into text — this is not processing by the Processor or its sub-processors: the Processor neither receives nor stores the audio, only the saved text; the Controller informs its data subjects about this.
• If the Controller switches on sign-in-free field reporting, it is responsible for informing the external reporters (the reporting form shows a short notice naming the Controller and a link to the Controller's own privacy notice), for the legal basis of the processing and for determining the retention period. The application provides two tools for this: (1) the “Delete reporter details” action, with which a user authorised to manage field reports — for example at the reporter's request — deletes the reporter's name and contact details with a reason (the report text is kept; the audit trail records who deleted, when and why, not the deleted data); (2) a tenant-level retention period, after which a daily automatic deletion removes the name and contact details. By default there is no automatic deletion — until the Controller sets a retention period, the reporter's details are kept together with the report. A photo attached to the report can be deleted via the deletion path for photos described above.

5. Processor obligations (Article 28(3) GDPR)

The Processor undertakes to process personal data:

• a) solely on the Controller's documented instructions;
• b) ensuring that persons authorised to access the data are bound by confidentiality;
• c) taking the security measures under Article 32 GDPR (see section 7);
• d) engaging sub-processors only with the authorisation under section 6, allowing objection;
• e) assisting the Controller in fulfilling data-subject rights (Articles 12-22 GDPR);
• f) assisting the Controller with obligations under Articles 32-36 GDPR (security, breach, impact assessment);
• g) at the end of the engagement, returning or deleting the data at the Controller's choice (see section 11);
• h) making available all information needed to demonstrate compliance with Article 28, and allowing audits (see section 12).

6. Sub-processors

By accepting this DPA, the Controller grants general authorisation for the use of the following sub-processors:

Not sub-processors: the database, authentication and file storage run as self-hosted Supabase, operated by us, on the Hetzner server above, and cookieless visit measurement on the public website uses self-hosted Umami (on the website only, never in the application; download clicks are measured in aggregate: the file name and the page it was clicked from — no personal data) — no separate cloud provider has access to either. The payment and billing provider has not yet been selected; it will act as an independent controller under its own terms, and is therefore not a sub-processor.

For on-premise (Enterprise) deployments, data runs on the Controller’s own infrastructure, so the set of sub-processors above may differ or not apply; this is governed by the relevant individual contract.

The Processor gives at least 30 days’ email notice before engaging a new sub-processor; the Controller may object and, absent agreement, terminate the subscription for cause. The Processor binds sub-processors to obligations equivalent to this DPA and remains liable for their acts.

7. Security measures (Article 32 GDPR)

• Encryption in transit: TLS 1.2+ for all traffic, HSTS enabled; internal services (database, object storage, authentication) are reachable only on the server’s loopback interface, never from the public network
• Encryption at rest: passwords are stored as one-way cryptographic hashes and two-factor authentication secrets are encrypted with AES-256-GCM. On the dedicated production server the database, the file store and the local backups sit on a LUKS-encrypted volume; the shared demo/evaluation environment is not disk-encrypted and holds no production customer data. Physical-access protection is additionally provided by the hosting provider’s data-centre controls
• Tenant isolation: database-level Row-Level Security (RLS) on every tenant table, enforced (FORCE) and reinforced in the application data-access layer; coverage is checked automatically on every deployment
• Append-only audit trail: a record of entries and status changes whose modification and deletion the database refuses for every role (enforced at database level); the lawful, contractual deletion is an explicit, logged procedure
• Access control: password hashing, role-based access control (RBAC), session timeout, invitation-only account creation
• Two-factor authentication (2FA): mandatory TOTP-based two-factor authentication for administrative (superadmin) access; available to every user of the tenant, and can be made mandatory per tenant for administrators or for all users (the tenant can tighten it itself)
• Backup: regular (6-hourly) off-site backup to Cloudflare R2 with an approximately 6-hour recovery point (RPO) and self-verifying read-back (SHA-256 comparison). Transfer is protected by TLS; since 25 September 2026 the database, log and configuration backups are encrypted before upload, under our own key (age), with the private key held off the server — the storage provider cannot read them. Encryption at rest for the file-store mirror continues to be performed by the storage provider under its own keys
• Security updates: the server operating system receives automatic security updates
• Internal access restriction: only the person responsible for operations accesses production data

Support access (impersonation): for troubleshooting or support purposes — at the Controller's request or to the extent necessary to provide the service — the operator of the Processor may temporarily access the Controller's environment. Such access does not use the account of any user: it uses a separate, dedicated support account (“OPEREX Support”) that is active only for the duration of the support session and is disabled on exit. Every such access leaves an immutable audit trail — naming the individual who actually performed it — and is subject to two-factor authentication. The Processor uses such access solely for the above purposes, not for its own purposes.

8. Personal data breach (Article 33 GDPR)

Upon becoming aware of a personal data breach, the Processor notifies the Controller by email without undue delay and within 24 hours of detection at the latest, stating the nature of the breach, the approximate scope of data subjects and data, the likely consequences and the measures taken. The Processor notifies even with partial information — it does not wait for the investigation to conclude — and states when the next update can be expected. Notification to the supervisory authority (NAIH) is the Controller’s responsibility; the Processor provides all necessary information. Why 24 hours: where the Controller also has a cybersecurity reporting duty (NIS2 / Hungarian Act LXIX of 2024), its own early warning is due within 24 hours — supplier notification has to serve that deadline.

9. International data transfer

The primary storage location for personal data is within the European Economic Area (Germany). Transfers outside the EEA take place only with the safeguards under Chapter V of the GDPR. Under the EU-U.S. Data Privacy Framework: Cloudflare, Inc. (US, off-site backup and DNS) and Resend Inc. (US, email delivery). Under standard contractual clauses (SCCs): Anthropic PBC (US, shift-text translation — only if the optional translation feature is activated).

10. Supporting data-subject rights

The Processor provides technical means to support data-subject rights (access, rectification, erasure, portability, restriction). Data subjects should approach the Controller in the first instance; if a data subject contacts the Processor directly, the Processor forwards the request and acts only on the Controller's instruction. A field reporter (section 3) may ask the Controller to delete their name and contact details; the tool for this is the “Delete reporter details” action under section 4.

11. Return and deletion of data on termination

• Data is retained for 30 days with the Controller's access (for export / reactivation). The return is complete: every tenant data table in machine-readable (NDJSON) and spreadsheet-openable (CSV) form, with a file inventory and a per-file SHA-256 checksum;
• thereafter it is permanently deleted from live systems; it leaves the backups when the backup retention period expires, within 90 days at the latest — unless retention is required by law (e.g. accounting: 8 years);
• on the Controller’s request, written confirmation of deletion is provided.

12. Audit and verification

Once a year, on written request, the Controller may request information and supporting documents on the security measures and sub-processor contracts. On-site audits may take place only with good cause, after prior coordination and a non-disclosure agreement (NDA); costs are borne by the Controller, unless a significant non-conformity is found.

13. Liability

The parties are liable to data subjects under Article 82 GDPR. The allocation of liability between the parties is governed by section 11 (limitation of liability) of the Terms, within the mandatory legal framework.

14. Entry into force, term, termination and final provisions

• Term: enters into force with the Terms and applies for the subscription period, except for provisions that survive by their nature (confidentiality, deletion).
• Governing law: Hungarian law, within the GDPR framework.
• Amendment: the Processor gives at least 30 days’ email notice.
• Contact: for data-protection matters, support@operex.eu.
• Related documents: Terms, Privacy policy, Legal notice.