What is ISO 27002:2022 Control 8.28 on Secure Coding?

Poor coding practices such as improper input validation and weak key generation can expose information systems to security vulnerabilities and result in cyber attacks and compromise of sensitive information assets.

For example, in the infamous Heartbleed bug incident, hackers exploited improper input validation in the code to gain access to more than 4 million patients’ data.

Therefore, organisations should ensure that secure coding principles are followed so that poor coding practices do not lead to security vulnerabilities.

Purpose of Control 8.28

Control 8.28 enables organisations to prevent security risks and vulnerabilities that may arise as a result of poor software coding practices by designing, implementing, and reviewing appropriate secure software coding principles.

Attributes Table of Control 8.28

Control 8.28 is a preventive type of control that helps organisations maintain the security of networks, systems, and applications by eliminating risks that may arise out of poorly-designed software code.

Control Type Information Security Properties Cybersecurity Concepts Operational Capabilities Security Domains
#Preventive #Confidentiality #Protect #Application Security #Protection
#Integrity #System and Network Security
#Availability



Get an 81% headstart

We've done the hard work for you, giving you an 81% Headstart from the moment you log on.
All you have to do is fill in the blanks.

Book a demo



Ownership of Control 8.28

Considering that 8.28 requires the design and implementation of organisation-wide secure coding principles and procedures, the chief information security officer should be responsible to take appropriate steps for compliance.

General Guidance on Compliance

Control 8.28 requires organisations to establish and implement organisation-wide processes for secure coding that applies to both software products obtained from external parties and to open source software components.

Furthermore, organisations should keep up to date with evolving real-world security threats and with the most recent information on known or potential software security vulnerabilities. This will enable organisations to improve, and implement robust secure software coding principles that are effective against evolving cyber threats.

Supplementary Guidance on Planning

Secure software coding principles should be followed both for new coding projects and for software reuse operations.

These principles should be adhered to both for in-house software development activities and for the transfer of the organisation’s software products or services to third parties.

When establishing a plan for secure coding principles and determining the prerequisites for secure coding, organisations should comply with the following:

  • Organisations should determine security expectations tailored to their needs and establish approved principles for secure software coding that will apply to both in-house software development and outsourced software components.
  • Organisations should detect and document the most prevalent and historical poor coding design practices and mistakes that result in compromise of information security.
  • Organisations should put in place and configure software development tools to ensure the security of all code created. One example of such tools is integrated development environments (IDE).
  • Organisations should achieve compliance with the guidance and instructions provided by software development tools.
  • Organisations should review, maintain, and securely use development tools such as compilers.

Supplementary Guidance on Security During Coding

Secure coding practices and procedures should take into account the following for the coding process:

  • Secure software coding principles should be tailored to each programming language and techniques used.
  • Deployment of secure programming techniques and methods such as test-driven development and pair programming.
  • Use of structured programming methods.
  • Proper code documentation and removal of code defects.
  • Prohibition on the use of insecure software coding methods such as unapproved code samples or hard-coded passwords.

Supplementary Guidance also notes that security testing should be performed both during and after the development in accordance with Control 8.29.

Before putting the software into actual use in the live application environment, organisations should consider the following:

  • What is the attack surface?
  • Is the principle of least privilege followed?
  • Carrying out an analysis of the most prevalent programming mistakes and documenting that these risks have been eliminated.



Compliance doesn't have to be complicated.

We've done the hard work for you, giving you an 81% Headstart from the moment you log on.
All you have to do is fill in the blanks.

Book a demo



Supplementary Guidance on Review Process

After the Code Is Put Into Use in the Production Environment

  • Updates should be applied in a secure manner.
  • Security vulnerabilities reported in line with Control 8.8 should be addressed.
  • Suspected attacks on information systems and errors should be recorded and these records should be reviewed on regular intervals so that appropriate changes to code can be made.
  • Unauthorised access to, use of, or changes to source code should be prevented via mechanisms such as management tools.

When Organisations Use External Tools, They Should Take Into Account the Following

  • External libraries should be monitored and updated at regular intervals based on their release cycles.
  • Software components should be carefully vetted, selected, and authorised especially cryptography and authentication components.
  • Licensing of external components and ensuring their security.
  • Software should be tracked and maintained. Furthermore, it must be ensured that it comes from a trustworthy source.
  • Development resources should be available for the long term.

When Making Changes to a Software Package, the Following Should Be Considered

  • Risks that may arise out of built-in controls or compromise of integrity processes.
  • Whether the vendor gives consent to changes.
  • Whether it is possible to get consent from the software vendor for regular updates.
  • The likely impact of carrying on the maintenance of the software that arises out of changes.
  • Whether the changes would be compatible with other software components used by the organisation.

Additional Guidance on Control 8.28

