Security

Most clinical systems rely on process controls to reduce data drift, fabrication, and audit gaps. PrismCDM enforces trust through architecture.

• Source Classification. Every displayable value carries an evidence classification that follows the value throughout its lifecycle.
• Provenance. Every conclusion can be traced from the protocol through Trial Intelligence, execution, evidence, and submission, to the inspection.
• Runtime validation. The platform refuses to display values that do not carry valid classification and a recognized missing-value state.
• CI gates. The Source Fidelity gate runs on every pull request and refuses to merge code that introduces invented-data patterns.
• Renderer enforcement. The Presentation Model layer rejects forbidden-field violations at the boundary between the engine and the rendered artifact.
• Missing Value States. NOT_AVAILABLE, REPRESENTATIVE, and AWAITING_SOURCE are first-class types; the absence of a value is itself a sourced fact.
• Inspection Evidence Package. The regulated artifact that consolidates the full architectural record for a study, generated on demand from the same substrate that ran the study.

The result: invented data is structurally impossible, not just discouraged.

Security, compliance, Source Fidelity, traceability, and inspection readiness are engineered into the platform from the architecture upward, not added afterward through process. This is the philosophical commitment that organizes every section below.

PrismCDM is deployed on modern managed cloud infrastructure designed for availability, resilience, encryption, and automated recovery.

• Multi-availability-zone deployment.
• Managed database with point-in-time recovery.
• Encrypted object storage for artifacts and evidence.
• Automated, encrypted backups with periodic recovery testing.
• Centrally managed secrets and key management.

• Multi-factor authentication (MFA). Required for production access and supported for customer accounts.
• Single sign-on (SSO). Supported via OIDC for enterprise customers. SAML is planned.
• Role-based access control (RBAC). Permissions scoped per tenant; least-privilege defaults.
• Session management. Configurable session expiration and re-authentication for sensitive actions.
• Internal access. Granted on a need-to-know basis, reviewed periodically, and logged.

• In transit. All connections use TLS 1.2 or higher.
• At rest. Data is encrypted at rest using industry-standard algorithms managed through the cloud key management service.
• Key management. Keys are rotated on a regular schedule. Customer-managed keys are supported under commercial agreements where required.

• Peer-reviewed pull requests, required for every change.
• Automated security scanning on every pull request.
• Dependency vulnerability scanning with prioritized remediation.
• Secret detection and pre-commit hooks.
• Static analysis for known vulnerability patterns.
• Source Fidelity CI gate that refuses invented-data patterns.
• CI/CD enforcement that prevents bypass of the gate set above.
• Release signing and provenance attestations on production builds.

• Regular vulnerability scanning of running infrastructure.
• Continuous dependency monitoring with automated alerts.
• Risk-prioritized remediation aligned with severity and exploitability.
• Documented patch management cadence.
• Responsible disclosure program (see Section 12).

PrismCDM separates four log categories, each retained according to its purpose.

• Application logs. Operational diagnostics.
• Security logs. Authentication, access control, and anomaly signals.
• Audit logs. Append-only records of regulated operations, identity-bound, aligned with 21 CFR Part 11 architectural primitives.
• Immutable provenance logs. The architectural record of how every conclusion was produced.

• Tenant isolation. CUSTOMER_SOURCE values never cross tenant boundaries. Isolation is enforced at the data layer, not at the UI layer.
• Ingest. Customer-source material is labeled at ingest with its evidence classification and tenant scope.
• Processing. Tenant data is processed within tenant scope. Tenant data is not used to train models that operate across customers.
• Retention. Retention follows the executed commercial agreement and applicable regulatory requirements.
• Exit. On termination, the customer can request export and deletion of customer-source data under the executed commercial agreement.

The platform is designed for availability with redundant multi-zone deployment, continuous monitoring, automated recovery, and tested disaster recovery procedures.

Specific Service Level Agreements for commercial customers are governed by the executed Master Services Agreement. Evaluation surfaces (the website, the Generate a Brief funnel, the Strategy Session intake) are best-effort and covered by Section 13 of the Terms of Service.

We work to reduce the likelihood and impact of incidents and to be transparent when one occurs.

• Severity levels. Incidents are classified P1 (major service-impacting), P2 (significant degradation or risk), and P3 (limited impact), with corresponding response and communication targets.
• Process. Detection, containment, eradication, recovery, and structured post-incident review.
• Root cause analysis. P1 and P2 incidents receive a documented root cause analysis with corrective and preventive actions.
• Customer notification. Customers affected by an incident are notified in line with the executed commercial agreement and applicable law.
• Aim. Useful information promptly, not complete information slowly.

We welcome reports from the security research community. If you believe you have discovered a vulnerability in PrismCDM, contact us through /contact with reason “Compliance Review” or “Technical question”. Please:

• Give us a reasonable opportunity to investigate and address the issue before public disclosure.
• Avoid privacy violations, destruction of data, or service disruption during your testing.
• Provide enough detail (steps to reproduce, affected components, your environment) to allow us to validate and resolve the issue.

We acknowledge receipt promptly, work with you in good faith, and credit your work where appropriate.

PrismCDM's AI posture is part of the same architectural commitment as Source Fidelity.

• Customer data is never used to train shared models that operate across customers.
• AI features operate inside tenant boundaries.
• Generated outputs preserve provenance and carry the same evidence classification as any other value.
• Human review remains required for regulated activities.
• Where third-party AI providers are used, requests are transmitted only for the purpose of providing the requested functionality and are governed by contractual and technical safeguards.

Conservative language applies: PrismCDM is architected for the regulatory environments our customers operate in, and independent validation follows our product maturity roadmap.

Additional depth on the current architecture, supporting evidence, and roadmap milestones is shared during the Compliance Review under NDA.

Third-party processors are under contract with confidentiality and security obligations consistent with our own. The current subprocessor list is maintained in the Trust Center and shared during the Compliance Review.

• Detailed architecture diagrams and component descriptions.
• Data flow diagrams and tenant isolation enforcement details.
• Identity, access, and audit documentation.
• Source Fidelity Architecture documentation.
• Subprocessor list with the role each plays.
• SOC 2 readiness package and roadmap.
• Business continuity and disaster recovery summary.
• Data Processing Agreement and Business Associate Agreement where applicable.

To request a Compliance Review, contact us through /contact with reason “Compliance Review”.

Security questions and reports can be directed to /contact with reason “Compliance Review” for posture questions or “Technical question” for disclosure reports.