# Compliance Readiness Plan

**Status:** Draft plan  
**Requested by:** Ramon / James  
**Scope:** FDA 21 CFR Part 11, ISO/IEC 27001, FDA 21 CFR Part 820/QMSR, FDA 21 CFR Part 210, ISO 13485, ISO 14971

## Short Answer

We should not answer "yes" to any of these today.

The honest answer is:

> Ask QIEN has some early building blocks for regulated use, including authentication, tenant-scoped RBAC, audit logging, ticket history, AI call logging, and human expert review. It is not yet validated or certified as compliant with FDA 21 CFR Part 11, ISO/IEC 27001, 21 CFR Part 820/QMSR, 21 CFR Part 210, ISO 13485, or ISO 14971. We can create a phased compliance-readiness program to close the gaps and produce evidence.

This is not only a database question. These frameworks require a combination of product controls, infrastructure controls, documented procedures, validation evidence, security governance, training, supplier management, and audit evidence.

## Important Distinctions

### "Database follows Part 11"

Part 11 is about electronic records and electronic signatures. The database can support Part 11 controls, but the system as a whole must define which records are predicate-rule records, whether electronic records replace paper, how signatures work, how records are retained, and how audit trails are protected.

Current Ask QIEN posture: **not Part 11 compliant yet**.

### "Database follows ISO 27001"

ISO/IEC 27001 is an information security management system standard for an organization, not a database certification. A database can be configured in support of ISO 27001 controls, but ISO 27001 requires an ISMS: risk assessment, control selection, policies, access reviews, incident response, supplier management, monitoring, internal audits, management review, and usually third-party certification.

Current Ask QIEN posture: **not ISO 27001 certified; product can be made ISO 27001-control-ready**.

### "Data models check compliance against CFR 820, CFR 210, ISO 13485, ISO 14971"

This is a product capability, not a certification. Ask QIEN can assist experts by mapping tickets, KB entries, and generated responses to relevant regulatory/standards clauses, but the AI must not certify compliance or replace expert/regulatory review.

Current Ask QIEN posture: **spec exists for regulatory standards-grounded guidance; implementation should remain expert-reviewed**.

## Current Building Blocks

| Area | Current support | Gap |
| --- | --- | --- |
| Authentication | Auth.js magic-link/SSO flow, users, sessions | Need MFA/SSO policy options, session policy, access review evidence |
| Authorization | Tenant memberships and role guards | Need systematic access-review workflow and more cross-tenant negative coverage |
| Audit log | `audit_log` table for key app events | Need immutable/append-only guarantees, broader event coverage, export, retention, tamper-evidence |
| Ticket history | Tickets and ticket messages preserve workflow history | Need formal record classification and retention policy |
| AI traceability | AI processing runs, artifacts, AI call logs | Need model/prompt/version evidence package and AI output review controls |
| Human review | Expert approves final responses | Need explicit approval/e-signature semantics for regulated records |
| Translations | Source hashes and review states for translated content | Need formal translation review policy if translated content is regulated record content |
| Validation | Automated tests exist | Need formal software validation / computer software assurance package |
| Security | Basic app security and tenant isolation | Need ISMS-level controls, backups, incident response, encryption posture, monitoring, vendor review |

## Recommended Phased Plan

### Phase 0 — Compliance Scope and Claims

**Goal:** Stop accidental over-claiming and define exactly what Ask QIEN is and is not claiming.

**Actions:**

1. Draft an approved external answer for Ramon/customer conversations:
   - "Not certified today."
   - "Designed with auditability and regulated workflows in mind."
   - "Compliance-readiness roadmap in progress."
   - "Customer remains responsible for its own QMS and regulatory decisions."
2. Define intended use:
   - Expert support and quality issue workflow.
   - Not a medical device.
   - Not autonomous regulatory decision-making.
   - Not a system of record for all GMP/QMS records unless explicitly configured and validated.
3. Define regulated record categories:
   - Ticket submission.
   - Clarification answers.
   - Expert response.
   - KB entry and revision history.
   - AI-generated draft/summary/assessment.
   - Translation and reviewed translation.
