Data Processing Agreement — ScanDrop

Version 1.0 · 1 September 2026

1. What This Document Is

This Data Processing Agreement (the "DPA") governs the processing of personal data carried out by Pietro Cangiano, trading as JK Studios (the "Processor"), on behalf of the business or self-employed courier using the ScanDrop app (the "Controller"), pursuant to Article 28 of Regulation (EU) 2016/679 ("GDPR").

The body of this agreement is not written here. This DPA incorporates, in full and without modification, the standard contractual clauses between controllers and processors adopted by the European Commission in Implementing Decision (EU) 2021/915 of 4 June 2021, published in the Official Journal L 199 of 7 June 2021. Those clauses form an integral part of this agreement and are available at eur-lex.europa.eu in every official language of the Union.

Using the Commission's own text, unaltered, is a deliberate choice: it is what makes the mandatory content of Article 28(3) present by construction rather than by drafting skill. What this page adds are the Annexes, which the clauses leave to the parties to complete — and which are the part that must describe the App truthfully.

This DPA is separate from, and additional to, the ScanDrop Privacy Policy, which addresses the Processor's own relationship with the individual user.

2. Who Is Controller of What

ScanDrop handles two sets of personal data, and the roles are not the same for both.

Delivery data — the names, addresses, phone numbers and cash-on-delivery amounts of the people receiving the parcels, and the team structure of the Controller (members, roles, invitations). The Controller decides which deliveries are made and why. The Processor holds this data on the Controller's behalf. This DPA covers this data.
Individual account data — the nickname, password and optional recovery email with which a person signs in to ScanDrop. This exists because that person chose to use the App, not because the Controller instructed it. For this data the Processor acts as an independent controller, and the Privacy Policy applies instead. This DPA does not cover it.

Where the Controller is itself a processor for a third party — a self-employed courier delivering on behalf of a carrier — the Processor acts as a sub-processor, and this DPA applies with the same effect.

3. Options Selected Under the Clauses

The Commission's clauses leave certain choices to the parties. The parties select:

Clause 7.7 (sub-processors) — Option 2: general written authorisation. The Controller authorises the sub-processors listed in Annex IV. The Processor shall inform the Controller of any intended addition or replacement at least 30 days in advance, giving the Controller time to object.
Clause 9 (deletion or return) — at the end of the provision of the services, the Processor shall delete the data, unless the Controller requests its return within 30 days.
Governing law — the law of Italy.
Competent courts — the courts of Italy.

4. Personal Data Breaches

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 data processed under this DPA, by email to the address associated with the Controller's account, describing the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken.

Notifications to a supervisory authority under Article 33 GDPR, and to data subjects under Article 34, are the Controller's responsibility. The Processor shall assist with the information in its possession.

ANNEX I — List of Parties

Data Exporter (Controller)

The business or self-employed courier that created the company in ScanDrop and accepted this DPA.
Identity, address and contact person: as provided by the Controller at sign-up and recorded in the Processor's systems together with the date and version of acceptance.
Activities relevant to the data transferred: organising and carrying out parcel deliveries.
Role: Controller (or processor, where acting for a carrier).

Data Importer (Processor)

Pietro Cangiano, trading as JK Studios.
Contact: support@jkstudios.it
Activities relevant to the data transferred: providing the ScanDrop application and the hosting of the delivery rounds it organises.
Role: Processor.

ANNEX II — Description of the Processing

Categories of data subjects

Recipients of consignments — people who are not users of the App, have no relationship with the Processor, and have consented to nothing. This is the category that matters most in this agreement.
Members of the Controller's team — couriers, warehouse staff and coordinators who use the App under the Controller's company.

Categories of personal data — recipients

Name or business name of the recipient.
Delivery address: the raw line as read from the label, and the same address split into street, house number, postcode, town, province and country.
Geographic coordinates of that address and its Google Place identifier, together with the moment they were resolved.
Telephone number, where it appears on the label or is entered by the courier.
Consignment tracking code and number of parcels.
Agreed delivery time window, where one exists.
Free-text notes entered by the courier about that delivery.
Cash-on-delivery amount and whether it has been collected.
Delivery outcome, the time of delivery, and the reason recorded for a failed attempt.

Categories of personal data — team members

User identifier, nickname and full name, held in a profile shared with the Processor's StockManager application.
Role within the company (owner, manager, courier, read-only) and membership status.
Invitations issued by the Controller, including an email address where the Controller enters one.
Notification device token and platform, where the member enables notifications.

Data expressly not processed

The following are named here because their absence is a design decision, not an omission, and because the Controller is entitled to rely on it:

Label photographs. When a courier photographs a parcel label, text recognition runs on the device and the image is deleted in the same operation. It is never transmitted, and the database has no column able to hold it.
Proof-of-delivery photographs. They remain on the courier's device. The database stores only a file name that is meaningful on that one device; no image is ever uploaded.
Courier location history. The courier's position is requested only when route ordering is invoked, is used for that single calculation, and is not written anywhere.
Special categories of personal data under Article 9 GDPR. None are processed.

Nature and purpose of the processing

Collection, storage, organisation, retrieval, transmission to the sub-processors listed in Annex IV, and erasure, for the sole purpose of allowing the Controller to organise and carry out parcel deliveries: holding the round, ordering it, navigating to each address, recording the outcome and reconciling cash-on-delivery amounts. The data is not used for profiling, is not sold, and does not feed any analytics.

Duration of the processing

