ISO 27001:2022 Annex A 8.28 Secure Coding

In this guide, I will show you exactly how to implement ISO 27001 Annex A 8.28 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Key Takeaways: ISO 27001 Annex A 8.28 Secure Coding

ISO 27001 Annex A 8.28 requires that security is “baked in” to your software development process, not just bolted on at the end. It mandates the use of Secure Coding Principles to prevent common vulnerabilities (like those listed in the OWASP Top 10) from ever entering your codebase.

Core requirements for compliance include:

• Adoption of Standards: You must explicitly define which coding standards you follow. You cannot just say “we code securely.” You need to cite a framework (e.g., OWASP Top 10, SANS Top 25, or specific language guidelines like PEP 8 for Python).
• Input Validation: The “Golden Rule” of secure coding: Never trust user input. Your code must validate every piece of data coming from a user (forms, APIs, uploads) to prevent attacks like SQL Injection or Cross-Site Scripting (XSS).
• Supply Chain Security: Modern code relies heavily on third-party libraries (open source). You must have a process to check these libraries for known vulnerabilities before you use them and keep them updated.
• Tooling: Use automated tools to help you. SAST (Static Application Security Testing) tools scan your code for security bugs while you type, acting as a spell-checker for security.

Audit Focus: Auditors will ask to see your Software Development Lifecycle (SDLC) policy. They will check:

1. The Standard: “Show me the document where you tell developers which security rules to follow.”
2. The Evidence: “Show me a pull request where a code change was rejected because of a security flaw.”
3. The Libraries: “How do you know your npm or Python packages don’t have vulnerabilities?”

Top 5 Secure Coding Principles (Audit Cheat Sheet):

Principle	Meaning	Why it matters (The Risk)	ISO 27001:2022 Control
Input Validation	Check all data entering the system.	Prevents SQL Injection & Buffer Overflows.	A.8.27 (Secure System Architecture)
Output Encoding	Sanitize data before displaying it.	Prevents XSS (Cross-Site Scripting).	A.8.28 (Secure Coding)
Least Privilege	Code runs with minimum permissions.	Limits damage if the code is hacked.	A.5.18 (Access Rights)
Secure Fail	Error messages shouldn’t reveal secrets.	Prevents attackers from learning system details.	A.8.28 (Secure Coding)
Crypto Agility	Don’t hardcode encryption keys.	Allows you to change keys if they are stolen.	A.8.24 (Use of Cryptography)

What is ISO 27001 Annex A 8.28?

ISO 27001 Annex A 8.28 is about secure coding which means you need to apply secure coding principles in development.

It is a new control introduced in ISO 27001:2022.

ISO 27001 Annex A 8.28 Secure Coding is an ISO 27001 control that requires us to develop code and software and systems with information security designed and built in. You may hear the term – ‘security by design and default’. The goal is to reduce the number of potential information security weaknesses in software.

ISO 27001 Annex A 8.28 Purpose

ISO 27001 Annex A 8.28 is a preventive control to ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.

ISO 27001 Annex A 8.28 Definition

The ISO 27001 standard defines ISO 27001 Annex A 8.28 as:

Secure coding principles should be applied to software development.

ISO27001:2022 Annex A 8.28 Secure Coding

ISO 27001 Annex A 8.28 Explainer Video

In this beginner’s guide to ISO 27001 Annex A 8.28 Secure Coding, ISO 27001 Lead Auditor Stuart Barker and his team talk you through what it is, how to implement in and how to pass the audit. Free ISO 27001 training.

ISO 27001 Annex A 8.28 Podcast

In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001:2022 Annex A 8.28 Secure Coding. The podcast explores what it is, why it is important and the path to compliance.

Top 5 Secure Coding Principles

• Input Validation: Never trust user input.
• Output Encoding: Prevent XSS.
• Least Privilege: Code runs with minimum permissions.
• Secure Fail: Errors shouldn’t reveal sensitive info.
• Cryptographic Agility: Don’t hardcode keys.

How to implement ISO 27001 Annex A 8.28

