Security Posture

The Cognethics platform is built on a layered security model with controls mapped to the major compliance frameworks. This page describes the controls Cognethics operates across the platform; the Security & Privacy Whitepaper available at the bottom goes into significantly greater depth for compliance, privacy, and infosec reviewers.

Security controls in place

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 at the database, queryset, and MCP-handler layers — a mandatory tenant foreign key on every record, organization scoping on every query, and a permission check at every tool handler — not optional, opt-in filters that a developer could forget to apply.

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 can 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.

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.

Sub-processors

The Cognethics sub-processor list is published with a public RSS change feed at developers.cognethics.com/trust/sub-processors/feed.xml. Any change to the list emits a webhook event and an audit-log entry. See the Sub-Processors page for the full list.

Webhook & event integrity

Outbound webhooks are HMAC-signed with per-subscription secrets and retried with exponential backoff. Delivery history is retained for replay and verification.

Control categories

The platform implements security, audit, and data-protection controls across all major domains. For a detailed mapping of implemented controls to recognised frameworks, request the Security & Privacy Whitepaper using the form at the bottom of this page.

Security & audit controls

Cognethics operates security and audit controls mapped to the SOC 2 Trust Services 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: Infrastructure hosted on AWS with redundancy across multiple Availability Zones within the customer-selected region, plus a cross-region hot standby for regional disaster recovery; 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, and strict tenant-level data segregation.
• Privacy: Consent-driven data collection, deletion workflows, data minimisation, and audit trails for personal-data access.

Healthcare & HIPAA safeguards

Cognethics supports HIPAA-covered entities and business associates. Technical safeguards include encrypted PHI fields (AES-256 at rest), role-based access with TOTP-based MFA, comprehensive audit logging with hash-chain integrity, and automated breach incident tracking. The underlying AWS infrastructure is covered by a signed Business Associate Agreement (available via AWS Artifact). Customer BAAs are available on request via the Trust Center contact form — select the Legal / DPA / BAA topic.

Cryptographic safeguards

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 (CMK) 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.

Data protection & privacy

Cognethics provides built-in compliance management for GDPR, CCPA, and LGPD:

• GDPR: Data Processing Addendum (DPA) with Standard Contractual Clauses (Module 2 — controller-to-processor, EU 2021/914); right-to-erasure workflows; Article 30 ROPA exports generated from your processing-activity register.
• CCPA & LGPD: Consumer rights templates (access, deletion, portability, opt-out); consent management for personal data collection.
• Data residency: Your tenant is provisioned in the AWS region and Availability Zone you select, so customer data resides in the region(s) that meet your residency requirements.
• Resilience & disaster recovery: Each tenant runs across multiple Availability Zones within its region. For tenants whose primary region is in the United States, production data is continuously replicated to a second AWS region (default: US East), maintained as a hot standby for regional disaster recovery. Multi-AZ and multi-region redundancy are distinct controls — multi-AZ protects against the loss of an Availability Zone within a region, while cross-region replication protects against the loss of an entire region. Customers can pin both their primary and disaster-recovery regions.

Request the Cognethics Security & Privacy Whitepaper

The Security & Privacy Whitepaper is our most detailed published treatment of the platform's security and privacy program — the full control mappings, data-protection practices, and architectural assurances behind the summary above, written for compliance, privacy, and infosec reviewers. Submit the form below with your work email and we'll send you a copy.

Questions?

For security or compliance questions — or to request a customer BAA or DPA — contact the Trust team and select the matching topic.

← Back to Trust Center