Documentation Index
Fetch the complete documentation index at: https://docs.rootkey.ai/llms.txt
Use this file to discover all available pages before exploring further.
The Problem
Regulators don’t just ask whether you were compliant - they ask whether you can prove it. And the burden of proof is increasing. NIS2 requires critical entities to demonstrate integrity and auditability of their information systems. DORA demands operational resilience documentation and incident audit trails from financial entities. ISO 27001 mandates logging and protection of records. In practice, most organisations produce logs - but logs are stored in systems that administrators can access, modify, or purge. When a regulator or auditor examines a log, they are trusting the organisation’s assurance that the log hasn’t been tampered with. That trust assumption is the vulnerability. ROOTKey eliminates it.How ROOTKey Solves It
ROOTKey anchors each audit event - a configuration change, an access grant, a system action, an incident - to the Polygon blockchain at the moment it occurs. The anchor is:- Immutable - no administrator, no breach, no system failure can alter a record after it is anchored
- Timestamped by the blockchain - the timestamp is set by network consensus, not by your system clock
- Independently verifiable - regulators, auditors, and counterparties can verify records without your cooperation
Architecture
ROOTKey integrates alongside your existing SIEM, ITSM, or logging infrastructure. You do not replace your log systems - you add a cryptographic integrity layer that makes each log entry independently verifiable.Implementation
Design your vault structure around audit domains
Create a vault per audit domain - one for access control events, one for configuration changes, one for incident records. This enables granular access control and simplifies providing regulators with evidence scoped to specific systems or periods.→ Create Vault
Anchor each auditable event at emission
Hook into your event pipeline - SIEM, logging agent, application middleware - and send each auditable event to ROOTKey immediately when it is generated, before it is written to any mutable storage.→ Create File
Use Tables for structured, queryable audit records
For structured event data - JSON logs, audit records with typed fields - use the Tables API to store records with schema validation and record-level integrity anchoring. This allows querying specific event types while preserving per-record verifiability.→ Tables API · Records API
Monitor your audit workload with Analytics
Use the Analytics API to track anchoring volume over time. This is useful for demonstrating continuous compliance activity to auditors and detecting gaps in coverage.→ Analytics - Vault Creation Over Time · Analytics - Files vs Validations
Provide verifiable evidence packages to regulators
When a regulator requests evidence, provide the vault ID, file IDs, and on-chain transaction hashes for the relevant period. The regulator can independently verify each record via Polygonscan - no access to your systems required, no trust assumption required.
Recommended Configuration
| Parameter | Recommendation |
|---|---|
| Protocol | RKP-1 (Full On-Chain) for maximum regulatory defensibility; RKP-3 (Hybrid) for high-volume event streams |
| Deployment | API Integration for cloud-native logging pipelines; On-Premise for air-gapped regulated environments; MQTT for OT/SCADA event streams |
| Anchor timing | Anchor at event emission, not at batch export - batching introduces a window where events can be altered before anchoring |
| Retention | On-chain anchors are permanent; configure off-chain retention according to your regulatory retention obligations |
Key API Endpoints
| Endpoint | Purpose |
|---|---|
| Create Vault | Create audit-domain-scoped vaults |
| Create File | Anchor individual audit events |
| File History | Full event history for a specific record |
| File Validations | Retrieve validation history across the vault |
| Tables API | Structured, queryable audit records |
| Analytics - Files vs Validations | Volume and validation activity over time |
Compliance Alignment
| Framework | How this use case addresses it |
|---|---|
| NIS2 Directive | Article 21 - integrity, auditability, and monitoring of information assets; Article 23 - incident reporting with verifiable evidence |
| DORA | Chapter II - ICT risk management and audit requirements; Article 17 - ICT-related incident management with tamper-evident records |
| ISO 27001 (in progress) | A.8.15 (logging and monitoring), A.5.33 (protection of records), A.5.36 (compliance with policies and standards) |
| PCI-DSS | Requirement 10 - track and monitor all access to network resources and cardholder data |
| SOX | Section 302/404 - internal controls over financial reporting with auditable evidence |
| eIDAS | Qualified electronic timestamps for audit records submitted as legal evidence |
Get started - free account
Set up a sandbox vault and anchor your first audit event in minutes.
Request a compliance architecture review
Our team will map your regulatory obligations to a concrete ROOTKey implementation and provide compliance documentation support.