The Report Has to Satisfy Their Bank: Penetration Testing for a Hong Kong Fintech Under Counterparty Review

The short answer: the penetration test report your bank asked for is not written for you. It will be read by a risk analyst at the counterparty who needs to tick a box and be able to defend that tick later. What makes it acceptable is a scope that matches what they care about, a stated methodology, reproducible evidence and a dated remediation and re-test record — not how many findings it contains.

Why is a bank asking a 28-person fintech for a penetration test report?

Take a composite, illustrative Hong Kong fintech. Twenty-eight people, about half of them engineers. The product is a B2B payments and reconciliation platform: corporate customers connect their accounting systems through an API, and the platform matches incoming and outgoing payments, flags exceptions and pushes settlement instructions. The whole business depends on a banking partner — the bank holds the client money accounts, provides the payment rails and, increasingly, wants a direct API connection rather than file uploads.

Commercial terms were agreed months ago. Onboarding then moved to the bank's third-party risk team, and it stopped at a security questionnaire. Most of the questions the head of engineering could answer in an afternoon: encryption at rest, MFA on production access, how secrets are stored, who can deploy. One line could not be answered at all. It asked for the most recent independent penetration test report, covering the systems in scope for the relationship, dated within the last twelve months.

The company had never commissioned one. It had run a free scanner against its public site before a funding round, and the cloud provider's own security dashboard was mostly green. Neither was a penetration test, and neither was independent. The go-live date the sales team had promised to three corporate customers was eight weeks away. The founder's first instinct was to ask for the cheapest test that produces a PDF. The head of engineering's first instinct was to ask for the most thorough test money could buy. Both instincts, as it turns out, are aimed at the wrong reader.

This situation is common enough in Hong Kong's fintech sector that it has its own shape. A small team, a counterparty with a formal onboarding process, a deadline set by someone else, and a document request that sounds simple and is not. The rest of this article walks through what that document actually has to do.

How is this different from testing for a launch, a regulator or an insurer?

The same service — a penetration test — answers different questions depending on who reads the output. When the trigger is your own launch date, the test is for you: you want to know what will break before customers find it, and we cover that timing problem in planning a pen test against an app launch. When the trigger is a licensing regulator, the question is whether you run a maintained testing programme over years, which is the frame of the pen-test requirement a Hong Kong payments firm didn't see coming. An insurer, at renewal, usually wants evidence of continuous hygiene more than a one-time deep test.

A counterparty is different from all three. The bank is not your regulator and cannot inspect you. It is not your insurer and does not price your risk into a premium. It is a business deciding whether to connect its systems and its reputation to yours, and its risk team has a policy that says a third party with this level of access must produce independent evidence of security testing. The report is that evidence. It will be filed, it may be audited internally, and the analyst who accepts it is personally on record for accepting it. That changes what the report needs to contain.

Who actually reads the report, and what are they looking for?

Picture the reader. A third-party risk or information security analyst at the bank, handling dozens of vendor and partner due diligence reviews at once. They are probably not going to re-run your exploits. They may never open the technical appendix. They are reading for four things, usually in this order.

First, whether the test covered the systems that matter to the relationship. If the bank is going to call your API, and your report tested only your marketing website, the report is irrelevant no matter how clean it is. Second, whether the test was done by someone independent, using a recognised approach, within the time window their policy requires. Third, what was found and how serious it was — in particular whether anything rated critical or high is still open. Fourth, what you did about it, and whether anyone checked.

Notice what is not on that list: the raw number of findings. A report with forty low-severity observations and a clear remediation record is easier to accept than a report with three findings and no evidence of what happened next. A report with zero findings can actually raise questions — an experienced analyst knows that a genuinely scoped test of a live web application almost always finds something, and a blank result makes them wonder what was actually tested.

The analyst also has to write something down. Their internal record will say, in effect, "partner provided independent penetration test dated X, scope covering Y, no open critical or high findings, remediation verified on Z." If your report makes each of those phrases easy to fill in, it will move quickly. If the analyst has to write back and ask what was in scope, or whether a high finding was fixed, you have lost a week — and at an eight-week deadline, a week matters.

What makes a penetration test report acceptable to a counterparty?

Strip away the formatting and four elements do almost all of the work. A report missing any one of them tends to generate follow-up questions; a report with all four tends to get filed.

Does the scope statement match what the counterparty cares about?

The scope statement is the first page a risk analyst reads carefully. It should name the systems tested in terms the counterparty will recognise: the production API endpoints the bank will integrate with, the customer-facing web application, the external perimeter of the environment that hosts them, and any administrative interfaces that could reach client data. It should say which environment was tested — production, or a staging environment that mirrors it — and, if staging, why that is representative.

