ISO 27001 A.8.28: Make secure coding an everyday practice

What A.8.28 requires in practice

Annex A control A.8.28 states that secure coding principles should be applied to software development. It is the most hands-on of the development controls: it concerns what developers actually do when they write and maintain code.

For an organisation, this means deciding what secure coding looks like for the languages, frameworks and environments in use, and making sure developers know and follow it. General instructions to be careful are not enough; guidance needs to address matters such as handling of input, credentials, permissions, errors and third-party components. The principles also need to reach contributors who write code on the organisation's behalf.

The outputs are current coding guidance suited to the technology, developer competence supported by learning and review, and a repeatable way to find, correct and learn from weaknesses. Applicability follows risk treatment and the Statement of Applicability, and specialist technical judgement remains necessary for coding decisions.

Give developers guidance they can use

Establish relevant expectations for the languages, frameworks and environments actually used. General instructions to write secure code are insufficient when developers need to decide how to handle input, credentials, permissions, errors or external components. Use current, suitable technical guidance and maintain it as the environment changes.

Support developers with training and practical review. A document is unlikely to improve implementation if the team cannot recognise the relevant failure modes. Include outsourced contributors where they write code for the organisation, and ensure that internal reviewers understand the expectations they are meant to assess.

Use protective patterns consistently

Choose approved approaches for recurring security functions, rather than allowing each developer to improvise a separate solution. Authentication, cryptography and other sensitive functions warrant particular care. Reused components need an appropriate source, version and maintenance decision; using an external library does not remove the need to understand its role and limitations.

Connect this with source-code access and vulnerability management. Code integrity and component maintenance support secure implementation, but neither replaces review of the application's own logic and information-handling decisions.

Why secure coding matters to the business

Many security incidents trace back to avoidable coding weaknesses. Each one that reaches production creates an urgent fix, potential customer exposure and a reputational cost out of proportion to the original mistake. Teams that build secure habits ship more reliably and spend less time on emergency patches. The benefit extends to commercial relationships: customers who rely on the software, or who embed it in their own products, increasingly ask how code is reviewed and developers are trained. At audit, observable coding practice shows that security is part of the craft, supported by competence rather than dependent on one expert.

How to implement A.8.28

Aim for guidance developers will actually use, supported by routine checks. A workable sequence is below. Involve experienced developers in writing the rules, because guidance created without them is seldom followed. Keep the rules short, concrete and tied to the technology in use, and let one pilot project show whether they work in practice before wider rollout.

1. Identify the languages, frameworks and environments in use, including those used by contractors.
2. Select suitable current technical guidance for each and adapt it into short rules the team can apply.
3. Cover the recurring decision points: input handling, credentials, permissions, error handling and external components.
4. Train developers on the failure modes behind the rules, using examples from your own code.
5. Build review into normal work so peers or tools check changes against the rules.
6. Record significant findings, correct them and share the lesson.
7. Keep the guidance up to date as the technology and threats change.
8. Extend expectations to outsourced contributors in the agreement and check delivered code.

Evidence an auditor expects for A.8.28

An auditor looks for coding practice that is current, understood and checked. Evidence may include: An auditor may also ask a developer to talk through a recent change and show where the rules affected it.

• the coding guidance for each technology in use, with its last review
• records of developer learning or briefing
• samples of code review records showing findings and corrections
• an interview with a developer on how credentials or input are handled
• observation of a recent change moving through review

Evidence for outsourced code carries equal weight.

Common nonconformities with A.8.28

Findings typically show guidance that is generic, outdated or unchecked. They usually arise because guidance was written once, and nobody tested whether developers use it, so an auditor tends to ask a developer to demonstrate how a recent change handled input or secrets.

• Coding guidance generic enough to apply to nothing in particular.
• Developers unable to describe how the rules apply to their own work.
• Code review that exists in name with no records of findings or corrections.
• Credentials or sensitive settings handled inconsistently across projects.
• Outsourced contributors outside the rules.

Illustrative software example: a secret embedded for convenience

Illustrative BPO example: unexpected input in a reconciliation script

A hypothetical BPO team maintains a script that processes files from an approved customer workflow. The author assumes the input always has the expected structure. A changed file format causes incorrect handling, and the resulting output appears complete even though some records were not processed as intended.

The team defines appropriate input checks and error handling for the business purpose, then tests representative valid and invalid conditions with safe sample data. Reviewers confirm that failures are visible to the responsible operator. This illustrates secure coding as protection of integrity and dependable behaviour, not merely a search for externally exploitable flaws.

Review code and test its behaviour

Use appropriate review and testing methods for the risk and complexity. Automated analysis can help identify some classes of issue, while informed review can assess context and business logic. Neither method should be treated as proof that no weakness remains. Record how relevant findings are assessed and resolved.

Connect checks with security testing in development and acceptance. Test important protections under expected and unexpected conditions. Review the resulting behaviour, not just whether a tool completed its run. Maintain suitable control over changes so a corrected pattern is not reintroduced through an old branch or copied example.

Keep secure coding active after release

Operational experience can reveal weaknesses that development checks missed. Establish a route from reported defects, relevant vulnerabilities and incidents back to the coding practices that need improvement. Review whether an issue affects other parts of the application or reused components, rather than assuming its first occurrence is unique.

Useful evidence includes relevant coding guidance, competence activities, review records, test outcomes and correction of significant findings. These are practical evidence methods, not a mandatory collection of separate forms. A meaningful sample follows a coding concern from identification through correction and verification, then asks whether the team learned anything that changes future work.

Common failures include obsolete guidance, unreviewed copied code and treating a clean automated scan as comprehensive assurance. Use competence planning to address recurring skill gaps. Secure coding works best when it is part of daily development and maintenance, rather than a specialist exercise performed only before an audit.