Page 1 of 4

FDA Cybersecurity Compliance Self-Assessment ✅

Evaluate Your Device Against SPDF Submission Requirements

🔐 SPDF: The Core of FDA Cybersecurity Expectations

SPDF stands for Secure Product Development Framework — a core concept introduced by the U.S. Food and Drug Administration (FDA) in its 2023 guidance on cybersecurity for medical devices. "A Secure Product Development Framework (SPDF) is a set of processes that help to reduce the number and severity of vulnerabilities in products throughout the device lifecycle.” SPDF is not a commercial framework or third-party standard. It’s an FDA-defined expectation for integrating cybersecurity into every stage of the software and system development lifecycle — from design and implementation to maintenance and decommissioning. This checklist is built around SPDF because it is the central organizing structure FDA uses to evaluate cybersecurity readiness. It covers Security Risk Management, Security Architecture, and Cybersecurity Testing — all required for compliance. ✅ A correctly implemented SPDF means you're meeting the FDA’s cybersecurity process expectations — but only if it includes every required activity and artifact.

📋 Checklist Structure

The following checklist is based on the three core components of the Secure Product Development Framework (SPDF) as defined in the FDA’s 2023 Cybersecurity Guidance: 1. Security Risk Management (RM) - Threat modeling - Cybersecurity risk assessment - Interoperability Considerations - Third-party components and SBOM - Unresolved anomaly assessment - TPLC security risk management

2. Security Architecture (SA) - Implementation of required security controls (e.g., auth, crypto, logging) - Architecture views (Global, Multi-Patient Harm, Updateability, Use-Case)

3. Cybersecurity Testing (CT) - Requirements verification - Threat mitigation testing - Vulnerability scanning and SCA - Penetration testing ⚠️ Note: While the checklist content aligns fully with the FDA’s structure, the order of execution has been adjusted to follow a more practical and logical implementation flow. This ensures better usability for engineering and regulatory teams while maintaining full compliance and traceability to FDA expectations.

✅ SECTION 1: SA - Architecture Views

Overview: The FDA requires four architecture views to demonstrate how cybersecurity is designed into the system. These diagrams establish context for threat modeling, risk analysis, and control selection. They must include explanatory text and reflect real-world use and deployment.

1.1 Global System View

Have you created a Global System View that shows all internal components, external systems, trust boundaries, and data flows — with a written narrative and version control?

1.1 Global System View

✅ Yes – A complete diagram exists with narrative explanation and is version-controlled.

⚠️ Partial – A diagram exists but lacks supporting documentation or is not tracked in version control.

❌ No – The Global System View has not been created or is missing key architectural elements.

1.2 Multi-Patient Harm View

Have you documented how your system prevents cascading impact across multiple patients using a Multi-Patient Harm View diagram and supporting explanation?

1.2 Multi-Patient Harm View

✅ Yes – Diagram and documentation clearly show how multi-patient harm is mitigated.

⚠️ Partial – Diagram or written explanation exists, but is incomplete or unlinked.

❌ No – Multi-Patient Harm View not created or not contextualized for real-world use.

1.3 Updateability/Patchability View

Have you modeled how updates are securely delivered, authenticated, and applied — with visual diagrams and narrative stored in version control?

1.3 Updateability/Patchability View

✅ Yes – Architecture for update delivery and patch validation is fully documented.

⚠️ Partial – Some update process documentation exists but lacks clarity or completeness.

❌ No – Updateability architecture not yet documented

1.4 Security Use Case Views

Have you created views that illustrate how key security objectives (e.g., authentication, confidentiality) are implemented across critical workflows — and included them in your design documentation?

1.4 Security Use Case Views

✅ Yes – Security Use Case Views are defined and tied to core workflows, with supporting rationale.

⚠️ Partial – One or two workflows covered, but coverage or documentation is lacking.

❌ No – Security-specific architecture views have not been developed.

1.5 Version Control and Traceability

