Compliance

MolTrace supports regulated scientific workflows by preserving evidence, enforcing human review, maintaining audit trails, and aligning documentation with applicable quality and regulatory expectations.

Coverage areas

Area	MolTrace documentation must cover
ICH Q3A(R2)	Organic impurities in new drug substances, including reporting, identification, and qualification context.
ICH Q3B(R2)	Degradation products in new drug products.
ICH Q3C	Residual solvent classes and permitted daily exposure context.
ICH Q3D	Elemental impurity risk assessment support.
ICH M7(R2)	Mutagenic impurity assessment support and expert review requirements.
ICH Q2(R2) and Q14	Analytical validation and analytical procedure development context.

Guideline values, jurisdiction notes, and nitrosamine language must be verified from official FDA, EMA, PMDA, Health Canada, and ICH sources before publication.

GxP and electronic records

MolTrace supports GxP-style workflows through evidence preservation, human review, export sign-off, audit trails, and role-based controls. Customers remain responsible for validating MolTrace within their own quality system and SOPs.

For 21 CFR Part 11 and EU Annex 11 support, document:

Unique user identity and access controls (see Security Policy → Access controls).
Time-stamped audit trails — see Audit trail integrity for the tamper-evident hash chain backing Part 11 §11.10 audit-trail expectations.
Electronic signature meaning, signer, timestamp, and linked record — see Electronic signatures below.
Record retention and retrieval.
Backup and recovery procedures, with a target recovery history of at least 35 days when contracted.
IQ/OQ support materials for enterprise validation packages — see Computer system validation (GAMP 5 / CSA) below.

Electronic signatures (21 CFR Part 11)

Electronic-signature creation is a hardened, dedicated path that supports the four classic Part 11 sub-paragraphs:

§11.100 attribution. The signer identity is taken from the authenticated server principal — the client-supplied signer_name / signer_email are ignored (the declared value is recorded in metadata for transparency, but never trusted as identity).
§11.70 record linking. A signature_digest binds a SHA-256 record_content_hash of the exact signed record snapshot, so a signature is non-transferable to a different record or version. The legacy signature_hash is preserved alongside it for back-compat verify.
§11.50 manifestation. A durable, human-readable manifestation — printed signer name + UTC date/time + meaning + bound-record hash + attestation — renders as JSON or printable HTML and is embedded in the inspection-package copy.
§11.200 re-auth. Signing is gated by a fresh step-up re-authentication (see Step-up re-authentication); the step-up factor and Authenticator Assurance Level are captured into the signature and the audit event.

Two read endpoints expose the §11.50 / §11.70 affordances:

GET /esignatures/records/{id}/verify (optional ?recompute=true) — re-derives the digest (detects row tampering) and optionally re-snapshots the live record (detects post-sign change).
GET /esignatures/records/{id}/manifestation (?format=json|html) — renders the durable Part 11 manifestation.

Every signing emits an esignature.create audit event that is auto-chained by the audit-chain listener, so signatures inherit tamper-evidence. Legacy (pre-binding) rows verify as unbound (valid=null) — never as tampered — and inline callers (system-release approval, pilot sign-off) keep working; the system-release approval signature is now content-bound. Framing stays “supports Part 11, not compliant-for-you”. (v0.50.0, 2026-06-19)

ALCOA+ hardening for controlled records

The ALCOA+ data-integrity principles map onto specific guarantees in the platform:

Attributable / why. A regulated change records its reason in a queryable reason_for_change column (not buried in a metadata blob), enforced by a shared alcoa.require_reason_for_change primitive — a whitespace-only reason is rejected with 422 (defense-in-depth beyond the model’s min_length=1).
Legible / contemporaneous. Every regulated mutation stamps a server-side UTC timestamp; request models exclude timestamp fields (a client-supplied created_at is rejected). A regression test pins this.
Original / raw vault. The raw-evidence write-once guarantee no longer silently degrades — a failure to set a raw archive read-only (chmod 0o444) raises under a settings-gated strict mode (ALCOA_RAW_VAULT_STRICT_IMMUTABLE, default off) instead of warning. Integrity-on-read (SHA-256 re-verify with 409 + an audited raw_fid.integrity_failure event) was already enforced.
Enduring / reversible-by-record. Archiving a controlled record is now an explicit soft delete — deleted_at + deleted_by + reason_for_change, the row retained and never session.delete-d; soft-deleted records are excluded from the default list and retrievable via ?include_deleted=true for the audit trail. deleted_by is the authenticated principal, never client-supplied.
Immutable audit trail. audit_events / audit_checkpoints are declared immutable-by-design — no DELETE route, no soft-delete, and a regression test guards that no audit-targeting DELETE route exists. The audit hash chain (see Audit trail integrity) backs this.

Framing stays “supports ALCOA+ / 21 CFR Part 11, not compliant-for-you”. (v0.51.0, 2026-06-19)

Computer system validation (GAMP 5 / CSA)

The platform surfaces a regenerable, change-controlled validation package at the release boundary — assembling the existing requirement → risk → test → execution traceability chain plus the release approval signatures and a CI-evidence ingestion seam into one deterministic artifact per release, re-runnable on every CI build and inspection. Framing stays “supports GAMP 5 / CSA, not compliant-for-you” — it accelerates the customer’s IQ / OQ / PQ evidence + change control; it does not replace the customer’s own CSV.

GET /system-releases/{id}/validation-package. Assembles the latest traceability matrix + requirement / risk / test counts + IQ / OQ / PQ-from-CI evidence + change-control state + release approval signature manifestations into one deterministic artifact per release. IQ and PQ are honestly marked customer-supplied rather than fabricated by the platform; OQ is drawn from the CI test summary.
POST /system-releases/{id}/evidence — the CI ingestion seam: a CI step POSTs parsed pytest / coverage results into the release’s structured slots. The endpoint refuses once the release is approved / released, because the §11.70-bound release snapshot is itself change-controlled.

Validated-state change control (GAMP 5 §14 / Annex 11). Any change to a validation project that is approved / archived or attached to an approved / released system release requires a reason_for_change (sourced from the payload metadata_json, reusing the ALCOA+ require_reason_for_change primitive). The gate is wired into the six child-mutation entry points (update_validation_project, plus the create paths for URS, functional spec, risk assessment, test protocol, and test case). Draft / in-progress projects stay freely mutable, so the validation workflow is not penalized before sign-off. (v0.52.0, 2026-06-20)

Human review

AI-supported interpretations, threshold assessments, and optimization recommendations must remain reviewable by qualified users before export or submission use.

AI governance

Regentry outputs may influence customer submission work, so MolTrace should document human-in-the-loop review, explainability, model versioning, performance monitoring, and change control. Any EU AI Act classification or conformity claim requires legal and regulatory review before publication.

Data protection

The compliance package should include the DPA, subprocessors list, SCCs where needed, retention policy, and security policy. Data residency is a roadmap item, not a shipped option: the production backend runs in Google Cloud region us-central1, so no EU-pinned deployment should be represented as available until one is contracted and documented.

Privacy: data-subject requests and residency

MolTrace processes customer workspace data as a processor. These are controls designed to support the customer’s GDPR obligations as controller — not a compliance certification. The posture a DPO should record is:

