Breaking news! The FDA just released new guidance on the refusal to accept (RTA) policy for cybersecurity devices.
Where can I find the new cybersecurity devices guidance?
The new guidance is titled “Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act,” and you can download a copy of the PDF directly from our website. This is the first time the FDA has created a definition for a “cyber device,” but this guidance is specific to the refusal to accept policy (RTA) rather than guidance for the format and content of pre-market notification (i.e., 510k) If you want to learn about new guidance documents as they are released, we recommend that you sign up for FDA email notifications. If you want to be notified of when our new blogs are posted, subscribe to our blog email notification list on this page.
What is a “cyber device” in the context of this cybersecurity devices guidance and submissions?
This new guidance defines “cyber device” using the following language:
includes software validated, installed, or authorized by the sponsor as a device or in a device;
has the ability to connect to the internet; and
contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.
What does “refusal to accept” (RTA) mean?
“Refusal to accept” or (RTA) is a policy that the FDA implemented for pre-market notification submissions (i.e., 510k) in 2012. The process occurs during the first 15 calendar days of the FDA review process. The FDA assigns a preliminary reviewer to perform the RTA screening of the submission, and the person completes an RTA checklist. The FDA substitutes an RTA screening with a technical screening for FDA eSTAR templates, and this is one of the reasons why Medical Device Academy uses the FDA eSTAR templates for all 510k submissions and De Novo classification requests instead of using the older 510k format and content requirements with 20 sections.
When will the FDA begin rejecting submissions during the RTA processes?
The FDA states directly in the guidance document that they will not reject submissions for cybersecurity for the balance of FY 2023 (i.e., before October 1, 2023). The wording used by the FDA is: “The FDA generally intends not to issue “refuse to accept” (RTA) decisions for premarket submissions for cyber devices that are submitted before October 1, 2023, based solely on information required by section 524B of the FD&C Act. Instead, the FDA will work collaboratively with sponsors of such premarket submissions as part of the interactive and/or deficiency review process.” We believe the FDA will update the eSTAR template to include requirements for cybersecurity on October 1, 2023. It will not be possible to submit a 510k that does not include the cybersecurity requirements in future eSTAR templates, because the eSTAR automatically verifies the completion of each section in the template.
Will there be another cybersecurity guidance released soon?
The FDA announced last October that a new cybersecurity guidance would be replacing the 2014 final guidance for cybersecurity. A draft was released in 2018, and an updated draft was released in 2022. The final updated guidance is included in the A-list of FDA priorities for final guidance documents, but the updated final version has not been released yet. The FDA webpage for cybersecurity was updated to include this new guidance on RTA policy for cybersecurity devices. We believe this indicates that the updated final version will be released soon. When it is released, we will publish a new blog about that guidance.
The 2022 draft cybersecurity guidance from the FDA emphasizes the need to design devices to be secure and the need to design devices capable of reducing emerging cybersecurity risks throughout the total product lifecycle. Designing devices for security must be built into your original design plan, or you will need to modify your device for improved security just to obtain initial 510(k) clearance from the FDA. What is not clear from the guidance or standards is when you need to conduct security testing or repeat tests.
Planning Cybersecurity Tests
As with all quality system processes, cybersecurity testing should begin with a plan. There are two models typically used for the design and development process: Waterfall Diagram (typical of hardware development) and V-Diagram (typical of software development).
Waterfall Diagram
V-Diagram
How are design plans for SaMD different from other design plans?
Most of the verification testing for software as a medical device (SaMD) is 1) conducted virtually, 2) tests software code in a “sandbox,” and 3) involves internally developed testing protocols. In contrast, verification testing for other types of devices involves 1) physical devices, 2) testing at a 3rd party lab, and 3) involves international standards and testing methods. The biggest differences between SaMD verification testing and other device verification testing are the speed and cost of the testing. SaMD verification is much faster and less expensive. Therefore, if your software design documentation is efficient, you can complete more design iterations. This is why software developers use the V-diagram to model the design and development process instead of the “waterfall” diagram.
Where do the requirements to test cybersecurity belong in your design plan?
A design plan documents the design and development process for your device. You must establish, maintain, and update the plan as the project progresses. There is no required format, but auditors and the FDA will audit your Design History File (DHF) for compliance with your plan. You are required to document the following content in your plan:
Stages of development
Reviews at each design and development stage
Verification, validation, and design transfer activities at each stage
Responsibilities and authorities for the design project
Methods you are using to ensure traceability of user needs, software hazards, software requirements, software design specifications, and software testing reports
Human resources needed for your design project, including competency
Software Design Inputs
In the early stages of the software development lifecycle, you must select an appropriate threat model and perform a hazard analysis for software security. These security hazards need to be included as design inputs in your software requirements specification (SRS). The need for updateability and patchability should also be included as design inputs.
In parallel with your SRS, you will need to create a User Specification. The SRS and User Specification will determine the use cases and call-flow views that require verification testing later in your software development process. After the SRS has been approved, you will need to create a software design specification (SDS). Each item in the SDS should be traceable to an item in the SRS. The SDS items that trace to security hazards are your risk controls. Each risk control will require you to test cybersecurity to verify risk control effectiveness. At this point, you will need to create your testing protocols for security.
System Testing Protocols to Test Cybersecurity
Testing protocols should include a boundary analysis and rationale for boundary assumptions. Testing protocols should also include vulnerability testing. The FDA recommends the following vulnerability testing:
Abuse cases, malformed, and unexpected inputs,
Robustness
Fuzz testing
Attack surface analysis,
Vulnerability chaining,
Closed box testing of known vulnerability scanning,
Software composition analysis of binary executable files, and
Static and dynamic code analysis, including testing for credentials that are “hardcoded,” default, easily guessed, and easily compromised.
Does your development budget include security testing?
Design control training traditionally emphasizes the importance of “freezing” design outputs before starting verification testing to prevent the need for repeating any of the verification testing. The reason for this is that verification testing is expensive, and it is time-consuming to produce additional verification samples. In contrast, SaMD is guaranteed to be changed multiple times during the verification testing process as software bugs are identified. Therefore, software developers focus on the velocity of developing code and testing that code. One exception to this is penetration testing. Penetration testing is usually conducted once your code is final because it is more expensive than other software verification and validation testing and it would need to be repeated each time the software is updated or patched.
Penetration Testing
Penetration testing is another method used to test cybersecurity that would probably be conducted in parallel with simulated use testing to validate performance and the effectiveness of human factors risk controls. Penetration testing could be at the system level in a sandbox environment, or it can be performed on a sample device in a simulated use environment. Your penetration testing documentation should include the following:
independence and technical expertise
scope of testing
duration of testing
testing employed, and
test results, findings, and observations
Postmarket cybersecurity management
For CE Marked products, there is a requirement for a postmarket surveillance plan (i.e., PMS plan) to be submitted as part of your technical file. The US FDA does not currently have this requirement for Class 1 and Class 2 devices, but Class 3 devices (i.e., PMA) and devices with humanitarian device exemptions (HDE) are required to submit a PMS plan as part of the premarket submission. The US FDA also requires a postmarket cybersecurity management plan to be submitted for premarket submissions of Class 2 and Class 3 devices. You should create your postmarket cybersecurity management plan during your verification and validation activities, and the final version should be approved at the time of product release.
If you need additional resources or training related to cybersecurity, you may be interested in the following:
On April 8, 2022, the FDA released a new draft cybersecurity guidance document to replace the 2018 draft that the industry does not support.
Why was the draft cybersecurity guidance created?
Due to the ubiquitous nature of software and networked devices in the medical industry, the impact of cybersecurity attacks is becoming more frequent and more severe. The WannaCry Ransomeware Attack is just one example of this global cybersecurity issue. The FDA is responding to the need for stronger cybersecurity controls by issuing a new draft cybersecurity guidance for 2022.
The first four paragraphs of the introduction explain why we need this, and WannaCry is mentioned in the second paragraph of the background section. This new guidance is only a draft, but this is the FDA’s third attempt at regulating the cybersecurity of medical devices. The first guidance was finalized in 2014. That’s the 9-page guidance we currently have in effect. The guidance mentions risk 11 times and there is no mention of testing requirements or a bill of materials (BOM). The 2018 draft guidance (24-pages) met with resistance from the industry for a lot of reasons. One of the reasons mentioned by Suzanne Schwartz in an interview is the inclusion of a cybersecurity bill of materials (CBOM). The industry felt it would be too burdensome to disclose all of the hardware elements that are related to cybersecurity. Therefore, the FDA rewrote the 2018 draft and released a new draft on April 8, 2022 (49-pages).
You might have expected the FDA to soften its requirements in the face of resistance from industry, but the new draft does not appear to be less robust. It is true that the CBOM was replaced by a software bill of materials (SBOM). However, the SBOM must be electronically readable and it must include:
the asset(s) where the software resides;
the software component name;
the software component version;
the software component manufacturer;
the software level of support provided through monitoring and maintenance from the software component manufacturer;
the software component’s end-of-support date; and
any known vulnerabilities.
You can be sure that the medical device industry will view providing an SBOM as a hefty burden. After all, a machine-readable SBOM is more complex than UDI labeling requirements. An SBOM will not fit on the “Splash Screen” for anyone’s software application. Companies may provide documentation through the company website with a link in their software to that information. The format of the information could be in the “Manufacturer Disclosure Statement for Medical Device Security (MDS2).” However, MDS2 is a 349-line item Excel spreadsheet to be used as a checklist (i.e. quite a bit longer than the GUDID data elements spreadsheet), and it took the FDA eight years to complete the transition for the UDI Final Rule (i.e. 2013 – 2021).
The 2018 draft cybersecurity guidance document from the FDA required a cybersecurity bill of materials (CBOM). CBOM was defined as “a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.” Therefore, the FDA’s change from a CBOM to an SBOM eliminated the requirement to disclose the hardware components. Despite the change in disclosure requirements, manufacturers will still be expected to monitor potential hardware vulnerabilities to cybersecurity attacks. It should also be noted that the language in the PATCH Act (a new bill submitted to the House of Representatives and to the Senate for ensuring the cybersecurity of medical devices) specifically requires manufacturers “to furnish a software bill of materials as required under section 524B (relating to ensuring the cybersecurity).”
Structure of the draft cybersecurity guidance
The 2022 draft cybersecurity guidance organizes the requirements into four major principles:
cybersecurity as part of device safety and the quality system regulations
designing for security
transparency
submission documentation
The draft cybersecurity guidance recommends the implementation of a Secure Product Development Framework (SPDF). However, there is not much detail provided in the guidance for a SPDF. In the past, the term for this type of process was referred to as a Secure Software Development Lifecycle (i.e. Secure SDLC). However, in February 2022, the NIST Computer Security Resource Center (CSRC) released version 1.1 of the Secure SDLC guidance which is now titled “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.” This guidance provides guidance on the implementation of best practices for reducing the risk of software vulnerabilities because existing standards for managing the software development lifecycle do not explicitly address software security (e.g. IEC 62304-1:2015). The SSDF recommends implementing a core set of high-level secure software development practices that can be integrated into your SDLC process. Your software development team will also require cybersecurity training.
Design for security is the second principle of the draft cybersecurity guidance
Under this new draft cybersecurity guidance, the FDA will be evaluating the cybersecurity of devices based on the ability of the device to provide and implement the following security objectives:
Authenticity, which includes integrity;
Authorization;
Availability;
Confidentiality; and
Secure and timely updatability and patchability.
Transparency of cybersecurity information is for users
The draft cybersecurity guidance seeks to give device users more information pertaining to the device’s cybersecurity controls, potential risks, and other relevant information. This information will be in the form of an SBOM that is electronically readable. This information shall include disclosure of 1) known vulnerabilities or risks, 2) information to securely configure and update devices, and 3) communication interfaces and third-party software.
In addition to providing an SBOM, the FDA draft cybersecurity guidance includes requirements for cybersecurity labeling in section VI(A). There are 15 specific labeling requirements identified by the FDA for sharing with device users to improve the transparency of cybersecurity information. The first of these requirements is recommendations from the manufacturer for cybersecurity controls appropriate for the intended use environment (e.g., antimalware software, use of a firewall, password requirements). This first labeling requirement is identical to the 2018 draft guidance. Several of the other requirements are copied from the 2018 draft guidance, but others are new and/or reworded cybersecurity labeling requirements.
FDA Submission Documentation Requirements
The 2022 FDA draft cybersecurity guidance includes requirements for FDA submission documentation. Submission documentation must include a security risk management plan and report. The draft cybersecurity guidance explains on page 13 (numbered 9) that “performing security risk management is a distinct process from performing safety risk management as described in ISO 14971:2019.” Therefore, instead of using your safety risk management process, your software development team will need to have a different risk management process for software security. Details on the content for security risk management plans and reports can be found in AAMI TIR57:2016 – Principles for medical device security—Risk management. Appendix 2 also provides guidance for the inclusion of a) call flow diagrams, and b) information details for an architecture view.
Cybersecurity testing requirements for your FDA submission
The biggest impact of this new draft guidance may be the requirement for testing. The 2014 guidance has no testing requirement, the 2018 draft guidance mentioned testing 5 times in a few bullet points, but this new draft guidance mentions testing 43 times. The testing requirements for cybersecurity risk management verification include:
Security requirements
Threat mitigation
Vulnerability testing
Penetration testing
This guidance also includes a paragraph with multiple bullets of requirements for each of the four types of testing. This would essentially double the size and scope of the current software section for a 510k submission, and manufacturers will need to create new procedures and templates for their cybersecurity risk management process. For example, penetration testing requirements include the following elements:
Independence and technical expertise of testers,
Scope of testing,
Duration of testing,
Testing methods employed, and
Test results, findings, and observations.
Differences between the cybersecurity guidance documents
The following table provides a high-level overview comparing the four cybersecurity guidance documents released by the FDA, including the 2016 guidance on post-market management of cybersecurity:
Vulnerability management plans
The FDA draft cybersecurity guidance document also has a requirement for manufacturers to develop a plan for identifying and communicating vulnerabilities to device users after the release of the device. The FDA requires this plan to be included in your device submission. The vulnerability management plan should include the following information (in addition to the requirements of the 2016 guidance for postmarket cybersecurity management):
Personnel responsible;
Sources, methods, and frequency for monitoring for and identifying vulnerabilities (e.g. researchers, NIST NVD, third-party software manufacturers, etc.);
Periodic security testing to test identified vulnerability impact;
Timeline to develop and release patches;
Update processes;
Patching capability (i.e. rate at which update can be delivered to devices);
Description of their coordinated vulnerability disclosure process; and
Description of how manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.
What’s the next step for the draft cybersecurity guidance?
In March the “Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act)” was introduced to the House of Representatives and the Senate. The goal of the PATCH Act is to enhance medical device security by requiring manufacturers to create a cybersecurity risk management plan for monitoring and addressing potential postmarket cybersecurity vulnerabilities. The FDA seeks comments on the draft cybersecurity guidance through July 7, 2022. Given the support of the new bill in the House of Representatives and Congress, it is likely that the FDA will get the support it needs for this new guidance.
What is your company’s approach to qualifying a software service provider and managing software-as-a-service (SaaS) for cybersecurity?
The need for qualifying and managing your software service provider
Most of the productivity gains of the past decade are related to the integration of software tools into our business processes. In the past, software licenses were a small part of corporate budgets, and the most critical software tools helped to manage material requirements planning (MRP) functions and customer relationship management (CRM). Today, there are software applications to automate every business process. Failure of a single software service provider, also known as “Software-as-a-Service” or (Saas), can paralyze your entire business. In the past, business continuity plans focused on labor, power, inventory, records, and logistics. Today our business continuity plans also need to expand for the inclusion of software service providers, internet bandwidth, websites, email, and cybersecurity. This new paradigm is not specific to the medical device industry. The medical device industry has become more dependent upon its supply chain due to the ubiquity of outsourcing, and what happens to other industries will eventually filter its way into this little collective niche we share. With that in mind, how do we qualify and manage a software service provider?
Threats to software service providers (Kaseya Case Study)
Two years ago the WannaCry ransomware attack affected 200,000 computers, 150 countries, and more than 80 hospitals.
Kaseya isn’t a hospital. Kaseya is a software service provider company. So why is this example relevant to the medical device industry?
The ransomware attack on Kaseya was severe enough that both CISA and the FBI got involved, and it compromised some Managed Service Providers (MSPs) and downstream customers. This supply chain ransomware attack even has its own Wikipedia page. The attack prompted Kaseya to shut down servers temporarily. None of this is a critique of Kaseya or their actions. They were merely the latest high-profile victim of a cyberattack in the news. Now cybercriminals are attacking your supply chain. We want to emphasize the concepts and considerations of this type of attack as it pertains to your business.
What supplier controls do you require for a software service provider?
If you are a manufacturer selling a medical device under the jurisdiction of the U.S. FDA, you need to comply with 21 CFR 820.50 (i.e. purchasing controls). The FDA requires an established and maintained procedure to control how you are ensuring what your company buys meets the specified requirements of what you need. Many device manufacturers only consider suppliers that are making physical components, but a software service provider may be critical to your device if your device is software as a medical device (SaMD), includes software, or interacts with a software accessory. A software service provider may also be involved with quality system software, clinical data management, or your medical device files. Do you purchase software-as-a-service or rely upon an MSP for cloud storage?
You need to determine if your software service provider is involved in document review or approval, controlling quality records, Protected Health Information (PHI), or electronic signature requirements. You don’t need a supplier quality agreement for all of the off-the-shelf items your company purchases. For example, it would be silly to have Sharpie sign a supplier quality agreement because you occasionally purchase a package of highlighters. On the other hand, if you are relying upon Docusign to manage 100% of your signed quality records, you need to know when Docusign updates its software or has a security breach. You should also be validating Docusign as a software tool, and there should be a backup of your information.
21 CFR 820.50 requires that you document supplier evaluations to meet specified and quality requirements per your “established and maintained” procedure. The specified requirements for this supplier might include the following:
How much data storage do you need?
How many user accounts do you need?
Do you need unique electronic IDs for each user?
Do you need tech support for the software service?
Is the software accessed with an internet browser, is the software application-based, or both?
How much does this software service cost?
Is the license a one-time purchase? Or is it a subscription?
The quality requirements for a supplier like this may look more like these questions;
How is my information backed up?
Can I restore previous file revisions in the case of corruption?
How can I control access to my information?
Can I sign electronic documents? If yes, is it 21 CFR Part 11 compliant?
Does this supplier have downstream access to my information? (can the supplier’s suppliers see my stuff?)
Do I manage PHI? If so, can this system be made HIPAA compliant? What about HITECH?
What cybersecurity practices does this supplier utilize?
How are routine patches and updates communicated to me?
A risk-based approach to supplier quality management
ISO 13485:2016 requires that you apply a risk-based approach to all processes, including supplier quality management. A risk-based approach should be applied to suppliers providing both goods and services. For example, you may order shipping boxes and contract sterilization services. Both companies are suppliers, but in this example, the services provided by the contract sterilizer are associated with a much higher risk than the shipping box supplier. Therefore, it makes sense that you would need to exercise greater control over the sterilizer. Software service providers are much like contract sterilizers. SaaS is not tangible but the service provided may have a high level of risk and potential impact on your quality management system. Therefore, you need to determine the risk associated with SaaS before you can evaluate, control, and monitor a software service supplier.
First, you need to document the qualification of a new supplier. It would be nice if your cloud service provider had a valid ISO 13485:2016 certification. You would then have an objectively demonstratable record of their process controls and know that they are routinely audited to maintain that certification. They would also understand and expect to undergo 2nd party supplier audits because they operate in the medical device industry. Alternatively, a software service provider may have an ISO 9001:2015 certification. This is a general quality system certification that may be applied to all products or services. In the absence of quality system certification, you can audit a potential supplier. For some suppliers, this makes sense. However, many companies that are outside of the medical device industry do not even have a quality system because it is not required or typical of their industry. For the ones that do, though, you can likely leverage their existing certifications and accreditations.
Cybersecurity standards you should know
Most cloud service providers will not have ISO 13485 certification, because it is a quality management standard specific to the medical device industry. However, you might look for some combination of the following ISO standards that may be relevant to a software service provider:
ISO/IEC 27001 Information Technology – Security Techniques – Information Security Management Systems – Requirements
ISO/IEC 27002:2013 Information Technology. Security Techniques. Code Of Practice For Information Security Controls
ISO/IEC 27017:2015 Information Technology. Security Techniques. Code Of Practice For Information Security Controls Based On ISO/IEC 27002 For Cloud Services
ISO/IEC 27018:2019 Information Technology – Security Techniques – Code Of Practice For Protection Of Personally Identifiable Information (PII) In Public Clouds Acting As PII Processors
ISO 22301:2019 Security And Resilience – Business Continuity Management Systems – Requirements
ISO/IEC 27701:2019 Security Techniques. Extension to ISO/IEC 27001 and ISO/IEC 27002 For Privacy Information Management. Requirements And Guidelines
Does your software service provider have SOC reports?
The acronym “SOC” stands for Service Organization Control, and these reports were established by the American Institute of Certified Public Accountants. SOC reports are internal controls that an organization utilizes and each report is for a specific subject. SOC reports apply to varying degrees for SaaS and MSP Suppliers
The SOC 1 Report focuses on Internal Controls over Financial Reporting. Depending on what information you need to store on the cloud, this report could be more applicable to the continuity of your overall business than specifically to your quality management system.
The SOC 2 Report addresses what level of control an organization places on the five Trust Service Criteria: 1) Security, 2) Availability, 3) Processing Integrity, 4) Confidentiality, and 5) Privacy. As a medical device manufacturer, these areas would touch on control of documents, control of records, and process validation, among other areas of your quality system. Some suppliers may not share a SOC 2 report with you, because of the amount of confidential detail provided in the report.
The SOC 3 Report will contain much of the same information that the SOC 2 Report contains. They both address the five Trust Service Criteria. The difference is the intended audiences of the reports. The SOC 3 is a general use report expected to be shared with others or publicly available. Therefore, it doesn’t go into the same intimate level of detail as the SOC 2 report. Specifically, information regarding what controls a system utilizes is very brief if identified at all compared to the description and itemized list of controls in the SOC 2 Report.
Other ways to qualify and manage your software service provider
SOC reports will help paint a picture of the organization you are trying to qualify for. You will also need to evaluate the supplier on an ongoing basis. It is essential to know if the supplier is subject to routine audits and inspections to maintain applicable certifications and accreditations. For example, if their ISO certificate lasts for three years, you should know that you should follow up with your supplier for their new certificate at least every three years. On the other hand, if they lose certification, it may signify that the supplier can’t meet your needs any longer and you should find a new supplier.
There is a long list of standards, certifications, accreditations, attestations, and registries that you can use to help qualify a SaaS or MSP supplier. One such registry is maintained by Cloud Security Alliance (i.e. the CSA STAR registry). “STAR” is an acronym standing for Security, Trust, Assurance, and Risk. CSA describes the STAR registry in their own words:
“STAR encompasses the key principles of transparency, rigorous auditing, and harmonization of standards outlined in the Cloud Controls Matrix (CCM) and CAIQ. Publishing to the registry allows organizations to show current and potential customers their security and compliance posture, including the regulations, standards, and frameworks they adhere to. It ultimately reduces complexity and helps alleviate the need to fill out multiple customer questionnaires.”
Some of the questions your supplier qualification process should be asking about your SaaS and MSP suppliers include:
Why do I need this software service?
Which standards, regulations, or process controls need to be met?
What is required for qualifying suppliers providing SaaS or an MSP?
How will you monitor a software service provider?
ISO certification, SOC reports, and the CSA STAR registry are supplier evaluation tools you can use for supplier qualification and monitoring. When you use these tools, make sure that you ask open-ended questions instead of close-ended questions. Our webinar on supplier qualification provides several examples of how to convert your “antique” yes/no questions into value-added questions.
Your software service provider should be able to provide records and metrics demonstrating the effectiveness of their cybersecurity plans. Below are three examples of other types of records you might request:
Cloud Computing Compliance Controls Catalogue or “C5 Attestation Report”
System Security Plan for Controlled Unclassified Information in accordance with NIST publication SP 800-171
Privacy Shield Certification to EU-U.S. Privacy Shield or Swiss-U.S. Privacy Shield
The privacy shield certification may be especially important for companies with CE Marked devices in order to comply with the European Union’s General Data Protection Regulation (GDPR) orRegulation 2016/679.
A final consideration for supplier qualification is, “Who are the upstream suppliers?” It is essential to know if your new supplier or their suppliers will have access to Protected Health Information (PHI). Since you have less control of your supplier’s subcontractors, you may need to evaluate how your supplier manages their supply chain and which general cybersecurity practices your supplier’s subcontractors adhere to.
Additional cybersecurity, software validation, and supplier quality resources
For more resources on cybersecurity, software validation, and supplier quality management please check out the following resources:
