Hong Kong software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Hong Kong, the biggest change is the Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653), which came into operation on 1 January 2026. Designated operators must report serious incidents on critical computer systems within 12 hours, submit a security management plan that covers secure development and supplier contracts, run a risk assessment with vulnerability assessment and penetration testing every 12 months, and commission an independent audit every 24 months. Banks, stored value facility licensees and payment system operators also follow sector codes issued by the HKMA in June and October 2026, and SFC-licensed firms were told on 2 June 2026 to keep an accurate inventory of software components and speed up patching because AI tools are shrinking the time between disclosure and exploitation.

This guide reads each rule from its primary text, shows the evidence a regulator will ask for, and ends with a 30/60/90-day plan that works with whatever tools you already have. It is a practical reading of public documents, not legal advice. Where a clause needs interpretation for your organisation, take it to counsel or to your regulating authority.

Key takeaways

• Cap. 653 has been in operation since 1 January 2026. It applies only to organisations designated as critical infrastructure (CI) operators, and only to the computer systems designated as critical computer systems. Schedule 1 lists eight sectors: energy, information technology, banking and financial services, air transport, land transport, maritime transport, healthcare services, and telecommunications and broadcasting services.
• Incident clocks are short. Under section 28 and Schedule 6, a CI operator notifies the Commissioner within 12 hours of becoming aware of an incident that has disrupted, is disrupting or is likely to disrupt the core function of the infrastructure, and within 48 hours in any other case. A written report follows within 14 days.
• Software and suppliers sit inside the plan. Schedule 3 asks the security management plan to cover security across "the entire development life cycle" of critical systems and the management of contracts with suppliers of computer-related services and products.
• Assess every year, audit every two. Section 24 requires a risk assessment within 12 months of designation and at least once every 12 months after that, including a vulnerability assessment and a penetration test (Schedule 4). Section 25 requires an independent audit within 24 months, then at least every 24 months.
• Sector codes are now live. The Commissioner's Office lists a generic code (1 January 2026) and sector codes for energy, land transport, and HKMA-designated banks, payment system operators, stored value facility licensees and retail payment system operators, the latest dated 15 October 2026.
• The HKMA and the SFC both moved on AI-enabled attacks on 2 June 2026. Both circulars ask firms to reassess patching and third-party service provider risk. The SFC circular also asks for an up-to-date inventory of software components and treats AI language models from vendors and open source as a source of cyber risk.
• The PDPO still governs personal data. Data Protection Principle 4 asks data users to secure personal data and to use contractual or other means to bind their data processors.
• Safeguard capabilities in this guide are all GA: SBOM generation and analysis, SCA and vulnerability management, reachability analysis, autonomous remediation (ships switched off), policies and gates, the Compliance and GRC suite, TPRM, CSAF and VEX upload, Package Firewall, SAST and DAST, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, Trust Center, the CLI and local runner, Zero AI mode, bring your own model and air-gapped deployment.

Who this applies to in Hong Kong

Hong Kong does not have one horizontal software security law. Obligations follow who you are, who licenses you and which systems you run. Five groups carry most of the weight.

Designated critical infrastructure operators. Cap. 653 reaches organisations that a regulating authority designates as CI operators in the eight Schedule 1 sectors, and then the specific systems designated as critical computer systems. The Commissioner of Critical Infrastructure (Computer-system Security) supervises most operators directly and receives every incident notification. Schedule 2 names two designated authorities that regulate the organisational and preventive duties for their own licensees: the Monetary Authority, for authorized institutions under the Banking Ordinance (Cap. 155) and for stored value facility licensees, designated system operators and settlement institutions under the Payment Systems and Stored Value Facilities Ordinance (Cap. 584); and the Communications Authority, for licensed telecommunications carriers and free television broadcasters. Being in a listed sector does not make you a CI operator. Designation does.

