ISO 27001 Annex A Controls: Complete Guide to All 93 Controls

Annex A is where ISO 27001 gets specific. While the main body of the standard (Clauses 4-10) defines what your Information Security Management System must do — establish scope, conduct risk assessment, implement management review — Annex A provides a reference set of 93 information security controls organized into four themes. These controls are the building blocks of your security implementation, and selecting which ones to apply (and which to exclude) is one of the most consequential decisions in your ISO 27001 journey.

The 2022 revision of ISO 27001 restructured Annex A significantly. The previous version (2013) organized 114 controls across 14 domains. The 2022 version consolidates these into 93 controls across four thematic categories, adds 11 entirely new controls, and introduces a control attributes system that enables more flexible categorization. If you are working with older documentation or consultants referencing the 14-domain structure, the 2022 restructuring is the most important change to understand.

This guide covers every Annex A theme, explains each control category, highlights the 11 new controls, and provides practical guidance for SaaS companies implementing these controls as part of their ISMS.

What Is Annex A and How Does It Relate to ISO 27001?

Annex A is a normative annex — meaning it is not optional guidance but a required part of the standard. However, you are not required to implement every Annex A control. You are required to consider every Annex A control and document your inclusion or exclusion decision in the Statement of Applicability (SoA).

The Relationship Between Risk Assessment and Annex A

The process works as follows:

1. Conduct your risk assessment — identify threats, vulnerabilities, and risks to information security within your ISMS scope.
2. Develop a risk treatment plan — for each risk above your acceptance threshold, decide how to treat it (mitigate, transfer, avoid, accept).
3. Select Annex A controls — for risks you are mitigating, identify which Annex A controls implement the treatment. You can also implement controls not in Annex A if needed, but Annex A serves as the baseline reference.
4. Document in the SoA — list all 93 Annex A controls, state whether each is included or excluded, provide justification for the decision, and note the implementation status.

This means your control selection is risk-driven, not arbitrary. You do not implement A.7.4 (Physical security monitoring) because it sounds like a good idea — you implement it because your risk assessment identified physical intrusion as a relevant threat to your information assets, or you exclude it because your SaaS company operates entirely from cloud infrastructure with no physical data centers to monitor.

Annex A vs. ISO 27002

Annex A lists the controls. ISO 27002 is the companion standard that provides detailed implementation guidance for each control. Think of Annex A as the table of contents and ISO 27002 as the manual. You do not need to purchase or certify against ISO 27002, but it is an invaluable reference when implementing controls.

The 2022 Restructuring: From 14 Domains to 4 Themes

The 2013 version of ISO 27001 organized Annex A into 14 control domains (A.5 through A.18). The 2022 revision reorganizes these into four high-level themes:

Theme	Controls	Focus
A.5 Organizational	37 controls	Governance, policies, roles, supplier management, legal compliance
A.6 People	8 controls	Screening, awareness, employment terms, remote working
A.7 Physical	14 controls	Secure areas, equipment protection, physical access
A.8 Technological	34 controls	Access control, cryptography, operations, development, vulnerability management

What Changed

Consolidation: Many controls from the 2013 version were merged. For example, the 2013 standard had separate controls for “information security policy” and “review of information security policy” — in 2022, these are combined into A.5.1.

Reorganization: Controls were moved to fit the four-theme structure. Access control policies, previously in their own domain (A.9), are now split between Organizational (A.5.15) and Technological (A.8.3) themes based on whether the control is a governance activity or a technical implementation.

11 new controls: The 2022 version introduces controls that did not exist in 2013, reflecting the evolution of the threat landscape and technology practices.

Control attributes: Each control now has five attributes (control type, information security property, cybersecurity concept, operational capability, security domain) that enable multi-dimensional categorization beyond the four themes.

Transition Timeline

Organizations certified under ISO 27001:2013 must transition to the 2022 version. The transition deadline has passed for most certification bodies, meaning all new certifications and surveillance audits are now against the 2022 version. If you are pursuing certification for the first time, you will certify against ISO 27001:2022.

