Control Definition
The organization must apply secure coding principles to software development — establishing an organization-wide baseline for how code is written and applying it before, during, and after coding, covering new code, reused code, and code obtained from third parties.
Control Objective
To ensure software is written so that vulnerabilities are prevented at the point of creation rather than discovered and patched after release.
What This Really Means
There is an old manufacturing maxim: you cannot inspect quality into a product — it has to be built in. Security testing, scanning, and patching all inspect; secure coding builds in. Every vulnerability that ships started life as a line of code written under deadline pressure, and the cheapest place to kill it is at the keyboard where it was born. A.8.28 makes that discipline an explicit, auditable expectation.
This control is one of the 11 controls added in the 2022 revision of ISO 27001 — it did not exist as a standalone requirement in the 2013 Annex A, where coding practice was only implied inside broader secure-development controls. The transition deadline for 2013-era certificates passed on 31 October 2025, so every current certificate must now address secure coding directly. Auditors know it is new and probe it specifically: mapping it to your old SDLC policy and assuming coverage is the most common transition mistake.
What the control actually asks for spans the whole arc of writing software. Before coding: a documented organizational coding standard anchored to recognized references — OWASP Top 10 and ASVS for web, plus language-specific guidance — along with expectations that developers understand the design, the data sensitivity, and which vetted components to use. During coding: input validation, output encoding, parameterized data access, centralized authentication and authorization, error handling that fails safely without leaking internals, logging that excludes secrets and personal data, and credentials kept in a vault rather than in source. After coding: peer review with a security lens, static analysis, and ongoing maintenance of what was shipped. Crucially, the scope includes code you did not write — open-source libraries, outsourced components, and increasingly AI-generated code all need rules, because your systems inherit their flaws either way.
When auditors assess A.8.28, the heart of it is whether the standard lives in the development workflow or on a shelf. A written, language-relevant coding standard is the entry ticket; the real evidence is pull-request reviews that reference it, pipeline gates that can actually fail a build, secret scanning that blocks a commit, training records for developers, and a managed dependency inventory. A tool license proves nothing on its own.
Why It Matters
The same code-level flaw classes have dominated breach reports for two decades. Injection, broken access control, and unsafe handling of untrusted input persist at the top of the OWASP Top 10 edition after edition — not because they are hard to prevent, but because prevention has to happen consistently across every developer, every sprint, every repository. A flaw caught in code review costs minutes; the same flaw found in production costs an emergency change, an incident investigation, and — where personal data is involved — a regulatory notification.
The economics have also shifted under the control's feet. A modern codebase is mostly other people's code: open-source dependencies typically dwarf first-party code by volume, and AI coding assistants now generate a meaningful share of what gets committed. Secure coding has therefore become a governance problem about inputs — which libraries you adopt, how assistant output is reviewed, how secrets stay out of repositories — not just a typing-discipline problem for individual developers.
When secure coding is left to individual habit:
- •Injection and access-control flaws in production – missing parameterization or per-endpoint authorization checks become exploitable the day they ship, and attackers scan for them continuously
- •Secrets in source control – hardcoded keys replicate across clones, forks, and CI caches; rotating an exposed credential after the fact is painful and almost always incomplete
- •Silently inherited vulnerabilities – unmanaged transitive dependencies ship Log4Shell-class flaws into your product without any of your developers writing a vulnerable line
- •AI-amplified defects – assistant-generated code merged without scrutiny reproduces insecure patterns at the speed of autocomplete, with authorization logic the most common casualty
- •A guaranteed audit probe – as a control new in 2022, auditors specifically test whether anything actually changed in your development practice, not whether an old policy paragraph mentions coding
Regional Compliance Context
For Indian organizations, secure coding failures escalate from engineering problems to regulatory ones quickly. A code-level flaw that exposes digital personal data is a personal data breach under the DPDP Act 2023, carrying notification obligations to the Data Protection Board and affected individuals — and CERT-In directions separately require many incident types on India-connected systems, including data breaches, to be reported within 6 hours. An injectable endpoint is not just a bug; it is a regulatory clock waiting to start.
RBI-regulated entities and SEBI market intermediaries face an additional layer: their respective directions and the CSCRF expect application security and secure development practices to be embedded and evidenced, so A.8.28 work does double duty in those examinations.
Implementation Guidance
Adopt an Organizational Secure Coding Standard
Write a coding standard owned by your engineering or application security lead, anchored to recognized references — OWASP Top 10 and ASVS for web applications, plus language- and framework-specific guidance for your actual stack. Keep the core document short and add per-language annexes. Store it in the repository where developers work, version it, and review it annually.
Set Expectations Before Coding Starts
Make security part of planning, not a post-merge surprise: stories touching authentication, payments, or personal data get explicit security notes; developers confirm input sources, authorization context, and data classification before writing code. Maintain an approved-components list so framework and library choices are made from vetted options. Threat intelligence from A.5.7 should inform which attack patterns your standard emphasizes.
Mandate Core During-Coding Practices
Codify the non-negotiables: validate all input at trust boundaries, encode output for its context, use parameterized queries or safe ORMs, route authentication and authorization through central components rather than per-endpoint reimplementation, fail closed with error messages that reveal nothing internal, and keep secrets in a vault — never in source, config files, or logs. Enforce mechanically where possible with linters and pre-commit secret scanning.
Enforce Review and Static Analysis Gates
Require peer review on every change, with a security-focused checklist for risky areas (authentication, session handling, file uploads, query construction). Run SAST in the CI pipeline on every change and block merges on agreed severity thresholds. Start with a small, high-confidence ruleset and tune quarterly — a gate that fails builds occasionally and credibly beats an encyclopedic one everyone ignores.
Govern Third-Party and Open-Source Components
Run software composition analysis (SCA) in the pipeline to flag known-vulnerable and license-problematic dependencies. Pin versions with lockfiles, automate update proposals with a dependency bot, and define adoption criteria for new libraries — maintenance health, provenance, and known-vulnerability history. Record exceptions with risk acceptance and an expiry date when a vulnerable dependency cannot be upgraded immediately.
Set Rules for AI-Assisted and Generated Code
Treat coding-assistant output as untrusted input: it goes through the same review, testing, and pipeline gates as human-written code, with extra attention to authorization logic and input handling where assistants most often go wrong. Define which tools are approved, and prohibit pasting secrets, personal data, or sensitive proprietary code into unapproved external services. Put these rules in the coding standard so they are auditable, not folklore.
Train Developers and Measure Adherence
Include secure coding in developer onboarding and refresh it at least annually, using hands-on, language-specific material rather than generic awareness slides. Track signals that the standard is alive: the share of builds clearing SAST gates, review coverage on risky changes, secret-scanning hits trending down, dependency-update lag. Feed recurring flaw classes from reviews, tests, and incidents back into the standard and the training.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.28:
Documentation
- Secure coding standard with language- and framework-specific sections, version history, and owner
- CI pipeline configuration showing SAST, secret-scanning, and SCA gates with blocking thresholds
- Pull-request records sampling security-relevant changes with completed reviews and checklist use
- SCA and dependency-management reports with remediation tracking and documented exceptions
- Developer secure-coding training records and onboarding checklist entries
Interviews
- Engineering lead or development manager about how the standard is enforced and what blocks a merge
- Developers, sampled, about the secure coding practices they apply daily and where the standard lives
- Application security owner about how findings from tools and reviews are triaged and fed back
Observations
- A live walkthrough of a recent pull request showing review, pipeline checks, and gate outcomes
- A repository inspection demonstrating secret scanning in force and dependencies pinned via lockfiles
- The SAST/SCA dashboard showing open findings, their ages, and the remediation trend
Practitioner Insights
The most common A.8.28 failure pattern I see: the organization buys a static analysis tool, wires it into the pipeline, and declares secure coding done. Then you open the dashboard and there are four thousand findings, untouched since the day the tool was installed, and no build has ever been blocked. A tool is not a control — the control is the standard, the gate, and the habit of treating findings like defects. A small tuned ruleset that genuinely fails builds is worth more than the most expensive scanner running in warning-only mode.
Because secure coding is new in the 2022 revision, I treat it as a transition probe: organizations map A.8.28 to their old secure development policy and assume they are covered. Two questions expose the gap quickly — show me the coding standard the developer you hired last quarter was trained on, and show me a change that failed a security gate and what happened next. If no merge has ever been blocked, the gate is decorative. And remember the scope: your certificate covers the code you ship, not just the code you write, so third-party libraries and AI-generated code need documented rules too.
Common Challenges & Solutions
Challenge
The secure coding standard exists but developers treat it as shelfware nobody reads.
Solution
Move the standard to where developers live: keep it in the repository, link it from pull-request templates, and encode as many rules as possible into linters and pipeline checks so the standard executes itself. Cut the prose to what cannot be automated. A ten-page document enforced by tooling beats a fifty-page document enforced by hope.
Challenge
Static analysis produces thousands of findings, mostly noise, and the team tunes it out.
Solution
Shrink the ruleset to high-confidence, high-impact categories first — injection, hardcoded secrets, unsafe deserialization — and block builds only on those. Triage the legacy backlog separately with a time-boxed plan instead of mixing it into daily development. Expand coverage quarterly as false-positive rates prove acceptable, and record tuning decisions so auditors see deliberate calibration rather than suppression.
Challenge
Most of the codebase is open-source dependencies the team has no direct control over.
Solution
You cannot control upstream code, but you can control adoption and currency: SCA scanning in CI, pinned versions with lockfiles, an automated dependency-update bot, and written criteria for accepting a new library. For vulnerable dependencies that cannot be upgraded immediately, record a formal exception with compensating controls and an expiry date — silent acceptance is what auditors penalize.
Challenge
AI coding assistants generate code faster than reviewers can scrutinize it.
Solution
Write the rule down: assistant output is a draft that goes through the same review, tests, and gates as any other code, with reviewers explicitly checking authorization context and input handling, which assistants routinely get wrong. Approve specific tools, and ban secrets and sensitive proprietary code from unapproved external services. Pair the policy with secret scanning and SAST so the pipeline catches what reviewer attention misses.
Challenge
A large legacy codebase predates the standard and cannot be retrofitted overnight.
Solution
Take a documented, risk-based position: the full standard applies to all new and modified code, while legacy remediation is prioritized from your threat model — externally exposed paths and authentication flows first. The boy-scout rule (leave touched code compliant) steadily shrinks the gap. Auditors accept a deliberate, recorded plan; what they do not accept is an undefined boundary between covered and uncovered code.
