Why Hong Kong Companies Are Bundling MSP, MSSP, and HKMA/C-RAF Support Into One Contract

TL;DR: A pattern has become common in Hong Kong procurement over the past several years: companies — particularly those that are themselves HKMA-regulated authorized institutions (AIs), or that sell technology and services into one — are issuing a single RFP that asks one vendor to deliver managed IT (MSP), managed security (MSSP), and support for HKMA cybersecurity supervision and the Cyber Resilience Assessment Framework (C-RAF), rather than running three separate procurements. This is not a marketing trend; it follows directly from how the Hong Kong Monetary Authority's Supervisory Policy Manual treats outsourcing, technology risk, and cyber resilience as a single accountability chain that the regulated institution can never fully delegate. This report explains the regulatory mechanics behind that shift, what C-RAF actually requires in its own documented structure, what each of the three procurement categories concretely means in practice, and — just as importantly — where the line sits between what a technology and security vendor can honestly do for a client and what remains the client's own non-delegable regulatory responsibility.

Key Findings

• The bundling pattern is a rational response to HKMA's outsourcing supervision, not a vendor sales tactic — the Supervisory Policy Manual's outsourcing module makes clear an authorized institution can outsource activity, never accountability.
• C-RAF is not a single test; it is a three-part assessment sequence — an Inherent Risk Assessment, a Maturity Assessment against defined control domains, and, for higher-risk institutions, Cyber-attack Simulation Testing (CAST).
• "MSP" and "MSSP" are not separable the way a two-vendor procurement implies — backup/recovery, endpoint management, and infrastructure operations are inseparable from endpoint security, threat detection, and incident response in practice.
• No vendor can complete, attest to, or submit a C-RAF assessment on a regulated institution's behalf — that is the institution's own board- and senior-management-level accountability.
• The organizational bar to responsibly bid on a bundled contract is higher than an MSP or MSSP bid alone: integrated operations, evidence built into daily delivery rather than assembled after the fact, and explicit contractual clarity on where the provider's responsibility ends.

The Pattern: One RFP, Three Historically Separate Disciplines

A real Hong Kong company's recent RFP — the kind of document that circulates among managed service providers in the territory rather than one written for public consumption — asked a single vendor to cover, side by side and under one contract:

• MSP services: managed IT service, on-site support, infrastructure management, cloud support, backup and recovery services.
• MSSP services: SOC-as-a-service, threat detection and monitoring, vulnerability assessment, penetration testing, endpoint security, email security, network security, security awareness training.
• Regulatory and cyber resilience support: HKMA cybersecurity-related regulatory support, C-RAF assessment support, incident response plan/playbook development and tabletop exercise support, documentation and evidence preparation, gap analysis and remediation recommendations, and assistance responding to HKMA enquiries and reviews.

Five years ago, this would very plausibly have been three RFPs, awarded to three vendors: an IT outsourcer for the desktop-and-server work, a security boutique for the SOC and penetration testing, and — quite often — a Big Four or specialist advisory firm for the regulatory and C-RAF piece, billed at advisory day rates rather than managed-service rates. Seeing all three folded into one procurement is a genuine shift, and it is worth being precise about why it is happening, because the reason shapes what a responsible vendor can and cannot promise in response.

This report treats the pattern as directionally real based on Brocent's own experience being asked to respond to RFPs shaped this way, not on a public survey — no survey of Hong Kong IT procurement structure of this kind is known to exist, and where this report describes a trend rather than a documented statistic, it says so explicitly.

Why Now: How HKMA's Supervisory Framework Actually Creates This Incentive

To understand why a company would bundle these three categories into one contract, it helps to look past the RFP itself and at the supervisory mechanics that produced the buying behavior.

The Supervisory Policy Manual treats technology risk as a single accountability chain

The HKMA supervises authorized institutions (banks and deposit-taking companies licensed under the Banking Ordinance) primarily through its Supervisory Policy Manual (SPM) — a modular set of supervisory guidance covering everything from capital adequacy to corporate governance to technology risk. Two SPM modules are most relevant here, and it is worth being precise about how confidently this report can speak to them: HKMA periodically revises module content and, less often, module codes and titles, so the description below reflects the structure that has been consistently and publicly documented, without asserting a specific current revision date for either module.

