ROUTERRA TEAMS — DATA PROCESSING AGREEMENT

Last updated: August 17, 2026

This Data Processing Agreement (the “DPA”) governs our processing of personal data on your behalf when you use Routerra Teams. It is the agreement required by Article 28(3) of the GDPR between you as controller and us as your processor.

In this DPA, “Routerra”, “we” and “us” mean the entity identified in section 1. “Customer” and “you” mean the business that subscribes to Routerra Teams. “the Terms” means the Routerra Teams Terms of Service.

1. This DPA, and how it is concluded

This DPA forms part of the Terms and is concluded when you accept them. Section 9 of the Terms says so, and this page is the document it refers to. By accepting the Terms — by creating a team or by using Routerra Teams — you enter into this DPA with us in the version published at /teams/dpa at that time, in satisfaction of Article 28(3) GDPR. There is no separate signature step, no extra checkbox and no negotiation: the agreement exists from the moment you accept the Terms.

The parties. The processor is Routerra Anatolii Trubin, a sole proprietorship registered in Poland, ul. Na Zjeździe 11, lok. 5p, 30-527 Kraków, Poland, NIP 6793319069, REGON 540576549, info@routerra.io. The controller is the business that accepted the Terms and holds the Routerra Teams subscription, identified by the team and the billing details in your account. We have not appointed a data protection officer; we are not required to.

Precedence. Where this DPA and the Terms say different things about the processing of personal data, this DPA prevails. Where this DPA and the Standard Contractual Clauses referred to in section 13 say different things, the Standard Contractual Clauses prevail. Everything else in the Terms continues to apply unchanged.

Duration. This DPA takes effect when you accept the Terms and lasts for as long as we process personal data on your behalf — which is longer than your subscription, because of the retention periods in Annex IV and section 11. We may change this DPA, and a material change follows the notice process in section 14 of the Terms.

A signed copy. If your organisation needs a signed copy for its records, ask us at info@routerra.io and we will provide one. That copy records these same terms — requesting it does not change them, and it is not a precondition of this DPA being in force.

2. Definitions and roles

Definitions. “GDPR” means Regulation (EU) 2016/679. “UK GDPR” means the GDPR as it forms part of the law of England and Wales, Scotland and Northern Ireland. “EU SCCs” means the Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914. “UK Addendum” means the UK International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018. “Customer Personal Data” means the personal data within the Customer Data that we process on your behalf, as described in Annex I. “Sub-processor” means a processor engaged by us to process Customer Personal Data. “controller”, “processor”, “data subject”, “personal data”, “processing”, “personal data breach” and “supervisory authority” carry the meanings given to them in the GDPR.

You are the controller of Customer Personal Data and we are your processor. That covers everything you or your team members and drivers upload to, or generate in, Routerra Teams: recipient names, addresses, coordinates, delivery notes and time windows; your driver roster; your team membership and invitations; proof-of-delivery photos; your team audit log; and, where live tracking is enabled for your team, Navigation Connect trip and position data. Annex I describes it in full.

Where you are not yourself the controller of some of that data — for example where you handle deliveries for another business that decides what happens to the recipients’ data — you act as that controller’s processor and we act as its sub-processor. In that case you warrant that you have the authority to instruct us on that controller’s behalf and to enter into this DPA for it, and every reference to “you” in this DPA is to be read as including that authority.

Where we are a separate controller. We are an independent controller, not your processor, for five things:

1. the sign-in accounts of your administrators and of your drivers — the email address, name, authentication identity and personal preferences held against the person, rather than against your team; drivers sign in to the driver app through the same authentication provider your administrators use;
2. billing;
3. our own product telemetry, including the crash and error diagnostics our own apps report to us when something in them goes wrong;
4. our support communications with you and your administrators, including the support chat in the dashboard;
5. security and abuse handling.

