GDPR
OnTrackio is built for organisations subject to the GDPR. This page explains the data-protection model: who plays which role, the lawful basis for processing, how the platform helps you answer data-subject requests, where data crosses borders, and how deletion works. It is the customer-facing summary of the Data Processing Agreement (DPA) and the contractual terms that back it.
:::note Before you begin
- This page is an explanation, not a contract. The binding terms are in your DPA, which forms a schedule to your service agreement. Where the two differ, the DPA governs.
- The hands-on steps for exporting or erasing one person's data live in GDPR and DSAR. This page covers the why behind them.
- "Personal data", "controller", "processor", "data subject", and "personal data breach" carry their GDPR meanings throughout. :::
Who is the controller and who is the processor
The roles are split the way the GDPR expects for a software-as-a-service tool: you decide what employee data to manage and why, and OnTrackio processes it on your documented instructions.
| Role | Party | Responsibility |
|---|---|---|
| Controller | You (the customer) | Decide the purposes and means of processing the personal data you put into your workspace. Own the relationship with your employees and any supervisory authority. |
| Processor | OnTrackio | Process that data only on your instructions — the instructions in your agreement, the DPA, and any later written instruction we confirm. |
| Sub-processor | Vetted vendors | Process data on OnTrackio's behalf for a specific function, under contracts no less protective than the DPA. See Sub-processors. |
OnTrackio processes personal data only on your documented instructions. If we ever believe an instruction breaches the GDPR, we tell you rather than act on it.
What data is processed, and on what basis
Your workspace holds the personal data needed to manage IT assets for your people. The categories below are the description of processing that Annex I of the DPA records.
| Category of personal data | Examples |
|---|---|
| Identification data | Name, email, employee ID |
| Professional data | Job title, department, location |
| Device-association data | Assigned asset tags, IP and MAC addresses, software licence assignments |
| Authentication metadata | Last-login timestamp, MFA enrolment state |
| Audit-log data | Actions performed in the platform, with timestamps and IP addresses |
| Aspect | Detail |
|---|---|
| Data subjects | Your employees, contractors, and other authorised personnel whose hardware, software, or access you manage |
| Lawful basis | Contract — processing is necessary to provide the IT asset-management service you've subscribed to |
| Nature of processing | Hosting, storage, retrieval, organisation, transmission, display, and deletion of the data |
| Purpose | Providing the OnTrackio ITAM service described in your agreement |
| Special-category data | None processed by default. Don't upload Article 9 data (health, biometrics, and the like) without a prior written agreement. |
| Duration | Your subscription term, plus the return and deletion window described below |
Data minimisation is built in. The endpoint agent reports only what asset management needs, and the public list of exactly what it collects is in What data is collected. Nothing about a person's private use of a device is in scope.
Privacy by design and by default
Article 25 expects the protections to be structural, not bolted on. The platform's architecture is the control.
| Principle | How it shows up |
|---|---|
| Tenant isolation | Each workspace runs in its own dedicated PostgreSQL database. No cross-tenant query is possible at the connection layer — the active database is chosen from the verified hostname. |
| Data minimisation | The agent collects only asset-relevant telemetry; the data model has no field for private activity. |
| Encryption | AES-256 at rest on the database and document storage; TLS for every connection in transit. |
| Access control | Role-based access scopes who can do what, with optional MFA and SSO. |
| Auditability | Every mutation is recorded with the actor, the event, and the timestamp. |
The full architecture and the technical and organisational measures (TOMs) that satisfy Article 32 are in Security overview and your DPA. Residency specifics are in Data residency.
How the platform supports data-subject rights
Articles 15 to 22 give individuals rights over their data. OnTrackio gives you built-in tooling for the rights it can act on directly, and a public intake form so any data subject can file a request against your workspace without an account.
| Right | GDPR article | How OnTrackio helps |
|---|---|---|
| Access | Article 15 | The Export JSON action on Admin → GDPR gathers everything held about one person into a single file. |
| Rectification | Article 16 | Edit the person's record directly; correction requests route through the intake form. |
| Erasure | Article 17 | The Erase action pseudonymises a person's identity fields while keeping assignment history for audit. |
| Restriction | Article 18 | Annotate or restrict the record; requests route through the intake form. |
| Portability | Article 20 | The same Export JSON file is a structured, machine-readable copy. |
Two surfaces back these rights:
- Admin → GDPR is the operator screen where an admin runs an export or an erasure for
a known person. Erasure is
super-admin-only and refuses to run while the person still holds assets, so a destructive action can't fire by accident. The step-by-step is in GDPR and DSAR. - The public intake form lives at
/privacy/requeston your workspace subdomain (for example,https://<slug>.app.ontrackio.com/privacy/request). It accepts access, rectification, erasure, restriction, and portability requests, records each with a 30-day response deadline, and is the link to put in a privacy notice or email footer.
The platform also assists with controller obligations beyond individual requests: supporting your data-protection impact assessments (Article 35) and prior consultations (Article 36), and making available the information you need to demonstrate compliance and to run audits (Article 28(3)(h)).
Where your data lives and how it crosses borders
Customer data is primarily processed in eu-central-1 (Frankfurt, Germany). A small number of transfers happen only for specific functions, each under an appropriate transfer mechanism.
| Destination | Why | Transfer mechanism |
|---|---|---|
| EEA (Frankfurt) | Primary hosting of your workspace data | No transfer — data stays in the EEA |
| Stripe (Ireland, with onward US) | Subscription billing only | Adequacy (Ireland); Standard Contractual Clauses for the onward US transfer |
| Anthropic (United States) | AI features — only when you enable them, and only the specific content sent to the feature | Standard Contractual Clauses (Module 2) plus supplementary measures; no model training on your data |
Where a transfer goes to a country without an adequacy decision, the EU Standard Contractual Clauses (Module 2: controller-to-processor) apply. Where an importer is certified under the EU-U.S. Data Privacy Framework, that certification is the primary mechanism with the SCCs as a fallback. On top of the legal mechanism, OnTrackio applies the supplementary technical measures the EDPB recommends: encryption in transit (TLS 1.2+) and at rest (AES-256), per-workspace database isolation, and access logging.
AI features are opt-in. Until an admin turns them on, no workspace content is sent to the Anthropic sub-processor. When enabled, only the specific content submitted to a feature is processed, and it is not used to train models.
The complete, current vendor list — with each vendor's purpose, processing location, and transfer mechanism — is in Sub-processors. OnTrackio notifies customers at least 30 days before adding a new sub-processor, so you can object on data-protection grounds within that window.
If there's a personal data breach
The notification chain follows the roles: OnTrackio tells you, and you decide what your regulator and your people need to hear.
| Step | Who acts | Timing |
|---|---|---|
| Notify the customer | OnTrackio → you | Without undue delay, and within 48 hours of becoming aware of a breach affecting your data |
| Assess and notify the supervisory authority | You (controller) | Article 33 — within 72 hours where the breach is notifiable |
| Notify affected data subjects | You (controller) | Article 34 — without undue delay where there's a high risk |
OnTrackio's notification to you includes, as far as known at the time: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken or proposed, and a contact point. Where not everything is known at first, we follow up in phases. Because you are the controller, the Article 33 and 34 decisions and filings are yours to make — the 48-hour processor notification exists so you have the time and detail to make them.
How long data is kept, and how it's deleted
Retention follows the subscription, and deletion is final by design — the database-per-workspace architecture makes erasure a physical operation, not a flag.
| Stage | What happens |
|---|---|
| During the subscription | Data is retained for as long as you use the service. |
| Return window | Within 30 days of termination, on request, your data is made available for export in a standard machine-readable format. |
| Deletion | 60 days after termination, your data is deleted or anonymised — effected by dropping the per-workspace database, an irreversible operation, together with the corresponding document-storage prefix. |
| Backups | Encrypted database backups are retained for 7 days in the same region and then rotated out automatically; data in a backup at deletion time leaves with that rotation. |
| Anonymised data | Aggregated, de-identified data that no longer identifies you or any person isn't subject to these stages and may be retained. |
Erasure inside a live workspace works differently from end-of-contract deletion. An Article 17 erasure pseudonymises one person's identity fields and keeps their assignment and audit history, so a "right to be forgotten" request doesn't break your evidence trail. End-of-contract deletion removes the entire workspace database. See GDPR and DSAR for the in-workspace erasure behaviour.
Audit and verification
You can demonstrate compliance from your own workspace and from OnTrackio's attestations.
| Source | What it gives you |
|---|---|
| Audit log | Every mutation across the platform, exportable to CSV or JSON — evidence for the Article 30 record and for access reviews. See Audit log. |
| Evidence packs | A one-page GDPR Article 30 pack generated from your live data. See Evidence packs. |
| Standardised questionnaires | Responses to common security questionnaires (such as CAIQ and SIG Lite) on request. |
| Third-party reports | Independent audit reports are shared once issued; see Certifications for current status. |
What sits with you, and what sits with us
GDPR compliance is shared. Knowing the split keeps the posture honest.
| Responsibility | Owner |
|---|---|
| Choosing what employee data to process and why | You (controller) |
| Lawful basis and any required privacy notice to your employees | You (controller) |
| Deciding on, and filing, Article 33 and 34 notifications | You (controller) |
| Not uploading special-category data without prior agreement | You (controller) |
| Processing only on your instructions, and the Article 32 security measures | OnTrackio (processor) |
| Built-in tooling for export and erasure, and the public request intake | OnTrackio (processor) |
| 48-hour breach notification to you, and sub-processor management | OnTrackio (processor) |
| Return and deletion of your data at end of contract | OnTrackio (processor) |