Banks, payment providers and stored value facilities. The Hong Kong Monetary Authority (HKMA) supervises authorized institutions through its Supervisory Policy Manual. Module TM-C-1, "Supervisory Approach on Cyber Risk Management", was issued on 29 November 2024 and replaced the HKMA's 2015 cyber security risk management circular. It sits alongside the Cyber Resilience Assessment Framework (C-RAF) 2.0, which the HKMA's own circulars and codes cite by domain and section number. Where the HKMA has designated one of these firms under Cap. 653, the firm also follows the HKMA's sector code of practice.

Securities firms and virtual asset trading platforms. The Securities and Futures Commission (SFC) supervises licensed corporations, SFC-licensed virtual asset trading platforms and their associated entities. Its cyber expectations sit in guidelines issued under section 399 of the Securities and Futures Ordinance and in a stream of circulars, the latest on AI-enabled attacks.

Every organisation that handles personal data. The Privacy Commissioner for Personal Data (PCPD) enforces the Personal Data (Privacy) Ordinance (Cap. 486, the PDPO) against every data user, whatever the sector.

Software and service suppliers to all of the above. Most vendors are not CI operators but are in scope indirectly: an operator's plan must manage supplier contracts, bank codes point to C-RAF supply chain controls, and SFC licensees must assess their service providers. Expect these duties to arrive as contract clauses and questionnaires.

The rules, regulator by regulator

Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653)

The Ordinance was enacted as Ordinance No. 4 of 2025 (the Chinese title is 《保護關鍵基礎設施(電腦系統)條例》). Section 1 left commencement to a notice by the Secretary for Security, and the Commissioner's Office lists its Code of Practice (Generic) as effective from 1 January 2026, the day the regime began.

The Ordinance sorts duties into three categories, defined in section 2.

Category 1, organisation (Part 4, Division 1). Section 19 requires a CI operator to maintain an office in Hong Kong and notify its address within one month of designation. Section 20 requires notice of operator changes within one month. Section 21 requires a computer-system security management unit, which the operator may run itself or through a service provider, in place within one month of designation if it does not already exist.

Category 2, prevention (Part 4, Division 2). Section 22 requires notice of material changes to critical computer systems within one month. Section 23 requires a computer-system security management plan within three months of designation, covering the matters in Schedule 3. Section 24 requires a risk assessment within 12 months of designation and then at least once every 12 months, covering Schedule 4. Section 25 requires an audit of the critical computer systems within 24 months of designation and then at least once every 24 months, with the report submitted within three months after each audit period ends. Section 25(9) says an audit only counts if an independent auditor carries it out.

Category 3, incident reporting and response (Part 4, Division 3). Section 26 requires participation in security drills that the Commissioner runs. Section 27 requires an emergency response plan within three months of designation, covering the matters in Schedule 3, Part 2. Section 28 requires incident notification to the Commissioner within the Schedule 6 times.

Three schedules matter most to software teams.

• Schedule 3, Part 1 (the security management plan) asks for the process of identifying the systems essential to the core function (item 2) and policies for identifying, assessing, monitoring, responding to and mitigating risks, vulnerabilities, threats and incidents (item 3(a)). It also asks for change control (3(d)), securing all components of the systems (3(e)), "principles that prioritize and integrate security measures throughout the entire development life cycle" (3(f)), and managing contracts with suppliers of computer-related services and products so the operator meets all three categories of obligation (3(h)).
• Schedule 4 (risk assessments) defines a vulnerability assessment as systematically examining a system for known vulnerabilities, and a penetration test as a simulated electronic attack. Part 2 lists both, followed by identifying and prioritising risks, deciding the tolerable level of risk, and deciding treatment and monitoring.
• Schedule 6 (incident times) sets 12 hours where the core function is or is likely to be disrupted and 48 hours otherwise, 48 hours for a written record if the first notification was not in the specified form, and 14 days for the written report.

The penalties for an operator's own duties are fines. Failing to notify an incident under section 28 carries up to HK$3,000,000 on summary conviction and HK$5,000,000 on indictment. Most category 1 and 2 failures carry HK$300,000 on summary conviction and HK$500,000 on indictment, plus daily fines while the failure continues.

