Security Overview

Scope

This overview covers the Verinten platform and the ClinicRadar product as operated by Kollekting Apps LLC. It is written for a procurement or vendor review and describes controls that are implemented. Where a control is planned rather than in place, it says so.

Access control

• Email and password authentication with verified email required before a workspace can be created or a subscription purchased.
• Sessions are server-validated on every security-sensitive page and action. There is no middleware-only authorisation anywhere in the system.
• Five workspace roles — Owner, Admin, Analyst, Viewer, Billing — with permissions enforced server-side, never by hiding an interface element.
• Sessions are listed, revocable, and expiring; revocation takes effect against the authoritative store, not a cache.
• Internal administration sits behind an identity gateway in addition to application authorisation, and every internal action is audited.

Tenant isolation

• Every tenant-owned record carries a tenant identifier and every query is scoped by it.
• Tenant context is resolved server-side from the session. A workspace slug in a URL is an address, never an authorisation.
• Every object-storage key and every background job message is prefixed with the owning tenant.
• Cross-tenant access is covered by automated tests.

Data protection

• Encryption in transit throughout, with HSTS enforced.
• Encryption at rest for all managed data stores.
• Object storage is private. Nothing is publicly addressable; downloads use authenticated routes or short-lived signed links.
• Support-case bodies are stored encrypted at the application layer.
• No patient data is collected — a product boundary rather than a setting.

Application security

• All external input — forms, webhooks, provider payloads, queue messages — is schema-validated before use.
• A restrictive content security policy, `nosniff`, frame denial, and a strict referrer policy on every response.
• Secure, HttpOnly, SameSite cookies with CSRF protection.
• Edge rate limiting and bot protection on public and API surfaces.
• Secrets held in the platform secret store, never in the repository, with an automated repository secret scan in the verification gate.
• Browser source maps are disabled in production; Worker source maps are uploaded privately.

Operations

• Isolated development, staging, and production environments with separate data stores and credentials.
• Forward-only database migrations with point-in-time recovery for up to 30 days.
• Structured logging with redaction of credentials, tokens, payloads, and personal evidence.
• Background processing is at-least-once with idempotent consumers and a dead-letter queue.
• A documented release procedure with post-deploy observation and rollback criteria.

Vulnerability reporting

Reports go to the security contact above. We acknowledge every report and tell the reporter what we found. Good-faith testing within the limits published on the security page will not lead to legal action from us.

Not yet in place

• No third-party audit certification (SOC 2, ISO 27001) has been obtained. We will not imply otherwise.
• Single sign-on and enforced multi-factor authentication are not in the first release.