Recipient data: for as long as the delivery, and no longer. Name, address, phone, coordinates, notes and cash-on-delivery amount are erased by the database itself at the instant a stop is marked as delivered. What survives is the outcome, the number of parcels, the tracking code, the time, and the round's cash totals, which identify nobody.
Undelivered parcels keep their data while they remain work to be done. It is erased when the round is closed with the parcel left inside it as a record. If the parcel is moved to another round or sent for reassignment, the data persists until that delivery is completed.
Safety net: a nightly job erases anything that escaped both moments after 90 days. In practice it catches only rounds that were opened and never closed.
On request: the Controller's owner or manager can erase a specific recipient's data across the whole company immediately, from within the App.
Team member data: for the duration of the membership.
End of service: deleting the company deletes its rounds and deliveries. Deleting an account deletes everything belonging to it.

ANNEX III — Technical and Organisational Measures

The measures below are those in place at the version and date shown at the top of this page.

1. Access control, enforced by the database

Row-level security is enabled on every table holding delivery data. Authorisation is decided by the database on each row, not by the interface: a request made directly to the server returns exactly the same rows as the App.
A delivery is readable only by the courier it is assigned to and by whoever prepared the round. A colleague, and the company owner, receive nothing — not a redacted record, no record at all.
The view used for supervision exposes counts and times only. It has no column capable of carrying a recipient, an address or a photograph.
One documented exception: parcels that a courier has deliberately sent back for reassignment become visible to the company's owner and managers, so they can decide which courier takes them. Visibility ends when the parcel is assigned. It is enforced by a database policy, not hidden in the interface.

2. Minimisation by design

Label photographs are read on the device and destroyed; no server ever receives one.
The courier's location is never recorded.
The end-of-day report and the depot returns list, which are the two outputs that leave the phone by messaging app, contain codes, counts and reasons — never names or addresses.
Addresses sent for geocoding are sent without the recipient's name.

3. Storage limitation, enforced automatically

Database triggers erase recipient data on delivery and on closure of a round.
A scheduled nightly job erases anything older than 90 days that escaped both.
A dedicated function lets the Controller satisfy an erasure request across the whole company; it returns only the number of records affected, never their content, so exercising the right does not become a way to browse colleagues' deliveries.
Every erasure request handled is logged with the requester and the number of records, and with a one-way digest of the search term instead of the term itself.

4. Credentials and sessions

Session tokens are stored encrypted by the device hardware — iOS Keychain, Android Keystore — and are not readable from a filesystem dump.
Sign-in uses a nickname; no real email address is used as the login identifier.
The optional recovery email is stored encrypted, is never returned in full to the App, and is used solely to send a password reset link.
Passwords are stored hashed by the authentication provider; the Processor never sees them.

5. Transport and storage security

All traffic between the App and the server uses TLS.
Encryption at rest is provided by the infrastructure provider named in Annex IV.
Third-party API keys exist only as server-side secrets and are never included in the application bundle; calls to external mapping services pass through the Processor's own server functions.
Server functions reject any request without a valid authentication token, and authorise no browser origin, so they cannot be invoked from a web page.

6. Integrity of automated messages

The text of every push notification is composed on the server, not supplied by the App, and membership is re-verified server-side before sending. A user cannot cause an arbitrary message to appear on a colleague's phone.
Per-user hourly limits, held in the database and therefore shared across all server instances, cap calls to paid external services.

7. Data on the device

Automatic system backup of application data is disabled on Android.
On iOS the operating system offers no way to exclude the application's documents from iCloud backup. Where the user has backup enabled, proof-of-delivery photographs are copied there by the operating system. This is disclosed in the Privacy Policy.

8. Assisting the Controller

Account deletion is available inside the App and is immediate.
Data export is available inside the App and produces a structured, machine-readable file, satisfying Article 20 requests without the Controller having to ask the Processor.
The Processor assists the Controller with requests it cannot satisfy on its own, at the contact address in Annex I.

9. Security incidents

Notification to the Controller within 48 hours of becoming aware, as set out in section 4 above.
The Processor keeps a record of incidents affecting data processed under this DPA and makes it available to the Controller on request.

ANNEX IV — List of Sub-Processors

The Controller authorises the following sub-processors under Clause 7.7, Option 2.

1. Supabase Inc. (United States)

Role: database, authentication and server functions.
Data: all data described in Annex II.
Location of processing: servers within the European Union.

2. Google LLC — Google Maps Platform (United States)

Role: converting addresses into coordinates (Geocoding API) and computing the order of a round (Routes API).
Data: the delivery address and its coordinates, and — only when the courier asks for the round to be ordered — the courier's current position at that moment. Recipient names are never sent.
Location of processing: United States. See section on transfers below.

3. 650 Industries, Inc. — Expo (United States)

Role: delivery of push notifications and distribution of application updates.
Data: the notification device token and platform, and the text of the notification, which may contain a team member's nickname and the name of a round. No recipient data is sent.
Location of processing: United States.

Transfers outside the European Economic Area

Google and Expo are United States companies, so the data described above leaves the EEA. Those transfers rest on the safeguards each provider declares it adopts under Articles 44-46 GDPR — adherence to the EU-US Data Privacy Framework, or standard contractual clauses approved by the European Commission. Supabase stores data on servers inside the European Union.

Acceptance

This DPA is accepted inside the ScanDrop app by the person who creates a company, before any delivery data is entered. The Processor records the accepting user, the date and time, and the version of this document. Where the Controller requires a signed paper counterpart, write to support@jkstudios.it.

Material changes to this document will be published here with a new version number, and the Controller will be asked to accept the new version in the App.