Security Documentation

How InRows Protects Your Data

A transparent overview of our security architecture, data handling practices, and compliance posture.

Last updated: March 2026

Encryption

In Transit

All data transmitted between your browser and our servers is encrypted using TLS 1.3. This includes API calls to the Grist backend, portal interactions, and authentication flows via Keycloak. HSTS headers enforce HTTPS-only connections.

At Rest

Data stored on our servers uses volume-level encryption (LUKS/dm-crypt) on all Docker data volumes. This protects Grist documents, PostgreSQL databases, and Redis data at the filesystem level. Encryption is transparent to the application layer.

What We Don't Claim

We do not currently offer end-to-end encryption or zero-knowledge architecture. Your data is accessible to the server-side application for processing (e.g., formula calculations, aggregation). We are transparent about this because trust requires honesty, not marketing claims. Client-side encryption for sensitive fields is on our roadmap.

Data Isolation

InRows uses a per-company document isolation model. Each company's data is stored in a separate Grist document with its own access control rules. This is fundamentally different from shared-database architectures where all companies' data sits in the same tables separated only by row-level security.

  • Each company gets a dedicated Grist document (not rows in a shared table)
  • Access control enforced at the Grist document level via ACL rules
  • Portal shadow database uses separate schemas per tenant
  • No company can query, join, or access another company's data
  • Company data can be exported or deleted independently (GDPR right to erasure)

Access Control

Authentication and authorization are handled by Keycloak, an enterprise-grade identity provider supporting OpenID Connect (OIDC).

Authentication

  • Single Sign-On (SSO) via Keycloak
  • Multi-factor authentication (MFA) support
  • Session management with token refresh
  • Automatic session expiry

Authorization (RBAC)

  • Admin — Full platform access
  • Manager — Approve/reject submissions
  • Clerk — Enter data, submit for review
  • Viewer — Read-only access

Audit Trail

All data changes and access events are logged in immudb, a tamper-evident database purpose-built for audit trails. This means:

  • Every submission, approval, and rejection is recorded with user ID and timestamp
  • Logs are append-only — entries cannot be modified or deleted after creation
  • Cryptographic verification ensures log integrity can be independently validated
  • Portal access events are tracked (who viewed what data, when)
  • Audit logs are retained for the duration of the contract plus 7 years

Benchmarking Privacy

Industry benchmarks are computed from anonymized, aggregated data only. Companies that opt in contribute their approved KPI values to aggregate statistics.

  • k-anonymity (k ≥ 5): benchmarks only shown when at least 5 companies contribute
  • Only aggregate statistics (mean, median, percentiles) are shared — never individual values
  • Opt-in model: companies explicitly choose to participate in benchmarking
  • Size-segmented: small, medium, and large companies compared within their peer group
  • Differential privacy noise added to prevent reverse-engineering of individual values

Infrastructure

Hosting

  • UK-based hosting
  • Docker containerized services
  • Traefik reverse proxy with auto-TLS
  • Isolated network per service

Monitoring

  • Health checks on all services
  • Automatic restart on failure
  • Structured logging
  • Error alerting (planned)

Compliance

GDPR

Compliant with EU/UK General Data Protection Regulation

Active

UK DPA 2018

Compliant with the UK Data Protection Act 2018

Active

ISO 27001

Information Security Management System certification

Planned

Security Questions?

If you have any questions about our security practices, please contact us.

security@inrows.com