This DPA does not govern that processing; our Privacy Policy does. The dividing line runs where the data came from: an account a person creates for themselves is ours to answer for; what you invite, enter, import or generate inside your team is yours, and we process it only for you. A driver is the clearest illustration of the line, because both sides of it exist for the same person: the account they sign in with is ours, while the entry you created for them on your driver roster — name, email, vehicle, shift, depot — is yours, and we hold it as your processor. Section 8 explains what follows from that when a driver closes their account.

3. Subject matter, duration, nature and purpose of the processing

Article 28(3) requires this agreement to set out the subject matter and duration of the processing, its nature and purpose, the types of personal data, the categories of data subject and the obligations and rights of the controller. Annex I sets out the first five, and it is part of this DPA rather than background information.

Your obligations and rights as controller are the last of those requirements, and they are set out in sections 2 and 4 of the Terms, which form one agreement with this DPA under section 1. Under section 4 of the Terms: you decide what goes into Routerra Teams; you warrant that you have a lawful basis under the GDPR for the personal data of your recipients and of your drivers and staff, and the right to disclose it to us; and you are responsible for the information those people must be given under Articles 13 and 14 and for handling their requests. Under section 2 of the Terms: the roles and permissions inside your team are yours to set and to review — we do not manage them for you — and you are responsible for the use your team makes of the service, including removing members and drivers who should no longer have access. Against those obligations you hold the rights this DPA gives you — to instruct us (section 4), to object to a sub-processor (section 7), to our assistance (sections 8 to 10), to delete or return your data (section 11), and to information and audit (section 12). We reproduce the summary here so that this document read on its own contains every term Article 28(3) requires.

In summary: the subject matter is our provision of Routerra Teams to you. The nature of the processing is the collection, recording, organisation, structuring, storage, retrieval, consultation, use, transmission and erasure of Customer Personal Data by automated means, together with its disclosure to the sub-processors in Annex III and to any destination you configure yourself. The purpose is to provide the service and nothing else: planning and optimising routes, geocoding addresses, dispatching routes to your drivers, notifying your recipients where you turn notifications on, recording proof of delivery, keeping your team audit log, and — where live tracking is enabled for your team — recording navigation status.

The duration is the term of the Terms, extended by the retention periods in Annex IV, by the deletion process in section 11, and by any period a law that applies to us requires. The categories of data subject are your team members and administrators, your drivers, and the recipients of your deliveries — people who are not our users and who have no relationship with us at all. The types of personal data are listed in Annex I, Part B.

4. Processing only on your documented instructions

We process Customer Personal Data only on your documented instructions, including in relation to transfers of that data to a third country or an international organisation. Your documented instructions are: the Terms, this DPA, the configuration choices and features you use in the product (which are instructions in themselves — turning on notifications, connecting an integration, enabling live tracking, deleting a stop), and any further instruction you give us in writing to info@routerra.io.

We do not process Customer Personal Data for our own purposes. We do not sell it, we do not use it for advertising, and we do not use it to train our own models. Where a sub-processor helps parse the files you import, it does so under API terms that exclude the use of that content for model training.

Where a law of the European Union or of a Member State that applies to us requires us to process Customer Personal Data other than on your instructions, we will tell you about that legal requirement before processing, unless that law prohibits telling you on important grounds of public interest.

If we think an instruction infringes data-protection law, we will tell you. We will inform you immediately if, in our opinion, an instruction infringes the GDPR or another data-protection provision of the Union or a Member State, and we may pause the processing concerned until the instruction is confirmed or changed. We are not obliged to give you legal advice, and telling you does not shift responsibility for the instruction onto us.

5. Confidentiality of personnel

We ensure that the people we authorise to process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that the commitment survives the end of their engagement with us. We grant that authorisation only to those who need the access to provide, secure or support the service for you, we limit it to what that work requires, and we withdraw it when it is no longer needed. Those people are instructed to process Customer Personal Data only on your instructions as passed on by us.

6. Security of the processing

We implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Article 32 GDPR, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risk to the rights and freedoms of the people whose data it is.