I am not in the business of telling you how to develop either systems or software. These are professions in their own right. Whilst I am a degree educated and time served software engineer, what I am going to do is show you want the ISO 27001 standard expects in the implementation for you to achieve ISO 27001 certification. These are on the whole, no brainers, common sense and what you would expect but let us take a look anyway.

Secure Development Policy

The first step is to create, or download, your secure development policy. The secure development policy set’s out what you do for information security in the context of software and systems development. It does not set out how you do it, as how you do it is covered in your processes.

General

A lot of what is required here is covered in the other ISO 27001 Annex A Clauses and specifically you should pay attention to:

ISO 27001 Annex A 8.25 Secure Development Life Cycle

ISO 27001 Annex A 8.26 Application Security Requirements

ISO 27001 Annex A 8.27 Secure Systems Architecture and Engineering Principles

You need to establish your processes for secure coding and set your security baseline. These should be applied to in-house as well as third party developers and open source software if applicable.

Threat Analysis

The use of threat analysis will be used to inform on vulnerabilities and guide the principles and processes that you have for secure coding.

More information on threat analysis is covered in: ISO 27001 Annex A 5.7 Threat Intelligence

Before Coding

Before you start coding the standard has considerations that cover new developments and reuse. These prerequisties include:

• Approved principles of secure coding
• Understanding of common and historical coding practices that lead to information security vulnerabilities
• Following development tool provider guidelines
• Maintaining, patching, updating development tools
• Secure design and architecture: ISO 27001 Annex A 8.27 Secure Systems Architecture and Engineering Principles
• Use of a controlled development environment

During Coding

During coding you will evidence and have in place

• Practices and processes based on the principles agreed
• Use secure coding techniques
• Use structured programming techniques
• Document Code
• Prohibit and prevent insecure design technqiues
• Test during and after development

Once code is operational

Once code is operational and in place you will perform review and maintenance and consider

• Securely Packaging and Deploying Updates
• Handle Reported Information Security Vulnerabilities
• Log errors and suspected attacks
• Protect source code from unauthorised access

Third party tools and libraries

If you have used third parties tools or libraries then you will have ensured that you

• have appropriate licensing for what you are doing,
• done due diligence and vetting
• acquired from an authorised and trusted source
• understood the lifetime limitations, if any, on what you use
• assessed the risk
• assessed compatibility with existing software

Coding Guidelines

You are going to make sure that you have documented coding guidelines. These can be standard guidelines or industry best practice, and you likely already do this today, just make sure that this written down, communicated and available to those that need it.

Separate Environments

You are going to make sure that for the in-scope developments that you have separate development, test and live environments with the appropriate management and controls in place around this. This will include the process of promoting through those environments and the authorisations and approvals and acceptance.

Specification and Design

What ever methodology you use it is likely to have a specification and design phase. I am not sure of a situation where you would not, although could, but it is at these phases that you will evidence that information security was considered. Here we place a lot of reliance on ISO 27001 Annex A 5.8 Information Security In Project Management. The same is true when it comes to security checkpoints in projects.

The advice here would be to have in your project management either a placeholder in an existing template / document or create a security specific one. Be sure you are considering things like access requirements, data transfers, technical controls, risks and risk mitigations. Have checkpoints with go / no go decisions and a process for what you do if the checkpoint fails.

Testing

All secure development will have testing. It is not our place, again, to tell you how to test as again, this is a profession in its own right but there must be a level of security testing in place that looks at the three parts of information security being confidentiality, integrity and availability.

Simple testing that can be considered here would be penetration testing, vulnerability testing, regression testing, code scanning and code testing.

Code Repositories

The configuration and management of code and code libraries should be carefully considered and documented. Many tools exist that can help with this and automate many of the tasks.

Knowledge and Experience

The standard touches on this in a number of areas, having people with the right knowledge and / or experience to perform the role. This is also true of the secure development lifecycle. Having a competency matrix and being able to point to qualifications or certifications will help. Where there are gaps a plan, such as training, should be in place but these are basic HR and people functions that are common place in any role.

Outsourced Development

If you outsource your development then the third party supplier controls will apply. The main thing is to ensure they meet your requirements for secure development but all relevant controls will apply to them.