Just as important, it should say what was out of scope and why. "Internal corporate network excluded; no connectivity to production" is a perfectly acceptable sentence if it is true. What reads badly is silence, because silence forces the analyst to guess, and guessing is exactly what they are not allowed to do.

Is the methodology stated, not implied?

The analyst needs to see that the test followed a recognised approach rather than an improvised one. For a web application and API, that usually means stating that testing covered the OWASP Top 10 categories and beyond, whether it was closed-box (the tester started with no inside knowledge) or open-box (the tester had documentation, credentials or code access), what test accounts and roles were used, and the dates and times testing took place.

Closed-box versus open-box is a real choice with a real consequence. Closed-box tells you what an outsider can do. Open-box, with authenticated access at each user role, tells you far more about the thing the bank actually worries about — whether one of your corporate customers can see or move another customer's money through your API. For a counterparty review of a multi-tenant payments platform, authenticated testing of the API is usually the more useful evidence.

Can a stranger reproduce the evidence?

Every finding should come with proof-of-concept evidence: the request that was sent, the response that came back, a screenshot where helpful, and enough detail that a competent engineer who was not there could reproduce it. Each finding should carry a severity rating on a recognised scale — CVSS is the common one — plus a plain-language description of the business impact and step-by-step remediation guidance.

This matters to a counterparty for a reason that has nothing to do with your engineers. Reproducible evidence is what separates a real test from a document produced to satisfy a questionnaire. An analyst who sees a list of vague findings with no evidence has no way to tell the difference, and will treat the report accordingly.

Is there a dated remediation and re-test record?

This is the element small teams most often miss, because it happens after the tester has left. The report the bank wants to see is not just the initial findings; it is the initial findings plus a record showing which were fixed, when, and that someone independent checked the fix. In practice that is either an updated version of the report with a remediation status column, or a separate re-test letter that references the original findings by identifier and records each one as closed, partially closed or accepted.

Without this record, the analyst is looking at a list of vulnerabilities in your platform with no evidence they are gone. That is a worse position than not having tested at all, from the counterparty's point of view, because now there is a document on file showing known weaknesses.

What should be in scope — and what does a counterparty rarely ask for?

Scoping is where most of the cost and most of the value is decided, so it is worth going through the usual candidates one by one for a platform like the one in our scenario.

• External network perimeter. Everything reachable from the internet in the environment that hosts the product: load balancers, API gateways, VPN endpoints, exposed management ports, forgotten subdomains. Almost always in scope, and a focused external test is the smallest credible unit of work.
• Web application and API. The customer-facing application and, above all, the API the bank will call and your corporate customers use. For a payments platform this is the heart of the report — authentication, authorisation between tenants, input handling, business-logic abuse such as replaying or altering settlement instructions.
• Cloud configuration. Storage permissions, identity and access policies, logging, network segmentation between production and everything else. Often reviewed alongside the external test rather than as a separate engagement, and frequently where a small team's real exposure sits.
• Internal network. An assumed-breach test — if an attacker gets onto an employee laptop or an internal server, how far can they move? For a fintech whose production runs entirely in the cloud and whose office network has no route to it, this may be lower priority for this particular review; for one with office access to production, it is not.
• People. Social engineering and phishing simulation. Valuable, and increasingly how real incidents start, but counterparties reviewing a technical integration rarely require it as a condition of onboarding. Worth doing; rarely what unblocks this specific questionnaire.

The practical rule: scope to the systems that touch the relationship and the data it will carry, then add whatever the counterparty's questionnaire explicitly names. If the questionnaire is ambiguous, ask the bank's risk contact directly which systems they expect to see covered. That one email can save a re-test of the wrong thing.

Why does the cheapest scan fail, and the most expensive engagement overshoot?

The founder and the head of engineering in our scenario were each half right. Cost does matter, and thoroughness does matter. But the question is not "how much testing" — it is "which testing produces the evidence this reader needs."

Automated scan vs. scoped penetration test vs. over-scoped engagement

• Automated vulnerability scan: fast and inexpensive, and genuinely useful as a recurring control. It checks known vulnerabilities and misconfigurations against signatures. It does not test your business logic, cannot tell whether tenant A can read tenant B's transactions, and produces a machine-generated report with no human judgement about exploitability. Most counterparty risk teams that ask for a penetration test will not accept a scan in its place, and submitting one tends to cost you credibility for the rest of the review.
• Scoped penetration test: a human tester, a defined scope matched to the relationship, a stated methodology, manual exploitation of what the scanner flags and of what it cannot see, CVSS-rated findings with proof-of-concept evidence, and a remediation and re-test step. This is the thing the questionnaire is actually asking for, and for a platform of this size it can usually be delivered inside the timeline.
• Over-scoped engagement: a full red-team exercise, extended social engineering, physical intrusion, every internal subnet. Some of these are valuable in their own right. For this particular reader, most of it is noise — the analyst will skip to the sections on the API and the perimeter — and the extra scope stretches the calendar past the deadline and the budget past what a 28-person company should spend on one document.

