CALL US 1-888-553-2256

The ISO 27001 & ISO 22301 Blog

Ranko Njegovan

What are secure engineering principles in ISO 27001:2013 control A.14.2.5?

In my days of programming (big hosts and green/amber terminals, matrix printers…) we didn’t think so much about information security, and especially not about secure engineering. Functional specifications were very simple, and acceptance criteria for the final product were: it had to look fairly nice, calculations (if any) had to be correct, reports with few selection criteria worked quickly… and few others.

Everything changed with PCs, and especially with the Internet.

In shopping centers, banks, airports, hospitals, nuclear sites, etc. various types of computer programs, through various types of networks, are handling data, monitoring, and even managing processes. We can use a vast number of online services that are available globally and 24/7. It’s great – if we are all good guys (not too sloppy ones) and Mother Nature treats us nicely.

Confidentiality, integrity, and availability (CIA) of information is mandatory, and that’s where secure engineering principles will help.

Secure engineering and secure engineering principles


Secure engineering is actually how you will apply security while developing your IT projects. In order to do that, you should take into account threats from natural disasters and humans. These may include: earthquakes, tornadoes, floods, misuse, and malicious human behavior (find more threats and vulnerabilities in Catalogue of threats & vulnerabilities.

To assure management of those treats, high-level rules are defined to apply security. These are your secure engineering principles. For example, most of the projects deal with information. So, your principle will be “Assure information protection in processing, transit, and storage.” Based on principles, procedures will be developed that define activities in detail. For the mentioned example, you will define, e.g., a backup procedure and clearly state that incremental backup should be done every day, and full backup done during the weekend. Also, you will define responsibilities and how to control whether the procedure is followed.

It’s important to know that principles apply to every phase of your development projects, and to all architectural layers of your final products (business, data, applications, and technology).

Requirements of ISO 27001:2013 – control A.14.2.5

To help you with the implementation of secure system engineering principles, a new control is introduced in Annex A: A.14.2.5 – Secure system engineering principles. Control is not defined with many details, but in general, ISO 27001 requires you to establish (i.e., define), document, apply (i.e., use them in real life), and regularly review your principles.

As you can see, the standard is not very specific; so, in order to implement that control, you can start with addressing the biggest threats.

So, you should introduce your principles to your people and make sure that they are followed. If you have outsourced partners, you should get them to apply those principles or to apply principles comparable to yours. You can do that by using contracts or some other regulatory means. If you are planning to use some new technologies, they should be analyzed for security risks (like known attack patterns).

A few hints on how to approach

Recently, I audited one ICT company (consulting, developing, implementations services) that defines secure principles in the most desirable way: easy to understand and operationally manageable.

Due to the fact that control A.14.2.5 is applicable, they took an interesting approach. During several brainstorming sessions with key employees (from the legal department, account managers, system architects, developers, testers, consultants from the implementation team, help desk guys) secure engineering principles emerged. During those sessions, they analyzed their current situation and assessed the biggest threats during development of their ICT projects, grouped them, and defined an approach of how to manage them. Of course, the detailed approach was defined in procedures and work instructions. To gain a customer view, on their last session they brought in the CIO of their biggest customer.

To test the defined principles (it was really testing of the procedures and templates defined) they documented an “internal audit” for one old application, using quality assurance checklists for each development stage.

So, since security engineering principles (a document with “political” statements) are your guidelines for building information security into all architectural layers, in order to have them implemented in a real-world environment they have to be followed by a procedure that is easily understandable by all affected people. If we take the previously mentioned principle “Assure information protection in processing, transit, and storage” and apply it to application development, it would be as follows:

  • business layer – e.g., based on user authentication level; only particular users can see personal data
  • data layer – e.g., only logging in with a strong database password for database maintenance activities is allowed
  • applications – e.g., application encryption is used for data export and import
  • technology – e.g., open-source software and state-of-the-art hardware and network infrastructure provided by selected vendors are used

Measure, Measure, Measure, Cut – M3C1 (Measure three times cut once)

It’s difficult to create a cookbook on how to define secure engineering principles. It really depends on lots of different factors, and it’s different for each company. Maybe the most important thing is that they are understandable for your employees and that everybody in the cycle gets “something for themselves.”

Prior to final approval of your documentation that defines secure engineering principles, try to apply it to some existing or old project to make sure that added value can be achieved. Don’t rush with it – define something that will help you and assure added value for your customer.
So, before you approve your principles – Measure, Measure, Measure and then Cut.

Click here to see this free  ISO 27001 Gap Analysis Tool to find out how compliant you are with the requirements of ISO 27001:2013.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 27001/ISO 22301 standards.

You may unsubscribe at any time.

For more information on what personal data we collect, why we need it, what we do with it, how long we keep it, and what are your rights, see this Privacy Notice.

2 responses to “What are secure engineering principles in ISO 27001:2013 control A.14.2.5?”

  1. Mostafa El-Hawary says:

    Why the ISO 27001 is very general?, i mean that i can state few secure engineering principles to be compatible with that section, and become ISO certified, what is criteria that say that this section is fulfilled?

Leave a Reply

Your email address will not be published. Required fields are marked *



  • Advisera is Exemplar Global Certified TPECS Provider for the IS, QM, EM, TL and AU Competency Units.
  • ITIL® is a registered trade mark of AXELOS Limited. Used under licence of AXELOS Limited. All rights reserved.
  • DNV GL Business Assurance is one of the leading providers of accredited management systems certification.