Codes of practice. Section 8 lets regulating authorities issue codes of practice. The Commissioner's Office lists these as of today:

The HKMA's code for stored value facility licensees (12 June 2026) shows how far into software these codes go. It ties each control to C-RAF 2.0. Section 6.2.8 (Security by Design) asks for a secure development process across the life cycle, referring to C-RAF subdomain 3.4. Section 6.2.9 (Asset Management) asks for a record of software assets with name, publisher and version. Section 6.2.17 (Patch Management) points to C-RAF sections 3.5.1 and 3.5.2 and asks for a risk-based patch strategy. Section 6.2.22 (Application Security) asks firms to install only authorised software and to protect the source code they own, maintain or customise. Section 6.2.25 (Supply Chain Management) points to C-RAF subdomain 2.1 and domain 7, and asks firms to avoid over-dependence on one or a few suppliers, with geopolitical risk named as a factor. The code says it gives practical guidance on category 1 and 2 obligations, and that category 3 guidance sits in section 7 of the generic code.

HKMA: TM-C-1, C-RAF 2.0 and the June 2026 circular

TM-C-1 is the HKMA's statement of how it supervises cyber risk at authorized institutions. Its listing in the HKMA's Banking Regulatory Document Repository cross-refers TM-E-1 (e-banking), OR-2 (operational resilience), TM-G-1 (general technology risk management) and SA-2 (outsourcing), which is where third-party arrangements are governed.

On 2 June 2026 the HKMA wrote to all authorized institutions under the heading "Strengthening Cyber Resilience amid Artificial Intelligence-Empowered Cyber Threats". The letter says frontier AI models can find and exploit zero-day vulnerabilities in critical software and could make attacks faster and more frequent. It asks institutions to do three things: review whether defences such as defence in depth, zero trust and patching protocols remain fit for purpose, and assess the cyber resilience of their third-party service providers as possible entry points for supply chain attacks; uplift incident response and recovery, including scenario testing; and review data resilience, including the Secure Tertiary Data Backup the HKMA has recommended. Its footnote anchors these expectations in TM-C-1 and C-RAF 2.0.

SFC: hacking risk guidelines and the 2026 circulars

The SFC's Guidelines for Reducing and Mitigating Hacking Risks Associated with Internet Trading apply to firms licensed for Types 1, 2, 3 and 9 regulated activity that run internet trading. Paragraph 4 says they do not have the force of law, but a failure to follow their spirit may reflect on a firm's fitness and properness. For software, three items stand out. Section 2.4 asks firms to implement security patches or hotfixes "within one month following the completion of testing". Section 2.6 asks for controls against unauthorised installation of software. Section 2.10 asks for a formal service level agreement with any third-party service provider that supports internet trading. Section 3.1 makes responsible officers accountable for the cyber risk framework, and section 3.2 asks for written incident escalation and reporting procedures.

The SFC's circular of 2 June 2026, "Enhanced cybersecurity measures to address evolving risks arising from artificial intelligence-enabled cyberattacks" (ref. 26EC32), is the more pointed document for software teams. Paragraph 3 makes senior management, including the Manager-in-Charge of Information Technology (MIC-IT), ultimately responsible. Paragraph 6 asks firms to "maintain an accurate and up-to-date inventory" of technology assets and components, including software and cloud services, and to identify which are externally exposed, business critical or dependent on third-party components. Paragraph 8 says AI language models, whether built in-house, provided by a group company or a vendor, or obtained from open source, may amplify cyber risk. Section (A) asks for faster patching and procedures for urgent fixes outside routine cycles. Section (D) asks for a stronger third-party supply chain risk framework, and section (E) for incident procedures tested through tabletop exercises or simulated attacks.

The appendix to that circular says large retail brokers, Type 13 depositaries and virtual asset trading platforms are "generally expected" to implement all the listed measures, and others should consider them in proportion. The patching measures include replacing end-of-life and unsupported software, ranking vulnerabilities by severity, exploitability, external exposure, data sensitivity and system criticality, automating patching for lower-risk items, and using compensating controls until a fix lands.

