In plain language
When you use LinkTrail, we handle personal data about the people who click your links and install your apps. You decide why that data is collected; we only do what you tell us. This agreement is the legally required contract covering that arrangement — it sets out what we do with the data, who helps us do it, how we protect it, how we help you answer your users' requests, what happens if something goes wrong, and what happens to the data when you leave. It applies automatically to every customer; you don't need to sign a separate copy, though we will sign one on request.
Section 9 is the part to read closely. Our attribution uses device fingerprinting, and that has legal and app-store consequences you need to decide about.
1. This agreement and who it binds
1.1. This Data Processing Agreement ("DPA") is between LinkTrail Ltd, a company registered in England and Wales (company number 17312947) with its registered office at 66 Paul Street, London, EC2A 4NA, United Kingdom ("LinkTrail", "we", "us") and the customer that accepts the Terms of Service ("you", "Customer").
1.2. This DPA forms part of, and is incorporated into, the LinkTrail Terms of Service (the "Agreement"). It applies whenever we process Customer Personal Data on your behalf.
1.3. If this DPA conflicts with the Agreement on the processing of personal data, this DPA prevails. If this DPA conflicts with the Standard Contractual Clauses or the UK Addendum, those prevail.
1.4. This DPA applies automatically and requires no separate signature. If your procurement process requires a signed copy, email legal@linktrail.io and we will execute one on these terms.
2. Definitions
"Data Protection Law" means, as applicable: the UK GDPR and the Data Protection Act 2018; Regulation (EU) 2016/679 ("EU GDPR"); the Privacy and Electronic Communications Regulations 2003 ("PECR") and national implementations of Directive 2002/58/EC; and any other data protection law applicable to a party's processing under this DPA.
"Customer Personal Data" means personal data that we process on your behalf through the Service — principally data about the end users of your apps and links, as described in Annex I.
"End User" means an individual who clicks a link you create or uses an app in which you have integrated our SDK.
"Sub-processor" means a third party engaged by us to process Customer Personal Data.
"Personal Data Breach", "controller", "processor", "data subject", "processing", and "supervisory authority" have the meanings given in the UK GDPR.
"SCCs" means the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914.
"UK Addendum" means the ICO's International Data Transfer Addendum to the EU SCCs, version B1.0.
Terms defined in the Agreement have the same meaning here.
3. Roles of the parties
3.1. You are the controller; we are the processor. For Customer Personal Data, you determine the purposes and means of processing and we process only on your instructions. Where you are yourself a processor for another controller, we are a sub-processor and your instructions must be consistent with that controller's.
3.2. We are a controller for our own data. We act as an independent controller for your account, billing, support, and marketing data — the data about you, not your end users. That processing is governed by our Privacy Policy, not this DPA.
3.3. We are also a controller for Service improvement. As disclosed in section 7.3 of the Agreement, we act as a controller when we use End User data to develop and improve fraud detection and to produce aggregated statistics, as set out in section 11 below.
3.4. Your responsibilities as controller. You warrant that: you have a valid lawful basis for the processing you instruct; you have given End Users the transparency information Data Protection Law requires; and you have obtained any consent required under PECR or Article 5(3) ePrivacy before the relevant data is collected. We rely on these warranties, and section 9 explains why they matter technically and commercially.
4. Scope and instructions
4.1. Documented instructions. We process Customer Personal Data only on your documented instructions, which comprise: this DPA, the Agreement, the configuration choices you make in the dashboard and API (including which attribution methods and integrations you enable), and any further written instructions you give.
4.2. Subject matter, duration, nature, purpose, data categories, and data subjects are described in Annex I, as Article 28(3) requires.
4.3. Unlawful instructions. We will tell you if, in our opinion, an instruction infringes Data Protection Law. We may suspend processing of the affected instruction until it is withdrawn or amended.
4.4. Legally required processing. If law requires us to process Customer Personal Data other than on your instructions, we will tell you first unless that law prohibits it on important grounds of public interest.
4.5. Restricted data. You must not submit through the Service, including in custom deep link payloads: special category data (Article 9), criminal offence data (Article 10), or data relating to children. The Service is not designed for those categories and our security measures are not calibrated to them.
4.6. Children. You must not integrate our SDKs or use our link endpoints in apps directed to children under 16, or under the age of digital consent applicable in the End User's country where that is lower, without our prior written agreement. Where we agree, you are responsible for establishing a lawful basis before sending us data about children and for configuring the Service accordingly, including disabling probabilistic matching.
5. Confidentiality
5.1. We keep Customer Personal Data confidential and ensure that everyone we authorise to process it is bound by an appropriate duty of confidentiality that survives the end of their engagement.
5.2. We limit access to personnel who need it to provide the Service or to meet a legal obligation.
6. Security
6.1. We implement appropriate technical and organisational measures to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access, taking account of the state of the art, implementation costs, and the nature and risk of the processing (Article 32).
6.2. Our current measures are described in Annex II.
6.3. We may update our measures over time, provided the level of protection is not materially reduced.
7. Sub-processors
7.1. General authorisation. You give us general authorisation to engage Sub-processors on the terms in this section.
7.2. Current Sub-processors are listed in Annex III. That annex names only the Sub-processors that process Customer Personal Data. Other vendors we use — such as our payment processor and email providers — handle data for which we are the controller and are disclosed in our Privacy Policy instead.
7.3. Flow-down. We impose on each Sub-processor data protection obligations no less protective than those in this DPA, by written contract. We remain fully liable to you for a Sub-processor's performance of its data protection obligations.
7.4. Changes and objection. We will give you at least 30 days' notice before adding or replacing a Sub-processor, by email to your account address and by updating Annex III. If you reasonably object on data protection grounds within that period, we will work with you in good faith to find a solution. If we cannot, you may terminate the affected part of the Service and receive a pro-rata refund of prepaid fees for the unused period, as your exclusive remedy.
7.5. Customer-configured integrations are not Sub-processors. When you connect a third-party service (for example an ad network or analytics tool) and instruct us to send data to it, that third party receives the data on your instructions and is your processor, sub-processor, or independent controller — not ours. You are responsible for the legal basis for that transfer and for your relationship with that third party. Annex III does not list them.
8. International transfers
8.1. Where data is processed. Customer Personal Data is hosted in the European Union. We do not operate a US region. Annex III gives each Sub-processor's processing location.
Content delivery is an exception. Our CDN and DNS are provided by Vercel, whose edge network operates globally. Every request, including clicks on link endpoints, is received at the edge location nearest the End User, which may be outside the UK and EEA, and is then passed to our EU application servers. The edge handles the connection and sees the End User's IP address. Link resolutions are not cached at the edge: every click is resolved by our EU servers, and application processing and storage of Customer Personal Data remain in the European Union.
8.2. Onward access from outside the UK/EEA. Some Sub-processors are established outside the UK and EEA or provide support and engineering access from outside those areas, even where the data is stored in the EU. Where that results in a restricted transfer, it is made under an approved mechanism: the EU SCCs for transfers subject to EU GDPR and the UK Addendum for transfers subject to UK GDPR, in each case supported by a transfer risk assessment and any additional measures required.
8.3. Transfers between you and us. Where your provision of Customer Personal Data to us, or our return of it to you, constitutes a restricted transfer, the parties agree that the SCCs (Module Two: controller to processor, or Module Three: processor to processor where you act as a processor) and the UK Addendum apply, and are incorporated into this DPA by reference, with:
- the data exporter being you and the data importer being us;
- Annex I of this DPA completing Annex I to the SCCs;
- Annex II of this DPA completing Annex II to the SCCs;
- Annex III of this DPA completing Annex III to the SCCs;
- Clause 7 (docking) applying; Clause 9 option 2 (general written authorisation) applying with the notice period in section 7.4; Clause 11 optional redress not applying; Clause 17 governed by the law of Ireland; and Clause 18(b) courts of Ireland — with the UK Addendum applying the law and courts of England and Wales for UK transfers.
For clarity: the reference to Ireland is not an error and does not conflict with section 15.4. Clause 17 of the SCCs requires the law of an EU member state, so Irish law is specified for SCC purposes only. This DPA as a whole remains governed by the law of England and Wales.
8.4. Government access requests. If we receive a legally binding request from a public authority for Customer Personal Data, we will notify you unless legally prohibited, challenge requests that appear unlawful or overbroad, and disclose only the minimum required.
8.5. EU representative. We have appointed Prighter Privacy IRL Ltd, 9 Clare Street, Dublin 2, D02 HH30, Ireland as our representative under Article 27 EU GDPR, covering both our controller and processor roles. EEA data subjects and supervisory authorities can contact our representative at app.prighter.com/portal/linktrail or at the address above, and may also contact us directly at privacy@linktrail.io.
9. Fingerprinting and attribution methods — allocation of responsibility
This section is unusual for a DPA. It is here because our attribution methods have specific legal and app-store consequences that you, as controller, must understand and decide about.
9.1. What the Service does. Our attribution waterfall attempts deterministic matching first, using the Google Play Install Referrer or a deferred click token. Where neither is available, it falls back to probabilistic matching — inferring that a click and an install belong to the same device by comparing:
- IP address, as observed by our servers at click and at install
- Platform (iOS or Android)
within a matching window of 7 days by default, configurable per workspace through the attribution settings API. Those two fields are the entire comparison; the Service does not collect or compare user agent strings, screen metrics, timezone or language/locale for this purpose, and its SDKs do not transmit them. The result is binary — a click is matched or it is not — and there is no confidence score. What is recorded on each install is its match type: deterministic, probabilistic, or none.
This is device fingerprinting. We describe it as such and do not present it as anything narrower. The Service does not access advertising identifiers — not the Apple IDFA, with or without App Tracking Transparency permission, and not the Google Advertising ID — but that does not make the practice something other than fingerprinting, and we do not rely on it to suggest otherwise.
The Service also uses a device identifier — a randomly generated per-install UUID on iOS, and the App Set ID on Android with a random UUID fallback — and, where a link leads to the App Store, writes a short random code to the iOS clipboard so the app can identify the originating link after install.
9.2. Data protection consequences. Reading or writing information on an End User's device — including the probabilistic matching in 9.1, reading the vendor-scoped device identifier, and writing the clipboard code — engages Article 5(3) ePrivacy and PECR regulation 6. Regulators treat this as requiring consent, and legitimate interests is not an available basis. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3) confirm this applies to device fingerprinting and identifier access, not only to cookies.
9.3. App store consequences. Apple prohibits device fingerprinting irrespective of whether App Tracking Transparency permission has been granted (App Store Review Guideline 5.1.2 and the Apple Developer Program License Agreement). The probabilistic matching described in 9.1 falls within Apple's description of that practice. The absence of IDFA access does not cure this.
This is a risk to your app submission, not only to your privacy compliance, and you carry it. We state it here plainly rather than leaving you to discover it at review. Section 9.5 describes how to switch the behaviour off.
9.4. Your decision, your responsibility. You are responsible for determining whether these methods are lawful for your users and territories, for obtaining consent where required before the SDK collects any data, and for compliance with applicable app store policies.
9.5. Consent gating and controls available to you.
- The SDK is consent-gated by default: no device data is collected until your app signals that the End User has consented. You can disable the gate in your SDK initialisation options, in which case collection begins when the app opens and obtaining consent beforehand becomes entirely your responsibility.
- Probabilistic matching is off by default for a new workspace and does not run until you switch it on. It can be switched off again, and the matching window changed, through the attribution settings for your workspace.
- These controls operate at workspace level only. They cannot currently be set per app or per link, so a workspace containing several apps cannot disable matching for one of them alone. If you need per-app separation, use separate workspaces.
9.6. Our commitment. We will describe these methods accurately in this DPA, our Privacy Policy and our documentation; keep the controls in 9.5 available; and not misrepresent the SDK's default behaviour, the signals it compares, or the granularity of these controls.
9.7. Request and response logging. We capture the bodies of requests to our link endpoints, API and SDK API, and of our responses, in Microsoft Azure Application Insights for debugging and support. This is disclosed here because it applies to all traffic, including paths that carry Customer Personal Data.
- Stripped entirely before storage: passwords, tokens, API keys and two-factor codes.
- Masked: names, IP addresses and device identifiers.
- Retained in full: email addresses. This is a deliberate choice, made so that a support trace can be tied to an account. It applies to every logged path, so where you include an End User's email address in a deep link payload or an event, or where a response returns End User records, that address is retained in these logs for 90 days.
- Retention: 90 days, set explicitly on the resource.
- Region: European Union.
You should account for this in your own records of processing and, where the logged data includes End User email addresses, in the transparency information you give your End Users. If retaining End User email addresses unmasked is not acceptable for your use case, contact us at privacy@linktrail.io before integrating.
10. Assistance to you
10.1. Data subject rights. Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures — including the dashboard and API functionality we provide — in fulfilling your obligation to respond to requests to exercise rights under Chapter III of the UK/EU GDPR.
10.2. Requests received directly. If an End User contacts us directly to exercise rights over Customer Personal Data, we will not respond substantively. We will promptly forward the request to you and confirm to the individual that we have done so, unless you have instructed otherwise.
10.3. Articles 32 to 36. We will provide reasonable assistance with your obligations on security, breach notification to supervisory authorities and data subjects, data protection impact assessments, and prior consultation — taking into account the nature of processing and the information available to us.
10.4. Charges. Assistance under this section is provided at no charge where the request is reasonable in scope and frequency. For assistance that is materially burdensome or repetitive, we may charge our reasonable costs, notified to you in advance.
11. Our own use of End User data
11.1. As disclosed in section 7.3 of the Agreement, we use End User data to develop and improve the Service — specifically to train and evaluate fraud detection models, and to produce aggregated statistics and benchmarks. For these purposes we act as a controller, not your processor.
11.2. For that processing we commit that: outputs do not identify you, your apps, or any individual End User; we do not sell End User data; we do not use it to build advertising or marketing profiles of End Users; and we do not disclose your data or metrics to other customers in identifiable form.
11.3. Our lawful basis for this processing is legitimate interests (Article 6(1)(f)) — operating a platform whose core promise is accurate, fraud-resistant attribution, which cannot be delivered from any single customer's data in isolation. We use the minimum data needed for the purpose. A balancing assessment is available on request at privacy@linktrail.io, and End Users may object as described in our Privacy Policy.
11.4. We also use processing data to diagnose faults, reproduce bugs, and develop the Service, on the same basis.
12. Personal Data Breach
12.1. We will notify you without undue delay, and in any event within 48 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data.
12.2. Our notification will describe, so far as known: the nature of the breach and the categories and approximate number of data subjects and records affected; the likely consequences; the measures taken or proposed; and a contact point for more information. Where we cannot provide all of this at once, we will provide it in phases without undue delay.
12.3. We will take reasonable steps to contain and remediate the breach and will cooperate with your investigation and any notification you must make to a supervisory authority or to data subjects.
12.4. Notifying you of a breach is not an admission of fault or liability.
13. Audits and information
13.1. We will make available the information reasonably necessary to demonstrate compliance with Article 28 and this DPA.
13.2. Documentation first. Your audit right is satisfied in the first instance by the information we publish or provide on request — including this DPA, Annex II, our sub-processor list, and any third-party audit reports or security documentation we hold. We do not currently hold an independent security certification or third-party audit report; Annex II is the primary documentation available.
13.3. On-site audits. Where that documentation is genuinely insufficient, or following a Personal Data Breach affecting your data, or where a supervisory authority requires it, you may audit us or appoint an independent auditor (not a competitor of ours, bound by confidentiality). Audits take place on reasonable prior notice of at least 30 days, during business hours, no more than once in any 12-month period except where required by a supervisory authority or following a breach, and must not unreasonably disrupt our operations.
13.4. You bear the costs of an audit you initiate, unless it reveals a material breach of this DPA by us, in which case we bear our own costs and yours.
14. Retention, return, and deletion
14.1. During the Agreement, we retain Customer Personal Data as described in Annex I, Part B.
14.2. On termination, at your choice, we will delete or return Customer Personal Data. Because we do not currently offer a self-serve export, you may request a copy in a commonly used machine-readable format by emailing privacy@linktrail.io before termination, or within 7 days of it, and we will provide it. After that period the data has been deleted from production under section 14.3 and we cannot produce it.
14.3. Deletion timetable. On termination, on account deletion, or on your written deletion instruction, we begin deleting Customer Personal Data straight away and complete removal from active production systems within 7 days. Deletion runs as a controlled process rather than an instantaneous wipe, which is why it takes days rather than seconds.
Residual copies remain in two places, each on its own expiry cycle:
- Database backups and point-in-time recovery archives, which expire on a rolling basis up to 12 months. These are held encrypted, are not used for any purpose other than disaster recovery, and are not searched, queried or restored to serve a deletion or access request.
- Request and response logs held under section 9.7, which expire after 90 days. These are not searched or exported to serve a deletion or access request.
Deletion is therefore complete in production within 7 days, and complete across all copies once the relevant log or backup has expired.
14.4. Exception. We may retain data where law requires it. Where we do, we continue to protect it under this DPA and process it only for the purpose that requires retention.
14.5. Deletion certificates. We will certify deletion in writing on request. The certificate confirms deletion from active production systems and states the backup and log expiry positions in 14.3; it does not certify that no copy exists in an unexpired backup or log, because that would not be true.
15. Liability, term, and general
15.1. Each party's liability under this DPA is subject to the limitations and exclusions in the Agreement, except where Data Protection Law does not permit that limitation.
15.2. This DPA takes effect when you accept the Agreement and continues while we process Customer Personal Data, with clauses that by their nature should survive (including sections 5, 8, 12, 14, and 15) surviving termination.
15.3. We may update this DPA to reflect changes in law, our Sub-processors, or our security measures. For material changes we will give at least 30 days' notice by email or in the dashboard. Sub-processor changes follow section 7.4.
15.4. This DPA is governed by the law of England and Wales, subject to section 8.3 for transfers governed by the SCCs.
15.5. Contacts. Data protection queries: privacy@linktrail.io. Security incidents: faizan@linktrail.io; security@linktrail.io reaches the same inbox and may be used instead. Legal notices: legal@linktrail.io, or LinkTrail Ltd, 66 Paul Street, London, EC2A 4NA, United Kingdom.
Annex I — Description of the processing
Part A: Details
Subject matter: Provision of the LinkTrail deep linking and attribution platform.
Duration: For the term of the Agreement, plus the deletion periods in section 14.3.
Nature and purpose of processing: Collecting, recording, storing, structuring, analysing, and transmitting End User data in order to route link clicks to the correct destination, deliver deferred deep link content after app install, attribute installs and events to marketing campaigns, detect click and install fraud, and present analytics to you.
Categories of data subjects: End users of your apps and of links you create — including people who click a LinkTrail link, and people who install or open an app containing our SDK.
Categories of personal data:
| Category | Data |
|---|---|
| Click event | Timestamp, link identifier, workspace identifier, campaign identifier, channel identifier, referrer, routed destination, deferred click token |
| Device and environment | User agent, device model, operating system and version, screen metrics, timezone, language and locale. These signals are stored and are compared for probabilistic matching as described in section 9.1 |
| Network | IP address, and the approximate location and network derived from it. Country is derived using a geolocation database held on our own servers, so IP addresses are not sent to any external geolocation service. IP addresses held in the application database are cleared once the attribution window for the relevant event closes; IP addresses in request and endpoint logs persist for the log retention window in Part B |
| Device identifiers | iOS: a randomly generated per-install UUID. The SDK does not read the identifier for vendor (IDFV). The UUID resets when the app is reinstalled and is never shared between apps. Android: App Set ID, which resets on uninstall and carries no advertising semantics, with a randomly generated UUID as fallback. Neither is shared across companies |
| Advertising identifiers | None. The SDK does not access the Apple IDFA at any point, with or without App Tracking Transparency permission, and does not read the Google Advertising ID |
| Clipboard (iOS) | Where a link leads to the App Store, a short random code is written to the device clipboard so the app can identify the originating link after install. The code contains no information about the individual and is cleared by the app after reading. Writing it engages Article 5(3) ePrivacy — see section 9.2 |
| App and install context | Application bundle identifier, platform, deferred click token where present |
| Install and app events | Google Play Install Referrer, install timestamp, first-open event |
| Post-install events | Events you choose to send us, such as signup or purchase value |
| Derived | Attribution match type, fraud score |
| Deep link payload | The deep link path and any custom data you attach to a link, which may contain personal data you choose to include |
| Request and response bodies | The content of requests to our link endpoints, API and SDK API, and of our responses, captured for debugging and support. Passwords, tokens, API keys and two-factor codes are stripped entirely before storage; names, IP addresses and device identifiers are masked. Email addresses are retained in full, including End User email addresses appearing in deep link payloads, event data or response bodies. See section 9.7 |
Special categories: None. Prohibited by section 4.5.
Frequency: Continuous, in real time as End Users interact with your links and apps.
Sub-processor processing: As set out in Annex III, for the duration of the Agreement.
Part B: Retention
| Category | Retention period |
|---|---|
| Raw click, install and event records, including device-level signals | 13 months from collection, then deleted by an automated purge job |
| Aggregated attribution reports (campaign-level counts, no device identifiers) | 3 years |
| Link endpoint, API and application request logs (including client IP address, request path, timestamp, user agent) | The log retention window provided by our hosting platform under our workspace plan, currently up to 90 days. We do not extend that window by streaming logs to an external provider |
| Request and response bodies captured for debugging (Azure Application Insights) | 90 days, set explicitly on the Application Insights resource rather than left at the platform default |
| Diagnostic and error data (stack traces and attached request context, which may include an IP address, a device identifier or deep link payload contents) | Held in the same platform log stream and subject to the same window, and in Azure Application Insights per Annex III |
| Audit trail entries (actor, action, resource, before/after values, source IP) | The source IP is cleared after 12 months. The remaining entry — actor, action, resource, and before/after values — is retained for the life of the account as an integrity record |
| Session and refresh token records (including issuing IP) | Deleted shortly after token expiry |
| Aggregated statistics derived under section 11 (LinkTrail as controller) | Retained on an ongoing basis in aggregate form only; no device identifiers |
Backups: database backups and point-in-time recovery archives expire on a rolling basis up to 12 months. See section 14.3 and Annex II.
Earlier deletion on request: you may ask us to delete your data before these periods expire, and we delete it on termination as set out in section 14. Deletion from backups occurs on expiry, as described in section 14.3.
Note: the analytics history shown in the dashboard by plan tier is a product feature, not the retention period. The figures above are the operative ones.
Annex II — Technical and organisational security measures
These are the measures we have in place. We may update them over time provided the level of protection is not materially reduced.
Verification note. Rows marked Verified were confirmed against the running system in July 2026. Rows marked Commitment are organisational obligations rather than technical controls. Rows marked To verify on provisioning describe measures for infrastructure not yet live; we will confirm or correct them before launch.
| Area | Measure | Status |
|---|---|---|
| Encryption in transit | All traffic is served over HTTPS. Plain HTTP requests to the API and to link domains are redirected to HTTPS by permanent (301) redirect; there is no HTTP fallback. HTTP Strict Transport Security is enabled with a max-age of 180 days including subdomains. We are not currently on the HSTS preload list. | Verified |
| Encryption at rest | The production database is encrypted at rest using AES-256, applied to primary and replica instances and to all backups, as provided by our hosting platform. | Verified |
| Access control | Production infrastructure and database access is limited to a small number of authorised personnel on a least-privilege basis. Multi-factor authentication is enforced at organisation level on our hosting, source control, and network providers, so it cannot be disabled by an individual member. | Verified |
| Environment separation | Production, staging, and development are separate environments with separate credentials. | Verified |
| Credential management | Role-scoped internal access, with application secrets held in the hosting platform's managed environment configuration and rotatable on demand. Secrets are not short-lived or automatically rotated. Configuration is validated at startup so the service fails to boot rather than running with a missing credential. Customer SDK API keys are stored only as SHA-256 hashes; the plaintext key is shown once at creation and is never retrievable afterwards, and individual keys can be revoked at any time. | Verified |
| Audit logging | An immutable, append-only audit trail records mutations made through the dashboard — actor, action, resource, before and after values, and source IP — and is available to customers through the audit API endpoint. Administrative actions on our hosting workspace are separately logged by our hosting provider and retained by them for at least 90 days. | Verified |
| Request logging | Application, API and link endpoint request logs do record client IP addresses, alongside request path, timestamp and user agent. Retention is the hosting platform's log-stream window under our workspace plan, currently up to 90 days, which we do not extend. | Verified |
| Request and response body logging | Request and response bodies across all traffic are captured in Microsoft Azure Application Insights (EU region) for debugging and support, with a retention period of 90 days set explicitly on the resource. Passwords, tokens, API keys and two-factor codes are stripped before storage; names, IP addresses and device identifiers are masked; email addresses are retained in full, as disclosed in section 9.7. Access is limited to personnel diagnosing a fault or support issue. | To verify on provisioning |
| Redaction method | The stripping and masking above must operate as an allowlist of fields permitted into the stored body, rather than a denylist of field names to remove, so that a newly added secret-bearing field is excluded by default rather than logged until someone notices. | To verify on provisioning |
| Backups | Database backups and continuous point-in-time recovery archives are provided by our hosting platform, encrypted at rest under the AES-256 encryption above, and expire on a rolling basis up to 12 months. Backups are not searched, queried or restored other than for disaster recovery. | Verified |
| Data minimisation | IP addresses held in the application database are cleared once the attribution window for the relevant event closes. This minimisation does not extend to request logs, where IP addresses persist for the log retention window above. | Verified |
| Personnel | Everyone with access to Customer Personal Data is bound by a written duty of confidentiality that survives the end of their engagement, as required by section 5.1. | Commitment |
| Edge protection | DDoS mitigation and a web application firewall operate at the edge, in front of the application and link endpoints, provided by our CDN layer. | To verify |
| Vulnerability management | Automated dependency scanning is enabled on our source repositories, alerting us to known vulnerabilities in third-party dependencies, and we apply security updates on review. We do not operate scheduled independent penetration testing. | Verified |
| Certifications | We do not hold an independent security certification, and no certification audit is currently underway. We rely on the measures in this annex and on the certifications held by our infrastructure Sub-processors, which those providers publish. | Verified |
| Breach response | Suspected security incidents can be reported to faizan@linktrail.io or security@linktrail.io, which reach the same inbox, monitored by a named individual responsible for investigation and for notifying affected customers within the timeframe in section 12.1. | Commitment |
Annex III — Sub-processors
Sub-processors that process Customer Personal Data:
| Sub-processor | Purpose | Processing location | Entity location / transfer note |
|---|---|---|---|
| Render (Render Services, Inc.) | Cloud hosting — application and database | European Union | US-parented; onward access under SCCs and UK Addendum |
| Vercel (Vercel, Inc.) | CDN and edge delivery, DNS, edge security | Global edge network — requests handled nearest the End User | US-parented; edge processing and onward access under SCCs and UK Addendum |
| Microsoft (Microsoft Ireland Operations Ltd / Microsoft Corporation) | Application performance monitoring, error monitoring, and request and response body logging (Azure Application Insights) — see section 9.7 | European Union | EU contracting entity; US-parented, onward access under SCCs and UK Addendum |
Planned Sub-processors, not yet receiving data. Disclosed in advance so you have notice before they go live. Each will move into the table above, and we will notify you under section 7.4, before it begins processing Customer Personal Data:
| Planned Sub-processor | Purpose | Processing location |
|---|---|---|
| Sentry (Functional Software, Inc.) | SDK and application error monitoring | European Union |
Not Sub-processors under this DPA. The following process data for which LinkTrail is the controller — our own customer, billing, website, and support data — and are disclosed in our Privacy Policy rather than here: Stripe (payments; Stripe is also an independent controller for its own fraud, AML, and regulatory purposes), Resend (transactional and marketing email), Titan via Hostinger (business email), Google (Google Analytics for Firebase and Ads conversion measurement, website only).
Integrations you configure — including ad networks and analytics platforms such as Meta, Google Ads, TikTok, Apple Search Ads, Amplitude, Mixpanel, Segment, Braze, Iterable, and BigQuery — are not our Sub-processors. See section 7.5.