When an auditor sits down for an ISO/IEC 27001:2022 surveillance audit, they are not going to ask whether your team "cares about security." They are going to ask you to point to a control, a piece of evidence, and a date. For application security teams, that means mapping real engineering practices — SAST results, dependency scans, SBOMs, code review logs — to specific clauses in ISO/IEC 27002:2022's Annex A. Ten of the standard's 93 controls (A.8.25 through A.8.34) deal directly with secure development, and several more touch supplier and cloud risk. Most scanner-first platforms, Veracode included, were built to find vulnerabilities, not to produce audit-ready mappings across the software supply chain. This post breaks down exactly which controls apply, what evidence auditors expect, and where a supply-chain-first approach closes gaps that pure static analysis leaves open.
Which ISO 27002:2022 controls actually govern application security?
Ten controls in the technological theme — A.8.25 through A.8.34 — map directly to the software development lifecycle, and three more (A.5.23, A.8.9, A.8.16) touch it indirectly. Specifically: A.8.25 (secure development life cycle), A.8.26 (application security requirements), A.8.27 (secure system architecture and engineering principles), A.8.28 (secure coding), A.8.29 (security testing in development and acceptance), A.8.30 (outsourced development), A.8.31 (separation of development, test, and production environments), A.8.32 (change management), A.8.33 (test information), and A.8.34 (protection during audit testing). Add A.5.23 (information security for cloud services), A.8.9 (configuration management), and A.8.16 (monitoring activities), and you have a 13-control cluster that an assessor will walk through line by line during a Stage 2 audit. Each control needs its own documented procedure, an owner, and a sample of evidence covering at least one full audit period — typically 3 to 12 months, depending on your certification body's sampling approach.
How did the 2022 revision change application security requirements from 2013?
ISO 27001:2022 consolidated four separate 2013-era controls into two and added six entirely new ones. The old Annex A.14 ("System acquisition, development and maintenance") contained 13 controls; the 2022 revision folded 14.2.1, 14.2.5, 14.2.6, and 14.2.8 into the single A.8.25/A.8.27/A.8.29 cluster, then introduced net-new requirements that didn't exist in 2013 at all: A.5.23 (cloud services), A.8.9 (configuration management), A.8.10 (information deletion), A.8.11 (data masking), A.8.12 (data leakage prevention), and A.8.16 (monitoring activities). The practical effect for AppSec teams: configuration drift and cloud workload posture are now first-class audit items, not implied extensions of "secure development." Organizations that transitioned before the October 31, 2025 deadline had to produce evidence for controls their 2013-era programs never tracked. Any certificate still referencing the 2013 control set after that date is no longer valid for new or renewal audits — a fact several mid-market SaaS companies discovered the hard way when their certification bodies rejected recertification submissions built on outdated control mappings.
What evidence does an auditor expect for A.8.28 (secure coding)?
Auditors expect three concrete artifacts: a documented secure coding standard referencing a specific framework (commonly OWASP ASVS or the SEI CERT guidelines), tool-generated evidence that the standard is enforced (static analysis findings tied to commits, not just periodic PDF reports), and a remediation trail showing time-to-fix for findings above a defined severity threshold. A common failure mode we see in pre-audit gap assessments: teams run a SAST scan quarterly, generate a report, and file it — but can't show the auditor that a specific critical finding from, say, March 2026 was triaged, assigned, fixed, and re-verified before the next release. ISO 27002:2022's guidance for A.8.28 explicitly calls for secure coding principles to be "applied," not merely "documented," which means auditors are increasingly asking for git-linked evidence rather than static reports generated outside the development pipeline.
Why do scanner-only platforms like Veracode struggle with A.8.30 and A.5.23?
Because A.8.30 (outsourced development) and A.5.23 (cloud services) are supply-chain controls, not code-quality controls, and SAST/DAST engines don't observe the supply chain at all. Veracode's platform, like most legacy AppSec suites, was architected around scanning code you own and control: upload a binary or repo, run static and dynamic analysis, get a findings report. That workflow has no native answer for the question A.8.30 actually asks — "can you demonstrate the security requirements you imposed on a third-party development shop, and verify they were met?" — because it never ingests contractor deliverables as a distinct, trackable supply-chain input. Similarly, A.5.23 asks for continuous visibility into the security posture of cloud services and the components running inside them, which requires SBOM generation, dependency provenance, and build-pipeline attestation — none of which a code scanner produces on its own. Teams using scanner-only platforms typically bolt on 2-3 additional tools (an SCA tool, a separate SBOM generator, a manual vendor questionnaire process) just to close these two controls, which fragments evidence across systems an auditor then has to cross-reference by hand.
What does non-compliance with these controls actually cost?
The direct cost is a nonconformity finding that can delay or block certification, but the indirect cost is usually larger: lost enterprise deals that require an active ISO 27001 certificate as a procurement gate. IBM's 2025 Cost of a Data Breach Report put the average cost of a breach involving a software supply chain component at $4.91 million, above the $4.44 million global average, and a growing share of enterprise RFPs now require proof of active ISO 27001:2022 certification (not the 2013 revision) before a vendor even reaches security review. A minor nonconformity typically gives you 90 days to remediate before a certification body escalates it; a major nonconformity — common when a control like A.8.30 or A.5.23 has zero evidence rather than partial evidence — can suspend certification outright. For companies selling into regulated industries or government supply chains, that suspension is often disclosed contractually within 5-10 business days, which turns a documentation gap into a customer-facing incident.
Does ISO 27001 certification actually require a specific tool, or just documented evidence?
ISO 27001 is deliberately tool-agnostic: the standard specifies outcomes, not products, so no certification body will ever list "Veracode" or "Safeguard" as a required line item on a Statement of Applicability. What matters is whether the evidence you produce for each applicable control is complete, timely, and traceable to a named owner. That said, the practical reality of a 13-control AppSec cluster spanning secure coding, environment separation, outsourced development, and cloud services is that manually stitched-together evidence — a spreadsheet here, a scanner PDF there, an email thread for the vendor questionnaire — tends to fail under auditor scrutiny not because the underlying practice is weak, but because the paper trail has gaps. Certification bodies increasingly flag "evidence fragmentation" as a minor nonconformity in its own right, separate from the underlying control failure, because it signals the control isn't actually operationalized day to day.
How Safeguard Helps
Safeguard was built around the software supply chain rather than the code repository, which is exactly the scope ISO 27002:2022's newer controls (A.5.23, A.8.9, A.8.30) require. Safeguard generates and continuously verifies SBOMs across your build pipeline, giving you the artifact-level evidence A.5.23 and A.8.30 ask for without a separate tool. Findings are tied to specific commits, build IDs, and deploy events, so when an auditor asks for the A.8.28 remediation trail on a finding from six months ago, you can produce it in minutes rather than reconstructing it from spreadsheets. Safeguard's control mapping dashboard aligns findings directly to the 13-control ISO 27002:2022 AppSec cluster, so compliance and engineering teams work from the same evidence set instead of maintaining a parallel audit-prep spreadsheet. For teams currently on Veracode or a similar scanner-only platform, Safeguard layers supply-chain visibility — third-party component provenance, build attestation, and dependency risk scoring — on top of existing pipelines, closing the A.8.30 and A.5.23 gaps without a rip-and-replace migration. The result is fewer nonconformities at Stage 2 audit, less manual evidence assembly per audit cycle, and a control mapping that stays current as ISO revises its Annex A rather than one your team has to re-derive from scratch at the next recertification.