ROUTERRA TEAMS — SECURITY

Last updated: August 17, 2026

This page describes the technical and organisational measures we apply to Routerra Teams data. It is not marketing copy: section 6 and Annex II of our Data Processing Agreement make this page the operative description of those measures for the purposes of Article 32 GDPR and of Annex II of the Standard Contractual Clauses, in the version published at the relevant time.

Because of that, everything below is something we can point at in our own code or configuration. Where a control that a security questionnaire would normally ask about does not exist yet, we say so at the end rather than describe it vaguely enough to pass. If you need assurance about something we have not named, ask us under section 12 of the DPA and we will answer in writing.

1. Hosting and data location

Routerra Teams runs on Amazon Web Services in the us-east-1 region in the United States. That is where the product data lives: compute, the database and object storage are all in that region.

• Database. Team data is held in a dedicated PostgreSQL database on Amazon RDS. The instance is not publicly reachable from the internet.
• Object storage. Attachments — proof-of-delivery photos and address-book files — are stored in Amazon S3, in a bucket with public access blocked at the bucket level.
• Separation from our consumer product. The Teams backend is a separate application from our consumer route planner and has no dependency on it.

Routerra itself is established in Poland, in the EEA. A customer in the EEA sending us personal data is therefore making an intra-EEA transfer; the transfer that needs a mechanism is ours onward to sub-processors outside the EEA, above all this hosting. Section 13 of the DPA sets out the Standard Contractual Clauses that cover it.

2. Encryption

In transit. All traffic between the Teams dashboard, the driver app and our backend, and all traffic to our public web surfaces, runs over HTTPS/TLS. The driver app on iOS is additionally configured to refuse cleartext HTTP outright and to require TLS 1.2 or higher with forward secrecy on connections to our domains.

At rest.

• Database. RDS storage encryption is enabled, using an AWS KMS key. Snapshots inherit that encryption.
• Object storage. The attachments bucket applies SSE-S3 (AES-256) server-side encryption by default to every object, and rejects customer-provided encryption keys.

Application-level encryption of secrets. Some values are encrypted by us before they reach the database, so that database access alone does not yield them:

• Integration credentials you supply — your Twilio account SID and auth token — are encrypted with AES-256-GCM (a fresh random initialisation vector per record and a 128-bit authentication tag) before storage. The auth token is never returned by any API response; it is decrypted only at the moment of sending a message. The account SID is returned to your own administrators when they read the integration settings, so that they can see which Twilio account is connected.
• Webhook signing secrets are encrypted with AES-GCM under a separate key-encryption key.
• API keys are not stored at all. We keep only a SHA-256 hash of the key and its first eight characters, so a key that is lost cannot be recovered from us — it can only be revoked and reissued.

Attachment access. Attachment objects are never public. Uploads and downloads use time-limited pre-signed requests that expire one hour after they are issued, and object keys are namespaced by team.

3. Access control

Authentication. Administrators and drivers sign in through Clerk, our authentication provider, and every request to the Teams backend carries a Clerk-issued JWT that we validate against Clerk’s published signing keys. The backend keeps no server-side sessions. Every endpoint requires an authenticated caller except health checks, metrics, the API documentation, and the webhook receivers in section 5 — which authenticate their callers by signature instead, because the caller is a provider rather than a person.

Authorisation is per team, on every team-scoped endpoint. An endpoint that operates on a team resolves the caller’s membership of that team and the permission their role grants before it does anything — @PreAuthorize("@teamSecurity.has(...)") in our code. Being signed in is not enough; being a member of some other team is not enough.

An architecture test fails the build if an endpoint is left unguarded. Rather than rely on review to catch a missing check, a test enumerates every HTTP endpoint whose path contains a team identifier and fails if any of them lacks an authorisation annotation. It runs in continuous integration on every pull request, so an unguarded team-scoped endpoint cannot merge.

Roles and permissions are yours. You decide who is in your team and what role each member holds; we enforce the role you set. Reviewing that membership is a control only you can exercise, and it is the one we would ask you to exercise most often.

Our own access. Access by Routerra personnel is limited to the people who need it to provide, secure or support the service, under the confidentiality commitment in section 5 of the DPA, and is withdrawn when it is no longer needed.

4. Tenant isolation

