Our controls, mapped to the SOC 2 Trust Services Criteria.

This page maps the controls ChironAI actually operates to the five SOC 2 Trust Services Criteria — Security (the Common Criteria), Availability, Confidentiality, Processing Integrity, and Privacy. It is written for the CISO, the auditor, and the security-questionnaire reviewer who need to see the controls before a formal report exists. Every control listed below is a control we run today; nothing here is aspirational.

A detailed, evidence-referenced controls-mapping document — walking each Trust Services Criterion to the specific operational and architectural control that satisfies it — is available to institutional customers under NDA. Request it from security@mindhyve.ai.

The Common Criteria cover access control, logical and physical protection, change management, and the monitoring that underpins every other criterion. These are the controls ChironAI leans on hardest.

• •Fine-grained clinical RBAC: permissions are clinical capabilities (not coarse role buckets) that compose into per-institution roles; effective permissions are resolved server-side on every request and cached in Redis for performance.
• •Multi-tenant isolation: a tenant-ID guard runs on every request before query execution, and PostgreSQL row-level security enforces isolation at the database layer under a non-owner application role (RLS active in production).
• •MFA (TOTP) for staff accounts, with step-up MFA re-verification required for privileged actions — bulk signing, document amendment, and super-admin operations — plus a configurable per-organization policy to require MFA for privileged actions.
• •Tamper-evident, hash-chained audit log (previous-hash linkage + HMAC signature) enforced immutable at the database layer: no UPDATE or DELETE is permitted, via a database trigger and revoked table grants, regardless of caller.
• •Secrets management: all secrets live in Azure Key Vault and are accessed via Managed Identity (keyless — no secrets in environment variables or code).
• •Network isolation: private endpoints and VNet isolation for service-to-service traffic; HSTS enforced on the production application.
• •Independent testing: external penetration testing on a defined cadence and at major release boundaries (results available to institutional customers under NDA).

The system is available for operation and use as committed. ChironAI treats availability as a deployment property configured per institution, not a single public number. The Availability & Resilience page covers this in full.

• •Azure Container Apps host production workloads with health probes and horizontal scale.
• •Blue-green and canary deployment patterns: production rollback is a traffic-split flip rather than a redeploy, and canary traffic surfaces regressions before they reach the full user base.
• •Continuous-restore PostgreSQL backups via Azure PostgreSQL Flexible Server.
• •Recovery-time and recovery-point objectives (RTO / RPO) are documented per institutional deployment in the deployment Statement of Work.

Information designated confidential is protected as committed. For ChironAI that means layered encryption and contractually-scoped access.

• •AES-256 encryption at rest across application data and binary clinical media.
• •TLS 1.3 in transit with modern cipher suites.
• •Application-level AES-256-GCM encryption applied to PHI fields, in addition to at-rest disk encryption.
• •Per-organization Business Associate Agreement (BAA) scoping every institutional PHI relationship.
• •Audit-trailed access: every privileged action is written to the tamper-evident audit log described under the Common Criteria.

System processing is complete, valid, accurate, timely, and authorized. This is where ChironAI’s clinical-workflow discipline shows up as a control set: the AI reasons, but a licensed clinician authorizes what enters the chart.

• •SHA-256 document-signature integrity: every signed clinical document carries a content hash captured at signature time, with verify-on-read validation on retrieval.
• •Immutable signed versions: amendments to signed documents are recorded as new versions; the original signed version remains immutable and verifiable, enabling full historical reconstruction.
• •Must-review-before-final gate: every AI artifact is reviewed and signed by a licensed clinician before it enters the chart — the AI reasons, the clinician decides.
• •Deterministic lab-value extraction: lab values are extracted by deterministic OCR (Azure Document Intelligence), not generative transcription, and are confidence-gated with a human-review path for low-confidence fields.

Personal information is collected, used, retained, disclosed, and disposed of in conformity with commitments and applicable criteria. The Data Handling page documents the architecture behind these controls.

• •No customer data or PHI in model training: Eve-Genesis (Clinical Edition) is 100% synthetic by construction — an architectural property, not a policy that can be revised under pressure.
• •Functional ADMT opt-out honored across all automated-analysis paths, consistent with CCPA/CPRA and AB 375.
• •Data-subject rights (access, rectification, erasure, restriction, portability, objection) supported under CCPA/CPRA, GDPR, and UK GDPR, routed through the institutional customer as data controller.
• •Retention per data class (commonly ~7 years for clinical records in the United States, per jurisdiction elsewhere), documented in the deployment Statement of Work.
• •Frontier reasoning model provider(s) are accessed under enterprise contract with no training on, or retention of, customer data or PHI.

For institutional customers running formal vendor diligence, the following artifacts are available on request under NDA. We only list what we actually provide; where an artifact does not yet exist, we say so rather than imply one.

• •Controls-mapping document: each SOC 2 Trust Services Criterion walked to the specific control that satisfies it, with evidence references.
• •External penetration-test summary (most recent engagement).
• •Business Associate Agreement (BAA) template.

We do not currently maintain a completed CAIQ or SIG questionnaire. We answer security-questionnaire content directly from the controls-mapping document above and welcome a customer’s own questionnaire format.

• Security — the operational and architectural detail behind the Common Criteria.
• Availability & Resilience — deployment, backup, and recovery posture.
• Subprocessors — the third parties that touch the service, and on what terms.
• Incident Response & Breach Notification — how we detect, contain, and notify.
• Compliance and Data Handling — the regulatory frameworks and the data architecture.