Security and compliance posture.
This page documents the current state of our 21 CFR Part 11 controls, GDPR position, encryption, audit-trail immutability, sub-processors, and vulnerability disclosure. Each section reports what is live today, what is in flight, and what is planned through Q4 2026, with named contacts to verify any line.
PDF · 12 pages · v1.0,
Where we stand today
- No-PHI architecture Implemented
- Designed without PHI ingress (detection + redaction + audit)
- SOC 2 Type I In progress
- In progress, target Q3 2026
- 21 CFR Part 11 In progress
- Controls implemented, validation package in preparation
- GDPR In progress
- DPA available on request, no EU data residency yet
- Encryption in transit Implemented
- TLS 1.3
- Encryption at rest Implemented
- AES-256
- Data residency Planned
- US-East today, EU planned Q4 2026
Posture statement
Last reviewed
We do not claim certifications we have not earned. SOC 2 Type I fieldwork is in progress with a target completion of Q3 2026, and SOC 2 Type II will follow. Below is the full controls and process detail you would expect from a vendor assessment, with explicit status on every line.
If your IT or QA team needs anything not covered here (a completed CAIQ, a pen-test letter, our Validation Master Plan draft, or a sponsor-specific DPA), use the inquiry form at the bottom of this page or email security@askmytrials.com directly. Two-business-day SLA.
No-PHI architecture
Last reviewed
AskMyTrials is designed to operate without PHI ingress. Detection, redaction, and audit logging make the no-PHI posture a verifiable architectural property, not a contractual assertion.
Contractual
Every user agrees to a no-PHI Acceptable Use Policy at first sign-in. Customers warrant in MSA that they will not submit PHI to AskMyTrials.
User-facing
Every free-text input surface (eligibility scenarios, per-trial Ask, feedback forms, sales-inquiry forms) shows a non-modal no-PHI notice immediately above the input. The eligibility checker scans input in real time and soft-blocks the submit button when patient identifiers are detected.
Server-side detection
Inbound free-text payloads are checked against a shared PHI detector that recognizes SSNs, MRNs, phone numbers, emails, ZIP+4 codes, full dates, dates-of-birth, addresses, IP addresses, and Luhn-valid credit-card-shaped numbers. High-confidence hits return HTTP 400 with a user-correctable error. The eligibility-intent path additionally runs a small LLM classifier as a second pass.
Egress redaction
Every outbound payload to an AI vendor (OpenAI chat completions, Voyage embeddings, Cohere rerank) is scrubbed by the same detector immediately before send. Conversation history is scrubbed on assembly so a single tainted turn cannot leak forward into subsequent calls. A CI build invariant fails the build if any new vendor-call file does not import the scrubber.
Storage redaction
Questions, answers, and feedback comments are redacted before they are written to Postgres, so even the 25-year audit copy in the queries and query_feedback tables never contains raw PHI.
Audit and reporting
Every block and every redaction is logged to audit_log. Organization administrators can see PHI-attempt counts; repeated attempts are escalated to the organization administrator for offline coaching.
BAAs are insurance against risks you accept into the system. The no-PHI architecture removes the risk surface entirely. If a subprocessor is breached tomorrow, no AskMyTrials traffic identifies a specific patient because no identifying traffic ever leaves our perimeter.
See the user-facing Acceptable Use Policy for the contractual layer.
21 CFR Part 11 controls
Last reviewed
The matrix below maps each Part 11 control to its current implementation in AskMyTrials. Status reflects what is live today, not what is on the roadmap. Validation evidence (test plans, runbooks, signed Validation Master Plan) is shared under NDA as part of vendor assessment.
| Reference | Control | Our implementation | Status |
|---|---|---|---|
| 11.10(a) | Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. | Migration-versioned schema with checksum-validated SHA-256 on every uploaded document. Pre-deployment test suite covers RAG retrieval correctness, audit-log integrity, and rate-limit behavior. Validation Master Plan in preparation as part of the SOC 2 Type I package. See evidence. | In progress |
| 11.10(b) | Ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. | TMF ZIP Bundle Export produces an FDA-ready archive (cover PDF, per-query PDFs, audit-trail CSV, manifest.json with SHA-256 hash chain) for any trial and any window. PDFs use embedded standard fonts; CSVs are UTF-8. See evidence. | In progress |
| 11.10(c) | Protection of records to enable their accurate and ready retrieval throughout the records retention period. | Postgres point-in-time recovery via Supabase, daily backups retained 30 days. Storage objects retained for the lifetime of the trial plus 25 years per ICH GCP, configurable per sponsor agreement. See evidence. | Implemented |
| 11.10(d) | Limiting system access to authorized individuals. | Role-based access control enforced at the Supabase row level (RLS) and API route level. Coordinators see only trials assigned to their site. Pharma admins see only trials owned by their organization. CRO admins inherit access scoped through parent_org_id. See evidence. | Implemented |
| 11.10(e) | Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. | Immutable audit_log table with append-only RLS policy. Every create, update, delete, export, and access action logs actor, action, target, timestamp, IP, and metadata. Audit entries cannot be modified or deleted by application users; service-role writes only. See evidence. | Implemented |
| 11.10(f) | Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate. | Document approval workflow gates RAG retrieval: only documents with current_version + IRB approval (where required by doc_type) are searchable. Sponsor verification on pinned answers requires medical_monitor or pharma_admin role. | Implemented |
| 11.10(g) | Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand. | Authority check at every API boundary via authenticatedClient(). Org-type checks (pharma, cro, site) gate sensitive endpoints (analytics, amendments, exports). Failed authority checks return 401 or 403 and are logged in access_anomalies for review. See evidence. | Implemented |
| 11.50(a) | Signed electronic records shall contain information associated with the signing that clearly indicates: the printed name of the signer, the date and time when the signature was executed, and the meaning associated with the signature. | TMF Bundle cover page captures Prepared by and Reviewed by signature blocks with name, title, date, and attestation paragraph. Pinned answer create / edit / delete actions log actor and timestamp. Full e-signature workflow (Part 11 Subpart C) is on the roadmap with the Validation Master Plan. | In progress |
| 11.50(b) | The items identified in paragraph (a) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record. | Audit-log fields are exported alongside records in TMF Bundles and ROI PDFs. Signature metadata appears in human-readable form on cover pages. | Implemented |
| 11.70 | Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. | Signature metadata is stored in audit_log rows whose primary key references the target record. Records are content-hashed with SHA-256 on export; the hash is recorded with the signature event so a record cannot be silently swapped for another. See evidence. | In progress |
| 11.100(a) | Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. | User accounts are uniquely keyed by email + auth.uid(). Disabled accounts are soft-deleted, preserving the foreign key for historical signatures. New users with the same email as a disabled account receive a new auth.uid(). | Implemented |
| 11.100(b) | Before an organization establishes, assigns, certifies, or otherwise sanctions an individual's electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual. | Site coordinator identity is verified by the pharma sponsor through site-activation invite codes. Pharma admin identity is verified by AskMyTrials onboarding. MFA can be enforced per organization. SSO/SAML for enterprise tenants is on the roadmap. | In progress |
GDPR posture
Last reviewed
AskMyTrials acts as a Data Processor for sponsor-provided trial documents and as a Data Controller for our own platform user accounts. We sign DPAs with sponsors on request and pass-through DPAs to all listed sub-processors.
Data subject rights
- Access: site coordinators and pharma admins can export their own queries via Settings > Exports.
- Erasure: individual user accounts can be deleted on request. Trial-level data is retained per the sponsor's regulatory retention schedule.
- Rectification: sponsor admins can correct user metadata at any time.
- Portability: TMF Bundle Export and Audit-log CSV provide structured data export.
EU data residency (Frankfurt) is on the roadmap for Q4 2026 alongside SOC 2 Type II.
Data residency
Last reviewed
Today. All production data resides in AWS US-East-1 via Supabase.
Planned. EU residency option (Frankfurt) targeted for Q4 2026. Sponsor-tier customers will be able to elect residency at organization creation. Planned
Access controls and MFA
Last reviewed
Access is enforced at two layers: Postgres row-level security policies on every table containing trial data, and authority checks at every API route boundary. Failed authority checks produce access_anomalies entries reviewable by sponsor admins.
| Role | Scope | MFA |
|---|---|---|
| Site coordinator | Read documents and ask questions for their site's assigned trials only. | Optional |
| Site investigator (PI) | Same as coordinator plus access to all coordinator activity within the site. | Optional |
| Pharma admin | Full read and write across all trials owned by their pharma organization. Manages access codes, pinned answers, exports. | Required |
| Pharma medical monitor | Read across all owned trials; accept and pin FAQ clusters; sign amendment briefs. | Required |
| CRO admin | Scoped to its parent pharma sponsor's trials, linked via parent_org_id. | Required |
| AskMyTrials staff | No production data access by default. Service-role access is gated by named, time-bounded support escalations logged to audit_log. | Required |
Audit trail immutability
Last reviewed
Every business action writes to audit_log. Schema fields: actor_id, action, target_type, target_id, ip, user_agent, metadata jsonb, created_at.
Immutability. Append-only. RLS policy denies UPDATE and DELETE for application roles. Service-role writes are gated by lib/audit.ts and emit on every business action.
Retention. Lifetime of the trial plus 25 years (ICH GCP). Configurable per sponsor agreement.
Export. Sponsor admins can export audit-log CSV per trial or across the portfolio, scoped to a date range.
Encryption
Last reviewed
In transit. TLS 1.3 enforced on all connections. HSTS preload with 2-year max-age + includeSubDomains.
At rest. AES-256 at the storage layer (Supabase Postgres + Storage, AWS S3 backend). Backups are also encrypted at rest.
Key management. Encryption keys are managed by the underlying providers (Supabase, AWS). AskMyTrials staff do not have direct access to raw key material.
Backups and disaster recovery
Last reviewed
- Backup frequency
- Daily automated Supabase backups
- Retention
- 30 days rolling
- RPO
- 24 hours
- RTO
- 4 hours
Quarterly DR restore drill against a non-production project. Last drill: 2026-04-15.
Sub-processors
Last reviewed
Trial data passes through the third parties listed below. Each operates under a Data Processing Agreement and the pass-through terms in our Master Services Agreement. We notify sponsors before adding a new sub-processor.
| Sub-processor | Purpose | Data type | Region | DPA |
|---|---|---|---|---|
| Supabase | Postgres database, authentication, file storage | All trial data, user accounts, uploaded documents, audit log | US-East-1 (AWS) | View DPA |
| Vercel | Application hosting, serverless functions, CDN | Request metadata, no persistent storage of trial data | Global edge with US primary region | View DPA |
| AWS Bedrock (Anthropic Claude) | LLM chat completions for question answering | Question text and retrieved document excerpts. PHI detector scrubs Safe Harbor identifiers from outbound payloads. Processed in an AWS-isolated environment under the AWS BAA. Inputs and outputs are not retained after processing, not shared with the model provider, and not used for training. | United States for utility tasks. Answer generation routes across AWS global regions under the BAA. | View DPA |
| Voyage AI | Text embeddings for retrieval | Document chunk text and PHI-scrubbed user queries. API traffic excluded from training. | United States | View DPA |
| AWS Bedrock (Amazon Rerank) | Cross-encoder reranking of retrieval candidates | PHI-scrubbed question and candidate chunk pairs. Processed in an AWS-isolated environment under the AWS BAA. Inputs and outputs are not retained after processing, not shared with any model provider, and not used for training. | United States | View DPA |
| CloudConvert | DOCX and PPTX conversion to PDF for ingestion | Source document during conversion only; no persistent storage | Germany (EU) | View DPA |
| Resend | Transactional email (invitations, alerts, security inquiries) | Recipient email, subject, body | United States | View DPA |
Vulnerability disclosure
Last reviewed
We welcome reports from independent security researchers. Send findings to security@askmytrials.com with reproduction steps and any proof of concept.
PGP key available on request for sensitive reports. Reach out via the inquiry form below or email security@askmytrials.com to receive the current public key.
Scope. Production app (askmytrials.com), API endpoints, public marketing site. Out of scope: rate-limit testing, automated scanners against production, social engineering of staff, physical attacks.
Response times. Triage within 2 business days. Fix windows: 90 days for high and critical, 180 days for medium and low.
We will not pursue legal action against researchers who follow this policy in good faith and avoid privacy violations, destruction of data, and service degradation.
Contact
Last reviewed
- Security: security@askmytrials.com
- Privacy: privacy@askmytrials.com
- General: hello@askmytrials.com
2 business days for security inquiries.