Services
AIManaged ServicesConsultingOutsourcing
Differentiators
Compliance & SovereigntyEmail InfrastructureObservability & AIFree Tools & Assessments
Language
EnglishDeutsch — soonFrançais — soonEspañol — soon
Book a review
Managed Services · Offensive security

Find it before they do — and prove you looked.

A scan tells you what is known to be weak. A penetration test proves what can actually be exploited — and gives an auditor the evidence DORA, NIS2, PCI DSS and ISO 27001 ask for. Human-led testing and continuous PTaaS, delivered by certified testers inside the EU.

Scope a penetration test What we test →

Penetration testing is a human-led security assessment in which certified testers actively try to exploit your systems — the way an attacker would — to prove whether your controls genuinely hold, rather than scanning for issues a tool already knows about. Penetration Testing as a Service, or PTaaS, runs that assurance continuously with a live dashboard and audit-ready reporting, instead of a once-a-year PDF that ages within days. In the EU it is mandated or expected by DORA, NIS2, PCI DSS and ISO 27001, and Argus Root delivers it with EU-resident testers and evidence kept under EU jurisdiction, mapped to the framework you are audited against.

In short

  • A scan is hygiene; a penetration test is assurance — human-led, exploiting and chaining real weaknesses. Auditors reject a scan submitted as a pentest.
  • EU drivers: DORA Articles 26–27 (TLPT, every 3 years, TIBER-EU), NIS2 Article 21, PCI DSS 4.0 Requirement 11.4 (annual + change), ISO 27001 control A.8.8.
  • The market is moving to continuous PTaaS — projected from $0.72B in 2026 to $1.98B by 2031 (22.6% CAGR), roughly double the broader pentest market ($2.72B → $5.54B).
  • Kickoff falls from ~6 weeks to 24–72 hours; a credible engagement runs from ~$5K for a small web app to $40–80K for an annual PTaaS subscription.
  • The average data breach now costs $4.88M — the case for finding it first is no longer only about ticking a compliance box.

What is the difference between a vulnerability scan and a penetration test?

The two are often sold as the same thing, and the confusion is expensive. A vulnerability scan is automated: it runs signature-based checks for missing patches, known CVEs and default configurations, and produces a long list of potential issues, many of them false positives. It is essential hygiene, and it is what our vulnerability-management program runs continuously. But it tells you only what is already known to be weak, in the abstract.

A penetration test is human-led. A tester actively tries to exploit the weaknesses, chains them together into real impact — privilege escalation, lateral movement, data access — and validates that each finding is genuinely exploitable rather than theoretical. That is the difference between a list of possibilities and a demonstration of what an attacker could actually achieve in your environment. Scans are hygiene; tests are assurance, and the gap between them is exactly where a breach lives.

This distinction has a hard compliance edge. Regulators and certification auditors know the difference, and submitting a scan report as evidence of penetration testing is itself a compliance risk. It is also why a suspiciously cheap engagement is a warning sign: a fifteen-hundred to four-thousand dollar 'comprehensive' web application test is almost always a scan with a cover page, and the true cost of that shortcut is the exploit it missed.

Which EU regulations require a penetration test?

More of them than most teams realise, and in different forms. For financial entities, DORA is the most prescriptive: Articles 26 and 27 require significant entities to conduct threat-led penetration testing under the TIBER-EU framework, at least every three years, against live production systems. NIS2 does not name a test in the same way, but its Article 21 raises the expectation for testing control effectiveness, and national competent authorities increasingly treat a credible penetration-test report as key evidence of readiness. ISO 27001 control A.8.8, on technical vulnerabilities, expects organisations to test their controls regularly, with findings tracked through to remediation — a test without a documented fix is a gap in the audit trail.

The picture is the same across the other frameworks European organisations live under. PCI DSS 4.0 carries an explicit penetration-testing obligation under Requirement 11.4, annually and after any significant change, for anyone handling cardholder data. SOC 2 points the same way through its CC4.1 control. The EU AI Act adds a cybersecurity expectation for high-risk AI systems across their lifecycle. The common thread is that all of them now want proof the controls work, not merely proof they exist on paper — and they increasingly want that proof on a regular cadence rather than once.

The practical trap is managing each regulation in isolation, running separate tests with separate providers for DORA, NIS2 and ISO and duplicating cost while leaving gaps where the frameworks meet. We scope a single engagement against the specific obligations that apply to you, so one well-defined test produces evidence accepted across several of them, and the scope matches the regulatory scope rather than whatever was easiest to point a tool at.

From a once-a-year PDF to continuous PTaaS.

The traditional model — a single engagement, a report delivered weeks later, filed until next year — fits an estate that barely changes. Few estates are like that now. A team shipping to production every week cannot rely on an annual snapshot that is out of date within days of being signed, and auditors have noticed: they increasingly ask for evidence of a testing cadence, not a single dated PDF. That is the shift Penetration Testing as a Service answers, and why it is the fastest-growing corner of the market, projected to roughly triple from 0.72 billion dollars in 2026 toward 1.98 billion by 2031, about double the growth rate of testing as a whole.