Are all architecture views version-controlled and traceable to your threat model and control documentation (e.g., risk table, SRTM, or control matrix)?

1.5 Version Control and Traceability

✅ Yes – All diagrams are version-controlled and linked to related security evidence.

⚠️ Partial – Stored in version control but not cross-referenced to threat model or controls.

❌ No – Diagrams are static or unmanaged; no integration with risk/control artifacts.

🛡️ SECTION 2. RM - Threat Modeling

Overview: Threat modeling is the foundation of FDA’s cybersecurity risk management process. It enables identification of threats, attack vectors, and system vulnerabilities based on your actual architecture and use context. FDA expects manufacturers to document and maintain threat models throughout the product lifecycle, using them to inform risk assessment, control selection, and testing strategies.

2.1 Use of Architecture Views

Have you used your architecture views (Global System, Use Case, etc.) to identify data flows, assets, boundaries, and workflows for threat modeling?

2.1 Use of Architecture Views

✅ Yes – Threat model clearly maps to all relevant architecture views and reflects real-world system use.

⚠️ Partial – Architecture views are referenced, but only loosely connected to threat modeling.

❌ No – Threat model is disconnected from system architecture

2.2 Threat Modeling Methodology

Have you selected and applied a structured threat modeling methodology (e.g., STRIDE, LINDDUN, or similar) to guide analysis?

2.2 Threat Modeling Methodology

✅ Yes – A recognized methodology is consistently used and documented.

⚠️ Partial – Methodology is mentioned or partially applied, but inconsistently.

❌ No – No formal method was used to identify threats.

2.3 Asset & Workflow Definition

Have you defined key system assets (e.g., credentials, patient data, update mechanisms) and workflows (e.g., login, OTA updates) as part of the threat model?

2.3 Asset & Workflow Definition

✅ Yes – All critical assets and workflows are documented and evaluated.

⚠️ Partial – Some assets or workflows are included, but others are missing.

❌ No – Assets and workflows are not explicitly modeled.

2.4 Attack Surfaces & Entry Points

Have you enumerated threats against system assets and workflows — including entry points, trust boundaries, and potential attack surfaces — and evaluated their impact, likelihood, preconditions, and mitigation strategies?

2.4 Attack Surfaces & Entry Points

✅ Yes – All threats are documented with reference to attack surfaces, boundaries, and preconditions, along with planned mitigations.

⚠️ Partial – Some threat evaluation exists, but critical system exposure areas or analysis steps are missing.

❌ No – Threats have not been formally identified, evaluated, or mitigated.

2.5 Threat Enumeration & Evaluation

Have you identified and evaluated specific threats tied to workflows, assets, or interfaces (including impact, likelihood, and assumptions)?

2.5 Threat Enumeration & Evaluation

✅ Yes – Detailed threat tables or matrices exist and include mitigation plans

⚠️ Partial – Some threats documented, but evaluation is inconsistent or incomplete

❌ No – No formal enumeration or analysis

2.6 Assumptions, Roles & Constraints

Have you recorded key threat modeling assumptions, attacker roles (e.g., internal, external), and known system constraints that influence threat exposure?

2.6 Assumptions, Roles & Constraints

✅ Yes – All assumptions and constraints are documented and justified.

⚠️ Partial – Some factors are noted informally or scattered across documents.

❌ No – Not documented

2.7 Third-Party Coverage

Does your threat model include third-party software, APIs, libraries, and external interfaces (e.g., BLE, REST, HL7-FHIR)?

2.7 Third-Party Coverage

✅ Yes – Third-party and interoperable elements are fully modeled and threat-assessed.

⚠️ Partial – Some third-party elements are addressed, but coverage is incomplete.

❌ No – Third-party risks are not part of the threat model.

2.8 Version Control & Maintenance

Is your threat model stored in version control, regularly updated, and linked to risk assessments and control decisions?

2.8 Version Control & Maintenance

