Program Design · Regulated Medical Device Manufacturing
An FDA-regulated manufacturer with connected products, a plant floor, and a cloud back end — three regulatory worlds that most programs run as three disconnected bureaucracies. Architecture, evidence model, metrics, and the ten ways it fails.
The Measure of the Program
A GRC program is good if it shortens time-to-clearance and time-to-patch. Everything else is overhead wearing a compliance costume.
Policy count, control-mapping breadth, and framework logos are inputs. The program earns its budget in exactly two currencies: how fast a compliant product reaches market, and how fast a vulnerability in the field gets closed without a field action. If neither number improves, the program is a tax.
Sections below are collapsed. The regulatory surface, architecture, metrics and failure modes are the load-bearing parts; open the rest as needed.
Scope first, because most programs are mis-scoped from day one. A digital-manufacturing medtech company is simultaneously three regulated entities: a device manufacturer (quality system, design controls, premarket submissions), a production operation (automated equipment, MES, historians, plant OT), and a digital business (cloud services, customer data, enterprise IT). Each has its own regulator, auditor, and failure mode.
The 2026 alignment matters here. QMSR took effect 2 February 2026, incorporating ISO 13485:2016 by reference into 21 CFR Part 820. FDA re-issued both the premarket cybersecurity guidance and the Computer Software Assurance guidance on 3 February 2026 to align terminology with it. A program still built around the old QSR vocabulary will produce evidence that no longer maps cleanly to how a current investigator or reviewer reads it.
| Domain | Binding / authoritative | What it actually demands of the program |
|---|---|---|
| Quality system | 21 CFR 820 (QMSR, eff. 2 Feb 2026) · ISO 13485:2016 by reference · Part 11 · Part 803 MDR · Part 806 | Design controls, DHF/DMR, CAPA, supplier controls, records integrity. Security work must land inside these objects or it has no regulatory standing. |
| Product cybersecurity | FD&C Act §524B (eff. 29 Mar 2023) · FDA premarket cyber guidance, final 3 Feb 2026 (supersedes Jun 2025 and Sep 2023) · postmarket guidance 2016 | SPDF tied into the QMS, AAMI SW96-aligned security risk file, threat model, machine-readable SBOM, VEX, vulnerability management plan, CVD policy, demonstrated patchability, scoped penetration test. |
| Security risk | ISO 14971 (safety) · AAMI TIR57 / AAMI SW96 (security) · IEC 81001-5-1 · IEC 62304 | Two linked but distinct risk processes. Security risk is expressed in exploitability; safety risk in harm. The bridge between them is the single most-audited artifact. |
| Production & QMS software | 820.70(i) · CSA guidance (final Sep 2025, re-issued 3 Feb 2026) · GPSV (Sec. 6 superseded) · Part 11 | Risk-based assurance by intended use and process risk — not blanket validation. This is what makes patching plant systems possible on a sane cadence. |
| OT / plant floor | IEC 62443 · NIST SP 800-82 | Zones and conduits, asset inventory, segmentation from enterprise, change control that coexists with production schedules. |
| Enterprise & cloud | NIST CSF 2.0 · ISO/IEC 27001 · SOC 2 · HIPAA where PHI flows · state privacy law | Customer assurance and the control backbone everything else inherits. |
| Ex-US | EU MDR · MDCG 2019-16 · NIS2 · EU Cyber Resilience Act · UK, Health Canada, TGA, PMDA | Largely the same evidence, different packaging. Build once, express many — or you will build it three times. |
| AI/ML functions | PCCP guidance · NIST AI RMF · ISO/IEC 42001 · EU AI Act | Change control for models, data lineage, drift monitoring, and a predetermined change plan so retraining isn't a new submission each time. |
The organising principle: one control set, three operating domains, one evidence store. Most failures are architectural rather than technical — the same control gets implemented three times, evidenced three ways, and audited three times, and nobody can answer a simple cross-domain question like "which fielded products contain this component."
The common failure is building a spreadsheet that maps NIST CSF to ISO 27001 to SOC 2 to 800-171 and calling it a control framework. That is a crosswalk, and it operates nothing.
A control framework has controls as the primary object: each has an owner, an implementation, a test procedure, an evidence artifact, and a frequency. Frameworks map to the control, never the reverse. Add a framework and you add mapping columns, not new controls — unless a genuine gap appears, which is the useful signal the structure produces.
| Field | Example |
|---|---|
| Control | Third-party components are inventoried per build with provenance and support status. |
| Owner | Release Engineering (accountable), Product Security (assuring) |
| Implementation | CycloneDX generated in CI on every build; fails the pipeline on unresolvable provenance |
| Evidence | Signed SBOM artifact + pipeline log, retained per DHF retention rule |
| Test | Quarterly: sample 5 releases, confirm SBOM hash matches shipped binary |
| Maps to | §524B(b)(3) · FDA premarket guidance SBOM element · 820.50 supplier controls · SOC 2 CC3.2 · ISO 27001 A.8.8 · CSF ID.AM-02 · 800-171 3.4.1 |
The test of whether you have one: add a new framework obligation and count how many new controls you write. In a healthy framework the answer is usually zero to three. If it is thirty, you are running crosswalks, not controls.
This is where good and bad programs actually separate. Security either lives inside design controls, with defined gates and defined evidence, or it lives beside them as a review that happens too late to change anything.
Safety risk (ISO 14971) and security risk (AAMI SW96 / TIR57) use different currencies. Safety asks how likely a hazardous situation leads to harm. Security cannot use probability the same way — an adversary is not a random failure, and historical rates don't predict attacker behaviour. So security scores exploitability, then hands off to the safety process at a defined join.
What auditors and reviewers probe: whether the join is real. Two registers, no traceability between them, is the most common finding. The test is simple — pick a controlled entry in the security risk file and ask which safety risk file entry it maps to, and who assessed severity. If the answer is a person rather than a record, it fails.
The scoring trap: raw CVSS as a security risk score. CVSS describes a vulnerability in the abstract; it says nothing about whether the component is reachable in your architecture, whether compensating controls exist, or what the clinical consequence is. Use CVSS as an input, layer reachability and exploitability, and let the safety process own severity.
Premarket is a finite project with a deadline. Postmarket runs forever, on a fleet you no longer control, with components you did not write, against a clock set by whoever publishes the CVE. This is the capability that separates a real program from a documentation exercise.
security.txt, a monitored address, and a named human. Researchers who cannot find a path go to the press or the ISAC.Product security gets attention because FDA asks about it in a submission. The plant floor gets attention after a ransomware event stops a line. The programs that handle this well treat production and QMS software as in-scope assets with the same control set and a different risk profile.
CSA is a security enabler, not just a quality efficiency. The historical pattern — treat every production and QMS system as requiring exhaustive validation on every change — makes security patching so expensive that systems stay unpatched for years, which is itself the larger risk. The risk-based approach (assurance proportional to intended use and process risk, leveraging vendor evidence and system-generated records rather than screenshot binders) is what makes a monthly patch cadence achievable on validated systems. Programs that have not re-baselined their validation approach against the current CSA guidance are usually carrying a large, invisible, self-inflicted vulnerability backlog.
| Plant-floor issue | What good looks like |
|---|---|
| Asset inventory | Passive discovery on OT segments; every PLC, HMI, historian, and test fixture in the same CMDB as enterprise assets, flagged by zone. |
| Segmentation | 62443 zones and conduits with documented data flows; enterprise compromise cannot reach production directly, and vendor remote access is brokered and recorded. |
| Patch cadence | Pre-agreed maintenance windows tied to the production calendar, with a risk-based exception route — not ad hoc negotiation per patch. |
| Part 11 records | Audit trails, e-signature integrity, and retention treated as security controls, since record tampering is both a data-integrity and a security event. |
| Continuity | Line-down scenario exercised, including "we cannot trust the MES." Recovery time objective agreed with operations, not assumed. |
| Contract manufacturers | 820.50 supplier controls extended to security: right to audit, incident notification clock, SBOM obligations flowed down in contract. |
Most GRC dashboards measure activity — policies published, training completed, controls mapped, vulnerabilities found. All of those go up when the program is busy and none of them go down when the program is failing. Useful metrics come in two classes, and both are needed: leading indicators that predict a submission or field outcome, and lagging indicators that confirm it.
| Metric | Target | Why this one |
|---|---|---|
| Threat model complete before architecture freeze | 100% | After freeze, findings become change requests nobody funds. This single metric predicts most premarket friction. |
| Security requirements traced to verification evidence | 100% | Traceability is what a reviewer and an investigator both actually check. Untraced requirements are aspirations. |
| SBOM regenerated per build, hash-matched to shipped binary | 100% | A submission-time SBOM is stale the moment it ships and useless for postmarket triage. |
| Components with an active upstream maintainer | >95% | Unmaintained dependencies are unpatchable by definition — this is a leading indicator of a future field action. |
| CVE publication → reachability determination | <5 days | Measures whether the SBOM-to-fleet query actually works. Most programs discover here that it doesn't. |
| Fielded units capable of receiving a patch without a service visit | trend up | Determines whether remediation is a software task or a logistics project. |
| Production/QMS systems on a current patch baseline | >90% | Directly reflects whether the CSA re-baseline actually happened. |
| Security CAPAs open past due date | 0 | The earliest visible sign that findings are being parked rather than closed. |
| Metric | Target | Why this one |
|---|---|---|
| Additional-information letters citing cybersecurity | 0 | Each one is roughly a quarter of schedule. The most expensive lagging metric in the set. |
| Submission cycle time attributable to security review | <10 days | If the program is working, security is not on the critical path. |
| Repeat audit or inspection findings | 0 | Non-repeat findings are normal. Repeats say the CAPA process does not work, which is a far larger finding than the original. |
| Field corrections traceable to a security defect | 0 | The outcome the whole program exists to prevent. |
| Uncoordinated public disclosures | 0 | Measures the CVD process end-to-end, including tone. |
| Customer security questionnaires requiring bespoke response | trend down | A proxy for whether the trust package answers questions before they're asked. |
Ten failure modes, roughly in order of how often they are the actual root cause. Most are structural, and most look like adequate programs from the outside until a submission or an event tests them.
Security keeps a vulnerability register scored on CVSS; quality keeps the 14971 risk file. Neither references the other. The program looks complete from either side and cannot answer the only question that matters — what could this vulnerability do to a patient.
How it surfaces: an audit or reviewer asks for traceability from a security control to the hazard it mitigates, and the answer is a subject-matter expert's recollection.
Fix: make the join an artifact with a controlled identifier, not a meeting. Every entry in the security risk file names its safety risk file counterpart or explicitly records why there is none.
Security is invited once the architecture is set, finds real problems, and every finding becomes a change request competing against launch date. Predictably, most are deferred with a risk acceptance, and the accepted risks accumulate across releases into a portfolio nobody has ever totalled.
How it surfaces: a risk-acceptance register that only grows; or an submission cycle where cybersecurity questions add months.
Fix: gate G1/G2 with security requirements as design inputs. A design input has regulatory standing; a security recommendation does not.
Someone assembles a component list for the submission. It clears. Eighteen months later a critical CVE lands in a widely-used library and the question "are we affected" takes three weeks, because the only SBOM describes a build that no longer exists.
How it surfaces: the first serious postmarket event. Nothing before that reveals it.
Fix: SBOM generation in CI, machine-readable, versioned with the binary, retained alongside the DHF, and queryable across the fielded portfolio in one operation.
Security findings are correctly routed into CAPA, which is then overwhelmed by volume it was never designed for. CAPAs age, extensions accumulate, effectiveness checks become perfunctory. The process meant to demonstrate control becomes the primary evidence of its absence.
How it surfaces: ageing CAPA metrics, repeat findings, and eventually an inspectional observation about the CAPA system itself — a much worse outcome than the original finding.
Fix: triage criteria that distinguish a systemic finding (CAPA) from routine remediation (tracked in engineering with an SLA). Not everything is a CAPA; and separately, nothing that is a CAPA gets a parallel informal backlog.
Production and QMS systems are held to a validation approach where any change triggers extensive revalidation. Patching becomes prohibitively expensive, so it stops. Years later the plant runs unsupported operating systems on systems that cannot be taken down, and the risk register does not reflect it because nobody scored it.
How it surfaces: ransomware, or an OT assessment that finds decade-old software on the line.
Fix: re-baseline against the current CSA guidance — assurance proportional to intended use and process risk, leveraging vendor evidence and system-generated records instead of manual documentation. This is one of the few places where the compliance-and-security interests point the same direction, and it is routinely left on the table.
Product security is funded because FDA asks. Enterprise IT is funded because customers ask. Nobody asks about the historian, so the historian is unowned, unpatched, flat-networked to the business, and running a vendor remote-access tool with a shared credential.
How it surfaces: a production outage, usually not targeted — commodity ransomware that reached the line through a flat network.
Fix: one asset inventory covering enterprise, OT, and test infrastructure; 62443 zones with documented conduits; and operations co-owning the risk with a named accountable leader.
Devices are in clinical use for a decade or more. Software support horizons are rarely stated at launch. When a vulnerability lands on a platform that can no longer be patched, the company has no pre-agreed position, and the announcement of end-of-support arrives in the same communication as the vulnerability.
How it surfaces: customer escalation, sometimes an ISAC advisory, occasionally a field action driven by inability to remediate.
Fix: published support lifecycle at launch with dates; a defined process for compensating controls where patching is impossible; and end-of-support communication decoupled from vulnerability disclosure.
A researcher reports responsibly. The reply comes from counsel, references terms of service, and asks about testing authorisation. The researcher waits, then publishes. The resulting coverage is about the response, not the flaw.
How it surfaces: once, publicly, in a way that is permanently searchable.
Fix: a published CVD policy with safe-harbour language, technical first response within 48–72 hours, and legal in an advisory rather than a front-line role. Credit researchers in advisories; it costs nothing and changes the relationship.
The program adds frameworks — CSF, 27001, SOC 2, 800-171, 62443, AI RMF — each with its own artefacts, each mapped to the others, none operated to the point of producing reliable evidence. Effort goes into the map, and the map is not the territory.
How it surfaces: an audit where controls exist on paper and evidence collection is a scramble; or a customer questionnaire that takes four weeks.
Fix: one control set with mapping columns. Adopting a new framework should add columns, not controls. Measure evidence automation percentage, not mapping coverage.
Quality owns the QMS, IT owns infrastructure, engineering owns the product. Product security sits in the seam. Every function is behaving reasonably, and the gap is invisible until something falls through it — typically a postmarket vulnerability where nobody owns the regulatory reporting determination.
How it surfaces: slowly, then all at once, during an incident where the first two hours are spent establishing who decides.
Fix: one accountable executive for product security with authority over the gates and the postmarket decision rule, and a documented decision-rights matrix. The title matters less than whether that person can stop a release.
Back to the Measure
Two numbers decide whether the program is real: how long a compliant product takes to reach market, and how long a reachable vulnerability stays open in the field.
Every artifact described above — the gates, the joined risk registers, the CI-generated SBOM, the disposition tree, the unified control set — exists to move one of those two numbers. Anything in the program that moves neither is overhead, and in a regulated manufacturer overhead is not neutral: it consumes the credibility the program needs on the day it asks engineering to stop a release.