The Pen-Test Requirement a Hong Kong Payments Firm Didn't See Coming

TL;DR: A licensed Hong Kong payments firm receives a routine regulatory review request that asks, among other things, for evidence of penetration testing — and its small IT team realizes "evidence" means more than a PDF from a scan someone ran two years ago. This is a composite, illustrative scenario, not a named client. It walks through what changes when testing moves from a one-off event to a maintained cadence, and where an IT partner's operational role stops and a firm's own compliance and legal judgment begins.

A Licensed Firm, and a Regulator That Doesn't Go Away After Licensing

Hong Kong is home to a large population of licensed payments and money-service businesses — stored value facility (SVF) operators, money service operators, and firms that move funds or process payments as their core business. Getting the license is a milestone. What comes after it is less visible from the outside: standing regulatory interest, from the Hong Kong Monetary Authority and the frameworks it administers, in how well a licensed firm manages technology risk — not as a one-time licensing checkbox, but as an ongoing supervisory relationship.

That interest shows up in different ways for different firms — periodic returns, ad hoc information requests, on-site or off-site reviews, questions triggered by an incident somewhere else in the industry. It is publicly understood, in the way HKMA's technology-risk-related guidance is generally described, that a licensed firm is expected to demonstrate it understands and actively manages its own technology risk, including the risk that its own applications and infrastructure carry exploitable weaknesses. Exactly what a given review will ask for, on what schedule, and against what specific standard, is a determination that sits with HKMA and the firm's own compliance function — not something a technology vendor can predict or promise on a firm's behalf. What follows describes a common shape this question takes in practice, and Brocent's own perspective on the operational side of answering it, grounded in the firm's real work in Hong Kong's financial-services sector.

Firms in this position are frequently smaller than the banks and insurers that tend to dominate public conversation about HKMA-adjacent oversight. A payments or money-service operator with under 100 staff rarely has a dedicated compliance department the size a bank would run, and it very often doesn't have a security-focused hire at all — the person answering a regulatory review's technology questions is frequently the same person who also manages the helpdesk queue and the cloud hosting bill. That's not a criticism of how these firms are run; it's simply the operating reality a lean payments business faces, and it's exactly the reality where an ad hoc approach to testing tends to take root, because nobody has the bandwidth to own a standing programme on top of everything else.

Why This Persona Is Different From a Bank or an Insurer

Publicly discussed HK-finance IT topics tend to gravitate toward hedge funds, family offices, and insurance brokerages — segments where compliance headcount is larger and testing programmes, where they exist, are often already reasonably mature. A licensed payments or money-service firm is a genuinely different persona: usually leaner, usually younger as a business, and usually facing its first serious regulatory review of its technology posture at a point where the platform has already grown well past its original scope. The gap this article describes isn't a hypothetical edge case for this segment — it's closer to the default starting point, which is exactly why the operational fix matters more here than a generic "run more tests" recommendation would suggest.

The Review Request That Didn't Match the Firm's Evidence

Picture a Hong Kong-licensed payments firm with roughly 50 to 90 staff. It has grown steadily — new merchant integrations, a growing transaction volume, a couple of new product lines layered onto the original platform over several years. Its IT function is small: a handful of people who keep the platform running, ship features, and handle day-to-day support. Security testing has happened, but it has happened the way it happens at a lot of firms this size — reactively. A prospective banking partner asked for a penetration test report before opening a settlement account, so the firm commissioned one. A large merchant's own vendor-security questionnaire asked the same question a year later, so the firm ran a scan. Nobody owns a standing testing programme; testing has been a response to whoever asked most recently, not a recurring item on anyone's calendar.

Then a routine supervisory review lands — a periodic check-in, not triggered by an incident, the kind of review a licensed firm should expect to face from time to time. Among the questions is one the firm has answered before, informally, but never had to document properly: what is your penetration testing programme, and can you show us evidence of it. The firm pulls together what it has. A PDF from a test run roughly two years ago, commissioned for a bank onboarding process rather than for its own risk management. No record of anything since. No clear answer to what was actually tested — was it the public-facing payment API, the merchant portal, the internal network, all three? Nobody currently at the firm was in the room when that scope was decided.

This is the moment the gap becomes visible. Not because the firm was careless — the platform has been reasonably well run, the original test wasn't fabricated or fraudulent — but because testing was never built as a programme. It was built as a series of one-off responses to whoever asked loudest.

What "We Ran a Scan Once" Actually Exposes

Three things tend to surface once a firm actually has to produce its testing history for a reviewer, rather than just assert that testing "has happened":

