A penetration test, or pentest, is a controlled attack on your own systems. A security specialist tries to find weaknesses in your apps, APIs, cloud, or network and then really exploit them, the way an attacker would. The point is to learn where your defenses give way before someone with worse intentions does.
A penetration test turns up flaws your own team would probably never spot, because it's hard to see the holes in a system you designed yourself. It's also a requirement in a lot of regulations, licenses and security standards. Usually a pentest isn't a standalone thing but one piece of a wider governance framework like DORA, PCI DSS, CCSS, SOC 2 or ISO 27001, the set of controls that keeps data secure and private and makes sure only the people who should see sensitive information can.
How a pentest is done
At Hacken, pentests follow NIST SP 800-115 and the Penetration Testing Execution Standard (PTES), and a typical engagement takes 2 to 4 weeks.
Let's walk step by step:
- Scoping and threat model. We agree on what's in scope, the rules of engagement and who would realistically attack you: an insider, a financially motivated group, a state actor. Mapping their likely moves (we use MITRE ATT&CK and STRIDE) decides where testers spend their time.
- Recon and mapping. Testers map your attack surface from the outside in: public information, exposed services, versions, and the trust boundaries between your users, apps, databases and cloud.
- Exploitation and escalation. Manual and automated testing. Getting in is half the job; the other half is seeing how far one foothold goes.
- Reporting. Each finding comes with a severity, proof that it's real and a fix you can hand to an engineer.
- Retest. You fix, we check the fix and update the report. One retest is included.
When testing ends, testers clean up after themselves: test accounts, uploaded files and tools are removed, so your systems are left as they were, minus the holes. And you get a report with documented findings and remediations.
If you imagined a Hacken engineer going into your office disguised as a deliveryman, or phishing exercises, you probably mixed it up with red teaming, which runs longer and also tests whether your team notices the attack.
Who asks for a pentest in fintech, crypto and finance
| Framework | Who it applies to | What it asks for |
|---|---|---|
| DORA, Article 24(6) | EU financial entities, including crypto-asset service providers licensed under MiCA | Tests at least yearly on all ICT systems that support critical or important functions |
| DORA, Article 26 | Entities their authority designates | Threat-led penetration testing (TLPT) at least every 3 years, on live production systems |
| PCI DSS 4.0.1, Requirement 11.4 | Anyone who stores, processes or transmits card data | Internal and external pentests every 12 months and after significant changes |
| NYDFS, 23 NYCRR 500.5 | Financial firms licensed by the New York DFS | A pentest by a qualified party at least once a year |
| CCSS | Exchanges, custodians and wallets seeking certification | Third-party audits and pentests are part of the standard; Level 3 expects them to be thorough |
| SOC 2, ISO 27001 | Anyone selling to enterprises or banks | No fixed pentest rule, but auditors usually expect a recent one as evidence |
As you see, almost every framework requires pentests "at least yearly". PCI DSS is the one that also ties testing to change: a significant update to the card environment means a new test, whatever the date. If you're in the EU, our DORA compliance guide covers the rest of the testing program.
When does a pentest stop being valid?
A pentest report has one date on it: the day testing ended. It describes the system as it was that day.
In our Q3 2026 Security & Compliance Report we looked at how long different kinds of security evidence stay useful and sorted them into three groups:
- Time-bound evidence, like Proof of Reserves and vulnerability scans, is only as good as it is recent.
- Cycle-bound evidence, like certifications, SOC 2 reports and regulator-mandated audits, lasts as long as its official cycle.
- Change-bound evidence, like audits, describes one specific build and goes out of date when that build changes.
The rule that matters here: a material change within the scope of the evidence means it needs reassessing, no matter how young it is. A pentest from last month on a login flow you rebuilt last week is already stale.
Is your pentest stale already?
Pull up your last report and check five things:
- Date. Is it older than your framework's cycle, usually 12 months?
- Scope. Does it cover what you run today, or what you ran then?
- Critical changes. Have you touched authentication, payment flows, custody or key signing, external APIs or core infrastructure since?
- New surface. Any new product, integration, entity or license since the test?
- Fixes. Were the findings retested, or just marked "done"?
A "yes" on the change questions makes the report stale for that part of the system, whatever the date says.
Are you really exposed between tests?
The standard pitch for a pentest-as-a-service subscription goes like this: every day you don't test, you're exposed. That's true in theory. In practice, we don't fully agree.
Financial companies don't rewrite their ledger, custody setup or authentication every month, and they shouldn't. Changing critical functionality that often is its own risk, and testing it every time would just turn that risk into an invoice. What changes often is the stuff around the core: new features, a new API partner, a new market. Those deserve a test when they change, not when the calendar says so.
The exception is multi-entity groups. When you're adding an entity, a license or a product every quarter, something is always changing, and a calendar starts to make sense because there's never a quiet month.
Annual vs continuous penetration testing: which one should you choose?
As the names suggest, an annual pentest happens once a year. Continuous penetration testing, despite its name, isn't continuous at all. It's a series of pentests spread across the year: monthly, per sprint, or after significant updates to code and systems. Some vendors may also fill the gaps with automated scanning, which is useful, but it isn't a pentest.
The two aren't quite the same kind of thing: one is a single deep test, the other is a schedule of smaller ones. Side by side, they look like this.
Do you need more than an annual pentest?
Does a regulation or certificate already ask for more than one test a year?
Do you change critical systems more than a couple of times a year?Authentication, payment flows, custody and key signing, external APIs, core infrastructure
Do you run several entities, or keep launching products and licenses?
If a hole slipped into a changed system, could you live with it until next year's test?
The short version: the annual test buys depth and a clean piece of evidence, while recurring tests buy freshness. Neither one buys both.
Most teams end up at "annual, plus a targeted test after critical changes". Simply put, it's enough for the vast majority of governance requirements, including PCI DSS, and it's cheaper than a subscription you don't use. But keep in mind that it won't cover DORA's threat-led penetration testing, which entities designated by their regulator need at least every three years.
Work through four questions in order and stop at the first one that gives you an answer.
- Does a regulation or certificate already ask for more than one test a year?
- Do you change critical systems more than a couple of times a year?
- Do you run several entities, or keep launching products and licenses?
- If a hole slipped into a changed system, could you live with it until next year's test?
Do you need more than an annual pentest?
Does a regulation or certificate already ask for more than one test a year?
Do you change critical systems more than a couple of times a year?Authentication, payment flows, custody and key signing, external APIs, core infrastructure
Do you run several entities, or keep launching products and licenses?
If a hole slipped into a changed system, could you live with it until next year's test?
So, in the end, you're choosing between a pentest-as-a-service and a regular pentest. If you expect a lot of tests next year across several companies or products, look at our Enterprise Assurance Programme. It's a 12-month retainer with a fixed yearly fee for all Hacken services within capacity that gives you predictable security spend, faster delivery, and continuous security access beyond just penetration testing.
Why not just use AI to pentest between real ones?
It's a good idea, partly. And there is a December 2025 study by Stanford, Carnegie Mellon and Gray Swan AI that answers it. In it, ten professional pentesters and several AI agents worked on a live university network of about 8,000 hosts.
The headline: a purpose-built agent called ARTEMIS came second overall, beat 9 of the 10 humans, and cost $18 an hour, against $60 for a professional owner of skin, meat, bones and pentest qualifications.
Look at the details, though, and it gets less exciting:
- Off-the-shelf tools did badly. Two general-purpose agents, Claude Code and MAPTA, refused the task out of the box, and a third stalled at recon. All three ended with zero findings.
- It missed the big one. 80% of the human testers found a remote code execution bug behind a web interface. ARTEMIS couldn't click through the interface, reported two minor misconfigurations instead, and moved on.
- It cried wolf more. It reported more false positives than the humans did, for example, treating a redirect back to the login page as a successful login.
So if the plan is to point a general-purpose AI assistant at your own app and call it a pentest, the study suggests you'd get further doing it by hand. AI is genuinely good at breadth: enumerating hosts and catching known issues between tests. For the report a regulator reads, you still want people who pivot, chain bugs and check each other's work.
That's how we run it. More than one engineer looks at the findings before they reach you, and our name goes on the report.
