ISO/IEC 27001:2022 reorganized its control set into 93 controls across four themes — Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls) — replacing the 114 controls in the 2013 edition. The restructuring is an improvement, but 93 controls still represent a significant surface area for a cloud-native SaaS company with no on-premises infrastructure and a distributed remote team.
The standard doesn't require that every control be implemented identically or to the same depth. Annex A is a reference set, and ISO 27001 explicitly requires that your Statement of Applicability (SoA) document which controls apply, which are implemented, and what the justification is for any exclusion. That framework gives organizations real latitude — but it also requires that you have a reasoned, documented position on each control, including those you've scoped out.
This piece covers the controls that are most operationally significant for a cloud-native SaaS company, and the ones most commonly misapplied or over-implemented when teams approach the standard without a cloud-native lens.
Organizational controls: where governance lives
The Organizational theme covers policies, roles, responsibilities, asset management, supplier relationships, and incident management. For a SaaS company, several controls in this group are high-weight.
5.1 — Policies for information security requires that information security policies are defined, approved, published, and communicated. For a SaaS company, this is foundational and genuinely required — you need documented policies covering access control, acceptable use, incident response, data classification, and similar areas. The common mistake is treating policy documentation as a one-time exercise rather than a living program. ISO 27001 requires that policies be reviewed at planned intervals; your ISMS audit evidence needs to show that reviews happened.
5.19 through 5.22 — Supplier relationships are among the most underestimated controls in a SaaS context. Control 5.19 (Information security in supplier relationships) and 5.20 (Addressing security within supplier agreements) require that your vendor management program covers information security requirements in supplier contracts. For a SaaS company relying heavily on cloud infrastructure and SaaS tools — AWS, GitHub, Okta, Datadog, and similar — the supplier security assessment program is a genuine control that requires evidence. BAAs with vendors processing personal data, security questionnaires or SOC 2 reports for key vendors, and a documented vendor register are the primary evidence artifacts.
5.28 — Collection of evidence is notable because it directly supports your audit program. It requires that procedures exist for identifying, collecting, acquiring, and preserving information that may serve as evidence. In practice, this means your incident response and audit evidence processes need to be designed to preserve chain-of-custody for digital evidence — relevant both for potential legal proceedings and for your own SOC 2 or ISMS audit program.
Technological controls: the highest operational density
The Technological theme contains the highest concentration of controls that have direct production system mapping. Several of these overlap with SOC 2 Trust Service Criteria, which makes combined SOC 2 / ISO 27001 programs more efficient than running them separately.
8.2 — Privileged access rights directly maps to your IAM configuration. The control requires that privileged access rights be allocated on a need-to-know basis, controlled separately from general user access, and reviewed at regular intervals. For AWS, this means your IAM role structure for privileged operations (admin-level or broadly scoped roles) needs documented justification and periodic review. The evidence artifacts are: the list of privileged roles and their attached policies, the list of principals with those roles assigned, and the access review records showing the assignments were verified as appropriate.
8.5 — Secure authentication requires that secure authentication technologies and procedures be implemented. For a cloud-native SaaS company, this primarily means MFA enforcement — both for your own team accessing production systems and for customer accounts. The observable evidence is your identity provider's MFA enforcement policy configuration (verifiable via API) and any exceptions or bypass records.
8.8 — Management of technical vulnerabilities requires a systematic approach to identifying, evaluating, and remediating technical vulnerabilities. This includes your vulnerability scanning cadence, the severity-tiered remediation timeline (a policy that says, for example, critical vulnerabilities must be remediated within 30 days, high within 90 days), and your evidence that the policy was followed. The common gap is organizations that have a vulnerability scanning program but no documented remediation SLA, or organizations that have the SLA on paper but lack evidence that it was followed for specific findings.
8.12 — Data leakage prevention is an area where cloud-native SaaS companies often need careful scoping. The control addresses preventing unauthorized disclosure of sensitive information. For a SaaS company, the primary DLP controls are AWS S3 bucket policies preventing public access, VPC network controls preventing unauthorized data egress, and application-level controls preventing unauthorized data export. A full DLP implementation with content inspection and egress filtering is appropriate for some organizations but represents significant implementation complexity. The SoA for this control needs to clearly document what scope is appropriate for your threat model.
Physical controls: the scoping question
The Physical theme includes 14 controls covering physical access to facilities, equipment maintenance, clean desk policies, and physical media. For a cloud-native SaaS company with no on-premises servers, no data center, and a remote-first team operating from home offices and co-working spaces, much of this section requires careful scoping decisions.
Controls like 7.1 (Physical security perimeters) and 7.2 (Physical entry) are directly applicable if you have a physical office, but the implementation looks quite different from the traditional perimeter security model. A co-working space arrangement doesn't give you control over building access logs. Your SoA needs to document this and explain the compensating controls — for example, that all sensitive processing happens in the cloud with no on-premises systems, so physical access to office space presents limited risk to information security.
Physical media controls (7.9, 7.10) are another area where cloud-native companies often over-implement. If your team primarily uses cloud storage and no physical media is used for information processing, the controls can be scoped accordingly — with appropriate documentation that physical media is not used and why that exclusion is justified.
People controls: smaller but non-trivial
The People theme covers screening (6.1), terms of employment (6.2), awareness and training (6.3), disciplinary processes (6.4), and responsibilities after termination (6.5). These are all genuinely applicable for most SaaS companies, and the evidence is straightforward: background check policies and records, employment agreements with security clauses, security awareness training records with completion evidence.
Control 6.3 (Information security awareness, education and training) is worth particular attention. ISO 27001 requires a program, not an annual checkbox. Your ISMS audit evidence needs to show ongoing training activity, not just one annual course completion record. For a small team, this can be as simple as documented monthly or quarterly security briefings, but the cadence needs to be planned, executed, and evidenced.
Building your Statement of Applicability with cloud-native context
We're not suggesting that cloud-native SaaS companies can simply exclude large sections of Annex A. The SoA exclusion process requires a documented risk-based justification for each excluded control, and the justification needs to hold up to scrutiny from a certification auditor. "We don't have physical servers" is a legitimate justification for some physical controls, but it needs to be expressed in risk language: what is the threat, what is the likelihood and impact if the control is absent, and what compensating controls or environmental factors reduce the residual risk to an acceptable level.
The practical approach for most cloud-native SaaS companies is to treat all 93 controls as starting applicable, work through each one with a risk-based lens, and document the reasoning for any exclusion or reduced implementation. The controls that genuinely don't apply to a cloud-native model — primarily physical security controls around server room access and physical media handling — will be a minority of the 93. The rest require implementation to some degree, even if the implementation looks different from the traditional enterprise model.
ISO 27001 certification is a commitment to operating an ISMS that continuously manages information security risk — not a one-time audit pass. The controls that have the highest operational value are the ones that produce observable, testable evidence of ongoing control activity: access reviews, vulnerability scan cycles, training records, vendor assessments. Those are also the controls where continuous monitoring adds the most value, because they're the ones with the highest risk of drift between planned and actual state.