• No dated evidence trail. A single report from two years ago answers "did you ever test," not "are you currently maintaining a tested, current security posture." A reviewer looking at a technology stack that has visibly changed since that report — new integrations, new product lines, possibly new infrastructure — has no way to know whether those changes were ever tested at all.
• Uncertain scope. Even where a report exists, the firm may not be able to say with confidence what it covered. Was it external network only, or did it include the web application layer? Did it include any API endpoints added since? A report without a clearly retained scope statement is hard to defend as current evidence of anything specific.
• A scramble against a deadline. Once the gap is visible, the instinct is to book a test immediately — but qualified testing teams are frequently booked several weeks out, and a rushed, deadline-driven engagement is a worse starting point for a testing programme than a planned one. Testing commissioned purely to answer one reviewer's question, rather than as the first cycle of an ongoing programme, tends to repeat the same one-off pattern the firm is trying to move away from.

None of these three problems is really about the quality of any individual test. They're about the absence of a programme wrapped around individual tests — the thing that turns "we did a test once" into "we maintain a tested, current environment and can show you exactly how."

Where Brocent's Role Starts — and Where It Stops

It's worth being direct about what an IT and security partner can and can't do here, because this is exactly the kind of situation where overstating a vendor's role does a licensed firm no favors.

Brocent's role in a situation like this is operational, not regulatory. That means: running the actual testing — through penetration testing engagements scoped to the firm's real environment, using certified testers and CVSS-scored findings with proof-of-concept evidence — on a schedule the firm sets and keeps to; maintaining the documentation and dated reports that build into an evidence trail over time; helping the firm's compliance team understand, in plain operational terms, what was tested, when, and what was found and remediated. What Brocent does not do, and should not be relied on to do, is tell a licensed firm what its regulator will consider adequate, certify that a given testing cadence satisfies any specific HKMA expectation, or substitute for the firm's own compliance and legal counsel in interpreting what a review actually requires. Those determinations belong with the firm's own compliance function and, where appropriate, its external legal counsel — not with a technology vendor, however experienced. A partner that claims otherwise is promising something it can't actually deliver.

What a good operational partner can credibly promise is consistency: the same environment tested on the same reasonable schedule, dated evidence retained in an organized way, and a working relationship where a compliance lead can ask "when did we last test the merchant portal, and what did it find" and get a straight, documented answer within minutes rather than a search through old email threads.

This division of labor is worth restating plainly, because it's easy for a stretched five-person IT team to want it to be simpler than it is: no vendor, however credentialed, can hand a licensed firm a certificate that says "compliant." What Brocent can hand a firm is a body of evidence — dated, scoped, remediated, current — that the firm's own compliance function can then use to make its own case to its own regulator. The evidence is Brocent's job. The judgment about whether that evidence is sufficient for a given review is the firm's job, exercised through its compliance and legal advisors. Conflating the two is where firms get into trouble, either by under-investing because a vendor implied "we've got compliance covered," or by over-trusting a single test result long after the environment it described has moved on.

What a Maintained Testing Cadence Actually Looks Like

The practical difference between the two states — ad hoc testing and a maintained programme — comes down to a handful of concrete habits, not a philosophy shift:

• A recurring schedule, not a one-off booking. Instead of commissioning a test only when someone external asks, testing runs on a set interval the firm has chosen and can defend — commonly annual, sometimes more frequent for systems handling payment data directly. Brocent's own penetration testing engagements are built around exactly this shape, with annual testing packages that include a re-test after remediation, rather than a single point-in-time report.
• Dated reports kept as a running evidence trail, not a single file retrieved when needed. Each cycle's report, scope statement, and remediation record accumulates into a history a compliance lead can hand to a reviewer without having to reconstruct it under time pressure.
• Scope reviewed every cycle, not assumed to be static. A firm that added a new merchant-facing API, migrated part of its infrastructure to a new cloud environment, or launched a new product line since the last test has, in effect, added untested surface area. Reviewing scope at the start of each cycle — rather than re-running the same test plan by default — is what keeps the evidence trail actually relevant to the current environment, including cloud-hosted components.
• A clear line between scanning and testing, run on their own appropriate cadences rather than conflated into one activity. Vulnerability scanning is automated, broad, and suited to a more frequent cadence; penetration testing is manual, deeper, and suited to a less frequent but more thorough cadence. A firm that only ever does one of the two has a real gap, whichever one is missing.

None of this requires exotic tooling or a large internal security team. It requires the testing relationship to be structured as an ongoing programme with a clear owner, rather than a transaction that happens whenever someone external asks the question.

Three Ways Hong Kong Payments Firms Approach Penetration Testing