• The module commonly referenced as TM-G-1, "General Principles for Technology Risk Management," sets the baseline expectation that an authorized institution's board and senior management remain accountable for technology risk regardless of how much of the actual technology operation is run by third parties — the source of the "you can delegate the work, not the accountability" framing that recurs throughout HKMA's technology-risk guidance.
• The module commonly referenced as SA-2, "Outsourcing," governs what an authorized institution must do before, during, and after it hands any material function to a third party — due diligence on the vendor, a written agreement preserving the institution's (and the regulator's) right to audit and access records, contingency planning if the vendor fails, and ongoing monitoring of the vendor's performance and control environment. Crucially, SA-2's logic does not stop at the institution's own outsourcing decision: because the institution remains accountable for the outsourced function's risk, its due diligence and monitoring obligations extend to understanding how its vendor manages security and resilience, not just whether the vendor delivers the contracted service on time.

Put together, these two modules mean that a bank's MSP and its MSSP are not, from HKMA's perspective, simply two service contracts running in parallel. They are both instances of the same outsourcing relationship the SA-2 module governs, and both are within scope of the same board-level technology-risk accountability TM-G-1 describes. A bank's internal compliance and risk teams increasingly recognize this and, rather than running two outsourcing due-diligence processes on two vendors whose work is operationally intertwined anyway, prefer to run one.

The Cybersecurity Fortification Initiative gave this accountability chain a concrete assessment tool

In May 2016, the HKMA launched the Cybersecurity Fortification Initiative (CFI), a program aimed specifically at raising the cyber resilience of Hong Kong's banking sector following a period of rising cyberattack activity against banks regionally. CFI was built around three pillars, and this three-pillar structure is well and consistently documented in HKMA's own public materials:

• The Cyber Resilience Assessment Framework (C-RAF) — a structured, self-assessment-based methodology banks use to evaluate their own cyber resilience, described in detail below.
• The Professional Development Programme (PDP) — a certification and training track, developed with the Hong Kong Institute of Bankers and the Hong Kong Applied Science and Technology Research Institute (ASTRI), intended to grow a pool of qualified cybersecurity practitioners serving the banking sector.
• The Cyber Intelligence Sharing Platform (CISP) — a platform for banks to share cyber-threat intelligence with each other and with the HKMA, on the premise that no single institution sees the whole threat picture alone.

The HKMA has continued to refine CFI and C-RAF since 2016; industry commentary sometimes refers to later iterations informally as "C-RAF 2.0" or similar. This report does not assert a specific current version number or revision date, since that detail changes over time and any reader relying on it for a live submission should confirm current requirements directly against HKMA's own published materials. What has remained stable across the framework's public description since 2016 is the three-component structure of C-RAF itself, described next.

Why a vendor gets pulled into scope even when it isn't the regulated entity

A meaningful share of the companies issuing RFPs shaped like the one this report is built on are not themselves banks — they are companies that sell services, software, or infrastructure to banks, or operate in adjacent regulated space and want to demonstrate a comparable control posture to counterparties who ask. SA-2's flow-down logic explains why: if a bank's own outsourcing due diligence routinely asks its vendors "can you show us your own security operations and evidence trail," any company selling into Hong Kong's banking sector has a commercial reason to answer that question credibly — which gives it its own reason to want an MSP/MSSP arrangement built with C-RAF-style evidence in mind from day one, rather than assembled retroactively when a bank customer's due-diligence questionnaire lands on their desk.

What C-RAF Actually Is: Three Components, Not One Test

C-RAF is frequently referred to informally as "the HKMA cybersecurity assessment," which understates what it actually is. In HKMA's own public description, it is composed of three distinct components, applied in sequence, each producing a different kind of output.

Component one: Inherent Risk Assessment

The Inherent Risk Assessment establishes how much cyber risk an institution carries by its nature — before considering any controls it has in place. It looks at factors such as the institution's technology footprint (number and type of connections, delivery channels, and technologies in use), the products and services it offers (particularly anything involving payments or third-party connectivity), its organizational characteristics (staffing, past history of incidents, mergers and acquisitions activity), and the external threat environment it operates in. The output is a risk tier — commonly described publicly as a low, medium, or high inherent risk categorization — that determines how rigorously the institution needs to complete the next two components.

