ISO 27001 Annex A 8.28 Secure coding practices in software development
What it says
Secure coding principles shall be applied to software development.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure software is built securely to prevent vulnerabilities.
This control is about making sure that the software your business uses or develops is built in a way that keeps it safe from hackers and glitches. If this isn't done, your software might have weak spots that bad actors could exploit to steal your information or disrupt your operations.
Free. Save your status, tasks and notes.
Why it matters
Poor secure coding increases risk of data breaches and operational disruptions due to exploitable software vulnerabilities.
How to implement
The IT manager should develop a secure coding policy that defines expected practices.
This can be done by setting specific guidelines that all software developers must follow, which should cover both in-house and outsourced efforts. Reference standards from ISO 27002:2022 and comply with Australian privacy regulations.
Software developers need to be trained in secure coding practices.
The organisation should organise training sessions and workshops on common coding vulnerabilities and how to avoid them. Use materials from recognised sources like OWASP and ensure the training is up to date with current threats.
Procurement teams should ensure that third-party software and open-source components align with secure coding practices.
They should verify that vendors apply secure coding standards by requiring documentation or certifications. This helps to ensure that all software components used are secure and reliable.
Project managers should implement security throughout the software development lifecycle.
This means incorporating secure design, threat modelling, and regular security reviews and testing into every project stage. Use methods like static application security testing (SAST) to find vulnerabilities early.
Executives should support a culture of continuous improvement in secure coding practices.
This involves monitoring industry trends and incorporating lessons learned into coding standards and procedures. Encourage feedback loops from security incidents to refine and strengthen secure coding policies continually.
Keep it running
Maintain secure coding standards with peer reviews, SAST/DAST and dependency scanning; refresh secure patterns and train developers on OWASP risks.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A copy of the organisation's secure coding policy.
Look at
Whether it includes clear guidelines for coding practices and covers third-party software. GOOD is when the policy is aligned with ISO 27002:2022 and Australian regulations.
- Check 2 of 5What an auditor asks for
Ask for
Records of developer training sessions on secure coding.
Look at
The content for relevance and frequency of these trainings. GOOD is when training is regularly updated and covers emerging threats as per ISO 27002:2022 guidance.
- Check 3 of 5What an auditor asks for
Ask for
To see recent security test reports from the software development process.
Look at
Whether these include assessments of coding vulnerabilities. GOOD is when reports show thorough testing was conducted using tools like SAST.
- Check 4 of 5What an auditor asks for
Ask for
Documentation on third-party software assessments.
Look at
The evaluation criteria and approval process. GOOD is when third-party solutions meet or exceed the organisation's secure coding practices.
- Check 5 of 5What an auditor asks for
Ask for
To review incident response records relating to coding issues.
Look at
Any security vulnerabilities that were identified and their resolution. GOOD is when post-incident reviews are used to improve existing coding practices.
Mappings
Closest match in ASD Information Security Manual: ISM-2040, Ensure secure programming practices in software development, which asks for the same thing.
ASD Information Security Manual: 34 mappings
This control is equivalent to ISM-2040.
Annex A 8.28 requires secure coding principles to be applied to software development. ISM-2040 directly requires the use of secure programming practices for the chosen programming language during software development, which is the practical expression of secure coding principles. Both controls address the same core requirement, with ISM-2040 providing slightly more implementation specificity (language-specific practices).
This control is broader than ISM-0938.
ISM-0938 requires organisations to select user application vendors that demonstrate Secure by Design/Secure by Default, including secure programming practices and use of memory-safe languages. ISO/IEC 27001:2022 Annex A 8.28 mandates secure coding principles in software development, which ISM-0938 expects vendors to follow. Annex A 8.28 focuses on development practices, while ISM-0938 focuses on procurement based on these practices.
This control is broader than ISM-0971.
Annex A 8.28 requires the application of secure coding principles in software development. ISM-0971 supports this by requiring use of the OWASP ASVS for web applications, which provides detailed secure coding and verification requirements that operationalise secure coding principles. ISM-0971 is scoped to web applications and includes assurance criteria beyond coding, whereas Annex A 8.28 is a general coding practice requirement.
This control is broader than ISM-1239.
Annex A 8.28 requires secure coding principles to be applied to prevent vulnerabilities. ISM-1239 supports this by mandating the use of robust web application frameworks, which can enforce safer defaults and reduce the likelihood of insecure coding patterns (for example, built-in CSRF protections). ISM-1239 focuses on tooling/frameworks, while Annex A 8.28 is about the secure coding principles developers must follow.
This control is broader than ISM-1241.
ISM-1241 requires that output encoding is performed on all output produced by web applications to prevent injection-style client-side attacks (e.g. XSS). Annex A 8.28 requires secure coding practices to be applied across software development, which commonly includes output encoding/escaping in web applications. ISM-1241 is a specific secure coding requirement focused on web output handling, while Annex A 8.28 is broader and covers many additional coding practices beyond output encoding.
This control is broader than ISM-1275.
ISM-1275 requires that all software-to-database queries are filtered/validated for legitimate content and correct syntax (i.e., query input validation to prevent malformed or malicious queries). Annex A 8.28 requires secure coding principles to be applied across software development, which includes practices such as input validation, parameterised queries, and defensive coding against injection. ISM-1275 is a specific secure coding requirement focused on database query construction and validation, whereas Annex A 8.28 is broader across all coding areas.
This control is broader than ISM-1276.
ISM-1276 requires software to use parameterised queries or stored procedures (rather than dynamically generated queries) for database interactions to prevent injection-style flaws. Annex A 8.28 requires secure coding practices to be applied across software development, which typically includes input handling and preventing injection (including SQL injection) via safe query construction. ISM-1276 is a specific secure-coding requirement focused on database query methods, while Annex A 8.28 is broader and covers many other secure coding topics beyond database access.
This control is broader than ISM-1278.
ISM-1278 requires software to avoid exposing database structure details through error messages. This maps to Annex A 8.28 because secure coding practices commonly include controlling exception handling, sanitising error outputs, and preventing information disclosure that could aid attackers. Annex A 8.28 applies broadly to coding principles across the application, whereas ISM-1278 is a targeted requirement specifically about database-related error information.
This control is broader than ISM-1849.
Annex A 8.28 requires secure coding principles to be applied to prevent vulnerabilities in developed software. ISM-1849 supports this by mandating use of the OWASP Top 10 Proactive Controls in web application development, translating secure coding principles into concrete developer actions. ISM-1849 is web-specific and prescriptive, while Annex A 8.28 is broader and principle-based.
This control is broader than ISM-1850.
ISM-1850 requires that web application development mitigates the OWASP Top 10 security risks. ISO/IEC 27001:2022 Annex A 8.28 requires secure coding principles to be applied to software development, which directly contributes to preventing many OWASP Top 10 issues (e.g. injection, insecure design and identification/authentication weaknesses). Annex A 8.28 is broader because it applies to all software development and does not enumerate the OWASP Top 10 specifically.
This control is broader than ISM-1851.
Annex A 8.28 requires developers to apply secure coding principles to reduce software vulnerabilities. ISM-1851 supports this by specifying a secure-coding benchmark for web APIs: mitigating the OWASP API Security Top 10 during development. ISM-1851 is narrower and technology-specific (APIs), while Annex A 8.28 applies across all software development.
This control is broader than ISM-1922.
Annex A 8.28 requires secure coding principles to be applied in software development. ISM-1922 supports this by requiring use of the OWASP Mobile ASVS in mobile app development, which provides concrete secure coding and verification requirements for common mobile risks. ISM-1922 is scoped to mobile applications and is a prescriptive standard, while Annex A 8.28 is a general secure coding principle requirement across software types.
This control is broader than ISM-2016.
ISM-2016 requires validation and sanitisation to be performed on all input received over a local network by software. ISO/IEC 27001:2022 Annex A 8.28 requires secure coding principles to be applied to software development, which would typically include input validation and sanitisation as a core secure coding practice. Annex A 8.28 is broader because it covers many secure coding principles beyond input handling, while ISM-2016 is specifically focused on the control to prevent input-driven vulnerabilities.
This control is broader than ISM-2030.
ISM-2030 requires scanning during commits to detect and block plaintext or encoded secrets/keys from being committed to the authoritative repository. Annex A 8.28 requires secure coding principles to be applied during software development, which commonly includes avoiding hard-coded credentials and implementing controls (such as pre-commit hooks/CI checks) to prevent credential leakage. ISM-2030 is a concrete technical enforcement mechanism for one secure coding outcome (no secrets in code), whereas Annex A 8.28 covers a wider set of secure coding principles beyond secret management.
This control is broader than ISM-2031.
ISM-2031 requires organisations to implement and use build-tool security features (e.g. compiler/linker hardening, pipeline protections) to strengthen executable security. ISO/IEC 27001:2022 Annex A 8.28 requires secure coding principles to be applied in software development, and hardened compilation/build settings reduce the impact of coding errors (such as memory corruption) by adding exploit mitigations. Annex A 8.28 primarily addresses how code is written, while ISM-2031 addresses how software is built and packaged into executables.
This control is broader than ISM-2057.
ISM-2057 requires documented input validation rules that are implemented in code and verified through positive and negative unit or integration tests. Annex A 8.28 requires secure coding principles to be applied across software development, within which input validation and associated testing are core secure coding practices. ISM-2057 is more specific (input validation documentation-to-code traceability and test coverage) while Annex A 8.28 is broader across many secure coding topics.
This control is broader than ISM-2058.
ISM-2058 requires that data sources and serialised data inputs are validated before being deserialised to prevent malformed or malicious payloads being processed. This relates to Annex A 8.28 because input validation and safe handling of untrusted data (including deserialisation) are core secure coding principles applied during software development. Annex A 8.28 is broader, covering many secure coding practices beyond deserialisation-specific validation (e.g. authentication, authorisation, error handling and cryptographic misuse prevention).
This control is broader than ISM-2059.
ISM-2059 mandates file type restriction and scanning for malicious content. Annex A 8.28 supports this through secure coding practices that include file type validation and malware scanning, ensuring uploads are securely handled across various application features.
This control is broader than ISM-2060.
Annex A 8.28 requires secure coding principles to be applied throughout software development to prevent vulnerabilities. ISM-2060 supports this by requiring code reviews to verify Secure by Design and secure programming practices are present in the implemented code. Annex A 8.28 is broader (principles and practices overall), while ISM-2060 focuses on one key assurance mechanism (reviews).
This control is broader than ISM-2064.
ISM-2064 requires that web application session cookies contain only digitally signed opaque bearer tokens to prevent tampering. Annex A 8.28 mandates applying secure coding principles, which would include correctly implementing tamper-resistant session management (e.g. signed tokens/cookies). ISM-2064 is a specific technical pattern for cookies, while Annex A 8.28 is broader across all coding practices and defect classes.
This control is broader than ISM-2066.
ISM-2066 requires web application sessions to be centrally managed server side to reduce risks such as session tampering and weak client-side session storage. Annex A 8.28 requires secure coding principles to be applied, which commonly includes secure session management design and implementation patterns. ISM-2066 is a concrete secure session management outcome, while Annex A 8.28 is broader and covers many other secure coding concerns beyond sessions.
This control is broader than ISM-2085.
ISM-2085 requires organisations to prevent exposing exact AI model confidence scores in APIs and user interfaces. Annex A 8.28 requires secure coding practices, which would typically include designing API/UI responses to avoid leaking sensitive or security-relevant information such as exact confidence values. The ISO control is broader and applies to all secure coding concerns, while ISM-2085 is a specific secure-by-design output-handling requirement for AI systems.
This control is broader than ISM-2158.
ISM-2158 focuses on secure handling of externally retrieved content in agentic AI, including input delimitation, validation/sanitisation, and preventing untrusted data from changing governing instructions or controls. Annex A 8.28 requires secure coding practices, which directly supports implementing robust parsing, input validation, content sanitisation, and safe tool-calling boundaries needed to meet ISM-2158. Annex A 8.28 is broader because it applies to all software development, while ISM-2158 targets a specific agentic AI threat pattern (retrieved-content/prompt injection).
This control partially meets ISM-0401.
ISM-0401 demands Secure by Design practices across the entire SDLC, covering stages like design, build, test, and release. ISO/IEC 27001:2022 Annex A 8.28 targets the specific application of secure coding principles during implementation. Thus, Annex A 8.28 is one part of Secure by Design, while ISM-0401 covers architecture, requirements, and more.
This control partially meets ISM-1780.
Annex A 8.28 requires that secure coding principles are applied during software development. ISM-1780 requires the use of SecDevOps practices for software development, which typically embed secure coding alongside automation, CI/CD controls, security testing and deployment governance. Annex A 8.28 is one component within the broader SecDevOps approach mandated by ISM-1780.
This control partially meets ISM-2061.
ISM-2061 requires developer-supported, security-focused peer reviews to be conducted on all critical and security-relevant software components. Annex A 8.28 requires secure coding principles to be applied during software development, and peer review is a common mechanism to enforce and verify those principles in practice. However, Annex A 8.28 is broader (covering secure coding generally), while ISM-2061 is a specific assurance activity (peer review) within that broader secure coding objective.
This control partially overlaps ISM-1460.
ISM-1460 requires the isolation mechanism vendor to demonstrate Secure by Design/Secure by Default practices, explicitly calling out secure programming and memory-safe languages or practices. Annex A 8.28 mandates that secure coding principles are applied to software development, which aligns with the secure programming expectations embedded in ISM-1460's vendor selection requirement. Annex A 8.28 is generally about how software is coded (typically within the organisation or its development arrangements), while ISM-1460 is specifically about procurement/selection assurance for virtual server isolation products.
This control partially overlaps ISM-1826.
ISM-1826 requires selecting vendors for server applications who apply secure programming practices and, preferably, use memory-safe programming languages. Annex A 8.28 requires secure coding principles to be applied to software development. ISM-1826 supports Annex A 8.28 by driving procurement towards products built with secure coding, but Annex A 8.28 applies to the organisation's development activities generally and does not specifically address vendor selection or secure-by-default vendor commitment evidence.
This control partially overlaps ISM-2041.
Annex A 8.28 requires secure coding principles to be applied across software development. ISM-2041 overlaps by requiring memory-safe programming languages or (less preferably) memory-safe programming practices, which are specific secure coding choices to reduce memory corruption vulnerabilities. ISM-2041 is narrower and technology-specific, while Annex A 8.28 covers secure coding more broadly.
This control partially overlaps ISM-2042.
Annex A 8.28 requires applying secure coding principles to reduce software vulnerabilities. ISM-2042 overlaps by mandating Secure by Default across the SDLC, including ensuring built-in security measures are included and enabled by default, which often depends on secure coding. ISM-2042 additionally emphasises default configuration and productised security features, which Annex A 8.28 does not explicitly address.
This control supports ISM-0402.
Annex A 8.28 requires secure coding principles to be applied to prevent vulnerabilities during software development. ISM-0402 supports this by mandating comprehensive vulnerability testing (SAST/DAST/SCA) prior to releases and periodically, which helps detect when secure coding practices were missed or incorrectly implemented. ISM-0402 is testing-focused and does not itself require secure coding practices to be followed in day-to-day development.
This control supports ISM-2062.
ISM-2062 requires unit and integration testing (positive and negative cases) to validate code quality and security. This supports ISO/IEC 27001:2022 Annex A 8.28 by providing a verification mechanism to demonstrate that secure coding principles are correctly implemented and that security-relevant behaviour holds under expected and misuse conditions. Annex A 8.28 focuses on the coding practices themselves, while ISM-2062 focuses on the testing evidence that those practices are effective.
This control depends on ISM-1924.
ISM-1924 requires organisations to build AI applications that can identify and mitigate adversarial prompt content (e.g. injection strings, malicious suffixes) at the point of use. Annex A 8.28 is a prerequisite because secure coding practices are typically needed to implement robust input validation, policy enforcement, guardrails, and safe prompt-handling patterns without introducing bypasses. Annex A 8.28 is broader across all software development, while ISM-1924 is a specialised secure-by-design requirement for generative AI prompt interfaces.
This control depends on ISM-2037.
Annex A 8.28 requires secure coding principles to be applied in software development. ISM-2037 requires developers who lack sufficient cyber security knowledge to undertake training on secure software development and programming practices, which is a prerequisite to consistently implementing secure coding in practice. Without the capability uplift in ISM-2037, effective fulfilment of Annex A 8.28 is less achievable and harder to sustain.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 27001 training
Mindset Cyber runs PECB-accredited ISO/IEC 27001 training that maps directly to the controls in this library.