✅ Yes – Threat model is under change control and tied to related artifacts.

⚠️ Partial – Stored in version control but updates are ad hoc or not traceable.

❌ No – Threat model is not maintained or version-controlled.

🧮 SECTION 3. RM: Cybersecurity Risk Assessment & Interoperability

Overview: Risk assessment transforms your threat model into a prioritized, traceable analysis of cybersecurity risk. The FDA expects you to evaluate each threat based on likelihood, impact and residual risk, and to demonstrate how existing or proposed mitigations reduce exposure. This process must be documented and maintained across the Total Product Lifecycle (TPLC), especially in interoperable, cloud or multi-component systems.

3.1 Threat Impact & Likelihood Evaluation

Have you evaluated each identified threat for potential impact, likelihood of exploitation, and preconditions — and documented the rationale behind risk scoring?

3.1 Threat Impact & Likelihood Evaluation

✅ Yes – Impact, likelihood, preconditions, and risk rationale are clearly documented for each threat.

⚠️ Partial – Some threats are evaluated, but scoring rationale is inconsistent or incomplete.

❌ No – Threats have not been formally evaluated or scored.

3.2 Interoperability Risk Identification

Have you flagged threats arising from interoperable components (e.g., HL7-FHIR, REST APIs, BLE, cloud endpoints) and documented untrusted connections?

3.2 Interoperability Risk Identification

✅ Yes – All relevant interfaces are evaluated in the risk model and tagged as interoperability risks.

⚠️ Partial – Interfaces are listed but not formally assessed or tied to threats.

❌ No – Interoperability risks are not included in the threat assessment.

3.3 Mitigation Documentation

Have you documented existing mitigations or controls for each threat and described how they reduce risk?

3.3 Mitigation Documentation

✅ Yes – Each threat includes a mapped mitigation strategy or control, described in the documentation.

⚠️ Partial – Some threats include mitigations, but documentation is incomplete or ad hoc.

❌ No – Mitigations have not been systematically recorded.

3.4 Residual Risk Evaluation

Have you evaluated and recorded the residual risk for each threat — classifying it as acceptable, unacceptable, or requiring further mitigation?

3.4 Residual Risk Evaluation

✅ Yes – Each threat has a documented residual risk classification, with supporting rationale.

⚠️ Partial – Some classifications are made, but reasoning is unclear or inconsistently applied.

❌ No – Residual risk has not been assessed or documented.

3.5 Security Risk Table Documentation

Have you created a structured Security Risk Table (or SRTM) that includes threat ID, affected components, impact, likelihood, risk score, mitigation, and residual risk — with interoperability tags where applicable?

3.5 Security Risk Table Documentation

✅ Yes – Full risk table or matrix exists with complete, tagged data for each threat.

⚠️ Partial – Risk table exists but lacks required fields or tagging.

❌ No – No formal Security Risk Table or traceable risk log has been developed.

3.6 Traceability and Testing Controls

Have you linked threats and mitigations to test plans, verification procedures, or security controls to support validation?

3.6 Traceability and Testing Controls

✅ Yes – Each risk and mitigation is mapped to test cases or control references in a traceable way.

⚠️ Partial – Some test/control links exist but are not comprehensive or clearly traceable.

❌ No – No documented links to validation testing or control implementation.

🧾 SECTION 4. SA: Implementation of Required Security Controls

Overview: This section addresses the implementation of specific cybersecurity controls that mitigate threats identified during risk analysis. FDA expects manufacturers to demonstrate that security is built into the product through appropriate, risk-based selection and application of controls. These should align with the five security objectives and cover areas such as authentication, cryptography, logging, integrity, resiliency, and updateability. Controls must be mapped to the threat model, clearly documented, tested, and justified.

4.1 Threat-to-Control Mapping

Have you reviewed your threat model and risk table to identify which threats require mitigation via technical controls — and mapped them accordingly?

