ISO 27001 A.8.28 - Secure Coding

Requirement

Requirement lens

This control asks whether secure coding principles are applied when software is developed.

“Secure coding principles shall be applied to software development.”

Plain-language meaning

Developers should follow secure coding standards that fit the languages, frameworks, tools, and risk level of the software being built. The standard should explain both general principles and specific coding rules that reduce common weaknesses.

Secure coding is more detailed than A.8.25 Secure Development Life Cycle. A.8.25 sets the lifecycle expectation; A.8.28 checks whether actual coding follows secure principles.

Why this matters

Most application vulnerabilities are created during design and coding. Secure coding standards reduce repeated mistakes such as hard-coded secrets, injection weaknesses, insecure memory handling, poor error handling, weak cryptographic use, unsafe dependencies, insecure deserialization, and missing authorization checks.

Secure coding standards also make AI-generated or automatically generated code easier to review. Generated code is not trustworthy just because it compiles.

Implementation guidance

Implementer focus

Pick standards developers can actually use. A generic policy is not enough for language-specific risks.

1. Identify coding scope

List where coding happens inside the ISMS scope, including internal development, scripts, APIs, infrastructure-as-code, database logic, macros, low-code extensions, supplier code, and AI-generated code.

2. Select secure coding standards

Use language, framework, and risk-specific standards. High-security code should have stricter rules than low-risk internal automation.

3. Make standards available and usable

Developers and reviewers should know which standard applies, where to find it, and what to do when legacy constraints prevent full compliance.

4. Use automated and manual checks

Static analysis, linting, secret scanning, dependency scanning, and secure code review can verify compliance. Automated checks help but cannot replace competent review.

5. Manage exceptions

Exceptions should be documented, risk-assessed, approved, and reviewed. Legacy constraints should not become permanent undocumented bypasses.

Audit guidance

Auditor focus

Start by finding where coding actually happens. Then check whether each coding context has applicable standards, trained users, compliance checks, and exception handling.

Auditors should verify:

coding activities in ISMS scope are identified;
risks of coding activities are assessed;
secure coding standards are selected for each language/context;
standards are documented and accessible;
coders know which standard applies to their work;
automated compliance tools are used where appropriate;
internal audit or technical review verifies coding practices;
exceptions are defined and approved;
third-party coding follows equivalent requirements.

Auditors should interview developers and reviewers, not only managers. Ask them to show the applicable standard and explain how they apply it.

Evidence examples

Evidence quality

Strong evidence proves secure coding standards are selected, known, applied, checked, and exceptions are managed.

Evidence	What it proves
Coding scope register	Coding activities are known
Secure coding standard	Rules are defined
Developer training records	Developers know expected practice
Static analysis/secret scan results	Automated checks are performed
Secure code review records	Human review checks security
Exception records	Constraints are risk-managed
Supplier coding requirements	Third-party code is covered

Strong evidence

Standards are language/framework-specific.
Developers can retrieve and explain applicable standards.
Automated checks run in CI/CD or release workflow.
Findings are reviewed and remediated.
AI-generated code is reviewed against the same standard.
Exceptions are risk-assessed and approved.

Weak evidence

One generic “write secure code” document.
Developers are unaware of the standard.
Static analysis exists but is not reviewed.
Findings are suppressed without approval.
AI-generated code is accepted without human review.
Third-party code is assumed secure.

Common failures

Implementation watchouts

A.8.28 fails when secure coding is treated as developer preference.

Failure	Why it matters
No language-specific standard	Common language flaws remain
No developer awareness	Standards are not applied
Tool-only review	Logic and design flaws are missed
Unmanaged exceptions	Legacy constraints become hidden risk
Supplier code unchecked	Third-party weaknesses enter production
AI code trusted blindly	Generated insecure patterns are accepted

Exam traps

Exam focus

A.8.28 is about applying secure coding principles. It is narrower and more code-specific than A.8.25.

Trap	Correct interpretation
Secure SDLC and secure coding are the same	A.8.25 is lifecycle rules; A.8.28 is coding principles
Automated tools prove secure coding	Tools support verification but do not replace standards and review
One generic standard fits all code	Language, framework, and risk context matter
AI-generated code is inherently safer	Generated code still needs secure review
Legacy constraints justify informal bypass	Exceptions should be documented and approved

KB-ready summary

Mentor takeaway

A.8.28 makes secure coding concrete. Strong implementation proves coding contexts are known, standards are language/risk appropriate, developers know them, tools and reviews check them, and exceptions are controlled.

Identify coding activities.
Select language and risk-specific standards.
Train developers and reviewers.
Use automated and manual checks.
Manage exceptions and generated code carefully.

Templates and checklists

Iso27001
Iso27002
Annex a
Technological controls
Secure coding
Secure development
Audit

Note Metadata

Aliases: A.8.28, Secure Coding

Source: 05 Annex A Technological Controls/A.8.28 Secure Coding.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

links

Control

ISO 27001 A.8.28 - Secure Coding

Requirement context

Primary control text, framework notes, or adjacent controls this note points to.

Implementation artifacts

Templates and working records that help operate the control.

Evidence required

Evidence packs and proof records that support auditability.

A.8.28 Audit Evidence Pack

Audit checks

Audit questions, checklists, or review material connected to the control.

A.8.28 Audit Checklist

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.