Category: Technical Security Controls

Secure Coding Control (8.28)

Also known as: Secure Coding, Annex A 8.28, Control 8.28

Simply put

Secure coding is a reference control that addresses building security into software during development, so that common coding weaknesses are avoided rather than fixed after the fact. It is identified as control 8.28 in the reference control set introduced by the ISO/IEC 27001:2022 revision, where Annex A controls are organized into four themes. This control is not automatically required; like other Annex A controls, it is selected for an organization based on risk assessment and documented in the Statement of Applicability.

Formal definition

Secure Coding (numbered 8.28 in the Annex A reference control set of the ISO/IEC 27001:2022 revision, which restructured Annex A into four themes) is a reference control aimed at establishing and applying secure coding principles across the software development lifecycle to reduce the likelihood of security vulnerabilities in developed or acquired code. As an Annex A control, it functions as a candidate control informed by the organization's risk assessment and is included or excluded through the Statement of Applicability rather than being mandated in every ISMS; the certifiable requirements themselves reside in clauses 4 through 10. Implementation typically spans planning, pre-coding standards, coding practices, and post-coding review activities, with the specific measures and their applicability depending on scope and the organization's risk decisions. Note that the detailed implementation guidance associated with this control is elaborated in ISO/IEC 27002, which is a guidance standard distinct from the certifiable ISO/IEC 27001 requirements; control numbering and counts should always be qualified by the applicable edition, since these differ between the 2013 and 2022 versions.

Why it matters

Software vulnerabilities introduced during development are frequently more costly and disruptive to remediate after code has been deployed than to prevent while code is being written. Secure Coding (8.28) matters because it shifts the emphasis toward building security into software throughout the development lifecycle, so that common coding weaknesses are avoided at the source rather than patched reactively once they reach production. For organizations whose risk assessment identifies software development as a meaningful source of exposure, applying secure coding principles can reduce the likelihood that exploitable defects are shipped in developed or acquired code.

Within an ISO/IEC 27001:2022 information security management system, this control is not automatically mandatory. Like other Annex A reference controls, it is a candidate control that an organization selects, or excludes, based on its risk assessment and documents in the Statement of Applicability. Its relevance therefore depends on scope: an organization that develops or acquires software is far more likely to determine that this control applies than one that does not. Where it is selected, it provides a structured basis for consistent coding practices rather than leaving security to the discretion of individual developers.

It is worth emphasizing what this control does and does not do. Selecting and applying Secure Coding (8.28) supports the reduction of vulnerabilities in code, but it does not by itself guarantee freedom from security defects or breaches, and its effectiveness depends on how the organization implements and maintains it. The control addresses one area of the broader ISMS and should be understood alongside the risk-driven selection of other Annex A controls.

Who it's relevant to

Software development and engineering teams

Teams that develop or acquire code are the primary audience for this control, since it addresses building security into software throughout the development lifecycle. Where the organization selects the control, developers are typically expected to work within established secure coding standards and practices across planning, coding, and review activities. The specific measures depend on scope and the organization's risk decisions.

ISMS and compliance managers

Those responsible for the information security management system decide, based on the organization's risk assessment, whether Secure Coding (8.28) applies and document that determination in the Statement of Applicability. They should be careful to qualify control numbering by edition, since Annex A differs between the 2013 and 2022 versions, and to distinguish the certifiable clause 4 to 10 requirements from the Annex A reference controls.

Auditors and certification bodies

Auditors assessing an ISO/IEC 27001 ISMS evaluate whether controls selected in the Statement of Applicability, including Secure Coding where applicable, are appropriately justified by the risk assessment and implemented as described. Because this control is not mandated in every ISMS, its inclusion or exclusion should be traceable to the organization's documented risk decisions rather than assumed.

GRC and security professionals mapping frameworks

Professionals aligning ISO/IEC 27001 with other frameworks should note that detailed implementation guidance for this control is elaborated in ISO/IEC 27002, a guidance standard distinct from the certifiable requirements. When comparing coverage across frameworks, mappings are typically partial, and satisfying a secure coding expectation in one context does not automatically satisfy the requirements of another.

Inside Secure Coding Control (8.28)

Annex A Control Reference (8.28)

Secure Coding is a reference control listed in Annex A of ISO/IEC 27001:2022, where it is numbered 8.28 within the restructured Annex A that organizes 93 controls into four themes. It is selected for applicability via the Statement of Applicability and informed by risk assessment rather than being universally mandatory.

Secure Coding Principles

The control addresses the application of secure coding practices across the software development lifecycle, aiming to reduce vulnerabilities introduced during development. The specific implementation depends on the organization's scope, technology stack, and risk profile.

Lifecycle Coverage

