Technical Due Diligence for Pre-IPO Companies: Assessing System Architecture and Code Quality

The SFC’s 2024-25 enforcement report, published in April 2025, recorded 194 active investigations into listing-related misconduct, with 38% specifically targeting deficiencies in issuer systems and internal controls — a 12 percentage point increase from the prior year. This escalation directly impacts the Pre-IPO due diligence process. For CFOs and sponsors preparing a company for a Hong Kong Main Board listing, technical due diligence (TDD) is no longer a supplementary check; it has become a core component of the sponsor’s reasonable inquiry obligation under HKEX Listing Rule 21.05 and the SFC’s Code of Conduct for Persons Licensed by or Registered with the SFC (the Code), specifically paragraph 17.6. The market now expects a formal, documented TDD process that assesses system architecture, code quality, and cybersecurity posture, not merely a cursory review of IT headcount. This article provides a practical framework for executing that TDD, with a focus on the specific technical areas that HKEX and the SFC scrutinise during the vetting process.

The Regulatory Mandate for Technical Due Diligence

The SFC’s December 2023 consultation conclusions on the Sponsor Regulation (Cap. 571V) explicitly expanded the definition of “reasonable inquiry” to include an assessment of the issuer’s IT infrastructure and data integrity controls. This is not a soft guideline; it is a codified obligation. The SFC’s 2024 thematic review of IPO sponsors found that 22 of 35 reviewed files contained “inadequate or absent” documentation of system architecture assessments, leading to enforcement referrals in 6 cases.

Sponsor Liability Under the Code of Conduct

Paragraph 17.6 of the SFC’s Code of Conduct requires sponsors to “take all reasonable steps to ensure that the listing document contains all information necessary to enable an investor to make an informed assessment of the issuer’s business.” For a technology-dependent issuer — which now includes most financial services, logistics, and retail companies — this necessarily includes an evaluation of the systems that generate the issuer’s core financial and operational data. The HKEX’s Guidance Letter GL57-13 (updated December 2024) further clarifies that sponsors must document the scope, methodology, and findings of any technical review, and must retain this documentation for at least seven years post-listing.

The 2024-25 Enforcement Shift

The SFC’s focus on system architecture is not abstract. In its 2024 enforcement action against the sponsor of a failed biotech listing, the SFC cited the sponsor’s failure to verify the issuer’s laboratory data management system (LDMS) as a key deficiency. The issuer had overstated its R&D output by 23% due to a software configuration error that the sponsor’s TDD process did not catch. The sponsor received a reprimand and a HKD 12 million fine. This case establishes a clear precedent: the SFC expects sponsors to test the system, not just interview the CTO.

Core Components of a Pre-IPO Technical Due Diligence

A robust TDD process for a Hong Kong IPO should be structured around three primary domains: system architecture, code quality and security, and data integrity and migration controls. Each domain requires specific documentation and testing protocols.

System Architecture Assessment

The TDD team must map the issuer’s entire technology stack, from front-end user interfaces to back-end databases and third-party API integrations. This map should be presented as a formal architecture diagram, version-controlled and signed off by the issuer’s CTO. The assessment must answer three questions: (i) Is the architecture scalable to handle the expected post-IPO transaction volume? (ii) Are there single points of failure that could cause a material business interruption? (iii) Is the architecture compliant with HKMA’s Supervisory Policy Manual (SPM) module SA-2 on “Outsourcing” if the issuer uses cloud services? For issuers with operations in the PRC, the TDD must also assess compliance with the PRC Cybersecurity Law (effective June 2017) and the Personal Information Protection Law (PIPL, effective November 2021), specifically regarding data localisation requirements. A failure to document these compliance checks can lead to a rejection of the listing application under HKEX Listing Rule 8.04.

Code Quality and Security Review

The SFC does not require a full source code audit, but the sponsor must demonstrate that it has reviewed the codebase for material risks. The TDD should include a static application security testing (SAST) scan using a recognised tool (e.g., SonarQube, Checkmarx). The scan report must be reviewed for critical and high-severity vulnerabilities. The SFC’s 2024 guidance on “Technology Risk Management for Listed Issuers” recommends that any issuer with more than 50 software developers maintain a formal code review process, with at least two independent reviewers per pull request. The TDD team should obtain evidence of this process, including a sample of pull request logs for the 12 months preceding the listing application. For issuers using open-source components, a software bill of materials (SBOM) must be produced and reviewed for known vulnerabilities (CVEs) with a CVSS score of 7.0 or higher. The sponsor must document the remediation plan for any identified vulnerabilities, including a timeline for deployment.

Data Integrity and Migration Controls

This is the area most directly tied to financial reporting. The TDD must verify that the issuer’s core transaction systems (e.g., ERP, CRM, payment gateways) produce data that reconciles to the financial statements in the prospectus. The SFC expects a formal data mapping exercise that traces each line item in the income statement back to a specific database table or API endpoint. For issuers that have undergone a system migration in the 24 months before listing, the TDD must include a parallel run test. The test should compare data from the legacy system and the new system for a minimum of three months of transaction data. The acceptable tolerance for discrepancies is 0.1% of total transaction value, per the HKEX’s guidance on financial data integrity in the 2023 update to the Listing Rules. Any variance above this threshold must be explained in the sponsor’s due diligence report and may trigger a requirement for a qualified audit opinion on the internal controls.

