# Q3 2026 Quarterly Spot-Check — IEC 81001-5-1 + FDA Cybersecurity (issue #2620)

Real requirement-vs-source comparison performed 2026-08-12 for the public Q3 2026 review-log entry.

## Progress

- [x] 12 sampled rows (12/12)

## Summary

| Atom | Verdict | Severity |
|---|---|---|
| REQ-IEC81001-4.1.1 | clean | — |
| REQ-IEC81001-4.1.7 | clean | — |
| REQ-IEC81001-5.1.3 | finding | low |
| REQ-IEC81001-5.3.3 | clean | — |
| REQ-IEC81001-5.7.1 | clean | — |
| REQ-IEC81001-5.8.1 | clean | — |
| REQ-IEC81001-6.2.2 | finding | high |
| REQ-IEC81001-7.5 | clean | — |
| REQ-FDACYBER-ANOMALIES | finding | medium |
| REQ-FDACYBER-CVD | finding | critical |
| REQ-FDACYBER-PATCH | finding | medium |
| REQ-FDACYBER-VULN | finding | medium |
| **Total** | **12 audited** | **critical:1, high:1, medium:3, low:1** |

## Methodology

- **IEC 81001-5-1:2021** — stored PDF (Tier C), resolved via `scripts/standards/standards-corpus get iec-81001-5-1-2021` → `/home/todd/.local/share/kelsey/standards/standards/iec-81001-5-1-2021.pdf`. Read via `Read` tool, `pages` param, on 2026-08-12. Clauses 4.1.1, 4.1.2, 4.1.7, 5.1.3, 5.3.3, 5.5.1, 5.7.1, 5.8.1, 5.8.5, 5.8.6, 6.1.1, 6.2.2, 7.5 all located and read directly from the PDF (pages 20–34, PDF page index confirmed to match each atom's `source_grounding.page`).
- **FDA Cybersecurity Guidance (Feb 3, 2026, current edition)** — `scripts/standards/standards-corpus fetch fda-cybersecurity-guidance-2026-02` returned `Error: not a live-source entry (source=pdf)`, confirming this entry is Tier B/stored-PDF only (no live source configured). Used `scripts/standards/standards-corpus get fda-cybersecurity-guidance-2026-02` → `/home/todd/.local/share/kelsey/standards/standards/fda-cybersecurity-guidance-2026-02.pdf`. Read via `Read` tool on 2026-08-12: title page/TOC (pp. 2–4), pp. 21–23 (V.A.4/V.A.5/V.A.6), pp. 30–37 (VI.B, VII.A–C.1), pp. 38–40 (VII.C.2, VII.C.3, VII.D), pp. 49–50 (Appendix 1.G/H). All roman-numeral section refs cited in the sample (V.A.5, V.A.6, VI.B, VII.C.1, VII.C.2, VII.D, Appendix 1.H) were located in the TOC (pp. 2–4 image) and confirmed to carry the titles the atoms' `authoritative_titles` claim, and their body content was read directly.
- Cross-referenced regimes appearing in the sample (`21-cfr-820-qsr` §820.90 "Nonconforming product", §820.198 "Complaint files"; `iec-62304-2015` §6.2 "Problem and modification analysis"; `iso-13485-2016` §4.1/§7.2.3; `iso-14971-2019` §10) were **not independently re-fetched this session** — they are secondary crosswalk pointers in `regime_keys`/`authoritative_titles`, not asserted as current binding obligations inside any sampled `requirement_text`, so per the task brief ("only report it if the page presents it as a current obligation") they were out of scope for a live check. None of the sampled atoms present a `21-cfr-820-qsr` clause as a current obligation in `requirement_text` — all sunset refs are confined to the crosswalk metadata only. Noting this as a methodology gap, not a finding.
- No row was marked `unverified` — every cited primary-regime clause (IEC 81001-5-1 or FDA cybersecurity guidance) was located and read this session.

## Findings

### REQ-IEC81001-5.1.3 — "Secure Coding Standards Planning"

- **Drift type:** invented-specificity
- **Severity:** low
- **Standard clause / source:** IEC 81001-5-1:2021 §5.1.3 "Secure coding standards"
- **Source quote (verbatim from PDF):**
  > "The MANUFACTURER shall establish and maintain secure coding standards consistent with current best practices related to the design and implementation of secure software systems.
  >
  > See Annex A."
- **Committed text (verbatim from repo):**
  > "The manufacturer shall establish and maintain secure coding standards consistent with current best practices related to the design and implementation of secure software systems. See Annex A.4."
- **Location:** `apps/compliance/data/iec81001-atoms.json`, atom `REQ-IEC81001-5.1.3`, field `requirement_text`
- **PDF page:** iec-81001-5-1-2021.pdf, page 23 (printed page 21)
- **Recommended revision:**
  > Change "See Annex A.4." to "See Annex A." — clause 5.1.3 itself only cross-references the whole of Annex A. The "See clause A.4" pointer belongs to a *different* clause, §5.5.1 ("Secure coding standards" under Software unit implementation and verification, page 24/printed 22: "The MANUFACTURER shall establish an implementation ACTIVITY (or ACTIVITIES) following secure coding standards. See clause A.4."), not §5.1.3.
- **Notes:** Low practical impact (both point into the same informative Annex A), but the specific subclause number is not what §5.1.3 says — it is borrowed from §5.5.1's parallel clause.

### REQ-IEC81001-6.2.2 — "Security Update Verification"

- **Drift type:** scope-broadening
- **Severity:** high
- **Standard clause / source:** IEC 81001-5-1:2021 §6.2.2 "SECURITY update VERIFICATION"
- **Source quote (verbatim from PDF):**
  > "The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for verifying that SECURITY updates created by the MANUFACTURER address the intended SECURITY VULNERABILITIES.
  >
  > The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for verifying that SECURITY updates do not introduce unintended effects to functional or quality attributes of HEALTH SOFTWARE. Such SECURITY updates include but are not limited to updates created by:
  > a) the HEALTH SOFTWARE MANUFACTURER,
  > b) suppliers of SOFTWARE ITEMS used in the HEALTH SOFTWARE, and
  > c) suppliers of SOFTWARE ITEMS or platforms on which the HEALTH SOFTWARE depends."
