Data Processing Agreement

1. Parties

This Data Processing Agreement ("DPA") is entered into between the Customer ("Data Controller") and YARDtwin Ltd, registered in Ireland ("Data Processor"), collectively the "Parties". This DPA forms part of, and is subject to, the YARDtwin Terms of Service.

2. Scope & Purpose

The Processor processes personal data on behalf of the Controller solely for the purpose of providing the YARDtwin yard management platform: dock scheduling, gate operations, digital twin yard visualisation, carrier and driver management, an audit trail built for GMP environments, analytics, and integrations. Processing is performed for the duration of the Controller's subscription and any retention period required by Section 11.

3. Categories of Data Subjects

• Controller's employees and administrators (named users of the platform)
• Drivers and logistics personnel checked in at the Controller's gates
• Carrier representatives and dispatch contacts
• Gate-security and warehouse-operator personnel

4. Types of Personal Data

• Identity data: names, email addresses, phone numbers, position/job title, company name and address
• Authentication data: bcrypt-hashed passwords (12 rounds), JWT access & refresh tokens, session timestamps, IP addresses, SSO identifiers (Google, Microsoft)
• Operational data: appointments, dock allocations, trailer movements, inspection records, documents, task assignments, vehicle registrations
• Driver data: licence numbers and licence images. Gate staff may take a face photo of the driver as gate evidence. Where a site turns on AI face comparison, our AI provider (Anthropic) compares that photo one-to-one with the licence photo or the driver’s stored photo to help staff confirm the driver’s identity. The result is advice: gate staff decide, and can admit a driver the comparison did not confirm by giving a reason. Each comparison is recorded on our servers with its result. Where face comparison is off (the default), no face photo is sent to the AI provider and staff compare the driver with the licence photo themselves; licence images are still read by AI where AI reading is on. YARDtwin stores no face templates and performs no one-to-many identification.
• Audit data: user actions, timestamps, IP addresses, user-agent strings, old/new value diffs, GMP-flagged records

5. Obligations of the Processor

• Process personal data only on documented instructions from the Controller (the platform UI and API constitute documented instructions)
• Ensure persons authorised to process data are bound by confidentiality agreements
• Implement appropriate technical and organisational security measures (Art. 32) — see Section 7 below
• Engage only the sub-processors listed in Section 6, for which the Controller gives general written authorisation; give at least 30 days' notice of any new sub-processor, to which the Controller may object (Section 6)
• Assist the Controller with data subject requests (Art. 15–22) via the DSAR endpoints described in Section 9
• Notify the Controller without undue delay, and in any case within 48 hours of becoming aware of a personal data breach; give an initial notice within 24 hours of any confirmed security incident affecting the Controller's data (Section 8)
• Delete or return all personal data upon termination of services (Section 11)
• Make available all information necessary to demonstrate compliance and support audits (Section 12)

6. Sub-processors

The Processor currently engages the following sub-processors, each acting under a Data Processing Agreement and (where applicable) Standard Contractual Clauses 2021:

The Controller gives general written authorisation for the sub-processors listed above. The Processor will give at least 30 days' notice of any new sub-processor; the Controller may object on reasonable grounds and, if the objection cannot be resolved, terminate the affected service without penalty.

Website-only services (no customer operational data)

These run on the public website only. They receive no customer operational data and are not sub-processors of it; any that set cookies load only with consent.

7. Security Measures (Art. 32)

• Encryption in transit: TLS 1.2+ on every endpoint; certificates managed by Microsoft Azure (DigiCert)
• Encryption at rest: Azure Postgres Flexible Server transparent data encryption; Azure Blob Storage encryption
• Licence images and signatures: Driver licence images and signatures are encrypted at rest with AES-256 by Azure Storage and Azure Database for PostgreSQL (Microsoft-managed keys), and access to them is limited by role and organisation
• Password hashing: bcrypt, 12 rounds
• Authentication: JWT access tokens (1-hour expiry) and refresh tokens (7-day expiry, rotated on use, never valid beyond 30 days from sign-in). Single sign-on (SAML 2.0, Google, Microsoft); time-based one-time-password MFA, mandatory for platform administrators and available to all users
• Tenant isolation: enforced server-side by tenant scoping, and tested automatically before every release: the release gate’s cross-tenant sweep calls the API as one organisation with another organisation’s record IDs, and the release is blocked if any of that organisation’s data can be read or changed
• Role-based access control: role-based permissions on authenticated routes, with tenant scoping enforced server-side
• Web Application Firewall: Azure Front Door WAF in Prevention mode with custom rate-limiting rules on the authentication, signup, password-reset and data-subject-request endpoints, plus platform-level L7 DDoS protection. No managed OWASP rule set is attached — that requires the Front Door Premium tier.
• Rate limiting: per-route limits, tighter on auth endpoints; in-memory + persisted attempt tracking
• Audit trail: tamper-evident and append-only (enforced in the database), GMP-relevant entries flagged separately and retained for at least 7 years while the service agreement runs (at the end of the contract it is exported to the Controller, unless the Controller declines the export in writing or cannot be reached after reasonable attempts, and then deleted — Section 11), other entries for 365 days, pseudonymised (not deleted) on Art. 17 erasure under Art. 17(3)(b)
• Continuous monitoring: Azure Application Insights; a website availability test every 10 minutes; a schema-drift alert (15-minute window); an alert when more than 10 server errors (HTTP 5xx) occur in 5 minutes; and a breach-monitor worker that checks the audit log every 5 minutes for failed-login spikes (10 or more for one account in an hour), sign-in attempts on one account from 5 or more IP addresses in 24 hours, and successful logins from an IP address not seen for that user in the last 30 days
• Software supply chain: Every pull request must pass npm audit (dependency vulnerabilities), Semgrep (static analysis) and gitleaks (secret scanning) before it can be merged, with a Trivy container image scan as an advisory check; these checks also run on every push to master and nightly, together with an advisory OWASP ZAP baseline scan (dynamic testing) of the production site. Secrets: Azure Key Vault accessed via App Service managed identity; no secrets in code, env files, or container images