The current description of those measures is our Security page, read together with Annex II of this DPA. That page is the operative description for the purposes of Article 32 and of Annex II of the Standard Contractual Clauses, in the version published at the relevant time.

Measures change; protection does not go backwards. We may update our technical and organisational measures over the life of this agreement — that is what keeping security appropriate to the state of the art means. We will not make a change that reduces the overall level of protection of Customer Personal Data below the level described when you accepted this DPA. You are responsible for the security of your own side: your team members’ and drivers’ credentials, the roles and permissions you set inside your team, and what you do with the data once you take it out of the service or send it to a destination you configure.

7. Sub-processors

You give us a general written authorisation to engage sub-processors to help provide Routerra Teams, on the terms of this section. The sub-processors engaged at the date of this page are listed in Annex III, and the current, authoritative list is the Teams table on our sub-processors page.

Notice of changes, and your right to object. Before a new or replacement sub-processor starts processing Customer Personal Data, we publish the change on the sub-processors page and give your team administrators at least 30 days’ notice by email or by notice in the dashboard. You may object within those 30 days on reasonable data-protection grounds, by writing to info@routerra.io and telling us what the grounds are. We will then work with you in good faith to find a solution — a configuration that avoids the sub-processor, an alternative provider, or additional safeguards. If we cannot find one within a reasonable time, you may terminate the affected part of the service, or the subscription, without penalty, and we will refund prepaid fees for the unused remainder of your term. Where we must appoint a sub-processor at short notice to keep the service secure or available, we may do so with less than 30 days’ notice and will tell you as soon as we can; your right to object is unaffected. This is the objection process that section 14 of the Terms refers to.

Terms we impose on them, and our liability. We engage each sub-processor under a written contract that imposes the same data-protection obligations as are set out in this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets the requirements of the GDPR. Where a sub-processor fails to fulfil those obligations, we remain fully liable to you for the performance of that sub-processor’s obligations.

Twilio is not a Routerra sub-processor. Saying so explicitly, because its absence from the list would otherwise look like an oversight: SMS notifications run on your own Twilio account. You supply the account SID and auth token, we store them encrypted, and we use them only to send messages on your behalf at your instruction. Twilio is therefore your processor under your own contract with Twilio, not ours — the data-protection arrangement with Twilio is yours to make, and Twilio is deliberately absent from Annex III and from the sub-processors page. The same is true of any other integration you configure with your own credentials, and of any outbound webhook you point at a system you operate: those destinations are yours, not our sub-processors.

8. Assisting you with data subject rights

Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures, insofar as this is possible, in fulfilling your obligation to respond to requests to exercise the rights of data subjects under Chapter III of the GDPR — access, rectification, erasure, restriction, portability, objection, and rights in relation to automated decision-making.

The first and usually the fastest of those measures is the product itself: the dashboard lets you find, correct and delete the records in your team — stops, address-book entries, drivers and team members — without needing us. Where a request cannot be satisfied that way, write to info@routerra.io and we will help within a time that lets you meet your own deadline under Article 12(3).

If a driver or a recipient comes to us directly, we send them to you. We are not their controller and we must not act on a request about your team’s data without your instruction. So we will not disclose, correct or erase Customer Personal Data on the strength of a request from the data subject; we will tell the person, promptly and without making it a run-around, that the controller is their employer or the business they ordered from, and we will notify you of the request without undue delay so that your own clock starts. This is what makes the “go to your employer” sentence in our Driver Privacy Notice an honest one rather than a deflection.

One consequence is worth stating plainly. If a driver closes the personal account they use to sign in, that closure revokes their access to your team, but it does not delete their entry on your driver roster — the roster is your record, and we do not delete a controller’s records without the controller’s instruction. A driver’s erasure request therefore runs through you, and we will act on it when you tell us to.

9. Assisting you with Articles 32 to 36