Secure coding considerations typically span planning, coding, review, and maintenance activities. The depth of coverage varies by organization and is shaped by the risks identified in the ISMS risk assessment.

Relationship to ISO 27002 Guidance

While Annex A of ISO 27001 states the control at a reference level, more detailed implementation guidance for secure coding is typically found in ISO/IEC 27002, which serves as a companion guidance standard rather than a certifiable requirement.

Common questions

Answers to the questions practitioners most commonly ask about Secure Coding Control (8.28).

Is secure coding a required control that every organization must implement to achieve ISO 27001 certification?

Not necessarily. Secure coding (identified as control 8.28 in the ISO/IEC 27001:2022 Annex A reference controls) is a reference control, not a mandatory ISMS requirement. Annex A controls are selected through the Statement of Applicability and informed by the organization's risk assessment. An organization that does not develop software may justify excluding or reducing the applicability of this control. The certifiable requirements are found in clauses 4 through 10, while Annex A provides reference controls that are applied depending on scope and identified risks.

Does having a secure coding control mean my code is guaranteed to be free of vulnerabilities?

No. Implementing a secure coding control supports the reduction of coding-related risks but does not guarantee that software is free of vulnerabilities. Like any control, it addresses the risks within its defined scope and depends on how consistently it is applied. An ISO 27001 certificate covers only the defined scope of the ISMS and attests that controls have been assessed against the standard's requirements; it does not warrant the absence of security defects or breaches.

How is secure coding typically incorporated into the software development lifecycle?

In most implementations, secure coding practices are applied across planning, development, and maintenance activities rather than at a single stage. Depending on scope, organizations often address secure coding principles before, during, and after coding, and may extend practices to third-party and open-source components. The specific approach varies with the technology stack, development methodology, and the risks identified during the organization's risk assessment.

What kinds of evidence might an auditor look for when reviewing this control?

Evidence typically depends on the certification body and the defined scope, but organizations often maintain documented secure coding standards or guidelines, records of developer training or awareness, and outputs from code review or testing activities. Auditors generally seek to confirm that the control operates consistently with the organization's stated approach and its Statement of Applicability. The exact expectations vary by auditor and engagement, so confirming specific evidence needs with the certification body is advisable.

How does secure coding relate to guidance in ISO 27002?

ISO 27002 provides implementation guidance for the reference controls listed in ISO 27001 Annex A, including secure coding. Organizations frequently consult ISO 27002 for practical detail on how a control such as this may be established and maintained. It is important to note that ISO 27002 is guidance and is not itself a certifiable standard; certification is assessed against ISO 27001.

How might secure coding practices be managed for third-party or open-source components?

Depending on scope, organizations often extend their secure coding approach to components they do not develop directly, such as third-party libraries and open-source dependencies. This may involve evaluating the security posture of external components and maintaining processes for identifying and addressing issues within them. The extent of these activities is typically determined by the organization's risk assessment and the boundaries defined in its Statement of Applicability.

Common misconceptions

Implementing secure coding control 8.28 is mandatory for every ISO 27001 certification.

Annex A controls, including 8.28, are reference controls selected through the Statement of Applicability and informed by risk assessment. An organization may justify exclusion of a control if it is not applicable to its defined ISMS scope, though secure coding is commonly relevant where software is developed.

The control number 8.28 applies across all versions of ISO 27001.

The 8.28 numbering and the four-theme structure reflect the 2022 revision of Annex A, which reduced the count from 114 controls in the 2013 version to 93. Control identifiers and groupings differ between editions, so the version should always be specified when citing this control.

Satisfying secure coding under ISO 27001 automatically satisfies equivalent SOC 2 expectations.

SOC 2 is a separate AICPA attestation examination evaluated against the Trust Services Criteria, not ISO 27001 Annex A controls. Mapping between the two frameworks is possible but partial, and meeting this ISO control does not automatically satisfy any SOC 2 criterion.

Best practices

Confirm applicability of control 8.28 through your risk assessment and document the decision in the Statement of Applicability, specifying the ISO 27001:2022 version when referencing the control.

Consult ISO/IEC 27002 for more detailed implementation guidance on secure coding, treating it as companion guidance rather than a certifiable requirement.

Integrate secure coding considerations across the development lifecycle in a manner proportionate to the risks identified for your defined ISMS scope.

Avoid assuming that secure coding practices demonstrated for ISO 27001 will directly evidence SOC 2 Trust Services Criteria, since mapping between the frameworks is only partial.

Maintain evidence of secure coding activities appropriate to how they will be evaluated, recognizing that specific expectations depend on the certification body, scope, and applicable risk decisions.

Review the control's implementation whenever scope, technology, or the underlying standard version changes, since control numbering and groupings differ across editions.