• No Formal Programme. Testing happens only when a client, banking partner, or merchant asks for evidence directly. No standing schedule, no consistent scope discipline, and — as the scenario above shows — a real exposure the moment a reviewer asks a question the firm hasn't had to answer in writing before.
• A One-Off Test Kept on File. Better than nothing: at least one dated report exists. But a single test ages quickly against a platform that keeps changing, and it answers "did you test once" rather than "are you currently testing what you currently run."
• A Recurring Testing Cadence With a Maintained Evidence Trail (Brocent's model). Testing runs on a schedule the firm owns and can explain, scope is reviewed each cycle against the current environment, reports and remediation records accumulate into a defensible history, and the firm's compliance team can produce that history on demand — while the regulatory determination of what's "adequate" stays exactly where it belongs, with the firm and its own counsel.

Frequently Asked Questions

Does a vulnerability scan satisfy a penetration-testing expectation?

Generally not on its own — the two are different activities. Vulnerability scanning uses automated tools to identify known weaknesses across a broad surface area; penetration testing has certified testers actively attempt to exploit those weaknesses, chain them together, and demonstrate real-world impact. A reviewer asking specifically about penetration testing is unlikely to accept a scan report as equivalent evidence, though the two are complementary and a mature programme typically runs both, on their own appropriate cadences. Whether a specific regulator or specific review accepts one in place of the other is a determination for the firm's own compliance judgment, not something a vendor should assert on the firm's behalf.

How often should a licensed firm test?

There's no single number that applies to every firm, and Brocent does not assert a specific frequency as a regulatory requirement. What's common in practice for firms handling payment data is an annual cycle at minimum, with additional testing triggered by material changes — a new externally facing system, a significant infrastructure migration, a new product line touching customer funds. The right cadence for a specific firm is a judgment call that should involve the firm's own compliance and risk function, informed by its actual risk profile.

What should a testing evidence trail include?

At minimum: a dated report for each testing cycle, a clear scope statement describing exactly what was tested (systems, environments, testing type), the findings with severity ratings, and a remediation record showing what was fixed and when — ideally with a re-test confirming the fix. The goal is that a compliance lead can hand a reviewer a clean, chronological picture without having to reconstruct history from scattered files.

Who determines whether our testing programme is adequate?

The firm itself, together with its own compliance function and, where needed, external legal or compliance counsel — informed by the specific regulatory expectations that apply to its license and business. An IT or security vendor, including Brocent, can describe what its testing programme does and produce the evidence a firm needs, but cannot and should not tell a firm that a given programme satisfies a specific regulatory standard. That determination is the firm's own, and it's a genuinely different kind of judgment from the operational work of running the tests.

Can the same provider run both scanning and testing?

Yes — it's a reasonably common setup, since a single provider with visibility into the same environment across both activities can maintain more consistent documentation. It isn't a requirement, though; some firms deliberately use separate providers for testing and for their broader managed IT relationship. What matters most for the evidence trail is that whichever provider runs the testing does so on a consistent schedule with dated, retained records — not which specific arrangement of vendors delivers it.

What happens if a review finds no prior testing on record?

That outcome is between the firm and its regulator, and Brocent doesn't speculate about specific regulatory consequences. What's within an IT partner's control is helping the firm respond quickly and credibly from that point forward — scoping and running a test promptly, and, more importantly, standing up the recurring programme so the same gap doesn't reappear at the next review. A firm's response to a finding, and how it's received, is generally judged as much on what changes afterward as on the original gap.

Does cloud-hosted infrastructure change what needs testing?

It changes what needs to be in scope, not whether testing is needed. A payments platform running partly or fully in the cloud still has an attack surface — APIs, web application layers, identity and access configuration, and depending on the cloud provider's shared-responsibility model, some infrastructure layers the firm is directly responsible for testing. Scope reviewed each cycle, as described above, is specifically meant to catch this — a cloud migration since the last test is exactly the kind of change that should trigger a fresh look at what's included.

Building the Cadence Into a Managed IT Plan, Not a Series of One-Off Bookings

The firm in this scenario doesn't actually have a testing problem in isolation — it has a programme problem, and testing is where it happened to become visible first. The same gap tends to show up elsewhere once you look: patching cadence, backup verification, access reviews, all the recurring operational disciplines that are easy to run once and hard to run consistently with a five-person IT team also shipping product.

This is why Brocent frames a maintained testing cadence as something that belongs inside an ongoing managed IT plan, not as a series of separately negotiated bookings every time a reviewer asks a question. The per-user managed IT plans on that page are built around exactly this kind of recurring operational discipline — security testing, patching, monitoring, and documentation running on a schedule as a standing part of the relationship, rather than something reassembled from scratch under deadline pressure each time it's needed. For a licensed payments firm, that consistency is the actual product: not a single passing test, but a defensible, current answer to "show us your testing programme" whenever the question comes up next. Penetration testing and, for firms whose environment calls for a deeper testing tier, the advanced Red Team Engagement option sit as add-ons inside that plan rather than as the destination — the plan is what keeps the cadence running between engagements.

If your firm is looking at a review request and doesn't like what its current testing history shows, the practical next step is a conversation, not a rushed test booking. See current pricing for the managed IT plan or get in touch to talk through what a maintained testing cadence would look like for your specific environment — and where Brocent's operational role fits alongside your own compliance and legal judgment on the regulatory side.