Why a Singapore Fintech's Cyber-Insurance Renewal Came Down to One Vulnerability Scan

A Singapore payments company's cyber-insurance renewal stalled on one question its broker asked and nobody in the office could answer on the spot: "When was your last vulnerability scan, and what did it find?" No scan, no report, no renewal at the quoted rate — until they had one.

Cyber Insurance Just Started Asking Fintechs a Different Question

For a Singapore-licensed fintech or payments company, cyber insurance used to be close to a formality: fill in a proposal form, tick a box confirming you run antivirus and back up your data, pay the premium, move on. That is no longer how the conversation goes for regulated financial businesses handling customer funds, payment credentials, or account data.

Insurers underwriting cyber policies for fintech and payments companies now ask evidence-based questions, not checkbox questions. "Do you have a firewall" has been replaced by "show us your most recent vulnerability scan report." "Do you run antivirus" has been replaced by "walk us through your patch cadence." The shift reflects a simple reality on the underwriting side: claims data shows that unpatched, known vulnerabilities are still the most common way attackers get in, and insurers would rather price (or decline) that risk with real evidence than take a company's word for it.

For a Singapore-licensed payments or fintech firm, this collides with a second pressure that is already familiar: the Monetary Authority of Singapore's Technology Risk Management guidelines expect regulated entities to manage technology risk actively, including regular vulnerability assessment as part of a broader security posture. A company that has already built reasonable day-to-day security habits — firewalls, endpoint protection, MFA, a reasonably disciplined patch cycle — can still find itself with nothing to hand an insurer, because none of that daily hygiene produces a document. Vulnerability scanning does. It is one of the few security practices whose entire output is a dated, readable artifact that answers exactly the question an underwriter is asking.

Singapore's position as one of Asia's leading fintech and payments hubs makes this a live issue for a large and growing population of MAS-licensed payment institutions, e-money issuers, and adjacent financial-technology firms — companies whose core product often *is* the movement or custody of customer money, which is precisely the profile an underwriter treats as higher-risk and therefore wants more evidence from, not less. A company in this category renewing cyber cover for the first time since the market hardened often discovers the evidence bar has moved without anyone telling them directly — the broker simply starts asking for documents that weren't part of last year's conversation.

The Scenario: Solid Habits, No Recurring, Documented Practice

Picture a Singapore-licensed payments or fintech company with somewhere between 40 and 80 staff — engineering, operations, compliance, customer support, a small finance team. By most day-to-day measures, its IT security is in decent shape. Laptops are managed and encrypted. There's a firewall at the office and cloud perimeter. Endpoint protection is deployed fleet-wide. Multi-factor authentication is enforced on email and the core banking or payments platform. Patches get applied, more or less, when IT gets around to it.

What this company does not have is a recurring, documented vulnerability-scanning practice — a scheduled process that systematically checks external-facing systems, internal servers, and web applications for known weaknesses, on a cadence, with a dated report at the end of each cycle. Maybe there was a one-off penetration test eighteen months ago, commissioned for a client due-diligence questionnaire. Maybe a previous IT hire ran an open-source scanner once and nobody has looked at it since. Either way, when the compliance lead goes looking for "our current vulnerability posture" to hand to the insurance broker, there is nothing dated within the last quarter, nothing that maps cleanly to the systems the company runs today, and no one who can say with confidence what the last scan actually found or whether it was fixed.

This is a genuinely common gap, and it is not a sign of carelessness — it is what happens when a growing company invests in the security controls that stop day-to-day incidents (firewalls, endpoint protection, MFA) but never assigns an owner to the separate, ongoing discipline of checking those controls for known weaknesses on a schedule and writing down what it finds.

