ISO/IEC 27001:2022 Compliance
ISO/IEC 27001:2022 is the international standard for an information security management system.
Learn how ImmuniWeb helps you evidence its Annex A application-security controls.
ISO 27001 Compliance
What Is ISO/IEC 27001?
ISO/IEC 27001 specifies how to establish, implement, maintain and continually improve an ISMS. Its main clauses (4-10) cover organizational context, leadership, planning, support, operation, performance evaluation and improvement, driven by risk assessment and treatment.
Annex A provides a catalogue of controls that organizations select via a Statement of Applicability. The 2022 edition reorganized these into 93 controls across four themes, including a modern set of technological controls covering secure development and vulnerability management. Certification is achieved through an external audit.
See how ImmuniWeb helps you evidence ISO 27001 Annex A controls A.8.25 - A.8.29 and A.8.8- secure development and security testing of your applications. Request a demo· or run a free Community Edition test.
Who Must Comply with ISO 27001?
ISO/IEC 27001 is voluntary but widely expected:
- Organizations seeking certification to demonstrate information security maturity.
- Suppliers and vendors required by enterprise customers or tenders to be certified.
- Any sector and size - the standard is technology- and industry-neutral.
Where the ISMS scope includes software development or internet-facing applications, the Annex A application-security controls apply.
Key ISO 27001 Controls for Application Security
Several Annex A (2022) controls drive application-security work:
- A.8.25 - Secure development life cycle: establish and apply rules for the secure development of software and systems.
- A.8.26 - Application security requirements: identify and apply security requirements when developing or acquiring applications.
- A.8.28 - Secure coding: apply secure coding principles to software development.
- A.8.29 - Security testing in development and acceptance: define and perform security testing across the development life cycle.
- A.8.8 - Management of technical vulnerabilities: obtain information about and address technical vulnerabilities in a timely way.
ISO 27001 Application-Security Controls in Depth
A.8.29 - Security Testing in Development and Acceptance
This control expects security testing to be defined and performed during development and before acceptance. Penetration testing and vulnerability scanning of web and mobile applications provide exactly this evidence, and re-testing after changes shows the control operates over time.
A.8.8 - Management of Technical Vulnerabilities
A.8.8 requires organizations to identify technical vulnerabilities, evaluate exposure and take appropriate action. Regular vulnerability scanning and attack-surface management feed this control directly.
A.8.25 & A.8.28 - Secure Development and Coding
Embedding security into the development life cycle and applying secure coding principles are best evidenced by testing in CI/CD - shifting security left so applications stay secure release after release.
Common Web & Mobile Application Risks to Address
The application risks these Annex A controls aim to prevent map closely to the OWASP Top 10:
- Broken Access Control — users reaching data or actions they should not.
- Cryptographic Failures — weak or missing encryption exposing sensitive data.
- Injection — SQL, command or other injection via unvalidated input.
- Insecure Design — missing security controls by design, not just by bug.
- Security Misconfiguration — default, incomplete or unsafe configuration.
- Vulnerable & Outdated Components — unpatched libraries and frameworks.
- Identification & Authentication Failures —weak login, session or credential handling.
- Software & Data Integrity Failures — untrusted updates, insecure CI/CD pipelines.
- Security Logging & Monitoring Failures — attacks going undetected.
- Server-Side Request Forgery (SSRF) — the server tricked into making malicious requests.
For mobile apps, the OWASP Mobile Top 10 is the equivalent reference (insecure data storage, insecure communication, weak cryptography, and so on). Reliably finding these issues requires testing the running application, not just a documentation review.
How to Evidence ISO 27001 Application Controls with ImmuniWeb
- Define scope.Map in-scope applications and assets with ImmuniWeb Discovery.
- Test in development & acceptance (A.8.29) with On-Demand and Neuron.
- Manage vulnerabilities (A.8.8) with Neuron scanning and Discovery attack-surface management.
- Secure the SDLC (A.8.25 / A.8.28) with Continuous in CI/CD.
- Remediate and retest with clear, zero-false-positive reports as audit evidence.
- Maintain evidence with periodic re-testing between surveillance audits.
How ImmuniWeb Helps You Achieve ISO 27001 Compliance
ImmuniWeb provides the testing that evidences ISO 27001's application-security controls for your auditor.
| Requirement | What it requires | ImmuniWeb products |
|---|---|---|
| A.8.29 | Security testing in development and acceptance. | On-Demand, Neuron, Continuous |
| A.8.8 | Management of technical vulnerabilities. | Neuron, Discovery, On-Demand |
| A.8.25 / A.8.26 / A.8.28 | Secure development life cycle, requirements and coding. | Continuous, On-Demand |
ImmuniWeb On-Demand delivers manual web application penetration testing; Neuron and Neuron Mobile provide automated scanning; MobileSuite covers mobile apps; Continuous embeds testing into CI/CD; and Discovery maps your attack surface - together producing audit-ready evidence for Annex A.
ISO 27001 vs International Frameworks
If you already work to international standards, the same ImmuniWeb testing supports all of them:
| Framework | Application-security angle | How ImmuniWeb maps |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A technical controls (A.8.x) | Web/mobile pentest, scanning, ASM as control evidence |
| SOC 2 | Security trust services criteria | Testing as control evidence |
| NIST CSF 2.0 | Protect / Detect functions | Application testing & monitoring |
| PCI DSS 4.0.1 | Req 6 & Req 11 | Web app pentest + scanning |
Penetration Testing vs Security Scanning
Both are needed. Automated scanning (DAST) gives broad, frequent coverage and is ideal for continuous testing in CI/CD; manual penetration testing finds business-logic and complex vulnerabilities that scanners miss and produces the depth auditors and regulators expect. Combine continuous scanning with periodic manual penetration testing, and re-test after significant changes.
Compliance Checklist (Application Security)
- In-scope applications and assets inventoried
- Security testing defined and performed in development/acceptance (A.8.29)
- Technical vulnerabilities managed and remediated (A.8.8)
- Secure development life cycle and coding applied (A.8.25 / A.8.28)
- Findings remediated and re-tested; evidence retained
- Re-testing maintained between surveillance audits
- Statement of Applicability reflects the controls in use
Why ISO 27001 Compliance Matters
ISO/IEC 27001 certification is frequently a precondition for enterprise contracts, tenders and partnerships, and signals a mature security posture to customers and regulators. Auditors expect demonstrable evidence that controls operate, not just policies.
Application-security controls are among the most scrutinised in modern audits, so regular testing of web and mobile applications is one of the clearest ways to evidence Annex A and pass surveillance audits.