Fast Track Compliance with the ISO 27001 Toolkit

---

Own Your ISMS, Don’t Rent It

Do it Yourself ISO 27001 with the Ultimate ISO 27001 Toolkit

---

For ISO 27001 Annex A 8.28 (Secure coding), the requirement is to apply secure coding principles, such as input validation and output encoding, to your software development. Auditors do not require you to buy expensive “DevSecOps” platforms; they require you to have a documented standard that your developers follow.

The High Table ISO 27001 Toolkit is the logical choice because it provides the governance layer, the policy and the guidelines, that proves you have a secure coding standard, without the complexity or cost of an online platform.

Here is why the Toolkit is the smarter choice for complying with Annex A 8.28:

1. Ownership: You Own Your Coding Standards

SaaS platforms often lock your secure coding checklists and policy definitions inside their system. If you cancel the subscription, you lose the “rules of the road” that your developers are supposed to follow.

• The Toolkit Advantage: You download the Secure Development Policy and Secure Coding Guidelines in Word/Excel. These documents become your organization’s permanent intellectual property. You can host them on your own internal wiki, print them for new hires, or embed them in your repo, they are yours forever, not rented.

2. Simplicity: Guidelines, Not Gatekeepers

Annex A 8.28 requires that secure coding principles be applied. It does not require a complex software tool to “enforce” them if your process is robust.

• The Toolkit Advantage: Developers hate friction. Instead of forcing them to log into a third-party compliance portal to “attest” to secure coding, you simply issue the Toolkit’s Secure Coding Checklist as part of your Pull Request (PR) template. It integrates seamlessly into the workflow they already use (like GitHub or GitLab) because it’s just clear, written guidance – no new software to learn.

3. Cost: A One-Off Fee vs. Per-Developer Licensing

Many application security tools and SaaS compliance platforms charge per “contributing developer.” If you have a growing engineering team, the cost to simply document that you are coding securely can be massive.

• The Toolkit Advantage: You pay a single, one-off fee for the Toolkit. Whether you have 5 developers or 500, the cost of your Secure Coding Policy documentation is the same. You save your budget for actual security tools (like SAST/DAST scanners) rather than spending it on a platform to host a PDF.

4. Freedom: Define Your Standard

SaaS platforms often come with rigid, pre-defined “best practices” that might not fit your tech stack (e.g., generic rules that don’t apply to your specific Rust or Go microservices).

• The Toolkit Advantage: The High Table Toolkit gives you a fully editable framework. You can tailor the Secure Coding Principles to match your exact technology stack – referencing specific libraries, frameworks, or OWASP guidelines that matter to your app. You define the standard that works for your code, rather than trying to fit your development process into a vendor’s box.

Summary: For Annex A 8.28, the auditor wants to see that you have a standard and that developers know it. The High Table ISO 27001 Toolkit provides that standard instantly. It gives you the clear, professional documentation needed to satisfy the requirement, leaving you free to manage your code your way, without ongoing subscriptions.

Conclusion

Many if not all of the controls that apply to this control are covered elsewhere. Be it the experience, licensing, technical controls but consider them in the context of this clause and be able to evidence them as they apply to secure development.

ISO 27001 Annex A 8.28 FAQ

ISO 27002 Control 8.28

ISO 27002 Control 8.28 provides the implementation guidance for Secure Coding.

Related ISO 27001 Controls

ISO 27001 Annex A 8.4 Access To Source Code

ISO27001 Annex A 8.25 Secure Development Life Cycle

ISO27001 Annex A 8.26 Application Security Requirements

ISO27001 Annex A 8.27 Secure Systems Architecture and Engineering Principles

ISO27001 Annex A 8.29 Security Testing in Development and Acceptance

ISO 27001 Annex A 8.30 Outsourced Development

ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments

Further Reading

ISO 27001 Secure Coding Explained

ISO 27001 Annex A 8.28 Control and Attributes Table

Control type	Information security properties	Cybersecurity concepts	Operational capabilities	Security domains
Preventive	Confidentiality	Protect	Application Security	Protection
	Integrity		System and Network Security
	Availability