What ISO 27001 Auditors Actually Want From Your Penetration Test

Plenty of companies walk into their ISO 27001 audit with a penetration test report in hand and still get stuck. The test was done. The report runs to 60 pages. Yet the auditor keeps asking questions the report does not answer: how the scope was chosen, how the findings tie back to the risk register, and whether the serious issues were ever fixed.

The problem is rarely the quality of the testing. It is the gap between the test and the rest of the information security management system (ISMS). A pen test that sits on its own, disconnected from your risks and controls, is weak evidence no matter how skilled the testers were.

This article walks through what auditors actually look for, how to scope a test that holds up, and what to do once the report lands on your desk.

Where penetration testing fits in ISO 27001

ISO 27001 does not contain a line that says "you must run a penetration test every year." That surprises people. What the standard does require is that you manage technical vulnerabilities and check that your security controls work as intended.

In the 2022 version of Annex A, two controls carry most of that weight. A.8.8, Management of technical vulnerabilities, asks you to find weaknesses in your systems, judge your exposure, and act on them in good time. A.8.29, Security testing in development and acceptance, asks you to test that new or changed systems meet their security requirements before they go live. If your certificate was issued under the 2013 version, you may know these as A.12.6.1 and A.14.2.8.

You could, in theory, meet these controls with scanning and internal reviews alone. In practice, most auditors expect an independent, hands-on test for anything facing the internet or holding sensitive data. A scanner can tell you a library is out of date. It cannot tell you that a normal user can change one number in a request and read another customer's invoices. That second kind of finding is what auditors want to see you looking for, which is why many companies bring in ISO 27001 penetration testing services instead of relying on scan reports alone.

Five things auditors check in a pen test report

Auditors are not security testers, and they will not rerun your test. They read the report as evidence. Here is what they tend to look for.

1. A scope that matches your ISMS. If your Statement of Applicability covers a customer platform, three APIs and an AWS account, the test should cover them too. A test of the marketing website alone does not show much about the systems that hold customer data.
2. Clear dates and an independent tester. The report should show when testing happened and who did it. Testers should be independent from the team that built and runs the systems.
3. Findings rated by risk. Each issue needs a severity rating and a short explanation of what an attacker could do with it. This lets you feed findings straight into your risk assessment.
4. Mapping to Annex A controls. This is the part many reports skip. When a broken access control finding is linked to controls such as A.5.15 and A.8.3, the auditor can see which control failed and where to look in your ISMS.
5. Proof of follow-up. A report full of open critical issues is not good evidence. A retest showing those issues closed is.

The fourth and fifth points are where generic pen tests usually fall short. A standard report can be technically excellent and still leave your compliance team to translate every finding into control language by hand. That is why it pays to pick a testing partner that maps findings to Annex A and includes retesting from the start. The auditor gets evidence in the format they expect, and your team skips weeks of rework.

How to scope the test so it holds up

Scoping is where most of the value is won or lost. A few habits make a big difference.

• Start from your risk register, not a price list. Look at the assets your risk assessment rates as high impact. Those belong in scope first. If budget is tight, it is better to test your core application deeply than to test ten minor systems lightly.
• Test as real users. Ask for authenticated testing across each user role. Many of the worst issues, like one tenant seeing another tenant's data, only show up once the tester is logged in.
• Include what sits around the app. APIs, cloud configuration, and the network behind your product are often weaker than the app itself. A misconfigured storage bucket or an exposed admin port can undo a well-built front end.
• Write down what is out of scope, and why. Auditors accept exclusions when they are reasoned. A note such as "legacy billing system excluded, scheduled for shutdown in Q2, compensating controls in place" is fine. A silent gap is not.
• Time it with your audit cycle. Testing three to four months before the audit leaves room to fix issues and retest. Testing the week before leaves you explaining open findings.

After the report: closing the loop

The report is the start of the work, not the end. What you do next is what the auditor really judges.

1. First, log every finding in your risk register or issue tracker with an owner and a due date. Set fix times by severity, for example critical issues within days and low ones within the next release cycle. Whatever targets you choose, write them into your vulnerability management procedure and stick to them.
2. Second, decide openly on anything you will not fix. Sometimes accepting a low risk is the right call. Record who accepted it and why. That record is valid evidence. A finding that was quietly ignored is a nonconformity waiting to happen.
3. Third, retest. Ask the testing team to confirm each fix and issue an updated report. This closes the loop between A.8.8 and your corrective action process, and it gives the auditor one clean document to review.
4. Finally, feed the lessons back. If several findings came from the same root cause, such as missing input validation, update your secure coding guidance and developer training. Auditors like to see the ISMS learn from a test, not just patch it.