Component two: Maturity Assessment

The Maturity Assessment evaluates the institution's actual cybersecurity controls against a defined set of control domains, and rates the maturity of each domain against defined maturity levels (commonly described in HKMA materials and industry commentary as a progression from a baseline level through intermediate to advanced maturity). This is the component that most resembles a conventional security-controls assessment, and it is structurally similar in spirit to control-domain maturity models used elsewhere in the industry, such as the US FFIEC's Cybersecurity Assessment Tool, which HKMA's own framework has been publicly described as having drawn conceptual inspiration from. The institution's required maturity level in each domain is calibrated against the inherent risk tier established in component one — a high-inherent-risk institution is expected to demonstrate a higher maturity level than a low-risk one.

Component three: Cyber-attack Simulation Testing (CAST)

For institutions whose inherent risk and maturity profile places them in scope, C-RAF's third component is Cyber-attack Simulation Testing — a live, threat-intelligence-led simulated attack against the institution's actual production environment, conducted by a qualified, typically independent testing team, designed to replicate the tactics of a realistic adversary rather than a generic penetration test. This is conceptually related to threat-intelligence-based red-teaming frameworks used by other regulators internationally (the UK's CBEST and the EU-wide TIBER-EU framework are the most commonly cited analogues), and HKMA's own materials describe it in similar terms — intelligence-led, scenario-based, and intended to test real detection and response capability rather than simply catalogue vulnerabilities. Not every institution is required to run CAST; it is generally reserved for those whose risk profile under components one and two places them there, and it is understood to require close coordination between the institution, its internal teams, and any external testing and response support it brings in.

What this three-part structure means for a supporting vendor

Each component asks something different of a vendor supporting the process, and conflating them is one of the more common ways an RFP response overstates what a vendor can deliver:

• Inherent Risk Assessment is primarily an internal exercise about the institution's own business and technology footprint. A vendor's honest contribution here is factual input about the technology environment it operates or supports — not a determination of the institution's risk tier, which is the institution's own judgment to make.
• Maturity Assessment is where a vendor with deep visibility into the institution's actual technical environment can contribute the most — supplying evidence of control implementation, helping map existing tooling and processes against the assessed control domains, and identifying gaps. It remains the institution's assessment; the vendor supplies the evidentiary and technical groundwork underneath it.
• CAST, where applicable, is typically run by specialist, often independent, testing providers precisely because independence from day-to-day operations matters to the exercise's credibility — an MSP/MSSP that operates the environment day to day is generally not the right party to also simulate attacking it, though it is very much the right party to be the one detecting and responding to the simulated attack, since that response capability is exactly what CAST is testing.

Deconstructing the Three RFP Categories: What Each One Actually Requires

RFP line items compress a great deal of operational reality into a few words. It is worth unpacking what "on-site support" or "SOC-as-a-service" actually obligates a provider to build and staff.

MSP services: the operational backbone

• Managed IT service and infrastructure management mean continuous responsibility for the health of servers, network equipment, directory services, and the applications the business runs on — not a help desk that reacts to tickets, but a team monitoring capacity, patch levels, and configuration drift on an ongoing basis, with defined service levels for both routine requests and outages.
• On-site support means a physical presence model — whether a dedicated on-site engineer, a scheduled rotation, or a rapid-dispatch arrangement — for the categories of problem that genuinely cannot be resolved remotely: hardware failure, network cabling, new-office setup, and situations where a regulator or auditor wants to see a person, not a remote session.
• Cloud support means operational ownership of whatever combination of Microsoft 365, Azure, AWS, or other cloud platforms the institution runs on — identity and access configuration, backup of cloud-resident data (which many organizations wrongly assume their cloud vendor already handles by default), cost and capacity management, and security configuration of the cloud tenant itself.
• Backup and recovery services mean a tested, documented recovery capability, not just a backup job that runs and reports success. In a regulated-institution context this specifically means the provider can demonstrate — with evidence, not assurance — that a recovery was actually tested and how long it took, because recovery time and recovery point objectives are exactly the kind of control detail a C-RAF maturity assessment or an HKMA review will ask about.

MSSP services: the security operating layer

• SOC-as-a-service means continuous (typically 24x7, though the exact coverage model should be specified in the contract rather than assumed) monitoring of security events across the environment, with defined triage and escalation procedures — the difference between a genuine SOC and a marketing label is usually visible in whether the provider can show a real escalation runbook and real historical response-time data, not just a dashboard.
• Threat detection and monitoring means the technical capability — typically an endpoint detection and response (EDR) platform combined with log aggregation and correlation (a SIEM or equivalent) — to actually see anomalous activity across endpoints, network, and cloud, not merely to collect logs that nobody reviews.
• Vulnerability assessment means a recurring (not one-time) scanning and prioritization discipline across the institution's technology estate, producing a tracked remediation backlog rather than a point-in-time report that gets filed away.
• Penetration testing means periodic, scoped, adversarial testing of specific systems or the network perimeter — distinct from CAST discussed above, and typically narrower in scope and less threat-intelligence-driven, though the two disciplines are complementary.
• Endpoint security means both preventive tooling (antivirus/EDR) and the operational discipline of keeping it deployed, updated, and actually functioning across every device in the fleet — a control that is trivial to claim and surprisingly common to have silently degraded on a meaningful percentage of any real device fleet.
• Email security means layered defense against phishing, business email compromise, and malicious attachments — a category worth naming specifically because email remains, by wide industry consensus, one of the most common initial-access vectors for the kind of incident C-RAF and HKMA's incident-reporting expectations are ultimately concerned with.
• Network security means firewall management, segmentation, and monitoring of traffic at the network boundary and increasingly within it, given how much lateral movement modern intrusions rely on.
• Security awareness training means a recurring program, not a once-a-year slideshow — phishing simulation, measurable completion tracking, and content that changes as the threat landscape does, because this is one of the few controls in the whole list that C-RAF's maturity model and most control frameworks explicitly expect to see evidenced as an ongoing program rather than a completed task.

Regulatory and cyber resilience support: the category that requires the most honesty

This is the category where the line between legitimate vendor support and overreach matters most, and it deserves to be discussed with more care than a bullet list.

• HKMA cybersecurity-related regulatory support can honestly mean a vendor helping the institution understand what a piece of HKMA guidance implies for its technical environment, and helping translate that into concrete technical and procedural changes. It cannot honestly mean the vendor interpreting HKMA guidance as a matter of regulatory or legal authority, or representing the institution in a regulatory capacity.
• C-RAF assessment support can honestly mean a vendor supplying technical evidence, mapping existing controls against C-RAF's control domains, and helping the institution's own compliance and risk staff understand where gaps sit. It cannot honestly mean the vendor completing or attesting to the assessment on the institution's behalf — C-RAF is, by HKMA's own design, a self-assessment the institution's board and senior management are accountable for.
• Incident response plan/playbook development and tabletop exercise support can honestly mean a vendor helping design and facilitate the plan and the exercise, bringing pattern-recognition from having supported other incidents. It should not mean the institution outsourcing ownership of its own incident-response decision rights, which need to remain with the institution's own designated incident commander regardless of who is running the technical response underneath that decision.
• Documentation and evidence preparation can honestly mean a vendor producing accurate, timestamped technical documentation of the environment it operates and secures — arguably where a well-run MSP/MSSP adds the most genuine value, because good documentation and evidence should be a byproduct of how the environment is actually run day to day, not a special project assembled ahead of a review.
• Gap analysis and remediation recommendations can honestly mean a vendor identifying control gaps against a named framework and proposing concrete remediation steps it is qualified to execute. It should be presented as a recommendation the institution's own risk function reviews and accepts, not a vendor-issued compliance verdict.
• Assistance responding to HKMA enquiries or reviews can honestly mean a vendor providing the factual, technical information the institution needs to respond accurately and promptly, and being available to answer technical questions a reviewer directs at the operating environment. It cannot honestly mean the vendor communicating with the regulator on the institution's behalf, or standing in for the institution's own accountable officers in that conversation.

What This Genuinely Requires of a Provider

Responding credibly to a bundled RFP of this shape is a materially higher bar than responding to an MSP RFP or an MSSP RFP alone, for three reasons that are organizational and procedural, not just technical.

Organizationally, the provider needs its managed-IT operations and its security operations to be one accountable function, not two teams under one sales umbrella. When a bank's due-diligence team asks how an incident is detected, escalated, and remediated end to end, an answer that requires stitching together two separate teams' separate tools and separate ticketing systems is itself a control weakness worth noting — and a sophisticated buyer will notice it.

Technically, the provider's tooling needs to generate evidence as a natural byproduct of normal operations, not as a special project assembled before an audit. A provider whose backup verification, patch compliance, endpoint coverage, and access logs are not already queryable and exportable in normal operation will struggle, under time pressure, to produce credible evidence when a C-RAF maturity assessment or an HKMA review actually asks for it.

Procedurally, the provider needs documented, contractually explicit boundaries about where its responsibility ends and the client's regulatory accountability begins — for the provider's own protection as much as the client's. A provider that markets itself as making C-RAF or HKMA compliance "easy," or implies it can carry regulatory risk on the client's behalf, is making a promise it cannot actually keep, and a claim like that should be treated as a warning sign by any buyer evaluating vendors for this kind of contract, not a selling point.

How a Provider Operationally Fulfills the Dual MSP/MSSP Role

Rather than describe this in the abstract, it is worth describing what an integrated MSP/MSSP operating model actually looks like in practice, in a way a reader could picture and verify against a real provider's operations rather than take on faith.

• One ticketing and monitoring system, not two. Infrastructure alerts, security alerts, and end-user support requests land in the same operational system, so an engineer working an incident can see the full technical history of the affected device or account — its support tickets, its patch state, its recent security events — in one place, rather than needing to request that information from a separate security team on a separate platform.
• Shared on-call and escalation paths between IT operations and security. A ransomware event, for instance, is simultaneously an infrastructure incident (systems down, backups needed) and a security incident (containment, forensics, root cause) — an operating model that routes these to genuinely separate teams with separate escalation chains loses time exactly when time matters most.
• Endpoint tooling that serves both functions from the same agent where practical. The same lightweight agent that gives a support engineer the ability to remotely assist a user can also be the source of continuous, evidence-generating security-posture data — encryption status, patch level, antivirus health — without requiring a second, separately-managed security agent competing for the same endpoint's resources.
• A single evidence trail that both operational teams and compliance/audit stakeholders can draw from. Session logs, change records, and security telemetry accumulate continuously as a byproduct of delivering the service, so that when a client's compliance team needs to demonstrate a control was operating effectively over a review period, the evidence already exists rather than needing to be reconstructed retrospectively.

A Concrete Delivery Process

A defensible engagement for this kind of bundled contract moves through phases a client's own risk and compliance stakeholders should be able to observe and validate, not just take on the provider's word.

• 1. Baseline discovery and inherent-risk-relevant fact-finding (typically the first few weeks). The provider inventories the technology environment in detail — assets, cloud services, third-party connections, data flows — producing the kind of factual input the institution's own Inherent Risk Assessment depends on, without the provider making the risk-tier judgment itself.
• 2. Control mapping and gap analysis against the institution's applicable framework. Existing controls (backup, endpoint protection, access management, monitoring) are mapped against the relevant C-RAF control domains or the institution's chosen framework, with gaps documented and prioritized — the technical groundwork underneath what will become the institution's own Maturity Assessment submission.
• 3. Remediation delivery against the prioritized gap list. This is where the MSP and MSSP functions actually execute — closing patching gaps, deploying or tuning endpoint and email security controls, formalizing backup testing, building out SOC monitoring coverage — on a schedule the institution's risk function has visibility into and can track.
• 4. Incident response plan and playbook development, followed by a tabletop exercise. The provider helps draft or refine the plan and facilitates a tabletop exercise that tests it against a realistic scenario, with findings documented and fed back into both the plan and the broader gap-remediation backlog.
• 5. Steady-state managed operation with continuous evidence generation. Ongoing MSP/MSSP delivery — ticketing, monitoring, patching, SOC coverage — runs as normal operations, with the provider's tooling continuously producing the audit trail (session records, patch compliance history, security event history, backup test results) the institution's compliance function can draw on for its own C-RAF Maturity Assessment updates and for responding to HKMA enquiries, without needing a special evidence-gathering exercise each time.
• 6. Periodic review and re-baseline. Given that C-RAF's own components are meant to be revisited periodically (inherent risk profiles change as an institution's technology and product mix evolves), the engagement should include a recurring cadence — commonly annual or aligned with the institution's own internal audit cycle — to re-run the gap analysis and confirm the control environment still matches what was last documented.