Taking into account the nature of the processing and the information available to us, we assist you in ensuring compliance with your obligations under Articles 32 to 36 GDPR: security of processing (Article 32), notification of a personal data breach to your supervisory authority and to data subjects (Articles 33 and 34), data protection impact assessments (Article 35) and prior consultation of a supervisory authority (Article 36). Section 10 covers breaches specifically.

Data protection impact assessments. The obligation to carry out a DPIA is yours, as controller; we cannot do it for you, because it turns on why you are processing and what your alternatives are, which only you know. What we do is supply the information we hold — this DPA, our Security page, Annex III, the retention periods in Annex IV, and answers to reasonable written questions about how the service works — so that your assessment describes the processing accurately.

Live driver tracking is likely to require a DPIA from you. Live driver tracking is an optional feature. It is off by default and is enabled per team; where it has not been enabled for your team, no driver position data is collected at all and this paragraph does not apply to you. Where you do enable it, you are systematically monitoring the location of workers — processing that appears on supervisory authorities’ Article 35(4) lists of operations requiring a data protection impact assessment, and one that will in most cases meet the general test in Article 35(1): systematic monitoring of people who are in a position of dependence on you. The assessment is yours to carry out, as is the employment-law basis, any consultation with employee representatives or works councils your jurisdiction requires, and the notice to your drivers. We will give you what we hold: what is collected, when it is collected, who can see it, how long it is kept, and where the driver’s own controls sit. Enabling the feature is your instruction to us as your processor.

10. Personal data breaches

We notify you without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, so that you can meet your own obligations under Articles 33 and 34 — including the 72-hour deadline for notifying your supervisory authority where the breach is notifiable. We notify you at the email addresses held for your team administrators.

Our notification will include the information we hold at the time: the nature of the breach, the categories and approximate number of data subjects and records concerned where we can establish them, the likely consequences, and the measures we have taken or propose to take to address it and to mitigate its effects. Where we cannot provide all of it at once, we provide it in phases without further undue delay rather than waiting until the picture is complete. We also give you reasonable further assistance to investigate and to document the breach.

The decision to notify a supervisory authority or the affected data subjects is yours, and we do not make it on your behalf unless you ask us to and we agree in writing. Our notifying you is not an admission of fault or liability.

11. Deletion or return at the end of the service

At the end of the provision of the service, we delete or return Customer Personal Data at your choice, and delete existing copies, unless a law of the Union or of a Member State that applies to us requires us to keep it. This is the deletion arrangement that section 13 of the Terms refers to.

How to choose, and what happens if you do not. Your access to the service ends when your subscription does — section 13 of the Terms says so, and this DPA does not give you a longer login. What it gives you is a 30-day grace period during which we keep Customer Personal Data rather than deleting it, so that the choice Article 28(3)(g) gives you is a real one after access has gone. Within those 30 days, ask us at info@routerra.io to return the data or to delete it. If you ask for it back, we return it in a commonly used machine-readable format. If you do not tell us, we treat that as an instruction to delete, and we delete Customer Personal Data within 90 days of the end of the subscription.

Before that, while you still have access. The product lets you download an individual route as a CSV, XLSX or PDF file, so if the routes are what you need, take them before your subscription ends. There is no bulk export of your whole team, and none of your address book, your driver roster or your audit log — so for anything beyond individual routes, the return obligation in the paragraph above is the route to it, and it is ours to perform rather than yours to work around.

You can delete it yourself, at any time. Deleting a team in the product removes that team’s data. You do not need to wait for the end of your subscription and you do not need us to do it. Individual records — stops, address-book entries, drivers — can be deleted in the product at any time. What that removal covers, and what it does not cover immediately, is set out in the paragraph below and in section 7 of our Security page, which between them are the only description of it — this agreement does not restate it anywhere else.

The team audit log, and the record of the deletion. What the release does: a backend release published alongside this agreement adds the database-level cascade that removes the team audit log along with the team. It removes the audit entry recording the deletion too — that entry is written in the same operation that deletes the team — so once it is deployed nothing in the audit log outlives the team. What is true until it deploys: audit entries for a deleted team remain, including entries left behind by teams deleted earlier; the release removes those as it goes in, and we will delete them sooner at your request. Either way, do not rely on the audit log as your own record that a team was deleted — take what you need before you delete, or ask us at info@routerra.io and we will confirm a deletion in writing.