A.5 Organizational Controls (37 Controls)

Organizational controls cover governance, management, and business-level security functions. These are the controls that define how your organization manages information security as a business function, not just a technical discipline.

Policies and Governance (A.5.1 - A.5.6)

A.5.1 — Policies for information security. An information security policy and topic-specific policies must be defined, approved by management, published, communicated, and reviewed. For SaaS companies, this means a high-level ISMS policy plus specific policies for access control, data classification, incident response, change management, and other relevant topics. See our policies guide for the complete list.

A.5.2 — Information security roles and responsibilities. Roles and responsibilities must be defined and allocated. This includes ISMS ownership (typically CISO or Head of Security), risk ownership (assigned per risk in the register), and operational security responsibilities (who patches servers, who reviews access, who manages incidents).

A.5.3 — Segregation of duties. Conflicting duties and areas of responsibility must be segregated. In SaaS terms: the person who writes code should not be the only person who approves it for production deployment. The person who provisions access should not be the same person who approves access requests.

A.5.4 — Management responsibilities. Management must require employees and contractors to apply information security in accordance with established policies. This means security responsibilities are in job descriptions, performance reviews consider security compliance, and management actively supports the ISMS rather than treating it as a security team problem.

A.5.5 — Contact with authorities. Maintain contact with relevant authorities (data protection regulators, law enforcement, sector-specific regulators). For SaaS companies operating internationally, this means knowing which authorities to contact in case of a data breach across different jurisdictions.

A.5.6 — Contact with special interest groups. Maintain contact with special interest groups and security forums. This includes ISACs (Information Sharing and Analysis Centers), industry security groups, vendor security advisory lists, and communities relevant to your technology stack.

Information Management (A.5.7 - A.5.14)

A.5.7 — Threat intelligence. Collect and analyze information about threats to the organization. For SaaS companies, this means monitoring CVE databases for vulnerabilities in your technology stack, subscribing to threat intelligence feeds, tracking industry breach reports, and monitoring for mentions of your organization in threat actor communications.

A.5.8 — Information security in project management. Integrate information security into project management. Every new feature, system change, or vendor integration should include security considerations. This is not a separate security gate but an integrated part of how projects are planned and executed.

A.5.9 — Inventory of information and other associated assets. Maintain an inventory of information assets and their owners. For SaaS companies, this includes production databases, code repositories, cloud accounts, internal SaaS tools, and the data they contain.

A.5.10 — Acceptable use of information and other associated assets. Define rules for the acceptable use of information assets and communicate them to all users. This typically manifests as an acceptable use policy covering company devices, cloud resources, customer data, and internal systems.

A.5.11 — Return of assets. Ensure that personnel return assets upon termination of employment or contract. For SaaS companies, “assets” include physical devices (laptops, phones) and logical access (deactivating accounts, revoking API keys, removing SSH keys).

A.5.12 — Classification of information. Classify information according to the organization’s needs, considering confidentiality, integrity, and availability. A three-tier scheme (Confidential, Internal, Public) works for most SaaS companies.

A.5.13 — Labelling of information. Implement labelling procedures aligned with the classification scheme. In practice, this means marking documents, emails, and data stores with their classification level. For SaaS companies, automated labelling (e.g., tagging database fields as “customer PII”) is more practical than manual document labelling.

A.5.14 — Information transfer. Establish rules and procedures for transferring information within and outside the organization. This covers email encryption, secure file sharing, API authentication for data transfers, and policies for transferring data to third parties.

Access Control and Identity (A.5.15 - A.5.18)

A.5.15 — Access control. Establish and implement rules to control physical and logical access to information. This is the policy-level control — your access control policy defines the principles (least privilege, need-to-know, role-based access) that technical controls implement. See our access control guide for detailed implementation guidance.

A.5.16 — Identity management. Manage the full lifecycle of identities — provisioning, modification, deprovisioning. For SaaS companies using centralized identity providers (Okta, Azure AD, Google Workspace), this means automated provisioning through SCIM, role-based group assignments, and prompt deprovisioning when employees leave or change roles.