4. Create a compliance claims matrix:
   - "Supported by design."
   - "Implemented technical control."
   - "Validated in our SDLC."
   - "Externally audited/certified."

**Done criteria:**

- No marketing/sales copy says "Part 11 compliant" or "ISO 27001 compliant" without evidence.
- A one-page customer-facing compliance posture statement exists.

### Phase 1 — Part 11 / Electronic Records Gap Assessment

**Goal:** Determine whether and where Part 11 applies, then design controls for those records.

**Actions:**

1. Identify predicate-rule records that customers may maintain in Ask QIEN.
2. Decide whether Ask QIEN electronic records are the authoritative record or merely supporting notes.
3. Add record classification metadata:
   - regulated record flag
   - record type
   - source language
   - source version/hash
   - retention policy
4. Expand audit log coverage:
   - create/update/delete/archive actions
   - login/session/security events
   - permission changes
   - export events
   - e-signature events
   - AI draft generation and expert acceptance/rejection
5. Add append-only/tamper-evident audit trail design:
   - no app-level update/delete for audit rows
   - actor identity
   - before/after values where appropriate
   - reason-for-change for regulated edits
   - optional hash chain or external log sink
6. Design electronic signature support:
   - meaning of signature: reviewed, approved, closed, rejected
   - signer identity
   - signer re-authentication step
   - signature manifestation on exported record
   - signature-to-record binding
7. Define record retention/export:
   - human-readable export
   - audit-trail export
   - retention lock / legal hold
   - restore test evidence

**Done criteria:**

- A Part 11 control matrix exists.
- Every Part 11-applicable record has owner, retention, audit, export, and signature decisions.
- Missing controls are ticketed.

### Phase 2 — Computer Software Assurance / Validation Package

**Goal:** Produce evidence that the system was built and tested for its intended regulated use.

**Actions:**

1. Create validation plan:
   - intended use
   - system boundaries
   - risk classification
   - validation approach
   - release acceptance criteria
2. Map product requirements to tests:
   - auth/RBAC
   - tenant isolation
   - audit trails
   - ticket state machine
   - expert response approval
   - AI human-review controls
   - data export
3. Create traceability matrix:
   - requirement -> implementation -> automated test -> release evidence
4. Add release evidence package:
   - version/commit
   - migration list
   - test results
   - known issues
   - deployment approval
5. Add change-control process:
   - risk assessment per change
   - migration review
   - rollback plan
   - post-deploy smoke test

**Done criteria:**

- Each release can produce a validation evidence bundle.
- High-risk workflows have automated regression tests and documented manual acceptance where needed.

### Phase 3 — ISO 27001 Readiness

**Goal:** Make the organization and product ready for an ISO 27001-style ISMS, whether or not certification is pursued immediately.

**Actions owned by business/operations:**

1. Define ISMS scope.
2. Create asset inventory.
3. Perform risk assessment.
4. Write policies:
   - access control
   - acceptable use
   - incident response
   - backup/restore
   - vendor management
   - secure development
   - vulnerability management
   - data retention/deletion
5. Establish access review cadence.
6. Establish vendor/supplier review:
   - Vercel
   - database provider
   - email provider
   - LLM providers
   - monitoring/logging providers
7. Decide whether to pursue third-party ISO 27001 certification or only customer-facing control readiness.

**Actions owned by engineering:**

1. Implement RLS or stronger DB-level tenant isolation.
2. Add security event logging.
3. Add backup and restore test runbook.
4. Add secret-scanning and dependency-scanning gates.
5. Add least-privilege production access model.
6. Add admin access review exports.
7. Document encryption in transit/at rest for each environment.
8. Add incident-support tooling:
   - user access disablement
   - tenant export
   - audit export
   - suspicious event queries

**Done criteria:**

- ISO 27001 control-readiness checklist exists.
- Core technical controls have evidence.
- Business policies and review cadences are active.