Residual copies, and what we must keep. Where a copy of Customer Personal Data survives deletion in system backups or in operational logs, we do not restore it into the live service except to recover from an incident, and it stays subject to this DPA — the confidentiality, security and transfer terms above — until it is overwritten or expires in the ordinary course. Separately, some records are ours to keep rather than yours to delete: billing records are retained for the period Polish accounting law prescribes, roughly five years, and we hold those as a controller under our Privacy Policy rather than as your processor. The retention periods that apply while the service is running are in Annex IV.

12. Audits and information

We make available to you all information necessary to demonstrate compliance with the obligations in Article 28 and allow for and contribute to audits, including inspections, conducted by you or by an auditor you mandate.

In the first instance that obligation is satisfied by this page, by our Security page, by the Teams table on our sub-processors page, and by our written answers to a reasonable security or data-protection questionnaire. We would rather answer a real question than send you a certificate that does not address it.

Where that is genuinely not enough to demonstrate compliance, you may audit us: on at least 30 days’ written notice, during business hours, in a way that does not disrupt the service or compromise the confidentiality or security of other customers’ data, and no more than once in any 12-month period — unless a supervisory authority requires it, or you are following up a personal data breach affecting your data, in which case there is no such limit. The auditor must not be a competitor of ours and must be bound by confidentiality obligations; audit findings are our confidential information. Each party bears its own costs, and you reimburse our reasonable costs where an audit goes beyond a single working day of our time.

13. International transfers

Start from where we are: Routerra is established in Poland, which is in the EEA. A customer in the EEA sending personal data to us is therefore making an intra-EEA transfer, which needs no transfer mechanism at all. The transfer that does need one is the onward transfer from us to sub-processors outside the EEA — above all our hosting in Amazon Web Services’ us-east-1 region in the United States, where the product data lives. We say this plainly because the modules of the Standard Contractual Clauses are chosen by who is transferring to whom, and getting that backwards produces a contract that protects nobody.

Module 3 (processor to sub-processor) is the operative mechanism. Where we transfer Customer Personal Data to a sub-processor outside the EEA, that transfer is made under Module 3 of the EU SCCs, which are incorporated into this DPA by reference and which you, as controller, authorise us to enter into with each such sub-processor on your behalf. Where a sub-processor also holds a current certification under the EU–U.S. Data Privacy Framework, that certification applies in addition; we do not rely on it in place of the Clauses. One exception we name because it matters: OpenAI is not certified under the Data Privacy Framework, and transfers to OpenAI rely on the Standard Contractual Clauses alone. Some sub-processors are in the EEA and involve no transfer at all — GraphHopper in Germany, TomTom in the Netherlands and Hotjar in Malta.

Module 2 applies to the extent it is required. If your own arrangement makes a controller-to-processor transfer out of the EEA necessary — for example because we agree to a deployment or an arrangement that puts Customer Personal Data outside the EEA at your instruction — Module 2 of the EU SCCs is incorporated into this DPA for that transfer, with you as data exporter and us as data importer. Module 2 is included here so that a customer who needs it has it, not because it is the normal case; where a transfer does not require it, it does not apply.

United Kingdom. Where a transfer is subject to the UK GDPR, the EU SCCs apply as modified by the UK International Data Transfer Addendum, which is incorporated into this DPA and completed as follows: the Addendum’s Tables 1 to 3 are populated by section 1 and Annexes I to III of this DPA, and in Table 4 neither party may end the Addendum when the ICO issues a revised approved addendum. Where a transfer is subject to Swiss law, the EU SCCs apply with the adjustments the Swiss Federal Data Protection and Information Commissioner requires, references to the GDPR being read as references to the Swiss Federal Act on Data Protection.

