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

Organisations that implement ISO 27001 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’s guidelines 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 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.

This section of the Standard 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 each 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’ 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.

That’s why you must conduct employee screening. That is to say, you should make sure that any developer working on your system, whether in-house or outsourced, is who they claim to be and that they have the necessary skills to do the job.

Likewise, you must conduct regular tests to make sure their work is satisfactory. This might include peer reviews, independent quality assurance and code reviews.

Another requirement is the segregation of duties. This refers to practices in which the knowledge and/or privileges required to complete a task are divided among the team, so that no single person can perform or control it alone.

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

There are several processes that you must include 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.

Separating the two environments also 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 access controls. These are security mechanisms that ensure employees can only view or edit information that’s relevant to their job.

After all, you don’t want every employee to be able to see your source code and related items, such as designs, specifications, verification and validation plans – and you certainly don’t want them to have the power to make changes to that information.

Likewise, you should also implement 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 organisations in instances where genuine mistakes break the environment, as developers can quickly compare earlier versions to see what went wrong.

The first technological consideration in your secure development policy should be to write guidelines on programming languages and coding.

Coding languages and development tools inevitably contain weaknesses, and developers must implement hardening techniques to reduce the attack surface of your software or application.

They might do this by removing login credentials that are no longer needed, performing integrity checks and disabling or removing unnecessary services.

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

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 contain guidance on secure repositories. These are the central point at which 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.