Scope Rules of Engagement Test manual-first · PTES/OWASP Findings live dashboard · rated Retest verify the fix held Audit-ready report mapped: DORA · NIS2 · PCI · ISO continuous loop — retest as the environment changes · kickoff in 24–72h, not 6 weeks
PTaaS turns testing from an annual event into a loop: scope it once, test manual-first, see findings live, verify the fixes, and produce the audit-ready report — then repeat as the estate changes, which is the cadence regulators now expect.

The practical gains are concrete. Time-to-kickoff drops from around six weeks to between 24 and 72 hours, because scoping and onboarding are handled on a platform rather than rebuilt each time. Findings appear as they are confirmed, so a critical issue is not held back for a final document. Retesting is built in, so a fix is proven rather than assumed. And the evidence accumulates into a continuous record, which is precisely what an auditor asking 'when did you last test, and what did you do about it' wants to see.

What we test, and how.

Coverage spans the surfaces that actually get attacked: the external perimeter, web applications and their APIs, internal networks and lateral-movement paths, cloud configurations, identity and directory systems, and increasingly the AI and machine-learning systems that now sit in production workflows. The approach is manual-first. Automation widens coverage, but a human tester goes where scanners cannot — business-logic flaws, chained vulnerabilities, the context-specific paths that no signature will ever match — and validates every finding by hand before it is reported.

The discipline around the testing is what keeps it safe and credible. Engagements follow recognised methodologies — PTES, the OWASP testing guides and NIST SP 800-115 — and are carried out by certified, EU-resident testers. Nothing begins until a Rules of Engagement document is signed, defining the targets, the window, the escalation path and what is firmly out of scope. The summary below is the shape of that scope and the result it produces — a set of rated findings mapped to the framework, not an attack recipe.

We cover Web & API External / internal network Cloud Identity / AD AI / LLM systems TLPT (TIBER-EU)

What you get, and what an auditor gets.

The deliverable is built to be used by two audiences at once. For your engineers, each finding comes with an exploitability rating, the business impact, a clear reproduction path and remediation guidance ranked by risk, so the fix work is prioritised rather than dumped. For your auditors and your board, the same engagement produces an executive summary, an attestation letter and a report mapped to the specific control the assessor will check — ISO 27001 A.8.8, DORA Article 26, PCI Requirement 11.4 — so the evidence drops cleanly into the audit rather than needing translation.

Crucially, the engagement does not end at the report. A finding stays open until the fix is verified or the risk is formally accepted, and retesting is included rather than sold back to you later. We provide the remediation guidance, work alongside your teams, and re-test to confirm the controls held. The honest test of a provider is whether they behave like an advisor who stays for the fix or a contractor who hands over a PDF of problems and leaves — and the second of those does not satisfy a regulator who asks to see remediation evidence, only findings.

How does this fit with vulnerability management and the rest?

Penetration testing is one layer of a security program, not the whole of it, and it works best on top of the others. The continuous hygiene — scanning the estate, prioritising by real risk, driving the fixes — is the job of our vulnerability and patch management program, and it makes a test sharper by clearing the noise before a human looks. The test then provides the periodic assurance that the controls genuinely hold, which scanning alone cannot give. Where the weakness lives in the build pipeline rather than the running system, our DevSecOps and supply chain security work covers it.

Around both sits the broader posture: the detection and response, the policies and the audit story owned by managed security, and the framework mapping and sovereignty argument carried by our compliance and sovereignty practice. For a financial entity under DORA, the threat-led test is the sharp end of an operational-resilience program that runs across all of these. We deliver the test as part of that whole, so the evidence it produces strengthens the rest rather than sitting in isolation.

Run inside the EU, by testers under EU law.

A penetration test generates some of the most sensitive material an organisation will ever hand to a third party: findings, screenshots, captured credentials, payloads and logs that together describe exactly how to get in. Where that evidence is handled and stored is therefore not a logistics detail but a jurisdictional decision. Routing it through testers and platforms outside the EU reintroduces precisely the exposure the DORA, NIS2 and GDPR obligations behind the test are meant to close.

We keep the whole chain inside the EU: EU-resident certified testers, EU evidence handling, and a clear, contracted approach to how that material is stored and destroyed. The report is mapped to your specific framework, the engagement is scoped against your real regulatory obligations, and the proof you can hand an assessor was produced under the same law they are holding you to. It is the same principle that runs through everything Argus does — a European operator that does the work itself and keeps the sensitive parts where they belong.

Questions buyers ask.

