ISO 27001:2022 was written for organizations with persistent physical infrastructure, employees with ten-year tenures, and formal document workflows managed by a separate quality department. None of those assumptions hold for a Series B cloud-native SaaS company where production runs on Kubernetes, the engineering team turns over every three years, and everything that should be a document lives in Notion or a GitHub repo.
You can still get certified. Every serious cloud SaaS we have worked with has been able to fit the ISO 27001 requirements to its actual operating model without breaking the product. But the adaptation requires understanding which parts of the standard are essential versus traditional — and that distinction is not in the standard itself.
This article is the practitioner’s read on running a cloud-native ISMS. It reflects what we actually build in our ISO 27001 engagements, including the shortcuts that work and the ones that catch you at Stage 2. If you are a first-time certification target — particularly a Series B-to-D SaaS with international customer demand — the rest of this is written for you.
What ISO 27001 actually requires
The standard has two parts that matter for certification:
Clauses 4–10 are the ISMS requirements — what an Information Security Management System must do to be recognized as one. These are non-negotiable. Context of the organization (Clause 4), leadership (5), planning (6), support (7), operation (8), performance evaluation (9), improvement (10). Every ISMS has to satisfy each clause.
Annex A is the control catalog — 93 controls organized into 4 themes (Organizational 37 controls, People 8, Physical 14, Technological 34). You do not have to implement all 93. The standard requires you to select which controls apply to your organization (via the Statement of Applicability) and justify both inclusions and exclusions.
The Stage 2 certification audit confirms both: the ISMS exists and operates, and the controls you said you implemented actually operate.
Cloud-native SaaS companies most commonly stumble on two fronts. The first is the “Physical” control theme, where controls written for an organization with its own data center need to be adapted for an organization whose “data center” is AWS. The second is the ISMS operational cadence — management review cycles, internal audit, continual improvement — which is formal structure that many SaaS teams do not naturally maintain.
Cloud-adapted ISMS design
Here is how the core ISMS requirements play out for a typical cloud-native SaaS.
Clause 4 — Context of the organization
You need to document the “internal and external issues” relevant to your ISMS. For a SaaS company, this is your customer mix, data types processed, regulatory environment, third-party service provider landscape, and strategic direction.
Cloud adaptation: keep this as a short, maintained section in a wiki rather than a quarterly-updated document. The auditor wants to see it has been reviewed against current reality. A page last updated eighteen months ago that references customers you no longer serve is worse than a paragraph updated last month.
Clause 5 — Leadership
The standard requires “top management” to demonstrate commitment. In a SaaS company, top management usually means CEO + CTO + CISO (or the highest-ranking security leader). The ISMS needs a named owner, documented policy commitment, and evidence that security is included in business strategy.
Cloud adaptation: The “Information Security Policy” document is traditionally a multi-page statement. For SaaS we write a one-page top-level policy that states intent and commits to the supporting policies — and then each supporting policy (access control, incident response, etc.) is its own document. This keeps the top-level policy stable while the supporting policies iterate.
Clauses 6 and 8 — Risk management
This is where many SaaS teams either underinvest or over-engineer. The standard requires a risk assessment methodology, an asset-and-threat model, a risk treatment plan, and re-assessment at defined intervals.
Cloud adaptation: treat risk assessment as operational, not ceremonial. A risk register maintained in a normal engineering tool (Linear, Jira, Notion) with fields for threat source, impact, likelihood, treatment, and status is fine. Updated when the threat landscape changes or when new assets come online. Re-reviewed quarterly at minimum.
The formal methodology document is typically a three-page PDF that defines the impact/likelihood scales, the risk acceptance criteria, and how treatments are chosen. That is one-time work; the operational register is the ongoing work.
Clause 7 — Support
Resources, competence, awareness, communication, documented information. Most of this is light. The documented-information clause is where SaaS teams often over-build.
Cloud adaptation: there is a principle in 27001 called “documented information” that roughly means “the documents and records that support the ISMS.” It does not mean “every policy and procedure needs to be in a formal document management system.” A policy in a Notion page with a clear version, owner, last-reviewed date, and review cadence is documented information. A document management system is not required.
Clauses 9 and 10 — Performance evaluation and improvement
Internal audit program, management review, nonconformity handling, corrective actions, continual improvement. This is the formal structure that SaaS teams most often underinvest in.
Cloud adaptation: the internal audit does not need to be conducted by an independent department. It can be conducted by someone who does not directly own the controls being audited — often the security engineer auditing the IT team’s controls, or vice versa. Internal audits on a rolling schedule (two or three Annex A themes per quarter) satisfy the annual-coverage requirement without overwhelming the team.
Management review happens at a defined cadence, usually quarterly. For a SaaS company, this is often the security section of the existing exec staff meeting — not a separate ISMS-only review. As long as the review covers the required inputs (changes in internal/external issues, performance of the ISMS, results of audits, etc.) and produces outputs (decisions, improvements), the standard is satisfied.
The controls that cloud SaaS gets wrong
Annex A has 93 controls. For cloud-native SaaS, seven of them consistently cause friction at Stage 2 audit.
A.5.23 — Information security for use of cloud services
This is the control that most directly addresses cloud adoption. The auditor wants to see a documented process for selecting cloud services, defining the security responsibilities between you and the provider, and monitoring the provider’s performance.
What we build for this: a cloud service inventory (every SaaS and IaaS provider you use), a shared-responsibility matrix for each (what you handle, what the provider handles), and a periodic review of each provider’s SOC 2 / ISO 27001 / equivalent attestation. Updated when new services are adopted.
A.5.31 — Legal, statutory, regulatory and contractual requirements
You need a maintained register of applicable requirements — GDPR if you process EU data, CCPA if California, HIPAA if health data, etc. This is often missing or out of date in SaaS companies that grew internationally without updating the register.
What we build: a requirements register with the applicable law, scope, internal owner, and control mappings. Reviewed annually or whenever the company enters a new jurisdiction.
A.8.2 — Privileged access rights
Auditors drill this. They want evidence that privileged accounts are explicitly approved, time-limited where possible, monitored, and reviewed. Generic “admin users” without role definitions fail this.
What we build: a privileged access matrix with named individuals, specific systems, time-of-access limits where applicable, approval workflow, and quarterly review.
A.8.9 — Configuration management
Cloud environments drift if not managed. The auditor wants to see baseline configurations, drift detection, and change control.
What we build: Infrastructure as Code for all production — Terraform or CloudFormation — with drift detection and pull-request-gated changes. Baseline configurations documented as the Terraform files themselves, with code review standing in for the traditional change advisory board.
A.8.12 — Data leakage prevention
This is where auditors test your SaaS-specific posture. Can CUI or PII leak via Slack? Via a copy-paste to a personal email? Via an unapproved SaaS tool?
What we build: data classification policy with specific definitions, DLP controls appropriate to the tooling (Microsoft Purview for M365 tenants, in-app DLP for Google Workspace), and monitoring for anomalous data flows. The point is not perfect prevention — the point is demonstrable awareness and layered controls.
A.8.16 — Monitoring activities
SIEM or equivalent logging for security events, with defined event types, retention periods, alerting rules, and review cadences.
What we build: centralized logging (Datadog, Splunk, Elastic, or cloud-native like CloudWatch + Athena) with defined event categories, 12-month retention for security events, alerting for high-severity patterns, and weekly or monthly review documented in a ticketing tool.
A.8.23 — Web filtering
This control was added in 27001:2022 and is genuinely new for many organizations. It requires controls to protect against accessing websites with malicious content.
What we build: DNS-layer filtering (Cisco Umbrella, Cloudflare Gateway, or similar) on corporate endpoints, with categorical blocks for known-malicious and explicit-content categories, and documented exceptions for business-need access.
What the Stage 1 + Stage 2 audits look like
ISO 27001 certification is a two-stage process conducted by the certification body (not by you — the certification body is a third-party, and the lead auditor must be ISO 27001-certified personally).
Stage 1 is a readiness review, typically 2–3 days. The auditor reviews your ISMS documentation — your Statement of Applicability, risk assessment, management review outputs, policies — to confirm the ISMS is structurally ready for certification. Stage 1 produces findings that should be remediated before Stage 2.
Stage 2 is the operational audit, typically 5–10 days depending on organization size. The auditor reviews evidence that the ISMS is operating and that Annex A controls are implemented effectively. This includes interviews with leadership, technical personnel, and operational staff, plus spot-checks of evidence artifacts.
If Stage 2 passes, the certification body issues the certificate (valid three years) and schedules the annual surveillance audits (typically 3–5 days each).
Where cloud SaaS companies spend the most time
Across our engagements, three areas dominate the time budget:
-
Statement of Applicability preparation. The SoA maps each of the 93 Annex A controls to your organization — applicable or not, implementation status, reference to the control’s implementation. Getting this right takes weeks of cross-functional work with engineering, IT, people ops, and legal.
-
Risk assessment methodology and first full cycle. Adopting the methodology is straightforward. Producing the first full risk assessment against your real environment takes longer than teams expect because the work is genuinely diagnostic.
-
ISMS operational cadence during the operating period. Between Stage 1 and Stage 2, the ISMS needs to operate for at least three months — better, six. This means management reviews have happened, internal audits have been conducted, nonconformities have been identified and treated. Teams who treat the pre-Stage-2 period as a document sprint rather than an operating period fail Stage 2.
Pairing with SOC 2
Most of the cloud SaaS companies we work with are running both ISO 27001 and SOC 2, either simultaneously or in sequence. The controls overlap heavily — see our companion article on SOC 2 vs ISO 27001 and when to do both — and the evidence pipeline can be designed once for both.
The structural difference to remember: SOC 2 gives you a report, ISO 27001 gives you a publicly verifiable certificate. If your customer mix is mixed U.S. and international, most of them will accept one or the other; some will demand both.
When to engage
For first-time ISO 27001 certification, the inflection point for engaging outside support is before you draft the Statement of Applicability. If you start with a consultant who has run the framework before, the SoA is scoped correctly on the first pass and the risk assessment methodology fits your environment. If you start alone and engage later, we often spend the first month reworking the SoA.
Our ISO 27001 practice is built around cloud-native SaaS — we do not push on-prem control templates at teams that do not have on-prem. We design the ISMS for your product and we integrate with whatever SOC 2 work is running in parallel. If a scoping conversation is useful, a 30-minute call usually lands a realistic path.
Related reading: SOC 2 vs ISO 27001: which to pursue first · SOC 2 Type II evidence patterns