The Cybersecurity Code of Practice for Critical Information Infrastructure (CCoP) 2.0, issued by the Cyber Security Agency of Singapore, was designed to strengthen the resilience of essential services in the face of increasingly sophisticated cyber threats.
While the regulatory intent of CCoP 2.0 is clear, the operational challenge is not. Compliance is no longer achieved by documenting controls, publishing policies, or completing periodic assessments alone. Organizations are now expected to prove that cybersecurity controls operate effectively under real attack conditions.
Across governance, protection, detection, and response domains, CCoP 2.0 implicitly shifts expectations from control presence to control effectiveness. This creates a growing need for defensible, repeatable, and current evidence that controls work as intended in real-world environments.
This is where Picus changes how CCoP 2.0 compliance is achieved. By continuously validating security controls against real adversary behavior, Picus turns technical control performance into operational, audit-ready evidence, enabling organizations to meet CCoP 2.0 requirements with confidence.
CCoP 2.0 was designed to reduce this risk by emphasizing continuous assessment, detection, and response readiness. Operationalizing that intent requires continuous validation. Modern Critical Information Infrastructure (CII) environments rely on technical controls across identity, endpoint, network, detection, and OT layers to enforce CCoP 2.0 requirements. Picus approaches compliance by validating these controls directly.
Instead of asking whether a control is configured, Picus tests whether it:
This shifts CCoP 2.0 compliance from policy-driven assertions to evidence-based assurance, where effectiveness is demonstrated continuously rather than inferred periodically.
"The Critical Information Infrastructure owner (CIIO) shall establish a red teaming or purple teaming attack simulation plan…" (Section 5.16.1)
"The CIIO shall conduct a red teaming or purple teaming attack simulation on its CII at least once every 24 months to test and validate the effectiveness of its cybersecurity measures against prevalent cybersecurity threats." (Section 5.16.2)
Section 5.16 requires CIIOs to formally plan, execute, and validate adversarial simulations that test prevention, detection, and response capabilities. Picus supports this requirement by continuously executing adversary-emulated attack techniques aligned with real-world TTPs. This allows organisations to validate control effectiveness between mandated simulations and produce evidence that cybersecurity measures operate effectively against prevalent threats.
"The CIIO shall conduct a penetration test on the CII…" (Section 5.15.1)
"The CIIO shall ensure that third-party penetration testing service providers and their penetration testers … possess industry-recognised accreditations and certifications." (Section 5.15.3)
Section 5.15 mandates penetration testing conducted by accredited, human penetration testers at defined intervals and after major system changes. Picus complements these tests by automating repeatable attack scenarios that continuously validate baseline security controls between formal engagements. This reduces manual effort, expands coverage, and enables human testers to focus on advanced and creative attack paths.
"The CIIO shall establish processes to identify and track cybersecurity vulnerabilities of the CII." (Section 5.14.1)
"The CIIO shall remediate all cybersecurity vulnerabilities in a timely manner, with priority given to vulnerabilities that pose a greater risk to the security or operations of the CII." (Section 5.14.2)
Section 5.14 requires not only vulnerability identification, but prioritised remediation based on operational risk. Picus supports this requirement by validating whether identified vulnerabilities are exploitable in practice. By simulating real attack paths, Picus helps organisations prioritise remediation based on real exposure rather than theoretical severity alone.
"The CIIO shall establish and implement mechanisms and processes for monitoring and detecting all cybersecurity events in respect of the CII." (Section 6.2.1(a))
"Alerts for further investigation shall be triggered for all deviations and anomalous activities that are detected." (Section 6.2.2(c))
"The CIIO shall review the mechanisms and processes … at least once every 12 months to ensure that the mechanisms and processes remain effective." (Section 6.2.3)
Section 6.2 explicitly requires CIIOs to ensure detection mechanisms remain effective over time. Picus supports this requirement by executing real-world attack scenarios and analysing detection outcomes. Using Picus Detection Analytics, organisations can determine which attack behaviors trigger alerts, which are missed, and where visibility gaps exist, supporting continuous review and tuning of detection mechanisms as required by the Code.
"The CIIO shall ensure that the OT CII is not connected to any enterprise network except where necessary…" (Section 10.2.1)
"The CIIO shall monitor the data flows from the OT CII to any enterprise network for anomalies…" (Section 10.2.2)
Section 10.2 mandates segmentation, monitoring, and protection of OT environments. Picus supports this requirement by simulating adversarial attack techniques targeting IT–OT boundaries, allowing organisations to validate whether segmentation, access controls, and monitoring mechanisms effectively prevent unauthorised access and lateral movement without disrupting operations.
"The CIIO shall conduct scenario-based cybersecurity exercises…" (Section 7.3.1)
"The CIIO shall conduct scenario-based cybersecurity exercises … at least once every 12 months." (Section 7.3.2)
Section 7.3 mandates recurring, scenario-based exercises. Picus supports this requirement by embedding adversarial simulations into operational environments, enabling continuous and realistic exercises that test people, process, and technology together.
"The CIIO shall generate, collect, and store logs of all access and attempts to access the CII…" (Section 6.1.1)
"The CIIO shall ensure that the logs … are stored for a minimum period of 12 months." (Section 6.1.4(c))
"The CIIO shall provide any such logs … as may be required by the Commissioner." (Section 6.1.3)
Section 6.1 requires logs to be complete, retained, and usable for investigation. Picus supports this requirement by validating whether real attack activity generates the expected logs across controls and infrastructure. This helps organisations confirm that logging mechanisms provide sufficient evidence to support investigations, audits, and regulatory requests.
"The CIIO shall establish and implement mechanisms and processes to obtain threat intelligence…" (Section 6.4.1)
"The CIIO shall put in place controls to mitigate cybersecurity threats and address vulnerabilities identified from threat intelligence." (Section 6.4.3)
Section 6.4 requires CIIOs to translate threat intelligence into mitigating controls. Picus supports this requirement by converting threat intelligence reports into executable validation tests. This allows organisations to verify that controls implemented in response to threat intelligence actually mitigate the identified threats.
"The CIIO shall establish and implement a cybersecurity risk management framework." (Section 3.2.1)
"The CIIO shall maintain and keep updated a risk register for each CII." (Section 3.2.4)
Section 3.2 requires risks to be identified, assessed, prioritised, and tracked. Picus supports this requirement by providing validated evidence of control effectiveness and exposure, enabling risk registers to be updated with tested outcomes rather than assumptions and improving risk prioritisation decisions.
"The CIIO shall establish a Cybersecurity Incident Response Plan…" (Section 7.1.1)
"The CIIO shall review the Cybersecurity Incident Response Plan at least once every 12 months." (Section 7.1.6)
Section 7.1 requires incident response plans to be actionable and effective. Picus supports this requirement by simulating attacks that exercise detection, escalation, and containment workflows, allowing organisations to validate whether incident response processes would function as required.
"The CIIO shall ensure that actual practices and implementation are consistent with the policies, standards, guidelines, and procedures." (Section 3.3.3)
Section 3.3 requires alignment between documented policies and real implementation. Picus validates whether controls enforcing policies operate as expected in practice, helping organisations identify and remediate gaps between policy and execution.
"Adequate resources and attention must be devoted to the CIIO's cybersecurity strategy…" (Section 3.1)
"The CIIO shall ensure that its board of directors … includes at least one member that has knowledge and awareness of cybersecurity matters." (Section 3.1.2)
Section 3.1 requires leadership oversight to be informed and effective. Picus provides objective validation data that leadership can use to assess cybersecurity effectiveness, supporting evidence-based oversight and decision-making.
"The CIIO shall establish mechanisms and processes to identify all CII assets and maintain an inventory of the assets." (Section 4.1.1)
"The CIIO shall update the inventory whenever there is any change to any CII asset." (Section 4.1.2)
Section 4.1 requires asset inventories to reflect real dependencies and exposure. Picus supports this requirement by validating which assets are reachable and exploitable through real attack paths, enriching asset inventories with risk context rather than static listings.
CCoP 2.0 aims to ensure that essential services remain resilient because the controls protecting them work in practice.
Picus helps organizations move from periodic, assumption-based compliance to continuous, evidence-based assurance. By validating control effectiveness against real attack behavior, Picus turns CCoP 2.0 compliance into a living, defensible security posture.
Get your demo and see how Picus helps organizations protect Critical Information Infrastructure with audit-ready evidence.