4.1 Threat-to-Control Mapping

✅ Yes – All threats requiring mitigation are clearly mapped to selected security controls.

⚠️ Partial – Mapping exists but is incomplete or informal.

❌ No – Control selection is not driven by risk analysis

4.2 Control Selection Based on FDA Guidance

Have you selected security controls aligned with FDA Appendix 1 and relevant frameworks (e.g., OWASP ASVS, NIST 800-53, IEC standards), covering areas like authentication, authorization, cryptography, logging, integrity, resiliency, and updateability?

4.2 Control Selection Based on FDA Guidance

✅ Yes – Control selection follows FDA and industry-standard guidance and addresses all key control categories.

⚠️ Partial – Some control categories are covered, but mapping to guidance is incomplete.

❌ No – Control selection lacks alignment with FDA expectations or known frameworks.

4.3 Documentation of Threat–Control–Component–Test Mapping

Have you documented how each control maps to a specific threat, system component or workflow, and corresponding test case — in a traceable format like a control matrix or requirements table?

4.3 Documentation of Threat–Control–Component–Test Mapping

✅ Yes – All controls are fully traceable across threats, components, and tests.

⚠️ Partial – Mapping exists but lacks consistency or full traceability.

❌ No – No structured mapping between controls, threats, and validations exists.

4.4 Residual Risk and Compensating Controls

Have you identified threats that remain unmitigated and documented compensating controls or rationale for accepting residual risk?

4.4 Residual Risk and Compensating Controls

✅ Yes – Residual risks are clearly recorded and either justified or addressed with alternate controls.

⚠️ Partial – Some residual risks noted, but compensating controls or rationale is missing.

❌ No – Residual risk is not assessed or documented.

4.5 Assumptions and Design Constraints

Have you documented assumptions and constraints (e.g., platform limits, legacy dependencies) that affect security control selection or implementation?

4.5 Assumptions and Design Constraints

✅ Yes – All key limitations and their impact on control design are clearly explained.

⚠️ Partial – Some constraints are noted but not formally linked to control decisions.

❌ No – No design limitations or trade-offs have been recorded.

4.6 Architecture Diagram Integration

Have you updated your architecture diagrams to reflect security control placement (e.g., auth flows, encryption paths, isolation zones), and ensured consistency with implementation?

4.6 Architecture Diagram Integration

✅ Yes – Architecture diagrams clearly show control locations and are version-controlled.

⚠️ Partial – Controls appear in documentation but are not reflected in architecture views.

❌ No – Controls are not visually integrated into system architecture.

4.7 Control Traceability Format

Have you stored control decisions in a structured and version-controlled format such as a Security Requirements Traceability Matrix (SRTM), Control Mapping Sheet, or equivalent — with links to risks, components, and validations?

4.7 Control Traceability Format

✅ Yes – All control decisions are formally documented and linked in a traceability artifact.

⚠️ Partial – Some control information is recorded, but not in a centralized or structured format.

❌ No – Control rationale and traceability are undocumented or fragmented.

🧾 SECTION 5. CM: SBOM & Supply Chain Transparency

Overview: The FDA now expects device manufacturers to provide a Software Bill of Materials (SBOM) detailing all third-party, open-source, and proprietary components. This includes their version, supplier, known vulnerabilities, and support status. A complete SBOM is foundational for identifying inherited risks, evaluating software provenance, and responding to vulnerabilities throughout the device lifecycle. It must be machine-readable, maintained over time, and linked to testing, patching, and disclosure processes.

5.1 SBOM Coverage

Do you generate a complete Software Bill of Materials (SBOM) that includes all third-party components — including name, version, supplier, hash, license, download URL, and end-of-support date (if available)?

5.1 SBOM Coverage

✅ Yes — we maintain a full SBOM with all metadata for each release.

⚠️ Partially — we list some components but lack key details or only update it occasionally.

❌ No — we don’t generate an SBOM.

5.2 SBOM Format