The gap also tends to widen quietly as a company grows. A 40-person fintech with one office and one cloud environment is a manageable thing to keep a mental map of; an 80-person fintech with a hybrid-remote engineering team, a handful of SaaS integrations added over eighteen months, a payments API exposed to partners, and a couple of legacy servers nobody has decommissioned is not. Every new integration, every new cloud service, and every new employee laptop is a small expansion of what an attacker — or an insurer's questionnaire — considers "in scope." Without a recurring scan that automatically covers whatever is currently live, the list of things nobody has checked grows in step with the business, invisibly, until a renewal conversation forces someone to look at it all at once.

What Happens When You Can't Answer the Question

The immediate, visible problem is the renewal itself. A broker comes back from the insurer with a request for a current vulnerability scan or assessment report, and the company has nothing to send that is both recent and complete. A few things can happen from there, none of them good: the renewal quote comes back at a materially higher premium to price in the unknown risk; the policy renews but with a coverage exclusion or sub-limit tied to unpatched-vulnerability incidents specifically; or the underwriter asks for a scan to be completed within a fixed window (often 30 days) as a condition of binding coverage, which turns a planning exercise into a fire drill.

Underneath that immediate problem are three others that tend to surface once someone starts asking questions:

• No internal owner for "when did we last check." Security tooling — firewall, EDR, MFA — usually has a clear owner because someone had to buy and configure it. Vulnerability scanning often does not, because it is a recurring *activity*, not a one-time purchase, and recurring activities without an assigned owner quietly stop happening.
• Confusion between a one-off penetration test and ongoing scanning. These get used interchangeably in casual conversation but answer different questions. A penetration test is a point-in-time, manually-driven exercise that proves what a skilled attacker could actually achieve against a defined target — valuable, but a snapshot from whatever date it was run. A vulnerability scan is a broader, repeatable, largely automated check for known weaknesses that is meant to run on a schedule. An insurer asking "what's your current vulnerability posture" wants the second thing; a pentest report from eighteen months ago does not answer it, no matter how good the pentest was.
• No remediation loop, so findings (when they exist) go nowhere. Even where a scan has been run, if the resulting list of findings sits in someone's inbox with no tracked follow-up, the company has spent money to document its own exposure without reducing it — which is arguably a worse position than not scanning at all, since a discovered-but-unfixed finding is now something an insurer or auditor could reasonably ask "why is this still open."

Brocent's Take: Insurers Are Asking a Specific, Answerable Question

Here is the reframe that actually matters for a company in this position: the insurer is not asking for a perfect security program. They are asking a specific, narrow, answerable question — can you show current evidence that you actively look for known weaknesses in your systems and act on what you find? That is a much smaller ask than "prove you're unhackable," and it has a correspondingly specific, achievable fix: a recurring vulnerability-scanning practice that produces a report an underwriter, auditor, or client due-diligence team can actually read and act on.

The honest fix is not a scramble the week before renewal. A one-time scan commissioned in a panic, two weeks before the policy lapses, technically produces a document — but it also produces a document with an obvious date stamp that says "we started doing this because our insurer asked," which is a materially weaker position at the next renewal than a report that's the fourth or fifth in an ongoing, dated series. The stronger, cheaper-over-time position is to treat vulnerability scanning the way the company already treats patching or backups: a standing, owned, recurring operational practice, not a one-off compliance purchase.

This is also where the "checkbox versus evidence" distinction from earlier in this piece cuts the other way in a company's favor. A firm that can hand its broker a dated, CVSS-scored scan report from last month, alongside a short note on what was found and fixed, is answering the underwriter's actual question directly — and doing so from a position of routine operational discipline rather than reactive scrambling. That difference is visible to an underwriter reading the file, and it is the difference between a renewal that goes smoothly and one that gets re-priced or delayed.

What a Real Vulnerability-Scanning Practice Actually Includes

A vulnerability-scanning practice built to actually hold up — to an insurer, an auditor, or MAS's Technology Risk Management expectations — has a few concrete, non-negotiable pieces. It is worth being specific about what these are, because "we run scans" can mean almost anything from a genuinely rigorous program to a single automated tool report nobody reads.

