Compliance and audit overview
OnTrackio turns the asset, licence, and offboarding data you already keep into evidence an auditor will accept. This page explains what the compliance suite covers, the design choice behind how it labels that evidence, and which screen answers which question. The how-to and reference pages linked throughout cover the steps.
The whole suite lives under Admin → Compliance in the sidebar. Everything on the hub is read-only and computed from your current data, so it's safe to open during a live audit call.
:::note Before you begin
- You need an admin role (
admin,it-admin, orsuper-admin) to reach any compliance screen. - GDPR erasure is stricter: only a
super-admincan run it. Other admins see the GDPR page and can run exports. - Evidence packs read live data — generate one the moment an auditor asks, since the generation timestamp is printed at the top. :::
What the suite is, and what it is not
OnTrackio is an IT asset-management platform that contributes ITAM-derived evidence to your compliance programme. It is not a full governance, risk, and compliance (GRC) suite. That boundary is deliberate, and it shapes everything below: the platform produces strong evidence for the controls that touch assets, users, and licences, and it says so plainly where a control needs paperwork it can't generate for you.
This honesty is the point. An evidence pack that claims "implemented" for a control it only partially covers fails the moment an auditor probes it. A pack that cites a real number for what the platform measures, and names what you still owe, survives that probe and tells you exactly where the remaining work is.
The five compliance surfaces
The Compliance section of the sidebar holds five entries. Each answers a different question.
| Surface | Sidebar label | Answers | Detail page |
|---|---|---|---|
| Evidence packs | Compliance | "Show me my asset inventory and access controls mapped to a framework." | Evidence packs |
| Incident notification | NIS2 incidents | "Have we met the NIS2 Article 23 reporting deadlines?" | NIS2 incident notification |
| Effectiveness assessment | Effectiveness | "Are our security controls actually working?" | NIS2 effectiveness |
| Audit log | Audit log | "Who did what, and when?" | Audit log |
| Data-subject rights | GDPR | "Export or erase one person's data." | GDPR and DSAR |
Evidence packs: your data, mapped to a framework
The hub at Admin → Compliance is a grid of cards, one per framework. Each card shows the headline numbers for that framework and a button that streams a single-page PDF you can attach to an evidence request without writing a covering note. Each card surfaces its own gap metrics, so you can see which assets or users are missing evidence before you hand the pack over.
| Pack | Maps to | Headline signals | Download action |
|---|---|---|---|
| ISO/IEC 27001 — A.8 Asset management | Inventory completeness, ownership, classification | Active assets, assets with category and owner, assets missing a serial number | Download A.8 evidence pack |
| SOC 2 — CC6.1 Logical access | Licensed seats, renewal coverage, offboarding hygiene | Active licences, total seats, offboarded users still holding assets | Download CC6.1 evidence pack |
| GDPR — Art. 30 Records of processing | Data-subject inventory, disposal evidence, handover deeds | Users tracked, wipe certificates this year, disposal wipe coverage | Download Art. 30 evidence pack |
| NIS2 — Article 21(2) | All ten cybersecurity risk-management measures, (a) through (j) | Sub-controls counted by status — implemented, partial, planned | Download Article 21 evidence pack |
Every figure on a card comes from the same query that fills the PDF, so the screen and the document can never disagree. If a number looks wrong, fix the underlying record — for example add a missing serial number on the hardware page — and regenerate.
How the NIS2 pack labels coverage honestly
The NIS2 pack is the most detailed, and the clearest illustration of the honesty principle. Article 21(2) lists ten measures. Rather than mark each "implemented", the pack tags every sub-control with a coverage class that tells the auditor exactly how far the platform's evidence goes.
| Coverage class | What it means | Example sub-controls |
|---|---|---|
| ITAM-native evidence | The platform produces full evidence for this control; the status reflects real measurements. | (b) Article 23 incident notification, (f) effectiveness assessment, (j) MFA enrolment |
| ITAM hygiene floor | The platform supplies a necessary precondition, not the whole control. Status is capped at partial — you still owe the rest. | (a) asset register feeding risk analysis, (d) vendor inventory feeding supply-chain, (i) offboarding tracking |
| ITAM proxy | A coverage metric, not an effectiveness measurement. Status is capped at partial because the metric only stands in for the control. | (e) purchase records for acquisition security, (h) agent coverage for cryptography |
| Outside ITAM scope | You must produce this evidence yourself. The pack says so explicitly and points the auditor elsewhere. | (c) your own business-continuity plan, the secure-comms half of (j) |
For each sub-control, the pack states what OnTrackio contributes, lists what you must provide separately, and never inflates the status beyond what the evidence backs. The full breakdown is in Evidence packs.
The NIS2 pack is ITAM-derived evidence for the asset-related portion of Article 21 — it is not a complete NIS2 attestation. Controls marked outside ITAM scope, such as your business continuity plan and cryptography policy, sit in your own GRC tooling or with a consultant. The pack names each one so nothing is silently assumed.
The two NIS2-native workflows
Two NIS2 controls are where the platform produces genuinely native evidence — it owns the timer, the workflow, and the records end to end. Both are first-class screens, not just rows in a PDF.
- Article 23 incident notification (
NIS2 incidents) logs a significant incident and auto-computes the 24-hour early-warning, 72-hour notification, and 30-day final-report deadlines from the detection time. It then walks the incident through notify the CSIRT → file the final report → close, and stamps each transition. The CSIRT email is a per-tenant setting because each EU member state has its own contact. See NIS2 incident notification. - Article 21(2)(f) effectiveness assessment (
Effectiveness) answers whether your controls are working, not just present. It tracks metric snapshots over time, runs a documented review through draft → reviewed → signed, and stores a versioned policy document with a tamper-check hash. See NIS2 effectiveness.
How audit and GDPR fit alongside
Two surfaces underpin the framework packs rather than mapping to a single one.
- The audit log records every mutation across the platform with the actor, the event, and the timestamp, and exports to CSV or JSON with the same filters you're viewing. That trail is evidence for SOC 2 CC7.2, ISO 27001 A.8.15, and the GDPR Article 30 subject-access record at once. See Audit log.
- The GDPR screen handles one person at a time: a portability export (Article 20) gathers everything held about a user into a single JSON file, and erasure (Article 17) pseudonymises their personal data while keeping the assignment history intact for audit. Both actions are themselves logged. See GDPR and DSAR.
Erasure is intentionally narrow. It refuses to run while the user still holds assets, never
erases a super-admin or your own account, and requires you to retype the user's email to
confirm — so a destructive action can't fire on a slip.
Where your data lives
A recurring auditor question is residency and isolation. Each customer workspace runs in its own dedicated PostgreSQL database; no cross-tenant query is possible at the connection layer, because the active database is chosen from the verified hostname. Within a workspace, role-based access control scopes who can do what.
| Layer | Posture |
|---|---|
| Data residency | Hosted in the EU (Frankfurt) today |
| Database isolation | One dedicated database per workspace |
| Encryption at rest | AES-256 on the database; SSE-S3 on document storage |
| Encryption in transit | TLS for every connection |
| Access control | Role-based, with optional MFA and SSO |
The customer-facing detail — sub-processors, certifications, and the full data-flow narrative — lives in the Trust Center. For tenant-by-tenant isolation specifics, see Data residency.
Limitations and trade-offs
Knowing the edges keeps the evidence credible.
| Boundary | What it means |
|---|---|
| Evidence packs are a snapshot, not an ISMS | A pack maps your live ITAM data to specific controls. It complements a SOC 2 report or ISO 27001 certificate; it doesn't replace one. |
| Coverage is honest, not maximal | Sub-controls outside ITAM scope are labelled as customer-provided rather than dressed up. That's by design — it's what makes the rest trustworthy. |
| NIS2 native evidence is two controls | The platform owns Article 23 notification and Article 21(2)(f) effectiveness end to end. The other measures range from hygiene floor to outside scope. |
| Erasure preserves history | GDPR erasure pseudonymises personal data but keeps assignment records, so audit integrity survives a "right to be forgotten" request. |
| Residency is EU today | Workspaces are hosted in the EU. US residency is on the roadmap; see Data residency for the current state. |