- **Committed text (verbatim from repo):**
  > "Verify that security updates address the intended security vulnerabilities. Verify that security updates do not introduce unintended effects to functional or quality attributes. This applies to updates from the health software manufacturer, suppliers of software items, and suppliers of platforms."
- **Location:** `apps/compliance/data/iec81001-atoms.json`, atom `REQ-IEC81001-6.2.2`, field `requirement_text`
- **PDF page:** iec-81001-5-1-2021.pdf, page 30 (printed page 28)
- **Recommended revision:**
  > "Verify that security updates created by the manufacturer address the intended security vulnerabilities. Verify that security updates — including those created by the manufacturer, suppliers of software items, and suppliers of platforms — do not introduce unintended effects to functional or quality attributes."
- **Notes:** The clause splits two distinct verification duties with two different scopes: verifying a fix *addresses the intended vulnerability* is scoped **only to manufacturer-created updates**; verifying an update *doesn't break other things* is scoped to manufacturer + software-item suppliers + platform suppliers. The committed text merges both sentences and attaches the three-party "applies to" list to *both* duties, extending "verify the fix addresses the intended vulnerability" to supplier- and platform-created updates as well — an obligation §6.2.2 does not place on the manufacturer.

### REQ-FDACYBER-ANOMALIES — "Security Assessment of Unresolved Software Anomalies"

- **Drift type:** conflation
- **Severity:** medium
- **Standard clause / source:** FDA Cybersecurity Guidance (Feb 3, 2026) §V.A.5 "Security Assessment of Unresolved Anomalies"
- **Source quote (verbatim from PDF):**
  > "FDA's Premarket Software Guidance recommends that device manufacturers provide a list of software anomalies that exist in a product at the time of submission. For each anomaly, FDA recommends that device manufacturers conduct an evaluation of the anomaly's impact on the device's safety and effectiveness, and consult the Premarket Software Guidance to assess the associated documentation recommended for inclusion in such device's premarket submission.
  >
  > Some anomalies discovered during development or testing may have security implications and may also be considered vulnerabilities. As a part of ensuring a complete security risk assessment under Subclause 7.1 of ISO 13485, the assessment for impacts to safety and effectiveness may include an assessment for the potential security impacts of anomalies. The assessment should also include consideration of any present Common Weakness Enumeration (CWE) categories."
- **Committed text (verbatim from repo):**
  > "FDA's Premarket Cybersecurity Guidance (current edition February 3, 2026) recommends that for each software anomaly that exists in a product at the time of premarket submission, device manufacturers conduct an evaluation of the anomaly's impact on device safety and effectiveness, including an assessment of the potential security impacts of anomalies."
