Security

The Cognethics platform is built on a layered security model with controls enforced by construction at the database, queryset, and MCP-handler layers — not by optional filters a developer could forget to apply.

Tenant Isolation

Every customer runs in a fully isolated tenant, with a second nested layer of organization-level scoping for customers that operate subsidiaries, sites, or departments within their tenant. Isolation is enforced by construction — a mandatory tenant foreign key on every business model, queryset-level enforcement, and MCP-handler-level enforcement keep data within its tenant boundary, with per-org sub-scoping via the X-Organization-Context header.

Encryption

• At rest: AES-256 across all storage layers (PostgreSQL, S3, EBS) via AWS KMS. Sensitive application data is additionally encrypted with a dedicated per-tenant AWS KMS customer-managed key (CMK) using envelope encryption, giving each tenant cryptographic isolation and automatic key rotation.
• In transit: TLS 1.2+ for all external traffic. Internal services run on a private loopback and are not network-exposed.
• PHI fields: application-layer encryption for protected health information on top of the disk-level encryption.

Compliance-Grade Audit Trail

Every privileged action on the platform is recorded in an append-only audit log with a per-tenant SHA-256 hash chain. Each entry references the hash of the prior entry in the same tenant, and a PostgreSQL immutability trigger blocks updates and deletes at the database level. Customers verify the integrity of their own audit slice via POST /api/audit/verify-chain/.

Access Control

• TOTP-based multi-factor authentication, which organizations can require for all members via tenant policy.
• Role-based access control with a least-privilege default. Permissions are checked at every API surface (REST, MCP, WebSocket).
• Separation of duties: distinct administrative, compliance, and operational permission groups; compliance officers see audit logs without holding platform-administration rights.
• Production access for Cognethics personnel requires mandatory MFA and follows IAM least-privilege with just-in-time elevation and audit.

Enterprise Identity

Self-serve SAML 2.0 and SCIM 2.0 provisioning are available to every tenant. Customers configure their identity provider, SP metadata, attribute mappings, and SCIM tokens through the tenant-admin console. OIDC federation is supported via the platform's federated-identity backend.

Infrastructure Security

• VPC isolation, security-group least-privilege, VPC Flow Logs, and private subnets for the data tier.
• AWS GuardDuty threat detection and AWS Security Hub compliance monitoring.
• Dependency scanning, container image scanning, and quarterly third-party penetration tests.
• Cross-region streaming PostgreSQL standby, encrypted EBS snapshots, and tested restoration procedures.

Cryptographic Posture

Cognethics uses industry-standard cryptography throughout the platform:

• AES-256 encryption for data at rest across all storage layers (via AWS KMS), with a dedicated per-tenant AWS KMS customer-managed key for sensitive application data.
• TLS 1.2+ for all network traffic.

For customers with strict cryptographic-posture requirements, Cognethics offers dedicated FIPS-mode infrastructure — a separate deployment running the OpenSSL FIPS provider and kernel FIPS mode with continuous cryptographic self-tests. Contact the Trust team to provision a FIPS-mode environment for your tenant.

Sub-Processors and Webhook Integrity

The Cognethics sub-processor list is published at /trust/sub-processors/ with a public RSS change feed. Any change to the list emits a webhook event and an audit-log entry. Outbound webhooks are HMAC-signed with per-subscription secrets and retried with exponential backoff; delivery history is retained for replay and verification.

Control Alignment

Cognethics designs its security, audit, and data-protection controls to align with the SOC 2 Trust Service Criteria:

• Security: multi-tenant isolation, encryption at rest and in transit, cryptographic key management with automatic rotation, access-control enforcement at every API boundary.
• Availability: AWS multi-AZ failover capability; uptime monitoring via public /api/v1/health/ and /api/v1/health/ready/ endpoints.
• Processing integrity: input validation, cryptographic integrity checks, and audit logging of all data modifications.
• Confidentiality: encryption of sensitive data at rest and in transit, role-based access control, strict tenant-level data segregation.
• Privacy: consent-driven data collection, deletion workflows, data minimization, and audit trails for personal-data access.

For the full control mappings and the Security & Privacy Whitepaper, see the security posture page. Data-protection commitments are documented in the Data Processing Addendum and Privacy Policy.

Responsible Disclosure

Found a vulnerability? Submit it through the form below — select the Vulnerability Disclosure topic. We respond within one business day and credit researchers who follow responsible-disclosure timelines.

← All legal documents