ISO 27001 Annex A 8.28 is a security control that mandates the application of Secure Coding Principles throughout the software development lifecycle. By enforcing secure architecture, input validation, and secure memory management, organizations prevent vulnerabilities, ensuring system resilience and minimizing the risk of exploitation in production environments.
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:
- The Standard: “Show me the document where you tell developers which security rules to follow.”
- The Evidence: “Show me a pull request where a code change was rejected because of a security flaw.”
- The Libraries: “How do you know your
npmorPythonpackages 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) |
Table of contents
- Key Takeaways: ISO 27001 Annex A 8.28 Secure Coding
- What is ISO 27001 Annex A 8.28?
- ISO 27001 Annex A 8.28 Explainer Video
- ISO 27001 Annex A 8.28 Podcast
- Top 5 Secure Coding Principles
- How to implement ISO 27001 Annex A 8.28
- Further Implementation Guidance
- Applicability of ISO 27001 Annex A 8.28 across different business models.
- Fast Track ISO 27001 Annex A 8.28 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 8.28 FAQ
- ISO 27002 Control 8.28
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 Annex A 8.28 Control and Attributes Table
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.
Establishing a robust secure coding framework is essential for mitigating software vulnerabilities at the source. By integrating security into the earliest stages of the development lifecycle, organisations can satisfy ISO 27001 Annex A 8.28 requirements while reducing the long-term cost of remediation.
1. Formalise Secure Coding Standards and Guidelines
- Define and document a set of mandatory coding standards based on industry-recognised benchmarks such as OWASP Top 10, CERT, or CWE.
- Establish specific technical requirements for input validation, output encoding, and the secure use of cryptography to prevent common injection attacks.
- Result: A consistent baseline of security expectations that developers must meet across all internal and outsourced projects.
2. Provision Integrated Security Tooling in the IDE
- Deploy “linting” tools and IDE-based security plugins that provide real-time feedback to developers as they write code.
- Configure these tools to flag prohibited functions, hardcoded credentials, and insecure memory management patterns before the code is even committed.
- Result: The immediate identification and correction of security flaws, fostering a “shift-left” security culture within the team.
3. Implement Automated Static and Dynamic Analysis
- Integrate Static Application Security Testing (SAST) and Software Composition Analysis (SCA) into the CI/CD pipeline to scan for vulnerabilities and insecure dependencies automatically.
- Establish “Build Breakers” that prevent code from progressing if it contains unresolved security issues above a defined risk threshold.
- Result: A automated gatekeeping mechanism that ensures only code meeting your security standards can be merged or deployed.
4. Enforce Peer Reviews and Collaborative Security Audits
- Mandate a four-eyes principle where a second developer or security specialist must review all code changes via Pull Requests (PRs).
- Utilise checklists derived from your secure coding standards to guide the review process and ensure technical compliance.
- Result: Reduced risk of intentional backdoors and human error through rigorous peer-led verification.
5. Execute Secure Deployment and Configuration Management
- Use Infrastructure as Code (IaC) templates to ensure that the environments where code is deployed are hardened by default.
- Revoke all default passwords and disable unnecessary services or API endpoints in the application configuration before release.
- Result: A secure execution environment that protects the application from exploitation through misconfiguration.
6. Maintain and Update Third-Party Components
- Monitor security advisories for all external libraries and frameworks used within your codebase.
- Establish a formal patching schedule to replace or update vulnerable components within a timeframe dictated by your risk management policy.
- Result: Continuous protection against supply chain attacks and newly discovered vulnerabilities in software dependencies.
Further Implementation Guidance
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.
Applicability of ISO 27001 Annex A 8.28 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Applies to internal automation scripts (e.g., Python, PowerShell) and low-code platforms like Zapier or PowerApps. The goal is to prevent simple errors like hardcoded passwords. |
|
| Tech Startups | Fundamental to the product. Requires a “Shift Left” approach where security is automated via tools in the IDE and CI/CD pipeline to match rapid release cycles. |
|
| AI Companies | Focuses on the integrity of the model and data processing. Secure coding here includes protecting against adversarial inputs and ensuring Python libraries are tamper-free. |
|
Fast Track ISO 27001 Annex A 8.28 Compliance with the 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.
| Compliance Factor | SaaS “Secure Coding” Platforms | High Table ISO 27001 Toolkit | Real-World Example |
|---|---|---|---|
| Data Ownership & Continuity | Locks policy definitions and checklists inside a proprietary system. Canceling the subscription means losing the “rules of the road.” | Permanent Ownership: You download “Secure Development Policy” and “Secure Coding Guidelines” in Word/Excel that you own forever. | Hosting guidelines on your internal wiki or embedding them in your repo, rather than renting access to them. |
| Simplicity & Workflow | Adds friction by forcing developers to log into a third-party portal to “attest” to secure coding practices. | Guidelines, Not Gatekeepers: Seamlessly integrates by adding the “Secure Coding Checklist” directly to your existing Pull Request (PR) templates. | Developers checking a box in GitHub/GitLab during a PR, rather than logging into a separate compliance tool. |
| Cost Structure | Often charges licensing fees per “contributing developer,” causing costs to skyrocket as engineering teams grow. | One-Off Fee: A single payment covers the documentation suite regardless of team size (5 or 500 developers). | allocating budget to actual security tools (SAST/DAST) instead of paying per-user fees just to host a policy PDF. |
| Freedom & Customization | Enforces rigid, pre-defined “best practices” that may be too generic or irrelevant for specific stacks (e.g., Rust, Go). | Define Your Standard: A fully editable framework allows you to tailor “Secure Coding Principles” to your exact tech stack and OWASP needs. | Writing specific rules for your microservices architecture rather than trying to fit into a vendor’s generic 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
What is the primary requirement of ISO 27001 Annex A 8.28?
ISO 27001 Annex A 8.28 requires that secure coding principles are applied to software development to reduce vulnerabilities. This means you cannot just code for functionality; you must establish specific guidelines (like input validation and error handling) to prevent security flaws from being introduced into the software.
Is following the OWASP Top 10 mandatory for ISO 27001?
While ISO 27001 does not strictly mandate OWASP, it is the industry standard most auditors expect to see. To demonstrate compliance, your secure coding policy should explicitly reference how you mitigate common risks, such as:
- Broken Access Control: Ensuring users cannot act outside their intended permissions.
- Injection Flaws: Preventing SQL or command injection by sanitizing inputs.
- Cryptographic Failures: Ensuring sensitive data is encrypted at rest and in transit.
Does this control apply to internal scripts and low-code platforms?
Yes, Annex A 8.28 applies to any code or logic that interacts with business data. It is a common misconception that it only applies to customer-facing apps. You must secure:
- Database Scripts: SQL queries used for reporting or maintenance.
- Automation Scripts: Python or PowerShell scripts used by IT (often overlooked but high risk).
- Low-Code/No-Code: Configurations in platforms like PowerApps or Zapier must still follow security logic.
What tools are required to demonstrate secure coding compliance?
Auditors generally expect a mix of proactive guidelines and automated scanning tools. Evidence of compliance typically includes:
- IDE Plugins: Tools (like SonarLint) that alert developers to security issues in real-time as they type.
- SAST Tools: Static Application Security Testing scanners that check the code repository before deployment.
- SCA Tools: Software Composition Analysis tools that check open-source libraries for known vulnerabilities.
What will an ISO 27001 auditor ask regarding Control 8.28?
Auditors focus on whether developers actually know and follow the guidelines. Be prepared for interview questions such as:
- “Show me your documented Secure Coding Guidelines.”
- “How do you ensure developers are trained on these guidelines?”
- “Show me evidence that a recent pull request was rejected due to a security violation.”
- “How do you manage the security of third-party libraries (dependencies)?”
Who is responsible for secure coding?
While developers write the code, accountability is shared across the technical team.
- Developers: Responsible for adhering to the guidelines and fixing issues found by scanners.
- Tech Leads/Architects: Responsible for enforcing the standards during code reviews.
- Security Team: Responsible for maintaining the policy and selecting the scanning tools.
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 |
