Vulnerable code ships to production every day. When it does, attackers exploit injection flaws, harvest hard-coded credentials, and walk through gaps that no firewall can close. The consequences hit from every direction — data breaches that trigger regulatory notification, audit nonconformities that stall certification, and reputational damage that lingers long after the patch lands. ISO 27001 Control 8.28 exists to break that cycle by embedding secure coding practices directly into the way software gets built.
What 8.28 Requires
ISO 27001 8.28 is a technological control introduced in the 2022 revision of the ISO 27001 standard. It requires organizations to establish, document, and enforce secure coding practices across all software development activities. There is no predecessor in ISO 27001:2013 — this is an entirely new control added because the standard’s authors recognized that most exploitable vulnerabilities originate in code, not infrastructure.
The control applies to both internal development teams and outsourced development engagements. Organizations must define secure coding standards, embed those standards into every phase of the software development lifecycle (SDLC), and verify that code meets them before it reaches production.
8.28 spans three phases. In planning and pre-coding, organizations define coding standards, select approved frameworks, and establish minimum security baselines. During active coding, developers apply input validation, output encoding, secure authentication patterns, and proper error handling — while peer review and automated analysis verify compliance in real time. In post-deployment maintenance, the organization monitors for newly disclosed vulnerabilities in its codebase and third-party dependencies, then patches within defined SLAs.
The practical effect is straightforward: if your organization writes, commissions, or integrates software, 8.28 requires you to prove that security is a design constraint — not an afterthought applied during annual penetration testing.
Why 8.28 Matters
Consider a common scenario. An organization deploys a customer-facing application without validating user inputs. An attacker identifies the gap, crafts a SQL injection payload, and exfiltrates thousands of customer records. The incident triggers a mandatory breach notification under GDPR, a major nonconformity finding at the next surveillance audit, and months of remediation work — all because a single coding practice was missing from the development workflow.
This is not a hypothetical edge case. Application-layer vulnerabilities remain the primary attack vector for web-facing systems. The OWASP Top 10 2025 edition lists Broken Access Control as the number-one risk category, affecting 3.73% of applications tested. According to IBM’s 2025 Cost of a Data Breach report, the global average cost of a data breach reached $4.88 million, and organizations that identified third-party software vulnerabilities as the initial attack vector faced some of the longest containment timelines.
Control 8.28 addresses this reality directly. Rather than relying solely on perimeter defenses or post-deployment scanning, it pushes security left into the development process itself — where fixing a vulnerability costs a fraction of what it costs after release.
What attackers exploit
When secure coding controls are absent, attackers target predictable weaknesses:
- Unvalidated user inputs — enabling SQL injection, command injection, and path traversal attacks
- Hard-coded credentials and secrets — exposed in source code repositories, configuration files, or build artifacts
- Unpatched third-party libraries — open-source dependencies with known CVEs that remain in production
- Missing output encoding — creating cross-site scripting (XSS) vulnerabilities
- Absent or superficial code review — allowing insecure patterns to pass unchallenged into the main branch
- No SAST or DAST in the CI/CD pipeline — meaning vulnerabilities are only discovered during infrequent manual testing
- Insecure error handling — leaking stack traces, internal paths, or database structure to end users
How to Implement 8.28
For your organization (first-party)
Implementing 8.28 requires integrating secure coding into your existing development workflow, not building a parallel compliance process.
Step 1: Define secure coding standards. Document your organization’s coding standards with explicit references to established frameworks — OWASP Top 10, CERT Secure Coding Standards, or the CWE Top 25. Include language-specific guidelines for every technology stack in use.
Step 2: Embed standards into developer workflows. Secure coding rules should be visible where developers work. Configure IDE linting rules to flag insecure patterns. Add security criteria to pull request review checklists and your Definition of Done. If a developer can merge code without a security review, the standard is not embedded.
Step 3: Integrate automated security testing. Add static application security testing (SAST) to your CI/CD pipeline so every build is scanned. Supplement with software composition analysis (SCA) to identify vulnerabilities in third-party libraries. These tools should block merges when critical findings are detected, not just generate reports.
Step 4: Train developers. Secure coding training must be ongoing, not a one-time onboarding activity. Track completion by date and topic, and retain evidence — auditors will ask for it.
Step 5: Establish vulnerability triage and patching SLAs. Define severity-based response timelines. Critical vulnerabilities in production code need a documented maximum time-to-patch, with escalation paths when SLAs are at risk.
Step 6: Monitor post-deployment. Log and review security events in production. Subscribe to vulnerability advisories for your dependency stack. Secure coding does not end at deployment.
Evidence to produce: Secure Coding Policy, training records, SAST scan reports, code review logs, dependency inventory (Software Bill of Materials), vulnerability tracking records.
Common mistakes:
- Writing a secure coding policy that is never enforced in the build pipeline
- Running SAST only before annual audits instead of on every build
- Ignoring third-party library vulnerabilities because “it’s open source”
- Treating secure coding training as a one-time onboarding checkbox
- Hard-coding secrets in configuration files and relying on .gitignore for protection
For your vendors (third-party assessment)
When outsourcing development or integrating third-party software, 8.28 compliance extends to your supply chain. A structured vendor security review process helps verify that external development partners meet your secure coding requirements.
Questionnaire questions to ask:
- Do you maintain documented secure coding standards?
- What SAST and DAST tools are integrated into your pipeline?
- How do you manage open-source dependencies and track known vulnerabilities?
- What is your patching SLA for critical vulnerabilities?
Evidence to request: Secure coding policy, recent SAST/DAST scan summaries, software bill of materials (SBOM), developer training completion rates.
Red flags: A vendor that cannot name their secure coding standard, has no automated security testing in their pipeline, produces no SBOM or dependency tracking, or relies solely on annual penetration testing for security validation.
Verify beyond self-attestation. Request a SOC 2 Type II report or ISO 27001 certificate. Understanding your ISO 27001 third-party risk requirements helps you define what evidence to demand. Ask for a recent penetration test executive summary. Review their vulnerability disclosure process. Self-assessment questionnaires tell you what the vendor claims; independent evidence tells you what they actually do.
Audit Evidence for 8.28
Auditors assessing 8.28 expect both policy-level documentation and operational evidence that secure coding practices are active, not just defined.
| Evidence Type | Example Artifact |
|---|---|
| Policy | Secure Coding Policy defining coding standards, approved frameworks, and review requirements |
| Standards reference | Documented adoption of OWASP Top 10 or equivalent with language-specific guidelines |
| Training records | Developer secure coding training completion certificates with dates and topics |
| SAST reports | Automated static analysis scan results from CI/CD pipeline showing findings and remediation |
| Code review logs | Pull request review records showing security-focused review comments and approvals |
| Dependency inventory | Software Bill of Materials (SBOM) listing all third-party libraries and their vulnerability status |
| Vulnerability tracking | Issue tracker records showing security defect triage, SLA compliance, and closure |
| Penetration test results | Application penetration test report with findings mapped to coding practices |
The key distinction auditors look for is evidence of continuous practice versus one-time compliance activity. Proper ISO 27001 audit preparation ensures these artifacts are current and accessible when the auditor arrives. A SAST report from two weeks ago carries more weight than a penetration test from eleven months ago.
Cross-Framework Mapping
Control 8.28 aligns with secure development requirements across multiple regulatory and industry frameworks. The table below maps equivalent controls.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | SA-04(03) — Development Process, Product, and Acquisition Information System Security Engineering | Full |
| NIST 800-53 | SA-08 — Security and Privacy Engineering Principles | Full |
| NIST 800-53 | SA-10 — Developer Configuration Management | Full |
| NIST 800-53 | SA-11(01) — Developer Testing and Evaluation: Static Code Analysis | Full |
| NIST 800-53 | SA-15(05) — Development Process, Standards, and Tools: Attack Surface Reduction | Full |
| SOC 2 | CC8.1 — Change Management | Partial |
| CIS Controls v8.1 | 16.1–16.14 — Application Software Security | Full |
| NIST CSF 2.0 | PR.DS (Data Security), PR.IP (Protective Technology) | Partial |
| DORA (EU) | Article 7 — ICT Risk Management, Secure Development | Partial |
Organizations pursuing multiple certifications can use 8.28 implementation evidence to satisfy overlapping requirements, reducing duplicate ISO 27001 compliance effort.
Related ISO 27001 Controls
Control 8.28 does not operate in isolation. It connects to several other Annex A controls that together form a complete secure development capability.
| Control ID | Control Name | Relationship |
|---|---|---|
| 8.25 | Secure development lifecycle | Provides the SDLC framework that 8.28 operates within |
| 8.26 | Application security requirements | Defines the security requirements code must satisfy |
| 8.27 | Secure system architecture and engineering | Sets architectural constraints that guide coding decisions |
| 8.29 | Security testing in development and acceptance | Validates that 8.28 coding practices are effective |
| 8.8 | Management of technical vulnerabilities | Handles vulnerabilities discovered in deployed code |
| 8.9 | Configuration management | Ensures secure build and deployment configurations |
| 8.31 | Separation of development, test, and production | Prevents untested code from reaching production |
| 6.3 | Information security awareness and training | Covers secure coding training requirements |
Frequently Asked Questions
What is ISO 27001 8.28?
ISO 27001 8.28 is a technological control requiring organizations to apply secure coding standards and practices throughout software development. Introduced in the 2022 revision of ISO/IEC 27001, it has no predecessor in the 2013 version. The control covers the full development lifecycle — from pre-coding standards definition through active development to post-deployment maintenance — and applies to both in-house and outsourced development.
What happens if 8.28 is not implemented?
Without secure coding controls, vulnerabilities like injection flaws, hard-coded credentials, and unpatched dependencies enter production code unchecked. This expands the organization’s attack surface, increases the likelihood of a data breach, and creates a clear audit nonconformity that can delay or block ISO 27001 certification. The downstream costs — incident response, regulatory notification, and customer attrition — far exceed the investment required to implement the control.
How do you audit 8.28?
Auditors verify 8.28 by reviewing documented secure coding standards, SAST scan evidence from the CI/CD pipeline, code review records, and developer training logs. They look for proof that practices are continuous — not just artifacts produced before the audit. Expect questions about how vulnerabilities are triaged, how third-party dependencies are tracked, and whether security testing blocks deployment when critical findings are present.
How UpGuard Helps
Secure coding reduces vulnerabilities at the source — but you still need visibility into the risks that reach your external attack surface. UpGuard Breach Risk continuously monitors your organization’s internet-facing assets for exposures that insecure coding practices create, helping you identify and remediate vulnerabilities before attackers find them.