Nodl
en

Technical and Organisational Measures (TOMs)

Stand: 08. Juni 2026
Responsible party: ex-nihilo GmbH

These TOMs form part of the Data Processing Agreement (DPA), supplement the Privacy Policy, and are reviewed regularly. The current subprocessor register describes the service providers in use.

At a glance

  • EU hosting (Hetzner, Nuremberg) with HTTPS/TLS and enforced SSL in production.
  • Workspace-based tenant isolation, role-based access control, and admin audit events.
  • CI/CD with automated tests, linting, schema checks, and dependency audits.
  • Observability via OpenTelemetry and self-hosted SigNoz; structured application logs.
  • Rolling backups (generally up to 35 days), recovery processes, and incident response procedures.

1. Organisation and governance

  • Data protection and security requirements are aligned with Art. 32 GDPR.
  • Responsibilities for operations, development, and incident response are defined internally.
  • Subprocessors are selected based on data protection and security criteria and documented in the subprocessor register.
  • Material changes to service providers or safeguards are communicated to customers in good time.

2. Access control

  • User accounts with authentication and password protection (bcrypt hashing).
  • Workspace-based tenant isolation; database queries and product logic are scoped to the current workspace.
  • Role and permission model for users and administrators (need-to-know).
  • Production system access is limited to authorised personnel.
  • Admin actions are recorded as audit events.
  • Login protection: throttling of failed sign-in attempts (email + IP) plus additional IP-based rate limits.
  • Multi-factor authentication for infrastructure and cloud access, where supported and configured by the provider.

3. Encryption and key management

  • TLS/HTTPS for data in transit; enforced SSL and HSTS in production.
  • Storage on controlled server and storage infrastructure with appropriate encryption at rest, where technically available.
  • Session authentication via encrypted Rails cookies; no plaintext password storage.
  • API keys, provider credentials, and secrets are not stored in source code; they are managed via environment variables and encrypted credentials.
  • Regular rotation and renewal of security-relevant credentials as required by operations.

4. Application security / SDLC

  • Code reviews and quality gates before deployment.
  • Automated tests (unit, integration, system), RuboCop linting, and database consistency checks in the CI pipeline.
  • Dependency scans with bundler-audit against known vulnerabilities in Ruby gems.
  • Content Security Policy (CSP), CSRF protection, and secure Rails defaults.
  • Rack::Attack for rate limiting, blocklists against scanner bots, and protection of open endpoints (e.g. registration).
  • Separation of development, test, and production environments where possible.
  • No use of real customer data in development or tests where avoidable.

5. Infrastructure and network

  • Container-based deployments (Docker) with a minimal production image; the application runs as a non-root user.
  • Operation on Hetzner infrastructure in Nuremberg, Germany (EU/EEA).
  • Cloudflare for DNS, CDN, attack protection, and performance, where deployed.
  • Segmentation of production and staging environments; separate secrets and configurations.
  • Firewall and network rules on a deny-by-default basis, where supported by the hosting provider.

6. Monitoring and logging

  • OpenTelemetry export for traces, metrics, and logs to self-hosted SigNoz, where configured.
  • Structured application logs with request IDs; health-check paths are excluded from regular logging.
  • Security and incident logs for detecting and investigating abuse or attacks.
  • Logs avoid customer content (audio, transcripts, documents) where technically possible.
  • Alerting on errors, anomalies, and availability issues via the monitoring setup.

7. Backup and disaster recovery

  • Regular rolling backups of the database and relevant files.
  • Retention generally up to 35 days; then overwritten in the backup cycle.
  • Encrypted or otherwise protected backup storage in controlled infrastructure.
  • Documented recovery processes for technical incidents.
  • Runbooks for emergency scenarios, including a communication plan.

8. Incident response

  • Procedures for detecting, assessing, and handling security incidents.
  • Escalation to responsible technical and organisational contacts.
  • Documentation of incidents, measures, and follow-up.
  • Notification of affected customers per the DPA; for personal data breaches, within 48 hours where legally and contractually required.
  • Post-incident reviews including root-cause analysis and improvement measures.

9. AI and provider safeguards

  • Transmission to AI providers (Mistral/Voxtral, Google Gemini) only to deliver the commissioned functions.
  • No use of customer data for model training by ex-nihilo.
  • Contractual and technical configuration with no-training / zero-data-retention or equivalent settings, where available.
  • No intentional biometric identification, emotion recognition, or profiling by Nodl.

10. Business continuity

  • Operation on suitable server infrastructure with monitoring of availability and system health.
  • Clear recovery objectives for critical scenarios (data loss, hosting outage).
  • Regular review of backup and recovery processes.

Questions about security measures: [email protected].

Are you sure?