SFC IT Risk Management for Financial Institutions: System Development and Change Management

The Securities and Futures Commission (SFC) has sharpened its focus on information technology (IT) risk management for licensed corporations. The catalyst was the series of major system outages and cybersecurity incidents at several Hong Kong brokers between 2022 and 2024, which exposed critical weaknesses in system development lifecycle (SDLC) controls and change management processes. In its 2024-25 enforcement priorities, the SFC explicitly stated that it would scrutinise firms’ IT governance, specifically the controls around system upgrades, patch management, and new application deployments. For any licensed corporation or applicant, a failure to demonstrate a robust SDLC and change management framework is now a direct pathway to licence conditions, fines, or licence refusal. The SFC’s Guidelines on Cybersecurity (2023) and the Code of Conduct for Persons Licensed by or Registered with the SFC (Cap. 571, subsidiary legislation) provide the binding framework. This article outlines the specific procedural requirements for system development and change management that every financial institution must implement.

The Regulatory Framework: SFC Guidelines and the Code of Conduct

The SFC does not operate in a vacuum. Its IT risk management expectations are grounded in two primary instruments: the Guidelines on Cybersecurity (the Guidelines) and the Code of Conduct for Persons Licensed by or Registered with the SFC (the Code). The Guidelines, issued in 2023, replaced the earlier 2017 circular on cybersecurity. They apply to all licensed corporations (LCs) and associated entities registered with the SFC.

The Guidelines mandate a formal IT governance structure. Paragraph 4.1 of the Guidelines requires that the board of directors or an equivalent governing body approve the firm’s IT risk management strategy. This is not a delegation to the IT department. The board must document its approval of the IT risk appetite, the system development policy, and the change management policy. The SFC’s 2024 Annual Report noted that in 23% of on-site inspections, the board had not formally reviewed or approved the IT risk framework.

The Code of Conduct imposes a general obligation on licensed persons. Paragraph 2.1 of the Code requires every licensed person to “act with due skill, care and diligence.” The SFC has interpreted this to include the duty to maintain reliable and secure IT systems. A failure to properly manage a system change that results in a trading outage or data loss is a breach of this fundamental duty. The SFC’s Enforcement Division has made clear that it will pursue disciplinary action under Section 194 of the Securities and Futures Ordinance (Cap. 571) for such breaches.

The Guidelines on the Management of Information Technology (2019) remain relevant. Although the Cybersecurity Guidelines are the primary document, the earlier 2019 guidelines on IT management still provide detailed expectations for SDLC. They require a formal project management methodology, segregation of duties between development and production, and documented testing phases. All three documents must be read together by compliance officers.

Step 1: Establishing a Formal System Development Lifecycle (SDLC) Policy

The SFC expects every licensed corporation to have a written SDLC policy. This policy must cover all stages of a system’s life: planning, analysis, design, development, testing, deployment, and maintenance. The policy must be approved by the board and reviewed annually.

The policy must define governance roles. The SFC’s 2023 Guidelines, at Paragraph 5.1, require that the policy assign clear responsibility for each stage. The business owner is responsible for defining requirements. The development team is responsible for coding. The quality assurance (QA) team is responsible for independent testing. The IT operations team is responsible for production deployment. No single individual should control more than one of these roles for any given change. This is a segregation of duties requirement.

The policy must mandate a risk classification for each system change. The SFC does not prescribe a specific classification system, but it expects one. A common approach is to classify changes as “standard” (no impact on trading, settlement, or client data), “major” (impact on a critical function), or “emergency” (immediate fix for a live production issue). For each classification, the policy must prescribe a different approval path and testing rigour. A standard change may require only a manager’s approval. A major change must require sign-off from the business head, the IT head, and the compliance officer.

The policy must require a formal testing phase. Paragraph 6.2 of the Guidelines requires that all system changes be tested in a non-production environment before deployment. The testing must include functional testing, integration testing, and user acceptance testing (UAT). The results of UAT must be documented and signed off by the business owner. The SFC’s 2024 inspection findings revealed that 12% of LCs had no documented UAT sign-off for at least one major system change in the preceding 12 months.

Step 2: Implementing a Rigorous Change Management Process

Change management is the operational heart of IT risk control. The SFC’s expectation is that every change to a production system is controlled, documented, and auditable. The process must apply to software updates, hardware configuration changes, database schema changes, and third-party vendor patches.

The process must include a formal change request (CR) system. Every change must be logged in a CR system. The CR must contain: the change description, the business justification, the risk classification, the planned implementation date and time, the rollback plan, and the names of the approvers. The SFC’s Guidelines on Cybersecurity at Paragraph 7.1 require that all CRs be retained for at least two years after implementation.

The process must require a pre-implementation review. Before any change is deployed to production, a designated reviewer (who is not the developer or the implementer) must verify that the change meets the requirements, that all tests have passed, and that the rollback plan is viable. This reviewer is typically the QA lead or a senior IT manager. The SFC’s 2023 circular on IT incidents noted that 40% of reported incidents were caused by changes that bypassed this review step.

The process must mandate a post-implementation review (PIR). Within five business days of a major change, the firm must conduct a PIR. The PIR must confirm that the change achieved its intended outcome, that no new vulnerabilities were introduced, and that all documentation is updated. The PIR report must be filed to the IT risk committee. The SFC has stated that it will request PIR reports during routine inspections.

Emergency changes require an expedited but still controlled process. An emergency change—such as a critical security patch—cannot wait for the full approval chain. However, the SFC expects that the firm still logs the change, obtains at least verbal approval from the IT head, and documents the reason for the emergency. A full retrospective review must be completed within 72 hours of the emergency change.

Step 3: Managing Third-Party System Development and Vendor Risk

Many licensed corporations outsource system development to third-party vendors. The SFC’s expectations do not diminish when the work is outsourced. The licensed corporation remains fully responsible for the vendor’s compliance with the SFC’s IT risk requirements.

The firm must conduct due diligence on the vendor. Paragraph 9.1 of the Guidelines requires that the firm assess the vendor’s financial stability, security posture, and track record. The due diligence must be documented and updated annually. The SFC’s Outsourcing Guidelines (2019) further require that the firm’s board approve the outsourcing arrangement.

The contract must include specific IT risk clauses. The service level agreement (SLA) must specify: the vendor’s obligation to follow the firm’s SDLC policy, the vendor’s obligation to provide access to its systems for audit, the vendor’s obligation to notify the firm immediately of any security incident, and the vendor’s obligation to maintain data in Hong Kong or a jurisdiction with equivalent data protection laws. The SFC’s 2024 Thematic Review on Outsourcing found that 18% of SLAs lacked a mandatory breach notification clause.

The firm must retain the right to audit the vendor. The contract must grant the firm—or its appointed auditor—the right to conduct on-site or remote audits of the vendor’s development and change management processes. The SFC expects that these audits occur at least once every two years for critical vendors. The audit report must be submitted to the firm’s IT risk committee.

The firm must test the vendor’s code before production deployment. Even if the vendor develops the code, the firm’s own QA team must conduct independent testing. The SFC’s Guidelines on Cybersecurity at Paragraph 6.4 explicitly state that “a licensed corporation cannot rely solely on the vendor’s testing results.” The firm must perform its own functional and security testing in a non-production environment.

Step 4: Documentation, Audit Trails, and Board Reporting

The SFC’s enforcement actions consistently show that a firm’s failure to document its IT risk controls is treated as a control failure in itself. If it is not written down, it did not happen.

All SDLC and change management activities must be logged. The firm must maintain an audit trail that records: who requested a change, who approved it, who developed it, who tested it, who implemented it, and when. The audit trail must be tamper-proof. The SFC’s Code of Conduct at Paragraph 16.1 requires that all records be retained for at least seven years.

The board must receive a quarterly IT risk report. The report must include: the number of changes implemented, the number of failed changes, the number of emergency changes, the results of PIRs, and any incidents or near-misses. The board must formally minute its review of this report. The SFC’s 2023 Guidelines at Paragraph 4.3 require that the board “challenge management on the effectiveness of IT risk controls.”

The firm must conduct an annual independent audit of its IT risk framework. The audit must be performed by an internal audit function that is independent of the IT department, or by an external auditor. The audit scope must include a review of the SDLC policy, the change management process, and a sample of actual change records. The audit findings must be reported to the board and to the SFC upon request.

Closing: Five Actionable Takeaways

1. The SFC now treats a documented, board-approved SDLC policy as a baseline requirement, not a best practice—any licensed corporation without one is non-compliant.
2. Segregation of duties between development, testing, and deployment is mandatory; a single person controlling two stages for a single change is a red flag that the SFC will pursue.
3. All changes, including emergency patches, must be logged in a formal change request system with a documented rollback plan and a post-implementation review.
4. Outsourcing system development does not transfer regulatory liability—the licensed corporation must independently test all vendor code before production deployment.
5. The board must receive and formally minute a quarterly IT risk report that includes change management metrics, incident summaries, and audit findings.

This does not constitute legal advice. Consult a solicitor for your specific case.