What This Report Does Not Claim

• This is not legal or regulatory advice, and it is not a substitute for the institution's own legal counsel, compliance function, or direct engagement with the HKMA. Any company acting on the pattern described here should confirm its specific obligations directly against current HKMA publications and, where appropriate, qualified legal counsel.
• This report does not assert the current exact wording, numbering, or revision date of any specific HKMA Supervisory Policy Manual module, or the current exact version or terminology of C-RAF. HKMA revises its guidance over time; the structural description here reflects what has been consistently and publicly documented, not a claim of currency with the latest revision.
• This report does not have visibility into any specific institution's confidential supervisory correspondence with the HKMA, and makes no claim about what any particular regulator review, enquiry, or examination has actually asked for in practice.
• This report does not claim that Brocent, or any technology and security vendor, can complete, attest to, or submit a C-RAF assessment, or otherwise assume an HKMA-regulated institution's own regulatory accountability. That accountability sits with the institution's board and senior management by design, and no outsourcing arrangement changes that.
• This report does not present the "bundled procurement" pattern as a documented industry statistic. No public survey of Hong Kong IT procurement structure of the kind this report would need to cite a specific figure is known to exist. The pattern described is based on how Brocent has observed real RFPs shaped in the Hong Kong market and on the regulatory logic (SA-2, TM-G-1) that would predict exactly this kind of buying behavior — a reasoned inference and a direct operational observation, not a statistic, and presented as such.
• This report is scoped to HKMA-regulated authorized institutions and companies selling into that sector. It does not address the Insurance Authority's or the Securities and Futures Commission's parallel (and structurally different) technology-risk and outsourcing regimes.
• This report does not claim regulatory pressure is the only cause of the bundling pattern. Ordinary procurement efficiency — fewer vendor relationships, fewer contracts to renew, a single point of accountability — is very likely a genuine, coexisting motivation, and this report does not attempt to weight the relative contribution of each cause.

