First published in the July/August 2026 edition of Banking Today, the official publication of the Hong Kong Institute of Bankers (HKIB).
The thumbnail description of cybersecurity laws in Hong Kong before 2026 was that there was no cybersecurity law. This unflattering description was technically inaccurate, but it rang true for many industry sectors. The notable exception was the regulatory framework that the Hong Kong Monetary Authority (HKMA) has applied to Authorized Institutions for more than 10 years.
The Protection of Critical Infrastructure (Computer Systems) Ordinance (CI Ordinance) came into force on 1 January 2026. It is the first horizontal cybersecurity legislation in Hong Kong and applies to critical computer systems of designated critical infrastructure operators across a number of sectors, including banking and finance. What, then, has changed for Authorized Institutions under the regulatory oversight of the HKMA?
The position before the CI Ordinance
The cybersecurity of Authorized Institutions has been regulated by the HKMA under its risk-based supervisory framework as a core focus long before the implementation of the CI Ordinance. The regulatory policy and framework were first set out in the Cybersecurity Fortification Initiative which was introduced in 2016 and further enhanced in 2021. The Cybersecurity Fortification Initiative has three core pillars:
• the Cyber Resilience Assessment Framework;
• the Professional Development Programme; and
• the Cyber Intelligence Sharing Platform.
The Cyber-Resilience Assessment Framework (C-RAF) is a comprehensive, structured risk-based framework for banks to assess their risk profiles, and to benchmark the maturity and level of defence and resilience required to protect against cyber-attacks. C-RAF comprises:
a) an inherent risk assessment based on risk factors such as business size, operational characteristics, technology profile, and usage;
b) a maturity assessment for Authorized Institutions to assess whether their cybersecurity controls are commensurate with their inherent risk levels. The maturity assessment covers a number of domains, including:
• governance;
• protection;
• detection;
• response and recovery;
• situational awareness;
• third-party risk management; and
• identification.
c) Intelligence-led Cyber-attack Simulation Testing (iCAST) for Authorized Institutions with “medium” or “high” inherent risk ratings to test their cyber resilience by simulating reallife cyber-attacks.
The C-RAF is not a public document. However, based on other similar public framework documents, the C-RAF will likely include requirements to have internal policies and procedures such as:
• regular reporting to the board or senior management on the status of cybersecurity and business continuity programmes; routine penetration testing and vulnerability scanning;
• annual training and skills development of staff covering the latest cyber threats, issues, and incident response;
• well-defined playbooks for incident response and recovery steps; and
• escalation channels for prompt reporting of cyber events from any level of the organization.
The Professional Development Programme is a local certification scheme and training programme to train cybersecurity practitioners in the banking and information technology industries. The programme has a particular focus on technical capabilities for conducting cyber resilience assessments and simulation testing. The certification scheme recognises the equivalence of qualifications in major overseas jurisdictions.
The Cyber Intelligence Sharing Platform is a commonly shared intelligence platform to help share threat intelligence in the banking sector in respect of cyber-attacks.
The HKMA also facilitates and participates in industry-led cyber-attack simulations to enhance the sector’s collective preparedness against cyber incidents. The most recent example of this was the extreme weather scenario conducted as the Whole Industry Simulation Exercise (WISE) 2025.
Supervisory Policy Manual
The HKMA sets out its general policy in the Supervisory Approach to Cyber Risk Management (Module TM-C-1) of its Supervisory Policy Manual (Cyber Risk Management Guideline). The policy sets out the best practice and advisory standards and minimum regulatory expectations of the HKMA in respect of cyber risk management. The Cyber Risk Management Guideline is supplemented by additional statutory guidelines published in the “Supervisory Policy Manual on Technology Risk Management, Business Continuity, Operational Resilience and Outsourcing”.
The Cyber Risk Management Guideline and its related guidelines require Authorized Institutions to maintain governance arrangements, internal policies and procedures, incident response arrangements, escalation channels, audit, training, and board or senior management reporting. Critically, the Cyber Risk Management Guideline specifically incorporates C-RAF implementation and assessment.
The Cyber Risk Management Guideline is a statutory guideline issued by the HKMA. Statutory guidelines do not themselves have the force of law. However, failure to fulfil its requirements may lead to the HKMA forming the view that the Authorized institution is not meeting the minimum regulatory expectations of the HKMA to satisfy the minimum requirements for authorisation under the Banking Ordinance or other statutory obligations under the Banking Ordinance.
The CI Ordinance
The CI Ordinance came into operation on 1 January 2026. It created a dedicated statutory regime for protecting critical computer systems operated as part of critical infrastructure in Hong Kong. This changed the legal landscape in Hong Kong. Cybersecurity obligations for designated critical infrastructure operators became statutory obligations rather than regulatory expectations under sector-specific guidance.
The CI Ordinance established the Office of the Commissioner of Critical Infrastructure (Computer-system Security) under the Security Bureau (CI Commissioner). The CI Commissioner regulates operators of critical infrastructure in a number of sectors that have been expressly designated as critical for the delivery of essential services in Hong Kong. These sectors include the banking and financial services sector. The statutory obligations are organised into three categories:
1. Organisational obligations. These include maintaining an office in Hong Kong for carrying on its business in Hong Kong; notifying changes to the operator of critical computer systems; and establishing a computer-system security management unit.
2. Preventive obligations. These include notifying material changes to critical computer systems; implementing a computer-system security management plan; and conducting computer-system security risk assessments and computer-system security audits every two years.
3. Reporting and response obligations. These include participating in computer-system security drills conducted by the CI Commissioner; implementing an emergency response plan; and notifying the CI Commissioner of incidents within specified timeframes.
The CI Ordinance designates the HKMA as a “designated competent regulator” to directly supervise the responsibilities relating to organisational and preventive obligations under the CI Ordinance in respect of Authorized Institutions [1] designated by the HKMA as operators of critical infrastructure (CI Operators). The CI Commissioner will retain sole regulatory responsibility and authority for incident reporting and response obligations under the CI Ordinance. The CI Operators must still fulfil sector-specific reporting obligations of the HKMA in addition to the reporting obligations to the CI Commissioner.
Developments after the CI Ordinance effective date
Memorandum of Understanding
The HKMA entered into a Memorandum of Understanding (MoU) with the CI Commissioner on 29 May 2026 to ensure a coordinated approach to implementation work for which the
HKMA is a designated regulator, and to reduce the compliance burden for CI Operators where practicable. The key principles for co-operation under the MoU are:
• The HKMA and the CI Commissioner will notify and consult each other prior to issuing a written direction to a CI Operator for non-compliance with obligations under the CI Ordinance.
• The HKMA and the CI Commissioner will consult each other prior to the issue of or changes of any codes of practice.
• The HKMA and the CI Commissioner will keep each other informed on the designation or revocation of CI Operators and critical computer systems.
• The HKMA will provide assistance to the CI Commissioner regarding the CI Commissioner’s function of monitoring the reporting of computer-system security incidents by CI Operators. This is specifically limited to streamlining compliance by the CI Operators with overlapping obligations under the CI Ordinance and the Banking Ordinance.
• The HKMA will provide assistance to the CI Commissioner to respond to computer-system security threats or incidents in connection with CI Operators, particularly where threats or incidents may impact multiple sectors.
• The HKMA and the CI Commissioner will co-operate with each other in the investigation and prosecution of potential offences committed by CI Operators.
• The CI Commissioner will inform the HKMA prior to performing any function in respect of a specified critical infrastructure regulated by the HKMA.
• The CI Commissioner and the HKMA may share with each other information obtained under the CI Ordinance to avoid making duplicate information requests.
• The CI Commissioner and the HKMA will consult each other in advance on public communications matters relating to their performance of their respective functions under the CI Ordinance to ensure consistency and clarity in public messaging.
The purpose of the MoU is to address the risk of duplication of effort and resources both by regulators and by CI Operators. Inevitably, though, there is an increased compliance burden.
HKMA Sectoral Code of Practice
The CI Commissioner published a General Code of Practice on 1 January 2026 (General Code). On 2 June 2026, the HKMA published a Code of Practice for Authorized Institutions designates as CI Operators (HKMA Code). The HKMA Code is not subsidiary legislation, and failure to comply with its provisions would not in itself constitute an offence. However, the HKMA may issue written directions to require CI Operators to take appropriate actions in relation to compliance with organisational and preventive obligations in the HKMA Code. Failure to comply with those directions would be an offence.
The HKMA Code translates the obligations under the General Code into banking sector implementation expectations. Sometimes, the HKMA clarifies its regulatory expectation. For instance, the HKMA requires separate notification of the office in Hong Kong of the CI Operator of the CI Ordinance, even though the office may have been separately notified under the Banking Ordinance. Also, organisation restructuring and transfer of the banking licence are specifically identified by the HKMA as a change of operator event, and the CI Operator must notify the HKMA of these changes for the purpose of the CI Ordinance. Mostly, the HKMA’s approach is to correlate the obligations in the General Code to existing obligations of the CI Operator under the Supervisory Policy Manual or other HKMA guidance, or under relevant control principles outlined in the applicable C-RAF maturity assessment matrix sub-domain.
The HKMA Code is broadly divided into sections addressing the HKMA designation process, the organisational obligations overseen by the HKMA and the preventive obligations overseen by the HKMA. The HKMA Code expressly excludes reporting and response obligations under the CI Ordinance as the HKMA has no direct regulatory authority to oversee and regulate those obligations under the CI Ordinance. The HKMA also published template notification forms. In practice, CI Operators designated by the HKMA must integrate these new processes into existing HKMA supervisory channels, including their usual supervisory contacts and technology risk teams.
AI cyber threat landscape
A further post-commencement development is the HKMA’s circular on strengthening cyber resilience amid AI-empowered cyber threats, issued on 2 June 2026. This circular highlights the recent emergence of increasingly capable frontier AI models that mark a step change in the global cyber risk landscape, particularly the capacity to independently identify and exploit zero-day vulnerabilities in critical software and infrastructure.
The circular sets out the regulatory expectation of the HKMA for Authorized Institutions generally to review and assess the sufficiency of existing cyber defence controls, improve incident response and recovery capabilities, and enhance data resilience to counter destructive cyber attacks.
The circular also provided an update on the development of the Cyber Resilience Testing Framework (CRTF). This is a new supervisory framework that will provide Authorized Institutions with a systematic method to stress test their ability to respond to and recover from actual “breach” situations. It augments and complements existing cyber initiatives by extending cyber resilience capabilities from detection and prevention-based approaches to those oriented also around response and recovery.
This is an example of a thematic circular from the HKMA that is addressed to all Authorized Institutions, and which is of particular relevance to CI Operators. Notably, the circular was published on the same date as the publication of the HKMA Code.
Concluding thoughts
By the time of implementation of the CI Ordinance, the banking sector had almost 10 years of experience under the Cybersecurity Fortification Initiative of the HKMA. As a consequence, Authorized Institutions were already substantially fulfilling many of the obligations under the CI Ordinance. CI Operators can have cautious optimism that their designation by the HKMA will not cause a seismic shift in either their compliance obligations to the HKMA for organisational and preventive obligations under the CI Ordinance, or in the risk-based approach they adopt based on prior HKMA requirements. It is, in effect, a continuation and evolution of their prior regulatory position.
The most substantial change for CI Operators will be their new response and reporting obligations under the direct regulatory authority of the CI Commissioner [2] These are supplementary to any overlapping obligations that may be owed to the HKMA under sector-specific regulations. This will require a new relationship with a new regulator, and new processes and procedures (and training and awareness) for the relevant notification, reporting, and response obligations. Even so, the CI Operators can expect to be generally well-prepared to meet those obligations. The 12-hour and 48-hour notification obligations to the CI Commissioner are not as onerous as the regulatory expectations of the HKMA for Authorized Institutions. It should be possible to meet and fulfil those obligations concurrently, albeit through different communication channels.
Perhaps the most significant change for CI Operators is less what has happened to date, and more what lies ahead. Hong Kong now has a statutory framework and dedicated regulator for the protection of critical computer systems of CI Operators. We can expect that there will be further specific codes of practice and other guidance and circulars from the CI Commissioner, which will be adapted and adopted by the HKMA as a designated regulator. These are likely to focus on core topics such as services supply-chain risk, artificial intelligence, risk assessment frameworks, and more granular, specific risk controls. We will also learn from enforcement actions brought by the CI Commissioner and from the case law and legal principles that emerge from prosecutions under the CI Ordinance.
The introduction of the CI Ordinance is a significant step forward that improves the security of critical infrastructure necessary for the delivery of essential services in Hong Kong. For the banking sector, that journey had already started, and Authorized Institutions are well aware that there is a long road ahead.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This article is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this article. This article was last reviewed on [14 September 2026].
[1] The designation of the HKMA applies in respect of its role as regulator of Authorized Institutions, stored value facility licensees, and system operators or settlement institutions for designated clearing and settlement or retail payment systems. The primary focus of this article is on Authorized Institutions.
[2] CI Operators will also need to be aware of, and prepared for, the enforcement powers of the CI Commissioner. This is outside the scope of this article.
On 26 May 2026, the Securities and Futures Commission (“SFC”) and the Financial Services and the Treasury Bureau (“FSTB”) published their consultation conclusions on the proposed regulatory regimes for virtual asset (“VA”) advisory service providers (“VA Advisory Regime”) and virtual asset management service providers (“VA Management Regime”). Pádraig Walsh from our Digital Asset and Cryptocurrency practice reviews the key points.
VA advisory services
The SFC and FSTB have expressed their views on the scope of the VA Advisory Regime and the definition of VA advisory services.
Advice concerning acquisition or disposal of VAs only: The proposed scope of the VA Advisory Regime will be limited to advice on VAs only. The regime will not cover technology tools that objectively filter information to assist users to conduct self-directed research without making a recommendation or similar advice. The regime will also exclude advice on securities or derivatives.
Substance over form: The SFC will look at the substance of the activity, not its label, when determining whether an activity constitutes advising on VAs. For instance, advising on VA labelled as pure utility token will not be important if the VA is in substance a payment or governance token that falls within the scope of the statutory definition of VAs.
Technology neutral: VA advisory services using technology such as algorithms and AI Large Language Models (LLMs) will not change the fact that the services are VA advisory services regulated by the VA Advisory Regime.
The respondents generally agreed with the definition and scope of VA advisory services but sought to clarify the boundaries of regulated VA advice and the availability of exclusions.
The SFC and FSTB acknowledged the significance of digital channels and the role of finfluencers in influencing investor behaviour. However, they noted that finfluencers are not unique to the VA sector and are increasingly prevalent in traditional financial markets. The SFC and FSTB will conduct a holistic review of the existing regime for traditional financial products, and then conduct a separate review for the VA Advisory Regime.
VA Management Services
“VA Management Services” include any person who carries on a business in Hong Kong in providing a service of managing a portfolio of VAs for another person. The VA Management Regime will apply to the management of portfolio of VAs where the manager has discretionary power to make investment decisions in respect of the VA portfolio for another person.
The VA Management Regime will largely mirror regulations that apply to Type 9 regulated activity (asset management) (“RA9”) under the SFO:
No minimum threshold: There will be no minimum threshold of VA in a portfolio before the VA Management Regime. This means that the inclusion of VA in a portfolio, however small, will result in a requirement to be licensed for VA Management Services. This approach is consistent with regulatory standards for RA9 activities.
Multiple licences may be required: If a person manages a portfolio consisting of both VAs and traditional investment products referencing VAs, they will need a VA Management Licence under the AMLO and an RA9 Licence under the SFO.
Exception for VA management licensee: A VA Management licensee will not need a separate VA dealing licence if its dealing activities are carried out solely for the purpose of providing VA management services.
Technology neutral: The VA Management Regime is also intended to be technology neutral. The use of technological tools itself will not change the fact that management services are provided in substance.
Regulatory requirements
The SFC applies a general principle of “same activity, same risks, same regulation” to VA activities.
Financial resource requirements: Type 4 regulated activities for advising on securities (“RA4”) and VA advisory services are functionally quite similar. The financial resource requirements to be imposed on VA advisory services will follow those that apply to RA4 licensed corporations. Similarly, the VA Management Regime will largely follow the regulations applicable to RA9 licensed corporations.
No double regulatory capital requirements: Corporations licensed under the corresponding securities licensing regimes (e.g. RA4 or RA9) will not need to double their regulatory capital requirements if they become licensed under the VA Advisory Regime or VA Management Regime.
The FSTB and SFC will finalise the legislative proposal for establishing the licensing regimes for VA advisory and VA management providers under the Anti-Money Laundering and Counter-Terrorist Financing Ordinance (Cap. 615). They expect to introduce a bill to the Legislative Council in 2026.
There will be no transition period after the legislation passes. Firms involved in VA related activities are encouraged to begin preparation for the new VA licensing regimes, if they have not already done so.
Final thoughts
The coverage of Hong Kong’s VA licensing regime is becoming more comprehensive. In December 2025, the SFC and FSTB announced that consultation conclusions on legislative proposals to regulate virtual asset dealers and custodians were complete. Soon, licences for practically the full suite of VA activities will be available in Hong Kong. This will mark a pivotal step in completing Hong Kong’s regulatory framework under the SFC’s ASPIRe roadmap.
Pádraig Walsh and Evelyn Wong
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was published on [6 August 2026].
In January 2024, the Securities and Futures Commission (SFC) set institutional resilience and operational efficiency as one of its four strategic priorities. Since then, the SFC has stepped up its focus on cyber resilience and security as a core regulatory expectation for licensed corporations (LCs), virtual asset service providers (VATPs) and associated entities. In this news update, Pádraig Walsh from our cybersecurity practice reviews a recent SFC circular that sets out the expected regulatory standards of the SFC to respond to the growing threat posed by AI-enabled cyberattacks.[1]
Developments in the risk environment
Cybersecurity incidents in Hong Kong have been trending upwards for a number of years. 2025 saw a significant uptick in that trend. According to the HKCERT, the number of cybersecurity incidents increased to 15,877 in 2025 from 12,536 in 2024, representing a 27% year-on-year increase. HKCERT identified AI-driven attacks and agentic AI risks at the top of its five cybersecurity risks for 2026, and included AI-related issues among three of that top five.
AI has marked a step change in the pace, sophistication and effectiveness of cyberattacks. The SFC highlighted in particular:
AI is increasing the sophistication, scale and frequency of cyberattacks: Frontier AI models can plan and execute more complex multi-step actions autonomously. The spread of AI-enabled tools lowers the technical barrier for threat actors to execute malicious activities. AI-enabled tools also enable the execution of those activities with a higher degree of sophistication. This is evident, for instance, in attack vectors such as phishing and deepfake impersonation. LCs and VATPs need to reassess existing prevention, detection, response and recovery measures.
Reduced response time for remediation: AI-enabled tools have led to the rapid identification and exploitation of new vulnerabilities. The period between disclosure of a vulnerability and active exploitation is also becoming shorter. LCs and VATPs must enhance patching and vulnerability management procedures.
Regulatory expectations
The SFC has made it clear that senior management remains ultimately responsible for cybersecurity risk management. This includes the Manager-in-Charge of Information Technology (MIC-IT). It is a core responsibility of the MIC-IT to review the cybersecurity framework of the firm in question, and to review, approve and properly implement cybersecurity enhancements. The key focus should be to ensure the firm’s cybersecurity frameworks remain appropriate and effective in preventing, detecting, responding to and recovering from evolving threats.
As a general foundational principle, the SFC expects firms to maintain robust and up-to-date security controls to protect systems, client information and client assets. Firms should maintain a comprehensive and dynamic inventory of technology assets, including hardware, software, databases, cloud services and network infrastructure. Firms should also identify which assets are externally exposed, business-critical or dependent on third-party components or providers.
The circular identifies five key areas for consideration:
Patching and vulnerability management: Firms should review and strengthen patch management processes. The processes should address known vulnerabilities promptly and implement procedures for urgent and critical patches outside normal maintenance cycles.
Access and privilege controls: Firms should adopt a “zero trust” mindset. This is a design principle under which network access is not implicitly trusted based solely on network location or user status. Firms should implement robust access and privilege controls and minimise attack surfaces. This means applying least-privilege access controls, enhanced firewall protection and stronger network segmentation, among other measures.
Detection and monitoring: Firms should strengthen threat detection, system monitoring and threat intelligence capabilities.
Supply chain risk management: Firms should strengthen their supply chain risk governance framework, enhance initial and ongoing assessments of third party service providers, and prioritise potential impact from third party service providers to critical operations and business critical components.
Incident response and recovery: The SFC expects firms to review and enhance incident response procedures and contingency plans. Firms should establish swifter adequate escalation and reporting procedures to take account of the swifter pace of AI-enable attacks. Firms should consider pre-planned containment strategies, including the ability to block malicious activities, isolate affected systems and restrict access rapidly. Firms should back up records, databases, and supporting documents on a regular basis, and ensure the swift availability of the backup copies when needed.
Firms should review incident handling procedures and response plans to ensure:
(a) the roles and responsibilities for personnel involved in the incident response;
(b) the escalation protocols to facilitate coordinated efforts across teams, including IT, risk management, compliance, and senior management;
(c) the pre-authorised containment actions that should be immediately implemented;
(d) the actions required for the recovery of the firm’s operations and business continuity; and
(e) the communication strategies with stakeholders, including clients, third party service providers, law enforcement agencies, and the SFC.
The SFC has highlighted that firms must regularly test their incident handling procedures and contingency plans through tabletop exercises and simulated attacks to assess their effectiveness. This often requires the engagement of professionals with specialist knowledge and experience. This can supplement tabletop exercises or crisis simulations. Also, external expertise is often needed for the conduct of VAPT assessments and red team exercises.
LCs and VATPs are required to report immediately to the SFC upon any material failure, error, or defect in the operation or functioning of their trading, custody, accounting, clearing, or settlement platforms, systems or equipment. This includes any material cybersecurity incident. Firms need to be equipped and prepared to make accurate and appropriate notifications.
Final thoughts
Tremendous opportunities are being realised and developed from the use of AI and AI language models by LCs and VATPs. Just as those opportunities exist for firms and users that adopt responsible and safe use of AI, they also exist for criminals and dangerous threat actors in the cyber world. The SFC circular recognises that AI-enabled tools have now created a substantially more dangerous cyber risk environment.
The SFC circular substantially raises supervisory expectations regarding cyber resilience in an AI-driven threat environment. Licensed firms should not view AI risk solely as a governance or technology adoption issue. The SFC now clearly expects firms to take account of the enhanced threat AI-enabled tools represent in their cybersecurity frameworks and ongoing compliance.
This escalated concern is not a surprise. Financial services is a critical sector of the economy. Cyber resilience is a stated core target area for the SFC. The SFC is more regularly publishing guidance on cyber risk and AI risk. There is SFC 2024 circular on use of generative AI language models. Also, we recently reviewed the SFC circular on implementing authentication methods to mitigate hacking risks from phishing attacks and monitoring measures to identify suspicious activities (see our article on this link).
This is a circular of critical importance to MIC-ITs in LCs and VAPTs. Senior management and MIC-ITs are accountable for cybersecurity preparedness and implementation. Many firms will require additional budget to allocate sufficient resources to meet the expected regulatory standards. There will be a need to external support in training, awareness and readiness for incident response, and in reviewing incident response and business continuity plans to ensure they are fit for purpose.
Cyber resilience against AI-enabled cyber attacks is at the Board table.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was published on [4 August 2026].
[1] SFC Circular, Enhanced cybersecurity measures to address evolving risks arising from artificial intelligence-enabled cyberattacks, 2 June 2026 [link]
The Securities and Futures Commission (SFC) has issued a circular on 9 July 2026 setting out enhanced expectations for internet brokers and SFC-licensed virtual asset service providers (VASPs) in relation to client account protection, phishing-resistant authentication and surveillance of suspicious account activities [link]. In this update, Pádraig Walsh from our Cybersecurity practice looks at the SFC’s latest expectations and the practical implications for licensed firms operating internet trading or virtual asset platforms.
Background
Phishing remains a significant cybersecurity risk in Hong Kong. The SFC noted that phishing continued to be the most common type of reported cybersecurity incident in Hong Kong, and that in 2025 fraudsters carried out large-scale SMS phishing campaigns targeting clients of internet brokers and VASPs. The attacks involved malicious links impersonating brokers and purported requests from regulators or government bodies, with clients being induced to enter login credentials and one-time passwords (OTPs) on fake websites.
The SFC’s concern is clear. If authentication credentials can be intercepted, threat actors can gain access to compromised client accounts and conduct unauthorised transactions. The new circular is directed at authentication standards. It also sets out a broader control framework covering prevention, detection, response and client education.
Robust authentication: from OTPs to phishing-resistant controls
The central message of the circular is that internet brokers and VASPs should adopt strong and phishing-resistant authentication solutions for client login and device binding, rather than merely OTPs. The appendix to the circular provides detailed examples of authentication methods that the SFC regards as acceptable and sets out the standards expected for their implementation.
Passkeys
Passkeys are password-less credentials based on public-key cryptography. The authentication credential remains on the client’s device, hardware security key or passkey manager. Only a corresponding public key used by the firm can verify authentication requests. This significantly reduces the risk of account takeover arising from stolen passwords or intercepted authentication codes.
Importantly, the SFC also sets out implementation expectations. Firms should ensure passkey solutions are appropriately certified, make passkey registration subject to strong identity verification procedures, and maintain controls governing the recovery, replacement and revocation of passkeys where devices or passkey managers are lost or compromised.
Device binding
Device binding creates a secure association between a client’s account and a registered device so that login requests can be verified as originating from an authorised device. Device binding can become vulnerable when it is established using weak methods such as passwords and OTPs.
The appendix to the circular provides examples of acceptable approaches. These include using an existing passkey to authenticate a new device, biometric verification against facial data collected during onboarding, and in-person identity verification at the firm’s offices.
Monitoring, client notifications and incident response
The circular makes clear that authentication controls alone are not sufficient. Internet brokers and VASPs should promptly notify clients of successful logins and other high-risk account activities. These include logins from new devices, new device binding and the creation or revocation of passkeys. They are also strongly encouraged to require client confirmation before further transactions are permitted following certain material changes or unusual account activities.
Firms should implement effective monitoring and surveillance measures to identify suspicious login activity and abnormal trading activities. These measures include predefined thresholds and red flags based on a client’s profile, trading behaviour, account activity, device usage and login patterns. The SFC gives examples such as transactions inconsistent with previous trading patterns, unusually large numbers of transactions in illiquid or small-cap stocks, and unusual transactions shortly after a password reset, change in contact details or new device binding.
If a hacking incident occurs, firms should have procedures to halt unauthorised activities, safeguard client assets, notify affected clients and prevent further compromise. Firms must conduct root cause analysis, maintain detailed incident reports and implement remedial measures.
Hacking incidents should also be reported to the SFC immediately. The SFC makes it clear that a hacking incident reaches the notification standard of a material failure, error or defect in the operation or functioning of systems or equipment under the SFC Licenced Persons Code of Conduct and the VATP Guidelines.
Implementation timeline
The SFC expects firms to review and enhance client notification, monitoring, surveillance, response and reporting procedures immediately. Robust authentication solutions should be implemented as soon as practicable and no later than 8 July 2027. Large internet brokers are expected to implement these solutions immediately.
During the implementation period, firms should incorporate robust authentication methods into their internet trading systems, ensure adequate testing before deployment, roll out the methods to all clients as soon as practicable, and communicate the changes with appropriate guidance and support.
Management responsibility
The circular is also a regulatory reminder to senior management. The SFC states that senior management are ultimately responsible for overseeing implementation of the enhancements and ensuring client accounts are properly protected. This applies in particular to the Manager-in-Charge of Overall Management and Oversight and the Manager-in-Charge of Information Technology.
The SFC also warns that if an internet broker or VASP fails to implement adequate measures to prevent, detect and stop large-scale unauthorised transactions conducted through hacked client accounts, the SFC will hold the relevant firm accountable for losses suffered by clients.
Key takeaways
Phishing attacks are on the rise. According to the latest statistics from HKCERT, a total of 15,877 cybersecurity incidents were reported in 2025, marking a new record high. Among them, phishing attacks remained the most prominent threat, accounting for nearly 60% of total cases. The rise of generative AI has made phishing messages increasingly realistic and harder to detect. This further increases the associated risks. The virtual world is a scary place.
The circular is a timely reminder that cybersecurity controls are now a front-line regulatory issue for internet brokers and virtual asset platforms. Firms should not treat authentication upgrades as a purely technical project. The SFC expects an integrated framework covering phishing-resistant login controls, device-binding governance, transaction surveillance, client alerts, incident response and ongoing client education.
Pádraig Walsh and Christie Yau
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was published on 16 July 2026.
In this news update, Pádraig Walsh from our Data Privacy practice looks at a recent investigation report by the Hong Kong Office of the Privacy Commissioner for Personal Data (PCPD) into the wrongful disclosure of personal data in April 2025 through sample forms by an airline company. The heart of the findings provides a salutary reminder of the importance of training and awareness programmes in data privacy management.
What happened
An airline passenger complained to the PCPD that the personal data of two other passengers and two related persons were disclosed to him through sample forms attached to an email sent by a ground service agent of an airline company stationed in Phu Quoc in Vietnam.
This arose when the passenger claimed compensation from the airline company for delayed baggage for a flight from Hong Kong to Vietnam. The ground service agent in Phu Quoc requested the passenger by email to complete the required forms for settlement of the claim, and attached two sample forms to the email. The sample forms contained the personal data of two passengers and two related persons, including names, flight details and bank account details.
Upon being notified of the incident, the airline company instructed the ground service agent the next day to stop sharing and attaching personal data of passengers, and directed the ground service agent to require its staff to attend briefing and training sessions.
The conduct of the ground service agent involved a breach of the Ground Operations Manual of the airline company. The PCPD investigated the complaint.
PCPD findings and decision
The key findings of the PCPD were that the key contributing factors to the data breach were that the airline company:
1. failed to take effective measures to raise the awareness of the staff members of the ground service agent of personal data privacy requirements in the Ground Operations Manual;
2. failed to provide sufficient and regular training to staff members of the ground service agent; and
3. failed to monitor the performance of ground handling agents.
The PCPD found that the airline company had not taken all practicable steps to ensure that the personal data involved was protected against unauthorised or accidental access, processing, erasure, loss or use, and the airline company had contravened DPP 4(1) of the Personal Data (Privacy) Ordinance concerning the security of personal data. The PCPD served an Enforcement Notice on the airline company, directing it to take measures to remedy the contravention and to prevent recurrence of similar contraventions in future.
Lessons to learn
This investigation and enforcement action is all about failure in training and awareness programmes. The Ground Operations Manual had adequate provisions to deal with personal data management in the circumstances of this case. The person on the ground was not aware of the provisions. Here it did not matter that the person on the ground was in Vietnam. The ground service agent acted under the control and authority of the airline company in Hong Kong. It was a data processor of the Hong Kong data user. So, it was the obligation of the airline company to train and elevate awareness of the ground service agent of privacy requirements under Hong Kong law.
Privacy policies and procedures are not documents to be kept on the shelf. They are the operational steps people in an organisation must follow to implement effective privacy management. You need to be aware of a process before you can follow it. Training is the key to unlock this awareness.
An organisation does not rise to the level of its aspiration, it falls to the level of its training. This key message is a core tenet of privacy management programmes. Training and awareness programmes are the key driver to ensuring organisational and human behaviour implements well-designed policies, programmes and processes. We, at Tanner De Witt, provide organisation training to elevate privacy awareness and breach response readiness. Speak to us. We can help.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was last reviewed on 29 April 2026.
The Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) came into force in Hong Kong on 1 January 2026. This is the first substantial horizontal cybersecurity legislation in Hong Kong. We are exploring the scope and impact of this legislation in a series of articles, focusing in a Q&A format on the key issues businesses and industries need to be aware of. This article and our previous articles are now available here, here, here,here and here.
In this final article in the series, Pádraig Walsh from our Cybersecurity practice reviews the investigation, inspection and enforcement powers available to the CICS Commissioner under PCICSO.
13. Enforcement powers
13.1 Does the CICS Commissioner have investigation and enforcement powers?
Yes. The investigation and enforcement powers of the CICS Commissioner under PCICSO include powers to:
(a) direct the CI Operator to perform or prohibit certain acts;
(b) require the CI Operator to produce relevant information and documents;
(c) enter premises of a CI Operator with a warrant; and
(d) enter premises of a CI Operator without a warrant in emergency cases.
13.2 Does the CICS Commissioner have powers of early intervention toconduct an enquiry?
The CICS Commissioner has the power to appoint an authorised officer to make enquiries into an event if the CICS Commissioner believes the event has had actual adverse effect, or is likely to have an adverse effect, on the CCS of a critical infrastructure. The scope of the inquiry is directed to identifying what caused the event and whether a computer-system security threat or a computer-system security incident has occurred in respect of the CCS.
This early intervention power to investigate is specifically characterised as investigating events that are not, or not yet, characterised as computer-system security incidents. The purpose is to obtain additional information to assess the event. The scope of the enquiry may be extended if the early intervention investigations confirm a computer-system security threat or incident with an adverse effect has occurred.
13.3 Is a CI Operator required to produce documents, information and statements to the CICS Commissioner in early intervention enquiries?
The authorised officer appointed by the CICS Commissioner for an early intervention investigation has the power by notice to require a CI Operator to:
(a) produce documents the authorised officer reasonably believes to be relevant to his inquiries, and to be in the possession or control of the CI Operator or accessible in or from Hong Kong by the CI Operator;
(b) give an explanation or further particulars in relation to the documents;
(c) send a representative to attend before the authorised officer to answer questions relating to the enquiry; and
(d) answer in writing written questions relating to the enquiry.
Failure to comply with a notice by the authorised officer when required is an offence.
13.4 Does the CICS Commissioner have powers toconduct a direct investigation in relation to a computer-system security threat or incident?
Yes. The CICS Commissioner has the power to appoint an authorised officer to carry out an investigation into, and to respect to, a computer-system security threat or incident. The investigation will be directed to:
(a) identify what caused the threat or incident;
(b) assess the impact, or potential impact, of the threat or incident;
(c) remedy harm that has arisen from the threat or incident;
(d) prevent any further harm from arising from the threat or incident; and
(e) prevent any further computer-system security incident from arising from the threat or incident.
13.5 Is a CI Operator required to produce documents, information and statements to the CICS Commissioner in relation to direct investigation of a computer-system security threat or incident?
The authorised officer appointed by the CICS Commissioner for an investigation has the power by notice to require a CI Operator to:
(a) produce documents the authorised officer reasonably believes to be relevant to his investigation, and to be in the possession or control of the CI Operator or accessible in or from Hong Kong by the CI Operator;
(b) give an explanation or further particulars in relation to the documents;
(c) send a representative to attend before the authorised officer to answer questions relating to the investigation; and
(d) answer in writing written questions relating to the investigation.
Failure to comply with a notice by the authorised officer when required is an offence.
13.6 Can the CICS Commissioner compel the CI Operator to take direct action in the course of the direct investigation?
The CICS Commissioner can additionally authorise its authorised officer to require the CI Operator to take specific actions. This additional authorisation would only arise and be granted if the CI Operator is unwilling or unable to take reasonable steps to assist in the investigation or respond to the threat or incident, and there are public interest grounds for granting the additional authority. Public interest grounds would include the potential harm or disruption that may be caused by the threat or incident.
13.7 What direct action could be required of the CI Operator?
Upon being granted the additional authority by the CICS Commissioner, the authorised officer could require the CI operator:
(a) not to use the investigated system;
(b) to preserve the state of the system;
(c) to monitor the system;
(d) to perform a scan of the system to detect vulnerabilities and assess the impact of the threat or incident in respect of the system;
(e) to carry out any remedial measures, or to cease carrying on any activities, in relation to the threat or incident; and
(f) to give the authorised officer other assistance.
13.9 Is a third party who is not the CI Operator required to produce documents or comply with directions of the CICS Commissioner in respect of a direct investigation?
Yes, but only if and after certain due process conditions are fulfilled.
The authorised officer for the investigation may apply to a Magistrate for a warrant to provide documents and information, make statements and perform actions. The authorised officer must confirm on oath that there are reasonable grounds to believe that the CI Operator is unwilling or unable to assist the investigation or respond to the threat or incident, and there are public interest grounds for granting the requested warrant. The warrant can only be directed to an organisation having, or appearing to have, control over the investigated system (other than the investigated CI Operator).
The warrant will authorise the authorised officer of the CICS Commissioner to require the third party to provide documents and information, make statements and perform actions to the same extent as may be required of a CI Operator.
13.10 Can the CICS Commissioner enter premises of the CI Operator to obtain documents and information for early intervention enquiries and direct investigations?
Yes, but only if and after certain due process conditions are fulfilled.
The authorised officer for the enquiry may apply to a Magistrate for a warrant to enter premises and seize documents. The authorised officer must confirm on oath that there are reasonable grounds to suspect that there are, or are likely to be, documents relevant to his inquiries or investigations on the premises in question. In addition, the Magistrate must be satisfied that the CI Operator is unwilling or unable to take all reasonable steps to respond to the inquiries or investigations of the authorised officer or to the threat or incident, and it is in the public interest to issue the warrant. Exceptions to this process can apply in emergency situations.
The warrant will authorise the authorised officer of the CICS Commissioner to enter the specified premises, if necessary by force, and to search for, inspect, make copies of, take extracts from, seize and remove documents relevant to the enquiries of the authorised officer. This power applies to both early intervention enquiries and direct investigations.
Additionally, for direct investigations, the authorised officer of the CICS Commissioner can be authorised to:
(a) access, inspect and carry out remedial measures on the accessible systems relevant to the investigation;
(b) search for, inspect, make copies of and take extracts from any information stored in accessible systems if the officer has reasonable grounds to believe the information is relevant to the investigation;
(c) carry out other remedial measures in relation to the threat or incident; and
(d) require other assistance from an organisation having, or appearing to have, control over the investigated system.
The warrant can apply in respect of any premises, and not merely premises owner or occupied by the CI Operator.
13.11 Can the CICS Commissioner enter premises without a warrant in emergency situations?
Yes, this is possible in exceptional emergency situations.
The normal conditions and considerations for seeking a Magistrate’s warrant must be fulfilled. Additionally, the CICS Commissioner must be satisfied that it is not reasonably practicable to obtain a warrant. Then, the CICS Commissioner may authorise the authorised officer to enter any premises in emergencies without a warrant to search for and seize relevant items, access and inspect the investigated system to carry out remedial measures, search for, inspect and make copies of information relating to the investigated system, and require relevant organisations to assist in the investigation or respond to the threat or incident.
13.12 Is the CI Operator required to implement directions of the CICS Commissioner in the course of an investigation?
Failing to comply with specified requirements imposed by the CICS Commissioner in response to computer-system security threats and incidents without reasonable excuse is an offence for which a fine of up to HK$500,000 may be imposed.
13.13 How will the CICS Commissioner’s powers apply in respect of operations of the CCS that are conducted outside Hong Kong?
The CI Operator is required to submit information accessible to them in or from Hong Kong in compliance with a request made by the CICS Commissioner under PCICSO.
13.14 Will employees of CI Operators be personally liable for offences under PCICSO?
No. PCICSO itself only imposes penalties on CI Operators on an organisation basis, and those penalties are fines only.
Criminal liability under other legislation may still apply.
13.15 Will a CI Operator be required to provide documents or information subject to legal professional privilege?
No, a CI Operator will not be required to provide documents or information subject to legal professional privilege. PCICSO provides that any claims, rights or entitlements on the ground of legal professional privilege are not affected by PCICSO.
13.16 What defences are available to defendants in prosecutions under PCICSO?
PCICSO provides a defendant a statutory defence that arises if the defendant exercised proper due diligence to avoid the commission of the offence. This will require the defendant to produce sufficient evidence that the commission of the offence was due to a cause beyond the defendant’s control, and the defendant took all reasonable precautions and exercised all due diligence to avoid the commission of the offence by the defendant.
If this due diligence defence is based on the commission of the offence being due to the act of another person or reliance on information given by another person, then the defendant must:
(a) identify that other person;
(b) take reasonable steps to secure the co-operation of the other person; and
(c) establish it was reasonable to rely on the information provided by the person.
A defence of reasonable excuse may also apply in respect of some offences under PCICSO.
14. Other relevant matters
14.1 Will service providers to CI Operators be directly responsible to the CICS Commissioner for services in respect of CCS?
CI Operators can outsource their work, but not their responsibilities. The Code of Practice makes clear that a CI Operator must maintain an agreed level of CCS security within supplier relationships to ensure that all suppliers adhere to a defined set of computer-system security requirements. This includes:
(a) defining security responsibilities of service providers in contract terms;
(b) having and exercising audit and compliance monitoring rights to verify that service providers have implemented sufficient controls over its CCS;
(c) putting in place retention and deletion protocols to ensure all sensitive digital data in service provider services or facilities is deleted at the expiry or termination of the service or upon request of the CI Operator;
(d) entering into confidentiality and non-disclosure agreements with service providers to protect the sensitive digital data; and
(e) undertaking and providing training in respect of CCS subject to the service delivery.
Sample contract clauses are set out in Annex H to the Code of Practice.
14.2 Does PCICSO have extra-territorial effect outside Hong Kong?
No. There is no power under PCICSO to directly take enforcement actions outside Hong Kong against or in respect of computer systems located outside Hong Kong.
There are indirect extra-territorial implications under PCICSO. CI Operators are required to produce information relevant to the security of their CCS that is accessible in or from Hong Kong, regardless of whether that information or the server it is stored on is physically located outside Hong Kong.
Investigation, inspection and enforcement powers are a necessary and important part of any regulatory framework. The CICS Commissioner has broad powers, which must be exercised with conventional due process safeguards. The particular nature of critical infrastructure means that there must be a statutory power to step in and take control if a CI Operator refuses or neglects to do so. Critical infrastructure is, by definition, necessary for the proper functioning of the Hong Kong economy and society.
This concludes our review of this important new legislation for Hong Kong. You may review the entire series here.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was last reviewed on 21 April 2026.
The Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) came into force in Hong Kong on 1 January 2026. This is the first substantial horizontal cybersecurity legislation in Hong Kong. We are exploring the scope and impact of this legislation in a series of articles, focusing in a Q&A format on the key issues businesses and industries need to be aware of. Our previous articles in the series are available on here, here, here, and here.
In this article, Pádraig Walsh from our Cybersecurity practice reviews the strict reporting and notification to the CICS Commissioner under PCICSO.
12. Incident Response Obligations: Incident notice and reporting obligations
12.1 What is the basic obligation of the CI Operator in respect of notification and reporting of security incidents?
The basic obligation of the CI Operator is to notify and report a computer system security incident to the CICS Commissioner if it becomes aware of the security incident.
12.2 What is the policy purpose of computer-system security incident notification?
The policy purpose is to enable the CICS Commissioner to assess the overall consequences of the computer-system security incident. The CICS Commissioner will assess the consequences for the provision of essential services in different sectors, or for the maintenance of critical societal or economic activities in Hong Kong. The CICS Commissioner will then assess and take appropriate remedial measures to prevent the impact from spreading to other sectors.
12.3 What is a notifiable computer-system security incident?
All computer-system security incidents are notifiable. A computer-system security incident is an event that:
(a) involves unauthorised access to the CCS or any other unauthorised act on or through the CCS or another computer system; and
(b) has an actual adverse effect on the computer-system security of the CCS.
12.4 What are examples of notifiable computer-system security incidents?
Examples of notifiable computer-system security incidents are:
(a) large-scale or volumetric distributed denial of service (“DDoS”) attack causing degradation of an essential service;
(b) ransom DDoS attack where a ransom note is received;
(c) ransomware attack that causes suspension of an essential service or shows signs of data compromise;
(d) unintended external connection to a CCS caused by malware infection or by an adversary exploiting a vulnerability;
(e) an employee or other insider accesses sensitive digital data of a CCS and maliciously exfiltrates that data or maliciously misconfigures the access privilege of the CCS;
(f) configurations or data of a CCS are modified by a malicious payload or script;
(g) an employee or other insider abuses his authority to interfere with the functioning of the CCS; and
(h) any tampering with cryptographic key management devices that hampers the normal functioning of a CCS.
12.5 What is a notifiable serious computer-system security incident?
A notifiable serious security incident is a computer-system security incident which has disrupted, is disrupting or is likely to disrupt the core function of the critical infrastructure concerned. The timelines for notifying a serious security incident are shorter.
12.6 How can a CI Operator assess if a notifiable computer-system security incident is also a serious security incident?
A computer-system security incident is considered as a serious incident if:
(a) the downtime affecting the core function of the critical infrastructure concerned has exceeded or is likely to exceed the maximum tolerable downtime prescribed in the business continuity management plan of the CI Operator;
(b) the service performance has dropped or is likely to drop below the minimum service level prescribed in the business continuity management plan of the CI Operator;
(c) the incident has triggered or is likely to trigger the activation of business continuity or disaster recovery procedures;
(d) the incident has caused or is likely to cause the leakage of material volume of customer data according to volumes prescribed in the business continuity management plan of the CI Operator;
(e) the incident has leaked or is likely to leak sensitive digital data that hampers the normal functioning of the CCS;
(f) the incident has caused or is likely to cause a material number of customer enquiries or complaints according to numbers and volume prescribed in the business continuity management plan of the CI Operator; or
(g) threat actors have threatened to launch an attack against a CCS at a specified time that would likely trigger any of these scenarios.
12.7 Are all incidents causing adverse impacts to CCS notifiable?
No. Examples of incidents that would not be notifiable include:
(a) an event arising from pure technical failure;
(b) natural disaster;
(c) mass power outage;
(d) a computer-system security threat that is detected and timely removed or quarantined; or
(e) personal data leakage arising from human mistake.
12.8 What is the timeline for notifying a computer-system security incident?
The CI Operator must notify the CICS Commissioner as soon as practicable after becoming aware of a serious computer-system security incident, and no later than 48 hours after becoming aware. The timelines are shorter for a serious computer-system security incident.
Failure to give notice when required is an offence.
12.9 What is the timeline for notifying a serious computer-system security incident?
The CI Operator must notify the CICS Commissioner as soon as practicable after becoming aware of a serious computer-system security incident, and no later than 12 hours after becoming aware.
Failure to give notice when required is an offence.
12.10 When will a CI Operator be considered to have become aware of a computer-system security incident?
The CICS Commissioner accepts that, once signs of disruption or irregularity are noticed in a CCS, then a short period of investigation is needed to confirm whether a computer-system security incident. Once the CI Operator has a reasonable degree of certainty that a computer-system security incident has occurred, the CI Operator will be deemed to have become aware of the computer-system security incident.
12.11 How is the notification made?
The CICS Commissioner has published a prescribed form [link] that must be used by the CI Operator to notify the CICS Commissioner of a computer-system security incident. The CI Operator should complete the form as far as practicable based on the information available, and submit the form through a designated secured channel.
The CI Operator may first make the notification to a designated telephone number. If the initial notification is not in the prescribed notice form of the CICS Commissioner, then the CI Operator must complete and submit the prescribed notice form to the CICS Commissioner within 48 hours of the initial notification.
12.12 What information is required under the prescribed notice form?
The prescribed notice form requires information on:
(a) name of the CI Operator;
(b) CCS affected;
(c) assessment of seriousness of the incident;
(d) nature of the incident;
(e) time of the identifying the incident, and becoming aware of it;
(f) summary of key incident points; and
(g) details of the reporting party.
If the initial notification is by call to a designated number, then the information required is:
(a) the nature of the computer-system security incident;
(b) the CCSs involved; and
(c) the key summary points of the incident.
In this case, the prescribed notice form must be submitted within 48 hours of the call.
12.13 What is the timeline for providing a report to the CICS Commissioner on a computer-system security incident?
The CI Operator must submit a report to the CICS Commissioner in respect of the computer-system security incident within 14 days after the date on which the CI Operator became aware of the incident.
Failure to submit a report when required is an offence.
12.14 What is the process to submit a report the CICS Commissioner in respect of a computer-system security incident?
The CICS Commissioner has published a prescribed form for the purpose of submitting a report in respect of a computer-system security incident [link].
12.15 What information is required under the prescribed report form?
The prescribed report form requires information on:
(a) name of the CI Operator;
(b) details and physical location of CCS affected;
(c) nature and details of the incident;
(d) point of intrusion;
(e) root cause analysis;
(f) time of the identifying the incident, and becoming aware of it;
(g) method and means of identification of incident
(h) details of vulnerabilities found;
(i) impact assessment, including scope of impact, operational and service impact, data impact, customer/third party impact, and financial impact;
(j) duration of disruption;
(k) response actions, current status summary and future actions with timelines;
(l) details of third party service providers engaged to support;
(m) stakeholder communications, including to media; and
(n) details of the reporting party.
12.14 Is the report to the CICS Commissioner intended to be a final report?
No. The CI Operator is expected to promptly provide a supplementary report or material to the CICS Commissioner if additional information becomes available after submitting the written report.
12.15 Is the CI Operator required to make other notifications and reports in respect of a computer-system security incident?
The notice and reporting obligations under PCICSO are without prejudice to notice and reporting obligations under sector-specific regulations. So, if other applicable laws or regulations impose notification and reporting obligations on the CI Operator, then the CI Operator will need to additionally fulfil those obligations and cannot rely on its notification and report to the CICS Commissioner.
Examples of other sector specific notice obligations include:
(a) Banking sector: There is a duty on authorised institutions to notify the Monetary Authority when they become aware that a significant incident, IT-related fraud or a major security breach has occurred. There is also a specific obligation to notify affected customers, and make public announcements if necessary.
(b) Insurance sector: There is a duty on insurers, upon detection of a relevant cyber incident, to report the incident with the related information to the Insurance Authority as soon as practicable, and in any event within 72 hours from detection.
(c) Financial services sector: There is a duty on licensed corporations to report to the Securities and Futures Commission upon the happening of any material cybersecurity incident (including ransomware attacks) or any material failure, error or defect in the operation or functioning of trading, accounting, clearing or settlement systems or equipment.
12 hours and 48 hours. These are the timelines that CISOs leading CSS Management Units will be acutely mindful of. Notification obligations are the core emergency legal requirement under PCICSO. However, CI Operators must be mindful that it will not be possible to fully and accurately provide the information required for notifications unless the organisational and preventative obligations have also been rigorously followed. It is the exacting process of preparing plans, assessments and audits, and conducting training and drills, that provides the resources, information and expertise to make accurate complete notifications within the exceptionally short timelines required under PCICSO.
In our final article in this series, we will review the enforcement powers of the CICS Commissioner under PCICSO.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was last reviewed on 16 April 2026.
The Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) came into force in Hong Kong on 1 January 2026. This is the first substantial horizontal cybersecurity legislation in Hong Kong. We are exploring the scope and impact of this legislation in a series of articles, focusing in a Q&A format on the key issues businesses and industries need to be aware of. Our previous articles in the series are available on here, here, here and here.
In this article, Pádraig Walsh from our Cybersecurity practice reviews the reporting and response obligations in respect of security drills led by the Commissioner of Critical Infrastructure (Computer-system Security) and maintaining a detailed emergency response plan.
9. IncidentReporting and Response Obligations
9.1 What is a computer-system security incident?
A computer-system security incident is an event that:
(a) involves unauthorised access to the CCS or any other unauthorised act on or through the CCS or another computer system; and
(b) has an actual adverse effect on the computer-system security of the CCS.
9.2 What is the main purpose of the incident reporting and response obligations of CI Operators?
The main purpose of incident reporting and response obligations of CI Operators under PCICSO is to ensure CI Operators respond to incidents and recover CCS promptly.
9.3 What are the main incident reporting and response obligations of CI Operators?
The main incident reporting and response obligations of CI Operators are to:
(a) participate in a computer-system security drill required by the CICS Commissioner;
(b) submit and implement a computer-system security incident emergency response plan; and
(c) notify computer-system security incidents to the CICS Commissioner.
9.4 What is the role of the designated regulators in respect of incident reporting and response obligations under PCICSO?
There is no primary role for the designated regulators in respect of incident reporting and response obligations under PCICSO. The CICS Commissioner will perform those obligations directly.
The regulatory intent is that designated regulators can apply specialist sector regulatory oversight and expertise in respect of organisational and preventive obligations, while the CICS Commissioner will have global oversight of incident reporting and response by all CI Operators. So, CI Operators that deal with their designated regulators for organisational and preventive obligations for computer system security under PCICSO, must directly deal with the CICS Commissioner for incident reporting and response obligations under PCICSO. Those CI Operators may have sector specific reporting obligations in addition to the obligations to the CICS Commissioner.
The currently designated regulators under PCICSO are the Hong Kong Monetary Authority for the banking and financial services sector, and the Communications Authority for the telecommunications and broadcasting services sector.
10.1 Can the obligation to perform a security drill be performed unilaterally by CI Operators?
The statutory obligation under PCICSO specifically relates to a requirement notified by the CICS Commissioner in writing to participate in a computer system security drill conducted by the CICS Commissioner. The CI Operator cannot excuse itself from this statutory requirement on the basis of the conduct of internally organised security drills.
10.2 What are the purposes of the security drill?
The purposes of the security drill are for the CI Commissioner to test the CI Operator’s readiness to respond to security incidents, primarily:
(a) assessing the validity and effectiveness of CI Operator’s emergency response plan; and
(b) assessing the participating personnel’s knowledge of their roles and responsibilities in responding to security incidents.
10.3 What are the features of a security drill conducted by the CICS Commissioner?
The particular features of a security drill will be determined by the CICS Commissioner. The security drill may be conducted as a tabletop exercise, functional exercise, simulated attack or other means directed by the CICS Commissioner.
A security drill may involve multiple CI Operators in the same or different sectors, and multiple government units. The purpose could be to test the coordination of security incidents with large societal or economic impacts and restoration of public order.
A security drill will not involve actual deployment of CCSs or their production environment.
10.4 How frequently will security drills be conducted?
No more than once every two years.
10.5 Who would be required to attend a security drill?
The expectation of the CICS Commissioner is that these persons should attend a security drill:
(a) management personnel with a role in the emergency response plan;
(b) CSS Management Unit;
(c) emergency response team members;
(d) corporate communications personnel; and
(e) other personnel necessary for the particular security drill.
10.6 What is the role of the CICS Commissioner after the security drill?
The CICS Commissioner will provider comments on the performance of the CI Operator in the security drill, including areas of improvement. The CI Operator will be required to take remedial actions to adopt and implement recommendations of the CICS Commissioner.
10.7 Is participation in a security drill conducted by the CICS Commissioner discretionary?
It is mandatory for a CI Operator to participate in a security drill conducted by the CICS Commissioner, once the CICS Commissioner has given written notice to the CI Operator to do so. Failure to participate once notified is an offence.
11. Incident Response Obligations: Emergency response plan
11.1 What is the basic obligation of the CI Operator in respect of its emergency response plan?
A CI Operator must submit an emergency response plan detailing the particulars and process for the CI Operator’s response to security incidents in respect of CCS of its critical infrastructure within three months of its designation by the CICS Commissioner, and within one month after any revisions thereafter.
11.2 What is the scope of the emergency response plan?
The scope of the emergency response plan should include incident management, and business continuity management and disaster recovery planning.
11.3 What is incident management?
The incident management aspects of the emergency response plan ensure that the incident response activities are carried out in an orderly, efficient and effective manner, minimising damage from the security incident.
11.4 What is business continuity management?
The primary focus of business continuity management is on the CI Operator’s ability to continue essential operation during disruptions arising from security incidents.
11.5 What is disaster recovery planning?
The primary focus of disaster recovery planning is on the effective restoration of the CCS from severe disruption. This enhances the resilience of business operations in connection with CCS.
11.6 Who is responsible for the emergency response plan?
The emergency response plan is considered a critical document by the CICS Commissioner, and is not an administrative matter. The CI Operator must ensure that the emergency response plan and any subsequent material changes are approved by:
(a) the Board of Directors of the CI Operator;
(b) a functional sub-committee properly delegated by the Board; or
(c) senior management overseeing the operation of the concerned critical infrastructure, such as a Chief Executive Officer or Chief Operating Officer.
11.7 What security incident response matters should be included in the emergency response plan?
The security incident matters to be included in the emergency response plan include:
(a) the structure, roles and responsibilities of a team responsible for responding to security incidents;
(b) the threshold for initiating emergency response protocols to security incidents;
(c) the procedures for reporting security incidents;
(d) The procedures for investigating the cause and assessing the impact of security incidents, including playbooks for:
(i) containing the security incident;
(ii) handling of digital evidence, including identification, collection, acquisition, preservation of evidence and chain of custody;
(iii) investigating the cause and impact of the incident;
(iv) recording the incident response process, including details of the incident, actions taken and decisions made; and
(v) conducting a post-incident review;
(e) the recovery plan for resuming the provision of essential services by, or the normal operation of, affected critical infrastructure;
(f) the plan for communicating with stakeholders and the general public in respect of security incidents;
(g) the recommended post-incident measures for mitigating the risks of recurrence of security incidents, including a post-security incident review that address:
(i) facts and causes of the security incident;
(ii) gaps in existing governance, risk management and compliance in respect of the security incident, and the degree of consequence;
(iii) effectiveness and efficiency in executing the emergency response plan; and
(iv) improvement actions recommended; and
(h) review procedure for the emergency response plan.
11.8 What business continuity matters should be included in the emergency response plan?
The business continuity matters to be included in the emergency response plan include:
(a) the business continuity objectives to be achieved;
(b) business impact analysis of the CCS to identify, as applicable:
(i) maximum tolerable downtime (“MTD”);
(ii) recovery time objectives (“RTO”);
(iii) recovery point objectives (“RPO”); and
(iv) minimum service levels (“MSL”).
(c) resources needed to resume the relevant business processes;
(d) policies and procedures to ensure continuity of essential services;
(e) roles and responsibilities of relevant management and personnel;
(f) training and testing to ensure responsible employees are familiar with the business continuity plan and policy; and
(g) evaluation and review whenever there are material changes to CCS.
11.9 What disaster recovery matters should be included in the emergency response plan?
The business continuity matters to be included in the emergency response plan include:
(a) recovery strategy that aligns with the business continuity objectives;
(b) policies and procedures for backup, taking into account geo-location risk management for data hosting sites;
(c) recovery procedures to an alternative site, including resumption plans for the primary site;
(d) regular testing of backup media and telecommunication services; and
(e) evaluation and review whenever there are material changes to CCS.
11.10 What training obligations are required by CI Operators?
The CI Operator must ensure all members of the emergency response team are familiar with both their own roles and responsibilities and those of other team members as defined in the emergency response plan. The CI Operator must also provide training for all team members to ensure their capabilities to carry out their assigned duties.
Members of the emergency response team are expected to participate in security drills conducted by the CICS Commissioner, and may be subject to comment by the CICS Commissioner in respect of performance at that security drill.
11.11 How should the emergency response plan address communication matters in the context of security incident response?
The CI Operator must ensure there are multiple communication channels (e.g. phone, correspondence and email) available to effectively communicate with stakeholders in response to the security incident.
The CI Operator should appoint at least two contact points for non-working hours emergencies in relation to computer security issues. The contact points will be required to maintain communication with the CICS Commissioner during an emergency, and should also be capable of handling security incidents or relaying security messages to responsible personnel in a timely manner. The CI Operator must provide contact details of these contact points to the CICS Commissioner.
11.12 Are there requirements in respect of data gathering in the course of security incident response?
The CI Operator is expected to collect and preserve digital evidence of the security incident, and is encouraged to engage capable incident response and forensic examination personnel to do so. Initially, the CI Operator must prioritise timely system recovery to restore essential impacted business operations. Otherwise, collection of digital evidence is a priority.
11.13 How frequently should the emergency response plan be reviewed?
The emergency response plan should be reviewed upon any material changes to CCS, and in any event at least once every two years.
11.14 What is the process to notify the CICS Commissioner in respect of the emergency response plan?
There is no prescribed format for an emergency response plan. Accordingly, the CICS Commissioner has not published a prescribed form for the purpose of giving notice.
The CI Operator must submit the emergency response plan to the CICS Commissioner within three months of designation, and thereafter within one month of any revision to the emergency response plan.
Failure to give notice when required is an offence.
11.15 What other regulatory oversight is there of the emergency response plan?
PCICSO includes a positive statutory obligation on CI Operators to implement the emergency response plan. The Code of Practice requires that the CI Operator should provide necessary resources required to implement the emergency response plan. It is not a document for presentation and filing purposes. It is a document to direct the activities of the CI Operator in respect of CCS.
Cybersecurity professionals will be very familiar with security drills and exercises. They are the tried and tested means of assessing whether an emergency response plan is fit for purpose. The innovation of PCICSO is to set the framework for the conduct of those drills periodically on the scale of the Hong Kong economy. An emergency response plan is a critical document, and will assist CI Operators to think through foreseeable issues that might arise in a security incident.
In the next article in this series, we will look at specific incident notification obligations under PCICSO.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was last reviewed on 14 April 2026.
The Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) came into force in Hong Kong on 1 January 2026. This is the first substantial horizontal cybersecurity legislation in Hong Kong. We are exploring the scope and impact of this legislation in a series of articles, focusing in a Q&A format on the key issues businesses and industries need to be aware of. Our previous articles in the series are available on here and here.
In this article, Pádraig Walsh from our Cybersecurity practice reviews the preventive obligations for management plans for computer-system security of critical computer systems, critical computer system risk assessment, and an independent critical computer system audit.
6. Preventive Obligations: CSS Management Plans
6.1 What is the basic obligation of the CI Operator in respect of CSS Management Plans?
A CI Operator must submit a plan for protecting the computer-system security of the CCS of the critical infrastructure operated by the CI Operator within three months of its designation by the CICS Commissioner.
6.2 Who is responsible for the CSS Management Plan?
The CSS Management Plan is considered a critical document by the CICS Commissioner, and is not a mere administrative matter. The CI Operator must ensure that the CSS Management Plan and any subsequent material changes are approved by:
(a) the Board of Directors of the CI Operator;
(b) a functional sub-committee properly delegated by the Board; or
(c) senior management overseeing the operation of the concerned critical infrastructure, such as a Chief Executive Officer or Chief Operating Officer.
6.3 What general matters should be included in the CSS Management Plan?
The general matters required by PCICSO to be included in a CSS Management Plan are:
(a) The organisation of the CSS Management Unit.
(b) The process of identifying computer systems that are essential to the core function of the critical infrastructure operated by the CI Operator.
(c) Various policies and guidelines, including for:
(i) identifying, assessing, monitoring, responding to and mitigating computer-system security risks, vulnerabilities, threats and incidents to CCS;
(ii) detecting computer-system security threats and incidents to CCS;
(iii) controlling access to, and preventing unauthorised acts on, CCS;
(iv) change management controls in respect of changes to CCS;
(v) security of all components of CSS;
(vi) security by design principles;
(vii) availability of the systems during disruption;
(viii) managing contracts and communications with suppliers and vendors of third party services and products; and
(ix) periodic review of the CSS Management Plan.
(d) Training and awareness programmes in respect of the CSS.
6.4 What specific computer-system security policies and guidelines should be in place under a CSS Management Plan?
The Code of Practice published by the CICS Commissioner [link] publishes a series of expectations and requirements in respect of the subject matter of and standards stipulated in a CSS Management Plan. The relevant subject matter headings are:
The CSS Management Plan will essentially consist of a collection of policies, standards and guidelines. In its submissions to the CICS Commissioner, the CI Operator should provide a clear cross-reference that maps each applicable requirement between relevant sections of the CSS Management Plan and the Code of Practice published by the CICS Commissioner.
6.5 How frequently should the CSS Management Plan be reviewed?
The CSS Management Plan should be reviewed upon any material changes to CCS, and in any event at least once every two years.
6.6 What is the process to notify the CICS Commissioner in respect of the CSS Management Plan?
There is no prescribed format for a CSS Management Plan. Accordingly, the CICS Commissioner has not published a prescribed form for the purpose of giving notice.
The CI Operator must submit the CSS Management Plan to the CICS Commissioner within three months of designation, and thereafter within one month of any revision to the CSS Management Plan.
Failure to give notice when required is an offence.
6.7 What other regulatory oversight is there of the CSS Management Plan?
PCICSO includes a positive statutory obligation on CI Operators to implement the CSS Management Plan. It is not a document for presentation and filing purposes. It is a document to direct the activities of the CI Operator in respect of CCS.
If the CICS Commissioner believes that a CI Operator has not properly implemented a CSS Management Plan to its satisfaction, the CICS Commissioner can direct the CI Operator to arrange to carry out a CSS Audit to ascertain if the CSS Management Plan or any part of it has been properly implemented, and to submit the audit report to the CICS Commissioner.
7. Preventive Obligations: CSS Risk Assessments
7.1 What is the basic obligation of the CI Operator in respect of CSS Risk Assessments?
A CI Operator must conduct an annual computer-system security risk assessment (“CSS Risk Assessment”) in respect of the risks relating to security of the CSS of critical infrastructure it operates, and submit a report of the CSS Risk Assessment to the CICS Commissioner. The CSS Risk Assessment must include vulnerability assessment and penetration testing.
7.2 What matters should be included in a CSS Risk Assessment?
The matters required by PCICSO to be included in a CSS Risk Assessment are:
(a) Vulnerability assessment of the CCS.
(b) Penetration test of the CCS.
(c) Identification and prioritisation of identified risks.
(d) Determination of the impact on the security of the CCS that may result from the identified risks, and the level of risks that CCS can tolerate.
(e) Identification of the treatment and monitoring required to deal with the identified risks.
7.3 Who can conduct CSS Risk Assessments?
There is requirement of independence of the personnel conducting risk assessments. Vulnerability assessments should be conducted under the supervision of personnel with relevant qualifications. Penetration tests should be carried out by personnel with relevant qualifications.
7.4 How should CSS Risk Assessments be conducted?
CSS Risk Assessments should be conducted according to nationally or internationally recognised methodologies or standards. These include standards published by:
(a) the China National Standardisation Administration (SAC);
(b) the Hong Kong Digital Policy Office;
(c) the US National Institute of Standards and Technology (NIST); and
(d) international bodies such as the International Electrotechnical Commission (IEC) and the International Organisation for Standardisation (ISO).
7.5 What are the regulatory expectations for the conduct of the vulnerability assessment?
Vulnerability assessments should be conducted under the supervision of personnel with relevant qualifications. The vulnerability assessment should involve various vulnerability identification activities to identify potential security loopholes and vulnerabilities. These include vulnerability scanning, source code reviews, and configuration reviews.
7.6 What are the regulatory expectations for the conduct of the penetration testing?
The penetration test should be conducted by a tester having suitable knowledge, relevant experience and appropriate professional qualification. The penetration test in the CSS Risk Assessment should be carried out from the position of a potential attacker or based on threat intelligence, and can involve active exploitation of possible vulnerabilities of the CCS. The test should include areas of network security, system software security, client-side application security and server-side application security.
7.7 What should be included in a CSS Risk Assessment report?
The CSS Risk Assessment report should include:
(a) Background information;
(b) Executive summary;
(c) Assessment scope, objectives, methodology, time frame and assumptions;
(d) Description of current environment or system, including network diagrams;
(e) Security requirements;
(f) Personnel involved in the computer-system security risk assessment;
(g) Summary of findings and recommendations;
(h) Risk analysis results, including identified assets, threats, vulnerabilities and their impact, likelihood and risk levels;
(i) Recommended safeguards with cost-benefit analysis;
(j) Conclusions; and
(k) Annexes, including completed vulnerability assessment report, penetration test report, covered asset inventories, and asset valuation results.
7.8 What is the timeline to complete the CSS Risk Assessment, and to submit the report to the CICS Commissioner?
The first CSS Risk Assessment must be completed within 12 months of designation by the CICS Commissioner, and a further CSS Risk Assessment must be conducted within each successive 12 months thereafter.
The CI Operator must submit its report from the CSS Risk Assessment to the CICS Commissioner within three months after deadline for conduct of the relevant assessment.
Failure to conduct the CSS Risk Assessment, or to file the report to the CICS Commissioner, when required is an offence.
8. Preventive Obligations: CSS Risk Audits
8.1 What is the basic obligation of the CI Operator in respect of CSS Audits?
A CI Operator must arrange to carry out an audit every two years in respect of the computer-system security of the CCS of critical infrastructure it operates (“CSS Audit”), and submit a report of the CSS Audit to the CICS Commissioner.
8.2 What matters should be included in a CSS Audit?
The matters required by PCICSO to be included in a CSS Audit are:
(a) Verification of whether the existing protection measures in respect of the CSS have been performed properly. This includes whether CSS Management Plans have been properly implemented, and whether the implementation observed relevant provisions in an applicable Code of Practice or was conducted otherwise.
(b) An opinion on the condition of the computer-system security of the CCS based on its verification and assessment.
8.3 Who can conduct CSS Audits?
The CSS Audit must be conducted by persons who are independent of the operation or maintenance of the CCS, and who were not involved in the design or maintenance of the computer-system security controls. The expectation is that the CSS Audit would be conducted by independent third party auditors or by an internal audit department that is not involved in the operation or maintenance of the CCS.
The auditor should possess suitable knowledge, relevant experience and appropriate professional qualifications.
8.4 How should CSS Audits be conducted?
CSS Audits should be conducted according to nationally or internationally recognised methodologies or standards. These include standards published by:
(a) the China National Standardisation Administration (SAC);
(b) the Hong Kong Digital Policy Office; and
(c) international bodies such as the International Electrotechnical Commission (IEC) and the International Organisation for Standardisation (ISO).
8.5 What should be included in a CSS Audit report?
The CSS Audit report should include:
(a) Background information;
(b) Executive summary;
(c) Scope;
(d) Objectives;
(e) Audit methodologies;
(f) Assumptions, limitations and qualifications;
(g) Findings and report; and
(h) Statement of opinion.
8.6 What is the timeline to complete the CSS Audit, and to submit the report to the CICS Commissioner?
The first CSS Audit must be completed within 24 months of designation by the CICS Commissioner, and a further CSS Audit must be conducted within each successive 24 months thereafter.
The CI Operator must submit its report from the CSS Audit to the CICS Commissioner within three months after the deadline for conducting the relevant assessment.
Failure to conduct the CSS Audit, or to file the report to the CICS Commissioner, when required is an offence.
Plans, assessments and audits are the core work of the CSS Management Unit. The regulatory intent is that a strong focus on prevention will mitigate the risk of security incidents. The CSS Management Plan is not a once-and-done task. The process of assessment, audit and review are intended to bring about a virtuous cycle of continuous improvement in the security of critical computer systems.
In the next article in this series, we will look at some incident reporting and response obligations under PCICSO.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was last reviewed on 9 April 2026.
The Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) came into force in Hong Kong on 1 January 2026. This is the first substantial horizontal cybersecurity legislation in Hong Kong. We are exploring the scope and impact of this legislation in a series of articles, focusing in a Q&A format on the key issues businesses and industries need to be aware of. In our first article in the series, we looked at sectors covered by the legislation and the designation process.
In this article, Pádraig Walsh from our Cybersecurity practice reviews the organisational obligations under PCICSO, and the preventive obligations for reporting material changes to critical computer systems.
3. Organisational Obligations
3.1 What is the main purpose of the organisational obligations of CI Operators?
The main purpose of organisational obligations of CI Operators under PCICSO is to ensure CI Operators have a sound management structure to implement necessary protection measures.
3.2 What are the main organisational obligations of CI Operators?
The main organisational obligations of CI Operators are to:
(a) maintain a permanent office in Hong Kong;
(b) notify the CICS Commissioner or Designated Regulator of a change of the organisation that operates the critical infrastructure;
(c) establish and maintain a computer-system security management unit (“CSS Management Unit”); and
(d) appoint an employee with adequate professional knowledge of computer-system security to supervise the CSS Management Unit.
3.3 Can the office of the CI Operator be a PO box, registered office address or virtual office?
No. The office in Hong Kong will not be merely an address to which notices and other documents may be given or sent. The office must also be the location where a CI Operator employs persons and conducts business. The office is expected to be the location for managing daily operations, making business decisions, interacting with stakeholders, and maintaining business records.
3.4 What are examples of changes in the organisation of a CI Operator?
Examples of operator changes include:
(a) Transfer of operations: The daily operation, management or maintenance of a critical infrastructure is changed from an existing CI Operator to another CI Operator.
(b) Cessation or closure: The existing CI Operator ceases to provide daily operation, management or maintenance of the critical infrastructure.
(c) Sale of operations (M&A): Merger, acquisition and other trade sale scenarios that affect the operation of the critical infrastructure.
Routine changes in shareholding or ownership transfer of a CI Operator do not in themselves constitute operator changes.
3.5 Can the CI Operator outsource or engage third parties to perform the functions of the CSS Management Unit?
The PCICSO expressly allows that the CI Operator can either set up and maintain the CSS Management Unit by itself, or engage a service provider instead. This includes engaging overseas or outsourced CSS Management Units. However, the person responsible for supervising the CSS Management Unit must be an employee appointed by the CI Operator.
3.6 What are the competence requirements for the supervisor of the CSS Management Unit?
The basic requirement is that the supervisor of the CSS Management Unit must have adequate professional knowledge of computer system security. This means possessing appropriate professional qualifications and professional experience in computer-system security commensurate with the risk of their CCSs to discharge the duties effectively.
Examples of appropriate professional qualifications include:
(a) Certified Information Security Professional (“CISP”);
(b) Certified Information Systems Auditor (“CISA”);
(c) Certified Information Security Manager (“CISM”); and
(d) Certified Information Systems Security Professional (“CISSP”).
3.7 What is the process to notify the CICS Commissioner in respect of organisational obligations?
The CICS Commissioner has published forms for the purpose of giving notice in respect of organisational obligations:
(b) Form for notifying changes of CI Operator [link]; and
(c) Form for notifying employment of supervisor of CSS Management Unit [link].
In general, notice must be given within one month of designation as a CI Operator, or within one month after any material change in circumstances. Failure to give notice when required is an offence.
Designated Regulators may create separate notification forms.
4. Preventive Obligations
4.1 What is the main purpose of the preventive obligations of CI Operators?
The main purpose of preventive obligations of CI Operators under PCICSO is to ensure CI Operators take measures to prevent cyber attacks.
4.2 What are the main preventive obligations of CI Operators?
The main preventive obligations of CI Operators are to:
(a) notify material changes to CCS;
(b) submit and implement a computer-system security management plan (“CSS Management Plan”);
(c) conduct regular security risk assessments and submit a report; and
(d) carry out regular independent security audits and submit a report.
5. Preventive Obligations: Material changes to CCS
5.1 What constitutes a material change to a CCS?
A change to a CCS is a material change if the change:
(a) affects the computer-system security of the CCS, the ability of the CI Operator to respond to a computer-system security threat or incident in respect of the CCS; or
(b) makes any information provided to the CICS Commissioner or Designated Regulator in respect of the CCS no longer accurate in a material particular.
This is generally a change that would reasonably be expected to have a significant effect on the computer-system security risk of a CCS or risk to the CI’s core function.
5.2 What type of material changes to a CCS trigger a notification obligation?
Material changes to a CCS that trigger a notification obligation to the CICS Commissioner or Designated Regulator are:
(a) a material change to the design, configuration, security or operation of a CCS;
(b) a CCS is removed from the critical infrastructure;
(c) a computer system is added to the critical infrastructure that is accessible by the CI Operator in or from Hong Kong, and is essential to the core function of the critical infrastructure;
(d) a change occurs to a computer system that is an existing computer system of the critical infrastructure and is accessible by the CI Operator in or from Hong Kong, such that the system becomes essential to the core function of the infrastructure.
5.3 What are examples of material changes to a CCS?
Examples of material changes to a CCS include:
(a) Platform migration;
(b) Server virtualisation;
(c) Major version upgrade of a core component (e.g. database);
(d) Changes to the computing platform or hardware;
(e) Application re-design;
(f) Significant code changes;
(g) Changes to the underlying infrastructure that supports the CCS;
(h) Integration with or change in interdependency on external systems or networks;
(i) Changes of mission or major functions that alters the CSS’s operational scope, intended purpose or requirements in security, resources or functions;
(j) Any system modification that fundamentally alters the characteristics or nature of the CCS; or
(k) Substantial changes in CCS components maintained by cloud service suppliers that the CI Operator becomes aware of.
5.4 What is the process to notify the CICS Commissioner in respect of material changes to CCS?
The CICS Commissioner has published a form for the purpose of giving notice in respect of changes to a CCS [link].
Designated Regulators may create separate notification forms.
The CI Operator must submit the completed form within one month of the triggering change event. The date on which the event occurs generally refers to the moment when a change is deployed to a production environment. If the deployment is conducted in phases, the date on which the event occurs should apply to each individual phase of the change deployment. A CI Operator can notify the CICS Commissioner of all changes collectively at the initial phase of the change deployment.
Failure to give notice when required is an offence.
5.5 Can the CICS Commissioner conduct follow up actions after notification of a material change to a CCS?
The CICS Commissioner may direct the CI Operator to:
(a) conduct a CSS Risk Assessment in respect of all or part of the CCS, and file the report for the assessment; or
(b) arrange to carry out a CSS Audit in respect of all or part of the CCS, and file the report of the audit.
CI Operators must have a substantive business presence in Hong Kong, with a dedicated management unit responsible for computer system security supervised by a suitably qualified and competent professional. This organisational setup is essential to be able to meet the other obligations under PCICSO, including the notification of material changes to a critical computer system summarised above.
In the next article in this series, we will look at more preventative obligations under PCICSO.
Pádraig Walsh
If you want to know more about the content of this article, please contact:
Disclaimer: This publication is general in nature and is not intended to constitute legal advice. You should seek professional advice before taking any action in relation to the matters dealt with in this publication. This article was last reviewed on 2 April 2026.