Do you generate the SBOM in a standardized format such as SPDX, CycloneDX, or SWID?

5.2 SBOM Format

✅ Yes — we use one of these formats and version-control each SBOM.

⚠️ Partially — we generate SBOMs but they are in non-machine-readable formats (e.g. Excel, PDF).

❌ No — our SBOMs are not machine-readable.

5.3 SBOM Automation

Do you the SBOM as part of your , for every release?

5.3 SBOM Automation

✅ Yes — the SBOM is generated automatically with each CI/CD build.

⚠️ Partially — SBOMs are created manually or only for major versions.

❌ No — we do not automate SBOM generation.

5.4 Vulnerability Tracking

Do you track known vulnerabilities in third-party components using a software composition analysis (SCA) tool or CVE/NVD feeds?

5.4 Vulnerability Tracking

✅ Yes — we actively track vulnerabilities (e.g. CVEs) using a tool or data feed and respond to critical issues.

⚠️ Partially — we are aware of some vulnerabilities but don’t track them systematically.

❌ No — we don’t monitor vulnerabilities in third-party software.

5.5 High-Risk Component Logging

Do you tag and track third-party components with HIGH/Critical vulnerabilities or End-of-Life (EOL) status in a vulnerability log?

5.5 High-Risk Component Logging

✅ Yes — we maintain a log for these components and monitor them for remediation or replacement.

⚠️ Partially — we log some risks, but it’s inconsistent or incomplete.⚠️ Partial – Basic supplier info is known, but no formal evaluation

❌ No — we don’t track or tag these components.

5.6 Risk Model Integration

Are third-party risks explicitly integrated into your Threat Model and Security Risk Table?

5.6 Risk Model Integration

✅ Yes — we include third-party risks as a defined threat source in both.

⚠️ Partially — some risks are included, but it’s not systematic.

❌ No — third-party risks are not documented in our models.

5.7 Control Traceability Format

✅ Yes — we use an SRTM or equivalent, with traceable links across all decision points.

⚠️ Partially — we document controls, but they’re not version-controlled or traceable.

❌ No — we don’t maintain a structured control traceability format.

🧪 SECTION 6: Cybersecurity Testing (PT)

Overview: The FDA expects manufacturers to provide structured evidence that implemented security controls mitigate known threats and vulnerabilities. This includes verifying control behavior, testing threat mitigations, scanning for known issues (e.g., CVEs), and conducting independent penetration testing. All activities must be traceable to your security requirements, threat model, and architecture — and collectively support your residual risk justification and premarket submission.

6.1 Requirements Verification Coverage

Do you verify that each implemented control fulfills its associated security requirement (e.g., authentication, encryption, update flow), and document the result?

6.1 Requirements Verification Coverage

✅ Yes — we verify each control’s behavior against defined security requirements and log results, including partial or failed outcomes.

⚠️ Partially — we test some controls, but not systematically or with traceable logs.

❌ No — we do not systematically verify or document control effectiveness.

6.2 SRTM Usage

Do you use a Security Requirements Traceability Matrix (SRTM) to track coverage of your implemented security controls?

6.2 SRTM Usage

✅ Yes — we maintain a complete, version-controlled SRTM linking requirements to controls and their test outcomes.

⚠️ Partially — we maintain a basic or outdated matrix without full traceability.

❌ No — we don’t use an SRTM.

6.3 Threat Scenario Testing

Do you simulate attack scenarios from your threat model to test the effectiveness of your mitigations?

6.3 Threat Scenario Testing

✅ Yes — we test both common and edge-case attack paths using adversarial inputs and record results in a structured format.

⚠️ Partially — we test a subset of scenarios but not comprehensively or with full documentation.

❌ No — we don’t simulate threat scenarios.

6.4 Residual Risk Logging

Do you log failed or partially satisfied controls along with an assessment of their residual risk?

6.4 Residual Risk Logging

