Compliance Guide to HK Code of Practice for CI Operators Using Picus

Sıla Özeren Hacıoğlu | 12 MIN READ

| February 18, 2026

The Hong Kong Code of Practice (CoP) pursuant to the Protection of Critical Infrastructures (Computer Systems) Ordinance establishes baseline cybersecurity obligations for Critical Infrastructure operators [1].

The Code makes clear that compliance requires more than documented policies, it requires demonstrable control effectiveness, structured risk management, continuous monitoring, and measurable incident readiness.

Across risk assessment, audit, patch management, logging, OT security, drills, and emergency response, the CoP shifts the focus from control presence to operational performance. CI operators must be able to prove that their critical computer systems can withstand real-world attack techniques and that security measures function as intended under live conditions.

The Picus Platform™ supports this objective by continuously validating exploitability and control effectiveness through adversary-emulated techniques. By testing prevention, detection, and response capabilities in a production-safe manner, Picus enables CI operators to generate audit-ready evidence, prioritize remediation based on validated exposure, and demonstrate ongoing compliance aligned with the operational intent of the Code.

How Picus Helps CI Operators Meet Hong Kong Code of Practice (CoP) Requirements for Computer Systems

CoP v1.0 Section 6.3: Computer-System Security Risk Assessment

“The computer-system security risk assessment should include a vulnerability assessment and a penetration test which, among other steps, identify security and control weaknesses. …” (Section 6.3.4)

How Picus supports this requirement

Section 6.3.4 requires that computer-system security risk assessments include both vulnerability assessments and penetration testing to identify security and control weaknesses.

Picus supports this requirement by continuously validating whether identified vulnerabilities and control gaps are exploitable in practice. Through Adversarial Exposure Validation (AEV), which combines Breach and Attack Simulation (BAS) and automated penetration testing, Picus tests prevention and detection controls against real-world adversary techniques across network, endpoint, cloud, and identity layers.

While vulnerability assessments highlight potential weaknesses and penetration tests demonstrate point-in-time exploitation, Picus extends their value by:

  • Verifying whether vulnerabilities can be leveraged into successful attack paths
  • Testing whether existing security controls block, detect, log, and alert on adversary behavior
  • Providing MITRE ATT&CK–mapped evidence to support structured risk documentation
  • Prioritizing remediation based on validated exploitability and control effectiveness

This enables organizations to transform Section 6.3.4 risk assessments from static findings into continuously validated, evidence-based evaluations of real security posture.

CoP v1.0 Section 6.2.26: Monitoring and Detection

“The CI operator should establish a mechanism to monitor... for detecting anomalies and potential... security incidents.” (Section 6.2.26(a))

“Procedures and processes should be in place to ensure 24 x 7 monitoring and a timely response…” (Section 6.2.26(d))

“Threat intelligence should be... used to assess threat levels and potential impacts to CCSs and appropriate mitigation actions.” (Section 6.2.26(e))

How Picus supports this requirement

Section 6.2.26(a) and (d) require not only the implementation of monitoring mechanisms, but assurance that they effectively detect real threats, support timely response, and remain effective over time.

Picus supports this requirement by executing adversary-emulated attack techniques and measuring how detection technologies such as EDR, XDR, IDS, and SIEM respond. This enables CI operators to validate whether:

  • Malicious behaviors trigger alerts
  • Detection logic accurately identifies adversary techniques
  • Security events are logged correctly
  • Alerts provide sufficient fidelity for investigation and response
  • Visibility gaps exist across the environment

By continuously validating detection controls against real-world TTPs, Picus enables organizations to confirm that 24×7 monitoring mechanisms function as intended and that detection-to-response workflows can operate effectively under live attack conditions.

Section 6.2.26(e) requires translating threat intelligence and attacker methodologies into concrete mitigation actions. Picus converts known and emerging threat intelligence into safely executable attack simulations, allowing operators to verify whether current controls can block or, if prevention fails, detect newly observed attack techniques across the kill chain. The platform also provides ready-to-apply vendor-based and vendor-neutral mitigation content to support timely, evidence-backed remediation.

CoP v1.0 Section 6.2.23: Log Management

“The CI operator should record and identify the events involving CCSs that may lead to a computer-system security incident.” (Section 6.2.23(a))

“Any retained log should provide sufficient information to enable comprehensive audits of the effectiveness and compliance of security measures.” (Section 6.2.23(e))

How Picus supports this requirement

Section 6.2.23 requires logs to be meaningful, investigation-ready, and capable of supporting comprehensive audits of security effectiveness and compliance.

Picus supports this requirement by executing real-world adversary-emulated attack scenarios and analysing logging and detection outcomes across implemented defensive controls. Using Picus Detection Analytics, organisations can determine:

  • Whether relevant log sources are being ingested in a timely manner
  • Whether log data contains sufficient granularity to identify malicious events
  • Which adversary behaviours generate log entries
  • Which techniques trigger alerts and escalation workflows
  • Which behaviours are missed due to visibility gaps
  • Which additional log sources or configurations are required to close coverage gaps