How the Clauses are completed. For both modules: Annex I of the Clauses is Annex I of this DPA; Annex II of the Clauses is Annex II of this DPA read with our Security page; Annex III of the Clauses is Annex III of this DPA. The optional docking clause (Clause 7) applies. For Clause 9, option 2 — general written authorisation — is selected, with the notice period in section 7 of this DPA. The optional wording in Clause 11(a) about an independent dispute-resolution body is not selected. The governing law under Clause 17 is the law of Poland and the forum under Clause 18(b) is the courts of Poland, which matches section 15 of the Terms.

Both modules attach only to the extent required. Nothing in this section creates a transfer mechanism for a transfer that does not need one, and nothing in it should be read as an admission that a particular transfer is a restricted transfer. Where a transfer needs a mechanism and none of the above covers it, we will not make it. Our sub-processors and their locations are in Annex III, and changes are published on the sub-processors page.

14. California: service provider terms

This section applies to the extent the California Consumer Privacy Act as amended by the California Privacy Rights Act (the “CCPA”) applies to personal information we process for you. Terms used here — business, service provider, personal information, sell, share — carry the meanings the CCPA gives them.

You are the business and we are your service provider. Personal information is disclosed to us only for the limited and specified business purpose of providing Routerra Teams to you, as described in section 3 and Annex I. We do not sell and do not share personal information within the meaning of the CCPA, and we do not accept it as consideration for anything.

We will not retain, use or disclose personal information for any purpose other than performing the service for you, or as otherwise permitted by the CCPA; we will not retain, use or disclose it outside the direct business relationship between you and us; and we will not combine it with personal information we receive from another source, except where the CCPA permits a service provider to do so. We certify that we understand these restrictions and will comply with them.

We will assist you in responding to verifiable consumer requests, will tell you if we determine that we can no longer meet our obligations under the CCPA, and will allow you to take reasonable and appropriate steps to stop and remediate any unauthorised use of personal information. Our engagement of sub-processors follows section 7, and each is engaged as a service provider or contractor under a contract with equivalent restrictions.

15. Annex I — Description of the processing

This Annex is Annex I of the Standard Contractual Clauses for both modules referred to in section 13.

A. The parties

Data exporter / controller / business: the Customer — the business that accepted the Terms and holds the Routerra Teams subscription. Contact: the team administrators identified in your account. Activities relevant to the transfer: use of Routerra Teams to plan, dispatch and record deliveries. Role: controller (or, in the case described in section 2, processor).

Data importer / processor / service provider: Routerra Anatolii Trubin, ul. Na Zjeździe 11, lok. 5p, 30-527 Kraków, Poland, info@routerra.io. Activities relevant to the transfer: providing Routerra Teams. Role: processor. Where Module 3 applies, Routerra is the data exporter and the sub-processor in Annex III is the data importer.

B. Description of the processing

Categories of data subject. The processing concerns:

• your team members and administrators — the people you invite into your team and the roles you give them (their own account records are ours as controller, as section 2 explains; their membership, invitation and activity inside your team is yours);
• your drivers — the people on your roster who receive routes in the driver app;
• the recipients of your deliveries — your own customers, who are third parties to this agreement, who are not our users, and whose data reaches us only because you put it there;
• any other individual whose personal data you choose to enter into a free-text field.

Categories of personal data.

What this table no longer lists, and why. An earlier version of this Annex included an offline-sync ledger among the categories of personal data. It is not one, and we have removed it rather than leave an over-declaration standing. That record has four fields — a row identifier, an opaque operation identifier generated by the driver app, and two timestamps. It carries no team identifier, no driver identifier and no content of the operation, so it records that an edit made offline has already been applied, not what the edit contained or whose it was. It exists so that the same edit is not applied twice when a driver’s phone reconnects.

Being personal data of nobody, it is neither Customer Personal Data nor data we hold as controller: it sits outside the division of roles in section 2 altogether, rather than on either side of it — section 2’s list of the things we are controller for is exhaustive, and this is not one of them. Annex IV continues to state how long it is kept, so nothing about it is hidden by its removal from this table.

