Methodology, internal & external
A documented, industry-accepted method, with tests at least every 12 months and after significant change, by qualified, independent testers.
Adversarial assurance
Find the path, not just the flaws.
Scanners list weaknesses. Attackers chain them. We test the way a capable adversary would, and report what they could actually reach.
- Web & API
- Network
- AWS · Azure · Google Cloud
- Who it is for
- Leaders who need independent proof that their defenses hold
- What we test
- Applications, APIs, networks, cloud and segmentation
- How we rate
- CVSS v4.0, adjusted for your exposure and data
- What you receive
- Executive narrative, technical report and retest
A clean scan is not a safe system.
Serious breaches rarely need one critical flaw. They chain several ordinary ones: a verbose error, a permissive role, a forgotten endpoint.
Scanners cannot reason about business logic or reachability. Our testers can, working from your threat model under written rules of engagement.
Client outcomes
What a well-run test changes.
The value lies in the decisions made afterwards, not in the number of findings.
01
Demonstrated attack paths
Evidence of how an adversary moves from entry point to sensitive data.
02
Priorities teams accept
Ratings that combine CVSS v4.0 with real exposure and business context.
03
Evidence auditors recognize
Structured for PCI DSS 11.4, ISO/IEC 27001, SOC 2 and DORA.
04
Verified remediation
Retesting confirms the path is closed, not just masked.
Requirements
What the standards actually ask for.
Frameworks mean different things by “penetration test”. These requirements shape scope and frequency most often.
Correct and retest
Exploitable findings are corrected in line with their risk ranking, then retested to verify the fix.
Segmentation testing
Confirm CDE isolation annually and after change, or every six months for service providers.
Resilience testing & TLPT
Annual testing of critical ICT systems, plus threat-led testing at least every three years for designated entities.
Interactive demonstration
Severity is a fact about your environment.
Adjust exposure, data sensitivity and exploit maturity to see why the same issue can warrant a different priority.
How we rate findings
We report a CVSS v4.0 vector for comparability, then a remediation priority based on what we demonstrated: reachability, data and chaining.
Loading interactive demonstration…
Simplified scoring model applied to a fictional finding. It shows the reasoning behind our priorities rather than the CVSS v4.0 equations.
Methodology
Structured to repeat. Creative enough to matter.
Aligned with OWASP WSTG and ASVS, PCI SSC guidance and NIST SP 800-115, and driven by manual judgment.
-
01
Scope
Targets, windows, exclusions and stop conditions agreed in writing.
OutputRules of engagement
-
02
Threat model
Map the attack surface from an adversary’s viewpoint.
OutputPrioritized hypotheses
-
03
Test & exploit
Automated coverage plus manual testing. Exploitation stops at proof.
OutputEvidence log
-
04
Chain
Combine weaknesses into realistic paths and assess impact.
OutputAttack-path narratives
-
05
Report & retest
Debrief with owners, then retest fixes within the agreed window.
OutputReport and retest letter
What we test
Every layer an attacker can reach.
Scoped together, so findings in one layer inform testing in the next.
Application & API
Authenticated, manual testing across every role, aimed at the authorization and business-logic flaws scanners cannot see.
- Broken object- and function-level authorization
- OAuth / OIDC flows, sessions and MFA bypass
- Payment-page integrity (PCI DSS 6.4.3 · 11.6.1)
Network
External tests show what the internet can exploit. Internal tests assume a foothold and measure how far it travels.
- Active Directory and Entra ID attack paths
- Lateral movement and privilege escalation
- PCI DSS segmentation from every out-of-scope segment
Cloud
Identity is the perimeter. We test what a stolen key or compromised workload could do in AWS, Azure and Google Cloud.
- IAM escalation and cross-account trust
- Kubernetes RBAC, pod security and escape
- CI/CD and infrastructure-as-code trust boundaries
Red teaming & TLPT readiness
Objective-based exercises that test detection and response. For DORA-designated entities, we prepare scope and governance for a TIBER-aligned test.
- Critical-function mapping and control-team set-up
- Tester eligibility under DORA Art. 27 confirmed in writing
Configuration posture is covered by Cloud Security & Assurance, and clients often combine the two.
Framework mapping
One test, several obligations.
We scope around the most demanding requirement that applies to you.
| Control area | PCI DSS v4.0.1 | ISO/IEC 27001:2022 | SOC 2 (TSC) | DORA |
|---|---|---|---|---|
| Periodic external & internal testing | Directly addressed | Partially addressed | Partially addressed | Directly addressed |
| Testing after significant change | Directly addressed | Partially addressed | Partially addressed | Partially addressed |
| Segmentation / isolation validation | Directly addressed | Partially addressed | Not addressed– | Partially addressed |
| Application security testing | Directly addressed | Directly addressed | Partially addressed | Directly addressed |
| Remediation and retest evidence | Directly addressed | Partially addressed | Partially addressed | Directly addressed |
| Threat-led red teaming | Not addressed– | Not addressed– | Not addressed– | Directly addressed |
Directly addressed Partially addressed or different evidence expectations , Not a primary objective. ISO/IEC 27001 through Annex A 8.8 and 8.29, SOC 2 mainly through CC4.1 and CC7.1, and DORA through Articles 24–27.
Industry considerations
Same techniques. Different consequences.
We plan around change freezes and feed findings straight into your DORA testing program. DORA readiness →
Scoped to PCI DSS 11.4 from the start, including six-monthly segmentation tests for service providers. PCI DSS →
Tenant isolation, cross-role authorization and a summary letter you can share with customers. SOC 2 readiness →
No intrusive techniques against clinical systems, and any PHI exposure triggers an immediate stop and notification. HITRUST →
Testing aligned to the authorization boundary and documented to FedRAMP penetration test guidance. FedRAMP →
Use cases
Where we are most often asked to look.
Broken object-level authorization
Changing an identifier returns another customer’s data.
Directory attack paths
A standard user reaches domain admin in a few steps.
Workload role escalation
A compromised container uses its role to read secrets.
Payment-page script tampering
A third-party checkout script is altered to skim cards.
Leaky CDE boundaries
A monitoring agent quietly bridges into the CDE.
LLM-integrated applications
Prompt injection, unsafe tool use and cross-user leakage.
Deliverables
What you hold at the end.
Written for the executive who needs exposure, and the engineer who needs the fix.
Executive summary
Exposure and attack paths in plain language.
Technical findings
Evidence, CVSS v4.0, priority and specific fixes.
Attack-path narratives
Where each control could have stopped the attacker.
Findings register
CSV or JSON for your ticketing system.
Attestation of testing
Scope, dates and method, shareable without the findings.
Retest report
Closure evidence for PCI DSS 11.4.4 and your audit files.
Accreditation & scope
Who tests, and how the work stands up
What MarkTillson delivers
- Named senior testers, with qualifications listed in every proposal
- Independent testing that meets PCI DSS 11.4 and FedRAMP guidance
- TLPT readiness and testing for DORA-designated entities
Built into every engagement
- Written authority for every target before testing starts
- Third-party platforms tested with the provider’s permission
- Threat intelligence sourced as TIBER-EU specifies
FAQs
Questions procurement and engineering ask.
How is a penetration test different from a vulnerability scan?
A scan finds known weaknesses at scale. A test confirms which are exploitable, finds the logic flaws scanners miss and chains issues into real paths. PCI DSS treats them separately, in 11.3 and 11.4.
Will testing disrupt production?
Not when it is planned properly. Rules of engagement set windows, rate limits, excluded techniques and stop conditions, and exploitation stops at proof.
How often should we test?
For PCI DSS, at least annually and after significant change, with six-monthly segmentation tests for service providers. Beyond compliance, time tests to your major releases.
Is retesting included?
Yes. Every proposal includes a retest of remediated findings within an agreed window, with an updated report.
Can we share the report with customers?
Share the attestation letter or the executive summary rather than the full technical report. We produce both as standard.
Can you perform DORA threat-led penetration testing?
Yes, for designated entities. TLPT follows Delegated Regulation (EU) 2025/1190 and TIBER-EU, and we confirm tester eligibility in writing before the engagement starts.
Scope a test
Tell us what an attacker would want. We’ll find the way in.
A senior tester will come back with a proposed scope, approach and rules of engagement, usually within one business day.