Most enterprise buyers now request assurance artifacts before procurement. Without operational security and continuous evidence, deals stall even when teams think they're ready on paper. As a company selling into large organisations, you need to show that your security program meets recognised frameworks and withstands scrutiny from auditors and security teams. The ISO 27001 Controls List is at the heart of this conversation because it shows how you manage risk, not just whether you have policies. But it is only meaningful when the controls are embedded into your technology and business processes and when evidence of operation exists.
An Information Security Management System (ISMS) is a systematic way of managing sensitive information so that it remains secure. It covers people, processes, and technology and requires risk assessment, documentation, accountability, and ongoing improvement. When you build an ISMS, you aren't chasing a single certificate—you are putting in place a living program with metrics and evidence. The ISO 27001 Controls List is part of Annex A of the standard and is often misunderstood as a checklist. It's not a shopping list. Instead, it's a reference catalogue of controls you might use to mitigate identified risks. Controls must be justified through a risk analysis, documented in a Statement of Applicability (SoA), and routinely reviewed. When an enterprise prospect or auditor asks for your controls, they are looking for the rigour of your risk assessment and the fit between the risk and the control. When you speak with enterprise buyers, referencing the ISO 27001 Controls List demonstrates that your security program is structured and risk based.
This guide explains the structure of the ISO 27001 Controls List, its integration with risk assessment, and the four categories that organise the controls. We will connect major themes like access management, cryptography, incident response, and business continuity to the relevant controls and show how to apply them in enterprise sales and healthcare contexts. Throughout the article, I draw from Konfirmity’s experience delivering more than 6,000 audits over twenty-five years, show typical timelines and pitfalls, and use recent data from credible sources such as the ISMS site, IMS-Smart, Secureframe, Teleport, and IBM’s 2025 Cost of a Data Breach report.
What ISO 27001 Is

ISO 27001 is an international standard for information security management. It defines how organisations should set up, operate, and improve an ISMS. The standard has been refreshed several times, with ISO/IEC 27001:2022 being the current edition. When assessing your readiness for enterprise deals, focus on these aspects:
- Risk assessment and treatment: Clause 6 of ISO 27001 requires a formal risk assessment that identifies threats, vulnerabilities, and impacts. You must then decide how to address each risk—mitigate, transfer, avoid, or accept—and choose controls accordingly.
- Ten clauses: Clauses 4–10 define the mandatory requirements for context, leadership, planning, support, operation, performance evaluation, and improvement. Clause 5 calls for leadership commitment; Clause 6 mandates risk assessment and security objectives; Clause 7 deals with resources and competence; Clause 9 requires internal audits and management reviews; Clause 10 covers continual improvement.
- Annex A with 93 controls: ISO 27001:2022 reduced Annex A from 114 to 93 controls and grouped them into four categories—Organisational, People, Physical, and Technological. This revision matches modern risks like cloud services, remote work, and decentralised identities.
The ISO 27001 Controls List summarises these 93 controls. However, you only implement those relevant to your risks. For example, if you run a SaaS product with privileged access to healthcare data, you may prioritise strong access control, encryption, and incident response. The SoA must list each control, state whether you implement it, justify your decision, and provide evidence. Many auditors look at how your SoA matches your risk register and how you operationalise controls. Shortcutting this step leads to findings and delayed deals. Auditors often ask specifically to review your ISO 27001 Controls List because it reflects your security posture and how your controls link to identified risks.
How Annex A Fits With Risk Assessment

