This is a general overview written for engineering and security teams, not legal advice. Regulatory text changes, obligations differ by entity and jurisdiction, and you should confirm what applies to you with your own counsel and supervisor.
Something has quietly changed in how financial regulators think about security testing, and a lot of crypto and fintech teams are still answering the old question.
The old question was did you test? You booked a penetration test, received a PDF, filed it, and produced it when someone asked. The new question is is the control still working? Those sound similar. Operationally they are nothing alike.
The shift, in three rulebooks
MiCA brought crypto-asset service providers in the EU into a regime that expects security and operational-resilience arrangements to be assessed before a platform starts handling client funds, and maintained afterwards. The licensing moment gets the attention. The maintenance obligation is the part that outlives it.
DORA goes further for in-scope financial entities, setting out ICT risk management and a digital operational resilience testing programme — including, for entities meeting the criteria, advanced threat-led penetration testing. The framing throughout is a programme, recurring and evidenced, not an engagement you commission and forget.
NYDFS has been the clearest on the mechanics. Its cybersecurity regulation pairs periodic penetration testing with regular vulnerability assessment, and treats continuous monitoring as the alternative that satisfies the same underlying concern. Read that structure and the intent is hard to miss: the regulator cares about whether exposure is being detected between tests, not about the existence of the test.
Different instruments, same direction. Evidence that a control operated, not evidence that it was once examined.
Why the annual model breaks for platforms that ship
A penetration test describes a system as it was during one week. If you deploy monthly, that is a reasonable approximation. If you deploy several times a day — which most exchange, wallet and payment platforms now do — the report is describing something that no longer exists by the time it is delivered.
The gap is not theoretical. Three failure shapes recur:
The change after the test. The audited code was fine. The IAM policy edited two weeks later was not. Nothing in an annual cycle catches this.
The fix that was never verified. A finding is remediated, a ticket moves to done, and nobody replays the original reproduction against the new code. A meaningful share of "fixed" findings are fixed in the wrong place, or fixed on one path and not the equivalent one.
The control that drifted. An exception was granted with a compensating control and a review date. The review date passed. The compensating control was decommissioned in a refactor. On paper the risk is accepted; in practice nothing is compensating for it.
Each of these is invisible to a point-in-time report by construction, and each is exactly what a supervisor is probing when they ask what happened between assessments.
What continuous assurance actually means
The phrase is used loosely, so it is worth being precise. It does not mean running a full scan nightly — that produces noise and a large bill without improving coverage.
It means event-driven reassessment: a merge, a deployment, an IAM change, a contract upgrade, a signer rotation, a new certificate or a newly published advisory affecting your dependency graph each triggers targeted re-evaluation of what that change actually touched.
It means verification rather than closure: a finding is not closed because a ticket moved, but because the original evidence was replayed against the changed code and failed to reproduce.
It means assurance state per asset: every asset carrying a current state — unknown, observed, assessed, at risk, remediating, verified, drifted — so that coverage gaps are visible facts rather than assumptions.
And it means exceptions that expire: an accepted risk with a date, a named approver, and an alert when the control it depended on moves.
The evidence supervisors and auditors actually want
If you are building toward this, these are the artefacts worth being able to produce on request:
- Authorization history — what was in scope for each assessment, what was excluded, who authorised it and when it lapses.
- Coverage records — what was assessed, what was skipped, and the recorded reason. "We did not check that" with a reason is a far better answer than silence.
- Finding lifecycle — discovery, corroboration, validation, ownership, remediation and verification, with dates.
- Tool and model versions — so a result can be re-derived months later rather than taken on trust.
- Exception register — accepted risks, compensating controls, approvers, expiry dates.
- Drift detection — evidence that you would notice if an approved control state stopped being true.
That list is not a compliance exercise bolted onto a security programme. It is the natural output of a programme that is actually running continuously — which is the point. If producing it is painful, that is usually a signal about the programme rather than about the paperwork.
Where certification still sits
One thing worth stating plainly, because vendors blur it: generating evidence is not the same as certifying compliance.
A platform can map findings to SOC 2 criteria, ISO 27001 controls, NIST CSF and 800-53, PCI DSS, DORA and NYDFS requirements, and retain the evidence behind each. It cannot make you compliant, and it cannot substitute for an accredited auditor's opinion. What it can do is make the auditor's job an examination of real records rather than an archaeology exercise.
Practical next step
If you are preparing for a licence application, a DORA readiness review or a SOC 2 Type II observation window, the useful question is not "when is our next pentest booked". It is: if a supervisor asked what changed in our estate last month and whether any of it created exposure, could we answer with records rather than recollection?
Coiny's autonomous AI penetration testing platform is built around that question — event-driven reassessment, fix verification, and a retained evidence trail per finding — and sits alongside the wider risk, security and compliance programme for the controls it tests.