8. Personal Data Breach Notification

The Processor shall notify the Controller without undue delay, and in any case within 48 hours of becoming aware of a personal data breach affecting the Controller's data, and shall give an initial notice within 24 hours of any confirmed security incident affecting the Controller's data. Notification shall include the nature of the breach, categories and approximate number of data subjects affected, likely consequences, measures taken or proposed, and the breach-register reference. Detected anomalies route to Azure Monitor Action Group yardtwin-breach-actions; confirmed incidents are tracked in the breach-register table with a 72-hour DPC countdown.

9. Data Subject Rights

The Processor provides the Controller with the following endpoints to fulfil data-subject rights within the 30-day Art. 12(3) deadline:

• POST /api/v1/dsar/export/by-email — machine-readable export covering Art. 15 (access) and Art. 20 (portability)
• POST /api/v1/dsar/erase/by-email — erasure on a verified request: the person's own user accounts in the selected customer accounts are anonymised and their sessions, tokens, notifications, pending invitations, newsletter and sign-up records and own avatar are deleted; operational records held by the Controller (bookings, gate and visit records, driver roster, contacts) are listed for the Controller to act on; the audit trail keeps an anonymised actor reference for GMP integrity (Art. 17(3)(b))
• Self-service request portal at /data-request

10. International Transfers

Operational data is stored within the European Economic Area (Microsoft Azure, Sweden Central and Norway East). Standard Contractual Clauses (2021) apply to each transfer to a sub-processor outside the EEA; where a recipient is certified under the EU-US Data Privacy Framework, that is also relied on. Transfer impact assessments are being completed (target November 2026).

11. Duration, Termination & Data Return

This DPA remains in effect for the duration of the service agreement. Upon termination:

• The Controller may export all of its data within 30 days via the in-product export functions or by request
• After 30 days, the Processor will delete all of the Controller's operational personal data
• While the service agreement runs, audit logs are retained in a pseudonymised state: GMP-relevant entries for at least 7 years after the event to meet GMP record-retention requirements (21 CFR Part 11 / EU GMP Annex 11; Art. 17(3)(b) legal-obligation override), other audit entries for 365 days. At the end of the contract, before the Controller's data is deleted, the Controller is given a complete export of its audit trail, with a verification receipt, to keep for its own record-retention period, unless it declines the export in writing or cannot be reached after reasonable attempts; the Processor then deletes the audit trail with the rest of the Controller's data. Apart from the backups described below, which expire on their own schedule, and the Processor's own record of the handover (the receipt, the export's hashes and counts, and who made and received it), the audit trail is kept longer only if the Controller instructs the Processor in writing, under a separate agreement.
• Operational data is deleted within 30 days after the end of the contract. Point-in-time database backups expire within 7 days. Encrypted monthly archive backups are kept for up to 7 years for disaster recovery only; they are not restored except to recover the service, the data in them is beyond use, and it expires with the backup.
• A full database backup is taken every night and kept for 35 days in separate encrypted storage in the EEA (Sweden Central, geo-replicated to Sweden South); data erased from the live service remains in those backups, beyond use, until they expire.

12. Audit Rights

The Processor shall make available to the Controller all information necessary to demonstrate compliance with Art. 28 GDPR. Customers may request: the current sub-processor register, the latest tenant-isolation regression-test report, the external penetration-test summary once a test has been carried out (see GDPR Policy 11.1), and answers to a vendor security questionnaire. Reasonable on-site or remote audits may be arranged with at least 30 days' notice, conducted by the Controller or an independent third party bound by confidentiality. The Processor holds no ISO 27001 or SOC 2 certification today; once ISO 27001 certification is achieved (targeted Q1 2027), the Processor will offer the certificate as substitute evidence.

13. Liability & Governing Law

Liability under this DPA is subject to the limitations set out in the YARDtwin Terms of Service. This DPA is governed by the laws of Ireland and the EU General Data Protection Regulation (GDPR). Any disputes are subject to the exclusive jurisdiction of the courts of Ireland.

14. Contact

For questions about this DPA, to request a review copy (a countersigned edition is issued once company registration is complete), or to exercise any of the rights set out above, contact admin@yardtwin.com or the data-protection contact at dpo@yardtwin.com. This is a role mailbox monitored by the person responsible for data protection at YARDtwin Ltd. YARDtwin has not designated a statutory Data Protection Officer under Article 37 GDPR, which is not mandatory for its processing (GDPR Policy 11.2); the contact address is published in place of an individual's name.