ISO 27001 Application Security Checklist: Secure Development
Application security is a cornerstone of the ISO 27001:2022 standard, addressed primarily through Annex A.14 (Security Requirements of Information Systems) and reinforced by controls in Annex A.8 (Asset Management), A.9 (Access Control), and A.12 (Operations Security). This ISO 27001 application security checklist maps every stage of the secure development lifecycle (SDLC) to the specific Annex A controls you must implement, the evidence auditors will request, and the technical practices that demonstrably reduce application risk.
Annex A.14 Requirements for Application Security
Annex A.14 contains three control objectives that directly govern application security. Each objective comprises specific controls that are examined during certification and surveillance audits.
| Control ID | Control Name | Requirements |
|---|---|---|
| A.14.1.1 | Information security requirements analysis and specification | Information security requirements must be integrated into the requirements phase for all new information systems and enhancements to existing systems |
| A.14.1.2 | Securing application services on public networks | Applications deployed over public networks must incorporate encryption, authentication, and protection against data leakage |
| A.14.1.3 | Protecting application services transactions | Transaction data must be protected against incomplete transmission, mis-routing, unauthorised message alteration, and duplication |
| A.14.2.1 | Secure development policy | Rules for the development of software and systems must be established and applied to all development activities |
| A.14.2.2 | System change control procedures | Changes to systems within the development lifecycle must be controlled through formal change control procedures |
| A.14.2.3 | Technical review of applications after operating platform changes | When operating platforms change, critical business applications must be reviewed and tested for adverse impact |
| A.14.2.4 | Restrictions on changes to software packages | Modifications to software packages must be discouraged, limited to necessary changes, and strictly controlled |
| A.14.2.5 | Secure system engineering principles | Principles for engineering secure systems must be established, documented, maintained, and applied |
| A.14.2.6 | Secure development environment | Organisations must establish and secure development environments for system development and integration efforts |
| A.14.2.7 | Outsourced development | Outsourced system development must be supervised, monitored, and subject to the same security requirements as in-house development |
| A.14.2.8 | System security testing | Security testing must be carried out during development, including regression testing, penetration testing, and vulnerability scanning |
| A.14.2.9 | System acceptance testing | Acceptance testing programmes must include security-related criteria and be completed before system go-live |
Secure Coding Standards
ISO 27001 does not mandate a specific secure coding standard, but your ISMS must define one and demonstrate that developers follow it. Most organisations adopt OWASP Application Security Verification Standard (ASVS), CERT Secure Coding, or a custom standard derived from these sources. Your secure coding standard should address the following domains.
- Input validation: Validate all input from untrusted sources against allow-lists. SQL injection, cross-site scripting (XSS), and command injection vulnerabilities arise from weak input validation. Implement parameterised queries (for SQL) and context-aware output encoding (for XSS).
- Authentication: Enforce multi-factor authentication (MFA) for privileged access. Use OAuth 2.0 or SAML for federated authentication. Store password hashes using bcrypt, Argon2, or PBKDF2. Never store plaintext or unsalted hashes.
- Authorisation: Implement role-based access control (RBAC) or attribute-based access control (ABAC). Verify authorisation at every layer – API gateway, service layer, and data layer. Avoid relying solely on client-side access controls.
- Cryptography: Use approved cryptographic algorithms (AES-256, RSA-2048, SHA-256). Manage cryptographic keys through a centralised key management system (KMS). Rotate keys annually or when personnel with key access leave the organisation.
- Session management: Generate session identifiers using cryptographically secure random number generators. Set session timeouts (15–30 minutes of inactivity for high-risk applications). Regenerate session IDs after login and privilege escalation.
- Error handling: Display generic error messages to end users. Log detailed error information securely for operational teams. Never expose stack traces, database schemas, or internal server paths in production responses.
Code Review and Vulnerability Scanning
Code review and vulnerability scanning are mandatory controls under A.14.2.8 (System security testing). Your ISMS must document the frequency, scope, and methodology for both activities.
| Activity | Frequency | Tools / Methods | Evidence Required |
|---|---|---|---|
| Peer code review | Every pull request / merge request | GitLab merge request reviews, GitHub pull request reviews, Checkstyle, SonarQube | Review comments, approval records, resolved findings |
| Static application security testing (SAST) | Every commit (pre-commit hooks) and nightly full scan | SonarQube, Checkmarx, Veracode, Semgrep, Snyk Code | SAST report, finding remediation logs, pass/fail thresholds |
| Software composition analysis (SCA) | Every build (CI/CD pipeline) | Snyk, Dependabot, Trivy, OWASP Dependency-Check | SCA report, dependency licence compliance, CVE remediation records |
| Dynamic application security testing (DAST) | Quarterly and before major releases | Burp Suite, OWASP ZAP, Acunetix, Netsparker | DAST report, confirmed vulnerabilities, retest results |
| Penetration testing | Annually and after significant architectural changes | External penetration testing firm (CREST or equivalent certified) | Penetration test report, remediation plan, retest confirmation |
Dependency and Supply Chain Security
Modern applications rely heavily on open-source dependencies, third-party libraries, and API services. Annex A.15 (Supplier Relationships) and A.14.2.6 (Secure development environment) require organisations to manage supply chain risk throughout the software lifecycle.
- Maintain a software bill of materials (SBOM) for every application, listing all direct and transitive dependencies.
- Automate dependency scanning in the CI/CD pipeline using SCA tools. Configure builds to fail on critical or high-severity vulnerabilities.
- Establish a vulnerability management SLA: critical CVEs remediated within 48 hours, high-severity within 7 days, medium within 30 days.
- Verify the integrity of downloaded packages using checksum validation and repository signing (npm audit, NuGet signature verification, Maven GPG signing).
- Review and approve each dependency’s licence terms (GPL, AGPL, MIT, Apache) against your organisation’s legal policy.
- Remove unused dependencies and deprecated libraries. Each unnecessary dependency increases the attack surface.
API Security and Authentication
Application programming interfaces (APIs) are a primary attack vector. ISO 27001 requires specific controls for API security under A.14.1.2 and A.14.1.3, particularly when applications are accessible over public networks. Every API must implement authentication, authorisation, rate limiting, payload validation, and logging. Use API gateways to centralise security policies including token validation, IP allow-listing, request throttling, and TLS termination. Document every API endpoint with its security classification, authentication method, and data sensitivity level. Conduct API-specific penetration testing at least annually, covering OWASP API Security Top 10 risks.
Deployment Security
Secure deployment is the final gate before your application reaches production. Your deployment pipeline must satisfy multiple Annex A controls, including A.12.6.1 (Management of technical vulnerabilities), A.14.2.2 (System change control procedures), and A.14.2.9 (System acceptance testing).
| Checklist Item | Control Reference | Verification Method |
|---|---|---|
| Infrastructure as code (IaC) scanned for misconfiguration | A.12.6.1 | Terrascan, Checkov, tfsec scan passed as pipeline gate |
| Secrets (passwords, keys, tokens) not stored in code repositories | A.9.4.3 | Secret scanning tool (GitLeaks, TruffleHog) passes pre-commit |
| Container images scanned for vulnerabilities | A.12.6.1 | Image scan report with zero critical vulnerabilities |
| Approved release authority recorded | A.14.2.2 | Change request ticket approved, CAB minutes logged |
| Database migrations reviewed and tested | A.14.2.9 | Migration script reviewed, rollback script tested, backup verified |
| Production access restricted to authorised deployers | A.9.2.5 | Privileged access reviews, just-in-time (JIT) access enabled |
Frequently Asked Questions
What is the ISO 27001 application security checklist?
The ISO 27001 application security checklist is a structured set of requirements drawn from Annex A controls (primarily A.14) that ensures applications are designed, developed, tested, and deployed with appropriate security controls throughout the software development lifecycle.
Which Annex A controls cover application security?
The primary controls are found in Annex A.14 (Security Requirements of Information Systems), which includes 12 controls covering secure development policy, system change control, secure engineering principles, secure development environments, outsourced development, system security testing, and acceptance testing. Supplementary controls include A.9 (Access Control), A.8 (Asset Management), and A.12 (Operations Security).
Do I need penetration testing for ISO 27001 compliance?
Yes. Penetration testing is a requirement under A.14.2.8 (System security testing). Your ISMS must define the frequency (typically annual) and scope of penetration testing. Testing must be conducted by a qualified party, ideally independent of the development team. CREST or equivalent certification is strongly recommended for penetration test providers.
How do I demonstrate secure development to an auditor?
Provide evidence of your secure development policy, coding standards, code review records, SAST/DAST reports, dependency scanning results, vulnerability remediation logs, and acceptance test records. The auditor will look for consistent application of security controls across the SDLC, not just documentation.
Does ISO 27001 apply to legacy applications?
Yes. Annex A.14 requirements apply to all information systems, including legacy applications. For legacy systems that cannot be easily modified, compensating controls must be implemented (e.g. web application firewall, network segmentation, additional monitoring). The risk treatment plan should document why full compliance is not feasible and how compensating controls reduce risk to an acceptable level.
What is the difference between SAST, DAST, and SCA?
SAST (Static Application Security Testing) analyses source code for security vulnerabilities without executing the application. DAST (Dynamic Application Security Testing) tests the running application for vulnerabilities through simulated attacks. SCA (Software Composition Analysis) scans open-source dependencies for known vulnerabilities and licence compliance issues. ISO 27001 requires all three as part of a comprehensive security testing programme.
Strengthen your application security posture for ISO 27001. Bitrixme’s DevSecOps consultants help you implement secure SDLC controls, select testing tools, and prepare audit evidence. Schedule a consultation to align your development pipeline with ISO 27001 requirements.