The scoped test is not a compromise between the other two. It is the only one aimed at the reader.

How should you plan the timeline backwards from the deadline?

Work backwards from the date the bank needs the final document, not from the date you would like testing to start. For our scenario, eight weeks out, the plan looks roughly like this.

The first week goes to scoping and contracting: confirming with the bank which systems they expect covered, agreeing scope and test windows with the provider, preparing test accounts at each role, and making sure production owners know when testing will happen. Standard penetration tests are designed to be non-disruptive, and testing windows can be scheduled outside business hours if needed, but somebody on your side still has to be reachable while it runs.

Testing itself depends on scope. As a guide, a focused external network test typically takes three to five days; a full external, internal and web application engagement typically takes two to three weeks. A provider should give you a time and scope estimate at the proposal stage, and you should not sign a proposal that does not include one.

Then comes the part everyone underestimates: remediation. Your engineers need real time to fix what was found, test the fixes and deploy them. If testing finishes in week four and the bank needs the document in week eight, you have perhaps two to three weeks of remediation before the re-test has to happen. That is enough for a handful of serious findings; it is not enough if you discover a structural authorisation problem in the API. Which is exactly why the next two sections matter.

Why is the re-test the part small teams forget to negotiate?

Almost every first-time buyer focuses on the test and treats the re-test as a detail. From the counterparty's point of view, the re-test is the part that turns a list of problems into evidence of control.

Before you sign, be clear about three things. Is a re-test included, and on what terms? How long after the initial report can it be scheduled? What does it produce — a revised report, or a separate letter referencing the original finding identifiers?

For reference, Brocent's annual testing packages include a re-test after the initial findings are remediated, confirming that vulnerabilities have been closed and no new issues have been introduced. If you are buying a one-off engagement from any provider, do not assume a re-test is part of it. Ask, get the answer in writing, and if it is not included, negotiate it into the statement of work before testing starts — it is far easier to agree then than after the findings land and the deadline is two weeks away.

Also agree who performs the re-test. A re-test performed by your own engineers is not independent evidence. The same provider that ran the original test, checking against its own finding identifiers, produces the cleanest record.

What do you do with findings you cannot fix before the deadline?

Sometimes the honest answer is that a finding cannot be fully fixed in time. A deep authorisation issue might need a redesign of how tenants are separated in the data model; an outdated component might be tied to a vendor upgrade you do not control. The temptation is to hope the analyst does not notice. They will notice, and the damage to trust will be larger than the finding.

What works is a combination of three things. First, a compensating control that reduces the risk now — restricting the affected endpoint to the bank's IP range, adding an additional authorisation check at the gateway, disabling a feature until it is rebuilt, or increasing monitoring on the specific behaviour an attacker would need. Second, the re-test should verify that compensating control and record the finding as mitigated rather than closed. Third, a dated remediation plan: what will be done, by whom, by when, and how you will evidence it — ideally with a commitment to share a further re-test result once it is complete.

Risk teams are used to this. What they cannot accept is an open critical finding with no plan, or a plan with no date. A high-severity finding that is mitigated, monitored and scheduled for a fix in six weeks, with a named owner, is a normal thing to see in a partner file.

Can you reuse the report for the next counterparty?

In our scenario, the bank is the first counterparty to ask but will not be the last. Corporate customers, a second banking partner, a payment scheme and a prospective investor may all ask the same question within the year. It is worth planning for that from the start.

The full technical report is sensitive — it is, after all, a map of how your platform was attacked. Most providers and most counterparties expect it to be shared only under a confidentiality agreement, and some engagement terms restrict onward sharing. Check your own contract with the testing provider before sending the report anywhere. A common and sensible pattern is to maintain two documents: the full report, shared only with parties that genuinely need the technical detail, and an executive summary or attestation letter from the provider that states the scope, dates, methodology and remediation status without the exploit detail. Many reviewers will accept the summary and only ask for the full report if something in it prompts a question.

Reuse also has a time limit. A report that was acceptable in March may not be acceptable in the following February if your platform has shipped major changes since, or if the next counterparty's policy requires testing within six months rather than twelve. Record the date and version of the platform tested so that you can answer that question when it comes.

How do you turn a one-off into an annual cycle?

The first test is almost always bought under pressure. The second one should not be. Once you know a counterparty relationship requires independent testing, you know it will require it again next year, and probably whenever you ship a significant change to the integration.