✅ Yes — we track control failures and document residual risks in the Security Risk Table.

⚠️ Partially — we log failures, but don’t evaluate or update downstream risk artifacts.

❌ No — we don’t maintain this information.

6.5 Static Code Analysis

Do you perform Static Application Security Testing (SAST) to detect insecure code patterns and logic flaws?

6.5 Static Code Analysis

✅ Yes — we routinely perform SAST and retain reports as part of our automated test process.

⚠️ Partially — we run SAST occasionally or on select components.

❌ No — we don’t use SAST tools.

6.6 Dynamic or Fuzz Testing

Do you perform Dynamic Application Security Testing (DAST) or fuzzing on exposed interfaces such as APIs, USB, or BLE?

6.6 Dynamic or Fuzz Testing

✅ Yes — we run automated DAST and fuzz testing, and include these reports in our testing artifacts.

⚠️ Partially — we have run such tests before, but they are not routine or fully documented.

❌ No — third-party risks are not documented in our models.

6.7 Software Composition Analysis (SCA)

Do you use your SBOM in conjunction with SCA tools to identify vulnerabilities in third-party components?

6.7 Software Composition Analysis (SCA)

✅ Yes — we scan SBOM components for CVEs using an SCA tool and triage based on severity, exploitability, and context.

⚠️ Partially — we scan components but don’t consistently track or act on findings.

❌ No — we don’t use SCA tooling.

6.8 Penetration Test Scope

Do you define a structured scope and methodology for your penetration tests, tied to your system architecture and threat model?

6.8 Penetration Test Scope

✅ Yes — we maintain a formal pentest plan that includes scope, threat model, and test methodology (white-, gray-, or black-box).

⚠️ Partially — we perform pentests but without defined scope or documentation.

❌ No — we do not plan or structure pentests formally.

6.9 Independent Testing

Are penetration tests conducted by an independent team, separated from the development team?

6.9 Independent Testing

✅ Yes — pentests are run by a qualified third party or an internal team with clear separation and impartiality.

⚠️ Partially — tests are performed internally with limited independence.

❌ No — tests are not independent of development.

6.10 Multi-Step Exploit Simulation

Do your pentests include multi-step or chained attack scenarios (e.g., chaining auth bypass into privilege escalation)?

6.10 Multi-Step Exploit Simulation

✅ Yes — we include complex exploit chains and document them in our test results.

⚠️ Partially — we test individual vulnerabilities, but not full attack paths.

❌ No — we do not simulate multi-step exploits.

🧮 SECTION 7: Security Assessment of Unresolved Anomalies (RM)

Overview: The FDA requires manufacturers to document and assess any unresolved anomalies — security-relevant test failures, incomplete mitigations, or unpatched vulnerabilities — that persist after design and testing. Each anomaly must be evaluated for its potential impact, linked to the threat model and risk table, and accompanied by a clear rationale if it remains unmitigated. This is critical to ensuring residual risks are transparent, justified, and traceable, especially for premarket review.

7.1 Logging of Unresolved Anomalies

Do you maintain a structured log of unresolved anomalies, including failed, skipped, or partially successful security tests?

7.1 Logging of Unresolved Anomalies

✅ Yes — we maintain a centralized Unresolved Anomaly Log that captures all test failures and exceptions in a structured format.

⚠️ Partially — we record some anomalies, but the log is informal or lacks standard fields.

❌ No — we don’t maintain a dedicated or structured anomaly log.

7.2 Anomaly Metadata and Disposition

For each unresolved anomaly, do you document its description, affected component, severity, and whether it was mitigated, accepted as residual risk, or deferred?

7.2 Anomaly Metadata and Disposition

✅ Yes — each entry includes full metadata and final disposition (mitigated, accepted, or deferred), as well as linkage to the relevant component.

⚠️ Partially — we include some of this information, but documentation is incomplete or inconsistently applied.

❌ No — we don’t systematically record this level of detail.

