The Hong Kong Securities and Futures Commission (SFC) is continuing its engagement with a global regulatory initiative targeting unlawful activities by finfluencers [see link]. In this update, Pádraig Walsh from our Fintech practice looks at the SFC’s growing focus on online investment content and the increasing cross‑border reach of finfluencer‑driven misconduct.
Context
Finfluencers are social media personalities who use their platforms to promote financial products and share insights and advice with their followers. Almost by definition, finfluencers seek to persuade and induce the retail public in respect of trading activities. There is an obvious regulatory concern when objective factual presentation and appropriate investment analysis are discarded in favour of unauthorised financial promotions and personal opinion.
Finfluencing is not a new phenomenon. The SFC recognised the influence of digital channels on investors’ perceptions and financial behaviours in respect of virtual assets in its ASPIRe regulatory framework in early 2025, and committed to being vigilant and taking enforcement action against reckless activity that causes risk and harm to the public.
The key challenge remains enforcement. The online medium of finfluencing through social media platforms to global audiences presents jurisdictional challenges. The SFC may wish to adopt a regulatory framework to encourage finfluencers to contribute constructively to educate the public and advocating the best practices. However, there is a need for any framework to move forward in step with international developments and progress.
Regulatory initiatives
The SFC has actively participated since inception in the Global Week of Action against Unlawful Finfluencers organised by the International Organization of Securities Commissions (IOSCO). The SFC and the Hong Kong Investor and Financial Education Council also contributed to an IOSCO Report on Finfluencers [link], which includes a detailed Good Practices section to guide securities regulators globally on regulatory approach and enforcement.
In April 2025, the SFC commenced a thematic inspection to assess the compliance of securities brokers with applicable regulatory requirements when engaging finfluencers and digital platforms to market financial products and services.
The SFC has undertaken enforcement actions against unlawful finfluencer activities. In one prosecution, an SFC licensed representative was convicted for providing investment advice in his personal capacity in a Telegram subscription-based chat group [link].
The SFC has increasingly focused on early detection and prevention of unlawful finfluencer activity. The SFC has strengthened its proactive surveillance of online platforms, including through the use of technology‑driven monitoring tools to detect suspicious social media posts and accounts engaging in unlicensed promotions. The SFC has also worked directly with major social media platforms to facilitate the prompt removal of problematic content, social media posts and profiles impersonating public figures and promoting unauthorised investment products.
In parallel, the SFC has continued to place emphasis on investor education and awareness.
ASPIRe’s “Re” pillar: collaboration as a regulatory tool
The SFC’s approach is consistent with Pillar “Re – Relationships” under its ASPIRe regulatory roadmap for the virtual asset market. The relationships pillar focuses on empowering investors and industry participants through education, engagement and transparency, while promoting informed participation and constructive regulatory dialogue.
Initiative 11 under the ASPIRe regulatory roadmap recognised the growing influence of finfluencers as a new channel of investor engagement. The initiative contemplates a regulatory framework to promote responsible financial communications, accountability and investor awareness. No specific development on a regulatory framework has been announced by the SFC. The relationship pillar emphasises close engagement and coordination with overseas securities regulators. We expect that a regulatory framework in Hong Kong will occur in line with international developments, so there is convergence in the regulatory approach to an issue that transcends jurisdictional boundaries.
Key takeaways
The latest regulatory developments of the SFC serve as a timely reminder that:
• global coordination is becoming a core feature of financial regulation, particularly in digital and online markets.
• financial services intermediaries and investors should not assume that influencer‑based activities fall outside traditional regulatory scrutiny.
• governance, monitoring and contractual controls around online promotions are increasingly critical.
The SFC’s regulatory approach underlines that effective regulation in the digital age requires ongoing vigilance and informed investor participation. Financial services intermediaries relying on digital marketing or influencer‑based outreach should be aware that regulatory expectations are converging globally, particularly where content is accessible by investors in multiple jurisdictions. As the SFC continues to operationalise the ASPIRe roadmap, we expect international collaboration – especially in enforcement and supervisory engagement – to play an even more prominent role in shaping regulatory outcomes for Hong Kong‑facing businesses.
For more details about ASPIRe, please refer to our article “ASPIRe: Looking back and ahead on the regulatory roadmap for virtual assets in Hong Kong” at this link.
Pádraig Walsh and 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 last reviewed on 7 May 2026.
News update: Secondary Trading of Tokenised Authorised Investment Products Permitted in Hong Kong
The Securities and Futures Commission in Hong Kong (SFC) continues to progressively use its 2025 ASPIRe regulatory roadmap and framework to advance the development and integration of the Web3 market in Hong Kong. In this news update, Pádraig Walsh from our Fintech practice, looks at the circular published by the SFC on 20 April 2026 (“Secondary Trading Circular”) that sets out an update to regulatory framework for tokenised SFC-authorised investment products (“Tokenised Products”) in Hong Kong.
Background
On 2 November 2023, the Securities and Futures Commission (SFC) published two circulars that outlined a regulatory framework for security token offerings in Hong Kong (see our review of the prior circulars here). These circulars included guidance on the requirements for authorisation by the SFC for tokenised SFC-authorised investment products. The parameters were limited to primary dealing only. The SFC considered secondary trading activities needed more consideration to ensure the regulatory framework could provide the appropriate level of investor protection.
The SFC has since noted that, as of March 2026, 13 Tokenised Products were offered to the public in Hong Kong, with the assets under management of their tokenised classes increasing around seven-fold to $10.7 billion over the past year.
A key part of the ASPIRe framework is to open up products and access in the Web3 ecosystem in Hong Kong. The SFC wishes to support the tokenisation and trading of tokenised bonds, funds and other instruments. The purpose of the Secondary Trading Circular is to allow licensed virtual asset trading platforms in Hong Kong (“VATPs”) to offer secondary on-platform trading of Tokenised Products. The intention is to broaden trading venues, enhance liquidity and reinforce the development of a blockchain‑enabled financial infrastructure within clear regulatory guardrails.
Key requirements
The following are key requirements set out in the Secondary Trading Circular for secondary trading of Tokenised Products:
Trading channel: Product providers must test trading arrangements with relevant licensed VATPs before launch to confirm operational and system readiness. Product providers may only execute trades when the client has sufficient funds or equivalent holdings to cover the trade.
Fair pricing: Licensed VATPs must implement risk controls. These must include price deviation alerts, notices to investors on primary market alternatives and system monitoring that prevents excessive fluctuations and manipulation.
Liquidity provision:
Product providers must appoint a market maker for each Tokenised Product, monitor secondary market liquidity, appoint SFC-licensed distributors, and have arrangements to facilitate primary and secondary market transfers of Tokenised Products.
Licensed VATPs must conduct due diligence, ensure appropriate commitment, arrange to rectify any short comings of obligations, and impose specific obligations and arrangements for particular Tokenised Product in respect of the relevant market makers.
Disclosure: The offering document should describe the risks and information associated with secondary trading of the Tokenised Products, including liquidity and price deviation risks, and explain when the platform may suspend secondary trading of Tokenised Products.
Notification: Product providers should alert the SFC early to issues that may adversely affect the operations, secondary trading, or liquidity of their Tokenised Products.
SFC prior consultation and approval
Product providers will need authorisation, prior consultation and SFC approval as applicable when introducing new products with tokenisation features. Intermediaries, including licensed VATPs, must notify and discuss their proposals with their case officers before engaging in secondary trading of Tokenised Products for the first time and later upon any material changes to arrangements.
Analysis
The Secondary Trading Circular can be viewed through the lens of the SFC’s approach to tokenised products generally. At this stage, the SFC is more comfortable with taking traditional financial products generally (bonds, funds) and applying the “same business, same risks, same rules” ethos to tokenisation of those products. This is not RWA tokenisation for the purists. It is a pragmatic path to opening more regulated routes involving the benefits of blockchain technology. The initiative allows a tokenised form of a traditional securities product to be traded in the evening and on weekends, and to be supported by the use of regulated stablecoins and tokenised deposits to facilitate liquidity. This is progressive, beneficial and timely.
The SFC has continued to focus on investor protection. Product providers, VATPs and intermediaries must adopt safeguards that typically apply to listed secondary-market trading. These include execution standards, pricing controls, liquidity support and disclosure. Providers and intermediaries considering introducing Tokenised Products should review their governance and operational readiness early, update client-facing disclosures, and engage the SFC for prior consultation or approval. These are not light touch requirements. There is a material compliance cost involved. Investor protection is still the key touchstone.
Conclusion
The Secondary Trading Circular demonstrates the SFC’s continued push to provide a clear pathway for retail traditional finance products to use Web3 infrastructure. This marks a further step and enhancement of Hong Kong’s Web3 ecosystem.
Pádraig Walsh and Jack Lee
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 4 May 2026.
On 16 March 2026, the Office of the Privacy Commissioner for Personal Data (PCPD) issued a media statement reminding organisations and members of the public to use “OpenClaw” and other agentic artificial intelligence tools with caution. In this news update, Pádraig Walsh from our Data Privacy practice looks at the key data privacy and cybersecurity risks arising from agentic AI that were highlighted by the PCPD and the recommended safeguards to adopt before deployment.
What is agentic AI (and why does it matter)?
Agentic AI tools differs from other AI tools such as AI chatbots. AI chatbots are limited to analysing documents and providing information based on pre-defined questions. Agentic AI can operate as a form of digital assistant that can provide information and carry out tasks independently, once objectives are clearly defined. Agentic AI can read and write local files, deploy system resources, interface with third-party services, or autonomously carry out multiple-step tasks according to pre-defined instructions. This can be deployed for tasks such as handling emails, making hotel reservations and settling payments. These processes do not require user’s real time involvement once the instructions have been given. Open Claw is one example of this form of agentic AI.
The PCPD has highlighted that these capabilities can amplify privacy and security risks. Agentic AI needs careful design and implementation of access controls, monitoring and technical safeguards across a number of data sets and computer networks and systems. This is particularly necessary to preserve privacy and security. Without strict privilege settings and oversight, expanded access may expose large volumes of personal data to unauthorised access, copying, or onward disclosure. The system may also misread user instructions and delete or change critical information. Risks increase further if connected systems have design flaws or weak safety controls. Malicious code may be introduced and exploited to compromise accounts or take over devices. Agentic AI is becoming increasingly easy to use and deploy. The ease of use can result in premature deployment before privacy and security concerns are fully considered.
PCPD’s suggestions
The PCPD reminded organisations and members of the public that, they should first understand the personal data privacy and security risks involved before deploying or using agentic AI tools. The PCPD recommended users of agentic AI to:
(a) consider the nature and sensitivity of the personal data involved and grant the minimum access right to agentic AI;
(b) use the latest official version and avoid third-party versions or outdated versions to reduce risk of data breach incidents from unpatched system vulnerabilities;
(c) adopt adequate measures to ensure system security and data security;
(d) install and use plugins with caution, verify that the relevant programmes are official versions to ensure their security;
(e) conduct continuous risk assessments to identify and evaluate risks involved using agentic AI
Conclusion
Open Claw launched to significant attention and impact, which has since somewhat waned. The PCPD guidance is not limited to one application or tool though. The issues are more pervasive than that. Agentic AI tools have the capacity of performing tasks without human oversight and may in time move beyond answering questions to taking actions across business systems.
The privacy and security consequences of misconfiguration of agentic AI can be immediate and significant. The PCPD will still assess responsibility by reference to the data user collecting and controlling the use of personal data. If an organisation in Hong Kong uses agentic AI in its operations that collects or uses personal data when deployed, then that organisation (and most likely, not the system developer) will be responsible and accountable. The data user (and humans!) must still have oversight of the deployment and activity of agentic AI. The data user will still be accountable.
The PCPD’s statement is a useful reminder that organisations should treat agentic AI deployments as a governance and risk project. Organisations should retain robust oversight and establish systemic rules on what data an AI agent may access and process. We expect regulatory attention in this area to continue as adoption accelerates.
And remember, privacy by design and default from the outset, and human oversight and monitoring in implementation are the key protections. You don’t want a PCPD enforcement action to force you to claw back privacy and security after the event.
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 last reviewed on 30 April 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.
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 will explore 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 this first article, Pádraig Walsh from our Cybersecurity practice reviews who qualifies as critical infrastructure operators, how operators are designated, and which sectors fall under the regulatory ambit of the Commissioner of Critical Infrastructure (Computer-system Security) and sector regulators.
Introduction
1.1 Is there a cybersecurity law in Hong Kong?
Yes. The Protection of Critical Infrastructures (Computer Systems) Ordinance, (Chapter 653, Laws of Hong Kong) (“PCICSO”) came into operation on 1 January 2026. This is a comprehensive cybersecurity law, focussing on the protection of critical computer systems in critical infrastructure from cybersecurity risk.
1.2 What is the competent regulatory authority?
The Office of the Commissioner of Critical Infrastructure (Computer-system Security) (“CICS Commissioner”) is the competent regulatory authority. This office is a division of the Security Bureau of the Government of Hong Kong, and is not an independent statutory body.
1.3 What is the role of designated regulatory authorities?
Some regulatory responsibilities are shared with designated statutory sector regulators. Specifically, PCICSO designated the Monetary Authority and the Communications Authority (“Designated Regulators”) as competent regulators to directly supervise the responsibilities for organisational and preventive obligations under PCICSO in respect of certain regulated entities under its regulatory purview, as summarised below:
This reflects that the Monetary Authority and Communications Authority already regulate their respective sectors with a degree of sophistication and familiarity with the operations and needs of the relevant sectors. This will avoid duplication of effort with the remit of the CICS Commissioner.
The means that the Monetary Authority and Communications Authority, as designated authorities under PCICSO, will perform these functions in respect of CI Operators under their scope of authority:
(a) Identify and designate CI Operators and critical computer systems;
(b) Monitor CI Operators’ compliance with organisational and preventive obligations under PCICSO;
(c) Issue codes of practice to CI Operators, setting out the proposed standards for the organisational and preventive obligations. This can include adopting Codes of Practice published by the CICS Commissioner, as well as supplementing with sector specific Codes of Practice; and
(d) Issuing a written direction to a CI Operator if it has failed to fully comply with organisational or preventive obligations under PCICSO.
The CICS Commissioner will be responsible for regulating CI Operators of all sectors (including banking and financial services and telecommunications and broadcasting services) for incident reporting and response obligations.
1.4 How will the regulation be applied?
The main piece of legislation is the PCICSO. The CICS Commissioner will issue codes of conduct, guidelines and forms. The CICS Commissioner issued a General Code of Practice on 1 January 2026 [link], and a Code of Practice for the Energy Sector on 28 January 2026 [link]. We can expect the CICS Commissioner to publish other sector-specific Codes of Practice.
Codes of Practice are not subsidiary legislation. Failure to comply with the requirements of a Code of Practice would not in itself constitute an offence. However, the CICS Commissioner may issue written directions to require a CI Operator to take appropriate actions in relation to compliance with obligations under the PCICSO. Those directions are likely to be based on requirements set out in Codes of Practice, and compliance will be measured against the relevant provisions in the Code of Practice. Failure to comply with directions issued by the CICS Commissioner is an offence.
Guidelines are non-binding.
The Regulatory Perimeter
2.1 Who and what is the target of regulation under PCICSO?
The primary target of regulation is the protection of critical infrastructure and designated computer systems operated by designated critical infrastructure operators in Hong Kong. Direct regulation will only apply to large organisations. Only organisations designated by the authorities will be subject to PCICSO.
2.2 What is not regulated under PCICSO?
PCICSO does not cover, or is not intended to cover:
(a) Government departments. The Hong Kong Government already applies internal Government Information Technology Security Policy and Guidelines.
(b) Personal data, trade secrets and business information in computer systems. Personal data is already subject to regulation of the Office of Privacy Commissioner for Personal Data (“PCPD”) under the Personal Data (Privacy) Ordinance, Chapter 486, Laws of Hong Kong (“PDPO”).
(c) Small and medium size organisations or the general public.
2.3 What are critical infrastructure operators?
Critical infrastructure operators (“CI Operators”) are businesses or organisations that operate critical infrastructure. We analyse that description more in the paragraphs below.
2.4 What is critical infrastructure?
Critical infrastructure is any infrastructure that is essential to the continuous provision in Hong Kong of an essential service in a specified sector, and any other infrastructure the damage, loss of functionality or data leakage of which may hinder or substantially affect the maintenance of critical societal or economic activities in Hong Kong.
2.5 What are the specified sectors of CI Operators?
The specified sectors are:
Energy
Information technology
Banking and financial services
Air transport
Land transport
Maritime transport
Healthcare services
Telecommunications and broadcasting services
2.6 What are examples of critical infrastructure and CI Operators?
2.7 What does designation mean?
Not all businesses in the specified sectors are directly subject to the obligations of PCICSO and the regulatory oversight of the CICS Commissioner or the Direct Regulators under PCICSO. Direct regulation will only apply to large organisations, and will not apply to small and medium size organisations or the general public.
Designation is the process the CICS Commissioner and Designated Regulators will use to identify CI Operators, and the designated computer systems, that will be subject to direct regulation. The process will involve the CICS Commissioner and Designated Regulators identifying critical infrastructure, the CI Operators operating the critical infrastructure, and the critical computer systems relied upon in those operations.
The CICS Commissioner and the Designated Regulators have the statutory power to require operators to provide information he reasonably believes necessary to ascertain and assess each level of enquiry, from assessment of critical infrastructure, assessment of operators and ultimately, assessment of computer systems. It is an offence for an operator to fail to comply with an information request of the CICS Commissioner or Designated Regulators.
2.8 How will critical infrastructure be identified?
In general, the CICS Commissioner and Designated Regulator will have regard to:
(a) the kind of service provided by the infrastructure.
(b) whether there would be disruption or other significant impact to critical societal or economic activities in Hong Kong if the infrastructure was damaged, lost functionality or suffered data leakage.
2.9 What factors will be applied in the designation of CI Operators?
The factors considered when designating an organisation as CI Operator include:
(a) The extent of dependence of core functions on computer systems;
(b) The sensitivity of the data controlled by the infrastructure concerned; and
(c) The extent of control over the operation and management of the infrastructure concerned by the CI Operator in Hong Kong.
2.10 What factors are considered in the designation of critical computer systems?
The ultimate target of PCICSO and the primary concern of the CICS Commissioner and Designated Regulators is the protection of critical computer systems (“CCS”) in the operation of critical infrastructure by CI Operators.
These factors must be taken into account before designating a computer system as a CCS:
(a) the role of the computer system in core functions of the critical infrastructure;
(b) the impact of disruption or destruction of the computer system on core functions;
(c) the extent to which the computer system is related to other computer systems of the CI Operator;
(d) the extent to which the computer system and other computer systems of the CI Operator are related to those of other CI Operators and the computer systems other CI Operators use;
(e) the sensitivity of digital data stored or processed by the computer system that are used directly in the provision of essential services; and
(f) any information provided by the CI Operator.
Operational technology systems can also be considered as computer systems for the purpose of PCICSO. These systems could include supervisory control and data acquisition systems, distributed control systems or programmable logic controllers.
Underlying IT infrastructure of a computer system could also be regarded as components of the computer system, and within the scope of regulation under PCICSO. This could include network components, operating platforms, middleware, IoT devices and uninterruptible power supply systems.
2.11 What information is required to assess designation?
The CICS Commissioner and the Designated Regulators have discretion to require an operator to provide information reasonably necessary for learning about the operator and its critical computer systems.
In practice, this is likely to include:
(a) organisation chart of the operator;
(b) system functions;
(c) network infrastructure diagram and architecture;
(d) nature and volume of data processed;
(e) manufacturers and models of hardware and software;
(f) third party IT or telecom services provided by third parties;
(g) backup plans;
(h) information and technical specifications of the system design and operation; and
(i) other facts and functions about the computer system, including upstream and downstream dependencies.
2.12 How will an operator know it has been designated for compliance with obligations under PCICSO?
The process of designation is initiated by the CICS Commissioner and Designated Regulator through communication. The decision to designate will be notified in writing by the CICS Commissioner or Designated Regulator, setting out the effective date and CCS covered.
2.13 Is designation of a CI Operator or CCS made public?
No.
The sectors included under the ambit of PCICSO are the conventional sectors in similar legislation in other jurisdictions. PCICSO though will follow a designation process. Simply being a significant business in a covered sector does not automatically make a business subject to the legislation. There will be a formal process of designation that will pragmatically and systematically brings organisations under the purview of the CICS Commissioner (or designated regulator) over time.
In the next article in this series, we will look at the organisational obligations and certain 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 31 March 2026.