Practical Execution: Scope, Timing, and Documentation

Executing a TDD that satisfies HKEX and SFC standards requires careful planning on scope, timing, and documentation. The sponsor should not treat TDD as a standalone workstream; it must be integrated into the overall due diligence plan from the start of the engagement.

Scoping the TDD Engagement

The scope of the TDD should be defined in a formal engagement letter between the sponsor and the TDD provider (which may be an internal IT audit team or an external firm). The letter must specify the systems in scope, the testing methodology, the acceptance criteria for findings, and the reporting format. The HKEX’s Guidance Letter GL57-13 recommends that the scope cover at least the following: (i) all systems that generate data included in the prospectus financials, (ii) all systems that handle customer personal data, (iii) all systems that process payments, and (iv) all systems that are critical to the issuer’s business continuity. For issuers with a material PRC operations, the scope must also include the systems that store data subject to PIPL or the Cybersecurity Law.

Timing and Integration with the IPO Timeline

The TDD should commence no later than six months before the expected A1 filing date. This timeline allows for the identification of material issues and their remediation before the sponsor issues its final due diligence report. The TDD findings should be presented to the audit committee at least 90 days before the filing date. The sponsor must retain all TDD documentation, including raw scan reports, architecture diagrams, and remediation plans, for a minimum of seven years from the date of the listing, as required by the SFC’s record-keeping obligations under the Code of Conduct, paragraph 17.8.

Documentation Standards for the Sponsor’s Report

The sponsor’s TDD report should follow a standardised format. The HKEX does not prescribe a specific template, but market practice, as established by the Big Four accounting firms’ 2024 guidance on IPO due diligence, includes the following sections: (i) Executive Summary with a materiality assessment, (ii) Scope and Methodology, (iii) System Architecture Findings, (iv) Code Quality and Security Findings, (v) Data Integrity Findings, (vi) Remediation Plan and Status, and (vii) Conclusion on the issuer’s readiness for listing. Each finding must be rated on a three-tier scale: Critical, High, or Medium. Critical findings — those that could result in a material misstatement of the prospectus or a breach of law — must be resolved before the sponsor can issue a clean due diligence report. The SFC’s 2024 enforcement report specifically notes that a failure to escalate critical findings to the board is a breach of the sponsor’s duties under the Code.

Common Pitfalls and How to Avoid Them

Based on the SFC’s enforcement actions and the HKEX’s rejection letters from 2023 and 2024, three common pitfalls emerge: scope gaps, insufficient testing of third-party systems, and inadequate documentation of remediation.

Scope Gaps: The Shadow IT Problem

A recurring issue in SFC enforcement cases is the failure to identify “shadow IT” — systems that are used by the issuer’s business units but are not under the control of the central IT department. In a 2023 enforcement action against a fintech issuer, the SFC found that the issuer’s loan origination system had been built and maintained by a business unit without any involvement from the CTO. The system had no audit trail, no access controls, and no backup. The sponsor’s TDD had missed it entirely. To avoid this, the TDD team must conduct a comprehensive discovery exercise, including interviews with department heads and a review of all software procurement records for the past three years. The sponsor should also run a network scan to identify all devices and servers connected to the issuer’s network.

Insufficient Testing of Third-Party Systems

Many issuers rely on third-party SaaS platforms for core functions such as payment processing, customer relationship management, and human resources. The TDD must assess these platforms as if they were internal systems. The sponsor should request a SOC 2 Type II report from each material third-party provider. If the provider does not have a SOC 2 report, the sponsor must conduct its own assessment, including a review of the provider’s data centre, access controls, and incident response plan. The HKEX’s 2024 update to the Listing Rules on outsourcing (effective 1 January 2025) requires that any issuer that outsources a material business function to a third party must include a risk assessment of that third party in its listing documents. The TDD must provide the basis for that risk assessment.

Inadequate Documentation of Remediation

Even when a TDD identifies issues, the SFC has found that sponsors often fail to document the remediation process adequately. In a 2024 case, the sponsor’s TDD report noted 12 critical vulnerabilities in the issuer’s payment gateway. The issuer claimed to have fixed all 12, but the sponsor did not re-test the system. The SFC fined the sponsor HKD 8 million for failing to verify remediation. The correct approach is to require the issuer to provide a formal remediation plan with a timeline, then re-run the SAST scan and the parallel run test after the fixes are deployed. The re-test results must be documented in a supplementary TDD report, signed off by the sponsor’s engagement partner.

Actionable Takeaways for CFOs and Sponsors

1. Integrate TDD into the due diligence plan from Day 1 — do not treat it as a last-minute compliance checkbox; the SFC’s enforcement data shows that late TDD is the single largest predictor of sponsor liability.

2. Demand a formal architecture diagram and a software bill of materials (SBOM) from the issuer at the start of the engagement; these are the foundational documents that the HKEX review team will request during the vetting process.

3. Insist on a parallel run test for any system migration that occurred within the 24 months before filing — the 0.1% tolerance threshold for data discrepancies is a hard line, not a guideline.

4. Document every remediation step, including the re-test results, in a supplementary TDD report that is retained for at least seven years post-listing; the SFC’s 2024 enforcement actions confirm that the failure to re-test is a breach of the sponsor’s duties.

5. Verify that the TDD scope explicitly covers all third-party SaaS platforms and shadow IT systems — a network scan and a review of software procurement records are the minimum tools required to identify these risks.