7.3 Risk Table Integration

Do you update your Security Risk Table to reflect unresolved anomalies and include associated residual risk justifications?

7.3 Risk Table Integration

✅ Yes — we evaluate unresolved anomalies and update the Security Risk Table with the impact, justification, and traceability to affected controls.

⚠️ Partially — only high-severity anomalies are reflected, or entries lack sufficient rationale.

❌ No — we don’t simulate threat scenarios.

7.4 Justification for Non-Remediation

Do you provide clear, written justifications for not fixing specific security issues, such as compensating controls, low-risk categorization, or remediation infeasibility?

7.4 Justification for Non-Remediation

✅ Yes — all unresolved issues include documented rationale that explains why remediation wasn’t pursued, including compensating safeguards or clinical risk considerations.

⚠️ Partially — we justify some issues, but documentation is incomplete or lacks clarity.

❌ No — we do not formally justify or track decisions not to fix security findings.

🔄 SECTION 8: TPLC Security Risk Management (RM)

Overview: Cybersecurity is not a one-time effort. FDA expects manufacturers to maintain an active security risk management process across the entire product lifecycle, including postmarket monitoring, vulnerability triage, patching, documentation updates, and threat model revisions. This ensures the device remains secure as threats evolve and new vulnerabilities emerge. The TPLC process should be structured, measurable, and traceable, and aligned with both premarket plans and postmarket expectations.

8.1 Vulnerability Triage

Do you triage newly discovered vulnerabilities within defined SLAs and log metadata such as source, affected components, CVSS score, and response action?

8.1 Vulnerability Triage

✅ Yes — we triage vulnerabilities within SLA (e.g., CVSS ≥ 7 triaged in ≤ 7 days) and log full context for each case, including source, severity, affected components, and resolution decision.

⚠️ Partially — we track some vulnerabilities but don’t consistently meet SLAs or capture complete structured metadata.

❌ No — we don’t have a defined triage or tracking process.

8.2 Patch Deployment and SLA Tracking

Do you have a defined patching process with SLAs and infrastructure to deliver, track, and confirm security updates?

8.2 Patch Deployment and SLA Tracking

✅ Yes — we maintain a patch deployment log with SLA enforcement, track each patch through planning → release → confirmation, and deliver updates through a secure infrastructure.

⚠️ Partially — we deploy patches, but don’t track timing or verify delivery systematically.

❌ No — we don’t use an SRTM.

8.3 Threat Model and Risk Register Maintenance

Do you update your threat model and security risk register after major changes such as new releases, vulnerability disclosures, or architectural updates?

8.3 Threat Model and Risk Register Maintenance

✅ Yes — we revisit and version these documents quarterly and after key changes, including reassessment of previously accepted risks.

⚠️ Partially — updates occur occasionally but not in a structured or traceable way.

❌ No — we don’t simulate threat scenarios.

8.4 Security Metrics and SPDF Review

Do you collect metrics such as time-to-patch, time-to-deploy, or % of vulnerabilities patched on time, and use them to improve your SPDF security processes?

8.4 Security Metrics and SPDF Review

✅ Yes — we track key metrics like time-to-patch and time-to-deploy, and review our TPLC and SPDF performance regularly to identify and address process gaps.

⚠️ Partially — we collect some metrics, but don’t use them consistently to improve our security program.

❌ No — we don’t track performance metrics or conduct regular process reviews.

8.5 Coordinated Vulnerability Disclosure

Do you operate a Coordinated Vulnerability Disclosure (CVD) process with public intake and a defined triage/response workflow?

8.5 Coordinated Vulnerability Disclosure

✅ Yes — we have a documented CVD policy, a public contact, and a defined intake, triage, and remediation process aligned with ISO 30111 or equivalent.

⚠️ Partially — we handle disclosures informally but lack a published policy or structured workflow.

❌ No — we don’t have a formal process for receiving or managing external vulnerability reports.