Security should run in parallel with legal and compliance work, not after them. Start with a gap assessment, scope the audit and penetration test early, and document custody, monitoring, and incident response as the platform is built. Early sequencing reduces rework, allows remediation before submission, and avoids the common failure where security evidence is still incomplete when regulators begin review.
Sequencing security work so the licence review is not held up
The practical answer is to treat security as a parallel workstream, not a final gate. A virtual asset firm should start by identifying security gaps early, then run audit and penetration testing in time to leave room for remediation before the application is submitted. That sequencing matters because regulators usually want evidence that controls already exist, not promises that they will be finished later.
The platform build should therefore be shaped around the evidence you will need to show: custody controls, monitoring, and incident response should be designed and documented as the environment is assembled, not reconstructed afterwards. If the team waits until legal drafting is complete, security evidence often becomes a last-minute dependency that delays the licence package even when the underlying technical work is otherwise sound.
A useful way to think about the schedule is to separate legal drafting, control design, implementation, testing, and evidence collation, while keeping them tightly coordinated. The aim is not just to “do security earlier”, but to make sure the audit trail, test results, and operational procedures mature alongside the platform itself.
What should be finished before submission?
Before filing, the firm should be able to show that the core control story is coherent: what assets are protected, who can move value, how custody is safeguarded, how activity is monitored, and what happens when something goes wrong. That means the security programme needs enough detail to survive regulator scrutiny without relying on future work or informal assurances.
For firms building a new stack, the main risk is not one missing document, but a mismatch between the application narrative and the real state of the controls. If the application says custody is tightly governed, but the test evidence, incident runbooks, or monitoring design are still being drafted, reviewers may reasonably pause the process. Early sequencing reduces that mismatch and gives the team time to close it.
Security testing should be positioned as evidence generation, not a box-ticking exercise. Scope the audit and penetration test early enough that findings can be fixed and retested before the submission window closes. If the first testing cycle happens too late, remediation becomes a schedule risk rather than an improvement step.
Why delay happens and how to avoid it
Most delays come from one of three places: unresolved gaps in the control design, late testing that exposes more remediation than expected, or incomplete documentation that forces the applicant to explain controls that have not yet been fully operationalised. The common thread is that security work was treated as a downstream dependency instead of part of the licensing critical path.
Firms also underestimate how much time is needed to turn technical controls into reviewable evidence. A control can exist in code or infrastructure long before it is described clearly enough for an application pack. That is why documentation should be written while the platform is being built, so the team can show both how the control works and how it is operated.
One practical discipline is to keep the remediation loop short. When testing finds a weakness, the team should know who owns the fix, how quickly it will be retested, and whether the issue affects the submission timeline. That avoids the common failure mode where testing is completed, but the evidence still cannot be signed off because the remediation backlog is unclosed.
Risk and Threat Considerations
Late sequencing creates both operational and security exposure. If custody controls, monitoring, or incident response are not mature when the licence review begins, the firm can end up presenting an incomplete control environment, which increases the chance of review delays, rework, or a paused application.
Failure mechanism: Security evidence is assembled after the platform is already too far along, so testing, remediation, and documentation compete with submission deadlines and leave gaps that regulators can see.
Impact: The firm may have to postpone filing, rerun tests, update procedures, or redesign parts of the operating model, all of which can slow launch and weaken confidence in the control environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-18 — Security Awareness and Skills Training | Supports coordinated control build-out and evidence discipline for licensing readiness. |
| Recommendation — Align control owners early so security evidence matures before submission. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Licensing sequencing depends on meeting regulatory obligations with evidence ready at review. |
| Recommendation — Map regulatory evidence requirements early and track completion before filing. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | The answer depends on sequencing security work to fit the firm's licensing context and obligations. |
| PR.PS-04 — Platform Security | Custody, monitoring, and incident response are platform security controls that must mature before review. | |
| Recommendation — Set the application timeline around security evidence needs, not after them. Build and document platform security controls alongside the licence application. | ||
Practitioner Guidance
What to prioritise: Start with a gap assessment that identifies the controls most likely to be examined first, then lock the testing schedule around those controls rather than around developer convenience. The earlier the firm knows where its weak points are, the more likely it is to reach submission with a credible, reviewable pack.
What to verify: Confirm that the audit trail, penetration test scope, custody narrative, monitoring design, and incident response process all describe the same operating model. If those artefacts disagree, treat that as a licensing risk, not just a documentation issue.
Practitioner takeaway: The fastest path to approval is usually not “finish legal first and security later”, it is to build the licence evidence and the control environment together so testing, remediation, and documentation can converge before review.