Routerra Teams is a multi-tenant service, so isolation between teams is a property of the schema rather than a matter of care: every table holding team data is scoped to a team — by a mandatory team identifier with a foreign key to the team, or through a parent record that carries one — and the team identifier that scopes a request comes from the URL and is checked against the caller’s membership before any query runs.

The same holds in object storage: attachment keys are namespaced by team (pod/<team>/… and ab/<team>/…), and the pre-signed request that grants access is issued for one specific object. What happens to a team’s data when the team itself is deleted is set out in section 7.

5. Webhooks and API keys

Outbound webhooks are signed. Every delivery to an endpoint you configure carries an HMAC-SHA256 signature computed over a timestamp and the exact request body, sent as t=<unix-seconds>,v1=<hex-digest>. Verify it at your end before trusting a payload, and use the signed timestamp to reject deliveries that are older than you are willing to accept — that is what makes replaying an old, validly signed delivery ineffective. The signing secret is held encrypted, as section 2 describes. Delivery records are retained for 30 days (section 7).

Inbound webhooks are verified. Callbacks we receive from our authentication and billing providers are accepted only when their signature verifies and their timestamp is within tolerance, and navigation events published to us by Google Navigation Connect are accepted only when authenticated by the publisher’s signed token.

API keys are issued per team. A key belongs to one team, can be named, can be given an expiry date, can be disabled or revoked at any time, and records when it was last used. The key value is shown once at creation and stored only as a hash (section 2). Deleting the team deletes its keys.

6. Logging and monitoring

Application and infrastructure logs. Server logs and metrics are collected for the operation and security of the service. Log lines carry a request identifier, the acting account’s identifier and — where the request is team-scoped — the team identifier, so an incident can be reconstructed. Our logs and metrics provider is listed on our sub-processors page.

Error alerting, and what an alert contains. Errors raise an alert into an internal channel so that we see them without waiting for a report. An alert carries the acting account’s identifier, the team name and identifier, the role, and the request identifier — enough to find the request — together with the error itself. It used to carry the signed-in person’s email address as well; that field has been removed in the same backend release as the two retention jobs marked “enforcement release pending” in section 7, so until that release is deployed the email address is still included.

We will not overstate the effect of that change. The alert also carries the error message and stack trace, and those can contain personal data incidentally — a message body, a recipient address, whatever the failing operation was handling. So personal data of your administrators, drivers or recipients can still reach the alerting channel, which is why the provider that receives it is named on our sub-processors page and bound by the terms in section 7 of the DPA. What that release removes is the field that carried it by design; this incidental channel remains either way.

Audit log, which is yours to read. Every mutating action in a team is written to the team audit log with the acting member, the entity and a record of the change. It is not an internal-only log — it is available to you in the dashboard, and it is the first place to look when you need to know who changed what.

Cloud API activity. Administrative API activity in our AWS account is recorded to AWS CloudTrail.

7. Retention and deletion

These are the periods after which we delete each kind of record while the service is running. They are the same table as Annex IV of the DPA, including its Status column, which records which of the scheduled deletion jobs are running today. Nothing here stops you deleting a record sooner.

† Enforcement release pending. These two periods are our commitment from the date at the top of this page. The scheduled job that enforces each of them automatically ships in a backend release published alongside these documents. 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.

What happens when a team is deleted. Deleting a team removes the team record, and the database cascades that deletion through the tables holding that team’s data — members, invitations, settings, drivers, depots, zones, plans, routes, stops, the address book and its labels, attachment records, notification configuration and templates, delivery records, navigation trips and positions, webhook endpoints and their deliveries, API keys and integration configuration. The tables that have no team column of their own — a route, a delivery record, a navigation position — go with the parent record that does. What that removal covers, and what it does not cover immediately, is set out in the two paragraphs below — the only place on this page that describes it.

The team audit log, and the record of the deletion. What the release does: a backend release published alongside these documents 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.

Two things we describe as they are, not as they round off. Proof-of-delivery images: the records that make them reachable through the product go with the team immediately, but the image objects themselves are removed by the storage lifecycle rule at 365 days from upload rather than on the day the team is deleted. Address-book files: their deletion from object storage is attempted immediately after the team record is removed, but it happens outside the database transaction and is not retried — if it fails, the failure is logged and reconciled by hand rather than automatically. In both cases, if you need the data gone sooner or want confirmation that it is, ask us at info@routerra.io and we will remove it and tell you.

At the end of your subscription, section 11 of the DPA governs: a 30-day window in which to ask for your data back or ask us to delete it, and deletion within 90 days of the end of the subscription if you do not.