• CVE-matched detection, prioritized by real-world exploitability. A scan that returns a raw list of every theoretically possible vulnerability is not useful — most companies would be staring at hundreds of findings with no way to know which ones matter. A useful scan matches discovered software and configurations against known CVEs and then prioritizes them using signals like CVSS severity scoring, EPSS (which estimates real-world likelihood of exploitation), and the CISA Known Exploited Vulnerabilities list — so the five findings that are actually being exploited in the wild this month rise to the top of the report, above the two hundred that are theoretical.
• A recurring cadence — monthly or quarterly, not annual. A vulnerability scan is a snapshot of a moving target: new CVEs are published constantly, and a system that was clean in January can have a newly disclosed, actively exploited weakness by March. Monthly or quarterly scanning (Brocent's managed scanning tiers run on a continuous, ongoing basis rather than a single point-in-time check) is what keeps the picture current instead of stale by the time anyone reads it.
• A plain-language report with a per-device or per-asset risk score. A raw export from a scanning tool is not something a broker, an auditor, or a non-technical compliance lead can act on. A report worth handing to an insurer includes a human-written executive summary, a prioritized, CVSS-scored findings list mapped to specific assets, and enough context that someone outside IT can understand what was found and how serious it is.
• A remediation loop, not a report that sits in an inbox. The point of scanning is to fix things, not to document them. A practice worth having includes a tracked path from "finding" to "confirmed fixed" — ideally with a re-scan that verifies the fix actually worked — so the company can say, honestly, not just "we scan" but "we scan, and we close what we find."

Three Ways Companies Handle This Question

• No Recurring Scanning ("we'll check before the audit"): Security controls exist, but vulnerability checking happens reactively — usually because a client questionnaire, an audit, or an insurance renewal forces the issue. There is no dated, current report on hand at any given moment, and whatever gets produced under time pressure is a one-off with no history behind it.
• A One-Off Annual Pentest: A genuinely useful exercise, but a snapshot from a single date, produced by manual testing against a defined scope, and it answers "what could a skilled attacker achieve on this date" rather than "what known weaknesses exist across our current systems right now." Twelve months later, at the next renewal, that report is old evidence for a question that expects something recent.
• Recurring Vulnerability Scanning With Monthly Reporting (the Brocent model): A continuous, managed scanning practice — external, internal, authenticated, and web-application scans depending on scope — that runs on a schedule and produces a dated, CVSS-prioritized report each cycle, with a tracked remediation path and re-scan confirmation. This is the version that answers an insurer's or auditor's question with current evidence, every time it's asked, not just the one time someone remembered to run a tool.

How This Fits Into a Broader Security Program

Vulnerability scanning is not a replacement for the rest of a company's security stack — it is the practice that tells you whether the rest of the stack is actually working as intended. Brocent's Vulnerability Scanning service is available as a standalone add-on directly from the Add-ons section of Brocent's managed IT support plans, scoped to the number of assets a company runs, and delivered either as a one-time assessment or as an ongoing managed service with continuous scanning and regular reporting.

For a Singapore fintech or payments company, it typically sits alongside two other pieces: managed IT security services, which covers the day-to-day monitoring, patch management, and endpoint protection that a scan report is actually checking the effectiveness of, and Brocent's broader cybersecurity practice, which covers the risk assessments, awareness training, and incident-response planning that surround a vulnerability-management program rather than replace it. None of these are sold as a mandatory bundle — a company can add vulnerability scanning on its own, on top of whatever IT support arrangement it already has, or combine it with the wider security services stack. Current, team-size-based pricing for the scanning service and every other add-on is published on Brocent's pricing page. Companies working through a renewal timeline, or simply trying to figure out what a scanning program would cost and cover at their size, can reach Brocent directly through the contact page.

Frequently Asked Questions

What's the difference between vulnerability scanning and a penetration test?

A vulnerability scan is automated, broad, and repeatable — it systematically checks a defined set of systems against known vulnerability databases and reports what it finds, on a recurring schedule. A penetration test is a manual, point-in-time exercise where a tester actively attempts to exploit weaknesses to prove real-world impact against a specific target. Scanning answers "what known weaknesses exist right now, across everything we run." A pentest answers "what could a skilled attacker actually achieve against this specific system, on this date." Most companies that need both use scanning continuously and pentest periodically — commonly annually, or when a major system changes.

How often should scanning actually happen?

Monthly or quarterly, not annually, for a company that wants the results to still be current when an insurer, auditor, or client asks for them. New vulnerabilities are disclosed constantly, so an annual scan is stale for most of the year it's supposed to cover. Brocent's managed scanning tiers run on a continuous basis rather than a single check, specifically so the report on file is always recent.

Will a scan report satisfy our insurer, or do they want something more?

It depends on the insurer and the size of the policy, but a dated, CVSS-scored vulnerability scan report — showing what was checked, what was found, and what was remediated — is exactly the kind of evidence most cyber-insurance underwriters are asking for when they request proof of active vulnerability management. Larger policies or higher-risk profiles sometimes also expect a periodic penetration test alongside ongoing scanning; the two are complementary rather than substitutes for each other.

What does a scan actually check?

Scope depends on what's being scanned, but a properly run assessment covers external, internet-facing systems (what an attacker on the open internet could reach), internal network and server infrastructure, and, where relevant, authenticated checks and web-application or API scanning against the OWASP Top 10 categories of common web vulnerabilities. Cloud environments — Microsoft 365, Azure, AWS configurations — can be included in scope as well, since misconfiguration there is one of the more common sources of exposure for a fintech running cloud-hosted infrastructure.

Who fixes what the scan finds?

The scan itself only identifies and prioritizes findings — remediation is a separate step. Depending on the arrangement, a company's own IT team can action the findings list, or it can be handled as part of a managed engagement where the fixes get tracked through to confirmed resolution and verified with a re-scan. The important part, either way, is that there's a documented path from "finding" to "confirmed fixed," not just a list that gets emailed once and forgotten.

How much does this typically cost at our size?

Pricing scales with the number of assets in scope and whether the engagement is a one-time assessment or an ongoing managed service — a lean 40-80-person fintech scoping an external-plus-internal scan is a meaningfully different quote from a multi-site enterprise engagement. Brocent's pricing page publishes current tiers and what's included at each; the most accurate way to get a fixed number is to send an asset count and compliance target for a same-cycle quote.

Does this replace the security controls we already have — firewall, MFA, endpoint protection?

No, and it isn't meant to. Vulnerability scanning is a check on whether those controls are configured correctly and whether the systems behind them have known, unpatched weaknesses — it's a verification layer, not a substitute for the controls themselves. A firm with strong day-to-day security hygiene and no recurring scan is in a genuinely better starting position than one with neither, but it's still missing the one artifact — a dated, evidence-backed report — that an insurer, auditor, or client due-diligence questionnaire is actually asking to see.

We're mid-way through our policy year, not renewing yet — is it worth starting now?

Yes, and arguably it's the better time to start. Beginning a recurring scanning practice mid-cycle means that by the time the next renewal conversation happens, the company already has several months of dated reports on file, rather than a single report commissioned two weeks before the deadline. It also means any findings from the first scan — which, for a company scanning for the first time, are usually the most numerous — are already being worked through and closed well ahead of the date an underwriter or auditor might ask to see the evidence.

The Bottom Line

An insurer asking for evidence of current vulnerability scanning is not asking a trick question, and it is not asking a company to be a different, more security-mature business than it already is. It is asking for one specific, recurring, well-defined practice — CVE-matched scanning, run on a schedule, reported in plain language, followed by a tracked fix — that most of Brocent's Singapore fintech and payments clients did not have in place until an insurer, auditor, or client questionnaire asked for it directly. Building that practice once, as a standing operational routine rather than a pre-renewal scramble, is what turns "we'll check before the audit" into a question the company can answer confidently every single time it's asked.