ISO 27001 testing requirements
ISO/IEC 27001:2022 is the international standard for information security management systems, and an organisation of any size can be certified to it. ISO 27001 testing verifies Annex A controls such as 8.8 technical vulnerabilities and 8.25 to 8.33 development and testing. FintechAssuranceLabs produces penetration test reports, a requirement-to-test traceability matrix, and retest evidence for the certification audit.
- Jurisdiction
- Global (certification by accredited certification bodies)
- Primary source
- iso.org
Engineering interpretation of testing requirements, not compliance advice.
What ISO/IEC 27001:2022 requires
ISO and IEC published ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements, on 25 October 2022. The ISO/IEC 27001:2022 standard page (ISO, checked on 2026-09-16) lists edition 3 and one amendment, Amendment 1:2024 on climate action changes. The IAF MD 26:2023 transition requirements (IAF, issued 15 February 2023, checked on 2026-09-16) ended the transition on 31 October 2025, and every certificate to ISO/IEC 27001:2013 expired or was withdrawn at that date.
Clauses 4 to 10 are mandatory for certification. The clauses that decide test scope are:
- 6.1.2 and 8.2, risk assessment. The organisation assesses information security risks at planned intervals, and when significant changes are proposed or occur. A new payment rail, a new banking partner, or a new mobile app is a significant change.
- 6.1.3, risk treatment. The organisation compares its selected controls with Annex A (6.1.3 c) and produces a Statement of Applicability (SoA) that justifies each included and excluded control (6.1.3 d).
- 6.3, planning for changes. Changes to the ISMS are carried out in a planned manner.
- 9.1, 9.2, and 9.3, performance evaluation. Documented information is kept as evidence of monitoring results, the internal audit programme and results (9.2.2), and management review results (9.3.3).
- 10.2, nonconformity and corrective action. Each nonconformity gets a correction, a cause analysis, and a record of the result.
Annex A is normative and lists 93 controls in four themes: organizational controls 5.1 to 5.37, people controls 6.1 to 6.8, physical controls 7.1 to 7.14, and technological controls 8.1 to 8.34. ISO/IEC 27002:2022 gives implementation guidance for each control, and certification audits run against ISO/IEC 27001. For a fintech product team, most of the test scope sits in these Annex A controls:
- 8.8 Management of technical vulnerabilities. Vulnerabilities in systems in use are identified, exposure is evaluated, and measures are taken.
- 8.25 Secure development life cycle, 8.26 Application security requirements, and 8.28 Secure coding. Secure development rules are set and applied, security requirements are identified and approved for each application, and secure coding principles apply to all code.
- 8.29 Security testing in development and acceptance. Security testing processes are defined and run in the development life cycle, including acceptance before release.
- 8.30 Outsourced development. The organisation directs, monitors, and reviews development work done by suppliers.
- 8.31 Separation of development, test and production environments. Environments are separated and secured.
- 8.32 Change management. Changes to systems follow change management procedures.
- 8.33 Test information and 8.11 Data masking. Test information is selected, protected, and managed. Data masking follows the access control policy and business requirements, which matters when personal data or account data reaches a test environment.
- 5.15 Access control, 8.2 Privileged access rights, 8.3 Information access restriction, and 8.5 Secure authentication. Access follows business need and uses secure authentication.
ISO 27001 controls that testing verifies
| Requirement | What we test | Evidence produced |
|---|---|---|
| 8.29 Security testing in development and acceptance | Security test stage in the release pipeline, and acceptance tests against the security requirements of each release | Security test plan and test results per release, with the acceptance decision |
| 8.26 Application security requirements | Authorisation, input validation, and transaction integrity on payment, payout, and account APIs | Requirement-to-test traceability matrix |
| 8.8 Management of technical vulnerabilities | Web, API, and mobile applications inside the ISMS scope | Penetration test report with severity and reproduction steps per finding |
| 5.15, 8.2, and 8.3 Access control and privileged access | Each role against the data and actions that the role needs, including support and admin roles | Access control and authorisation test matrix |
| 8.5 Secure authentication | Login, session expiry, password reset, and step-up authentication for high-risk actions | Authentication test cases with request and response captures |
| 8.31 Separation of environments | Network paths, shared credentials, and shared API keys between test and production | Environment separation test result with test date and scope |
| 8.33 Test information and 8.11 Data masking | Test data stores for unmasked personal data and account data copied from production | Search queries and results per test data store |
| 8.32 Change management | Regression and security retests for each change to production systems | Regression results linked to the change ticket |
| 8.13 Information backup and 8.14 Redundancy | Restore from backup and failover of the ledger and payment services | Restore and failover test record with recovery times measured in the test |
| 10.2 Nonconformity and corrective action | Each security finding after the development team deploys a fix | Retest result linked to the original finding |
Artifacts an ISO 27001 certification auditor requests
For the software and testing controls, an auditor from the certification body typically requests:
- the ISMS scope, including the products, environments, and locations in scope;
- the Statement of Applicability with the justification for each included and excluded Annex A control (6.1.3 d);
- risk assessment results and the risk treatment plan (6.1.2, 6.1.3, 8.2, 8.3);
- the secure development policy and the security requirements for applications in scope (8.25, 8.26);
- security test plans, test results, and acceptance records for recent releases (8.29);
- penetration test reports, vulnerability scan results, and remediation records with retest dates (8.8);
- the environment architecture and records of approval for any copy of production data into a test environment (8.31, 8.33);
- change tickets with linked regression and security test results (8.32);
- supplier agreements and review records for outsourced development and testing (5.19, 5.20, 8.30);
- the internal audit programme and results, and management review results (9.2.2, 9.3.3);
- the list of nonconformities with corrective actions and their results (10.2).
IAF MD 26:2023 states that a transition audit does not rely only on document review, especially for technological controls. Test results with dates, scope, and retest records answer that expectation for controls 8.8 and 8.29.
Common ISO 27001 findings in fintech products
- SoA claims a security test stage that does not exist. The SoA marks 8.29 as implemented, but the payment API release pipeline has no security test step and no acceptance record. The gap breaks 8.29 and the accuracy of the SoA under 6.1.3 d.
- Production snapshot in staging. A team restores a production database with customer names, IBANs, and card numbers into staging to reproduce a payout defect, with no masking and no approval. The defect breaks 8.33 and 8.11.
- Staging calls live payment rails. A staging service uses the production payment provider API key, and a test run creates real payouts. The defect breaks 8.31.
- Support role reads any customer account. An internal API checks that the caller is logged in and does not check that the account belongs to the case. The defect breaks 5.15 and 8.3.
- Penetration test scope older than the architecture. A new open banking connector and a new mobile app went live after the last penetration test, and the risk assessment was not updated. The gap breaks 8.8 and the significant change condition of 8.2.
- Finding closed without a retest. A high-severity finding moves to "done" after a fix, with no repeated test and no record of the result. The gap breaks 8.8 and 10.2.
- Hotfix outside change management. An engineer deploys a fee calculation fix directly to production, with no ticket and no regression run. The gap breaks 8.32.
- Supplier code without test evidence. An outsourced team delivers a card onboarding module, and the organisation holds no security test results for the module. The gap breaks 8.30.
How we cover ISO 27001 testing
The security testing service delivers the web, API, and mobile penetration test report, findings with severity, reproduction steps, and retest results, and the access control and authorisation test matrix. These deliverables are evidence for 8.8, 8.29, 5.15, 8.3, and 8.5. Penetration tests and automated scans produce different evidence for 8.8; the comparison of penetration testing and vulnerability scanning explains the split.
The audit evidence testing service builds a requirement-to-test traceability matrix from the SoA, a test evidence pack per audit scope, a gap report before the certification or surveillance audit, and retest evidence after remediation for 10.2. The certification body decides on conformity; the evidence pack gives the auditor dated test results mapped to each Annex A control.
The operational resilience testing service delivers resilience test scenarios for critical services, failover and recovery time results, and third-party provider outage simulations. These results are evidence for 8.13 and 8.14. Teams that also report under SOC 2 reuse much of the same evidence; the SOC 2 and ISO 27001 comparison sets out where the two differ.
We test ISO 27001 controls for Banking-as-a-Service and card issuing platforms, open banking and data aggregation providers, payment acquiring, neobank, business banking, and KYC/AML products. In vendor due diligence, partner banks and enterprise buyers check the scope stated on an ISO/IEC 27001 certificate, because the certificate covers only that scope.
FintechAssuranceLabs holds ISO 27001 certification, verified via SGS Spain and valid until 2030.
Related
Segments
- Banking-as-a-Service and card issuing
- Open banking and data aggregation
- Payment acquiring
- Neobanks and digital banking
- Business banking
- Spend management and corporate cards
- Crypto exchanges and wallets
- KYC/AML and anti-fraud
- Accounting and invoicing
- AP/AR automation and treasury
- Subscription billing and revenue management
- Cap table and equity management
- Cashback and rewards
- Chargeback management
- Debt collection and loan management software
- Crypto tax and portfolio trackers
- Expense reporting
- Tax software
- Trading terminals and analytics
Questions
Does ISO 27001 require penetration testing?
Does ISO 27001 require vulnerability scanning?
What is ISO 27001 compliance?
What is ISO 27001 penetration testing?
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing