| Contracts | | The intent of CIP-013-1 is to require entities to develop and implement processes that consider supply chain risks when procuring products and services. Entities are required to include specified security concepts in their procurement activities for high and medium impact BES Cyber Systems but does not mandate the inclusion of any specific provisions in new or renewed contracts to comply with CIP-013. The required process should be integrated into a registered entity’s procurement practices by the effective date of CIP-013-1, if approved by the Commission. |
| Contracts | | The Cyber Security Supply Chain Risk Management Plans Implementation Guidance for CIP-013-1
provides guidance in this area. Entities should develop and implement a solid procurement plan and document anomalies. |
| Contracts | | Yes, an executed contract demonstrating that the requirements of CIP-013-1 were addressed would be sufficient to demonstrate compliance if the registered entity also provides its CIP-013-1 process(es). Attestations, internal procedures, and all relevant email communications should be documented and maintained as evidence of compliance. There should be no need to reveal sensitive/proprietary information to demonstrate compliance. An entity may choose to provide documents with redacted information as audit artifacts. |
| Contracts | | Review the implementation guidance document and the implementation plan for Initial performance. Once the standard is in effect, all new/renegotiated contracts are subject to the standard. |
| Contracts | | The audit team will sample all R2 implementations, so the initial evidence request will ask for a complete list of applicable procurement(s). The audit team will sample the list in accordance with the ERO Sampling Handbook and request complete implementation documentation for the sampled procurements. Keep in mind the R1 plan should provide processes and procedures to indicate how the registered entity will meet the security objectives of CIP-013-1 and address each component of R1 Part 1.1 and Part1.2. While redlined contracts may serve as evidence of R2 implementations, the R1 plans should describe the registered entity’s methodology for identifying and assessing risks associated with applicable procurements. Contracts may be a component of the R1 plan, but the registered entity should ensure the procurement documents support the development of a contract that meets the CIP-013-1 security
objectives. |
| Contracts | | The risk assessment should be performed on the vendor, product, and/or service as dictated by the SCRM plan. The registered entity’s SCRM plan determines where and how the risk assessment is performed. Regarding R1 Part 1.2 and its sub-parts, while the action to renegotiate or abrogate existing contracts is not required, it is expected that mitigations are implemented to address the risks of these elements not being contractually binding on the vendor. All procurements of products or services applicable to high or medium impact BES Cyber Systems after October 1, 2020 would be applicable, under the R1 SCRM plan and R2 implementation. |
| Contracts | | Both contract language and vendor performance to a contract are explicitly taken out of scope for these Requirements by the Note to Requirement R2. As dictated in the R2 note, entities are not expected to renegotiate their contracts; however, the supply chain risk standard would apply to the procurements associated with these agreements. It is recommended that entities do not solely rely on contract language to demonstrate implementation of this Requirement. Instead, it is suggested the implementation of the processes include documentation that you have followed the processes step-by-step. Contracts will only be considered if entities voluntarily submit them as evidence. Procurements, including those under existing contracts, performed on or after October 1, 2020 are subject to CIP-013-1 and should be considered applicable to the Supply Chain Risk Management plan(s). Entities are expected to demonstrate implementation of the SCRM plan on or after the effective date. Dated documentation should demonstrate the process/procedures identified in the SCRM plan were implemented and afforded the required R1 controls to assess and identify cyber security risks and mitigating identified risks as applicable. |
| Contracts | | Both contract language and vendor performance to a contract are explicitly taken out of scope for these Requirements by the Note to Requirement R2. It is recommended that entities do not solely rely on contract language to demonstrate implementation of this Requirement. Instead, it is suggested the implementation of the processes include documentation that you have followed the processes step-bystep. Contracts will only be considered if entities voluntarily submit them as evidence. Procurements, including those under existing contracts, performed on or after October 1, 2020 are subject to CIP-013-1 and should be considered applicable to the Supply Chain Risk Management plan(s).
Entities are expected to demonstrate implementation of the SCRM plan on or after the effective date. Dated documentation should demonstrate the process/procedures identified in the SCRM plan were implemented and afforded the required R1 controls to assess and identify cyber security risks (Part 1.1) and mitigating identified risks as applicable (Part 1.2). |
| Contracts | | The entity determines which evidentiary artifacts are appropriate to demonstrate adherence to the Standard Requirements. These elements should be documented within the SCRM Plan and/or presented during an audit engagement. These artifacts individually or collectively should be able to demonstrate reasonable assurance of adherence to the applicable Standard Requirements. However, a contract itself does not show compliance. Evidence should show that controls in the SCRM plan are implemented that meet the requirements of the Standard. |
| Contracts | | The entity determines which evidentiary artifacts are appropriate to demonstrate adherence to the Standard. These elements may be documented within the SCRM Plan and/or presented during an audit engagement. These artifacts individually or collectively should be able to demonstrate reasonable assurance of adherence to the applicable Standard Requirements. The absence of a contractual clause may present more risk and the CEA could test for Standard adherence. |
| Contracts | | An executed contract demonstrating Part 1.2 was addressed could be sufficient to demonstrate compliance if the registered entity also provides additional supporting evidence such as processes/procedures, email communications, and attestations. The registered entity should not reveal any sensitive or proprietary information that would cause a breach of contract. |
| General / Applicability | | No, the requirements of CIP-013-1 apply only to registered entities, consistent with NERC’s jurisdiction. The registered entity is responsible for complying with CIP-013-1 and for ensuring the vendor is performing in accordance to any contract/agreement. Vendor performance and adherence to a contract is outside the scope of CIP-013-1. |
| General / Applicability | | Entities considered NIST, NAGF guidance, NATF guidance, EEI guidance, SOC2, and ISO 27001 in developing their SCRM programs. In most cases, registered entities used two risk assessment questionnaires, one for vendors and one for products or services. |
| General / Applicability | | In this situation, the registered entity providing the non-reliability service could be considered a vendor providing related services. The Supplemental Material on page 12 of CIP-013-1, states, “The term vendor(s) as used in the standard is limited to those persons, companies, or other organizations with whom the registered entity, or its affiliates, contract with to supply BES Cyber Systems and related services. It does not include other NERC registered entities providing reliability services (e.g., Balancing Authority (BA) or Reliability Coordinator (RC) services pursuant to NERC Reliability Standards). A vendor, as used in the standard, may include: (i) developers or manufacturers of information systems, system components, or information system services; (ii) product resellers; or (iii) system integrators.” |
| General / Applicability | | Yes, a registered entity would be required to document that it does not allow any active vendor remote access. A registered entity would include one or more methods for determining and disabling active vendor remote access sessions in the event such sessions become necessary. |
| General / Applicability | | Yes, in the Supplemental Material on page 12 of CIP-013-1, states, “The term vendor(s) as used in the standard is limited to those persons, companies, or other organizations with whom the registered entity, or its affiliates, contract with to supply BES Cyber Systems and related services. It does not include other NERC registered entities providing reliability services (e.g., Balancing Authority or Reliability Coordinator services pursuant to NERC Reliability Standards). A vendor, as used in the standard, may include: (i) developers or manufacturers of information systems, system components, or information system services; (ii) product resellers; or (iii) system integrators.” The definition does not exclude registered entities as vendors if they are providing products such as hardware or software. |
| General / Applicability | | Product resellers are cited in the CIP-013-1 Supplemental Material section as potential vendors, “A vendor, as used in the standard, may include: (i) developers or manufacturers of information systems, system components, or information system services; (ii) product resellers [emphasis added]; or (iii) system integrators” (p. 12). Depending on the specific reseller and the item(s) procured through the reseller, there may be additional cybersecurity risks associated with such procurements beyond those identified and assessed for the product manufacturer(s) or the product type(s) in the Part 1.1 cybersecurity risk identification and assessment (i.e., hardware and/or software obtained through a reseller). A registered entity would identify and assess any cybersecurity risks that may be involved in purchasing such applicable hardware or software from resellers. |
| General / Applicability | | Under CIP-013-1, 4. Applicability, 4.2 Facilities, it states, “For the purpose of the requirements contained herein, the following Facilities, systems, and equipment owned by each Responsible Entity in 4.1 above are those to which these requirements are applicable.” Additionally, R1. Is applicable to all procurements associated with high and medium impact BES Cyber Systems. As written, the compliance obligations ultimately reside with the Responsible Entity who owns the Facilities with identified high or medium impact BES Cyber Systems. It would be expected that the Responsible Entity perform the risk assessment according to their documented plan to include analyzing risks posed by the vendor, equipment, and services provided, if applicable. These risks are then to be mitigated accordingly. In the scenario where there is joint or shared ownership, it is expected that both Responsible Entities coordinate or perform joint or separate risk assessments. |
| General / Applicability | | The entity dictates what artifacts of evidence best demonstrates compliance with the Standard
Requirements. If prescribed by the SCRM plan, entities could provide the results of their audit on vendors
to show due diligence in identifying and assessing cyber security risks.
|
| General / Applicability | | Any procurement on and after October 1, 2020, of BES Cyber Systems from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s) are subject to CIP-013-1. |
| Risk Mitigation | | When purchasing cyber assets in bulk, it is suggested that an entity have a plan for tracking assets in case they end up being used in CIP-applicable roles. Such an approach would provide a means to assess/mitigate risks as necessary. |
| Risk Mitigation | | The assessment, acceptance, mitigation, and transfer of risk is part of what the entity will work through in developing the supply chain cyber security risk management plan(s). Categorizing risk (e.g. high, medium, low) and then performing the risk management processes is a good path forward. |
| Risk Mitigation | | Whatever the notification mechanism is (e.g., email), the entity should show the processes by which the coordination takes place. Any expectations (time frame, levels of severity, etc.) should be consistent with an entity’s overall incident response plan(s). |
| Risk Mitigation | | One approach is to ensure the registered entity’s SCRM plan details the process to re-evaluate or reassess the vendor(s). This should include the controls the registered entity deploys to maintain awareness of possible vendor acquisitions. |
| Risk Mitigation | | CIP-013-1 is applicable to any procurement regardless of the scenario, including an emergency. CIP-013-1 is silent to any special provisions such as emergency procurements. A registered entity may identify certain hardware, software or services that may be used during emergencies and perform risk assessments in planning for these situations to mitigate the supply chain risk.
Although the CIP-013-1 Standard does not directly address emergency procurements, the registered entity
could consider including language in its R1 SCRM procurement plan that addresses the potential for the
use of purchasing cards in emergency situations. The registered entity should document the emergency
procurement process in the R1 SCRM procurement plan, along with documentation that registered entity
personnel or approved contractors verified after-the-fact risks and mitigations of the procurement. |
| Risk Mitigation | | The registered entities are still responsible for implementation of Part 1.2 in R1. Registered entities should have documented and implemented controls for Part 1.2 in the absence of vendor adherence. For example, if the registered entity’s vendor is not notifying it of vendor-identified incidents, then it may implement a control that monitors US-CERT, ICS-CERT, E-ISAC, and NERC Alerts. |
| Risk Mitigation | | A vendor’s intentional or unintentional ability to adhere to the conditions of an agreement as it relates to CIP-013-1 should be identified and assessed as a risk. As with all of the risks, it is the responsibility of the registered entity to mitigate them accordingly. As an example, the registered entity may address this risk by the implementation of internal controls and processes such as using reputable shippers, tracking shipments, and requiring signatures on delivery. |
| Risk Mitigation | | In this case, the procurement documents (e.g., RFP and vendor response evaluation matrices) used for a specific applicable procurement, along with any contract language connected to the procurement can serve as primary evidence the registered entity pursued its due diligence for the R1 Part 1.2 Requirement Parts, when the vendor failed or refused to comply. As stated in R2, vendor performance and adherence to a contract is beyond the scope of R2, so the responsibility of compliance rests on the registered entity to demonstrate it implemented its Part1.2 processes as far as it could reasonably go without negating the procurement. Since the registered entity identified risk, it is incumbent on the registered entity to enact mitigating measures that would address the vendor’s refusal to meet the Requirement Parts. |
| Risk Mitigation | | Any identified security risks should have some form of mitigation to reduce risk(s); simply accepting the risks is not adequate, unless the analysis performed demonstrates no other reasonable mitigations are available. |
| Risk Mitigation | | The entity-defined SCRM plan documents what level within the organization determines if a risk is acceptable. Furthermore, in instances in which risk must be accepted, entities are expected to document and implement other mitigating controls to minimize the accepted risk, as documented in the SCRM plan. It is incumbent that if a vendor exceeds your organization’s risk threshold, a thorough review and approval should be conducted to ensure a solid understanding of the risk and the mitigating controls afforded or needed to be implemented. Particularly if the risk is identified as having a high probability of causing adverse effects.
Further, entities may want to consider including a process to frequently review and discuss these types of
risk approvals. |
| Risk Mitigation | | It is incumbent on entities to understand the effectiveness and efficiency of third party assessments within their environment. Based on what is documented in the SCRM plan, entities determine if these files are appropriate as evidentiary files. |
| Risk Mitigation | | Both should be done to conduct an accurate cybersecurity risk identification and assessment.
-Vendor questionnaire
-Product or service questionnaire |
| Risk Mitigation | | FERC Order No. 829
The security objective is to ensure entities consider cyber security risks to the BES from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s); and options for mitigating these risks when planning for BES Cyber Systems. |
| Risk Mitigation | | CIP-013-1 is applicable to any procurement regardless of the scenario, including an emergency.
The registered entity should consider including language in its plan to address the potential for the use of purchasing cards in emergency situations.
The registered entity should consider conducting an after-the-fact cybersecurity risk identification and assessment and implement any mitigations of the procurement.
|
| Risk Mitigation | | Based on a given registered entity’s plan
-With every procurement
-Existing assessments could be leveraged
-When certain “triggers” are met such as being bought and sold
-Annually, bi-annually, etc. |
| Risk Mitigation | | Third-party services could be used to complement a registered entity’s own cyber security identification and risk assessment.
|
| Risk Mitigation | | Registered entities should document and implement controls for Part 1.2 in the absence of vendor adherence.
For example, if the registered entity’s vendor is not notifying it of vendor-identified incidents, then a control that monitors US-CERT, ICS-CERT, E-ISAC, and NERC Alerts could be implemented. |
| Software Source/Integrity | | Organizational processes can (and should) be created to ensure software is validated at a higher (centralized) organizational units (e.g. using a central repository), rather than relying on numerous field operations groups. One suggestion is to include the verification and integrity verifications in the patch management process, if possible. |
| Software Source/Integrity | | No, in general, ERO Enterprise audit teams do not accept attestations as primary evidence for performance-based Standards. Some vendors do not have the tools for end users to verify the software integrity obtained. If this were the case, the audit team likely would examine applicable mitigating measures taken for these exceptions. As CIP-010-3 R1 Part 1.6 states, “when the method to do so is available to the registered entity from the software source,” the ERO Enterprise recommends registered entities consider how vendor capability may impact the development of potential internal or external mitigation controls in lieu of vendor support for Part 1.6. The ERO Enterprise also recognizes not all software sources have secure methods for verifying the integrity of the software, so suggests the registered entity document these exceptions in the SCRM plan. If there is an instance where a method is not available to verify the integrity and authenticity of software, it is recommended to document the exception and any mitigating measures internally to reduce the supply chain risk of introduction of malware or counterfeit software. While not required, it
is a best practice to retain artifacts of the vendor’s available methods or lack thereof for the verification of software integrity and authenticity of all software and patches. This will provide an internal audit trail for the registered entity’s records to allow easy reference and may save research time in the event any of those methods should change in the future. For third parties performing the Part 1.6 controls, the audit team likely would expect the registered entity to demonstrate that it obtained the software update/install from the third party performing these services. |
| Software Source/Integrity | | Only procurements for applicable BES Cyber Systems that occur on or after the effective date (October 1, 2020) are in scope for the CIP-013-1 procurement planning processes. However, CIP-005-6 (R2 Parts 2.4 and 2.5), and CIP-010-3 (R1 Part 1.6) become effective on October 1, 2020 and apply to all high and medium impact BES Cyber Systems, including existing applicable BES Cyber Systems. |
| Software Source/Integrity | | The registered entity should use its SCRM plan to identify and assess the risks associated with the third party software installed. The results of this analysis would dictate what mitigations are appropriate to address the risks related to the third party software. Some common forms of evidence include, but are not limited to, checklists or the contents of a change ticket that documents the due diligence performed. |
| Software Source/Integrity | | The Supply Chain Standards are silent on terms and conditions for procured products or services that registered entities may install. A registered entity should implement its risk identification and assessment methodology for all procurements and installations of open-source software on applicable BES Cyber Systems. |
| Software Source/Integrity | | The registered entity may address Part 1.2.1 and Part 1.2.4 by developing one or more internal processes to identify and monitor reputable third-party sources for assessments and reports of applicable open source software incidents or vulnerabilities. The registered entity may consider developing a modified Part 1.2.5 process for acquiring, verifying, and authenticating such software and applicable patches, as released by reputable sources (e.g., for software upgrades or security patches for identified vulnerabilities). An example of this could be a completed evaluation that specifically addresses open source technology. |
| Software Source/Integrity | | The ERO Enterprise also recognizes not all software sources have secure methods for verifying the integrity of the software, so it recommends the registered entity document these exceptions in the supply chain cyber security risk management plan. If there is an instance where a method is not available to verify the integrity and authenticity of software, the ERO Enterprise recommends the registered entity to document the exception and any mitigating measures afforded internally to reduce the supply chain risk of introduction of malware or counterfeit software. Some examples include, but are not limited to, thoroughly research where the software is being downloaded, ensure the name of the file downloaded from the source matches what is being installed, and verify the checksum values and signature files if available. Pursuant to CIP-013-1, Requirement R1, Part 1.2.5, the registered entity should document its verification process of the authenticity of the open source software. In instances where authenticity checks are unavailable, the registered entity should consider documentation outlining the risk factors identified and security controls used to prevent impact to reliability and security. Some example evidence may include change tickets, checklists, results of the evaluation, etc. |
| Software Source/Integrity | | A registered entity should implement its cyber security risk identification and assessment for all procurements of open-source software on all applicable systems.
A registered entity should implement a method to verify the identity of the source and the integrity of the open-source software on all applicable systems.
Document controls implemented that minimize the risks associated with open-source software. |
| Third Party Assessment/Verification/Certification | | The entity determines which evidentiary artifacts are appropriate to demonstrate adherence to the Standard Requirements. These elements should be documented within the SCRM Plan and/or presented during an audit engagement. These artifacts individually or collectively should be able to demonstrate reasonable assurance of adherence to the applicable Standard Requirements.
The ERO will request additional evidentiary artifacts to substantiate compliance with R1 and R2 including internal controls. However, if these elements are absent from the plan and the entity decides not to present them, the ERO could ask further questions to gain clarity. |
| Third Party Assessment/Verification/Certification | | Third-party services can be an acceptable input into the overall cyber security risk(s) assessment implemented by the entity. |
| Third Party Assessment/Verification/Certification | | It is incumbent on the entity to demonstrate the effectiveness of their risk assessment, including the utilization of third-party assessor/certifiers/solution providers. |
| Third Party Assessment/Verification/Certification | | The Standard Requirement affords an entity the flexibility to utilize frameworks as an input in their overall SCRM Plan. |
| Third Party Assessment/Verification/Certification | | The utilization of frameworks in an entity's supply chain risk management program can be implemented. It is the responsibility of the entity to demonstrate the effectiveness of the framework within the overall supply change risk management strategy being implemented. |
| Third Party Assessment/Verification/Certification | | The utilization of frameworks in an entity's supply chain risk management program can be implemented. It is the responsibility of the entity to demonstrate the effectiveness of the framework within the overall supply change risk management strategy being implemented. |
| Third Party Assessment/Verification/Certification | | Third-party assessments or certifications can be an acceptable input into the overall cyber security risk(s) assessment implemented by the entity. However, entities should ensure the identification and assessment of cyber security risk(s) to the Bulk Electric System specifically address the entities applicable Cyber Assets from vendor products or services. Entities are expected to mitigate all identified risks as dictated by their SCRM plan. Mitigation of all identified risks may include adding new controls or leveraging existing controls. |
| Third Party Assessment/Verification/Certification | | The entity determines which evidentiary artifacts are appropriate to demonstrate adherence to the Standard Requirements. These elements should be documented within the SCRM Plan and/or presented during an audit engagement. These artifacts individually or collectively should be able to demonstrate reasonable assurance of adherence to the applicable Standard Requirements. |
| Third Party Assessment/Verification/Certification | | Entities are expected to mitigate all identified risks using mitigation strategies as documented within the SCRM Plan. Additionally, mitigation of all identified risks may include adding new controls or leveraging existing controls. |
| Third Party Assessment/Verification/Certification | | The utilization third-party assessments or certifications within an entity's supply chain risk management program can be implemented. It is the responsibility of the entity to demonstrate the effectiveness of the third-party assessments or certifications within the overall supply change risk management strategy being implemented. The entity is expected to follow their SCRM plan. If the plan directs the Entity to audit their vendor(s), then it will be incumbent on the Entity to do so accordingly. The Entity needs to be aware of this from a contract standpoint. |
| Third Party Assessment/Verification/Certification | | The entity determines which evidentiary artifacts are appropriate to demonstrate adherence to the Standard Requirements. These elements should be documented within the SCRM Plan and/or presented during an audit engagement. These artifacts individually or collectively should be able to demonstrate reasonable assurance of adherence to the applicable Standard Requirements. |
| Third Party Assessment/Verification/Certification | | The utilization third-party assessments or certifications within an entity's supply chain risk management program can be implemented. It is the responsibility of the entity to demonstrate the effectiveness of the third-party assessments or certifications within the overall supply change risk management strategy being implemented, regardless of source and accessibility by the ERO. While having this information provides other intrinsic benefits for awareness, entities are expected to show how the certification works within their program. The ERO Enterprise does not provide guidance or endorsement for industry in terms of where and how certifications are obtained. |
| Third Party Assessment/Verification/Certification | | Entities are expected to mitigate all identified risks using mitigation strategies as documented within the SCRM Plan. The mitigation strategy implemented should be consistent with the entity SCRM Plan. Additionally, any mitigation strategies implemented should be supported by the implemented cyber security risk(s) assessments, business decisions, and the SCRM Plan. |
| Third Party Assessment/Verification/Certification | | It is expected that every entity will have a different risk profile, so risks identified for one may be different that those identified for another. Depending on the facts and circumstances, identified risks associated with a particular vendor utilized by other entities may prompt additional internal control discussions. |
| Third Party Assessment/Verification/Certification | | Registered Entities should ensure that provisions are included in their contractual agreements, 3rd party assessments, or internal controls are implemented such that if a vulnerability is found or identified by a vendor, all regulatory compliance requirements can be met (R1.2.4). For example, releasing information to regulatory authorities via evidence submission.
|
| Vendor | | Although the term “vendor” is not defined in the NERC Glossary of Terms, the drafting team did provide guidance in the CIP-013-1 Guidelines and Technical Basis section. As discussed therein, the standard drafting team (SDT) intended the term vendor to include those persons, companies, or other organizations with whom the Responsible Entity, or its affiliates, contract with to supply BES Cyber Systems and related services. The SDT did not intend it to include, for instance, other NERC registered entities providing reliability services (e.g., Balancing Authority or Reliability Coordinator services) pursuant to NERC Reliability Standards. |
| Vendor | | Consider applying your CIP-011-2 Information Protection Program to secure any BCSI on the decommissioned Cyber Assets. Once this has been documented by your control process, terminate any remaining access permissions. The registered entity should treat the new vendor as such, with a complete Part 1.1 risk identification and assessment process of the vendor and applicable products or services. |
| Vendor | | Within the parameters of CIP-013, the entity is expected to follow their SCRM plan. If the plan directs the entity to audit their vendors, it will be an expectation that it is conducted accordingly. CIP-013-1 is forward looking and eventually all applicable vendors will be assessed and identified cyber risks for products and/or services will be addressed. Therefore, it is prudent to continuously monitor procurement of vendor products or services. The SCRM plan should include a process for monitoring and assessing changes to identified cyber risks after an assessment has been conducted. |
| Vendor | | Supplemental Material
The term vendor(s) as used in the standard is limited to those persons, companies, or other organizations with whom the Responsible Entity, or its affiliates, contract with to supply BES Cyber Systems and related services. It does not include other NERC registered entities providing reliability services (e.g., Balancing Authority or Reliability Coordinator services pursuant to NERC Reliability Standards). A vendor, as used in the standard, may include: (i) developers or manufacturers of information systems, system components, or information system services; (ii) product resellers; or (iii) system integrators. |
| Vendor | | If an entity has contracts with both (VAR and OEM) and both are providing products or services, then both could meet the vendor definition in the Supplemental material.
An identification and assessment of cyber security risks (Part 1.1) should be implemented for both including notification, coordination, disclosure, etc. (Part 1.2)
License agreements may or may not be contractual (READ THEM)
An entity has the flexibility to use a broad or narrow assessment for each vendor based on the risks
Both can introduce certain cyber security risks, even if they act as a middle person
|
| Vendor | | Part 1.1 identification and assessment of cyber security risks. A registered entity should identify and assess any cyber security risks that may be involved in purchasing such applicable hardware or software from the vendor that it is contracted with.
Although the primary focus should be on the vendor you are contracted with, cyber security risks associated with the reseller should not be ignored as part of your cyber security risk identification and assessment.
|