Processor assistance under Art. 28(3)(e), not delegation. MolTrace assists; the controller verifies identity, decides scope, applies the Art. 15(4) balancing, and responds to the data subject.
The DSAR / erasure planner is library-only. Internal tooling with no API endpoint and no product surface — Art. 15 access discovery (every store, including those that cannot be exported or erased, plus sub-processor recipients, retention windows, source, and the automated-decision position), an Art. 17 per-store erasure plan, and the Art. 12(3) deadline (one month; the two-month extension only if the subject is notified with reasons inside month one).
Execution of deletions is deliberately not automated. Deletions happen on documented controller instruction, never because a plan was generated.
Four honest dispositions across every classified store group (15 today): erase · pseudonymise + restrict · retain (legal obligation, Art. 17(3)) · immutable ledger. A legal hold suspends destruction everywhere and never downgrades the immutable-ledger disposition.
Pseudonymisation is never reported as erasure. Under Recital 26 a tokenised or hashed record remains personal data, so it is reported as retained and restricted — as is the ALCOA+ soft-delete. This is enforced as a test invariant.
Identity cannot be erased from the immutable audit ledger today. The audit chain’s canonical payload covers the identity fields, so an erasure-by-rewrite is indistinguishable from tampering and would undercut Part 11 §11.10(e) retention. Crypto-shredding (hash the ciphertext, destroy the per-subject key) is documented as a seam with four preconditions — not a shipped capability. security_events carries no hash chain, so those identity columns are safely pseudonymisable.
Residency: single-region, no tenant region pinning. All tenants are served from Google Cloud us-central1. Until pinning is contracted and documented, no EU-pinned or customer-selected region should be represented as available.

Customer-facing detail lives at Privacy Policy → Data-subject requests and the right to erasure and → Data residency. (v0.62.0, 2026-06-26)

Framework control-evidence register (SOC 2 / ISO 27001)

MolTrace does not hold a SOC 2 report or an ISO/IEC 27001 certificate. Both are audited outcomes issued by an independent auditor or certification body. What the platform publishes instead is a self-assessment of control coverage — a register that maps implemented controls to the criteria an auditor would test, so a prospect or auditor can see the readiness position. It is not a claim of certification, and only an auditor’s report (SOC 2) or a certificate (ISO 27001) provides assurance.

The repository carries a machine-checkable control → evidence register (compliance/controls.json) that maps each of the 21 in-repo security controls (built across Security Prompts 5–21) to the SOC 2 Trust Services Criteria, the ISO/IEC 27001:2022 Annex A themes, and repo-relative evidence paths — the actual source, test, and design files backing each control.

SOC 2 criterion	Annex A	Representative in-repo controls
`CC6` logical access	`A.5`, `A.8`	Deny-by-default policy-as-code authorization, Argon2id password hashing, field-level envelope encryption, TLS / transport headers, enterprise SSO (OIDC), SCIM 2.0 provisioning, MFA / passkeys / step-up, session hardening, rate limiting.
`CC7` system operations, detection, response	`A.5`, `A.8`	Tamper-evident audit hash chain, security detections engine + SIEM sink, incident-response program + GDPR breach-notification deadline engine, backup / DR restore-integrity verifier, CSPM IaC drift gate.
`CC8` change management	`A.8`	Secure-SDLC CI gates (SAST / SCA / IaC), signed supply chain (SBOM + SLSA provenance + verify-at-deploy), least-privilege CI, GAMP 5 / CSA validation lifecycle + change control, committed-secret scanning.
`CC4` monitoring	`A.5`, `A.8`	Coordinated vulnerability disclosure (RFC 9116 `security.txt` + VDP) and the pen-test program.
`PI1` processing integrity	`A.8`	Audit hash chain, 21 CFR Part 11 e-signature binding + manifestation, ALCOA+ controlled-records primitives, validation lifecycle.
`C1` confidentiality	`A.8`	Field-level envelope encryption + KMS / BYOK seam, ALCOA+ controlled records.
`A1` availability	`A.5`, `A.8`	Per-tenant + per-route rate limiting and request-size guard, backup / DR restore-integrity verifier.
`P1` privacy	`A.5`	Incident-response program + GDPR breach-notification deadline engine.