How Brocent Delivers This

Brocent is a managed IT and cybersecurity services provider headquartered in Singapore, with an established Hong Kong office (operating in the territory since 2016) and roots going back to its founding in Beijing in 2007. Two things about how Brocent operates are directly relevant to the pattern described in this report, and both are described here as verifiable operational facts, not marketing claims.

First, Brocent runs managed IT services and cybersecurity services as one integrated operation, not as separate business lines assembled at contract signing. This is the organizational model this report argues is actually necessary for a bundled MSP/MSSP/regulatory-support engagement to be credible — see Managed IT & Security Services for how that integration is structured, and Managed IT Support for the underlying support-delivery plans and coverage model.

Second, Brocent's own endpoint platform, BCS Beam, generates exactly the kind of evidentiary byproduct this report describes as valuable for C-RAF-related documentation — as a normal function of delivering remote support and endpoint security monitoring, not as a special compliance exercise. Every remote-support session BCS Beam facilitates is written to an audit ledger recording who connected, to which device, when, in what mode, and against which support ticket; the security-health side of the same agent continuously checks disk encryption, antivirus and firewall status, patch posture, and known-vulnerability exposure against CIS-aligned benchmarks, and produces reportable, per-device evidence rather than a point-in-time attestation. That connection-level and posture-level audit trail is a direct, concrete example of the "evidence generated as a byproduct of normal operations, not assembled before an audit" principle this report argues a provider needs in order to responsibly support C-RAF-related documentation work.

Consistent with the boundary this report has been explicit about throughout: Brocent is not HKMA-licensed or HKMA-regulated, and does not assume, on behalf of any client, the client's own regulatory accountability for C-RAF completion, attestation, or formal communication with the HKMA. Brocent's role in a bundled MSP/MSSP/regulatory-support engagement is technical execution, evidence generation, and documentation and gap-analysis support — delivered by one integrated team rather than a patchwork of disconnected tools and vendors.