What is the difference between a vulnerability scan and a penetration test?
A scan is automated. It checks for known issues — missing patches, known CVEs, default configurations — and returns a long list, often with false positives. A penetration test is human-led: a tester actively tries to exploit weaknesses, chains them into real impact such as privilege escalation or data access, and confirms each finding is genuinely exploitable. Scans are hygiene; pentests are assurance. Submitting a scan report as a penetration test is a compliance risk, because auditors know the difference.
Which EU regulations require a penetration test?
Several, in different ways. DORA requires significant financial entities to run threat-led penetration testing under Articles 26 and 27, at least every three years, following the TIBER-EU framework. NIS2 does not prescribe a test by name but its Article 21 raises the expectation, and regulators treat a credible report as evidence. PCI DSS 4.0 mandates testing under Requirement 11.4, annually and after significant change. ISO 27001 control A.8.8 expects regular testing of control effectiveness. SOC 2 and the EU AI Act add their own demands.
How often should we run a penetration test?
At a minimum, annually, and additionally whenever something material changes — a major release, a cloud migration, a new API, an identity change, a merger, or a newly deployed AI system. PCI mandates annual plus significant change. For estates that change weekly, an annual snapshot is out of date within days, which is why continuous testing through a PTaaS model is increasingly the answer for externally exposed production assets.
What is PTaaS, and how is it different from a traditional pentest?
Penetration Testing as a Service replaces the one-off, PDF-at-the-end engagement with a continuous model: a live dashboard of findings, retesting as code ships, and audit-ready evidence produced year-round rather than once. It combines human testers with a platform that handles scoping, status, triage and reporting, so time-to-kickoff falls from around six weeks to 24 to 72 hours. The deliverable becomes an ongoing assurance feed, not a snapshot that ages immediately.
Is a cheap penetration test worth it?
Usually not, and it can be worse than none. A 1,500 to 4,000 dollar 'comprehensive' web application pentest is almost always an automated scan dressed up, or an inexperienced tester, and the real cost arrives later when an attacker finds the flaw the engagement missed. A serious test is human-led, validates every finding manually, and is priced accordingly — from around 5,000 dollars for a small web application upward.
Who carries out the testing, and to what standard?
Certified, EU-resident testers working manual-first, with automation used only to widen coverage rather than to replace human judgement. Engagements follow recognised methodologies — PTES, the OWASP testing guides, NIST SP 800-115 — and testers hold credentials such as OSCP or CREST. Every finding is verified by hand before it is reported, so what you receive is exploitable reality rather than a scanner's guesses.
What does an auditor actually accept as evidence?
A report that maps each finding to the framework you are audited against, with exploitability and business-impact ratings, the remediation taken, and the retest that confirmed the fix. A test that confines itself to one minor web application does not satisfy DORA's requirement to test resilience across the full ICT environment, so scope must be defined against the regulation, not against what is easiest to test. We produce the report in the form the assessor expects.
What is threat-led penetration testing (TLPT)?
TLPT is the advanced, intelligence-driven test DORA requires of systemically important financial entities, conducted under the TIBER-EU framework at least every three years. It is not a standard pentest: it has a threat-intelligence phase, a red-team execution phase against live production systems without the defending team's knowledge, and a closure and remediation phase overseen by the competent authority. Confining it to non-critical systems, which some firms attempt, is exactly what supervisors push back on.
Will testing disrupt our production systems?
Not when it is scoped properly. We agree a formal Rules of Engagement document before any testing begins, defining the targets, the window, what is in and out of scope, and the escalation path. Destructive actions such as denial-of-service or production-data exfiltration are excluded unless explicitly contracted and contained. The point is to find what an attacker could do, safely and under control, not to cause the outage ourselves.
How is penetration testing different from your vulnerability management?
They are complementary. Vulnerability management is the continuous program of scanning the whole estate, prioritising by real risk and driving fixes — the hygiene layer. A penetration test is the periodic, human-led assurance on top: it proves whether the controls actually hold against an attacker who chains weaknesses together. Scanning tells you what is known to be weak; testing tells you what can truly be exploited. A mature program runs both.
Can you test our AI systems?
Yes. AI and machine-learning systems are tested against manipulation, adversarial input and data leakage, covering training data, inference APIs and model logic. The EU AI Act raises the bar for high-risk systems, requiring appropriate cybersecurity across their lifecycle, and because AI systems change often, a once-a-year test fits them poorly. We treat AI testing as a recurring strand aligned to model iteration rather than a single event.
Do you just report problems, or help us fix them?
We stay through remediation. A finding is not closed until the fix is verified or the risk is formally accepted, and retesting is part of the engagement rather than a paid extra bolted on later. We provide remediation guidance mapped to risk, work with your teams on the fixes, and re-test to confirm they held — because a report you are left to act on alone is the failure mode, not the service.
Why run penetration testing with an EU provider?
Because the evidence a test produces — findings, screenshots, credentials, payloads, logs — is sensitive, and where it is handled and stored is a jurisdictional decision. EU-resident testers and EU evidence handling keep that material under EU law, which matters for the very DORA, NIS2 and GDPR obligations the test exists to support. We map engagements to your specific framework and keep the whole chain inside the EU.

Scope a test against the framework you answer to.

Tell us what you run and which obligations apply — DORA, NIS2, PCI DSS, ISO 27001 — and we will define a scope that satisfies them, give you a fixed engagement plan, and book certified EU testers, with kickoff in days rather than weeks. You get a clear picture of what will be tested, how the evidence will map to your audit, and what the report and retest will deliver, before anything begins.

Scope a penetration test See all managed services →