{
  "sRequirements": [
      {
    "requirementStandard": "IEC 62443 3-2 (§4.2.1)",
    "requirementName": "ZCR 1.1: Identify the SUC perimeter and access points",
    "requirementDescription": "Large organizations often operate multiple control systems across different industrial facilities, any of which can be designated as a SUC. A single facility may have several control systems managing different functions. This requirement calls for the identification of SuCs for cybersecurity analysis. The SuC definition encompasses all IACS assets necessary for a complete automation solution. Creating a SuC description may involve compiling a system inventory, architecture diagrams, network diagrams, and dataflows to clearly identify the IACS assets included in the SuC.",
    "requirementSatisfaction": "The organization must clearly identify the SuC, including defining a distinct security perimeter and identifying all access points to it."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.3.1)",
    "requirementName": "ZCR 2.1: Perform initial cybersecurity risk assessment",
    "requirementDescription": "The initial cybersecurity risk assessment aims to determine the maximum potential risk resulting from a SuC compromise. It evaluates impacts on various aspects, including health, safety, environment, business continuity, production, product quality, finances, legal matters, regulations, and reputation. This assessment guides subsequent detailed risk assessments and assists in organizing assets into zones and conduits within the SuC. For potentially hazardous processes, reference should be made to PHA and functional safety assessments according to IEC 61511-2 to identify worst-case impacts. Additionally, organizations should consider threat intelligence from government sources, sector-specific ISAC, and other relevant sources. A typical approach is to employ a risk matrix that relates likelihood, impact, and risk, such as a corporate risk matrix. Examples of risk matrices can be found in Annex B",
    "requirementSatisfaction": "The organization must perform a cybersecurity risk assessment for the SuC or validate the relevance of a prior assessment. This assessment focuses on identifying the most significant unmitigated cybersecurity risk associated with interference, breaches, disruptions, or disabling of critical IACS operations."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.4.2)",
    "requirementName": "ZCR 3.1: Establish zones and conduits",
    "requirementDescription": "Grouping assets into zones and conduits helps identify assets with shared security requirements and determine common security measures for risk mitigation. While this is a general requirement, particular attention should be given to safety-related systems, wireless systems, systems directly linked to the internet, systems managed by external entities, and mobile devices. Assets are often organized into functional layers within operational areas, following models like the Purdue reference model defined in IEC 62264-1 or reference architectures from IACS product suppliers.",
    "requirementSatisfaction": "The organization should categorize IACS assets into zones or conduits based on criteria like asset criticality, operational function, location, necessary access, and organizational responsibility. This categorization follows risk assessment outcomes or other relevant factors."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.4.3)",
    "requirementName": "ZCR 3.2: Separate business and IACS assets",
    "requirementDescription": "Business and IACS are distinct system types that should be separated into separate zones due to fundamental differences in functionality, responsible organization, and initial risk assessment outcomes. Recognizing these differences is crucial, as well as understanding the potential impact of IACS on health, safety, and the environment",
    "requirementSatisfaction": "IACS assets must be grouped into zones that are logically or physically separated from business or enterprise system assets."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.4.4)",
    "requirementName": "ZCR 3.3: Separate safety-related assets",
    "requirementDescription": "Safety-related IACS assets typically require enhanced security measures compared to standard control system components and interfaces. These safety-related zones need higher security levels because of the greater risk associated with potential impacts on health, safety, and the environment if they are compromised.",
    "requirementSatisfaction": "Safety-related IACS assets should be located in separate zones from non-safety-related assets. If separation is not possible, the entire zone should be considered a safety-related zone."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.4.5)",
    "requirementName": "ZCR 3.4: Separate temporarily connected devices",
    "requirementDescription": "Devices with temporary connections to the SUC, like maintenance laptops, portable equipment, and USB devices, pose unique security challenges and should be placed in separate zones. These devices are of concern because their temporary connections can extend to external networks outside the zone. Some exceptions may apply, such as handheld devices used exclusively within a single zone without external network connections.",
    "requirementSatisfaction": "Devices with temporary connections to the SUC should be separated into different zones from assets meant for permanent IACS connections."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.4.6)",
    "requirementName": "ZCR 3.5: Separate wireless devices",
    "requirementDescription": "Wireless signals are more vulnerable than wired networks due to their lack of physical barriers, exposing wireless devices to a wider range of potential threats. In most cases, a wireless access point serves as a conduit connecting a wireless zone to a wired zone, potentially requiring extra security measures, like a firewall, to ensure proper separation",
    "requirementSatisfaction": "Wireless devices should be in separate zones from wired devices"
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.4.7)",
    "requirementName": "ZCR 3.6: Separate devices connected via external networks",
    "requirementDescription": "Remote access, typically provided for maintenance and reporting to employees, suppliers, and partners, extends beyond the SUC’s physical boundary and should be treated as a separate zone with distinct security requirements.",
    "requirementSatisfaction": "Devices allowed to connect to the SUC through external networks should be placed in separate zones"
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.5.2)",
    "requirementName": "ZCR 4.1: Compare initial risk to tolerable risk",
    "requirementDescription": "This step assesses whether the initial risk is acceptable or needs additional mitigation.",
    "requirementSatisfaction": "If the initial risk exceeds the organization’s tolerable risk, a detailed cyber security risk assessment, as defined in (§4.6), must be conducted."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.2)",
    "requirementName": "ZCR 5.1: Identify threats",
    "requirementDescription": "A comprehensive threat list for security risk assessment should include descriptions of the threat source, the threat source’s capability, potential threat vectors, and the assets that may be affected.",
    "requirementSatisfaction": "A list of potential threats to zone or conduit assets shall be created."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.3)",
    "requirementName": "ZCR 5.2: Identify vulnerabilities",
    "requirementDescription": "To assess threat vectors, identify known vulnerabilities associated with assets, often through vulnerability assessments.",
    "requirementSatisfaction": "Analyze the zone or conduit to document known vulnerabilities associated with its assets, including access points."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.4)",
    "requirementName": "ZCR 5.3: Determine consequence and impact",
    "requirementDescription": "Estimating the worst-case impact of a cyber threat is crucial for cost-benefit analysis of security controls.",
    "requirementSatisfaction": "Evaluate each threat scenario for its potential consequences, documenting the worst-case impact on areas like personnel safety, financial loss, business interruption, and the environment."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.5)",
    "requirementName": "ZCR 5.4: Determine unmitigated likelihood",
    "requirementDescription": "Likelihood in risk management pertains to the probability of an event happening, assessed subjectively or objectively, qualitatively or quantitatively.",
    "requirementSatisfaction": "Evaluate each threat to determine its unmitigated likelihood, which is the likelihood of the threat materializing."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.6)",
    "requirementName": "ZCR 5.5: Determine unmitigated cyber security risk",
    "requirementDescription": "Unmitigated cyber security risk is often assessed using a risk matrix, which relates likelihood, impact, and risk.",
    "requirementSatisfaction": "The unmitigated cyber security risk for each threat is determined by combining the impact measure from 4.6.4 and the unmitigated likelihood measure from 4.6.5."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.7)",
    "requirementName": "ZCR 5.6: Determine SL-T",
    "requirementDescription": "Effectively communicating this information to the cybersecurity team is essential. SL-T can be a single value or a vector.",
    "requirementSatisfaction": "A Security Level Target (SL-T) must be set for each security zone or conduit."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.8)",
    "requirementName": "ZCR 5.7: Compare unmitigated risk with tolerable risk",
    "requirementDescription": "For each threat identified in 4.6.6, compare the unmitigated risk to the tolerable risk.",
    "requirementSatisfaction": "This step aims to decide if the unmitigated risk is acceptable or needs further assessment."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.9)",
    "requirementName": "ZCR 5.8: Identify and evaluate existing countermeasures",
    "requirementDescription": "Assess residual risk by factoring in the presence and effectiveness of existing countermeasures.",
    "requirementSatisfaction": "Identify and assess existing SUC countermeasures for their effectiveness in reducing likelihood or impact."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.10)",
    "requirementName": "ZCR 5.9: Reevaluate likelihood and impact",
    "requirementDescription": "Existing countermeasures are factored in to assess the mitigated likelihood, and the consequences and impact from 4.6.4 are also reassessed with these countermeasures in mind.",
    "requirementSatisfaction": "Reevaluate likelihood and impact while considering the effectiveness of countermeasures."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.11)",
    "requirementName": "ZCR 5.10: Determine residual risk",
    "requirementDescription": "Residual risk assessment measures the current risk level and the effectiveness of existing countermeasures.",
    "requirementSatisfaction": "The final risk for each threat from 4.6.2 is determined by combining the reduced likelihood and impact values from 4.6.10."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.12)",
    "requirementName": "ZCR 5.11: Compare residual risk with tolerable risk",
    "requirementDescription": "The aim here is to assess if the residual risk is acceptable or needs further action.",
    "requirementSatisfaction": "If residual risk surpasses acceptable levels, the organization must decide whether to accept, transfer, or mitigate it, as per the organization’s policy."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.13)",
    "requirementName": "ZCR 5.12: Identify additional cyber security countermeasures",
    "requirementDescription": "When residual risk surpasses the organization’s tolerance, countermeasures are implemented to mitigate it. These countermeasures can be technical or non-technical, and asset reallocation to higher security zones may also reduce risk. IEC 62443-3-3 provides guidance on selecting technical countermeasures, which are evaluated for effectiveness using SL-C ratings. It’s important to consider cost and complexity during the design of these countermeasures.",
    "requirementSatisfaction": "If the residual risk exceeds the organization’s tolerable risk, identify additional countermeasures unless the organization chooses to accept or transfer the risk."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.6.14)",
    "requirementName": "ZCR 5.13: Document and communicate results",
    "requirementDescription": "The detailed cyber risk assessment findings should be documented and shared with relevant stakeholders within the organization. Appropriate information security classification should be applied for confidentiality. Documentation should include session dates, participant names and titles, system architecture diagrams, Process Hazard Analysis (PHA), vulnerability assessments, gap assessments, and threat information sources. These records should be archived along with the cyber risk assessment.",
    "requirementSatisfaction": "Cybersecurity risk assessments should be documented and shared with relevant personnel in the organization. These documents are dynamic and serve various purposes, including testing, auditing, and future assessments. It’s important to protect this sensitive information, which may contain system details, vulnerabilities, and existing safeguards."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.2)",
    "requirementName": "ZCR 6: Document cyber security requirements, assumptions, and constraints",
    "requirementDescription": "A Cybersecurity Requirements Specification (CRS) must be created to document mandatory security measures for the SUC. It should be based on the detailed risk assessment results and include general security requirements from company policies, standards, and regulations.",
    "requirementSatisfaction": "Cybersecurity requirements must be documented to ensure clear communication and proper implementation. The CRS doesn’t have to be a standalone document; it can be integrated into other IACS documents."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.3)",
    "requirementName": "ZCR 6.1: Cyber security requirements specification",
    "requirementDescription": "A Cybersecurity Requirements Specification (CRS) must be created to document mandatory security measures for the SUC.",
    "requirementSatisfaction": "The CRS should encompass security countermeasures and features aligned with organizational security policies."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.4)",
    "requirementName": "ZCR 6.2: SUC description",
    "requirementDescription": "Clearly defining the SUC’s scope in the CRS is crucial.",
    "requirementSatisfaction": "The CRS should provide a high-level description of the SUC, including its name, function, usage, and the equipment/process it controls."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.5)",
    "requirementName": "ZCR 6.3: Zone and conduit drawings",
    "requirementDescription": "An overview drawing of the SUC is essential for clear communication of zone and conduit boundaries and asset placement within the SUC.",
    "requirementSatisfaction": "The organization shall create zone and conduit drawings for the entire SUC, and each asset in the SUC must be assigned to a specific zone or conduit."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.6)",
    "requirementName": "ZCR 6.4: Zone and conduit characteristics",
    "requirementDescription": "Documenting zone and conduit attributes is essential for effective security management.",
    "requirementSatisfaction": "For each defined zone and conduit, document the specified attributes."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.7)",
    "requirementName": "ZCR 6.5: Operating environment assumptions",
    "requirementDescription": "Comprehensive documentation of the physical and logical environments is essential for safeguarding IACS assets.",
    "requirementSatisfaction": "The CRS shall detail the physical and logical SUC environment."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.8)",
    "requirementName": "ZCR 6.6: Threat environment",
    "requirementDescription": "The threat environment of a SUC can be influenced by factors like geopolitics, physical surroundings, and system sensitivity.",
    "requirementSatisfaction": "The CRS should describe the threat environment affecting the SUC, encompassing the sources of threat intelligence and covering both current and emerging threats."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.9)",
    "requirementName": "ZCR 6.7: Organizational security policies",
    "requirementDescription": "All systems must adhere to the organization’s baseline security policies.",
    "requirementSatisfaction": "The CRS should encompass security countermeasures and features aligned with organizational security policies."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.10)",
    "requirementName": "ZCR 6.8: Tolerable risk",
    "requirementDescription": "The organization’s acceptable risk level for the SUC should be documented in the CRS.",
    "requirementSatisfaction": "Stakeholders must be informed of the established tolerable risk level to ensure alignment with the SUC’s risk level."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.7.10)",
    "requirementName": "ZCR 6.9: Regulatory requirements",
    "requirementDescription": "This is important to ensure regulatory compliance.",
    "requirementSatisfaction": "Any relevant cyber security regulatory requirements that apply to the SUC shall be included in the CRS."
  },
  {
    "requirementStandard": "IEC 62443 3-2 (§4.8.2)",
    "requirementName": "ZCR 7.1: Attain asset owner approval",
    "requirementDescription": "Risk assessments are typically overseen by third-party facilitators and involve subject matter experts knowledgeable about industrial processes and IACS. However, these experts usually lack the authority to make risk acceptance decisions. As a result, the assessment findings need to be presented to senior management with decision-making authority.",
    "requirementSatisfaction": "Asset owner management responsible for the process controlled by the SUC must review and approve the risk assessment results."
  }
]
}