The SFC's 12 November 2024 circular on the use of generative AI language models remains the base for AI governance at licensed corporations, and 26EC32 reminds firms that high-risk AI use cases trigger notification duties under the Securities and Futures (Licensing and Registration) (Information) Rules.

Joint regulators: the cross-sectoral Cyber Mapping exercise

On 29 July 2026 the HKMA, the SFC, the Insurance Authority and the Mandatory Provident Fund Schemes Authority reported on the first production run of a cross-sectoral Cyber Mapping exercise, completed in March 2026 with over 50 financial institutions. They found no new systemic "unknown-unknowns", but saw similar adoption patterns in network appliances, security monitoring and privileged access management tools, and recurring specialist vendors in some payment and customer communication workflows, which they said supports earlier supervisory monitoring of third-party concentration.

Personal Data (Privacy) Ordinance (Cap. 486)

The PDPO (《個人資料(私隱)條例》) sets six Data Protection Principles in Schedule 1. DPP4(1) requires data users to take all reasonably practicable steps to protect personal data against unauthorised or accidental access, processing, erasure, loss or use. DPP4(2) requires a data user that engages a data processor to adopt contractual or other means to prevent unauthorised or accidental access to the data transferred, and DPP2(3) does the same for retention. DPP5 asks data users to make their policies and practices available.

Two features surprise teams arriving from other regimes. The PDPO has no mandatory breach notification duty; the PCPD's guidance encourages data users to notify the PCPD and affected people as soon as practicable. Section 33, which would restrict transfers of personal data outside Hong Kong, has not been brought into operation. The PCPD has also published an AI model personal data protection framework (June 2024) for organisations procuring and using AI. Treat any amendment proposals as proposals until a bill is gazetted.

AI rules

Hong Kong has no AI statute. AI obligations arrive through the SFC and HKMA circulars, the PDPO and the PCPD's guidance. For a CI operator, an AI service on a critical computer system is part of that system for the plan and the risk assessment.

What the rules ask of software and open source

Across these regimes, the same few asks repeat. None of them uses the word SBOM, and none sets a fixed CVE remediation deadline. Each asks you to know your components, fix what matters quickly, control suppliers and prove it. An SBOM is the most practical way to answer the SFC's component inventory, the HKMA code's software asset record and Schedule 3's "all components" item.

SBOMs and component inventories

No Hong Kong rule names the SBOM, but the SFC, the HKMA codes and Schedule 3 all ask for what it contains. A machine-readable SPDX or CycloneDX SBOM per critical system and release answers all three, and lets you say within hours whether a new vulnerability touches a critical computer system.

Vulnerability handling and patch timelines

The only fixed number is the SFC guidelines' one month after testing. Everything else is risk-based, using the SFC appendix factors. Write your own deadlines by risk tier, record exceptions and keep the dates.

Third-party and ICT supplier risk

Schedule 3, item 3(h) puts supplier contracts inside the plan. The HKMA codes add C-RAF domain 7 and a concentration test, the SFC wants assessments updated for AI-enabled threats, and the Cyber Mapping circular shows regulators looking at shared vendors across firms.

Incident reporting clocks

Only Cap. 653 sets a statutory clock: 12 hours where the core function is or is likely to be disrupted, 48 hours otherwise, and a written report in 14 days, all running from awareness. The SFC guidelines ask for written escalation procedures, and PDPO notification to the PCPD is voluntary.

Secure development and data residency

Schedule 3, item 3(f) and the HKMA's section 6.2.8 ask for security across the life cycle: a written standard, automated dependency and code checks in CI, protected source code (section 6.2.22) and recorded release gates. None of these regimes requires data to stay in Hong Kong. Section 19 of Cap. 653 requires an office, not local hosting, and PDPO section 33 is not in operation, but outsourcing rules still expect you to know which tools see source code and personal data.

Real public incidents in or affecting Hong Kong

