As virtual asset service providers operate in a more supervised environment, the key cybersecurity question is no longer just what test to buy. It is whether the engagement being scoped actually matches the requirement the firm is trying to satisfy.

Why this matters now

Virtual asset service providers are operating in a more structured regulatory environment than they were a few years ago. That has practical consequences for how cybersecurity work is scoped, documented, and evaluated.

In many markets, cybersecurity is no longer treated as a narrow technical issue. It sits closer to licensing, governance, oversight, and ongoing compliance expectations. That means firms need to think more carefully about the difference between doing useful technical work and commissioning an engagement that is actually fit for a regulated purpose.

The core problem: many firms start with the wrong question

A common starting point is to ask whether the business needs a vulnerability assessment, a penetration test, external scanning, or some combination of the three.

Those are valid questions, but they are often incomplete. The more useful starting point is: what requirement are we actually trying to satisfy, and what kind of engagement fits it?

That distinction matters because a technically sound engagement may still fall short if the real objective is broader than technical remediation. A VASP may need work that supports licensing, internal compliance review, governance oversight, or a regulator-linked assurance process. That is where the gap appears between technical testing and regulatory audit readiness.

Quick definitions: these services are not interchangeable

Vulnerability assessment

Generally focused on identifying weaknesses across systems, infrastructure, applications, or internet-facing assets.

Penetration test

Generally focused on validating exploitability and realistic attack paths, often by simulating how an attacker could leverage weaknesses in practice.

Cybersecurity audit

Usually broader in scope and more likely to cover controls, governance, documentation, operating effectiveness, and whether cyber risk is being managed in a structured way.

Why this gap matters more for VASPs

VASPs sit at the intersection of financial regulation, technology risk, third-party dependency, and cross-border supervision. That makes cybersecurity more than a matter of patching vulnerabilities or running a periodic test.

Many firms in the sector need two things at once. They need genuine technical assurance over internet-facing systems, applications, infrastructure, and operational controls. They also need assurance that is usable beyond the security team, whether for compliance review, board oversight, partner due diligence, or a jurisdiction-specific regulatory process.

The gap appears when a firm buys a service that solves the first problem but not the second.

Jurisdiction matters more than most firms assume

One of the easiest mistakes to make is assuming that the same service label means the same thing everywhere. It does not.

Different markets use different terminology, different approval structures, and different levels of formality around cyber obligations. A penetration test that is appropriate in one setting may not fully answer the question in another. The safest approach is to begin with the exact rule, guidance note, supervisory expectation, or internal requirement that is driving the work.

What this looks like in practice

Scenario 1: a VASP needs technical remediation support

A firm wants to understand its exposure, prioritize weaknesses, and reduce the likelihood of compromise. In that case, a vulnerability assessment, external scanning, or targeted penetration testing may be the right starting point.

Scenario 2: a VASP needs testing plus broader control review

A firm is preparing for internal compliance review or board oversight and needs more than a technical findings list. It may need a broader engagement that also considers documentation, control coverage, operational processes, and how findings are presented.

Scenario 3: a VASP is responding to a regulator-linked requirement

A firm is trying to satisfy a formal obligation under a licensing or supervisory framework. In that case, the critical question is not only what service is required, but whether the engagement is scoped and documented in a way that fits the requirement.

Third-party risk is part of the picture

VASP cybersecurity is rarely confined to the firm’s own internal systems. Many firms depend heavily on cloud providers, infrastructure partners, payment integrations, wallet technology, intermediaries, and other vendors.

That is why a narrow testing exercise may identify technical weaknesses in one part of the environment while missing the broader operational picture. In practice, understanding third-party dependencies is often part of understanding the real cybersecurity risk of the business.

The most common mistake: starting with the vendor, not the requirement

The easiest way to buy the wrong engagement is to start with a service catalogue instead of the underlying obligation.

If a firm begins by asking which vendor offers a penetration test, it may be narrowing the conversation too early. The better starting point is the requirement itself. Is the goal to improve security posture, support licensing, respond to a formal cyber requirement, or prepare for compliance or supervisory scrutiny?

Those objectives overlap, but they are not identical. A test that is suitable for technical remediation may not be sufficient for a broader compliance-driven purpose. Conversely, some firms overcomplicate matters by buying a more formal engagement when what they really need first is focused technical validation and remediation.

Questions to ask before engaging a provider

·         What exact rule, guidance, or business requirement are we trying to satisfy?

·         What output do we need at the end: a technical findings report, a broader control review, or something that supports licensing, compliance, or governance review?

·         Do we need technical testing, a broader audit, or both?

·         Does the relevant jurisdiction expect anything specific around assessor competence, experience, or approval?

·         Can the provider clearly explain where its role starts and ends?

What this means for VASPs

The practical takeaway is straightforward. A VASP should not begin with the question, “Which testing firm should we hire?” It should begin with, “What are we actually trying to satisfy, and what kind of engagement is appropriate for that requirement?”

That is usually the difference between buying a service that is technically useful and buying one that is genuinely useful to the business.

Final thought

The VASP cybersecurity gap is not simply the gap between secure and insecure firms. It is often the gap between doing technical work and being ready to evidence that work in a way that fits a regulated environment.

As VASP regimes continue to mature, that distinction is likely to matter more, not less. The safest path is to start with the requirement, map it to the right type of engagement, and only then choose the provider.