DRAFT — pending legal review, not yet in force. This document has not been reviewed by qualified legal counsel and does not constitute a binding agreement or legal advice.

Data Processing Agreement (DPA / AVV)

Article 28 GDPR agreement for the processing of personal data by PivotScanner on behalf of the customer.

1. Parties & roles

This agreement (the German-law Auftragsverarbeitungsvertrag, AVV) governs processing under Article 28 GDPR between:

Controller:the customer — the fleet operator or company that holds the PivotScanner account and determines the purposes and means of processing its crew and vessel data.

Processor:ML Upskill Agents UG (haftungsbeschränkt), Vilseck, Bayern, Germany, operating PivotScanner. Company details and Impressum are published at upskillagents.de.

2. Subject-matter & duration

The processor processes personal data solely to provide the PivotScanner service (compliance and maintenance tracking) to the controller. Processing lasts for the duration of the account and ends on termination, subject to the deletion and return terms in section 9.

3. Nature & purpose of processing

Storage, organisation, retrieval, structuring, and erasure of crew certificate records, hours-of-rest logs, planned-maintenance records, and document metadata, together with offline caching to the controller's devices, in order to provide vessel-compliance tracking. The processor does not use the data for any other purpose and does not use it to train any AI model.

4. Categories of data subjects & personal data

Data subjects:the controller's crew members and the controller's own staff (operator/administrator users).

Categories of personal data: identity data (names, nationalities), professional certifications (STCW certificate types, numbers, expiry dates), rest-hour records, and contact details (email). Nationality is processed only to meet maritime regulatory requirements.

5. Controller instructions

The processor processes personal data only on the documented instructions of the controller, including with regard to international transfers, unless required to do otherwise by EU or member-state law. Using the service in accordance with its documentation constitutes the controller's instructions. If the processor believes an instruction infringes the GDPR, it will inform the controller.

6. Confidentiality

Persons authorised by the processor to process the personal data are bound by confidentiality. Access to production data is restricted to the minimum personnel needed to operate and support the service.

7. Sub-processors

The controller authorises the processor to engage the sub-processors below. The processor will inform the controller of intended changes and remains responsible for the sub-processors' compliance.

Sub-processorLocationPurpose
Supabase, Inc.EU — eu-central-1 (Frankfurt); US-headquarteredDatabase, authentication, file storage
CreemEstoniaBilling (merchant of record). Creem acts as an independent controller for payment-card data.
Vercel, Inc.EU — fra1 (Frankfurt) compute; US-headquarteredHosting & content delivery

International transfers.Customer data is hosted in the EU: the database, authentication and file storage run in Supabase's eu-central-1 region (Frankfurt) and the application is served from Vercel's fra1 region (Frankfurt). Supabase and Vercel are US organisations, so limited transfers of personal data to the United States (a third country under Chapter V GDPR) may still occur, for example for support and service operations. Such transfers rely on the EU Standard Contractual Clauses (Art. 46 GDPR) and, where applicable, the sub-processor's certification under the EU–US Data Privacy Framework, together with appropriate supplementary measures.

8. Assistance to the controller

The processor assists the controller, taking into account the nature of the processing, in responding to data-subject requests (access, rectification, erasure, restriction, portability, objection). See Data-subject rights for the mechanisms, including the self-service export. The processor also assists with security of processing, breach notification, and data-protection impact assessments under Articles 32–36.

9. Breach notification

The processor notifies the controller without undue delay after becoming aware of a personal-data breach affecting the controller's data, with the information the controller needs to meet its own Article 33/34 obligations.

10. Deletion & return on termination

On termination, at the controller's choice, the processor deletes or returns the personal data. The controller can export its data at any time from Settings → Export your data. Erasure removes the company/user record and its cascade tables and document files; residual copies in backups age out on the rolling backup window and are re-erased if a backup is ever restored. See the Data retention policy.

11. Audit rights

The processor makes available the information necessary to demonstrate compliance with Article 28 and allows for and contributes to audits, including inspections, conducted by the controller or an auditor it mandates, on reasonable notice and subject to confidentiality. The technical and organisational measures annex below is provided for this purpose.

Annex — Technical & Organisational Measures (Art. 32)

The measures below describe what the service actually implements today. They are stated truthfully and are not overstated.

  • Tenant isolation: every tenant table enforces PostgreSQL Row-Level Security using a flat company_id JWT-claim model, with FORCE ROW LEVEL SECURITYso the table owner cannot bypass it. One operator cannot read another's data.
  • Encryption in transit: TLS/HTTPS for all client and server-to-service traffic.
  • Encryption at rest: the managed Postgres database and the file-storage bucket are encrypted at rest by the infrastructure provider (Supabase).
  • Access control & least privilege: the RLS-bypassing service-role key is restricted to server and cron code paths and is never shipped to the browser; every privileged route performs its own authentication or bearer-secret check before doing work.
  • Pseudonymisation: internal records are keyed by opaque UUID identifiers rather than personal identifiers where practicable.
  • Resilience & backups: managed daily database backups plus a nightly off-site copy of the document-storage bucket provide recoverability. See the retention policy for backup windows.
  • Regular testing: changes pass a mechanical gate (typecheck, lint, and an automated test suite that includes RLS/authorisation isolation tests) before release.

To request a countersigned copy of this DPA, email support@pivotscanner.com.

Last updated: 2026-07-12