### Phase 4 — Regulatory Standards-Grounded Data Model Review

**Goal:** Let Ask QIEN assist expert review against medical-device/pharma standards without pretending AI is the regulator.

This should build on `docs/feature_regulatory_standards_guidance.md`.

**Actions:**

1. Create source registry:
   - 21 CFR Part 820/QMSR
   - 21 CFR Part 210
   - 21 CFR Part 11
   - ISO 13485
   - ISO 14971
2. Resolve licensing:
   - FDA/eCFR content can be handled differently from ISO content.
   - ISO full text should not be ingested or reproduced without permitted rights.
3. Add clause/source metadata:
   - source
   - edition/version
   - effective date
   - clause/section
   - licensing status
4. Add expert-only "regulatory considerations" panel:
   - possible relevant clauses
   - rationale
   - confidence
   - citations
   - "expert review required" language
5. Add AI prompt guardrails:
   - no definitive reportability/compliance conclusions
   - cite retrieved sources
   - distinguish facts, assumptions, and expert decisions
6. Add evaluations:
   - representative ticket set
   - expected source families
   - unacceptable assertions
   - hallucination checks
7. Add audit trail:
   - what source/version was retrieved
   - what the model suggested
   - what the expert accepted/edited/rejected

**Done criteria:**

- Expert can see standards-grounded suggestions with source/version traceability.
- AI outputs are advisory and reviewed.
- ISO content is not ingested beyond license permissions.

### Phase 5 — Customer-Ready Compliance Evidence Room

**Goal:** Prepare materials customers can review without giving unsupported guarantees.

**Artifacts:**

1. Security overview.
2. Architecture diagram.
3. Data flow diagram.
4. Subprocessor list.
5. Access-control model.
6. Audit-trail description.
7. Backup/restore summary.
8. SDLC and validation summary.
9. AI governance summary.
10. Regulatory-source governance summary.
11. Current compliance posture statement.
12. Roadmap and known limitations.

**Done criteria:**

- We can answer customer diligence consistently.
- Any "compliant" wording is backed by specific evidence and reviewed by counsel/compliance advisor.

## Suggested Response to Ramon

> Short answer: not yet, and we should not claim that the database is Part 11, ISO 27001, 21 CFR 820, 21 CFR 210, ISO 13485, or ISO 14971 compliant today. We do have early foundations: RBAC, tenant isolation, audit logging, ticket history, AI call logging, and human expert review. But those standards require more than a schema. They require defined record scope, validation evidence, audit-trail controls, retention/export, electronic signature semantics where applicable, security governance, policies, and in ISO 27001's case an organizational ISMS. The right next step is a phased compliance-readiness project: first define claims and regulated record scope, then build Part 11 controls and validation evidence, then pursue ISO 27001 readiness, and separately implement expert-reviewed standards-grounded guidance against CFR 820/210, ISO 13485, and ISO 14971.

## Risks

**Over-claiming:** Saying "compliant" too early can create customer, legal, and regulatory risk.

**Part 11 scope ambiguity:** Part 11 depends on predicate-rule records and actual customer use. Scope must be documented.

**ISO licensing:** ISO 13485 and ISO 14971 are copyrighted. We need a license strategy before ingestion, embedding, or excerpt display.

**AI false authority:** A model can sound definitive. The UI and prompts must keep expert accountability explicit.

**Validation burden:** Formal validation evidence takes ongoing process discipline, not a one-time code change.

**Security governance:** ISO 27001 readiness needs company-level operating practices, not just engineering tickets.

## External References

- FDA Part 11 guidance: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
- FDA Computer Software Assurance guidance: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-system-software-0
- FDA General Principles of Software Validation: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation
- FDA QMSR overview: https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-system-qs-regulationmedical-device-current-good-manufacturing-practices-cgmp
- ISO/IEC 27001:2022: https://www.iso.org/standard/27001
- ISO 13485:2016: https://www.iso.org/standard/59752.html
- ISO 14971:2019: https://www.iso.org/standard/72704.html