8. Backups

The production database has automated backups enabled: a daily snapshot taken in a fixed backup window, plus continuous transaction-log backup. Together these allow the database to be restored to a chosen point in time within a rolling one-day retention window. Backups inherit the storage encryption described in section 2, and they are held in the same region as the database.

What that does not include. Object storage — proof-of-delivery photos and address-book files — is not separately backed up and object versioning is not enabled, so a deleted or overwritten object is gone. There is no standby database in a second availability zone and no cross-region copy of backups.

We do not publish a recovery point objective or a recovery time objective, and we do not claim a restore-testing programme, because we do not have one to describe. The retention window above is the honest boundary of what a restore could recover, and we would rather give you that number than a target we have not measured.

9. Sub-processor management

Every vendor that stands behind Routerra Teams is listed, with its region, its purpose and the data it touches, on our sub-processors page. That page is the authoritative list; Annex III of the DPA reproduces it as at its own date.

Each sub-processor is engaged under a written contract imposing the same data-protection obligations as our DPA imposes on us, and we remain fully liable to you for their performance. Before a new or replacement sub-processor starts processing your data we publish the change and give your administrators normally at least 30 days’ notice, and you may object within those 30 days on reasonable data-protection grounds — with the exception that where we must appoint a sub-processor at short notice to keep the service secure or available, we may do so with less notice and will tell you as soon as we can, and your right to object is unaffected. Section 7 of the DPA sets out what happens then, up to and including terminating without penalty if we cannot find a solution.

Twilio is deliberately not on that list. SMS runs on your own Twilio account under your own contract with Twilio, using credentials you supply and we store encrypted. The same is true of any webhook endpoint you point at a system you operate: those destinations are yours, and what happens to data once it arrives there is outside our control and outside this page.

10. Incident response

When we become aware of a possible security incident we investigate first — establish what happened, what data and which teams are affected, and whether it is still happening — and contain it: revoking credentials or sessions, rotating secrets, and taking the affected path out of service if that is what it takes. The audit log and the request-scoped logs described in section 6 are what we reconstruct events from.

Where a personal data breach affects data we process for you, we notify you without undue delay after becoming aware of it, at the email addresses held for your team administrators, so that you can meet your own obligations under Articles 33 and 34 GDPR — including the 72-hour deadline for notifying your supervisory authority where the breach is notifiable. That commitment is section 10 of the DPA and this page does not narrow it.

Our notification carries what we know at the time — the nature of the breach, the categories and approximate numbers affected where we can establish them, the likely consequences, and the measures taken or proposed — and we send it in phases rather than waiting for a complete picture. The decision to notify your supervisory authority or the affected individuals is yours, as controller; we support it, we do not make it for you.

11. Reporting a vulnerability

If you believe you have found a security vulnerability in Routerra Teams — in the dashboard, the driver app or the API — please tell us at info@routerra.io, with enough detail to reproduce it: the endpoint or screen, the steps, and what you observed.

What you can expect. We acknowledge your report, we tell you our assessment of it once we have one, and we tell you when it is fixed. We will not pursue legal action against you for a good-faith report that follows the conditions below. We are a small team and we do not run a paid bug-bounty programme, so we do not promise a reward or a fixed response deadline — we would rather say that plainly than imply a service level we cannot hold to.

What we ask of you. Test only against your own team and your own data. Do not access, modify or retain another customer’s data; do not run denial-of-service or spam testing; do not use social engineering against our people or our customers; and give us a reasonable opportunity to fix the issue before disclosing it.

What this page does not claim

Security questionnaires ask about controls we do not have, and the honest answer is more useful to you than a carefully worded one. As at the date above we do not hold ISO 27001, SOC 2 or any other security certification; we do not run a penetration-testing programme or a third-party audit of the platform; we do not operate a formal vulnerability-scanning and patch-management programme with published timelines; we do not perform documented restore drills or publish an RPO or RTO; and we do not operate a high-availability standby or a disaster-recovery site.

None of that is a reason to stop asking. If one of these is a requirement for you, tell us at info@routerra.io: we would rather have the conversation than have you infer an answer from silence. When any of the above changes, it changes on this page first, and section 6 of the DPA commits us not to reduce the overall level of protection below what is described here.

Contact

Security questions, questionnaires, vulnerability reports and requests for information under section 12 of the DPA:

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

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