Sensitive data. Routerra Teams does not ask for special categories of personal data under Article 9, or for data relating to criminal convictions and offences under Article 10, and it has no field designed to hold them. Free-text fields — delivery notes in particular — will hold whatever you type into them, so do not enter special-category data there. If you do, you do so as controller and on your own basis, and the restrictions and safeguards you must apply are yours to determine.

Frequency of the transfer. Continuous, for as long as you use the service.

Nature and purpose of the processing. As described in section 3: providing Routerra Teams — route planning and optimisation, geocoding, dispatch to drivers, delivery notifications where you enable them, proof of delivery, the team audit log, and navigation status where live tracking is enabled for your team. No other purpose.

Duration of the processing. The term of the Terms, extended by the retention periods in Annex IV, by the deletion process in section 11, and by any period a law that applies to us requires.

Automated decision-making. Route optimisation orders and assigns stops by automated means. It does not produce legal effects concerning a data subject or similarly significantly affect them, and it is not profiling of the recipients — but we describe it here so that your own assessment of Article 22 can start from what the product actually does.

Sub-processors. Subject matter, nature and duration of the processing carried out by each sub-processor: as set out in Annex III, for the duration of our engagement of that sub-processor and the retention periods that apply to the data concerned.

C. Competent supervisory authority

Where Module 3 applies and we are the data exporter, the competent supervisory authority is the Polish authority: Prezes Urzędu Ochrony Danych Osobowych (President of the Personal Data Protection Office), Warsaw, Poland. Where Module 2 applies and you are the data exporter, the competent supervisory authority is determined under Clause 13 of the EU SCCs by reference to your establishment or your Article 27 representative. Where the UK Addendum applies, it is the UK Information Commissioner’s Office.

16. Annex II — Technical and organisational measures

This Annex is Annex II of the Standard Contractual Clauses. The current and fuller description of our technical and organisational measures is our Security page, which forms part of this Annex in the version published at the relevant time. The measures below are the ones this agreement commits us to, stated at a level we can stand behind rather than as a catalogue.

• Measures of pseudonymisation and encryption. Traffic between the dashboard, the driver app and our backend, and traffic to our public web surfaces, runs over HTTPS/TLS. Integration credentials you supply — your Twilio account SID and auth token — are stored encrypted with AES-GCM. Our own server-side product telemetry for Teams is keyed to the team rather than to a person and carries no personal identifiers. The dashboard’s own browser-side analytics — pageviews, a named set of product events, and automatic error reports — is keyed to an anonymous device identifier and is never linked to a named person; we do not say it carries no personal data at all, because an error report can include a stack trace incidentally. Driver-app diagnostics are device-pseudonymous.
• Measures for ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services. The Teams platform runs on Amazon Web Services in the us-east-1 region — compute, a PostgreSQL database and object storage for attachments — and is a separate system from our consumer product, with no dependency on it. Events published to us by Google Navigation Connect are accepted only when authenticated by the publisher’s signed token.
• Measures for user identification and authorisation. Administrators and drivers authenticate through our authentication provider (Annex III). Access inside a team is governed by the role you give each member, which is yours to set and to review. Access by our own personnel is limited to those who need it, under the confidentiality commitment in section 5.
• Measures for ensuring events logging and accountability. Every mutating action in a team is written to the team audit log with the acting member and a record of the change, which is available to you and which we use to reconstruct what happened after an incident. Infrastructure logs and metrics are collected for the operation and security of the service.
• Measures for data minimisation and data quality. The data in your team is the data you put there — we do not enrich it, buy it in or add fields of our own. Advertising identifiers are actively blocked in the driver app.
• Measures for ensuring limited data retention and for deletion. Scheduled deletion jobs enforce the retention periods in Annex IV; the Status column there records which of them are live today. Deleting a team removes that team’s data; what that removal covers, and what it does not cover immediately, is described in section 11 and in section 7 of the Security page that forms part of this Annex, and nowhere else in this agreement. Deletion terms on termination are also in section 11.
• Measures for ensuring accountability. This DPA, the published sub-processor list, the published retention periods and the information and audit rights in section 12.
• Measures to be taken by sub-processors to provide assistance to the controller. Each sub-processor is engaged under a contract imposing the obligations in section 7, including assistance obligations equivalent to ours under sections 8 to 10.

