ISMS Copilot
ISO 27001 Glossary

What is a Control in ISO 27001?

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.

Getting help

Use ISMS Copilot to identify appropriate controls for your risks, create control implementation documentation, and develop evidence collection strategies for audit readiness.

Was this helpful?
Was this helpful?