- **Location:** `apps/compliance/data/cybersecurity-atoms.json`, atom `REQ-FDACYBER-ANOMALIES`, field `requirement_text` (same conflation repeats in `atomic_constraints[0]`, out of primary scope but noted for context)
- **PDF page:** fda-cybersecurity-guidance-2026-02.pdf, page 22 (printed page 18)
- **Recommended revision:**
  > "FDA's Premarket Software Guidance recommends that device manufacturers evaluate each software anomaly present at the time of premarket submission for its impact on device safety and effectiveness. FDA's Premarket Cybersecurity Guidance (current edition February 3, 2026) §V.A.5 recommends that this assessment also include the anomaly's potential security impacts, including consideration of any present Common Weakness Enumeration (CWE) categories."
- **Notes:** The atom's cited source (`fda-cybersecurity-guidance-2026-02`, §V.A.5) is not actually the origin of the "conduct an evaluation of the anomaly's impact on safety and effectiveness" recommendation — the guidance text itself attributes that to a different, uncited document ("FDA's Premarket Software Guidance"). §V.A.5's own contribution is that the safety/effectiveness assessment "may include" (permissive) a security-impact component plus CWE consideration — softer language than the committed text's "recommends... conduct an evaluation... including." No obligation-level inversion (both are non-binding "recommends"/"may"), hence medium rather than high/critical.

### REQ-FDACYBER-CVD — "Coordinated Vulnerability Disclosure"

- **Drift type:** obligation-level
- **Severity:** critical
- **Standard clause / source:** FDA Cybersecurity Guidance (Feb 3, 2026) §VII.C.1 "Plans and Procedures (Section 524B(b)(1))" — this is one of the atom's own cited `regime_keys`
- **Source quote (verbatim from PDF):**
  > "Section 524B(b)(1) of the FD&C Act requires manufacturers of cyber devices to submit to FDA "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures" in their premarket submissions. We recommend that the plan contain the information recommended for the Cybersecurity Management Plan described in Section VI.B. In particular, such a plan should address the items discussed below.
  >
  > First, FDA considers that coordinated vulnerability disclosure (CVD) and related procedures, as required in section 524B(b)(1) of the FD&C Act, could include: ..."
- **Committed text (verbatim from repo):**
  > "FDA's Premarket Cybersecurity Guidance recommends that the manufacturer establish and publish a coordinated vulnerability disclosure (CVD) policy that provides a mechanism for security researchers, customers, and other third parties to report potential vulnerabilities. The policy should define how reports are received, acknowledged, investigated, and how the manufacturer coordinates with reporters through remediation and public disclosure."
- **Location:** `apps/compliance/data/cybersecurity-atoms.json`, atom `REQ-FDACYBER-CVD`, field `requirement_text`
- **PDF page:** fda-cybersecurity-guidance-2026-02.pdf, page 36 (printed page 32)
- **Recommended revision:**
  > "Per §524B(b)(1) of the FD&C Act, manufacturers of cyber devices must submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure (CVD) and related procedures. FDA's Premarket Cybersecurity Guidance recommends that this CVD component take the form of a published policy providing a mechanism for security researchers, customers, and other third parties to report potential vulnerabilities, defining how reports are received, acknowledged, investigated, and coordinated with reporters through remediation and disclosure."
