01
Final pentest report
- One document for management, technical team and audit: executive summary, technical report with proofs of concept, and prioritised remediation guide.
PENTESTING FOR ISO 27001
ISO 27001 asks you to prove your controls work. We provide the proof.
ISO 27001 is about managing risk and showing your controls actually hold, not about having more documents. We do not implement the standard or issue the certificate; we run the penetration testing that turns controls into audit-ready technical evidence: verified findings, demonstrated impact, prioritised remediation and an included retest.
Book an introductory meeting
30 minutes with a senior consultant.
Protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.
Request received.
A senior consultant will reply within one business day.
No se ha podido enviar. Inténtalo otra vez o escríbenos.
Trusted by companies in regulated sectors across Europe.
ISO 27001 does not ask for a PDF. It asks you to prove your controls work.
A scan tells you what might be wrong. A pentest proves what an attacker could actually do, and whether the controls in your Statement of Applicability hold when tested.
See what your ISO 27001 pentest would look like, on your own scope.
When you need technical evidence, not just a policy.
The standard sets no fixed frequency. The right trigger is risk plus significant change, which is why many organisations run it as a recurring review and again whenever the environment changes materially.
A bid that asks for technical evidence
A certification bid, a public tender or a large customer’s security questionnaire asks for proof, not a policy. The pentest produces it in the format your auditor and your customer accept.
Controls flagged as needing evidence
Your auditor has flagged controls that documentation alone does not support. We test those controls and hand back the technical evidence that closes the finding.
A major systems change, or a new company inside the scope
After a significant change to applications, infrastructure, SSO or IAM, or when a new company enters the ISMS scope, what was tested no longer is.
Confirming the fix holds
You have applied the fixes from an earlier report. We retest each finding and sign off which ones are genuinely closed, with full traceability.
Walking into the audit with the evidence done
Before a surveillance audit or a recertification, to show maturity sustained over time rather than a snapshot of the last month.
The ISMS written, the auditor not here yet
You are going for initial certification and your consultant built the ISMS. The Statement of Applicability can say technical controls are implemented when nobody has tested them. We test the ones in scope and leave you the evidence.
What happened in one system and the rest of the ISMS scope
You have had an incident, or a near miss. Once it is contained, the same path may still be open across the rest of the ISMS scope. We test those systems and document what we find.
Not sure if ISO 27001 pentesting is your right next step?
Talk to us
What you get.
A full security cycle, not a document: from verified vulnerability to closure.
02
Debrief session
- A review meeting with your team to explain the findings, answer questions and align the action plan.
03
Retest report
- After you apply the fixes, we verify each one, update its status and leave documented evidence of closure, the evidence an auditor wants to see.
04
Certificate of execution
- A document you can hand to auditors, clients or third parties as proof the testing was carried out.
05
Access to the platform
- Transparency and control over every finding from start to finish, with its evidence, status and retest in one place.
Every finding and its closure, audit-ready in one place.
From day one, findings live in our platform, not just in a document: managed, assigned and closed with full traceability, and exportable as audit-ready evidence for your ISO 27001 file.
PLATFORM WALKTHROUGH
We at Etnia highly value our collaboration with Asperis Security.
Frequently asked questions
If something here doesn’t match your situation, that’s the call: bring the edge case and we’ll scope around it.
The ones inside your ISMS scope. Clause 4.3 requires you to determine its boundaries and keep it as documented information. The standard does not require a pentest, but if you run one to support your certification it has to sit inside that scope: the systems, applications and networks supporting the information it covers. Within that, we prioritise what is exposed and what the Annex A technical controls rest on.
We settle the detail in the introductory meeting, and that is where what stays out, and why, gets decided. You define the final scope, and the one in the proposal is the one your auditor sees.
A pentest most directly evidences A.8.8, management of technical vulnerabilities, and A.8.29, security testing in development and acceptance, in the 2022 version of the standard. It also supports the risk-based approach behind Annex A and gives real weight to your Statement of Applicability and risk treatment plan.
Proof that the controls you list there as implemented really are. Clause 6.1.3 d) requires the Statement to set out which controls are necessary and why, and whether each one is implemented or not. For technical controls that is your own assertion; a pentest turns it into evidence with a date, a scope and a result.
So that is where we start: we look at which technical controls you declare implemented inside the scope, and we test those. If one does not hold, you find out before your auditor does, with time to fix it.
The scope sets it, and any timeline we gave you before we knew what was in scope would be made up. The wider the slice of your ISMS scope we have to cover, and the more depth each system needs, the more testing time it takes.
The timeline is confirmed in the proposal, with the testing window, before you sign anything. If you are working towards a certification, surveillance or recertification date, say so in the introductory meeting: we take it into account when we plan, and we tell you there and then whether it fits.
It depends on the scope, which is why there is no rate on this page. What moves the price is how many systems inside your ISMS scope are in, how deeply they are tested, whether there are users and roles to walk through, what type of test it is (black box, grey box or white box) and whether on-site work is needed.
What you can expect is a fixed proposal, with scope, timeline and price, before anybody touches a system. The retest that confirms your fixes, which is the closure evidence an auditor wants to see, is included, at no cost and with no time limit.
You do not have to close them all, but you do need a plan and stick to it. ISO 27001 sets no remediation deadline: A.8.8 asks you to evaluate your exposure and take appropriate measures, and you set the reaction times yourself. What the auditor checks is that you prioritise by risk and keep to what you wrote.
The prioritised report, the debrief action plan and the retest for each closure leave you the evidence for the technical controls that were tested. The rest of the audit (the ISMS, the internal audit and the management review) is not something a pentest covers, and not ours to run.
No. We do not implement the standard, run your management system or issue the certificate, which is awarded by your accredited certification body. We perform the penetration testing aligned with ISO 27001 so that you have the technical validation and evidence that auditors, clients and third parties expect to see. Many clients pair us with their ISMS consultant, and the two roles fit together cleanly.
Yes. We walk you through it on the call, so you can see the level of detail, the clarity of the reporting and the evidence format, and ask about whatever matters to you. We do not email it out on its own.
Ready to give your auditor the evidence they ask for?
An ISO 27001 pentesting engagement is a technical partnership. You define the scope, we run the testing, we provide the evidence your auditor expects. Quick turnaround, clear findings, actionable remediation steps.
Talk with a pentesting expert
Reply within one business day. Senior consultant on the call.
Protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.
Request received.
A senior consultant will reply within one business day.
No se ha podido enviar. Inténtalo otra vez o escríbenos.
Or email [email protected] directly.