Overview
A control in ISO 27001 is a measure that modifies or reduces information security risk. Controls are policies, procedures, practices, organizational structures, or technical mechanisms that protect the confidentiality, integrity, and availability of information assets.
What it means in practice
Controls are the "how" of security - the specific actions you take to address identified risks. After risk assessment identifies threats, controls are the countermeasures you implement to reduce those risks to acceptable levels.
Real-world example: If risk assessment identifies "unauthorized access to customer database" as a high risk, you might implement controls including: access control policy (organizational control), multi-factor authentication (technical control), and security awareness training (people control). Together, these controls reduce the risk.
Types of controls
By function
Preventive controls: Stop security incidents before they occur (access controls, firewalls, encryption)
Detective controls: Identify security incidents when they happen (monitoring, logging, intrusion detection)
Corrective controls: Reduce impact after incidents occur (backup restoration, incident response procedures)
By nature
Technical controls: Technology-based measures (encryption, authentication, malware protection)
Organizational controls: Policies, procedures, and management practices (risk management, asset classification)
Physical controls: Protect physical environment (locks, surveillance, facility access)
People controls: Human-focused measures (training, screening, NDAs)
By implementation approach
Administrative controls: Documented rules and procedures
Logical controls: Software and system-based controls
Physical controls: Tangible protective measures
Annex A controls
ISO 27001:2022 Annex A lists 93 specific controls organized into four themes that organizations can select from based on risk assessment:
Organizational controls (A.5.1-A.5.37): 37 controls for governance, policies, asset management, supplier management, incident management
People controls (A.6.1-A.6.8): 8 controls for employment lifecycle and human-related risks
Physical controls (A.7.1-A.7.14): 14 controls for facility security and physical asset protection
Technological controls (A.8.1-A.8.34): 34 controls for IT security, access management, and technical safeguards
Control selection: You're not required to implement all 93 Annex A controls. Your risk assessment determines which controls are necessary. Document control selection decisions in your Statement of Applicability.
Control objectives vs. controls
Control objective
The desired outcome or security goal (e.g., "prevent unauthorized access to sensitive data").
Control
The specific measure implementing the objective (e.g., "multi-factor authentication for all users accessing customer database").
Why the distinction matters
ISO 27001 Annex A lists control objectives. How you implement each control depends on your organizational context, technology, and risk profile. Two organizations can achieve the same objective with different implementations.
Proportional implementation: A small startup might implement "security awareness training" (A.6.3) through monthly team meetings, while an enterprise might use a learning management system with role-based curricula. Both satisfy the control objective if appropriate to their context.
Control effectiveness
What makes a control effective
Controls must actually reduce risk, not just exist on paper. Effective controls are:
Implemented: Actually deployed and operational
Appropriate: Suitable for the risk and organizational context
Measurable: You can verify they're working
Consistent: Applied uniformly across the organization
Maintained: Kept current as risks and environment change
Testing control effectiveness
Document review: Verify control documentation exists and is current
Observation: Watch controls in operation
Interview: Confirm staff understand and follow control procedures
Technical testing: Verify technical controls operate as configured
Evidence sampling: Review records proving ongoing control operation
Common audit finding: Controls documented in policies but not actually implemented or maintained. Auditors verify controls operate effectively, not just that you have nice documentation.
Compensating controls
When compensating controls are used
Sometimes you can't implement a specific control due to technical limitations, cost constraints, or operational reasons. Compensating controls are alternative measures that achieve the same risk reduction.
Requirements for compensating controls
Provide similar or better risk reduction than the original control
Address the same control objective
Be documented and justified in your Statement of Applicability
Be acceptable to auditors and stakeholders
Examples
Original control: Network segmentation to isolate sensitive systems
Compensating control: Enhanced monitoring and access controls if network architecture prevents segmentation
Original control: Biometric access for server room
Compensating control: Badge access with CCTV monitoring and access logs if biometrics aren't feasible
Control evidence
What auditors look for
For each implemented control, auditors request evidence proving:
Existence: The control is established (policy documents, system configurations)
Operation: The control functions regularly (logs, reports, records)
Effectiveness: The control reduces risk (metrics, test results, incident data)
Evidence examples by control type
Policy controls: Approved policy documents, version history, staff acknowledgments
Technical controls: Configuration screenshots, system logs, scan reports
Process controls: Completed checklists, workflow tickets, review records
Training controls: Completion certificates, attendance logs, test scores
Evidence strategy: Build evidence collection into control operation from the start. Quarterly access reviews generate evidence for access management controls, backup job logs prove backup controls operate, training completion reports support awareness controls.
Control lifecycle
1. Selection (Planning)
Based on risk assessment, identify which controls address identified risks. Document in Statement of Applicability.
2. Implementation (Deployment)
Deploy selected controls with appropriate scope, timing, and resources. Create policies, configure systems, train staff.
3. Operation (Day-to-day)
Execute controls as part of normal business operations. Generate evidence through logs, reports, and records.
4. Monitoring (Ongoing)
Track control effectiveness through metrics, reviews, and testing. Identify control failures or weaknesses early.
5. Review (Periodic)
Assess whether controls remain appropriate as risks, technology, and business change. Update or retire controls as needed.
6. Improvement (Continuous)
Enhance controls based on incidents, audit findings, new threats, or technology improvements.
Common control implementation mistakes
Implementing controls without risk assessment
Selecting controls based on templates or "best practices" rather than your actual risk assessment. This wastes resources and may leave gaps.
Over-documentation, under-implementation
Creating extensive policies and procedures but not actually deploying or operating the controls.
Set-and-forget mentality
Implementing controls once during certification preparation but not maintaining them or collecting ongoing evidence.
No effectiveness measurement
Assuming controls work without testing or measuring their impact on risk reduction.
Point solutions instead of defense in depth
Relying on single controls rather than layered defenses. One control failure shouldn't result in total compromise.
Best practice: Implement controls in layers (defense in depth). For example, protect sensitive data with: classification policy (organizational), access controls (technical), encryption (technical), monitoring (detective), and backups (corrective). If one control fails, others still provide protection.
Control maturity levels
Level 1: Initial/Ad hoc
Controls exist informally or inconsistently. No documentation or standardization.
Level 2: Repeatable
Controls are documented and generally followed, but implementation varies by department or individual.
Level 3: Defined
Controls are standardized, documented, and consistently implemented across the organization.
Level 4: Managed
Controls are measured and monitored. Metrics track effectiveness and performance.
Level 5: Optimized
Controls are continuously improved based on metrics, incidents, and changing risk environment.
ISO 27001 certification typically requires Level 3 (defined and consistent). Mature organizations aim for Level 4-5.
Controls in different frameworks
ISO 27001 controls
93 controls in Annex A, risk-based selection, internationally recognized.
NIST frameworks
NIST CSF uses five functions (Identify, Protect, Detect, Respond, Recover). NIST 800-53 provides detailed control catalog primarily for U.S. federal systems.
SOC 2 trust service criteria
Security, Availability, Processing Integrity, Confidentiality, Privacy criteria with control requirements specific to service organizations.
PCI DSS requirements
12 requirements focused on protecting payment card data, mandatory for organizations handling card payments.
Many controls overlap across frameworks. ISO 27001's risk-based approach often addresses requirements from multiple frameworks simultaneously.
Related concepts
Annex A Controls - The 93 specific controls in ISO 27001:2022
Risk Assessment - Process that determines which controls to implement
Statement of Applicability - Document listing your control selections
Risk Treatment - Implementing controls to address risks
Getting help
Use ISMS Copilot to identify appropriate controls for your risks, create control implementation documentation, and develop evidence collection strategies for audit readiness.