Template v0.1 · 17 October 2026

TEMPLATE — TO BE REVIEWED BY A LAWYER BEFORE SIGNING. This is a draft for the VesselSOS Fleet pilot. It is not legal advice and must not be signed until a lawyer has reviewed it (internal checklist: docs/fleet-legal-review.md in the site repository). Text in [square brackets] is to be filled in or decided.

Data processing agreement (GDPR Art. 28) — VesselSOS Fleet

Between

[Rental company legal name], registry code [●], address [●], represented by [name, position] (the Controller, “you”),

and

Innovesting OÜ, registry code 14903935, [registered address], Estonia, represented by [name, position] (the Processor, “we”), provider of VesselSOS and VesselSOS Fleet.

Each a Party, together the Parties.

1. Background and scope

1.1. The Controller uses VesselSOS Fleet (“Fleet”): a web dashboard, server functions, the Fleet API and optional integrations with which the Controller checks customers out on rental crafts, sees each rental on a map from the customer’s VesselSOS app between the customer’s acceptance and the return, receives alerts and help requests, and documents returns and incidents. Fleet is provided under the VesselSOS Terms of Use, section 12 “VesselSOS Fleet” (the “Terms”).

1.2. This agreement governs the processing of personal data that we carry out on the Controller’s behalf when providing Fleet (“Controller Data”), as described in Annex 1. It forms part of the Terms. If this agreement and the Terms conflict on data protection, this agreement prevails.

1.3. Outside the scope of this agreement — processing for which Innovesting OÜ is itself the controller, described in the VesselSOS privacy notice (vesselsos.com/privacy/):

• (a) the customer’s own VesselSOS account and app features (phone number, name, contacts, own trips, the SOS screen and SOS share, Friends, hazard reports), including the moment the customer starts or accepts a rental in the app;
• (b) the sign-in accounts of the Controller’s staff (email, name, role, alert settings, push tokens), the Controller’s own business and contract data, and security and audit logs of the Fleet service;
• (c) the Fleet website and demo requests;
• (d) anonymous or aggregated statistics derived from Fleet use (for example the number of rentals per day or per country) that do not identify any customer.

1.4. Terms used here (personal data, processing, controller, processor, sub-processor, personal data breach, data subject, supervisory authority) have the meaning given in Regulation (EU) 2016/679 (“GDPR”).

2. Controller’s instructions and responsibilities

2.1. We process Controller Data only on the Controller’s documented instructions, including with regard to transfers to third countries, unless EU or Member State law requires otherwise; in that case we tell the Controller before processing unless that law forbids it.

2.2. The Controller’s documented instructions are: this agreement and its annexes; the Controller’s use and configuration of Fleet (its settings, zones, rules, staff and roles, connected integrations, API keys and webhooks, and each action its staff take); and further written instructions agreed by the Parties. We tell the Controller at once if we think an instruction infringes data protection law.

2.3. Retention as instruction. The Controller instructs us to apply the retention periods in Annex 1, section F, which Fleet applies automatically. A different period (for example longer retention of rental records for insurance) is a change of instruction that the Parties agree in writing; [whether and how this can be configured is open].

2.4. The Controller is responsible for: having a legal basis for the processing; informing its customers (Art. 13/14 GDPR) about its processing, including that their position is visible to its staff from acceptance until return and that after an SOS or help request the track is kept for 30 days for an incident report; the lawfulness of its rental terms, zones and messages; and not entering special categories of data (Art. 9 GDPR), such as health data, into notes, rental terms or return checks.

3. Processor’s obligations

3.1. Confidentiality. Only persons who need access to provide, support or secure Fleet can access Controller Data, and they are bound by confidentiality.

3.2. Security. We implement the technical and organisational measures in Annex 2 (Art. 32 GDPR). We may change them as long as the overall level of protection does not fall.

3.3. Sub-processors. The Controller gives general authorisation to the sub-processors listed in Annex 3. We tell the Controller by email at least [30] days before adding or replacing a sub-processor; the Controller can object on reasonable data protection grounds within that period, and if the Parties cannot resolve the objection, the Controller can end its use of Fleet. We impose the same data protection obligations on each sub-processor by contract and remain responsible for them towards the Controller.

