Free ebook: NIS2 ready using ISO 27001 best practices
Download ebook
Academy home
Best Practices from ISO 27001 for Secure System Acquisition and Development: Create your NIS2 measures

In EU's new NIS2 directive, secure system acquisition and development are grouped together and named as 1 of 10 important security measures that organizations in scope need to have proportionate and documented security measures for.

Secure development and secure system acquisition are essential for your information security, because they are gateways to your data. They are one of the lines of defense against cyber security threats. With good measures on both development and acquisition you can ensure the systems you utilize can resist current and emerging threats.

  • Secure development: The goal is to ensure security is included in new systems right from the start. Secure development integrates security controls at every step of the development process to prevent potential breaches and minimize vulnerabilities.
  • Secure system acquisition: The goal is to acquire systems in a controlled way that ensures compliance with high-enough security standards. This guarantees the acquired systems aren't weaker than your other lines of defense – security program is only as solid as its most vulnerable point.

This blog post present battle-tested measures from ISO 27001 standard for improving both - your secure development and system acquisition practices. With these companies not only protect their sensitive data but also build trust with stakeholders and customers, ensuring that your company’s reputation remains intact in the process. Remember, it’s much more cost-effective to build security in from the beginning rather than dealing with the expensive aftermath of a data breach.

Secure development 101

Secure system development is a rigorous approach to designing, building and implementing software and hardware solutions with utmost consideration for security. It involves embedding information security and privacy considerations right from the initial stages of development, factoring in essential principles such as data confidentiality, integrity, and availability. Fundamental to secure system development is the recognition that security shouldn't be an afterthought – it's an integral part of software construction that needs to be anticipated, designed, and executed from inception until deployment.

Secure development benefits

  • Safeguard from vulnerabilities: A secure development process safeguards your systems from security vulnerabilities and reduces the risk of potential cyber attacks. The safeguards put into place during the planning and implementation stages ensure that your system is robust against malicious activities. As a result, there's less likelihood of unauthorized persons getting access to your valuable data.
  • Build customer trust: Implementing a secure development process is a requirement for information security certifications (like ISO 27001) and infuses trust among your customers and stakeholders. They are reassured that their data is secure in your hands. This trust can massively boost your brand's reputation and open the doors to new business opportunities.
  • Satisfy regulatory requirements: By adhering to e.g. ISO 27001 standard, you can have a common language for communication with customers. It will not only help you avoid penalties and legal problems, but it also catches the eye of potential investors and customers who see compliance as an indication of your commitment to ensure the highest level of data security.
  • Create responsibility for the developers: Developers have a big part to play in strong information security. By having clear guidelines for their coding work, that are monitored and continuously improved, you communicate that their input plays a key role in your information security program.

Secure system acquisition 101

Secure system acquisition refers to the process of procuring a new software or hardware system while ensuring its security compliance according to set standards. This process involves outlining the security prerequisites for new systems (which can of course significantly differ for critical or low priority systems), selecting an appropriate provider, ensuring that the system's security features meet your organization's needs, and lastly, adding the system to the existing infrastructure safely.

Secure system acquisition benefits

  • Risk mitigation: Secure system acquisition helps mitigate risks associated with security breaches, data leaks, and cyberattacks by ensuring that the systems being acquired meet established security standards and requirements.
  • Business continuity: By minimizing security vulnerabilities in acquired systems, organizations can enhance their resilience to cyber threats, thereby reducing the likelihood of disruptions to business operations and ensuring continuity.
  • Cost savings: Proactively addressing security concerns during the acquisition phase can help avoid costly security breaches, incidents, and remediation efforts that may arise due to inadequate security measures post-implementation.
  • Streamlined operations: Implementing security controls during the acquisition phase ensures that security requirements are integrated into the system architecture from the outset, reducing the need for costly retrofitting or reconfiguration later on.

ISO 27001: Examples of secure development and system acquisition best practices to implement

ISO 27001 addresses secure development and system acquisition on multiple controls, highlighting aspects like setting clear security requirements for built or acquired applications, having secure coding rules, creating a robust development and testing environment and implementing changes in a controlled way.

Often organizations also decide to refer to more detailed commonly accepted materials related to vulnerabilities and preventing them with secure coding (e.g. OWASP Top Ten).

8.25: Define general secure development rules