The public record for Hong Kong is thinner than in some jurisdictions, because breach reporting under the PDPO is voluntary and Cap. 653 incident reports are not published. Three items from official sources give useful context.

• Cyberport ransomware attack, August 2023. The PCPD published an investigation report on 2 April 2024 into a ransomware attack on the information systems of Hong Kong Cyberport Management Company Limited. The PCPD found the personal data of more than 13,000 people was affected, identified weaknesses including ineffective detection of brute-force attacks and no multi-factor authentication for remote access, found that some data had been kept longer than necessary, and served an enforcement notice.
• Incident volumes. The SFC's 2 June 2026 circular, citing HKCERT, says recorded incidents in Hong Kong rose to 15,877 in 2025 from 12,536 in 2024.
• Concentration in shared suppliers. The July 2026 joint Cyber Mapping circular is not an incident, but it is the regulators' own account of where one supplier failure could spread.

This guide draws no conclusions about what any organisation should have done beyond what these sources say.

The personas who own the problem

CISO of a designated CI operator. Owns the plan, the unit, the 12-hour clock and the audit. The triggers are fixed by the Ordinance: three months after designation for the plan and emergency response plan, 12 months for the first risk assessment, 24 months for the first audit. Needs board-reportable status against each date and an incident playbook that starts the clock at awareness.

Head of AppSec or VP Engineering. Owns Schedule 3, item 3(f) in practice: the secure development process, the component inventory, patch timing and release gates. Needs one pipeline process that produces evidence as a by-product, not a second workflow for the auditor.

GRC and regulatory affairs. Maps every obligation to evidence: Cap. 653 sections, the sector code clauses, C-RAF references, the SFC circular paragraphs and the PDPO principles. Needs a control map and an evidence calendar tied to the designation date.

Manager-in-Charge of IT at an SFC licensee. Named as ultimately responsible in 26EC32. Needs proof that the inventory exists, patching is faster for business critical components, and incident plans have been tested.

Procurement and vendor risk. Owns Schedule 3, item 3(h), SA-2 outsourcing reviews, the SFC's section 2.10 service level agreements and the concentration questions from the Cyber Mapping exercise. Needs contract clauses, SBOM requests and a supplier register that shows where one vendor sits under several critical services.

Data protection officer. Owns DPP4 and processor contracts, and decides on voluntary breach notification to the PCPD. Needs to know which systems and components hold personal data.

Suppliers selling into Hong Kong operators. Not regulated directly, but asked for SBOMs, vulnerability notice terms and audit cooperation, and needs to answer them consistently.

A practical 30/60/90-day plan

This plan works with or without Safeguard. Adjust it to your designation date; if you were designated early in 2026, your plan and emergency response plan are already due, and your first risk assessment falls before the end of the 12 months after designation.

Days 1 to 30: know what you have and fix the clocks

1. Confirm your status in writing. Record whether you are a designated CI operator, which systems are critical computer systems, which regulating authority covers category 1 and 2 duties, and your designation date. If you are an SFC licensee, record which appendix tier applies to you.
2. Build the deadline calendar from the designation date. One month (office, unit, changes), three months (plan, emergency response plan), 12 months (risk assessment), 24 months (audit) plus three months for the report.
3. Write the incident clock into the playbook. Define "aware", who decides whether the core function is disrupted or likely to be, who notifies the Commissioner within 12 or 48 hours, and who writes the 14-day report. Run it once as a tabletop.
4. Inventory components of every critical system. Generate an SPDX or CycloneDX SBOM for each application and container image that runs on a critical computer system. Add support status and flag end-of-life components.
5. List the suppliers behind each critical system. Software vendors, cloud and managed service providers, open source projects you depend on heavily, and AI model providers.

Use this checklist the same day:

Days 31 to 60: turn inventory into decisions

