Security overview
OnTrackio is a multi-tenant cloud service that protects your asset, licence, and user data with layered controls: per-workspace database isolation, encryption in transit and at rest, role-based access with multi-factor authentication, and a full audit trail of every change. This page explains those controls and maps them to the SOC 2 Trust Services Criteria so your security team can evaluate us against a framework they already know.
:::note Reading this page This is an explanation of our security posture, not a configuration guide. For the steps to turn on a control inside your own workspace — MFA, SSO, IP allowlists, API-token scopes — follow the linked how-to pages. For where data physically lives and how workspaces are isolated, see Data residency. :::
How we frame our controls
We describe each control honestly: what the platform enforces in code, what we inherit from our infrastructure provider, and where a control depends on process rather than software. A posture that claims everything is "fully covered" fails the moment an auditor probes it. One that states what's enforced, what's inherited, and what's still maturing survives that probe — and tells you exactly where the boundaries are.
Three layers carry every control below:
| Layer | What it covers | Who attests it |
|---|---|---|
| Platform | Controls enforced by the application — access, isolation, logging, change gates | OnTrackio, evidenced from the codebase and your live data |
| Infrastructure | Physical security, hardware disposal, data-centre operations | AWS, via its own SOC 2 / ISO 27001 reports for the eu-central-1 region |
| Process | Policies, reviews, and human procedures that sit alongside the software | OnTrackio, documented in our policy set |
:::note Certification status The controls on this page describe our current technical and process posture. They are not the same as a completed third-party attestation. For where our SOC 2 and ISO 27001 audits stand, see Certifications. :::
What we map to
Our security posture is organized around the SOC 2 Security Trust Services Criteria (the "common criteria", CC1 through CC9) because it's the framework most enterprise buyers ask about. The same underlying controls feed our ISO 27001 Annex A, GDPR Article 32, and NIS2 Article 21(2) posture — those frameworks ask many of the same questions in different words.
| Criterion | Theme | Where the weight sits |
|---|---|---|
| CC1 | Control environment | Process |
| CC2 | Communication and information | Platform + process |
| CC3 | Risk assessment | Platform + process |
| CC4 | Monitoring activities | Platform |
| CC5 | Control activities | Platform |
| CC6 | Logical and physical access | Platform (the largest area for a SaaS) |
| CC7 | System operations | Platform |
| CC8 | Change management | Platform |
| CC9 | Risk mitigation | Platform + infrastructure |
The rest of this page walks the criteria that translate to controls you can see and verify, starting with access — the criterion that matters most for a cloud service.
Logical and physical access (CC6)
Access control is where most of our engineering investment sits. It spans how a person proves who they are, what they're allowed to do once in, how accounts are created and removed, and how data is protected as it moves and at rest.
Authentication and authorization
You choose how strongly your workspace authenticates, from a password to enterprise SSO with multi-factor enforcement. Every protected screen and API route checks both who you are and what role you hold.
| Control | How it works |
|---|---|
| Sign-in methods | Password, Google Workspace SSO, Microsoft Entra ID, generic SAML 2.0, and WebAuthn / FIDO2 passkeys |
| Multi-factor authentication | Time-based one-time passcodes (TOTP) and passkeys, with an org-level policy to require MFA for admins or for everyone |
| Role-based access control | Five roles and a granular permission set; admin screens sit behind an admin-only gate |
| Per-workspace isolation | Each workspace runs in its own dedicated database; no cross-tenant query is possible at the connection layer |
| Domain restriction | SSO sign-in can be limited to your approved company domains, with an explicit bypass for external collaborators |
SSO and account lifecycle are separate concerns. SSO decides how someone signs in; SCIM provisioning decides which accounts exist at all. Most organizations run both — see SCIM provisioning and SAML SSO.
Account provisioning and removal (CC6.2)
Accounts are created and removed through controlled paths, never ad hoc. Removal is the half auditors scrutinize most, so it's built to be complete and traceable.
| Lifecycle event | How it's handled |
|---|---|
| Joiner | Admin invite, just-in-time creation on first SSO sign-in, or a SCIM push from your identity provider |
| Mover | Role changes from the user's admin page, or a SCIM PATCH that updates roles from your IdP |
| Leaver | A SCIM active: false push or DELETE deactivates the account and writes a dedicated audit entry; an offboarding sweep warns admins of departing users who still hold assets |
| Workspace closure | Deleting a workspace drops its dedicated database, removing all of its data |
SCIM provisioning covers the full RFC 7644 lifecycle (GET, POST, PUT, PATCH, DELETE) and
has been verified against Okta and Microsoft Entra payloads. SCIM groups carry directory
membership only — they never grant permissions directly, so a misconfigured group can't silently
mint an admin.
Protecting data in transit and at rest (CC6.6, CC6.7)
Data is encrypted on every hop and at every resting place, and the network perimeter is closed to direct public access.
| Surface | At rest | In transit |
|---|---|---|
| Workspace database | AES-256 (provider-managed key) | TLS 1.2+ on every connection |
| Document and file storage | SSE-S3 (provider-managed) | TLS via signed URLs |
| Sensitive application fields (MFA secrets, recovery codes) | Encrypted with the app key, held in a managed secrets store | Covered by transport above |
| API tokens | Stored as a hash only; the secret is shown once at creation | Sent as an Authorization: Bearer header |
| Endpoint-agent signing keys | Stored as a hash only; the secret stays on the device | HMAC-SHA256 signs every agent request |
Beyond encryption, the perimeter is hardened: TLS terminates at the load balancer, production forces HTTPS, the database sits in a private network with no public ingress, and outbound webhooks are guarded against server-side request forgery. Admins can narrow access further with a per-workspace admin-panel IP allowlist and per-token CIDR restrictions.
An API token's secret is displayed only once, immediately after you create it — it's stored as a hash afterward and can't be retrieved. Copy it then; if you lose it, revoke the token and mint a new one. See API tokens and webhooks.
Physical security and disposal (CC6.4, CC6.5)
OnTrackio holds no on-premises assets. Physical data-centre security and the secure destruction of storage media are inherited from AWS, which attests to them through its own SOC 2 and ISO 27001 reports for the Frankfurt (eu-central-1) region. Storage volumes are encrypted at rest, and disk disposal follows the provider's media-sanitization standard. At the application layer, deleting a workspace cascades to dropping its database.
Malware and external-threat defence (CC6.8)
| Control | How it works |
|---|---|
| Image scanning | Container images are scanned for vulnerabilities when published |
| Dependency updates | Automated weekly updates across application, frontend, and toolchain dependencies |
| No arbitrary file execution | Uploaded documents are stored as static blobs and never executed |
| Gated releases | Every change must pass automated checks before it can ship (see Change management) |
Monitoring and system operations (CC4, CC7)
We watch the running system for failures and anomalies, and we have a defined path from detecting a security event to responding to it.
| Capability | How it works |
|---|---|
| Performance monitoring | Infrastructure and application metrics, with container logs shipped to centralized log storage |
| Health alerting | An automated health check on the connection pooler raises an alarm that emails the operations team on failure |
| Anomaly detection | The audit log records every mutation; a mail-delivery event pipeline flags bounces and complaints |
| Security-event evaluation | The NIS2 Article 23 incident workflow logs significant incidents and auto-computes regulatory deadlines |
| Incident response | A documented runbook with a severity rubric, defined roles, customer-comms templates, and a quarterly tabletop-drill cadence |
| Recovery | Automated daily database backups with point-in-time recovery; the application is stateless and rebuilds from a known image |
The audit trail is also a customer-facing surface: you can review and export it yourself. It is evidence for SOC 2 CC7.2, ISO 27001 A.8.15, and the GDPR Article 30 record at once. See Audit log.
Change management (CC8)
Every change to the platform moves through the same controlled pipeline, so nothing reaches production unreviewed or untested.
- Authorize — all changes go through a pull request; direct pushes to the main branch are rejected for everyone by a branch-protection rule.
- Develop and review — changes are code-reviewed and described with a test plan and risk notes.
- Test — an automated test suite runs on every change and must pass before merge.
- Deploy — releases use zero-downtime deploys; the previous version keeps serving traffic if a new one fails its health check.
This gives a clean, traceable history: every production change maps to a reviewed request with an author and a passing automated check, which is the spine of both CC8 (change management) and CC1.5 (holding individuals accountable).
Risk mitigation and vendor management (CC9)
Business-continuity controls and third-party risk management round out the posture.
| Area | How it works |
|---|---|
| Backups and recovery | Automated daily database backups with point-in-time recovery; immutable release images |
| Stateless design | Any compute node rebuilds from a known image, so recovery doesn't depend on a single server |
| Audit-log retention | A retention floor protects the activity trail from being pruned below the minimum |
| Vendor risk | Each critical sub-processor has a documented risk profile, tier, and data-processing agreement on file, reviewed quarterly |
The vendors we rely on to deliver the service — and what each one processes — are listed in Subprocessors.
How this maps to other frameworks
The controls above aren't SOC 2-specific. The same evidence answers the access, encryption, logging, and isolation questions in the frameworks European buyers care about.
| Framework | What these controls support |
|---|---|
| ISO/IEC 27001 | Annex A access controls (A.5, A.8), cryptography (A.8.24), operations and logging (A.8.15) |
| GDPR | Article 32 security of processing — per-workspace isolation, encryption, audit trail, RBAC, MFA |
| NIS2 | Article 21(2) measures (e) secure development, (h) cryptography, and (j) MFA and secure authentication |
OnTrackio also turns this posture into auditor-ready evidence packs computed from your live data, under Admin → Compliance. See Compliance overview and the honest coverage labelling explained in NIS2 posture.
Limitations and trade-offs
Knowing the edges is what keeps the rest credible.
| Boundary | What it means |
|---|---|
| A posture is not an attestation | This page describes controls we enforce and inherit. It complements a SOC 2 report or ISO 27001 certificate; it doesn't replace one. See Certifications. |
| Some controls are inherited | Physical security and media disposal come from AWS attestations, not from OnTrackio directly. |
| Some controls are process, not code | The control environment (CC1) and parts of risk assessment (CC3) rest on policy and review rather than software, and scale with team size. |
| The internal network hop is trusted | Traffic from the load balancer to the application is plaintext within a private network whose perimeter AWS attests to; data is encrypted at every other hop. This suits ITAM data but would not meet PCI-DSS or HIPAA-strict end-to-end requirements, neither of which applies here. |
| Residency is EU today | Workspaces are hosted in the EU (Frankfurt). US residency is on the roadmap; see Data residency. |