A.5.17 — Authentication information. Control the allocation and management of authentication information (passwords, tokens, certificates, MFA devices). Enforce strong password policies, require MFA for all systems, and manage service account credentials through secrets management tools rather than shared spreadsheets.

A.5.18 — Access rights. Provision, review, modify, and remove access rights in accordance with the access control policy. Quarterly access reviews are the standard practice — comparing actual access against authorized access and removing discrepancies.

Supplier Management (A.5.19 - A.5.23)

A.5.19 — Information security in supplier relationships. Establish processes to manage security risks associated with the use of supplier products and services. For SaaS companies, every vendor that touches customer data, accesses production systems, or provides critical infrastructure is a supplier whose security posture affects yours. See our supplier management guide for comprehensive coverage.

A.5.20 — Addressing information security within supplier agreements. Include relevant security requirements in agreements with suppliers. This means data processing agreements, security SLAs, breach notification obligations, audit rights, and data return/deletion provisions.

A.5.21 — Managing information security in the ICT supply chain. Manage security risks in the ICT supply chain, including software dependencies, cloud service provider chains, and hardware procurement. For SaaS companies, this extends to open-source dependencies, SaaS tools used in development and operations, and the vendors’ own supply chains.

A.5.22 — Monitoring, review, and change management of supplier services. Continuously monitor, review, and manage changes to supplier security practices. Annual vendor reviews, continuous monitoring of vendor security posture, and reassessment triggered by vendor incidents or service changes.

A.5.23 — Information security for use of cloud services. Manage the acquisition, use, management, and exit from cloud services considering information security requirements. This is particularly relevant for SaaS companies — it covers your use of AWS, GCP, Azure, as well as SaaS tools in your stack.

Incident and Continuity (A.5.24 - A.5.30)

A.5.24 — Information security incident management planning and preparation. Plan and prepare for information security incident management. Develop incident response playbooks, define severity levels, establish communication protocols, and assign incident response roles.

A.5.25 — Assessment and decision on information security events. Assess events and decide whether they constitute information security incidents. Define clear criteria for what constitutes a security event versus an incident, and establish escalation procedures.

A.5.26 — Response to information security incidents. Respond to incidents in accordance with documented procedures. This includes containment, eradication, recovery, and communication — following the playbooks developed under A.5.24.

A.5.27 — Learning from information security incidents. Use knowledge gained from incidents to strengthen controls. Post-incident reviews (blameless postmortems) that produce actionable improvements and feed back into the risk assessment process.

A.5.28 — Collection of evidence. Establish procedures for the identification, collection, acquisition, and preservation of evidence. Digital forensics readiness — ensuring that logs are retained, evidence is handled with chain-of-custody procedures, and systems are configured to support investigation.

A.5.29 — Information security during disruption. Maintain information security at an appropriate level during disruption. When systems are down and you are in crisis mode, security controls still apply — incident response should not bypass access controls, and disaster recovery should not expose data through temporary workarounds.

A.5.30 — ICT readiness for business continuity. Plan, implement, maintain, and test ICT readiness to ensure business continuity. For SaaS companies, this means disaster recovery testing, failover procedures, backup restoration verification, and documented recovery time objectives (RTOs) and recovery point objectives (RPOs).

Compliance and Legal (A.5.31 - A.5.37)

A.5.31 — Legal, statutory, regulatory, and contractual requirements. Identify and document applicable legal, regulatory, and contractual requirements. For SaaS companies, this typically includes GDPR (if serving EU customers), industry-specific regulations, customer contractual obligations, and data localization requirements.

A.5.32 — Intellectual property rights. Protect intellectual property rights, including software licensing compliance. Ensure open-source license compliance, proprietary software licensing, and protection of your own IP (source code, algorithms, customer insights).

A.5.33 — Protection of records. Protect records from loss, destruction, falsification, unauthorized access, and unauthorized release. This covers both business records and evidence of ISMS operation (audit logs, risk registers, meeting minutes, policy approvals).