1. Rank vulnerabilities by the SFC's factors. Severity, exploitability (EPSS and the CISA Known Exploited Vulnerabilities catalogue help here), external exposure, data sensitivity and system criticality. Check whether the vulnerable code is actually reachable before you spend an emergency change window.
2. Set patch tiers and record exceptions. For example, a tier for internet-facing critical systems with known exploitation, another for internal critical systems, a third for the rest. Each exception gets an owner, a reason, a compensating control and an expiry date.
3. Add a release gate. Block a release when a critical system ships a component with a known exploited vulnerability or a disallowed licence, warn on the rest, and route exceptions through an approval record.
4. Update supplier contracts at renewal. Add vulnerability notification, SBOM delivery on request, incident cooperation that fits your 12 hour clock, and audit cooperation for your section 25 audit.
5. Map AI use. Record every AI language model in use, its source (in-house, group, vendor or open source), the data it can see and whether any use is high risk under the SFC's 2024 circular.

Days 61 to 90: make it repeatable and auditable

1. Draft or refresh the security management plan against each Schedule 3 item, pointing to live evidence rather than describing it.
2. Run the risk assessment rehearsal. Vulnerability assessment and penetration test scope agreed, risk ranking method written down, tolerable risk level approved.
3. Prepare for the independent audit. Collect evidence in the form an auditor will test: inventories with dates, gate decisions, exception approvals, supplier reviews, incident drill records.
4. Close the PDPO loop. List systems holding personal data, confirm processor contracts meet DPP4(2) and DPP2(3), and decide your voluntary notification approach.
5. Report to the board. One page: obligations, dates met and due, open high-risk findings and exceptions, supplier concentration, and next quarter's plan.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh, and every capability named is GA. Safeguard helps a team produce and keep the evidence these rules ask for. It does not make an organisation compliant, it is not a regulating authority's tool, and it holds no Hong Kong certification, registration or approval.

1. Choose where Safeguard runs. SaaS is multi-region (US, EU and Gov); there is no Hong Kong region. For teams that want code and data to stay inside their own perimeter, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models running inside your environment and signed offline snapshot delivery. The air-gapped deployment docs describe signed bundles and a control plane that makes no outbound calls, which suits operators that keep critical computer systems off the internet.
2. Keep source code on your machines. The Safeguard CLI (GA) installs with curl -fsSL https://cli.safeguard.sh/install | bash. safeguard scan builds an SBOM and matches it against vulnerability databases, and safeguard validate checks CycloneDX, SPDX and VEX documents. The local runner (GA) is part of the CLI: sign in with /login, and the machine polls the platform for jobs, scans locally and uploads only results, never source code. Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets you use a provider your firm has already approved. For an SFC licensee assessing AI risk under 26EC32, being able to switch AI off is a cleaner answer than defending it.
3. Generate SBOMs for every critical system. SBOM generation and analysis (GA) produces SPDX and CycloneDX from connected repositories, container registries, uploaded manifests and AI models, with continuous scanning on push, on schedule or on release. That gives you the component inventory behind Schedule 3, item 3(e), the HKMA code's software asset record and the SFC's paragraph 6.
4. Turn on the Hong Kong PDPO framework. In Compliance, the Hong Kong PDPO framework page is on unless you switch it off in Compliance › Manage. Each product scan checks requirements tied to DPP4 (security of personal data, knowing which software components hold it, and safeguards when a data processor is engaged), DPP2 (components recorded with name and version) and DPP5 (identifiable, timestamped documentation). Catalog controls and policy templates sit alongside, and the Compliance and GRC suite (GA) keeps controls, evidence, tests, questionnaires, risks and vendors in one place. There is no dedicated framework page for Cap. 653, the HKMA codes, C-RAF or the SFC circulars, so map those clauses to controls yourself using the table earlier in this guide.
5. Rank and fix vulnerabilities. SCA with deep transitive dependency scanning (GA) and vulnerability management with EPSS and CISA KEV enrichment (GA) give you the list. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which maps to the SFC's exploitability and criticality factors. Autonomous remediation (GA) opens tested, policy-gated upgrade pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own. SAST and DAST (GA) cover first-party code and verified running targets, which supports the vulnerability assessment half of Schedule 4. They do not replace the penetration test.
6. Gate releases and record exceptions. Policies, gates and guardrails (GA) evaluate scans with Block, Warn and Notify actions, and approvals run through time-boxed exceptions. That gives an auditor under section 25 a record of what was blocked, what shipped with an approved exception, who approved it and when it expires. Policies can be written in plain English. License compliance (GA) covers SPDX expressions and attribution.
7. Collect supplier SBOMs and exploitability statements. In the Third-Party Risk Manager (GA), SBOM requests go to one vendor or many with format requirements, automatic reminders, format and completeness validation, an automatic vulnerability scan on receipt and a correction request when an SBOM falls short. CSAF and VEX upload (GA) puts a supplier's exploitability statements next to your findings. This supports Schedule 3, item 3(h), the HKMA codes' supply chain sections and the SFC's section (D).
8. Stop risky packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build.
9. Inventory and govern AI. AI-BOM discovery (GA) finds AI SDK imports, model weight files, prompts, notebooks, MCP server configuration, managed inference endpoints, vector stores and agents, and assembles them into an AI-BOM. AI-SPM (GA) scans model artifacts. AI Gateway (GA) applies prompt injection, jailbreak and PII egress guardrails to LLM calls, and runs in monitor mode by default. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access. Together they give you the AI inventory the SFC's paragraph 8 implies, whether a model came from a vendor or from open source.
10. Answer customers and auditors once. Trust Center (GA) publishes your security posture and answers questionnaires, which helps suppliers facing the same questions from several Hong Kong operators. Safeguard's own posture wording is "SOC 2 Type II audit in progress" and "designed for FedRAMP High".