Annex A is not a mandatory checklist. IMS-Smart emphasises that Clause 6.1.3 of ISO 27001 requires organisations to compare their selected controls with Annex A and confirm that no necessary control has been overlooked. The SoA must include reasons for including or excluding each control and evidence of implementation. Teleport’s compliance guide echoes this by stating that Annex A functions as a reference framework to guide risk treatment planning; organisations must complete a SoA to document whether each control is implemented and why.
In practice, your risk assessment drives control selection. Start by identifying assets, threats, and vulnerabilities, then evaluate impact and likelihood. Prioritise high-impact risks and choose appropriate controls from the ISO 27001 Controls List. For example, if multi-factor authentication (MFA) is missing and your risk register shows a high likelihood of credential compromise, you may implement control A.8.3 (user authentication information) and A.8.2 (privileged access rights). If ransomware is a top threat, select controls on backup, disaster recovery, and incident response. When you build your ISMS, you use the ISO 27001 Controls List as a reference to ensure no essential control is missed. For risk assessments to carry authority, they must be grounded in the ISO 27001 Controls List, not on ad-hoc checklists. This catalogue provides the vocabulary to map decisions, but your risk context is unique. A client building a financial services platform may emphasise transaction integrity and logging, while a healthcare provider must protect electronic protected health information (ePHI) and comply with HIPAA safeguards.
Grouping of the control catalogue
The revised standard organises the 93 controls into four categories. According to the ISMS site, there are 37 organisational controls, eight people controls, fourteen physical controls, and 34 technological controls. A brief explanation of each category and its relevance to enterprise sales follows. Understanding how the Annex A controls list is structured helps assign responsibilities and makes it easier to maintain your SoA. Building your Statement of Applicability around the controls library clarifies which controls you implement and why, and it provides a defensible narrative for auditors.
Organisational Controls (37)
These controls govern policies, governance, compliance requirements, and supplier engagements. For enterprises selling to regulated clients, organisational controls demonstrate management’s commitment to security. Examples include information security policies, supplier risk management, business continuity planning, and governance structures.
People Controls (8)
People control focus on training, awareness, and assigning roles. They are critical because many breaches originate from human error or malicious insiders. Screening, regular training, disciplinary processes, and remote working security are essential measures.
Physical Controls (14)
Physical controls protect the environment where information and assets reside. Secure areas and perimeters, equipment siting, secure disposal of hardware, and clear desk policies assure clients that you manage physical risk.
Technological Controls (34)
Technological controls address computer systems. They include access control and authentication, cryptography and secret management, vulnerability and patch management, monitoring and logging, and incident management. Many enterprise buyers focus on these because they relate directly to the systems they integrate with.
Mapping Semantic Topics to Controls
To make the control inventory actionable, map your security program themes to specific controls. Common themes encountered in enterprise sales and healthcare compliance include:
- Information security management and risk assessment: Use organisational controls to document policies, roles, and risk mitigation. Maintain a risk register that ties each risk to a control and update it when risks change.
- Access control and identity management: Controls A.8.2–A.8.4 cover user access management, privileged access rights, and authentication. Implement SSO, MFA, and just-in-time privileged access. Conduct regular access reviews and document evidence.
- Cryptography and data encryption: Controls A.8.11 and A.8.12 mandate encryption and data leakage prevention. Deploy encryption for sensitive fields, manage cryptographic secrets, and document your protocols.
- Incident management: Controls A.5.24 and A.5.27 require incident planning and learning. Prepare a response plan with roles, severity tiers, and reporting channels. After incidents, perform root cause analysis and update controls.
- Network security and vulnerability management: Technological controls like A.8.7, A.8.8, and A.8.9 cover segmentation, testing, and configuration management. Use intrusion detection, penetration tests, and change management.
- Monitoring and logging: Control A.8.15 requires monitoring activities. Collect logs, configure alerts, and protect logs from unauthorised modification. SOC 2 also requires monitoring.
- Business continuity and resilience: Controls A.5.30 and A.8.14 focus on readiness for business continuity. Define recovery objectives, test plans, and involve important suppliers.
- Supplier relationships: Controls A.5.19–A.5.22 require risk assessments, contractual clauses, and monitoring. Evaluate your cloud providers and subcontractors, include right-to-audit clauses, and track remediation of findings.
Mapping your security themes to the ISMS controls list ensures consistency with the standard and shows auditors that you have thought about the intersection between risks and controls. Cross-referencing your risk themes with the security control list helps you systematically address threats rather than treating them piecemeal.
Practical Examples for Busy Teams
To move from theory to practice, consider these concise examples:
- Access control policy: A SaaS vendor selling into a regulated industry can state that all internal applications must integrate with a central identity provider, enforce MFA, and restrict privileged roles. Managers must approve access requests, logged, and reviewed quarterly. Evidence includes identity provider configuration, approval workflows, and access review records.
- Incident management flow: Create a diagram showing how incidents are reported, triaged, escalated, and resolved. When a suspected breach is detected, the on-call engineer logs the incident, notifies the security lead, and gathers logs. The security lead assesses severity, involves legal counsel if personal data is affected, and informs impacted clients. After resolution, a review identifies lessons and updates controls.
- Risk assessment tied to vendor management: When onboarding a vendor that processes personal data, perform a risk assessment that considers data sensitivity, volume, and regulatory requirements. Assign a risk rating, decide on controls such as contractual clauses, encryption, and monitoring, and document them in your SoA. Re-assess annually or when the vendor’s scope changes.
These examples show that the Annex A catalogue is not abstract. It translates into tangible actions and evidence that auditors and enterprise buyers will examine.
Integrating ISO 27001 Controls With Enterprise Sales
Enterprise procurement teams use security questionnaires and audits to evaluate vendors. Having a documented control set aligned to ISO 27001 accelerates this process. Here’s how the set of Annex A controls helps:
- RFP and due-diligence responses: When a prospect sends a security questionnaire, map their questions to your controls. If the questionnaire asks about encryption, reference controls A.8.11 and A.8.12 and provide evidence of encryption at rest and in transit. If they ask about change management, point to A.8.7 and A.8.9 and include your change approval records.
- Evidence library: Maintain an evidence library with policies, procedures, logs, and audit reports. This library should match your SoA and risk register. For a healthcare prospect, include evidence that demonstrates compliance with HIPAA’s security rule; for European clients, include GDPR data processing agreements and records of processing activities.
- Consistency across frameworks: Many enterprises require SOC 2 Type II or HIPAA attestation in addition to ISO 27001. You can cross-map controls to multiple frameworks. For instance, ISO control A.8.15 corresponds with SOC 2’s system monitoring criterion, and A.5.19 corresponds with HIPAA’s administrative safeguards. By reusing evidence across frameworks, you reduce duplication and speed up due diligence.
- Konfirmity’s approach: Our human-led managed service delivers end-to-end security and compliance. We don’t just advise; we execute. When supporting clients through ISO 27001 and SOC 2 readiness, we build the ISMS, implement controls inside their stack, manage evidence collection, and stay with them year-round. Typical readiness for a SOC 2 Type II audit takes four to five months with our approach compared with nine to twelve months when teams attempt it alone. Clients spend around seventy-five hours across the year on activities we ask of them, versus 550–600 hours if they manage it internally. This efficiency comes from matching security operations with control requirements and automating evidence capture.
During RFP responses, referencing the Annex controls list gives buyers confidence that your program aligns with an internationally recognised standard. Sales teams often rely on the ISO 27001 Controls List when crafting answers to security questionnaires, because it matches the language used by auditors and procurement reviewers.
Common Mistakes and How to Avoid Them

