Compliance Traceability Index¶
This directory contains requirements traceability matrices mapping regulatory standards to their implementation in Cloud-Native DCS. These documents are intended for FDA auditors, quality assurance teams, and engineers evaluating compliance coverage.
How to Use These Documents¶
- Auditors: Each document maps specific regulatory clauses to their implementation and evidence. Start with the summary table below, then drill into the per-standard document for detailed traceability.
- QA: Use the gap analysis sections to plan validation activities and track progress toward full compliance.
- Engineers: Review coverage status to understand which regulatory requirements are met and where gaps remain.
The models these matrices trace are live objects in the running system.
Compliance Summary¶
| Standard | Scope | Coverage | Status | Detail |
|---|---|---|---|---|
| ISA-88 / IEC 61512 | Batch process control | High | Substantially Implemented | Physical, procedural, recipe, and batch models mapped to CRDs; Part 3 library/transformation and Part 2 scheduling features are implemented at the data-model/controller layer with no UI/API/CLI surface (removed in #480, CRDs retained); named Partial rows remain |
| IEC 61131-3 | Programming languages (SFC, ST) | High | Implemented | SFC engine, ST interpreter, recipe/procedural chart execution |
| IEC 61499 | Function block architecture | — | Migrated off | Not a compliance posture: the product migrated from IEC 61499 to IEC 61131-3 cyclic-scan execution on 2026-03-16; the doc records the migration |
| 21 CFR Part 11 | Electronic records & signatures | High | Substantially Implemented | Immutable audit trail + validating webhook, OIDC auth, HMAC-SHA256 e-signatures, audit archival to TimescaleDB, executable IQ/OQ/PQ. Remaining gaps: two-factor enforcement delegated to the IdP (§11.100(c), §11.200(a) Partial) and identification-code/password controls (§11.300(a-b) Planned) |
| GAMP 5 | Computerized system validation (CSV) | High | Category 4 (Configured Product) | Per-layer categorization (infrastructure / configured product / configuration / Category 5 boundary) plus a V-model lifecycle mapping: executable IQ/OQ/PQ, ChangeRequest + e-signatures, and Qualification AuditRecords feed the customer's validation activities |
| ALCOA+ data integrity | FDA/MHRA data-integrity principles | High | Implemented | All nine principles mapped to shipped controls: OIDC-attributed immutable AuditRecords, synchronous timestamping, HMAC-SHA256 record-bound signatures, two-tier retention (etcd + TimescaleDB) with unified query and regulatory export |
| ISA-95 / IEC 62264 | Enterprise-control integration | Low | Partial | B2MML mapping, MES integration patterns |
| IEC 62443 | Industrial cybersecurity | Moderate-High | SL-C target { 2 2 2 2 2 2 2 } — FR 3 conditional on SR 3.3 and on SR 3.6 for the raw device write path (#1683); the other named conditionals closed (#971–#974, #977) | Full 51-row SR matrix, clause-verified 2026-07-18 against the purchased ANSI/ISA-62443-3-3 text (#968). Pod security, RBAC, distroless images, cert-manager mTLS, NetworkPolicies enforcing the IEC 62443 zone/conduit model, MQTT TLS+auth+ACL, cosign signing, SBOMs, OPC UA SignAndEncrypt. Clause-verified SL 3 elements: non-repudiation (SR 2.12), audit-information protection (SR 3.9), programmatic audit access (SR 6.1 RE(1)), crypto integrity on IP conduits (SR 3.1 RE(1)); reference cluster runs Talos (immutable node OS, cutover completed 2026-05-12) |
| IEC 62443-4-1 | Secure development lifecycle | Moderate | ML 2 baseline (7 of 8 practices); SVV gap pending external V&V engagement | All 47 requirements assessed 2026-07-18 (#970); SDL practice docs under docs/sdl/ (process/RACI, security-requirements spec, interface catalog + DiD design, secure coding standard, defect + update management); Table 3 tester-independence plan (single external engagement covers SVV-1/2/3/4 + review seats); public wording scoped to "aligned to 62443-4-1 practices" |
| IEC 62443-4-2 | Component technical security requirements | Moderate | Component SL-C 2 self-assessed, with CR 3.3 and CR 3.6 Partial (#1683); the named closures done (#971–#974, #977, #978) | All shipped components classified as software applications (3.1.42); full CR + SAR matrix clause-verified 2026-07-18 (#969); CCSC 2 delegation register documenting every platform-delegated countermeasure (IdP accounts/passwords, etcd at-rest, NTP, admission signature verification, physical segmentation); SAR 3.2 malicious-code mechanism qualification |
| OPC 30081 (PA-DIM) (inline-only — no detail doc) | OPC UA Process Automation Device Information Model | High | Subset | 6 types registered (PADIMType + 5 Signal* subtypes); BrowseNames match spec exactly. 4 PADIMType children over-claim Mandatory vs spec Optional -- fix tracked |
| OPC 40223 (Pumps) (inline-only — no detail doc) | OPC UA for Pumps and Vacuum Pumps | Moderate | Subset | PumpType registered with 7 group children at exact spec BrowseNames; leaf properties intentionally read live from server. VacuumPumpType deferred |
| OPC 40080 (Process Valves) (inline-only — no detail doc) | OPC UA for Process Valves (purported) | -- | N/A | Spec not published by OPC Foundation; absence verified and tested |
Status Legend¶
| Indicator | Meaning |
|---|---|
| Implemented | Requirement is fully implemented with tests and evidence |
| Substantially Implemented | Majority of requirements met; named gaps remain, documented per-clause in the matrix |
| Partial | Core functionality exists but gaps remain |
| Planned | Architecture is designed but implementation has not started |
| N/A | Requirement does not apply to this system |
Document Structure¶
Traceability documents share a common shape, though not every document carries every section (e.g., some omit a standalone Gap Analysis or Roadmap when the matrix rows themselves carry the gap status). The typical sections:
- Header -- Standard name, version, and applicability scope
- Requirements tables -- Requirement, Status, and Implementation evidence (column layout varies by standard)
- Gap analysis -- Honest assessment of what is not yet implemented
- Roadmap -- Planned work to close gaps
Each per-standard document is authoritative for its own structure and status detail. This index summarizes.
Supporting Documents¶
- Executable Validation Protocols (IQ/OQ/PQ) — architectural
overview of
dcs qualify {iq,oq,pq}, the executable replacement for blank IQ/OQ/PQ templates. Referenced from the 21 CFR Part 11 §11.10(a) row. - DR Drill Log — Audit Archive Corruption (2026-04-22): evidence artifact for the 21 CFR Part 11 §11.10(c) restore-path qualification (archive tamper detection, immutable S3 mirror restore).
- DR Drill Log — Certificate Expiry (2026-04-22): evidence artifact for the certificate-expiry DR scenario referenced from the IEC 62443 SL-3 operator checklist.
- DR Drill Log — Backup/Restore (2026-07-18): evidence artifact for IEC 62443 SR/CR 7.3 RE(1): backup → pre-restore integrity verification (tamper + truncation detection) → restore, incl. the restore-path defect the drill caught and fixed (#973).
Related Documentation¶
The documents in this directory are formal traceability matrices for the regulated standards Cloud-Native DCS is being qualified against (ISA-88, ISA-95, IEC 61131-3, ISA 5.1, IEC 62443, 21 CFR Part 11). For the adjacent modular automation reference standards that describe our role as a plant-level orchestrator, VDI/VDE/NAMUR 2658 (MTP), IEC 63280, NAMUR NE 148, and NAMUR NE 175 (NOA), see the Modular Automation Standards section. Those documents describe architectural alignment with industry standards. Clause-by-clause regulatory traceability stays in this directory.