ISO 27001 A.8.28: Secure coding
What This Control Requires
Secure coding principles shall be applied to software development.
In Plain Language
New in ISO 27001:2022, this control zooms in specifically on coding practices. While A.8.25 covers the overall secure development lifecycle, this one is about what happens at the keyboard - the practices that prevent injection flaws, XSS, buffer overflows, insecure deserialisation, and authentication weaknesses from making it into your codebase in the first place. The logic is simple: it is far cheaper to prevent a vulnerability during coding than to find it during testing or, worse, in production. Secure coding standards give developers clear guardrails, and automated tooling catches the rest. Auditors will want to see defined coding standards for your languages and frameworks, evidence that developers have been trained on them, and proof that compliance is checked through code review and automated SAST scanning.
How to Implement
Define secure coding standards for each programming language and framework your team uses. Base them on OWASP Secure Coding Practices and language-specific guides (CERT standards for C/C++, Java, Python, etc.). The critical practices: Input validation - validate everything on the server side. Use allowlists, not blocklists. Check data type, length, range, and format. Reject invalid input outright rather than trying to clean it up. Output encoding - encode output based on context (HTML, URL, JavaScript) to prevent XSS. Use templating engines with auto-escaping turned on by default. Parameterised queries - use prepared statements for every database query. Never concatenate user input into SQL strings. This single practice eliminates SQL injection. Authentication and session management - use established frameworks, not custom implementations. Generate secure, random session identifiers. Enforce session timeouts and regenerate session IDs after login. Cryptography - use well-tested libraries, never roll your own. Follow your organisation's cryptographic standards. Never hard-code secrets or keys in source code. Error handling - catch all error conditions. Log enough detail for debugging but show generic messages to users. Never leak stack traces, database errors, or internal paths. Verification - integrate SAST tools into your workflow and CI/CD pipeline. Configure rules that match your coding standards. Require code reviews with a security focus. Use pre-commit hooks to catch common issues before they even reach the repository. Train your developers on secure coding. Make it language-specific and practical - exercises, code review examples, security challenges. Track completion and build competency over time.
Evidence Your Auditor Will Request
- Documented secure coding standards for each programming language in use
- SAST tool configuration and scan results from CI/CD pipeline
- Secure code review records and findings
- Developer secure coding training records
- Examples of secure coding practices applied in recent projects
Common Mistakes
- No defined secure coding standards for the programming languages used
- Developers have not received secure coding training
- SAST tools are not integrated into the development workflow
- Code reviews do not include a security focus
- Hard-coded secrets are present in source code repositories
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| SOC 2 | CC8.1 | Related |
| NIS2 | Art.21(2)(e) | Partial overlap |
Frequently Asked Questions
Is this control new in ISO 27001:2022?
What are the most important secure coding practices?
Track ISO 27001 compliance in one place
AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.
Start Free Assessment