How we pentest apps as part of ISO 27001 work

Here is how FM CyberSecurity produces ISO 27001-defensible pentest evidence through Aikido AI Pentest, without booking a manual pentest engagement.

ISO 27001:2022 Annex A control 8.29, “Security testing in development and acceptance,” is what most ISMSs hang their app pentest evidence on. It accepts code review, scanning, and penetration testing as valid methods, and nothing in the standard requires a human in the loop. The auditor wants documented testing, a defined trigger, and an evidence trail.

1. Map your app inventory to the ISMS scope

List which apps sit inside the ISMS scope you wrote in step 1 of our ISO 27001 checklist. Annex A 8.29 only applies to systems the ISMS covers. A 30-person SaaS firm typically has one or two production apps, a customer-facing API, and an internal admin tool in scope.

Write the list on one page: app name, URL or repo, owner, in-scope yes or no. This list becomes the population the auditor samples from when they test 8.29.

2. Set Aikido AI Pentest against the in-scope apps

Connect each in-scope app to Aikido. For a web app, give Aikido the target URL plus test credentials. For an API, point it at the OpenAPI or GraphQL schema so the agents test documented and undocumented endpoints.

Aikido’s agents discover, exploit, and confirm vulnerabilities against the live target before any finding lands in the report. That validation step is what turns scanner output into pentest evidence.

3. Configure cadence: continuous plus pre-release

Annex A 8.29 expects testing during development and at acceptance. Configure Aikido on two triggers: continuous (on every push to main or on a committed schedule) and pre-release (gated against the deploy pipeline so a release blocks on confirmed exploitable findings). Aikido Infinite, launched February 2026, runs the continuous track. Write the cadence into your ISMS testing plan so the policy and the system line up.

4. Collect the evidence trail

Each Aikido run produces an audit-grade PDF report with validated findings, proof of exploit, reproduction steps, and remediation guidance, structured to ISO 27001 expectations. Store the reports where the ISMS document index can point to them: an item per app per quarter.

Keep three fields alongside each report: the run date, the commit or build tested, and the ticket that closed any findings. Those three tie the evidence back to a specific release, which is the thread the auditor follows.

5. Map Aikido output to Annex A 8.29 in your Statement of Applicability

In the SoA, the line for 8.29 names Aikido AI Pentest as the control mechanism, points to the testing plan, and references the evidence folder. One sentence is enough: “Security testing in development and acceptance is delivered through Aikido AI Pentest. Continuous runs on every release, pre-release runs as a deploy gate. Reports retained per the records policy.”

If any in-scope app is developed by a third party, Annex A 8.30 “Outsourced development” also applies. The same Aikido evidence covers 8.30 where you control the test target; the supplier contract carries the obligation where you do not.

6. How the auditor reads it across Stage 1 and Stage 2

At Stage 1 the auditor reads the testing policy, the SoA line, the scope list, and at least one sample report. The pass criterion is that the documentation hangs together: policy names Aikido, scope list matches the SoA, sample report exists.

At Stage 2 the auditor samples the running system, picks two or three apps from your scope list, and asks for the latest report on each. They check the date against your stated cadence and look for a closure record on every high-severity finding. Be ready for one question: “How is this evidence different from a vulnerability scan?” The answer is that Aikido confirms exploitability against the live target before reporting a finding, which is what makes the output count as penetration testing under 8.29 rather than scanning under 8.8. For why this is the only pentest pattern we run, see why Aikido is our only pentest provider.

7. Keep it running after certification

Surveillance audits in years one and two sample the same 8.29 evidence. Keep Aikido running on the same triggers and the reports landing in the same folder structure, and surveillance becomes a matter of pulling the latest sample. When scope changes (new app in, retired app out), update the scope list and Aikido configuration the same week so the two stay aligned.

Next action

Talk to Christian in our assessments practice for an ISO 27001 readiness review on the testing side: a scope-to-Aikido mapping, a draft 8.29 SoA line, and a testing plan you can operate on your own.

FAQ

Does the auditor accept AI pentest as evidence for Annex A 8.29?

Yes, when the output is a validated penetration test report with proof of exploit, not a vulnerability scan. The control names penetration testing as one acceptable method and does not require a human tester. Aikido’s reports include reproduction steps and exploit confirmation for each finding, which is what the auditor reads to decide whether the evidence counts. For the recurring testing obligation under other regimes, see which regulations require recurring pentests.

What about the auditor wanting an annual pentest letter?

Some auditors carry a habit from the 2013 version where the artefact was a once-a-year letter from a pentest firm. The 2022 control text is method-neutral; continuous testing with dated reports per release is a stronger evidence trail than one letter a year. If the auditor still wants a single summary, export an annual roll-up from Aikido covering the year’s runs, findings, and closures.

How does this work for SaaS we did not build?

You cannot run pentests against a vendor’s app without permission, and most contracts forbid it. Annex A 8.29 expects you to confirm the supplier tests their own software, usually by collecting their SOC 2 Type II report or ISO 27001 certificate plus a pentest summary. Run Aikido against the parts you do control: your own apps that integrate with the SaaS, and your tenant configuration where the vendor exposes an API. Annex A 8.30 carries the rest of the obligation through the supplier contract.

What if our app has APIs and not just a UI?

Aikido tests APIs alongside the UI. Point it at your OpenAPI or GraphQL schema and the agents cover documented endpoints, then probe for undocumented ones. The evidence trail and report structure are the same as for a UI app.