Every year, thousands of software vendors hit the same wall: a prospect's security questionnaire asks "Are you ISO 27001 certified?" and the honest answer is "we're not sure what that actually requires." ISO/IEC 27001 is the most widely recognized information security management standard in the world, with over 70,000 certificates issued globally as of the latest ISO Survey, yet the requirements themselves are often misunderstood as a checklist rather than a management system. Compliance automation platforms like Drata have made evidence collection easier, but automation alone doesn't tell you which of the 93 Annex A controls actually apply to your environment, how long certification takes, or how supply chain risk factors into an auditor's assessment. This guide breaks down the real requirements — clause by clause, control by control — and where a software supply chain security tool fits into the picture that compliance automation alone doesn't cover.
What Is ISO 27001 and Why Does It Matter for Software Vendors?
ISO 27001 is an international standard, published jointly by ISO and IEC, that specifies requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). The current version, ISO/IEC 27001:2022, replaced the 2013 edition on October 25, 2022, and organizations certified under the old version had until October 31, 2025 to transition. For software vendors, it matters because it's the de facto entry ticket for enterprise sales in Europe, APAC, and increasingly the US — 61% of enterprise procurement teams now list ISO 27001 or SOC 2 as a hard requirement in vendor risk assessments. Unlike SOC 2, which is largely an American attestation, ISO 27001 is recognized by accreditation bodies in over 190 countries, making it the standard of choice for vendors selling internationally.
What Are the Core ISO 27001 Requirements?
The core requirements live in clauses 4 through 10 of the standard, and all of them are mandatory — there's no "optional" clause the way there is with Annex A controls. Clause 4 requires you to define the context of your organization, including internal and external issues and interested parties. Clause 5 mandates top management leadership and a documented information security policy. Clause 6 requires a formal risk assessment and treatment methodology, plus measurable security objectives. Clause 7 covers resources, competence, awareness, and documented information (your policy library). Clause 8 requires operational planning and control, including the risk assessment execution itself. Clause 9 mandates performance evaluation through internal audits and management review, typically conducted at least annually. Clause 10 requires a process for continual improvement and nonconformity handling. Auditors check these clauses first, because a company can implement every technical control in Annex A and still fail certification if it can't demonstrate a functioning management system wrapped around them.
How Many Controls Does Annex A Include After the 2022 Update?
Annex A now contains 93 controls, down from 114 in the 2013 version, reorganized into four themes instead of the previous fourteen domains. The themes are Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). The consolidation also introduced 11 entirely new controls, including 5.7 (Threat Intelligence), 5.23 (Information Security for Use of Cloud Services), 8.9 (Configuration Management), 8.10 (Information Deletion), 8.11 (Data Masking), 8.12 (Data Leakage Prevention), and — most relevant to software vendors — 8.28 (Secure Coding). Control 5.19 through 5.23 specifically govern supplier and cloud service relationships, requiring documented processes for assessing third-party and open-source component risk. This is where most software companies underestimate scope: Annex A isn't a fixed checklist, it's a reference set, and your Statement of Applicability must justify which controls apply and which are excluded based on your actual risk assessment.
How Long Does ISO 27001 Certification Take?
Most first-time applicants take between 6 and 12 months from kickoff to certificate issuance, though mature security teams with existing documentation can compress this to 3 to 4 months. The timeline breaks into three phases: gap assessment and remediation (typically 6-10 weeks), a Stage 1 audit where the certification body reviews your documentation and readiness (usually 1-2 days on-site or remote), and a Stage 2 audit where the auditor tests whether controls are actually operating (3-5 days depending on company size). After certification, you're not done — ISO 27001 certificates are valid for three years, with mandatory surveillance audits in year one and year two, and a full recertification audit in year three. Companies that skip surveillance audits or fail to maintain evidence continuously often find themselves scrambling to reconstruct twelve months of logs and approvals right before the auditor arrives, which is the single most common cause of certification delays reported by certification bodies.
How Does ISO 27001 Compare to SOC 2, and Do You Need Both?
ISO 27001 certifies that you have a functioning management system, while SOC 2 attests that specific controls operated effectively over an observation period, and most enterprise software companies selling into both US and international markets end up needing both. SOC 2 Type II reports cover a 3 to 12 month observation window and are re-issued annually, with no third-party accreditation body — the report is produced by a licensed CPA firm. ISO 27001 involves an accredited certification body auditing against a fixed international standard, and the resulting certificate (not a report) is portable across the ~190 countries that recognize ISO accreditation. This is exactly the gap that compliance automation vendors like Drata, Vanta, and Secureframe were built to close: they map a single set of internal controls to both frameworks so evidence collection isn't duplicated. What none of these platforms do natively, however, is validate the security of the software supply chain itself — the open-source dependencies, container images, and build pipelines that Annex A controls 5.21 (Managing Information Security in the ICT Supply Chain) and 8.28 (Secure Coding) explicitly require you to assess. Automation platforms are strong at policy, access reviews, and HR onboarding evidence; they're not built to generate an SBOM, flag a vulnerable transitive dependency, or prove your CI/CD pipeline hasn't been tampered with.
How Safeguard Helps
Safeguard closes the specific gap between "we have an ISMS" and "we can prove our software supply chain meets Annex A requirements 5.19 through 5.23 and 8.28." Where general compliance automation platforms track policies, tickets, and HR attestations, Safeguard continuously scans your actual build artifacts, dependencies, and containers, generating audit-ready SBOMs and vulnerability evidence mapped directly to the ISO 27001 controls that reference third-party components and secure development. During a Stage 2 audit, when an assessor asks how you evaluate open-source risk under control 5.21, or how you enforce secure coding practices under 8.28, Safeguard gives you a timestamped, exportable record instead of a manual spreadsheet assembled the week before the audit. For teams already running Drata, Vanta, or another GRC platform to manage clause-level evidence and policy workflows, Safeguard plugs into the same evidence repository as the supply-chain-specific layer — CVE detection, dependency provenance, and build integrity checks — that those platforms don't natively provide. The result is fewer nonconformities tied to supplier and development controls, less scrambling before surveillance audits, and a defensible answer the first time a customer's security team asks how you actually secure what you ship, not just how you manage policy documents about it.