By validating logging under live attack conditions, Picus enables CI operators to confirm that events leading to potential security incidents are properly recorded, identifiable, and correlated. This ensures that retained logs provide sufficient evidence to demonstrate control effectiveness during audits and to support thorough incident investigations, as required by Section 6.2.23.

CoP v1.0 Section 6.2.21 Network Security

“The CI operator should plan and implement adequate network security controls on the CCSs to prevent malicious traffic from accessing the CCS…” (Section 6.2.21(a))

How Picus supports this requirement

Section 6.2.21 requires CI operators to implement layered network security controls, including intrusion detection or prevention at critical nodes, network segmentation based on trust levels, and secure internet access services equipped with filtering, routing control, and intrusion detection capabilities.

Picus supports this requirement by continuously validating whether these network controls function effectively under real-world attack conditions. Through AEV, Picus safely executes network-based attack techniques such as lateral movement, command-and-control communication, exploitation attempts, and data exfiltration behaviors. This enables CI operators to verify whether:

  • Intrusion Detection/Prevention Systems (IDS/IPS) identify and block malicious traffic at critical nodes
  • Network segmentation controls prevent unauthorized east-west movement
  • Firewalls (NGFW, WAFs) and secure email gateways (SEG) enforce intended access control policies
  • Internet-facing services are protected against exploit attempts and C2 callbacks
  • Detection logic captures and logs malicious network behaviors

Rather than relying solely on architecture diagrams or configuration reviews, Picus provides empirical validation of network control performance.

By continuously testing segmentation, filtering, and monitoring mechanisms against ATT&CK-mapped adversary techniques, CI operators can generate objective evidence that network security measures operate effectively, directly supporting the operational intent of Section 6.2.21.

CoP v1.0 Section 6.2.24 Cloud Computing Security

“The CI operator should ensure the computer-system security of CCSs that employ cloud technologies, regardless of the location of the cloud system.” (Section 6.2.24(a))

How Picus supports this requirement

Section 6.2.24 requires CI operators to define cloud security policies, assess and respond to cloud-specific risks, document shared responsibility models with cloud providers, and ensure proper protection and isolation of CI data.

Picus supports this requirement by validating cloud exposures and cloud security control effectiveness in practice.

Through Cloud Security Validation (CSV) and Adversarial Exposure Validation (AEV), Picus safely simulates cloud-based attack techniques across AWS, Azure, and GCP environments, including identity abuse, privilege escalation, misconfiguration exploitation, and data access attempts. This enables CI operators to verify whether:

  • Cloud IAM policies prevent privilege escalation and unauthorized access
  • Misconfigurations can be exploited into meaningful attack paths
  • Cloud-native security controls generate accurate alerts
  • Data isolation mechanisms function as intended
  • Shared responsibility boundaries are properly enforced

Picus complements traditional Cloud Security Posture Management (CSPM) by moving beyond configuration visibility to validated exploitability testing.

By continuously validating cloud controls against real attacker methodologies, CI operators can demonstrate that cloud-hosted CCS components are not only properly configured, but resilient against adversary behavior, directly aligning with the operational requirements of Section 6.2.24.

CoP v1.0 Section 6.5: Security Measures for Operational Technology (OT)

“If conducting a vulnerability assessment or a penetration test could adversely impact the normal functioning of an OT system, the CI operator should use alternative vulnerability identification activities...” (Section 6.5.9)

How Picus supports this requirement

Section 6.5.9 requires the use of alternative vulnerability identification activities where traditional vulnerability assessments or penetration testing may adversely impact OT system operations.

Picus supports this requirement by enabling controlled, production-safe validation at IT–OT boundaries and critical peripheral nodes without relying on intrusive scanning or disruptive testing within sensitive OT environments. By validating segmentation, zoning, access controls, and monitoring mechanisms, Picus allows organisations to assess whether these controls effectively prevent unauthorised access and lateral movement while maintaining normal OT system functionality.

This approach aligns with the intent of Section 6.5.9 by helping CI operators identify control weaknesses in a manner that does not jeopardise the stability or availability of operational technology systems.

CoP v1.0 Section 6.2.7: Computer-System Security Risk Management Approach

“The CI operator should formulate a risk management approach that outlines how computer-system security risks… are identified, assessed, mitigated, and monitored.” (Section 6.2.7(a))

How Picus supports this requirement

Section 6.2.7(a) requires a structured and systematic approach to identifying, assessing, mitigating, and monitoring computer-system security risks.

Picus supports this requirement by validating whether identified risks are truly exploitable within the organisation’s environment. Through Adversarial Exposure Validation (AEV), which combines Breach and Attack Simulation and automated penetration testing, Picus continuously executes adversary-emulated techniques mapped to real-world TTPs to test the effectiveness of existing security controls across prevention and detection layer solutions.

This enables organisations to confirm whether risk assessments reflect real-world exploitability rather than theoretical assumptions, assign evidence-based risk scores using the Picus Exposure Score (PXS), and prioritise mitigation efforts based on validated exposure and potential impact instead of static severity ratings alone.

