ISO 27001 A.8.25: Build security into the development life cycle

What A.8.25 requires in practice

Annex A control A.8.25 asks the organisation to set and apply rules governing how software and systems are developed securely. The emphasis falls on both halves: rules must exist, and they must actually shape the work.

Secure development rules answer practical questions. Where in the life cycle are security needs set? Who reviews design? How are safeguards built in and tested? Who authorises release? The control does not mandate a methodology, so iterative and staged approaches can both qualify provided the relevant decisions occur at suitable points.

The outputs are defined rules for the development life cycle, accountable owners for security decisions at each stage, and records showing how concerns were raised and resolved. The rules need to cover internal development and, where relevant, work carried out by others on the organisation's behalf. As with every Annex A control, applicability is a risk treatment decision recorded in the Statement of Applicability.

Define the decisions the life cycle must include

Identify where the team establishes security needs, reviews design, implements safeguards, tests outcomes and authorises release. The arrangements may be iterative or staged. What matters is that relevant decisions occur at suitable points, with accountable owners and enough evidence to show how concerns were handled.

Use application security requirements to make intended protection explicit and secure engineering principles to guide design choices. A requirement such as restricting customer data to authorised users needs to influence architecture and implementation, not remain an isolated line in a project document.

Fit the rules to the development actually taking place

Include relevant internal scripts, workflow automation and application extensions as well as major software products. A small tool can process important information or hold powerful credentials even when its author does not regard the work as a formal software project.

Scale the process to the risk and complexity. A proportionate approach can provide clear decision points without requiring identical paperwork for every change. Establish when specialist input is needed, what evidence supports acceptance and how the organisation handles a security concern that cannot be resolved before the proposed release.

Why a secure development life cycle matters to the business

Defects that reach production cost far more to fix than those caught early, and security defects can also expose customers. A team that adds security only just before release tends to find problems at the moment when changing course is hardest. Building security into planning, design and acceptance helps product teams ship with fewer surprises and gives sales teams a credible answer to customer questionnaires. It also reduces dependence on individual heroes, since the rules make good practice repeatable. At audit, a working life cycle shows that security is a normal part of delivery rather than an annual clean-up.

How to implement A.8.25

Fit the rules to how your teams actually build, then make them visible at the points where decisions are made. Resist the urge to introduce a heavy process; light, visible decisions at a few well-chosen points are easier to sustain and easier to evidence. Start with one product team and expand once the approach has proved workable.

1. Map the real development flow, whether continuous or staged, and mark where security needs are set, design is reviewed, safeguards are built, testing occurs and release is authorised.
2. Assign an accountable owner for each decision point.
3. Write brief rules for each stage in language developers recognise, linking to application security requirements and secure engineering principles.
4. Decide what evidence each stage leaves behind, such as review notes and test results, and keep it lightweight.
5. Extend the rules to contractors and outsourced developers.
6. Brief teams, using one real project as a worked example.
7. Sample recent releases to confirm the rules were followed, and record exceptions with reasons.
8. Improve the rules based on what the sampling shows.

Illustrative software example: a feature that changes data sharing

Illustrative BPO example: an internal reconciliation script

A hypothetical BPO analyst creates a script to reconcile customer records. It becomes part of the daily process and is later maintained by another employee, but no one has defined ownership, access or testing expectations. The organisation's development rules originally covered only the central IT team's projects.

The business brings the script into an appropriate controlled process, identifies its information and access needs, and establishes review and testing before changes are used operationally. It retains enough documentation for another competent person to maintain it. This demonstrates that practical secure development applies to consequential internal automation without pretending every small script needs the same ceremony as a major platform.

Protect the development environment and build capability

Developers need appropriate skills, trusted resources and protected tools. Source repositories, configuration and credentials require suitable control. Establish rules for the separation of development, testing and production appropriate to the environment, and clarify what information may be used during development.

Where external developers are involved, obtain suitable assurance that they follow the agreed rules. A supplier's own methodology may be acceptable, but the organisation still needs to understand how its security requirements are addressed. Avoid assuming that outsourcing makes secure development irrelevant to the ISMS.

Review evidence across one complete change

Common nonconformities with A.8.25

Findings usually reveal a gap between a written policy and what the teams do. These usually arise where written policy was prepared for audit and never reached the teams, so an auditor follows a real release back through the stated stages to see what happened.

• A development policy that exists but does not match how releases are actually produced.
• Security considered only at the final stage, with no earlier requirement or design review.
• No accountable person for release authorisation on some products.
• Outsourced or contractor development outside the rules.
• Exceptions taken under deadline pressure with no record or follow-up.