We publish this list rather than a longer one because everything in it is something we can point at. Where you need assurance about a measure not named here, ask under section 12 and we will answer in writing.

17. Annex III — Sub-processors

This Annex is Annex III of the Standard Contractual Clauses and the list of sub-processors you authorise under section 7, as at the date at the top of this page. The current, authoritative list is the Teams table on our sub-processors page, where changes are published and from which the notice period in section 7 runs.

‡ Engaged for our own processing, not for yours. These four are engaged for processing we carry out as an independent controller under section 2, rather than for the processing of Customer Personal Data described in Annex I. Each maps to one of the categories section 2 lists: Lemon Squeezy to billing; PostHog and Bugsnag to our own product telemetry, Bugsnag being the crash and error diagnostics part of it; and Tawk.to to our support communications. Section 2’s fifth category, security and abuse handling, has no marked vendor of its own: it runs on infrastructure that appears unmarked in this table — our DNS and proxy provider, our logging and metrics provider and our internal alerting provider — and those vendors stay unmarked precisely because the same systems also carry and hold Customer Personal Data, so we treat them as full sub-processors rather than splitting them. Strictly, the four marked here are therefore not sub-processors within the definition in section 2, and our Privacy Policy is what covers them in that capacity. We list them here anyway, for two reasons. You should be able to see every vendor standing behind the service from one table, without having to work out which document a name would have appeared in. And the boundary is not always clean — an administrator can paste anything into a support chat, and a crash or an analytics event can carry more context than it was designed to. So we bind them as if they were sub-processors: to the extent any of them does receive Customer Personal Data, it is engaged on the terms of section 7 and this DPA applies to it. Nothing here narrows Annex IV, which keeps our telemetry and crash-reporting retention outside this DPA in the ordinary case.

Twilio does not appear in this table on purpose — see section 7. SMS runs on your own Twilio account, so Twilio is your processor and not ours.

18. Annex IV — Retention periods

These are the periods after which we delete each kind of record while the service is running. They are enforced by scheduled deletion jobs rather than by manual clean-up, and the Status column records which of those jobs are running today. Section 11 governs what happens at the end of the service, and section 8 covers deletion on your instruction — nothing below stops you deleting a record sooner.

† Enforcement release pending. These two periods are our commitment under this agreement from the date at the top of this page, and we will honour them. The scheduled job that enforces each of them automatically ships in a backend release published alongside this agreement. Until that release is live, records in these two areas may be older than the period stated; ask us at info@routerra.io and we will delete anything older than the period on request. We will remove this note when the release is deployed.

Records with no fixed period, because you control them. Stops and recipients, address-book entries, your driver roster, your team members and their roles are kept until you delete them or delete the team. Invitations are kept until they are accepted or revoked. They have no automatic expiry because deciding how long you need your own operational records is a controller’s decision, not ours.

Records we keep as controller, not as your processor. Billing records are retained for the period Polish accounting law prescribes, roughly five years. Our own product telemetry and our driver-app diagnostics are held for our analytics provider’s retention period, one year on the plan we are on. Those are covered by our Privacy Policy, not by this DPA.

Contact

Questions about this DPA, sub-processor objections, requests for a signed copy, audit requests and data subject requests:

info@routerra.io
Routerra Anatolii Trubin, ul. Na Zjeździe 11, lok. 5p, 30-527 Kraków, Poland

Related documents: Teams Terms of Service, Security, Driver Privacy Notice, Sub-processors, Privacy Policy.