Secure development under ISO 27001: the controls that follow your code to production.

The 2022 edition groups these controls in the technological theme. Each one is short in the standard; the work is deciding what each means for your stack. The names below are the public Annex A titles. What follows each is our own description of the purpose.

8.25 Secure development life cycle

Security has a defined place in every phase of how you build, from idea to release.

8.26 Application security requirements

Security needs are written down for an application before it is built or bought.

8.27 Secure system architecture and engineering principles

Agreed design principles that new systems are measured against.

8.28 Secure coding

Coding practices that avoid known classes of flaw, applied and checked.

8.29 Security testing in development and acceptance

Security is tested before release, against the requirements set earlier.

8.30 Outsourced development

Code written by others is directed, monitored and reviewed as if it were yours.

8.31 Separation of development, test and production environments

Environments are kept apart so a mistake in one cannot spill into another.

8.33 Test information

Data used for testing is chosen and protected, and real personal data is handled with care.

8.32 Change management sits in the middle of this run. It has its own guide because it reaches beyond code into infrastructure and configuration.

Notice that most evidence comes from tools you already run. A team that uses pull requests and a build pipeline is producing the records; the gap is usually that nobody has written down that these steps are the control, so they drift.

1. Draw your current path from ticket to production, as it really runs.
2. Mark the points where a security decision is made or should be made.
3. For each point, name the owner, the check and the record it leaves.
4. Decide which changes are big enough to need a design review or threat model, and say how you tell.
5. Write it in a page or two, and reference it from your secure development policy.

• Contract terms for vendors. Secure coding expectations, ownership of code, right to review, and how defects are handled.
• Review on delivery. Vendor code goes through the same pull request and scan path as your own.
• Vendor access. Contractors reach only the repositories and environments they need, and lose access when work ends.
• Test data rules. Live personal data is not used for testing unless approved, protected like production, and deleted after.
• Lower-environment hygiene. Secrets and keys in test and development are not the production ones.

• A database copy for debugging. A full production snapshot restored to a laptop or a test account is the classic finding under 8.33.
• Shared admin across environments. If one role can change development and production alike, separation under 8.31 is only on paper.
• Scans that nobody reads. A tool that runs but whose results are never triaged does not show testing under 8.29.

• Show me your secure development policy and where the life cycle is described.
• Pick three merged changes from last quarter: who reviewed them, and what checks ran?
• How do you decide when a change needs a design or threat review?
• Who can deploy to production, and how is that limited?
• Where does test data come from, and has live data been used?
• For code a contractor wrote, show the review and acceptance.

Sources: ISO/IEC 27001:2022 Annex A control titles 8.25 to 8.33 (public titles only; the standard's text is not reproduced); OWASP Software Assurance Maturity Model (SAMM); NIST SP 800-218, Secure Software Development Framework (SSDF).