Organisations should ensure that security-relevant code is used when it is necessary and is resistant to tampering.

Control 8.28 also lists the following recommendations for security-relevant code:

  • While programs installed via binary code include security-relevant code, this is limited to the data stored within the application itself.
  • Concept of security-relevant code is only useful when code is run on a server that is not accessible to the user and it is segregated from the processes that use it and its data is kept securely in another database. For instance, you can run an interpreted code on a cloud service and access to code can be restricted to privileged administrators. It is recommended that you protect these access rights via methods such as just-in-time administrator privileges and robust authentication mechanisms.
  • Appropriate configurations on web servers should be implemented to prevent unauthorised access to and browsing of the directory.
  • When designing application code, you should start with the assumption that the code is vulnerable to attacks due to coding errors and actions by malicious actors. You should design critical applications in a way that they are not vulnerable to internal faults. For instance, the output produced by an algorithm can be reviewed to ensure that it complies with security requirements before it can be used in critical applications such as finance-related applications.
  • Certain web applications are highly vulnerable to security threats due to poor coding practices such as database injection and cross-site scripting attacks.
  • Organisations should refer to ISO/IEC 15408 series for more information about IT security evaluation.



Manage all your compliance in one place

ISMS.online supports over 100 standards
and regulations, giving you a single
platform for all your compliance needs.

Book a demo



Changes and Differences from ISO 27002:2013

27002:2022/8.28 is a new type of control.

New ISO 27002 Controls

New Controls


Organisational Controls

ISO/IEC 27002:2022 Control IdentifierISO/IEC 27002:2013 Control IdentifierControl Name
5.105.1.1, 05.1.2Policies for information security
5.206.1.1Information security roles and responsibilities
5.306.1.2Segregation of duties
5.407.2.1Management responsibilities
5.506.1.3Contact with authorities
5.606.1.4Contact with special interest groups
5.7NewThreat intelligence
5.806.1.5, 14.1.1Information security in project management
5.908.1.1, 08.1.2Inventory of information and other associated assets
5.1008.1.3, 08.2.3Acceptable use of information and other associated assets
5.1108.1.4Return of assets
5.12 08.2.1Classification of information
5.1308.2.2Labelling of information
5.1413.2.1, 13.2.2, 13.2.3Information transfer
5.1509.1.1, 09.1.2Access control
5.1609.2.1Identity management
5.17 09.2.4, 09.3.1, 09.4.3Authentication information
5.1809.2.2, 09.2.5, 09.2.6Access rights
5.1915.1.1Information security in supplier relationships
5.2015.1.2Addressing information security within supplier agreements
5.2115.1.3Managing information security in the ICT supply chain
5.2215.2.1, 15.2.2Monitoring, review and change management of supplier services
5.23NewInformation security for use of cloud services
5.2416.1.1Information security incident management planning and preparation
5.2516.1.4Assessment and decision on information security events
5.2616.1.5Response to information security incidents
5.2716.1.6Learning from information security incidents
5.2816.1.7Collection of evidence
5.2917.1.1, 17.1.2, 17.1.3Information security during disruption
5.30NewICT readiness for business continuity
5.3118.1.1, 18.1.5Legal, statutory, regulatory and contractual requirements
5.3218.1.2Intellectual property rights
5.3318.1.3Protection of records
5.3418.1.4Privacy and protection of PII
5.3518.2.1Independent review of information security
5.3618.2.2, 18.2.3Compliance with policies, rules and standards for information security
5.3712.1.1Documented operating procedures


People Controls


Physical Controls


How ISMS.online Helps

Our platform has been developed specifically for those who are new to information security or need an easy way to learn about ISO 27002 without having to spend time learning from scratch or reading through lengthy documents.

ISMS.Online comes equipped with all the tools needed for achieving compliance including document templates, checklists and policies which can be customised according to your needs.

Want to see how it works?

Get in touch today to book a demo.


Jump to topic

Max Edwards

Max works as part of the ISMS.online marketing team and ensures that our website is updated with useful content and information about all things ISO 27001, 27002 and compliance.

ISMS Platform Tour

Interested in an ISMS.online platform tour?

Start your free 2-minute interactive demo now and experience the magic of ISMS.online in action!

Try it for free

We’re a Leader in our Field

Users Love Us
Leader Winter 2025
Leader Winter 2025 United Kingdom
Best ROI Winter 2025
Fastest Implementation Winter 2025
Most Implementable Winter 2025

"ISMS.Online, Outstanding tool for Regulatory Compliance"

-Jim M.

"Makes external audits a breeze and links all aspects of your ISMS together seamlessly"

-Karen C.

"Innovative solution to managing ISO and other accreditations"

-Ben H.

DORA is here! Supercharge your digital resilience today with our powerful new solution!