An annual cycle has a predictable shape: agree scope at the same point each year, test, remediate, re-test, file the updated report and summary, and brief anyone who needs it. It also changes the economics. A provider that tests the same platform each year learns its architecture, spends less time on discovery and more on the parts that changed. Your engineers learn which classes of finding keep recurring and fix them at the source. And the report the counterparty receives each year becomes a trend rather than a snapshot — which is what a risk analyst actually wants to see.

This is also the point at which annual packages that include a post-remediation re-test make more sense than negotiating each engagement from scratch. Brocent's penetration testing service covers external network, internal network (assumed-breach lateral movement), web application testing against the OWASP Top 10 and beyond, and social engineering and phishing simulation, with closed-box and open-box options; every finding is documented with a CVSS risk score, proof-of-concept evidence, a business impact description and step-by-step remediation guidance.

But the annual test is still a point-in-time photograph. What determines whether next year's photograph looks good is what happens in the other fifty-one weeks.

Frequently asked questions

What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan is an automated check for known vulnerabilities and misconfigurations. A penetration test is a human-led attempt to exploit weaknesses, including business-logic flaws a scanner cannot see, with evidence of what was actually achievable. Scans are a good recurring control; a counterparty asking for a penetration test report usually will not accept a scan in its place.

How long does a penetration test take?

It depends on scope. A focused external network test typically takes three to five days. A full external, internal and web application engagement typically takes two to three weeks. Add time before for scoping and after for remediation and re-test, and plan backwards from the counterparty's deadline rather than forwards from today.

Will the report be in English?

Make report language an explicit line in the statement of work rather than an assumption. If the counterparty's risk team works in English, the report should be written in English from the start; a report translated after the fact can introduce ambiguity in exactly the places an analyst reads most carefully — scope, severity and remediation status.

Is a re-test included?

It depends on what you buy. Brocent's annual testing packages include a re-test after the initial findings are remediated. For any one-off engagement, with any provider, confirm in writing whether a re-test is included and on what terms before testing starts, and negotiate it in if not.

Can we share the report with more than one counterparty?

Usually yes, under confidentiality terms, but check your contract with the testing provider first. A practical approach is to share an executive summary or attestation letter broadly and the full technical report only with parties that need the detail. Keep a record of who received which version.

What if critical findings are found?

Fix what you can, verify the fix through the re-test, and for anything that cannot be fixed in time, put a compensating control in place and document a dated remediation plan with a named owner. Disclose it honestly. A mitigated, scheduled finding is normal in a partner file; a hidden one is not.

How often should we re-test?

At least annually for as long as the counterparty relationship requires independent testing, and after any significant change to the systems in scope — a new API version, a new hosting environment, a major authentication change. Check the counterparty's own policy; some require a shorter interval than twelve months.

Who signs the report?

The testing provider, not you. The report should identify the provider, the dates of testing, the version of the report and who led the test, and the provider should issue any attestation letter or re-test confirmation under its own name. A self-signed document is not independent evidence, which is the whole point of the request.

Where does the work that keeps next year's report clean actually live?

Go back to the scenario. The fintech gets its report, fixes most of what was found, mitigates the rest, and the bank connects. Twelve months later the question comes round again. Whether that second report is easy or painful depends almost entirely on what happened in between — and very little of that is penetration testing.

Most findings in a first test are not exotic. They are an unpatched component, a missing MFA enforcement on an admin path, a storage bucket with broader permissions than intended, a configuration that drifted from its baseline, a known vulnerability nobody was watching. None of these need an annual test to find. They need someone watching every week.

That recurring hygiene is exactly what a managed IT plan is for. Brocent's per-user managed IT plan runs on five pillars — 24/7 NOC monitoring, a multilingual helpdesk, security governance, backup and disaster recovery, and a vCIO — and every plan includes the BCS Beam endpoint agent, a read-only security and health audit that checks devices against CIS-aligned benchmarks, watches for vulnerabilities prioritised by CVE, CVSS, EPSS and the CISA Known Exploited Vulnerabilities list, and tracks patch posture. For firms that need more, managed security services extend that into dedicated detection and response. Brocent has worked in the region since its founding in Beijing in 2007, with a Hong Kong office since 2016 and headquarters in Singapore since 2021, and our financial services clients face this kind of counterparty review routinely.

Hong Kong plan pricing is published per user per month: Startup (1–5 employees) HK$855.14, Established (5–300) HK$1,247.40, Growth (10–500) HK$1,561.21, and Enterprise on a custom quote. For a 28-person team on the Established tier, that is HK$34,927.20 a month at the published rate, for the work that keeps the next report short. See the full breakdown on the pricing page, or talk to us about scoping this year's test and the plan that makes next year's easier.

The test is the photograph. The plan is what you look like when nobody is taking one.