What Safeguard does not do

• It does not notify the Commissioner, the PCPD or anyone else. The 12 or 48 hour notification, the 14-day report and any voluntary PDPO notice are your organisation's acts. Safeguard can hold the findings, component versions and timeline that feed them; a person files them.
• It does not perform your independent audit. Section 25 requires an independent auditor. Safeguard keeps the evidence the auditor tests; it is not the auditor and its outputs are not an audit opinion.
• It does not replace the penetration test. Schedule 4 lists a penetration test alongside the vulnerability assessment. Safeguard's scanners support the assessment; the test needs testers.
• It has no Hong Kong SaaS region and no Hong Kong certification. If code or data must stay inside your environment, use private VPC or dedicated tenancy, on-prem or air-gapped deployment, or the local runner.
• It does not inventory hardware, networks or physical controls. Critical computer systems include infrastructure no software scan sees, such as network appliances and industrial control systems. Your CMDB and network records remain the source for those.
• It does not write your security management plan or decide materiality. Framework pages and policy templates help, but whether a change is material under section 22, or whether an incident threatens the core function, is a judgment your accountable people make.
• It does not interpret the law. Requirement maps show where evidence fits. Whether a clause applies to you is a question for counsel or your regulating authority.

Common mistakes

• Starting the clock at confirmation instead of awareness. Schedule 6 runs from when the operator becomes aware of the incident. A playbook that waits for root cause will miss 12 hours.
• Counting from 1 January 2026 instead of your designation date. The one, three, 12 and 24 month deadlines run from each operator's designation date.
• Treating the security management plan as a document exercise. Schedule 5 asks the auditor whether the plan is implemented. A plan that describes controls nobody runs will fail the audit.
• Leaving suppliers out of the plan. Schedule 3, item 3(h) puts supplier contracts inside the plan. Renewals are the cheapest moment to add vulnerability notice and audit cooperation.
• Reading the SFC appendix as optional. For large retail brokers, Type 13 depositaries and virtual asset trading platforms, the SFC says it generally expects all the measures.
• Inventorying servers but not components. The SFC asks for software and third-party components, and the HKMA code asks for software name, publisher and version. A server list does not tell you which systems carry a vulnerable library.
• Assuming the PDPO requires local hosting. It does not today, but processor contracts under DPP4(2) still have to bind any vendor that touches personal data.

FAQ

What is Hong Kong's critical infrastructure cybersecurity law?

The Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653), enacted as Ordinance No. 4 of 2025 and in operation since 1 January 2026. It places organisational, preventive and incident reporting duties on organisations designated as CI operators, for the computer systems designated as critical computer systems.

Which sectors does Cap. 653 cover?

Schedule 1 lists energy, information technology, banking and financial services, air transport, land transport, maritime transport, healthcare services, and telecommunications and broadcasting services. Only designated operators within those sectors carry the duties.

How fast must a CI operator report a cyber incident in Hong Kong?

Within 12 hours of becoming aware, if the incident has disrupted, is disrupting or is likely to disrupt the core function of the infrastructure; within 48 hours otherwise. A written report goes to the Commissioner within 14 days of awareness.

Is an SBOM mandatory in Hong Kong?

No rule uses the term. The SFC's June 2026 circular asks for an accurate, up-to-date inventory of technology components including software, the HKMA's codes ask for software name, publisher and version, and Cap. 653's Schedule 3 asks you to secure all components of critical systems. An SBOM is the most practical way to meet all three.

Does Hong Kong have an AI law?

Not a dedicated statute. AI risk is governed through regulator guidance: the SFC's November 2024 and June 2026 circulars, the HKMA's June 2026 letter, and the PDPO with the PCPD's guidance on AI and personal data.

Must data be stored in Hong Kong?

Not under these regimes. Cap. 653 requires an office in Hong Kong, not local hosting, and the PDPO's cross-border transfer section has not been brought into operation. Sector outsourcing rules still expect you to control where data goes.

Can Safeguard run without our code leaving our environment?

Yes. The GA options are the local runner, which scans on your machines and uploads only results, plus private VPC, on-prem and fully air-gapped deployment, with Zero AI mode if no LLM may be in the loop. There is no Hong Kong SaaS region.

Before you fix anything

Every rule in this guide comes back to one question: when a component in a critical computer system is vulnerable, how fast does a tested fix reach production, and what do you do while no upstream fix exists? The section below covers how Safeguard approaches both.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session that fixes a vulnerable dependency in a repository. It reads the finding and advisory, asks before any command that changes something, edits the manifest, runs the install and tests with approval, and pushes nothing. That is the shape of the expedited, recorded fix the SFC's June 2026 circular asks for.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it, and scans from the terminal. For Hong Kong banks, brokers and CI operators that will not grant repository access to an outside platform, this is how SBOMs and findings are produced while source code stays on your systems.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows the kind of scoped agent access worth recording in an AI inventory when a regulator asks which models and agents touch your systems.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Protection of Critical Infrastructures (Computer Systems) Ordinance, Ordinance No. 4 of 2025 (Legislative Council)
• Office of the Commissioner of Critical Infrastructure (Computer-system Security): Code of Practice
• HKMA: Code of Practice for Stored Value Facility Licensees designated as CI operators, 12 June 2026
• HKMA: TM-C-1 Supervisory Approach on Cyber Risk Management (repository listing)
• HKMA: Strengthening Cyber Resilience amid Artificial Intelligence-Empowered Cyber Threats, 2 June 2026
• SFC: Guidelines for Reducing and Mitigating Hacking Risks Associated with Internet Trading
• SFC: Circular on enhanced cybersecurity measures for AI-enabled cyberattacks, 2 June 2026 (26EC32)
• SFC: Appendix to circular 26EC32
• HKMA, SFC, IA and MPFA: Joint Circular on the Cross-Sectoral Cyber Mapping Exercise, 29 July 2026
• PCPD: The Ordinance at a glance
• PCPD: Investigation report on the Cyberport ransomware attack, 2 April 2024
• Safeguard docs: Hong Kong PDPO framework
• Safeguard docs: CLI
• Safeguard docs: Local runner
• Safeguard docs: Air-gapped deployment
• Safeguard docs: AI-BOM discovery
• Safeguard docs: TPRM SBOM requests

Related reading from this series: Japan software supply chain and AI security rules, India software supply chain and AI security rules and Saudi Arabia software supply chain and AI security rules.

To try it, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.