A.5.34 — Privacy and protection of PII. Ensure privacy and protection of personally identifiable information as required by applicable laws and regulations. For SaaS companies processing customer data containing PII, this control bridges ISO 27001 and data protection requirements like GDPR.

A.5.35 — Independent review of information security. Conduct independent reviews of the ISMS at planned intervals or when significant changes occur. This is your internal audit and management review process.

A.5.36 — Compliance with policies, rules, and standards for information security. Regularly review compliance with the organization’s information security policies and standards. Ensure that the policies you have written are actually being followed — through monitoring, auditing, and management review.

A.5.37 — Documented operating procedures. Document operating procedures for information processing facilities and make them available to personnel who need them. Runbooks, standard operating procedures, and operational documentation for systems within the ISMS scope.

A.6 People Controls (8 Controls)

People controls address the human element of information security — from hiring through employment to departure.

A.6.1 — Screening. Conduct background verification checks on candidates before employment. The level of screening should be proportionate to the role — engineers with production access to customer data warrant more thorough checks than marketing team members.

A.6.2 — Terms and conditions of employment. Employment contracts must state the employee’s and the organization’s information security responsibilities. Include confidentiality clauses, acceptable use obligations, and the consequences of policy violations.

A.6.3 — Information security awareness, education, and training. All employees must receive appropriate security awareness training, and personnel with specific security roles must receive role-specific training. Annual security awareness training for all staff, supplemented by targeted training for engineers (secure coding), administrators (cloud security), and managers (incident escalation).

A.6.4 — Disciplinary process. Establish a formal disciplinary process for employees who commit information security policy violations. The process must be communicated to all employees so they understand the consequences of non-compliance.

A.6.5 — Responsibilities after termination or change of employment. Define information security responsibilities that remain valid after termination. NDAs that survive employment, return of assets, and the requirement not to retain company information.

A.6.6 — Confidentiality or non-disclosure agreements. Identify and document confidentiality and non-disclosure requirements. NDAs for employees, contractors, and third parties who access sensitive information.

A.6.7 — Remote working. Implement security measures for remote working. For SaaS companies (where remote work is often the default), this covers VPN requirements, endpoint security, home network security guidance, and policies for working from public locations.

A.6.8 — Information security event reporting. Provide a mechanism for personnel to report observed or suspected security events. This means clear reporting channels (a Slack channel, an email alias, a ticketing system), training on what to report, and a culture that does not punish reporters.

A.7 Physical Controls (14 Controls)

Physical controls cover the security of physical environments, equipment, and utilities. For SaaS companies that operate entirely in the cloud with no physical data centers, several of these controls are candidates for exclusion in the SoA — but the exclusion must be justified, and some physical controls apply even to cloud-native organizations.

A.7.1 — Physical security perimeters. Define security perimeters around areas containing information and information processing facilities. For SaaS companies with offices, this applies to the office environment — particularly areas where sensitive work occurs (security team area, server rooms if any exist).

A.7.2 — Physical entry. Secure areas should be protected by appropriate entry controls. Badge access, visitor management, and restricted access to sensitive areas.

A.7.3 — Securing offices, rooms, and facilities. Design and implement physical security for offices, rooms, and facilities. This includes server room security (if applicable), clean desk policies, and secure storage for physical documents.

A.7.4 — Physical security monitoring. Continuously monitor premises for unauthorized physical access. CCTV, intrusion detection systems, security guards. For fully remote SaaS companies, this control may be excluded if there are no physical premises to monitor.

A.7.5 — Protecting against physical and environmental threats. Design and implement protection against physical and environmental threats (fire, flood, earthquake, power failure). Even cloud-native companies should consider the physical security of their office environments and the environmental controls their cloud providers maintain.

A.7.6 — Working in secure areas. Define and implement security measures for working in secure areas. Restrictions on electronic devices in secure areas, supervision requirements, and access logging.

A.7.7 — Clear desk and clear screen. Define rules for clear desk and clear screen. Lock screens when away from workstations, do not leave sensitive documents on desks, and secure physical media in locked storage.

