ISO 27001 – A8.27 requires that you ensure information systems are securely designed, implemented and operated within the development life cycle.  By this point you will already have defined your development life cycle by implementing ISO27001 Annex A control A8.25 (Secure development lifecycle).

 But what principles should you adopt? How deep should you go? 

What does the standard require?

The standard states that “Principles for engineering secure systems shall be established, documented, maintained and applied to any information system development activities.” (A8.27 – Secure system architecture and engineering principles) 

Note here the ISO27001 control deliberately uses the word ‘architecture’ in the title. This tells us that this control is concerned with the way that systems are designed and built, and that it happens in a structured way. 

Note that this ISO27001 control has several aspects to it, where it states that principles shall be;

• Established – defined by someone
• Documented – exist in a way that can be evidenced
• Maintained – routinely considered and addressed
• Applied – evidenced that principles are being followed

 You need to keep these in mind when implementing this control. 

Why is this required?

There is a saying that goes “There is nothing new in this world.”. This saying suggests that whatever you’re doing has already been done before. So why re-invent the wheel?!  Just like building a house, there are design principles that are followed by architects and designers to ensure that the end result meets the needs of the user. 

By using established security principles when designing and implementing applications, you are learning from the lessons of others and reducing the likelihood of introducing vulnerabilities into your systems.

 This reduces security risks, but also increases system resilience and reduces the likelihood of a data breach. It also makes your software development lifecycle more efficient and effective. This can reduce costs and increase profitability by delivering systems faster, and free from defects and problems.

 Ongoing maintenance of the system will also be easier, as everyone is following the pre-agreed engineering principles.  If another developer looks at the system they will instantly recognise the way it has been designed and implemented.  

What the auditor is looking for

For this ISO27001 control, the auditor will expect to see a variety of security measures that might include;

 The auditor will be looking for the following to be in place; 

• Documented Secure Software Development Lifecycle (A8.25 – Secure development lifecycle)
• Documented Secure Development Frameworks (e.g. Microsoft Security Development Lifecycle (SDL)
• Management Review Team (MRT) meeting minutes.
• Risk Register.
• Audit results.
• Incident Logs.

 Note that the evidence that the auditor will expect to see will depend upon what principles you have applied.  For example, if you state that one of your design principles (for web) is to test your systems for OWASP vulnerabilities, then the auditor will expect to see how this has been achieved. 

What do you need to do?

Speak to the team responsible for development to understand and establish what principles they currently apply or follow.  For example, do they follow the principle of; 

• Security by design
• Privacy by design and default
• Least Privilege
• Fail securely

 In ISO27001 Annex A control, A8.28 (Secure Coding) expects the definition of secure coding practices, so take a look at that control to understand how the principle has been implemented.

 Once you are aware of the engineering principles that are followed, ensure that you document them.  We would suggest that you incorporate this into your Software Development LifeCycle (SDLC), which you defined in ISO27001 Anne A control A8.25 (Secure development lifecycle). 

On an ongoing basis you must ensure these principles are being followed, and this should form part of your audit of this control. This will evidence that the principles are being maintained and implemented. If there are any issues or incidents, investigate whether or not the principles failed or hadn’t been followed. 

Difficulty rating

We rate this a 1.5 out of 5 difficulty rating. This control is about formalising something that most likely already happens in your development teams. Your job is to ensure that the principles are being followed. Therefore, this control is more about the documentation and implementation of the control. 

Q&A

Are there ‘standard’ principles we should adopt?

Keep in mind the principles of ‘Privacy By Design and Default’, and ‘Security by Design’.  These are subtly different but should be understood and followed.  Your job is to ask “How can we evidence that we are following these principles?” 

Is it mandatory that this is documented?

Yes, because this control specifically states that we shall establish and document principles for engineering secure systems. However, if you’ve already documented your Security Development LifeCycle then you’re almost half-way there.