ISO 27001 for B2B SaaS: ISMS Reality, Not Theater

ISO 27001 certification tells enterprise buyers that your organization manages information security through a systematic, auditable framework. For B2B SaaS companies selling into regulated industries — healthcare, financial services, government, and large enterprise — it is increasingly a prerequisite rather than a differentiator.

But too many SaaS companies treat ISO 27001 as a documentation exercise: hire a consultant, generate a stack of policies, pass the audit, and move on. That approach produces an ISMS that looks good on paper but collapses the moment someone asks how a specific control actually works.

This article covers what ISO 27001 actually requires operationally, how to build an ISMS that survives contact with reality, and how to sustain certification without it becoming a full-time job.

What ISO 27001 Actually Requires

ISO 27001 is a management system standard. It does not prescribe specific technologies or configurations. Instead, it requires you to build and operate an Information Security Management System (ISMS) that follows a Plan-Do-Check-Act cycle. The core requirements are defined in Clauses 4 through 10, and the specific security controls are listed in Annex A.

The Core Clauses

Clause 4 (Context): Define the scope of your ISMS, identify interested parties (customers, regulators, employees), and understand the internal and external factors that affect information security.

Clause 5 (Leadership): Top management must demonstrate commitment, establish an information security policy, and assign roles and responsibilities. This is not optional. The auditor will interview your CEO or CTO to verify leadership engagement.

Clause 6 (Planning): Conduct a risk assessment, define risk treatment plans, and set measurable information security objectives. This clause drives everything else.

Clause 7 (Support): Ensure you have the resources, competence, awareness, and communication channels needed to operate the ISMS.

Clause 8 (Operation): Execute your risk treatment plans and manage the operational controls you have selected.

Clause 9 (Performance Evaluation): Monitor, measure, and evaluate the ISMS through internal audits and management reviews. Both are mandatory.

Clause 10 (Improvement): Address nonconformities and drive continual improvement. The auditor wants to see evidence that you fix problems and get better over time.

For a SaaS company, the practical implication is that you need documented processes for managing risk, selecting and operating controls, reviewing effectiveness, and improving over time. It is not enough to have controls in place. You must prove that you manage them through a defined system.

The 2022 Update: What Changed

ISO 27001:2022 replaced the 2013 version with significant changes to Annex A. Understanding these changes matters because auditors evaluate you against the current standard.

The 2013 version had 114 controls organized into 14 domains (A.5 through A.18). The 2022 version consolidated these into 93 controls organized into 4 themes: Organizational, People, Physical, and Technological.

Eleven new controls were added, including threat intelligence (A.5.7), cloud services security (A.5.23), ICT readiness for business continuity (A.5.30), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23), and secure coding (A.8.28).

For SaaS companies, the most relevant additions are cloud services security (A.5.23), which requires a formal process for managing cloud provider relationships and configurations, and secure coding (A.8.28), which requires documented secure development practices.

If you certified under the 2013 version, you had until October 2025 to transition. New certifications are assessed against the 2022 version.

ISMS Scope for SaaS

Scoping the ISMS correctly is the first critical decision. Get it wrong and you either over-extend (creating unnecessary work) or under-scope (leaving gaps that auditors will flag).

Cloud-Native Considerations

For a SaaS company running on AWS, GCP, or Azure, your ISMS scope typically includes: the SaaS application and its supporting infrastructure, the development and deployment pipeline, corporate IT systems (identity provider, collaboration tools, endpoints), the team that builds and operates the product, and customer data processed by the platform.

What you can usually exclude from scope: the cloud provider's physical infrastructure (covered by their own certifications), customer-side systems and networks, and any business functions that do not touch information security (e.g., a separate marketing team using only public data).

Remote Team Scoping

If your team is fully remote, your scope needs to address remote access controls, endpoint security, home network considerations, and secure communication channels. You cannot exclude remote work from scope just because you do not have an office.

Documenting the Scope

The ISMS scope statement should be specific: "The ISMS covers the design, development, deployment, and operation of the [Product Name] SaaS platform, including supporting cloud infrastructure on AWS, corporate IT systems, and all personnel involved in product development and operations." Vague scope statements like "information security across the organization" generate auditor questions.

Risk Assessment That Works