3.4. Data subjects’ rights. Taking into account the nature of the processing, we help the Controller answer requests from data subjects (access, rectification, erasure, restriction, portability, objection). Requests we receive directly about a rental we forward to the Controller without undue delay and do not answer on its behalf unless it asks us to. Fleet itself gives the Controller access to rental records and incident reports in the dashboard.

3.5. Customers’ VesselSOS accounts. When a customer deletes their VesselSOS account (an action under section 1.3(a)), the link between the account and the Controller’s rental records is removed; the rental records stay, without that link. [Lawyer: confirm this is acceptable for the Controller.]

3.6. Assistance. We help the Controller with security, breach notification, data protection impact assessments and prior consultation (Art. 32–36 GDPR), taking into account the nature of the processing and the information available to us.

3.7. Personal data breaches. We notify the Controller without undue delay, and where feasible within [48] hours, after becoming aware of a personal data breach affecting Controller Data, with the information available at that time (nature of the breach, categories and approximate number of data subjects and records, likely consequences, measures taken or proposed, contact point), and supplement it as more becomes known.

3.8. Records. We keep a record of processing activities carried out on behalf of the Controller (Art. 30(2) GDPR).

4. International transfers

4.1. Controller Data is stored in the European Union (Supabase, Stockholm region). Some sub-processors in Annex 3 process data in the United States (notifications, SMS, parts of the web hosting). Such transfers rely on the European Commission’s Standard Contractual Clauses (Decision (EU) 2021/914), module three (processor to processor), with supplementary measures where needed. [Lawyer: confirm module and transfer impact assessment.]

5. Audits and information

5.1. We make available to the Controller the information necessary to demonstrate compliance with Art. 28 GDPR, including this agreement’s annexes and, on request, a written description of our security measures.

5.2. The Controller may audit compliance, itself or through an independent auditor bound by confidentiality, no more than once in 12 months (or after a breach), on [30] days’ written notice, during business hours and without disturbing the operation of the service or other customers’ data. Each Party bears its own costs. We may answer first with written information if that is sufficient.

6. Duration, ending, deletion

6.1. This agreement runs as long as we process Controller Data for the Controller.

6.2. When the Controller stops using Fleet, the Controller can export what it needs (rental records through the dashboard and the Fleet API) during [30] days. After that we delete the Controller Data, including copies, within [30] days, unless EU or Member State law requires us to keep it. Backups are overwritten within 30 days in the normal backup cycle. [Open: there is no automated operator-deletion function yet — deletion on ending is a manual process.]

6.3. Retention periods in Annex 1 continue to apply until deletion.

7. Liability and other terms

7.1. Liability under this agreement follows the Terms (section 07 and section 12 “Liability”), except where Art. 82 GDPR or other mandatory law provides otherwise.

7.2. Estonian law applies. The courts of Estonia have jurisdiction [Lawyer: Harju County Court?].

7.3. Changes to this agreement must be in writing (email is enough if both Parties confirm).

Signatures

Annex 1 — Details of the processing

A. Subject matter and duration. Providing VesselSOS Fleet to the Controller for the duration of its use of Fleet (section 6).

B. Nature and purpose. Storage, retrieval, display, transmission and deletion of data needed to: identify the customer at check-out; send the rental offer to the customer’s app; show each accepted rental on the Controller’s live map and track until return; raise alerts (out of zone, late, low battery, help request, SOS) and send them to the Controller’s staff by dashboard, push notification and — for SOS — SMS; let staff message customers and extend rentals; record the return check; produce the rental log, evening overview and incident reports; import bookings from the Controller’s booking systems and the Fleet API; and send rental events to the Controller’s webhooks and booking systems.

C. Categories of data subjects.

1. The Controller’s customers (renters) who accept a rental in the VesselSOS app, and customers named in bookings that the Controller imports.
2. The customer’s emergency contact (one person, while the rental runs).

D. Categories of personal data.

