Why SaaS buyers ask for ISO 27001
For a SaaS company, ISO 27001 usually arrives through procurement. An enterprise customer runs a vendor review, the security questionnaire asks for a certificate, and the deal waits until there is one. The buyer wants independent assurance that the supplier runs a managed information security programme, and an ISO 27001 certificate issued by an accredited certification body is the most widely recognised way to give it in Europe.
The certificate alone is rarely the end of the review. Buyers read the scope statement printed on it, and many ask for the Statement of Applicability. Both need to show that the product they are buying is covered. This is why scoping is the first decision that matters.
Setting the scope around the product
Clause 4.3 of ISO 27001:2022 requires the organisation to define the boundaries of its information security management system, the ISMS, taking into account interfaces and dependencies with activities outside it. For a SaaS company, the practical scope is the product customers buy and everything that delivers it: the production cloud environment, the code repositories and the deployment pipeline, the teams that build, operate and support the product, and the suppliers the service depends on.
Parts of the business that do not touch the product can stay out, but the interfaces must be described. A narrow scope that leaves out the engineering team, or a scope that names the company but not the product, invites questions from the auditor and from customers. The difference between a real ISMS and a set of documents is covered in our article on ISMS vs security policies.
The Annex A controls that carry the most weight
ISO 27001:2022 lists 93 controls in Annex A, grouped into organisational, people, physical and technological themes. Every control is considered in the risk treatment, and each exclusion is justified in the Statement of Applicability. In a SaaS company, a few groups carry most of the weight:
- Cloud services, control 5.23, added in the 2022 revision, which covers how the company acquires, uses, manages and exits the cloud services it relies on.
- Supplier relationships, controls 5.19 to 5.22, covering security requirements in supplier agreements and the monitoring of supplier services.
- Secure development, controls 8.25 to 8.29, from the secure development life cycle to security testing during development and acceptance.
- Separation of environments and change management, controls 8.31 and 8.32.
- Configuration, vulnerabilities, logging and monitoring, controls 8.8, 8.9, 8.15 and 8.16.
- Backup and incident management, control 8.13 and controls 5.24 to 5.28.
The selection is driven by the risk assessment, not by a template. A company with no physical office still considers the physical controls, but its justification will point to its cloud provider and its remote working policy.
Shared responsibility with the cloud provider
Large cloud providers hold ISO 27001 certificates for their own services. Those certificates cover the provider's layer: the data centres, the hardware and the services as the provider operates them. They do not cover how the SaaS company configures its accounts, who has access to them, or what the company deploys on top.
Control 5.23 asks the company to define and manage that split. In practice that means knowing which services are used, which security responsibilities stay with the company, and how the provider's certificates and reports are reviewed. ISO/IEC 27017, a code of practice for cloud services, and ISO/IEC 27018, for personal data in public clouds, give useful guidance for this work. They are not required for ISO 27001 certification.
What the auditor samples in a SaaS company
The certification audit runs in two stages, explained in our article on the stage 1 and stage 2 audits. In stage 2 the auditor samples records of the ISMS in operation. In a SaaS company the usual samples are these: change requests with approvals and test evidence, access reviews for production and for the cloud console, joiner and leaver records with the dates access was granted and removed, vulnerability findings with their remediation tickets, backup restoration tests, incident records and supplier reviews.
Each sample must exist before the audit. A pipeline that enforces review on every merge produces change evidence automatically. A quarterly access review that nobody scheduled does not. This is where the operating side of security decides whether the certificate is obtained, and whether it survives the first surveillance audit. Testing is a frequent gap; our article on application security testing covers what control 8.29 expects in practice.
ISO 27001 or SOC 2
SaaS companies selling internationally often face both ISO 27001 and SOC 2. They overlap heavily in controls and evidence, but they are different instruments: ISO 27001 certifies a management system, while a SOC 2 report is an auditor's opinion on controls against the AICPA Trust Services Criteria. European buyers tend to ask for ISO 27001, and US buyers tend to ask for SOC 2. Our article on where ISO 27001, SOC 2 and TISAX overlap explains how to run one control set for both.
Where Qalea fits
A SaaS company evaluating how to reach ISO 27001 usually compares a compliance platform with a consultant. The comparison that holds up is against the full capability the certificate depends on: the compliance platform, plus endpoint protection, a SIEM and SOC, periodic penetration testing, vCISO time and the internal hours to run all of it. Qalea brings that stack together in one programme. We get the ISMS audit-ready and run the security work that keeps the certificate valid. More on the standard in our ISO 27001 topic hub.