ISO 27001 requires a formal risk assessment process. This is not a one-time exercise but a repeatable methodology that you apply when changes occur or at defined intervals.

Choosing a Methodology

Most SaaS companies use a qualitative approach with a likelihood-impact matrix. A 5x5 grid works: likelihood rated 1 (rare) to 5 (almost certain), impact rated 1 (negligible) to 5 (catastrophic). Multiply for a risk score. Anything above your defined threshold (typically 12-15) requires treatment.

The standard does not prescribe a specific methodology, but it must be documented and repeatable. Write a one-page risk assessment procedure that describes: who participates, what scale you use, how often you run it, and how results feed into the risk treatment plan.

Building the Risk Register

Structure your risk register with these columns: Risk ID, Asset/Process, Threat, Vulnerability, Likelihood, Impact, Risk Score, Treatment Decision, Treatment Controls (Annex A references), Risk Owner, and Review Date.

A typical SaaS risk register has 30 to 60 identified risks. Common entries include: unauthorized access to production environment, customer data breach via application vulnerability, service disruption from cloud provider outage, supply chain compromise through third-party dependency, insider threat from privileged access, and loss of key personnel with critical system knowledge.

Linking to Treatment

Every risk above threshold needs a treatment plan. The treatment plan maps directly to Annex A controls. Risk R-001 (unauthorized access to production) might map to A.5.15 (access control), A.5.17 (authentication), A.8.3 (access restriction), and A.8.5 (privileged access management). This chain — risk to treatment to control to evidence — is what auditors follow. For a deeper look at how this maps to SOC 2, see our SOC 2 evidence checklist.

Annex A Control Mapping for SaaS

Organizational Controls (A.5)

Nearly all 37 organizational controls apply to SaaS companies. Key ones include: A.5.1 (information security policies), A.5.2 (roles and responsibilities), A.5.7 (threat intelligence), A.5.8 (information security in project management), A.5.19-A.5.23 (supplier management and cloud services), A.5.24-A.5.28 (incident management), and A.5.29-A.5.30 (business continuity).

Supplier management (A.5.19-A.5.23) deserves special attention. Every SaaS company relies on dozens of subprocessors. You need a vendor management program that covers security assessment, contractual requirements, monitoring, and change management. See our detailed guide on vendor risk management for SaaS.

People Controls (A.6)

All 8 people controls are applicable for any company with employees. A.6.1 (screening), A.6.2 (terms of employment), A.6.3 (awareness and training), A.6.4 (disciplinary process), A.6.5 (responsibilities after termination), A.6.6 (confidentiality agreements), A.6.7 (remote working), and A.6.8 (information security event reporting).

Physical Controls (A.7)

This is where SaaS companies can legitimately exclude several controls. If you have no data center, controls related to physical perimeter security, environmental threats to server rooms, and cabling security can be excluded with proper justification. You still need to address: A.7.1 (physical security perimeters for your office), A.7.7 (clear desk), A.7.8 (equipment siting), A.7.9 (security of assets off-premises — laptops), and A.7.14 (disposal of equipment).

Technological Controls (A.8)

Nearly all 34 technological controls apply to SaaS companies. Critical ones: A.8.1 (user endpoint devices), A.8.2-A.8.5 (access management), A.8.7 (malware protection), A.8.8 (vulnerability management), A.8.9 (configuration management), A.8.15-A.8.16 (logging and monitoring), A.8.24-A.8.28 (cryptography and secure development), and A.8.32 (change management).

The output of this mapping exercise feeds directly into your Statement of Applicability.

Internal Audit Program

Internal audits are mandatory (Clause 9.2) and must be conducted before the certification audit. They are also one of the most practical tools for finding problems before the external auditor does.

Planning the Internal Audit

Create an internal audit program that covers all ISMS clauses and applicable Annex A controls over a defined cycle (typically one year). You do not have to audit everything at once. Most companies split internal audits into quarterly cycles, covering different control domains each quarter.

Who Should Audit

The internal auditor must be independent of the area being audited. An engineer cannot audit the controls they operate. Options: cross-departmental auditing (IT audits engineering controls, engineering audits HR controls), hiring an external consultant for internal audit, or using a GRC platform with built-in self-assessment capabilities.

Audit Execution

