NIS2

For each measure the answer is written from the perspective of the entity using Ithura, describing what Ithura provides or how to configure it.

Article 21(2)(a): Policies on risk analysis and information system security

Ithura does not author your risk-management policy. What Ithura contributes:

• Documented threat model and architecture in ops/architecture and this sovereign section. Feed these into your own risk analysis.
• Change-log driven security release notes on /releases. Every security-relevant change is called out so your policy owner can track the risk register.

Article 21(2)(b): Incident handling

• Audit log captures workspace-scoped admin actions with actor, IP, and metadata. Retained per your workspace configuration; exportable to CSV or streaming to SIEM on Enterprise.
• Session revocation endpoint invalidates a compromised session immediately.
• API token rotation endpoint invalidates a leaked API token immediately.
• Rate-limiting counters are recorded in Valkey; abnormal auth activity is visible via the metrics endpoint if you scrape it.

Ithura does not have a hosted SOC. Your own security team owns detection and response; Ithura provides the primitives (audit log, revocation endpoints, rate-limit counters) they need.

Article 21(2)(c): Business continuity, backup management, and disaster recovery

• Every data store is standard. Postgres, RustFS (S3-compatible), and Valkey are backed up with the same tools you already use for any other Postgres or S3 workload.
• Recommended backup posture for self-hosted:
  • Postgres: pg_dump or physical base-backup with WAL archiving. Restore tested quarterly.
  • RustFS: mirror to an off-host object store, or snapshot the volume.
  • Valkey: no persistent workspace data lives here (rate-limit counters, worker queue state). A rebuild is a fresh empty Valkey and a re-warmed cache.
• Single-binary restore means DR is: stand up the Docker services, restore Postgres, restore RustFS, point the API binary at both. There is no third-party service to re-provision.
• Multi-region is your choice. Ithura is stateless at the API layer, so running it in two regions behind a Postgres primary + replica is straightforward. Not part of the packaged compose out of the box; the Helm chart is the entry point for a multi-node deployment.

Article 21(2)(d): Supply-chain security

• Minimal dependency surface. Ithura's Go module set is pinned in go.mod and go.sum; the SPA's dependency set is pinned in pnpm-lock.yaml. Every dependency lives in a public registry and is verifiable by hash.
• Signed SBOM for every release, published alongside the release notes (planned as part of the sovereign packaging: syft-generated SPDX SBOM signed with cosign). Includes both the Go binary and the SPA bundle.
• No hidden runtime dependencies. The Docker image contains only the compiled binary and the SPA static assets. There is no vendored curl, no bundled binary blob, no separate agent phoning home.
• Container image provenance. Images are published to a public registry with a build-time SLSA-style attestation.

Article 21(2)(e): Security in network and information systems acquisition, development, and maintenance

• Reproducible builds. go build from a tagged commit yields the same binary; the CI pipeline records the build hash.
• Vulnerability scanning. Go dependencies checked with govulncheck and SPA dependencies with pnpm audit on every release.
• Public issue tracker for security findings. Report privately to security@ithura.com; the disclosure policy is documented in the top-level SECURITY.md in the repository. Fixed vulnerabilities are announced via release notes and, when significant, via GitHub Security Advisory.

Article 21(2)(f): Policies and procedures to assess the effectiveness of cybersecurity risk-management measures

Ithura is your subject of assessment, not your assessor. What Ithura provides to make assessments easier:

• Deterministic audit log to prove that a control fired (or failed).
• Metrics endpoint (Prometheus, token-gated) exposing auth counters, rate-limit drops, and admin-action counts.
• Signed release notes so you can attest to which version was running at any point in time.

Article 21(2)(g): Basic cyber hygiene practices and cybersecurity training

This obligation is entirely on the entity using Ithura. What Ithura provides is the tools to enforce good hygiene:

• Password policy with configurable minimum length and complexity (Enterprise).
• Two-factor enforcement across the workspace (Pro).
• Enforced SSO with IdP-managed password and MFA policies (Pro).
• Session policy with idle and absolute timeouts (Enterprise).
• Automatic sign-out on password change for all active sessions.

Article 21(2)(h): Policies and procedures regarding the use of cryptography and, where appropriate, encryption

• Cryptography inventory for Ithura itself:
  • TLS 1.2+ for HTTPS (terminator's choice; Ithura reference deploy uses Traefik with modern defaults).
  • bcrypt cost 12 for user password hashes.
  • AES-256-GCM for at-rest secret fields, key derived via SHA-256 from SECRET_KEY.
  • HMAC-SHA256 for webhook signatures.
  • SHA-256 as the general-purpose content hash for attachment addressing.
  • Standard crypto/rand for tokens and salts.
• Key management. The SECRET_KEY is a single environment variable. For higher-assurance deployments, source it from your secret store (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets from an external provider). Ithura does not require the value to live in a plain .env file.
• Key rotation. secrets.MaybeDecrypt is used at every read site so a new key can be rolled out incrementally: switch the write key, then a background worker re-encrypts existing rows on read.
• Post-quantum posture. Not part of Ithura today. TLS terminator can select post-quantum-hybrid suites where the underlying library supports them.

Article 21(2)(i): Human resources security, access control policies, and asset management

• Role-based access. Workspace admin (20), member (15), guest (5). Per-project explicit roles override workspace defaults. Custom roles available on Pro.
• Directory sync. SCIM 2.0 for user and group provisioning (Enterprise). New joiners provisioned from your IdP inherit the role mapped to their group.
• Deprovisioning. SCIM DELETE /Users/{id} or admin action sets the user inactive; sessions revoked; API tokens invalidated.
• Just-in-time SSO provisioning creates users on first login only for domains you verified (see Verified domains).
• Asset inventory in Ithura's context is your workspace inventory of projects and integrations; both are visible to admins in the settings.

Article 21(2)(j): Multi-factor authentication or continuous-authentication solutions, secured voice / video / text communications, and secured emergency-communications systems

• Multi-factor authentication. TOTP-based 2FA per user, workspace-wide enforcement on Pro.
• Secured voice / video. Huddles run on LiveKit with end-to-end encryption available (see the Huddles guide).
• Secured text. In-app chat and comments transit HTTPS. Content is not end-to-end encrypted at rest; if that is required, do not use in-product messaging for the content in question.
• Emergency communications. Ithura does not attempt to be an emergency channel. Provision a separate out-of-band channel for that purpose.

Reporting

Article 23 of NIS2 requires notification of significant incidents. Ithura's audit log is the primary evidence source for a workspace-level incident investigation. Export it during triage; the entries include actor, source IP, User-Agent, action, and target for every admin operation.