Fixing a security flaw in production costs far more than avoiding it in design. ISO 27001 secure development controls build security into the way you buy, build and change systems, from the first requirement to the final release.
In the 2013 edition, this area was Annex A.14 “System acquisition, development and maintenance”, with 13 controls. The 2022 edition reorganised it into a set of technological controls and added a new one for secure coding. This guide explains each and how development teams can meet them without slowing down.
Mapping: A.14 (2013) to ISO 27001:2022
| ISO 27001:2013 | ISO 27001:2022 |
|---|---|
| A.14.1.1 Security requirements analysis | 5.8 Information security in project management |
| A.14.1.2, A.14.1.3 Securing and protecting application services | 8.26 Application security requirements |
| A.14.2.1 Secure development policy | 8.25 Secure development life cycle |
| A.14.2.2 to A.14.2.4 Change control and reviews | 8.32 Change management |
| A.14.2.5 Secure system engineering principles | 8.27 Secure system architecture and engineering principles |
| A.14.2.6 Secure development environment | 8.31 Separation of development, test and production environments |
| A.14.2.7 Outsourced development | 8.30 Outsourced development |
| A.14.2.8, A.14.2.9 Security and acceptance testing | 8.29 Security testing in development and acceptance |
| A.14.3.1 Protection of test data | 8.33 Test information |
| New in 2022 | 8.28 Secure coding |
Planning: requirements and architecture
5.8 and 8.26 Security requirements
Define security requirements before you build or buy. For example, list authentication, authorization, logging, encryption and privacy needs. For web applications and APIs, the OWASP Application Security Verification Standard (ASVS) is a useful checklist. When you buy software or SaaS, add these requirements to the vendor evaluation.
8.27 Secure architecture
Next, apply secure design principles, such as defence in depth, least privilege, secure defaults and zero trust. In addition, run threat modelling for new systems and major changes. Simple methods like STRIDE work well in a one-hour workshop.
Building: the secure SDLC
8.25 Secure development life cycle
Write down how security fits into each stage of development. A practical secure SDLC includes:
- security requirements in user stories;
- threat modelling for significant features;
- secure coding standards and training;
- peer code review;
- automated security testing in the CI/CD pipeline;
- a security sign-off before release.
8.28 Secure coding (new)
This new control expects developers to follow secure coding practices. In practice, that means:
- validating all input and encoding output;
- using parameterised queries to prevent SQL injection;
- never hard-coding secrets;
- keeping third-party libraries up to date;
- using static analysis (SAST) and dependency scanning (SCA).
The OWASP Top 10 is a good starting point for developer training.
8.31 Separate environments
Keep development, test and production apart, with different access rights. As a result, a mistake in testing cannot damage live data.
Testing and release
8.29 Security testing
Test security before release. Combine automated scans (SAST, DAST, SCA) with manual testing, such as penetration tests for high-risk applications. Then fix findings based on risk, and record accepted risks.
8.33 Test information
Avoid using real personal data in test environments. Instead, use synthetic data or masked copies (see control 8.11 Data masking). If real data is unavoidable, protect it like production data and delete it after testing.
8.32 Change management
Every change to production should be recorded, reviewed, tested and approved. In a DevOps pipeline, these steps can be automated, for example through pull-request approvals and pipeline gates.
8.30 Outsourced development
If a vendor builds software for you, you remain accountable. Therefore, include security requirements, code ownership, testing rights and vulnerability disclosure in the contract. Also, review the vendor’s secure development practices and test what they deliver.
What auditors check
- A secure development policy or SDLC document.
- Evidence of code reviews and security testing for recent releases.
- Pipeline settings, such as branch protection and required checks.
- Test data handling rules.
- Contracts with outsourced developers.
FAQ
Does ISO 27001 apply if we only buy software?
Yes. Controls 5.8 and 8.26 cover security requirements when you acquire systems, including SaaS.
Do we need penetration testing for ISO 27001?
It is not mandatory by name. However, control 8.29 expects security testing, and pentests are common evidence for critical systems.
Related guides
- ISO 27001:2022 Annex A: all 93 controls and the 2013 mapping
- Free ISO 27001:2022 readiness checklist
- What is an ISMS? Concept, benefits and the PDCA cycle
Sources
- ISO/IEC 27001:2022, Information security management systems (ISO)
- ISO/IEC 27002:2022, Information security controls (ISO)
Preparing for an ISO 27001 or IT audit? Our ISO 27001 readiness assessment finds your gaps before the auditor does. Doing it yourself? The ISO 27001:2022 Starter Kit (₹1,999) gives you the gap workbook, risk register, Statement of Applicability and 13 policy templates. You can also start with our free ISO 27001:2022 readiness checklist, or contact us for a quote.