For each control area: review the documented procedure, examine evidence that the control operated as designed, interview the control owner, and document findings. Classify findings as conformity, observation (minor improvement opportunity), or nonconformity (control not operating as designed).

Corrective Actions

Every nonconformity requires a corrective action plan: root cause analysis, remediation steps, timeline, and responsible person. Track corrective actions to closure. The external auditor will review your internal audit results and verify that corrective actions were completed.

Stage 1 and Stage 2: What to Expect

The certification audit happens in two stages, typically conducted by the same certification body with a gap of 2 to 8 weeks between them.

Stage 1 (Documentation Review)

Stage 1 is a readiness check. The auditor reviews your ISMS documentation: scope statement, information security policy, risk assessment methodology, risk register, risk treatment plan, SoA, internal audit results, and management review minutes.

The auditor is looking for completeness and consistency. They will flag any missing mandatory documents, inconsistencies between the risk register and SoA, and areas where documentation does not meet ISO 27001 requirements.

Stage 1 typically takes 1-2 days for a SaaS company with 20-100 employees. The auditor will provide a report listing any findings that must be resolved before Stage 2.

Stage 2 (Implementation Audit)

Stage 2 is the main certification audit. The auditor verifies that your ISMS is implemented and operating as documented. They will: interview control owners and leadership, review evidence for each applicable Annex A control, test controls by examining samples (pull 3 access reviews from Q2, check 5 change management tickets from Q3), verify that internal audit findings were addressed, and assess the overall maturity of the ISMS.

Stage 2 takes 3-5 days depending on company size and scope. The auditor's report will classify findings as: major nonconformity (certification cannot proceed until resolved), minor nonconformity (must be resolved but does not block certification), or observation (improvement opportunity, no action required).

If you receive major nonconformities, you typically have 90 days to resolve them and provide evidence to the auditor. Minor nonconformities must be addressed by the next surveillance audit.

Maintaining Certification

ISO 27001 certification is valid for three years, with annual surveillance audits to verify continued compliance.

Surveillance Audits

Surveillance audits are shorter than the initial certification audit (typically 1-2 days). The auditor samples a subset of controls, reviews any changes to the ISMS, checks that corrective actions from previous audits were completed, and verifies that the ISMS is being actively managed.

Recertification

At the end of the three-year cycle, a full recertification audit is conducted. This is similar to the initial Stage 2 audit but benefits from the auditor's familiarity with your organization.

Continual Improvement

The standard requires evidence of continual improvement (Clause 10.2). This does not mean you need to implement major changes every year. It means you need to show that you identified improvement opportunities (through internal audits, management reviews, incident analysis, or monitoring) and acted on them. Keep a log of ISMS improvements: control enhancements, process streamlining, tool upgrades, training improvements.

The Operating Calendar

Build an annual calendar for ISMS activities. Monthly: review security incidents and metrics, update risk register if needed. Quarterly: management security summary, risk register formal review, vendor security documentation check. Semi-annually: internal audit of a subset of controls. Annually: full management review meeting, security awareness training, risk assessment refresh, SoA review, surveillance audit.

ISO 27001 vs SOC 2: Choosing Your Path

Both frameworks address information security, but they serve different purposes and audiences. If you are comparing the two, start with the SOC 2 readiness guide for the SOC 2 perspective.

ISO 27001 is the stronger choice for companies selling internationally, particularly in the EU, UK, and APAC markets. It is a recognized certification that appears on a certificate, not just a report.

SOC 2 is the standard for North American enterprise procurement. Most US-based buyers ask for SOC 2 first. The report format provides detailed control descriptions that procurement teams review.

Many SaaS companies pursuing both find that 60 to 70 percent of controls overlap. Build your ISMS once and use it to satisfy both frameworks. The risk register, access controls, incident response, change management, and vendor management programs all serve double duty.

Getting Started

Building an ISMS that earns certification and continues to operate effectively requires more than documentation. It requires a system that fits your organization's actual workflows, tools, and risk profile.

CertifyOps builds ISO 27001 ISMS programs for B2B SaaS companies. We handle gap assessment, documentation, risk assessment, SoA development, internal audit preparation, and certification body coordination. If you are planning for ISO 27001 certification, contact us to scope your ISMS build.