A.7.8 — Equipment siting and protection. Site and protect equipment to reduce risks from environmental threats and unauthorized access. For SaaS companies, this primarily applies to employee workstations and any on-premises network equipment.

A.7.9 — Security of assets off-premises. Protect assets taken off-premises. Laptop encryption, remote wipe capability, VPN requirements, and policies for taking devices to conferences, customer sites, or home.

A.7.10 — Storage media. Manage storage media through its lifecycle — acquisition, use, transportation, and disposal. This includes hard drives, USB devices, and backup media. For SaaS companies, cloud storage lifecycle management (encryption, access control, secure deletion) is the modern equivalent.

A.7.11 — Supporting utilities. Protect information processing facilities from power failures and other utility disruptions. For cloud-native SaaS companies, your cloud provider handles this for production infrastructure — but consider UPS and backup power for your office network infrastructure.

A.7.12 — Cabling security. Protect cabling carrying power and data from interception, interference, or damage. Primarily relevant for companies with on-premises infrastructure or office networking.

A.7.13 — Equipment maintenance. Maintain equipment correctly to ensure its continued availability and integrity. For SaaS companies, this applies to employee devices (patching, hardware refresh) and any on-premises equipment.

A.7.14 — Secure disposal or re-use of equipment. Securely erase or destroy data on equipment before disposal or reuse. When decommissioning employee laptops, ensure hard drives are securely wiped or destroyed. When decommissioning cloud resources, ensure data is deleted and storage is released.

A.8 Technological Controls (34 Controls)

Technological controls are the technical security mechanisms that protect information systems. For SaaS companies, this is typically the largest and most relevant section.

Endpoint and Access (A.8.1 - A.8.5)

A.8.1 — User endpoint devices. Protect information stored on, processed by, or accessible through user endpoint devices. This means endpoint detection and response (EDR) software, disk encryption, automatic OS updates, screen lock policies, and remote wipe capability for company devices. For BYOD environments, implement Mobile Device Management (MDM) or equivalent controls.

A.8.2 — Privileged access rights. Restrict and manage the allocation and use of privileged access rights. Separate admin accounts from daily-use accounts, implement just-in-time privilege escalation, monitor privileged sessions, and conduct regular privileged access reviews.

A.8.3 — Information access restriction. Restrict access to information according to the access control policy. This is the technical implementation of the policy defined in A.5.15 — role-based access control, attribute-based access control, API authorization, and data access restrictions based on classification and need-to-know.

A.8.4 — Access to source code. Manage access to source code, development tools, and software libraries. For SaaS companies, this means repository access controls (GitHub/GitLab permissions), branch protection rules, code signing, and restricting access to build and deployment systems.

A.8.5 — Secure authentication. Implement secure authentication technologies and procedures. Multi-factor authentication for all users, SSO integration, strong password policies (or better, passwordless authentication), and secure session management.

Configuration and Vulnerability Management (A.8.6 - A.8.10)

A.8.6 — Capacity management. Monitor and adjust resource utilization to meet current and future capacity requirements. Auto-scaling configurations, capacity monitoring dashboards, alerting on resource exhaustion thresholds, and capacity planning for growth.

A.8.7 — Protection against malware. Implement protection against malware combined with user awareness. EDR/antivirus on endpoints, email filtering, web filtering, and training users to recognize phishing and malicious content.

A.8.8 — Management of technical vulnerabilities. Obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures. Vulnerability scanning, dependency scanning (SCA tools), CVE monitoring for your technology stack, patch management processes, and defined SLAs for vulnerability remediation based on severity.

A.8.9 — Configuration management. Establish, document, implement, monitor, and review configurations of hardware, software, services, and networks. Infrastructure-as-code, configuration baselines, drift detection, and immutable infrastructure patterns. This is one of the 11 new controls in 2022 and is particularly relevant for SaaS companies managing cloud infrastructure.

A.8.10 — Information deletion. Delete information when no longer required. Data retention policies with automated enforcement, secure deletion of customer data upon contract termination, and purging of temporary data stores. Another new control in 2022.

Data Protection (A.8.11 - A.8.14)

A.8.11 — Data masking. Mask data in accordance with the access control policy and business requirements. Production data should not be used in development or testing environments without masking. Customer PII should be masked in logs, analytics, and support tools where full data is not required. This is a new control in 2022.

A.8.12 — Data leakage prevention. Apply data leakage prevention measures to systems, networks, and endpoints. DLP tools on endpoints and email, restrictions on copying data to external storage, monitoring for bulk data exports, and API rate limiting to prevent data scraping. Another new control in 2022.

A.8.13 — Information backup. Maintain tested backup copies of information, software, and system configurations. Automated backups with defined RPOs, backup encryption, offsite storage, and — critically — regular restoration testing. A backup that has never been tested is not a backup.

A.8.14 — Redundancy of information processing facilities. Implement redundancy for information processing facilities sufficient to meet availability requirements. Multi-AZ deployments, database replication, load balancing, and failover mechanisms.

Logging and Monitoring (A.8.15 - A.8.16)

A.8.15 — Logging. Produce, store, protect, and analyze logs that record activities, exceptions, faults, and other relevant events. Centralized logging (ELK, Splunk, Datadog), log retention policies, tamper-evident log storage, and defined log sources (application logs, access logs, infrastructure logs, security event logs).

A.8.16 — Monitoring activities. Monitor networks, systems, and applications for anomalous behavior and take appropriate actions. SIEM or monitoring platforms that correlate events, alert on anomalies, and enable investigation. This is a new control in 2022, reflecting the importance of continuous monitoring.

Operations Security (A.8.17 - A.8.22)

A.8.17 — Clock synchronization. Synchronize clocks of information processing systems to an approved time source. NTP configuration across all systems. This seems trivial but is essential for log correlation during incident investigation.

A.8.18 — Use of privileged utility programs. Restrict and control the use of utility programs that can override system and application controls. Limit access to database administration tools, system management utilities, and debugging tools in production.

A.8.19 — Installation of software on operational systems. Implement procedures to control the installation of software on operational systems. Restrict software installation on employee devices, control what can be deployed to production, and maintain approved software lists.

A.8.20 — Networks security. Manage and control networks to protect information in systems and applications. Network segmentation, firewall rules, VPC configuration, security groups, and network access control lists in cloud environments.

A.8.21 — Security of network services. Identify, implement, and monitor security mechanisms, service levels, and management requirements for network services. This covers both internal network services and third-party network services (ISPs, CDNs, DNS providers).

A.8.22 — Segregation of networks. Segregate groups of information services, users, and information systems on networks. Production, staging, and development environments on separate networks/VPCs. Customer-facing and internal management networks segregated. Database servers not directly accessible from the internet.

Web and Application Security (A.8.23 - A.8.24)

A.8.23 — Web filtering. Filter access to external websites to reduce exposure to malicious content. DNS filtering, proxy-based web filtering, or endpoint-based URL filtering to block access to known malicious sites, phishing pages, and inappropriate content. This is a new control in 2022.

A.8.24 — Use of cryptography. Define and implement rules for the effective use of cryptography, including key management. TLS 1.2+ for all data in transit, AES-256 for data at rest, proper key management (rotation, storage in HSM or secrets manager), and a cryptographic policy defining approved algorithms.

Development Security (A.8.25 - A.8.34)

A.8.25 — Secure development lifecycle. Establish and apply rules for the secure development of software and systems. Secure coding standards, security requirements in user stories, threat modeling during design, security testing in CI/CD, and security review for production deployments.

A.8.26 — Application security requirements. Identify, specify, and approve information security requirements for developing or acquiring applications. Define security requirements (authentication, authorization, input validation, encryption) as part of the application design process.

A.8.27 — Secure system architecture and engineering principles. Establish, document, maintain, and apply principles for engineering secure systems. Defense in depth, least privilege, fail secure, input validation, secure defaults. Document these principles and ensure they are followed in architectural decisions.