By grounding risk identification, assessment, mitigation, and monitoring in continuous validation results, the Picus Platform strengthens the overall risk management approach and aligns it with the operational intent of Section 6.2.7(a).

CoP Section 6.2.17: Patch Management

“The CI operator should adopt a risk-based approach to determine a suitable patch management strategy…” (Section 6.2.17(a))

How Picus supports this requirement

Section 6.2.17(a) requires timely patching and a risk-based prioritization strategy.

Picus complements this requirement by validating whether known vulnerabilities are actually exploitable within the CI operator’s environment before remediation decisions are made. By executing adversary-emulated exploit techniques mapped to specific CVEs, Picus determines whether a vulnerability can be successfully exploited against protected assets or whether existing security controls already mitigate the risk.

This validation produces an evidence-based exposure score that reflects real exploitability rather than theoretical severity. As a result, CI operators can:

  • Prioritize patching based on validated exposure and business impact
  • Deprioritize vulnerabilities effectively mitigated by layered controls
  • Focus remediation efforts on vulnerabilities that pose demonstrable risk

After patches are applied, Picus enables revalidation to confirm that exploitation attempts are no longer successful and that remediation actions have measurably reduced exposure.

This transforms patch management from volume-driven remediation to continuous, evidence-backed risk reduction.

CoP Section 6.4: Obligation to Arrange to Carry Out Computer-System Security Audits

“A computer-system security audit should assess whether a CI operator’s computer-system security management plan is implemented and whether the security controls and measures comply with the computer-system security management plan.” (Section 6.4.1)

“The computer-system security audit should verify the proper implementation of existing protection measures for the CCSs…” (Section 6.4.5)

How Picus supports this requirement

Section 6.4 requires independent verification that documented security controls are properly implemented and effective in practice. Picus complements this requirement by providing measurable, adversary-driven validation of control effectiveness. By executing controlled attack scenarios aligned with real-world threat techniques, Picus generates objective evidence (with a detailed report) showing whether security controls:

  • Block exploitation attempts
  • Detect malicious behaviors
  • Generate appropriate logs and alerts
  • Support incident containment workflows

This evidence can support audit preparation by demonstrating that protection measures are not only documented, but tested and validated under simulated attack conditions.

Picus does not replace independent auditors. Rather, it strengthens the audit process by providing continuous, defensible validation data that auditors can reference when assessing the effectiveness and implementation of security controls.

CoP v1.0 Section 7.1: Computer-System Security Drill

“The drill may be conducted in the form of tabletop exercise, functional exercise, simulated attack…” (Section 7.1.3)

How Picus supports this requirement

Section 7.1.3 explicitly permits simulated attacks as a drill mechanism to assess organisational readiness in responding to computer-system security incidents.

Picus supports this requirement by enabling controlled, production-safe adversary emulation aligned with real-world attack techniques. Through continuous execution of adversary-mapped scenarios, Picus exercises monitoring, detection, alerting, and escalation processes under realistic conditions, without disrupting business operations.

This allows organisations to assess whether security controls generate appropriate alerts, whether response teams follow defined procedures, and whether incident workflows function as intended. The platform provides measurable, ATT&CK-mapped validation results that can be used to document drill outcomes, identify improvement areas, and support structured post-drill reviews in accordance with Section 7.1.

CoP v1.0 Section 7.2: Emergency Response Plan – Incident Management

“A CI operator should formulate an emergency response plan…” (Section 7.2.1)
“The post-incident review should incorporate lessons learned to improve future response…” (Section 7.2.3(i))

How Picus supports this requirement

Section 7.2 requires CI operators to establish a formal emergency response plan and ensure that post-incident reviews lead to measurable improvements in future response capability.

Picus supports this requirement by providing continuous, evidence-based validation of the controls and processes that underpin the incident response plan. Through adversary-emulated scenarios aligned with real-world attack techniques observed in the wild, Picus generates objective data on how quickly threats are detected, how effectively controls contain malicious activity, and where procedural gaps exist.

These validated outcomes enable organisations to assess whether documented response procedures are operationally effective and to incorporate concrete findings into post-incident reviews. By grounding improvement efforts in measured control performance and verified exposure, Picus helps ensure that emergency response plans evolve based on tested evidence rather than assumptions.

Achieving Resilient Hong Kong Code of Practice Compliance Through Validation

The Hong Kong CoP is not a one-time audit; it is a commitment to "apply enhanced security measures" commensurate with the risks to our society.

Picus helps CI operators bridge the gap between policy and implementation. By moving to a model of continuous validation, organizations can provide the Commissioner with objective evidence that their critical systems are not just "compliant" on paper, but resilient in practice.

Get your demo to see how Picus can automate your CoP evidence collection today.

References

[1] “Code of Practice Pursuant to the Protection of Critical Infrastructures (Computer Systems) Ordinance, January 2026, Version 1.” Available: https://www.occics.gov.hk/filemanager/en/content_19/CoP_en_v1.0.pdf. [Accessed: Feb. 17, 2026]

Table of Contents

Ready to start? Request a demo