Secure coding

Plain-language summary

New in 2022: applying secure coding practices to any code your organisation writes — validating input, handling secrets and errors safely, reviewing code and using vetted libraries — so software does not ship with common, preventable vulnerabilities.

What the clause is really asking

Most exploited application flaws are old and well understood: injection, broken access checks, hard-coded passwords, unvalidated input, outdated libraries. This control, new in 2022, asks you to set secure coding principles and apply them before, during and after coding: planning (an agreed standard, approved tools and libraries, trained developers), writing (input validation, parameterised queries, least privilege, safe error handling, no secrets in code), review and testing (peer review, static analysis, dependency checks) and maintenance (updating libraries, fixing reported flaws). Like 8.25, it is commonly excluded by organisations that write no code, with a justification in the Statement of Applicability. Before excluding it, look for scripts, macros, low-code formulas that touch databases, and customisations of your website or ERP — a PowerShell script holding a domain admin password in plain text is a secure-coding failure. The common misunderstanding is that a modern framework or platform makes code secure on its own. The OWASP Top 10 and OWASP's Application Security Verification Standard are the usual reference points.

What auditors look for

Auditors check the Statement of Applicability and, if 8.28 is excluded, test the justification as for 8.25 by asking about scripts, macros and customisations. Where it applies, they ask for the secure coding standard and evidence that developers know it. They pick a recent change and look at the review record, static analysis or dependency scan results, and how findings were handled. They may search a repository or script folder for hard-coded credentials. They ask how third-party libraries are chosen and kept current. The hard question: when a critical vulnerability is announced in a library you use, how do you find every place it is used?

Typical evidence

Secure coding standard or adopted external guide; developer and script-author training records; code review records; static analysis and dependency scanning results with remediation; inventory of third-party libraries and components per application; secrets management approach and secret-scan results; Statement of Applicability justification where excluded; records of fixes for reported vulnerabilities.

How to comply — recommendations

If you write code, adopt an existing standard rather than writing your own — the OWASP Top 10 plus the first level of the Application Security Verification Standard cover most needs — and add a page of house rules: no secrets in code or scripts (use a vault or managed identity), parameterised queries, input validation, least privilege for service accounts. Require a second-person review before production. Switch on the static analysis, secret scanning and dependency alerts your code platform offers. Keep a library list per application. Train developers and script authors annually. If you write no code, record the justification and recheck it at management review.

Common nonconformities

No secure coding standard; hard-coded passwords or API keys in scripts and repositories; no code review before production; vulnerable or unsupported third-party libraries in use; static analysis tools available but unused or findings ignored; script authors never trained; exclusion from the SoA contradicted by in-house code; no record of libraries used.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.