Regulatory Compliance Matrix: WO System
Date: 2026-02-13 | Classification: Compliance — Engineering & QA
Scope: FDA 21 CFR Part 11, HIPAA Technical Safeguards, SOC 2 Type II
1. FDA 21 CFR Part 11 — Electronic Records & Signatures
§11.10 Controls for Closed Systems
| Requirement | CFR Reference | WO Feature | Implementation | Status |
|---|
| System access limited to authorized individuals | §11.10(d) | RBAC model (7 roles) | Role-per-entity permissions, tenant isolation via RLS | ✅ Ready |
| Use of authority checks | §11.10(g) | Approval gate guards | State machine guards check role + permission before transition | ✅ Ready |
| Device checks for validity of data input | §11.10(h) | Schema validation | JSON Schema + DB constraints + optimistic locking (version field) | ✅ Ready |
| Ability to discern invalid or altered records | §11.10(c) | Append-only audit trail | DB trigger prevents UPDATE/DELETE on audit_trail table | ✅ Ready |
| Operational system checks to enforce sequencing | §11.10(f) | State machine transitions | Deterministic transition map with guard functions; DAG dependency validation | ✅ Ready |
| Audit trail documentation | §11.10(e) | AuditTrail entity | Captures entity_type, entity_id, action, performed_by, timestamp, previous_value, new_value | ✅ Ready |
| Retention of electronic records | §11.10(c) | PostgreSQL + archive policy | Append-only table; partitioned by tenant + date; configurable retention | ✅ Ready |
| Use of secure computer-generated timestamps | §11.10(e) | Server-side timestamps | performed_at DEFAULT now() — not client-supplied | ✅ Ready |
| Protection of records for accuracy and integrity | §11.10(c) | Immutable audit events | Append-only + version field + optimistic concurrency | ✅ Ready |
§11.50 Signature Manifestations
| Requirement | CFR Reference | WO Feature | Implementation | Status |
|---|
| Signed record includes name of signer | §11.50(a)(1) | ElectronicSignature.signerId → Person.name | Foreign key to Person entity with display_name | ✅ Ready |
| Date and time of signature | §11.50(a)(2) | ElectronicSignature.signedAt | signedAt DateTime @default(now()) — server timestamp | ✅ Ready |
| Meaning associated with signature | §11.50(a)(3) | ElectronicSignature.meaning | Free text: "Approval of Work Order {id}", "QA Review of {id}" | ✅ Ready |
| Signature bound to record | §11.50(b) | Approval.signatureId FK | One-to-one binding: Approval → ElectronicSignature; immutable after creation | ✅ Ready |
§11.70 Signature/Record Linking
| Requirement | CFR Reference | WO Feature | Implementation | Status |
|---|
| Signatures linked to records to prevent falsification | §11.70 | Cryptographic binding | Hash of (WO version + signer_id + timestamp + meaning) stored in signature record | ⚠️ Partial |
| Signatures not excised, copied, or transferred | §11.70 | Immutable signature records | Append-only table; no UPDATE/DELETE allowed; referential integrity constraints | ✅ Ready |
§11.70 Gap: Cryptographic hash binding is specified in the architecture but requires implementation of the hash generation function and storage field. Estimated effort: 2 days.
§11.100 General Requirements for Electronic Signatures
| Requirement | CFR Reference | WO Feature | Implementation | Status |
|---|
| Each signature unique to one individual | §11.100(a) | Person entity + authMethod | signerId FK to Person; authMethod captures credential type | ✅ Ready |
| Identity verified before establishing signature | §11.100(b) | Re-authentication flow | Frontend re-auth prompt; backend validates session + credential | ⚠️ Requires Vault |
| Signatures administered by organization | §11.100(c) | Tenant-scoped signature config | Per-tenant approval chain configuration; admin-managed signer assignments | ✅ Ready |
2. HIPAA Technical Safeguards (45 CFR §164.312)
Access Controls
| Requirement | HIPAA Reference | WO Feature | Implementation | Status |
|---|
| Unique user identification | §164.312(a)(2)(i) | Person entity + tenant scoping | Person.id unique per tenant; enforced via RLS | ✅ Ready |
| Emergency access procedure | §164.312(a)(2)(ii) | Break-glass escalation | Admin override with enhanced audit logging + justification required | ⚠️ Design Only |
| Automatic logoff | §164.312(a)(2)(iii) | Session management | Session timeout configurable per tenant; signature window timeout | ⚠️ Frontend |
| Encryption and decryption | §164.312(a)(2)(iv) | Data-at-rest encryption | PostgreSQL TDE + GCP Cloud SQL encryption; Vault for secrets | ✅ Ready |
Audit Controls
| Requirement | HIPAA Reference | WO Feature | Implementation | Status |
|---|
| Hardware, software, procedural mechanisms for recording access | §164.312(b) | AuditTrail + OTEL | Every WO operation logged to append-only audit trail; OTEL spans for system-level tracing | ✅ Ready |
Integrity Controls
| Requirement | HIPAA Reference | WO Feature | Implementation | Status |
|---|
| Mechanisms to authenticate ePHI | §164.312(c)(1) | Version field + checksums | Optimistic locking prevents silent overwrites; integrity validated on read | ✅ Ready |
| Electronic mechanisms to corroborate ePHI not altered | §164.312(c)(2) | Append-only audit + hash chain | Each audit event references previous event hash (chain of custody) | ⚠️ Partial |
Transmission Security
| Requirement | HIPAA Reference | WO Feature | Implementation | Status |
|---|
| Integrity controls for transmitted ePHI | §164.312(e)(1) | TLS 1.3 | All API communication over HTTPS; mTLS for inter-service | ✅ Ready |
| Encryption of ePHI in transit | §164.312(e)(2)(ii) | TLS + encrypted event bus | NATS TLS; GCP internal encryption; no plaintext transmission | ✅ Ready |
PHI Detection Gap
| Gap | Severity | Mitigation |
|---|
| WO detail/summary fields may contain PHI (patient names, device serial numbers linked to patients) | High | Implement PHI scanner on WO creation and update; flag for review if detected; encrypt flagged fields at application layer |
| Job Plan work instructions may reference patient-adjacent data | Medium | PHI classification metadata on JobPlan; automated scanning before storage |
| TimeEntry records may capture provider-identifiable information | Low | Already scoped to Person entity; access controlled via RBAC |
3. SOC 2 Type II Trust Service Criteria
CC6 — Logical and Physical Access Controls
| Criterion | SOC 2 Reference | WO Feature | Implementation | Status |
|---|
| Restricts logical access | CC6.1 | RBAC (7 roles, entity-level permissions) | Role → Permission matrix; tenant RLS isolation | ✅ Ready |
| New access provisioned/modified/removed | CC6.2 | Admin role manages Person + Team assignments | Assignment audit trail; role changes logged | ✅ Ready |
| Authenticates users | CC6.3 | SSO + re-auth for signatures | ElectronicSignature.authMethod captures method; session binding | ✅ Ready |
| Restricts access to information assets | CC6.6 | Tenant isolation + entity-level permissions | PostgreSQL RLS; Vendor role restricted to own WOs | ✅ Ready |
CC7 — System Operations / Monitoring
| Criterion | SOC 2 Reference | WO Feature | Implementation | Status |
|---|
| Detects and reports failures | CC7.1 | Circuit breaker + observability | Three-state circuit breaker per agent worker; Prometheus alerting | ✅ Ready |
| Monitors system components | CC7.2 | OTEL + Grafana dashboards | Distributed tracing (wo.transition, wo.approval spans); custom metrics | ✅ Ready |
| Evaluates security events | CC7.3 | AuditTrail + event analysis | Audit events streamed to SIEM; anomaly detection on transition patterns | ⚠️ Partial |
| Responds to identified vulnerabilities | CC7.4 | Incident response integration | WO system can generate incident WOs from security events | ⚠️ Design Only |
CC8 — Change Management
| Criterion | SOC 2 Reference | WO Feature | Implementation | Status |
|---|
| Authorizes, designs, develops, configures, documents, tests, approves, and implements changes | CC8.1 | Core WO lifecycle | The WO system IS the change management system — every change to a validated system requires a WO with planning, execution, review, approval, and documentation | ✅ Primary |
CC8.1 is CODITECT's strongest SOC 2 alignment. The WO module is not merely compliant with change management requirements — it implements them as the primary mechanism.
CC9 — Risk Mitigation
| Criterion | SOC 2 Reference | WO Feature | Implementation | Status |
|---|
| Identifies and assesses risks | CC9.1 | Priority field + regulatory flag + dependency graph | WO risk classification at creation; DAG analysis for cascade risk | ✅ Ready |
| Risk management policies | CC9.2 | Checkpoint framework + approval chains | Configurable per-tenant approval policies; mandatory checkpoints for regulated changes | ✅ Ready |
4. Compliance Readiness Summary
| Framework | Total Requirements | ✅ Ready | ⚠️ Partial/Design | ❌ Gap | Coverage |
|---|
| FDA 21 CFR Part 11 | 16 | 13 | 3 | 0 | 81% |
| HIPAA §164.312 | 10 | 7 | 3 | 0 | 70% |
| SOC 2 Type II (CC6–CC9) | 11 | 8 | 3 | 0 | 73% |
| Total | 37 | 28 | 9 | 0 | 76% |
Path to 100% — Remaining Work
| Item | Effort | Blocking? | Framework |
|---|
| Cryptographic hash binding for §11.70 | 2 days | No | FDA |
| Vault integration for re-authentication (§11.100) | 1 week | Yes | FDA |
| PHI scanner for WO content fields | 3 days | No | HIPAA |
| Break-glass emergency access procedure | 2 days | No | HIPAA |
| Session timeout enforcement (frontend) | 1 day | No | HIPAA |
| Audit event hash chain (integrity proof) | 3 days | No | HIPAA |
| SIEM integration for security event analysis | 1 week | No | SOC 2 |
| Incident WO generation from security events | 3 days | No | SOC 2 |
| Security event evaluation automation | 1 week | No | SOC 2 |
Total effort to 100%: ~5 weeks engineering (parallelizable across 2 engineers)
5. Validation Documentation Requirements
For FDA-regulated deployment, the WO module requires:
| Document | Purpose | Status |
|---|
| IQ (Installation Qualification) | Verify system installed per specifications | Template needed |
| OQ (Operational Qualification) | Verify system operates within parameters | Test suite maps to requirements |
| PQ (Performance Qualification) | Verify system performs under real-world conditions | Requires production pilot data |
| Validation Plan | Master plan for IQ/OQ/PQ activities | Draft from SDD/TDD |
| Traceability Matrix | Map requirements → design → tests → results | Automatable from test suite |
| Risk Assessment | FMEA or equivalent for system risks | ADR-based risk register exists |
| Computer System Validation (CSV) Summary | Executive summary for auditors | Template needed |
CODITECT's agent architecture can automate generation of the Traceability Matrix and CSV Summary from existing ADRs, test results, and audit trail data — a significant time and cost savings for customers.
Copyright 2026 AZ1.AI Inc. All rights reserved.
Developer: Hal Casteel, CEO/CTO
Product: CODITECT-BIO-QMS | Part of the CODITECT Product Suite
Classification: Internal - Confidential