Software vendors are running into the same wall in enterprise procurement: no ISO 27001 certificate, no contract. Since the October 31, 2025 transition deadline, every active certificate must now comply with ISO/IEC 27001:2022, which cut Annex A from 114 controls down to 93 and regrouped them into four themes — organizational, people, physical, and technological — instead of the old 14 clauses. For a development team, roughly a third of those 93 controls touch the SDLC directly: secure coding (8.28), security testing in development (8.29), change management (8.32), and configuration management (8.9) are now audited line items, not policy statements. This piece breaks down what ISO 27001 actually requires of engineering teams, how it differs from SOC 2, what auditors check in your pipeline, and how long certification realistically takes — with the control numbers you'll need to map to your existing tooling.
What Is ISO 27001 and Why Does It Matter for Software Development Teams?
ISO 27001 is an international standard for building an Information Security Management System (ISMS), and for dev teams it matters because certification is now a de facto prerequisite for enterprise and government sales. The current version, ISO/IEC 27001:2022, was published in October 2022, and the joint accreditation bodies (IAF) set October 31, 2025 as the hard cutover date — certificates still referencing the 2013 edition are no longer valid. Unlike SOC 2, which is US-centric and report-based, ISO 27001 is a certifiable standard recognized in over 190 countries, which is why UK, EU, and APAC buyers frequently require it as a contract gate where US buyers might accept a SOC 2 Type II. Engineering teams feel this most acutely in Annex A's technological theme (controls 8.1–8.34), which covers secure development lifecycle practices, vulnerability management, and network security — areas that live in your CI/CD pipeline, not your HR handbook.
Which ISO 27001 Controls Apply Directly to the Software Development Lifecycle?
Eight controls in Annex A map directly onto engineering workflows, and missing any one of them is a common finding in Stage 2 audits. Control 8.25 (Secure Development Life Cycle) requires documented security gates at each SDLC phase — design, coding, testing, deployment. Control 8.26 (Application Security Requirements) requires that security requirements be defined before code is written, not retrofitted. Control 8.27 (Secure System Architecture and Engineering Principles) covers threat modeling and secure-by-design review. Control 8.28 (Secure Coding) requires documented coding standards and static analysis enforcement. Control 8.29 (Security Testing in Development and Acceptance) requires SAST, DAST, or equivalent testing before release — auditors will ask for tool output, not a policy PDF. Control 8.8 (Management of Technical Vulnerabilities) requires a documented process for identifying and remediating vulnerabilities within defined SLAs, commonly 15 days for critical CVEs and 30-90 days for high/medium. Control 5.9 (Inventory of Information and Other Assets) increasingly extends to software assets, meaning auditors now ask for an SBOM or equivalent component inventory. Control 8.32 (Change Management) requires a documented, auditable approval trail for production changes, which is why unreviewed merges to main are a recurring nonconformity.
How Does ISO 27001 Differ From SOC 2 for Engineering Teams?
ISO 27001 certifies a management system against a fixed control list, while SOC 2 audits how well you follow controls you defined yourself, and that distinction changes how much documentation your team owns. SOC 2 Type II reports are built around five Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy) and let you scope your own controls to fit; an auditor tests whether you did what you said you'd do over a 3-12 month observation window. ISO 27001 hands you a fixed menu — 93 Annex A controls — and requires a formal Statement of Applicability justifying any control you exclude, plus a certification audit performed by an accredited body, renewed via annual surveillance audits and full recertification every three years. In practice, most software vendors selling into both US and international markets end up maintaining both: SOC 2 Type II for US enterprise buyers and ISO 27001 for EU/UK/APAC deals, which is why teams increasingly build one evidence pipeline (vulnerability scan results, SBOM data, access logs) and map it to both frameworks rather than running duplicate compliance programs.
What Does an ISO 27001 Audit Actually Check in Your CI/CD Pipeline?
An ISO 27001 Stage 2 audit checks for documented evidence that security controls in your pipeline are actually enforced, not just described in a wiki page. Auditors sample a set of recent releases — typically 10-25 depending on deployment frequency — and trace each one through your change management trail: was there a pull request, a code review, a passing security scan, and a documented approval before merge to production. For control 8.29, they'll pull SAST/DAST scan logs and check whether findings above your defined severity threshold blocked the release or were formally risk-accepted with a named owner and remediation date. For control 8.8, they'll request your vulnerability register and check whether critical findings were remediated inside your stated SLA — a team that commits to 15 days and takes 45 on three sampled CVEs will get a nonconformity, not a warning. For control 5.9/8.31, expect a request for your component inventory: if you can't produce a current SBOM for the sampled release within the audit window, that's typically logged as a minor nonconformity requiring a corrective action plan within 90 days.
How Long Does ISO 27001 Certification Take for a Software Company?
Most software companies complete initial ISO 27001 certification in 6-12 months from kickoff to certificate issuance, with the timeline split roughly into three phases. Gap assessment and ISMS build-out (documenting policies, running a risk assessment, implementing missing controls) typically takes 3-6 months for a team that has some existing security tooling; teams starting from zero — no vulnerability management process, no SBOM, no formal access reviews — often need 9-12 months. Stage 1 audit (documentation review) is usually a 1-2 day desk audit, and Stage 2 (implementation audit) runs 3-5 days on-site or remote, scheduled 6-8 weeks after Stage 1 to give time to close any gaps found. Total cost for a company under 100 employees typically runs $15,000-$40,000 in certification body fees alone, before internal engineering time or consultant fees. After certification, annual surveillance audits (1-2 days each) run in years one and two, with full recertification in year three — meaning the SDLC controls you build now need to stay operational, not just pass once.
What Are the Most Common ISO 27001 Gaps Found in Development Teams?
The most common gap is an incomplete or stale software asset inventory, cited in a large share of Stage 2 audits because teams track infrastructure assets but not software components and their known vulnerabilities. Close behind is control 8.8's vulnerability SLA requirement: teams frequently document a remediation SLA (e.g., 15 days for critical) but have no automated way to prove which vulnerabilities were reachable, exploitable, or actually fixed within that window, leading auditors to flag the process as "not operating effectively" even when a policy exists. Third is control 8.29 evidence: teams run a SAST or SCA tool but can't produce a clean audit trail showing scan results were reviewed and gated releases, especially when findings were suppressed without documented justification. Fourth is control 8.32 change management: unreviewed hotfixes pushed directly to production outside the normal PR process are a recurring finding, often surfacing during exactly the kind of incident response review an auditor samples. Each of these gaps traces back to the same root cause — security data that exists somewhere in a tool, but isn't captured in a form an auditor (or a developer under deadline pressure) can act on.
How Safeguard Helps
Safeguard closes the evidence gap that shows up repeatedly in ISO 27001 audits by turning raw scan output into controls you can actually defend. Reachability analysis maps which vulnerabilities in your dependency tree are in code paths your application actually executes, so your control 8.8 remediation SLA can prioritize exploitable findings first instead of triaging every CVE equally. Griffin AI investigates and triages findings automatically, generating the documented risk-acceptance rationale auditors expect to see for anything not remediated within SLA. Safeguard generates and ingests SBOMs across your build pipeline, giving you the current, exportable component inventory that satisfies control 5.9 and 8.31 on demand rather than as a pre-audit scramble. And auto-fix PRs close the loop on control 8.32's change management requirement by routing every remediation through your normal pull request and review process, keeping the audit trail intact from detection to merge.