This control highlights, that secure development rules need to be documented, they need to cover the whole development lifecycle and they need to be rigorously enforced. You may also want to include checkpoints in your development projects, where a review from information security perspective is carried our.

Important aspects in secure development rules - e.g. separate environments, defining security requirements for products, testing processes and secure source code management are covered in more detail in the subsequent controls.

8.26: Acquire and create secure applications

This control doesn't discriminate between acquired or self-created applications - it says you need to define security requirements for both to ensure, all the acquired or self-created applications are secure enough.

Application security requirements benefit from priority classification. For 'Low' priority systems some basic checks on the software provider profitability and communications might suffice, but for 'High' priority system you might want to have detailed requirements for multi-factor authentication, encryption, integration and logging capabilities, data location and restoration or even required certifications (e.g. ISO 27001) for the service provider.

Application security requirements are in place to ensure that all necessary security needs are recognised and taken into account during the development or acquisition process.

8.28: Define secure coding rules for your developers

Ultimately software is a bunch of code where vulnerabilities can creep into. It's also otherwise important to create clear code with shared principles - it e.g. improves quality and makes it easier to introduce new people into the projects.

Secure coding rules try to ensure that software is written in a secure manner, reducing the chances of having potential vulnerabilities that could compromise information security. These procedures should be broadened to encompass software components sourced from third parties and open-source software. It's crucial that the team has ownership of the secure coding practices, as they need to stay up-to-date on the rapidly evolving threat landscape.

Secure coding rules could include e.g. following aspects:

  • general secure coding instructions (proper usage of selected frameworks / tools, screening of new external libraries, preventing general vulnerabilities (OWASP), acceptable software to use for coding work)
  • rules for reviewing and publishing code (code review agenda, controlled process for publishing updates)
  • definition of done (removing unnecessary code, updating documentation, ensuring automated checks are OK)
  • testing guidelines (how to test functionality, how to use test data, limiting use of customer data)

8.29: Set processes for testing the security of your applications

This control is about planning processes for testing the security of applications, not general functionality or user experience. In the development process, it's essential to establish and follow security testing procedures. These processes ensure that when applications or code are deployed to the production environment, they are thoroughly tested to confirm they meet information security requirements. Tests should align with specified requirements, covering both functional and non-functional aspects.

Having testing guidelines for your own personnel is important, but organizations often strenghten this aspect by using automated tools to run through the new written code (e.g. vulnerability scanning, secret detection, dependency scanning), automating the more dynamic security testing (e.g. DAST) or collaborating with specific penetration testing professionals to try to break into their environments and compromise data.

8.31: Separation of development, test and production environments

Development, testing, and production environments must be kept separate and secured to safeguard the production environment and data from potential compromise during development and testing activities. The necessary level of separation between these environments should be identified and enforced to prevent any issues from affecting production systems.

8.32: Implement changes in a controlled manner

This control highlights, that changes made to applications should follow change management rules. Smaller everyday code commits might be normal and follow a lighter process, bigger changes to key application components (e.g. authentication, logging, user management) might go through more comprehensive checks and risk analysis before being published.  

No matter if the change control procedures are light or heavy, they must be documented and enforced to safeguard the confidentiality, integrity, and availability of information across systems.

8.8: Have a process for managing technical vulnerabilities

Control 8.8 is a broad one about vulnerability management. When a technical vulnerability is identified through any source (e.g. security testing tools, manual code review or through external news sources), organization needs to know what to do.

The process might include categorizing the vulnerability, analysing the vulnerability and making decisions for the rejection or treatment actions with documented reasonings. Some vulnerabilities can be extremely urgent and need immediate treatment actions, while for some the actions can be grouped together and scheduled for later.


The importance of secure development and system acquisition can't be overstated. All kind of companies are totally dependant on their data and the applications used to store and process that data. This is shown time and time again e.g. through operations in physical factories getting crippled due to a ransomware attack. Protect your applications to protect your business!

You can find battle-tested best practices from ISO 27001 to help formulate your secure development and system acquisition procedures - and meet NIS2 requirements. From defining general rules, through creating secure applications, to managing technical vulnerabilities, it all allows your organization to create a secure system rooted in robust and tested practices.

As with all aspects of information security, secure development and acquisition practices need continuous improvement. Start with something and commit you and the people on your development teams to improvement - and you'll be on the right track.


Share article