- **Notes:** For **cyber devices** (the class this atom's own `regime_keys` cite §VII.C.1/§VI.B for), having CVD-related procedures as part of the required postmarket plan is a **statutory requirement under §524B(b)(1)** — the guidance text quotes the statute verbatim, and the requirement text the sampled atom itself cites as its source confirms this. The committed `requirement_text` field frames the entire obligation as an FDA *guidance recommendation* ("recommends that the manufacturer establish and publish...") with no mention of the binding §524B(b)(1) plan requirement — the inverse of the drift the audit brief warns about (guidance stated as binding), but the same category of error: **an obligation is misstated relative to its binding status**, here understating a statutory element as discretionary guidance. Notably the sibling atoms `REQ-FDACYBER-PATCH` and `REQ-FDACYBER-VULN` in this same sample correctly separate the §524B statutory "shall/requires" language from the guidance "recommends" language — this atom's `why_this_exists` field (out of audit scope) also correctly attributes CVD to §524B(b)(1), so the drift is isolated to the customer-facing `requirement_text` field.

### REQ-FDACYBER-PATCH — "Patch and Update Management Plan"

- **Drift type:** omitted-conditional
- **Severity:** medium
- **Standard clause / source:** FDA Cybersecurity Guidance (Feb 3, 2026), §524B(b)(2)(A) of the FD&C Act as quoted at §VII.C.1
- **Source quote (verbatim from PDF):**
  > "Section 524B(b)(2)(A) of the FD&C Act requires manufacturers of cyber devices to make available updates and patches to the device and related systems for known unacceptable vulnerabilities, with these updates and patches made available on a reasonably justified regular cycle."
- **Committed text (verbatim from repo):**
  > "Per §524B(b)(2)(A) of the FD&C Act, manufacturers of cyber devices shall make available postmarket updates and patches on a reasonably justified regular cycle."
- **Location:** `apps/compliance/data/cybersecurity-atoms.json`, atom `REQ-FDACYBER-PATCH`, field `requirement_text`
- **PDF page:** fda-cybersecurity-guidance-2026-02.pdf, page 37 (printed page 33)
- **Recommended revision:**
  > "Per §524B(b)(2)(A) of the FD&C Act, manufacturers of cyber devices shall make available postmarket updates and patches for known unacceptable vulnerabilities on a reasonably justified regular cycle."
- **Notes:** The committed text drops the qualifier "for known unacceptable vulnerabilities," which is load-bearing in the statute's own structure — §524B(b)(2)(A)'s "reasonably justified regular cycle" applies specifically to *known unacceptable vulnerabilities*, distinct from §524B(b)(2)(B)'s separate, faster "as soon as possible out of cycle" obligation for *critical vulnerabilities that could cause uncontrolled risks*. Dropping the qualifier reads as a blanket regular-cycle patch obligation rather than one scoped to a specific vulnerability classification.

### REQ-FDACYBER-VULN — "Vulnerability Assessment and Management"

- **Drift type:** conflation
- **Severity:** medium
- **Standard clause / source:** FDA Cybersecurity Guidance (Feb 3, 2026) §V.A.6 "TPLC Security Risk Management" (cited in `regime_keys`); the claimed content is actually §V.A.4 "Third-Party Software Components" (not cited)
- **Source quote — §V.A.6, verbatim from PDF (what IS cited):**
  > "Cybersecurity risks may continue to be identified throughout the device's TPLC. Manufacturers should ensure they have appropriate resources to identify, assess, and mitigate cybersecurity vulnerabilities as they are identified throughout the supported device lifecycle."
- **Source quote — §V.A.4, verbatim from PDF (what the claim actually describes, not cited in `regime_keys`):**
  > "As part of the premarket submission, manufacturers should also identify all known vulnerabilities associated with the device and the software components, including those identified in CISA's Known Exploited Vulnerabilities Catalog. For each known vulnerability, manufacturers should describe how the vulnerabilities were discovered to demonstrate whether the assessment methods were sufficiently robust. For components with known vulnerabilities, device manufacturers should provide in premarket submissions: A safety and security risk assessment of each known vulnerability (including device and system impacts); and ..."
- **Committed text (verbatim from repo):**
  > "FDA's Premarket Cybersecurity Guidance recommends that the manufacturer perform vulnerability assessment of all software components identified in the SBOM and establish a process for ongoing vulnerability management."
- **Location:** `apps/compliance/data/cybersecurity-atoms.json`, atom `REQ-FDACYBER-VULN`, field `requirement_text`
- **PDF page:** §V.A.6 on fda-cybersecurity-guidance-2026-02.pdf page 22 (printed 18); §V.A.4 SBOM-vulnerability content on page 21 (printed 17)
- **Recommended revision:**
  > "FDA's Premarket Cybersecurity Guidance §V.A.4 recommends that the manufacturer identify all known vulnerabilities associated with the device's software components (including those in the SBOM) and provide a safety and security risk assessment for each in the premarket submission; §V.A.6 recommends the manufacturer maintain a process to identify, assess, and mitigate vulnerabilities on an ongoing basis throughout the device's total product life cycle."
- **Notes:** The "perform vulnerability assessment of all software components identified in the SBOM" claim is §V.A.4 content (uncited in this atom's `regime_keys`), not §V.A.6 (the clause actually cited). §V.A.6's own text is about maintaining and updating risk-management documentation across the device lifecycle — it supports the atom's second clause ("establish a process for ongoing vulnerability management") reasonably well, but not the SBOM-specific per-component assessment claim in the first clause. The atom's own `source_grounding.excerpt` ("Sources, methods, and frequency for monitoring and identifying vulnerabilities") is drawn from a third section, §VI.B (page 34), reinforcing that the requirement text blends content from three different sections without citing the one (§V.A.4) that actually supports its central claim.

## Count

12 audited, 6 clean, 6 findings, 0 unverified.