Testing that satisfies your assessors
Most organisations commission a penetration test because something requires one. Our reporting is structured so the evidence lands in the format your auditor is expecting — without you having to translate it.
What each framework actually asks for
Requirements differ more than people expect. Knowing precisely which clause applies is what stops you buying more testing than you need — or less than will pass.
| Framework | Relevant requirement | What satisfies it |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 8.8 — technical vulnerability management Annex A 8.29 — security testing in development and acceptance |
Regular testing with documented findings and evidenced remediation. Our report plus retest evidences the full cycle, which is what assessors look for. |
| PCI-DSS v4.0 | 11.4.1–11.4.6 — internal and external penetration testing, segmentation validation | Annual testing plus testing after significant change. Segmentation must be validated at least every twelve months for merchants, six for service providers. |
| SOC 2 | CC4.1 — monitoring of controls CC7.1 — vulnerability identification |
Evidence that vulnerabilities are identified through a defined process and remediated. Testing cadence and closure evidence both matter to the auditor. |
| UK GDPR / EU GDPR | Article 32(1)(d) — regular testing of technical measures | Demonstrable, repeated testing of the measures protecting personal data. No prescribed frequency, so document your rationale for the cadence you chose. |
| DORA | Articles 24–27 — digital operational resilience testing | Annual testing for all in-scope EU financial entities; threat-led penetration testing every three years for those designated significant. |
| SAMA Cyber Security Framework | 3.3.14 — penetration testing | Required for Saudi financial institutions, covering internal and external surfaces with defined remediation timelines. |
| Saudi NCA ECC | 2-11 — penetration testing controls | Periodic testing of internet-facing services and internal systems, with results reported to the appropriate governance body. |
| UAE Information Assurance Standard | T5.5.1 — technical compliance and vulnerability assessment | Regular assessment for entities in scope of the UAE IA Standard, including critical infrastructure operators. |
| NIS2 | Article 21 — cybersecurity risk-management measures | Policies on assessing the effectiveness of risk management measures. Testing is the practical evidence that assessment occurs. |
| TIBER-EU / CBEST | Threat-led penetration testing frameworks | Intelligence-led red teaming for designated financial institutions. Our red team work is structured to prepare organisations for these programmes. |
This table summarises common requirements for planning purposes. It is not legal advice, and your specific obligations depend on your jurisdiction, sector and the scope your assessor has agreed. Confirm with your auditor or counsel.
What you can hand to an auditor
Technical report
Full findings with reproduction steps, evidence, CVSS v3.1 vectors and remediation guidance. The document your engineers work from.
Executive summary
Posture, risk themes and prioritised recommendations in business language, suitable for board and audit committee circulation.
Attestation letter
A signed statement of scope, dates and methodology. This is usually what your customers and assessors actually ask for.
Retest report
Updated status per finding after remediation — the evidence that closes the loop for ISO 27001 and SOC 2 assessors.
Segmentation evidence
For PCI-DSS, explicit documentation of which boundaries held and which did not, per tested path.
Methodology statement
Which standards were followed for your specific engagement, so assessors can verify the approach rather than take it on trust.
Compliance questions
How often do we need to test?
PCI-DSS and DORA specify annually plus after significant change. ISO 27001, SOC 2 and GDPR do not prescribe a frequency — they require a defined process, so you choose a cadence and justify it. Annual testing plus testing after major architectural change is the defensible baseline almost everywhere, and is what we would recommend regardless of what your framework demands.
What counts as a "significant change"?
A new authentication mechanism, a new payment flow, a major framework or platform upgrade, a migration to different hosting, a new externally-reachable service, or a merger bringing unfamiliar infrastructure into scope. Cosmetic changes and routine patching do not count. If you are unsure, the test is whether the change altered your attack surface or your trust boundaries.
Does the tester need to be certified or accredited?
It depends on the framework. PCI-DSS requires a qualified tester but does not mandate a specific certification. CBEST and TIBER-EU require accredited providers. Many customer security questionnaires ask for CREST or equivalent. Our testers hold CREST, OSCP and GIAC certifications individually; the company itself is not currently a CREST member, and we would rather tell you that plainly than let a badge imply otherwise. If your framework specifically requires a CREST member company, say so at scoping and we will tell you honestly whether we qualify.
Can one test cover several frameworks?
Usually yes. The underlying technical work is largely the same; what differs is how evidence is presented and which scope boundaries must be demonstrated. Tell us every framework you are working towards during scoping and we will structure one engagement to produce evidence for all of them, rather than you commissioning three overlapping tests.
Our customer sent a security questionnaire asking for a pentest report. Do we send the whole thing?
No — and you should not. A full technical report is a roadmap to your unremediated weaknesses, and it should never leave your organisation. The attestation letter exists precisely for this: it confirms scope, dates, methodology and that testing occurred, without disclosing findings. That is what your customer's question is actually asking for.
Tell us which framework you are working towards.
We will tell you what testing it actually requires — including when that is less than you were quoted elsewhere.