Organisations often misstep when adopting ISO 27001. Avoid these pitfalls:
- Treating Annex A as a checklist: Annex A is a reference, not a mandatory set. Selecting controls without a risk assessment leads to mismatches and weak justifications. Auditors will ask why certain controls are excluded or included and will expect to see risk-driven reasoning.
- Ignoring risk assessment: Some teams choose controls because peers do. Instead, conduct a thorough risk assessment and ensure that controls correspond to your threats and legal obligations. Use CVSS scores to prioritise vulnerabilities and document risk acceptance decisions.
- Overlooking people and physical controls: Technical controls are important, but many breaches involve human error or physical theft. Invest in training, enforce disciplinary processes, and secure physical environments.
- Evidence gaps: Having a control on paper is not enough. Auditors will request evidence that controls operate effectively over time. For SOC 2 Type II, the observation window is typically three to six months. Without continuous monitoring and documented evidence, you risk failing the audit.
Market Context and Cross-Framework Synergy
The importance of sound security controls is underscored by recent data. IBM’s 2025 Cost of a Data Breach report, summarised in independent analyses, found that the global average cost of a breach dropped slightly to around $4.44 million in 2025 after five years of increases. Detection and escalation costs fell to just under $1.5 million, and the average cost per breach in the US rose to $10.22 million. Healthcare remained the costliest sector at $7.42 million, though down from $9.77 million in 2024. The same report noted that a DevSecOps approach can reduce breach costs by more than $200,000. These numbers show that while breaches are becoming somewhat cheaper on average, they remain a significant risk—particularly in regulated industries—and that proactive security programmes pay off.
The October 31, 2025 deadline to transition from ISO 27001:2013 to ISO 27001:2022 means auditors will expect to see the revised control categories and SoA structure. Teleport notes that organisations must update their certification by this date and that the revised Annex A introduced controls focusing on cloud services, remote work, and decentralised identities. Because security breaches trigger multiple frameworks, a unified program that uses the security controls catalogue as its backbone and maps to SOC 2, HIPAA, and GDPR reduces duplication and supports cross-framework compliance. A sound implementation of the set of controls positions you well for cross-framework compliance and gives regulators and buyers confidence. In regulatory investigations, regulators ask whether a company has followed the overall controls inventory when designing its ISMS, which underscores the list’s importance in demonstrating due diligence.
Konfirmity’s experience shows that strong access control, encryption, monitoring, incident response, and vendor risk management are universal across frameworks. By implementing these controls once and matching them to each framework’s language—Trust Services Criteria for SOC 2, administrative and technical safeguards for HIPAA, and GDPR’s data protection principles—you can answer client questions quickly and provide consistent evidence.
Conclusion
Security that reads well in documents but fails under incident pressure is a liability. Enterprise buyers and healthcare regulators are not looking for polished policies; they want evidence of a program that withstands threats and supports continuous operation. ISO 27001 provides a foundation for building such a program, but its value comes from how you implement and operate the controls. Select controls based on a rigorous risk assessment, document your decisions in the SoA, and maintain evidence of continuous operation. Use the Annex list of controls as a guide, not a checklist. Match your implementation to other frameworks like SOC 2, HIPAA, and GDPR to streamline compliance and shorten sales cycles.
At Konfirmity, our human-led, managed security and compliance service delivers outcomes. We design and run your program, implement controls in your stack, collect evidence, and prepare you for audits. With more than 6,000 audits supported and twenty-five years of combined expertise, we know what works and what doesn’t. The message to every security leader and business owner is clear: build a durable security program once, operate it daily, and let compliance follow.
FAQs
1) How many controls does ISO 27001 have?
ISO 27001:2022 Annex A contains 93 controls grouped into four categories—Organisational, People, Physical, and Technological.
2) What are the 93 controls?
They are documented measures that address topics such as policies, supplier risk, business continuity, training, access management, cryptography, monitoring, and incident response. You only implement those relevant to your risk assessment, and you must justify your decisions in the SoA.
3) What are the 4 categories of ISO 27001?
The controls are organised into four groups: 37 organisational controls, eight people controls, fourteen physical controls, and 34 technological controls.
4) What are the 10 clauses of ISO 27001?
Clauses 4–10 define the core requirements of the ISMS: understanding the organisation and its context, leadership and commitment, planning including risk assessment, support in terms of resources and competence, operation, performance evaluation via audits and metrics, and continual improvement. Clause 0–3 provides introduction, normative references, and terms.