A.8.28 — Secure coding. Apply secure coding principles to software development. OWASP Top 10 awareness, input validation, parameterized queries, output encoding, secure session management, and secure handling of secrets in code. This is a new control in 2022.

A.8.29 — Security testing in development and acceptance. Define and implement security testing processes in the development lifecycle. SAST (static analysis), DAST (dynamic analysis), dependency scanning, penetration testing, and security acceptance criteria for releases.

A.8.30 — Outsourced development. Direct, monitor, and review activities related to outsourced system development. When using contractors or outsourced development teams, ensure they follow your secure development practices, their code is reviewed, and their access is controlled.

A.8.31 — Separation of development, test, and operational environments. Separate development, testing, and operational environments to reduce risks of unauthorized access or changes to the operational environment. Distinct AWS accounts or GCP projects for dev, staging, and production. No production credentials in development environments. No customer data in non-production environments.

A.8.32 — Change management. Control changes to information processing facilities and information systems. Formal change management for production systems — change requests, risk assessment, approval, testing, deployment, and rollback procedures.

A.8.33 — Test information. Protect test information appropriately. Test data should be anonymized or synthetic — never use real customer data in test environments. When test data must resemble production data, use data masking (A.8.11).

A.8.34 — Protection of information systems during audit testing. Plan and agree on audit testing that involves operational systems to minimize business impact. When penetration tests or vulnerability scans target production systems, schedule them to minimize disruption and ensure rollback procedures are in place.

The 11 New Controls in ISO 27001:2022

The 2022 revision introduced 11 controls that did not exist in the 2013 version. These reflect the evolution of the threat landscape and modern technology practices:

Control	Theme	Description	SaaS Relevance
A.5.7	Organizational	Threat intelligence	High — essential for understanding threats to your stack
A.5.23	Organizational	Cloud services security	Critical — directly addresses SaaS infrastructure
A.5.30	Organizational	ICT readiness for business continuity	High — DR/BCP for cloud services
A.7.4	Physical	Physical security monitoring	Low for cloud-native SaaS; may be excluded
A.8.9	Technological	Configuration management	Critical — IaC and cloud config management
A.8.10	Technological	Information deletion	High — data lifecycle management
A.8.11	Technological	Data masking	High — protecting data in non-production environments
A.8.12	Technological	Data leakage prevention	Medium-High — DLP for endpoints and APIs
A.8.16	Technological	Monitoring activities	Critical — continuous security monitoring
A.8.23	Technological	Web filtering	Medium — endpoint protection
A.8.28	Technological	Secure coding	Critical — foundational for SaaS development

These new controls are often a focus area during audits because auditors want to verify that organizations have addressed them — particularly if transitioning from a 2013-based ISMS.

Control Attributes

ISO 27001:2022 introduces five attributes for each control, enabling multi-dimensional categorization:

Control Type

• Preventive — prevents the occurrence of a security incident
• Detective — detects the occurrence of a security incident
• Corrective — corrects the impact of a security incident after it occurs

Information Security Properties

Which of the CIA triad the control protects:

• Confidentiality
• Integrity
• Availability

Cybersecurity Concepts (NIST CSF alignment)

• Identify — understand the environment and risks
• Protect — implement safeguards
• Detect — identify security events
• Respond — act on detected events
• Recover — restore capabilities

Operational Capabilities

Groups controls by operational function:

• Governance, Asset management, Information protection, Human resource security, Physical security, System and network security, Application security, Secure configuration, Identity and access management, Threat and vulnerability management, Continuity, Supplier relationships security, Legal and compliance, Information security event management, Information security assurance

Security Domains

• Governance and ecosystem
• Protection
• Defence
• Resilience

These attributes are useful for mapping controls to other frameworks (NIST CSF, CIS Controls), generating different views of your control environment (e.g., show me all detective controls, show me all controls protecting confidentiality), and demonstrating to auditors that your control selection is thoughtful and multi-dimensional.

Typical SaaS Exclusions

Not every Annex A control is relevant to every SaaS company. The Statement of Applicability documents your inclusion and exclusion decisions with justification. Common exclusions for cloud-native SaaS companies include:

Physical Controls Often Excluded

A.7.1-A.7.6 (Physical perimeters, entry, offices, monitoring, environmental, secure areas) — If your organization is fully remote with no physical office, or if your office does not contain information processing facilities (all processing occurs in the cloud), some of these can be excluded. However, if employees work from an office with company workstations, a subset may still apply.

A.7.8 (Equipment siting and protection) — If you have no on-premises servers or networking equipment beyond standard office equipment.

A.7.11 (Supporting utilities) — If all production infrastructure is in the cloud and your office does not house critical information processing equipment.

A.7.12 (Cabling security) — If you have no on-premises data center or specialized networking infrastructure.

Controls Rarely Excluded for SaaS

Virtually no SaaS company can justify excluding:

• A.5.1 (Policies) — every ISMS needs policies
• A.5.15-A.5.18 (Access control) — every SaaS has access to manage
• A.5.24-A.5.27 (Incident management) — incidents happen to every organization
• A.8.5 (Secure authentication) — authentication is fundamental
• A.8.9 (Configuration management) — cloud configuration is always relevant
• A.8.15-A.8.16 (Logging and monitoring) — every production system needs logging
• A.8.25 (Secure development lifecycle) — every SaaS develops software

Justification Requirements

Exclusion is not a shortcut. For every excluded control, your SoA must state:

• The control being excluded (reference number and title)
• The justification — why the risk the control addresses is not applicable to your organization
• Confirmation that the exclusion does not compromise information security

“We do not have on-premises servers, therefore A.7.12 (Cabling security) is excluded because there is no cabling carrying data or power to protect within the ISMS scope” is a valid justification. “Not applicable” without explanation is not.

Mapping Controls to the Risk Treatment Plan

The risk treatment plan and Annex A controls must be explicitly connected. This mapping is the backbone of your ISMS and the primary thing auditors verify.

From Risk to Control

For each risk in your treatment plan:

1. Identify the treatment actions — what specific measures address the risk
2. Map each action to one or more Annex A controls — which control reference applies
3. Document the mapping in both the risk treatment plan and the SoA
4. Implement the control — deploy the technical or organizational measure
5. Collect evidence — demonstrate that the control is operating

From Control to Risk

For each Annex A control in your SoA:

1. Identify the risk(s) it addresses — trace back to the risk register
2. Document the risk reference in the SoA justification
3. Verify coverage — ensure no gaps where risks exist without corresponding controls

Coverage Validation

Review your mapping for completeness:

• Every risk rated above your acceptance threshold should map to at least one Annex A control (or be formally accepted)
• Every included Annex A control should map to at least one risk (or a legal/regulatory/contractual requirement)
• No orphan controls — controls implemented without a clear justification
• No orphan risks — risks above the threshold with no corresponding treatment

This cross-referencing is what transforms a checklist exercise into an integrated risk management system. Auditors specifically test this traceability, and gaps are a frequent source of nonconformity findings.

How GRCTrail Helps

GRCTrail gives SaaS teams a structured platform to manage Annex A controls from selection through implementation and ongoing monitoring.

• Interactive Annex A control catalog with SaaS-specific implementation guidance for each of the 93 controls, so your team knows exactly what each control means in a cloud-native context rather than interpreting generic ISO language
• Automated SoA generation that pulls from your risk assessment to map risks to controls, justify inclusions and exclusions, and maintain traceability — the document auditors spend the most time reviewing
• Control implementation tracking with evidence collection that links each Annex A control to its implementation status, assigned owner, and supporting evidence, ensuring nothing falls through the cracks between risk assessment and audit

Get started with GRCTrail →

Related Guides

• What Is ISO 27001? A Guide for SaaS Companies
• ISO 27001 Risk Assessment: Process, Methodology, and Examples
• ISO 27001 Statement of Applicability: How to Create It
• ISO 27001 Access Control Guide
• ISO 27001 Policies Guide
• ISO 27001 Certification Checklist
• ISO 27001 Requirements: Understanding Clauses 4-10