No special categories of data are intended to be processed. The Controller must not enter them in free-text fields (section 2.4).

E. Who can see what. The Controller’s staff, by role: owner (everything, including settings, staff, keys and integrations), staff (rentals, craft status, pausing check-outs), rescue (read, message, acknowledge alerts). Before acceptance, staff see only the customer’s first name and masked phone number, never a position. After return, positions are no longer shown on the live map. Positions, tracks, the customer’s phone number and emergency contacts never leave through the Fleet API, webhooks or the Processor’s admin console.

F. Retention (applied automatically; daily job at 03:15 UTC unless stated).

Annex 2 — Technical and organisational measures

Hosting and encryption

• Database, authentication, server functions and secrets vault on Supabase in the EU (Stockholm). Data encrypted in transit (TLS) and at rest.

Access control in the database

• Row-level security is enabled on every Fleet table, and no table is granted to the anon, authenticated or service_role roles: all reads and writes go through server-side functions (SECURITY DEFINER, with a pinned search_path) that check who is calling and their role before returning anything.
• Each function checks the caller’s operator membership and role (owner / staff / rescue); data of one operator is never returned to another. Customers can act only on their own rental. Positions are returned only for active rentals and only from acceptance onwards; at return the rental’s trips are ended server-side, so no further positions can be added.
• Suspended operators cannot start rentals or use the API and integrations; running rentals can still be watched and returned (safety first).
• The last owner of an operator cannot be removed. A staff member’s SMS alert number can be set only by that staff member.
• Automated test suite (85 tests, run on every change) covering the exact API surface per role, absence of table grants, pinned search_path, cross-operator and cross-customer isolation, the acceptance-to-return position rule, roles, suspension, rate limits, retention and the integration handlers.

Authentication and secrets

• Customers: phone number with a one-time SMS code. Staff: email one-time link or code. No passwords are stored.
• Fleet API keys are stored only as a SHA-256 hash with a short prefix; the key is shown once; at most 10 active keys; keys can be revoked.
• Booking-system access keys and outgoing webhook signing secrets are stored in Supabase Vault (encrypted), not in database tables; the browser never sends a booking-system key to the database (connection goes through a server function).
• Inbound webhook URLs contain a secret token of which only the SHA-256 hash is stored; Bókun HMAC signatures are checked when sent; webhook content is never trusted — the booking is read back from the provider with the Controller’s key.
• Outgoing webhooks: HTTPS to public hosts only, HMAC-SHA256 signature with timestamp, redirects not followed, retries with back-off, paused after 20 consecutive failures.

Abuse protection

• Rate limits on every customer, staff and anonymous function and on the Fleet API (120 requests per minute per key). Anonymous callers are identified only by a salted, daily-rotating SHA-256 hash of the IP address; raw IP addresses are not stored.

Processor’s own staff

• The admin console has roles (viewer, support, ops, owner). It shows aggregates and support summaries only — never positions or tracks. Every read or change of personal data in the console is written to an append-only audit log (kept 24 months).
• Access is limited to the people who need it; sign-in by one-time email link.

Data minimisation and retention

• Retention in Annex 1, section F is enforced by scheduled database jobs.
• SMS outcomes are logged with masked phone numbers.
• Rental trips are not shown to the customer’s friends and send no automatic overdue SMS.

Incidents and continuity

• Personal data breaches are handled under section 3.7; the authority is notified within 72 hours where required.
• [To be completed: backup and restore procedure, internal access review, staff confidentiality undertakings.]

Annex 3 — Sub-processors

Not sub-processors (no Controller Data):

• OpenStreetMap and OpenSeaMap tile servers — the staff browser loads map tiles (IP address and map area viewed).
• MET Norway — [weather for the offshore-wind warning; receives only the coordinates of the Controller’s bases. Not yet confirmed in the code.]

Connected by the Controller (the Controller’s own providers, not our sub-processors):

• Booqable, Bókun, and any system the Controller connects through the Fleet API or webhooks. We exchange data with them only on the Controller’s instruction, with the Controller’s credentials, under the Controller’s contract with that provider.