How to create an ISO 27001 secure development policy – with template

Organisations that implement ISO 27001 and develop software and systems internally must write a secure development policy.

The requirements for doing this are outlined in Annex A.14 of the Standard: System acquisition, development and maintenance.

In this blog, we explain how you can use ISO 27001 and ISO 27002 to create your policy, and take a look at some of the controls you should implement.

What is a secure development policy?

A secure development policy is a set of rules that help organisations mitigate the risk of security vulnerabilities in development environments – i.e. the virtual workspaces where organisations make changes to software and web applications without affecting the live product or page.

To fully appreciate the policy’s importance, we must first explain its place within Annex A.14 of ISO 27001.

A.14 focuses on the security requirements of development and support processes, and covers issues such as system change control procedures, outsourced development and system security testing.

However, your approach to many of these will be framed around the secure development policy, which is covered in control A.14.2.1.

The policy should include guidance on how to manage developers, code securely and follow effective development practices.

It should also provide specific information on the ways security must be considered at each stage of the development lifecycle.

What does a secure development policy contain?

As with ISO 27001 generally, a secure development policy must consider the security risks and mitigation strategies associated with each of the three pillars of information security: people, processes and technology.

In this section, we explain how these pillars relate to your secure development policy.

  • People

‘People’ here refers primarily to your developers. It’s crucial that you establish certain rules regarding them, because their mistakes or malicious actions could cripple your organisation.

The policy should set out minimum requirements for developers, in terms of qualifications, level of experience, and so on. These don’t need to be terribly specific, but should ensure that any developer meets a minimum standard for developing your systems and software.

This reduces the risk of a developer’s mistake going unnoticed or the possibility of them deliberately sabotaging the software or application.

  • Processes

There are several processes that you must address in your secure development policy, such as the separation of development, testing and operational environments.

It goes almost without saying that you should isolate your development and operational environments – not doing this means any changes you make in development will take immediate effect in your software or application.

You should create an authorisation process that controls movement from one environment to another. This reduces the risk of a developer making unauthorised changes, thus ensuring that any modifications pass through an approval process.

This is standard stuff for product and service development, but organisations often forget that they must also implement a testing environment that’s distinct from both of these phases.

There are functional and security benefits of doing this. For a start, developers and testers often work at the same time. As such, the development phase is subject to frequent change, with tools running in the environment that could disrupt or undermine the testing process.

By isolating these environments, you also demonstrate that they are distinct processes, with different people responsible for each.

This makes it easier to silo testers from the developers, ensuring that they have no preconceived notions about the code. This mitigates the risk of bias and provides an objective opinion of the product/service that parallels someone using it in the live environment.


See also:


Your secure development policy should also include version control (sometimes known as ‘source control’).

This is the practice of tracking and managing changes to code over time, allowing organisations to see who made changes and when they occurred.

Implementing version control dissuades anyone from making unauthorised changes to your systems, and gives you documented proof of transgressions.

It also helps fix problems where genuine mistakes break the software, application or system in development, as developers can quickly compare earlier versions to see what went wrong.

  • Technology

The first technological consideration in your secure development policy should be to guidelines on programming languages and coding. The policy should direct the reader to the specific guidelines for each language and tool.

For example, organisations might mandate that developers follow certain best practices, such as those outlined in the OWASP Secure Coding Practices Guide.

Coding languages and development tools inevitably contain weaknesses or quirks that can lead to vulnerabilities or unintended behaviour. Developers must implement hardening techniques to reduce the attack surface of your software or application.

Whatever techniques you use, they must be agreed upon and documented so that developers are aware of their responsibilities.

Your secure development policy should also set the parameters on secure repositories. These are the systems where your code is stored and managed, so it’s essential that they are protected.

In most cases, organisations should use a Cloud-based repository, as it protects them in the event of physical damage to their servers.

We recommend reviewing the NCSC’s (National Cyber Security Centre) guidelines when creating your repository.

They provide essential advice on how to develop a secure repository, and contain a self-assessment to ensure that you’ve followed them.

Simplify the creation of your secure development policy

IT Governance’s ISO 27001 Toolkit contains a secure development policy template, helping you create comprehensive documentation quickly.

The toolkit was developed by the global experts who led the first ISO 27001 certification project, and contains more than 140 customisable documentation templates, including ISO 27001 policies, procedures, work instructions and records.

With our help, you can halve your implementation costs and the time taken to generate mandatory ISO 27001 documents.

Find out more