Inverifi logo

ISO 27001

Annex A.14 - Security in development and support processes

Get compliant with ISO 27001 – Annex A.14 and simplify compliance for your organisation.

Annex 14 controls aim to prioritise information security within application frameworks and the development lifecycle. Incorporate information security standards to each stage of the lifecycle, including data usage when the testing phase takes place.

A.14.1 – Security requirements of information systems

Aim to ensure that information security is an integral part of information systems across the entire life-cycle.

A.14.1.1 Information security requirements analysis and specification.

Risk assessment is an essential part of the business, and it should be taken into account when adapting a new system, or making changes to the existing one, to identify the security requirements of the business.


When contemplating new possible implementations, security measures should be established in the beginning stage to ensure the correct requirements are met before taking into consideration the next stage.


To determine the risk and security threats the organisation may face when a new system is implemented, a risk assessment analysis could be the best option to recollect data and take an informed decision.

A.14.1.2 Securing application services on public networks

When the information is processed through public networks, it must be protected from fraud, contract dispute, and unauthorised disclosure and change. For services supplied through a public network like the internet, cryptography policies ( Annex A.10) should be in place.

If sensitive data such as; finance or HR information is transmitted through this media, security is critical to avoid data breach. There should be minimum security requirements when dealing with this information.

System needs to be regularly monitored to find any suspicious activity or risk.

A.14.1.3 Protecting application services transactions

Any incomplete transmission of digital signature, emails, unauthorised messages alteration, disclosure, message duplication, or replay could lead to the loss of information secured on the systems. It’s your organisation’s responsibility to secure all forms of confidential data, transacting in your system from illegal interceptions, availability attacks or unauthorised disclosure, etc.

A.14.2 – Security in development and support processes

The aim is to ensure that information security is designed and implemented within the development life-cycle of information systems.

A.14.2.1 Secure development policy

Guidelines should be in place for the development of software and systems.


Relevant training should be available to developers on policies related to:

  • Secure coding principles.
  • Pair programming and peer reviews.
  • Independent quality assurance tests.
  • Encryption reviews and assessments.

A.14.2.2 System change control procedure

Any changes to systems during the development lifecycle need precise change control procedures. System change control should be managed and supervised by an authorised person.


Formal change management practices reduce the probability of unintentional or deliberate vulnerabilities that could compromise systems once the changes are made.


In system change control, the system owner must know what changes are executed, and keep accurate information of what changes have been made and by whom . They must ensure their systems are free from any new vulnerabilities.


Rules for authorisation and pre-live testing and validation should be set.

A.14.2.3 Technical review of applications after operating platform changes

When making updates or changes on the operating systems, vital business applications must be analysed to ensure no negative impact on the organisation’s operations or security has occurred. Some applications may experience compatibility issues after a switch to a new operating system platform.


It’s essential to assess operating system updates in a development or testing environment preliminary to implementing them in production.


Control and testing procedures for operating system modifications should be in accordance with accepted change management practices.

A.14.2.4 Restrictions on changes to software packages

Any modification on the software package should be discouraged, restricted, and all changes controlled strictly.


The software packages should be used with no alteration to the extent necessary and practical. If the software package is modified the following should be considered.

  • Possible conflict with built-in controls and processes of integrity;
  • Seller’s consent.
  • Opportunity, in regular system updates, to receive the necessary vendor changes;
  • Impacts on the organisation.
  • Any extra software compatibility in use.

Modifications should be implemented in a software copy, and the original software should be kept. All modifications should be carefully checked and reported, in order to reapply to potential software updates if necessary.

A.14.2.5 Secure system engineering principles

When developing IT projects, you should take into consideration threats from humans or natural disasters, high-level rules should be applied to cover those threats. These are defined as secure system engineering principles.


Secure systems engineering principles are critical to the success of any information system installation. At a generic and platform-specific level, principles of secure software engineering should be considered.


Principles should be considered in every phase of the project.

A.14.2.6 Secure development environment

Organisations should have in place a safe environment that covers the development of the system, from the initial phase to the final.


Risk assessment and other requirements, such as policies, legislation or agreement should be considered to create the level of protection needed.


Once the level of protection has been established, the organisation will record and provide the corresponding processes to any person involved in securing the development system and processes.

A.14.2.7 Outsourced development

All outsourced development must be supervised and monitored by the organisation. When system and software development is contracted out to a third party, the security requirements , ownership and non-disclosure terms, should be defined in the contract or agreement that is connected to the project.


Awareness and training referring to this, should be provided to the persons involved inside your organisations.

A.14.2.8 System security testing

Before the testing process takes place, the security functions integrated into the development process must all be well-defined and documented. The process of formal testing must be carried out by experienced and authorised parties.


Recording of the aim result should be done before the testing phase begins, and in order with the company’s security requirements.

A.14.2.9 System acceptance testing

Procedures should be in place for testing and approving new systems, and updates. Before conducting an acceptance testing, the tests and the standards for demonstrating that a test was successful should be defined based on business needs.

Security testing should also be a part of the acceptance testing process. Security testing should be included in all acceptance testing criteria and procedures.

A.14.3 – Test data

Test data controls, ensure the protection of data used for testing.

A.14.3.1 Protection of test data

Cautious collection, review and security of test data should be accomplished.


The use of any confidential information should be avoided for test purposes. In cases where personal information or sensitive information is needed for the purpose of the testing, this information should be protected by deletion or modification. The following should be considered for the protection of operational data.

  • Access management protocols should refer to application control systems.
  • Authorization should be requested every time operational information is copied to the testng setting.
  • Once the test environment is completed, operational information should be eliminated from a test environment.