A validator (compliance/validate_controls.py, pure stdlib, usable as a CLI or importable) enforces that every in-repo control cites a resolvable evidence path and carries a framework mapping. It is fail-on-drift — deleting or moving a control’s evidence file breaks the check — so the map cannot silently rot into a marketing artifact. Seven tests cover the shipped register validating clean plus the validator catching a missing path, an unmapped control, a duplicate entry, a missing via attribution, and any no-claim-of-certification violation. The shipped register validates clean at 21 controls with all evidence paths resolving. The change added no application or runtime code — register, validator, and documentation only. The human-readable view is docs/security/compliance_controls_map.md. (v0.61.0, 2026-06-29)

What the register does not claim

Controls MolTrace does not implement in-repo are labelled inherited or operational rather than presented as product evidence:

Inherited — physical and data-center security, carried by the cloud providers’ own attestations under the shared-responsibility model (CC6 / A.7).
Operational — HR screening and security-awareness training (CC1 / A.6); governance, the risk register, and risk-assessment methodology (CC1, CC3 / A.5); vendor and sub-processor risk management plus DPAs (CC9 / A.5); continuous-compliance tooling (Vanta / Drata) and the audits themselves (CC4 / A.5); 24/7 on-call paging and hosted SIEM ingest (CC7 / A.8), which the in-repo detections feed but whose routing is operational.

Framework status as recorded in the register: SOC 2 Type II — not held, controls designed to support the Trust Services Criteria, pursuing; ISO/IEC 27001:2022 — not held, controls mapped to and aligned with Annex A; ISO/IEC 27017 + 27018 — not held, cloud / PII-in-cloud extensions that would accompany an ISO 27001 ISMS; 21 CFR Part 11 / GAMP 5 / ALCOA+ — controls designed to support, with validation and SOPs owned by the customer; GDPR — processor controls designed to support the customer’s Art. 33 / 34 obligations. See also Certifications and assurance for the status labels permitted in customer-facing material. (v0.61.0, 2026-06-29)

Trust Center

docs/security/trust_center.md is the in-repo source content for a customer-facing Trust Center — the posture summary and trust artifacts a prospect should be able to self-serve. Publishing it as a web page is operational front-end work; the file is the source of record. It carries the same not-held framing verbatim and covers:

Posture at a glance, grouped as access, data protection, integrity and traceability, detection and response, secure delivery, and resilience — each line traceable to a control in the register.
Framework status table — every framework listed as not held, per the statuses above.
Sub-processor register — the in-repo source for the published list. Customers are notified of material changes per their DPA.

Sub-processors and the data each handles:

Sub-processor	Purpose	Data handled
Google Cloud	Backend hosting (Cloud Run), managed PostgreSQL (Cloud SQL, private IP), object storage, secrets, and key management	All tenant data at rest, the audit ledger, security events, encrypted IdP / MFA secrets, and the raw-FID vault.
Vercel	Primary frontend hosting (moltrace.co)	Browser session traffic and proxied API requests; no first-party database.
Customer-configured IdP (for example Okta, Microsoft Entra)	Enterprise SSO (OIDC) and SCIM provisioning	Authentication assertions and provisioning lifecycle; customer-owned federation, not MolTrace-operated.
GitHub	Source hosting and CI/CD (Actions)	Source code and build artifacts, keyless Sigstore provenance, and keyless Workload Identity Federation deploys — no production tenant data and no stored cloud service-account key.
Hosted SIEM + paging (operational, optional)	Security-alert log ingest and 24/7 on-call	Forwarded security-alert logs; configured per deployment.

(v0.61.0, 2026-06-29)

Compliance package

Customer-facing compliance requests should route to compliance@moltrace.com. The package should include security controls, DPA, subprocessors, incident response overview, audit-log behavior, validation support, and current certification status.

Current certification status is that no SOC 2 report and no ISO 27001 certificate is held today. Answer certification questions with the control-evidence register and the Trust Center posture summary — control coverage designed to support those frameworks — never with a status label that implies an audit has happened. (v0.61.0, 2026-06-29)

Legal review gate

This page is live as a compliance posture location, but final claims, certification statements, and jurisdiction-specific commitments must be approved before paid onboarding.