09 Annex A Controls Overview

ISO/IEC 27001 establishes the requirements for building and operating an Information Security Management System (ISMS).

Annex A provides a reference set of information-security controls that organizations consider when treating information-security risks.

In ISO/IEC 27001:2022, Annex A contains 93 controls organized into four themes:

Annex	Control Theme	Controls
A.5	Organizational Controls	37
A.6	People Controls	8
A.7	Physical Controls	14
A.8	Technological Controls	34
Total		93

The structure can be visualized as:

ISO/IEC 27001
      ↓
ISMS Requirements
      ↓
Risk Assessment
      ↓
Risk Treatment
      ↓
Annex A Reference Controls
      │
      ├── A.5 Organizational — 37
      ├── A.6 People — 8
      ├── A.7 Physical — 14
      └── A.8 Technological — 34
      ↓
Statement of Applicability
      ↓
Control Implementation
      ↓
Evidence & Assurance

For GRC professionals, understanding Annex A is important because these controls frequently become the foundation for:

Control libraries.
Risk-treatment decisions.
Policies and standards.
Statement of Applicability entries.
Evidence requirements.
Internal audits.
Certification audits.
Compliance mappings.

The objective is not to memorize 93 control names.

The objective is to understand what security outcome each control is intended to support and how to translate it into an operational enterprise control environment.

Learning Objectives

By the end of this lesson, you will be able to:

Explain the purpose of Annex A.
Understand the four Annex A control themes.
Explain how Annex A relates to risk treatment.
Understand the difference between Annex A and the ISMS requirements.
Recognize the major control areas within A.5, A.6, A.7, and A.8.
Translate reference controls into enterprise control statements.
Assign control ownership.
Define control frequency.
Identify appropriate evidence.
Understand control design and operating effectiveness.
Map controls to risks.
Map controls to policies and standards.
Map ISO controls to other frameworks.
Support Statement of Applicability decisions.
Prepare Annex A controls for assurance and audit.

1. What Is Annex A?

Annex A is a reference control set included within ISO/IEC 27001.

It provides organizations with security controls that should be considered when determining how identified information-security risks will be treated.

Think of it as:

Risk
   ↓
Treatment Required
   ↓
Which safeguards could reduce the risk?
   ↓
Consider Annex A

Annex A therefore supports risk treatment.

2. Annex A Is Not a Standalone Security Program

A common misconception is:

Implement 93 Controls
      =
ISO 27001

That is incorrect.

ISO/IEC 27001 includes management-system requirements covering areas such as:

Organizational Context

Leadership

Planning

Support

Operation

Performance Evaluation

Improvement

Annex A is only one part of the wider ISMS.

3. Annex A and Risk-Based Thinking

The process should generally look like:

Business Context
      ↓
Information Assets & Services
      ↓
Risk Assessment
      ↓
Risk Evaluation
      ↓
Risk Treatment
      ↓
Control Selection
      ↓
Annex A Review
      ↓
Statement of Applicability

Controls should support identified risks and requirements.

4. Do We Implement All 93 Controls?

Not automatically.

Organizations should consider the Annex A reference controls when determining necessary controls.

A control may be:

Applicable

Not Applicable

Where applicable, implementation may also be:

Implemented

Partially Implemented

Planned

Inherited

Shared

Applicability decisions should be documented in the Statement of Applicability.

5. Annex A Control Structure

ISO/IEC 27001:2022 organizes the controls into:

A.5 Organizational Controls
        37

A.6 People Controls
         8

A.7 Physical Controls
        14

A.8 Technological Controls
        34

Total:

37 + 8 + 14 + 34 = 93

6. Why the Four Themes Matter

The themes show that information security is broader than technology.

Security depends on:

Governance
+
People
+
Physical Environment
+
Technology

A strong ISMS addresses all four.

7. A.5 — Organizational Controls

A.5 contains 37 Organizational Controls.

These address governance and operational security processes across the organization.

Major areas include:

Security Governance

Roles & Responsibilities

Segregation of Duties

Threat Intelligence

Asset Management

Information Classification

Access Governance

Supplier Security

Cloud Services

Incident Management

Business Continuity

Legal & Regulatory Compliance

Privacy

Independent Review

Policy Compliance

Operating Procedures

These controls often have significant GRC involvement.

8. A.5.1 — Policies for Information Security

Organizations should establish appropriate information-security policies.

Typical artifacts include:

Information Security Policy

Access Control Policy

Acceptable Use Policy

Cryptography Policy

Incident Response Policy

Third-Party Security Policy

GRC frequently coordinates the policy lifecycle.

9. A.5.2 — Information Security Roles and Responsibilities

Security responsibilities should be defined and allocated.

Example:

CISO
→ Security Governance

IAM
→ Identity Controls

SOC
→ Monitoring

GRC
→ Risk & Compliance

Engineering
→ Technical Security

Clear ownership improves accountability.

10. A.5.3 — Segregation of Duties

Conflicting responsibilities should be separated where appropriate.

Example:

Developer
      ↓
Creates Change

Different Person
      ↓
Approves Change

This helps reduce fraud, error, and unauthorized activity.

11. A.5.4 — Management Responsibilities

Management should ensure personnel apply information security according to organizational requirements.

This connects leadership to control operation.

12. A.5.5 — Contact with Authorities

Organizations may need defined relationships with:

Regulators.
Law enforcement.
Data-protection authorities.
Government agencies.

These contacts may become important during incidents.

13. A.5.6 — Contact with Special Interest Groups

Organizations may participate in:

Industry Security Groups

Information Sharing Communities

Professional Associations

Security Forums

These can support awareness of emerging threats and good practices.

14. A.5.7 — Threat Intelligence

Organizations should gather and analyze information about relevant threats.

Sources may include:

Vendor Advisories

CERT Notifications

ISACs

Threat Intelligence Platforms

Internal Incident Data

Threat intelligence can support risk assessment and security operations.

15. A.5.8 — Information Security in Project Management

Security should be incorporated into project management.

Example:

Project Initiated
      ↓
Security Requirements
      ↓
Risk Assessment
      ↓
Architecture Review
      ↓
Security Testing
      ↓
Production

Security should not be added only after deployment.

16. A.5.9 — Inventory of Information and Other Associated Assets

Organizations should identify relevant assets.

Examples:

Applications

Databases

Cloud Accounts

Endpoints

Information

Infrastructure

SaaS Platforms

Asset inventories support risk management.

17. A.5.10 — Acceptable Use

Rules should define acceptable use of information and associated assets.

Examples include:

Corporate devices.
Internet access.
Email.
Cloud storage.
Software installation.

18. A.5.11 — Return of Assets

When employment or contracts end, organizational assets should be returned.

Examples:

Laptop

Access Badge

Mobile Device

Security Token

Documents

This commonly forms part of offboarding.

19. A.5.12 — Classification of Information

Information should be classified according to organizational requirements.

Example:

Public

Internal

Confidential

Restricted

Classification helps determine protection requirements.

20. A.5.13 — Labelling of Information

Organizations should establish appropriate information-labelling procedures.

Examples:

Document Labels

Email Labels

Data Classification Tags

Labels help users understand handling requirements.

21. A.5.14 — Information Transfer

Information transfers should be appropriately protected.

This can include:

Email

APIs

File Transfer

Cloud Sharing

Physical Media

Security should consider confidentiality, integrity, and authorization.

22. A.5.15 — Access Control

Organizations should establish rules governing physical and logical access.

The principle is:

Right Person

Right Access

Right Resource

Right Reason

This is a foundational security control.

23. A.5.16 — Identity Management

Identity lifecycle processes should be managed.

Example:

Joiner
   ↓
Identity Created

Mover
   ↓
Access Changed

Leaver
   ↓
Access Removed

Identity management supports numerous technical controls.

24. A.5.17 — Authentication Information

Authentication information should be appropriately allocated and managed.

Examples:

Passwords.
Secrets.
Authentication tokens.
Recovery credentials.

25. A.5.18 — Access Rights

Access rights should be:

Provisioned

Reviewed

Modified

Removed

according to business need.

Evidence may include access-review reports.

26. Supplier Security Controls

A.5 includes several controls related to suppliers.

These cover areas such as:

Supplier Relationships

Supplier Agreements

ICT Supply Chain

Supplier Monitoring

Supplier Changes

Cloud Services

These controls are central to Third-Party Risk Management.

27. Supplier Relationship Example

Vendor Selected
      ↓
Security Assessment
      ↓
Contract Requirements
      ↓
Onboarding
      ↓
Monitoring
      ↓
Reassessment
      ↓
Offboarding

This is a typical TPRM lifecycle.

28. Cloud Service Security

Cloud services require lifecycle governance.

Example:

Cloud Service Acquisition
      ↓
Risk Assessment
      ↓
Security Requirements
      ↓
Configuration
      ↓
Monitoring
      ↓
Change Management
      ↓
Exit Strategy

This is particularly relevant to modern enterprises.

29. Incident Management Controls

A.5 also addresses:

Incident Preparation

Event Assessment

Incident Response

Lessons Learned

Evidence Collection

These support structured security-incident management.

30. ICT Readiness for Business Continuity

Security and technology should support business continuity requirements.

Example:

Business Impact Analysis
      ↓
Recovery Requirements
      ↓
Technology Resilience
      ↓
Recovery Testing

Security must consider availability as well as confidentiality.

31. Legal, Regulatory and Contractual Requirements

Organizations should identify and manage applicable obligations.

Examples:

Privacy Law

Industry Regulation

Customer Contracts

Software Licensing

Security Commitments

GRC typically plays a major role here.

32. Protection of Records

Records should be protected against:

Loss.
Destruction.
Unauthorized access.
Unauthorized alteration.

Retention requirements should also be considered.

33. Privacy and Protection of PII

Organizations should identify and meet relevant privacy and personally identifiable information requirements.

This may involve:

Data Inventory

Privacy Requirements

Retention

Access Controls

Data Subject Processes

34. Independent Review of Information Security

Information security should be independently reviewed at planned intervals or after significant changes.

Examples:

Internal Audit

External Assessment

Independent Security Review

This provides assurance.

35. Compliance with Policies and Standards

Organizations should verify compliance with internal security requirements.

Example:

Security Standard
      ↓
Assessment
      ↓
Gap Identified
      ↓
Remediation

36. Documented Operating Procedures

Operational security activities should be documented where appropriate.

Examples:

User Provisioning Procedure

Backup Procedure

Incident Procedure

Vendor Review Procedure

This supports consistency.

37. A.6 — People Controls

A.6 contains 8 People Controls.

These address security throughout the employment and workforce lifecycle.

Major areas include:

Screening

Terms of Employment

Security Awareness

Disciplinary Process

Responsibilities After Employment

Confidentiality Agreements

Remote Working

Security Event Reporting

38. Screening

Organizations should perform appropriate background verification where permitted and relevant.

The level of screening should reflect:

Role

Access Level

Risk

Legal Requirements

39. Terms and Conditions of Employment

Employment agreements should define relevant information-security responsibilities.

Examples:

Confidentiality.
Acceptable use.
Security responsibilities.
Compliance obligations.

40. Security Awareness and Training

Personnel should receive appropriate security education and awareness.

Examples:

Security Induction

Annual Awareness

Phishing Training

Role-Based Training

Training should be relevant to role and risk.

41. Disciplinary Process

Organizations should establish a formal process for security-policy violations.

This supports consistent enforcement.

42. Responsibilities After Termination or Change

Security obligations may continue after:

Termination

Role Change

Contract Completion

Examples include confidentiality obligations and access removal.

43. Confidentiality Agreements

NDAs and confidentiality agreements should be identified, documented, and reviewed where appropriate.

These protect sensitive information.

44. Remote Working

Remote work should be appropriately secured.

Consider:

Endpoint Security

VPN / Zero Trust Access

Physical Environment

Data Handling

Authentication

Monitoring

45. Security Event Reporting

Personnel should know how to report suspected security events.

Example:

Employee Detects Suspicious Email
      ↓
Reports to Security
      ↓
SOC Investigates

Fast reporting can reduce incident impact.

46. A.7 — Physical Controls

A.7 contains 14 Physical Controls.

These protect:

Facilities

Equipment

Information

Personnel

Physical Infrastructure

Physical security remains relevant even in cloud-first organizations.

47. Physical Security Perimeters

Secure areas may require defined physical boundaries.

Examples:

Office

Server Room

Data Center

Restricted Area

48. Physical Entry

Access should be restricted to authorized individuals.

Controls may include:

Badges

Biometrics

Security Guards

Visitor Logs

49. Securing Offices and Facilities

Physical locations should be protected according to risk.

This may include:

Doors.
Locks.
Alarms.
Restricted areas.

50. Physical Security Monitoring

Organizations may use:

CCTV

Intrusion Detection

Security Guards

Access Logs

Evidence can demonstrate operation.

51. Environmental and Physical Threats

Organizations should consider threats such as:

Fire

Flood

Power Failure

Extreme Weather

Civil Disturbance

Physical risk assessment remains important.

52. Working in Secure Areas

Personnel working in secure areas should follow appropriate security procedures.

This may restrict:

Photography.
Unauthorized devices.
Visitors.
Unsupervised access.

53. Clear Desk and Clear Screen

Sensitive information should not be unnecessarily exposed.

Examples:

Documents Stored Securely

Screens Locked

Whiteboards Cleared

Simple controls can reduce information exposure.

54. Equipment Placement and Protection

Equipment should be located and protected to reduce environmental and unauthorized-access risks.

55. Security of Assets Off-Premises

Assets outside organizational facilities require protection.

Examples:

Employee Laptop

Mobile Device

Portable Storage

Remote Equipment

This is increasingly important with hybrid work.

56. Storage Media

Storage media should be appropriately managed through its lifecycle.

Example:

Acquire
 ↓
Use
 ↓
Store
 ↓
Transfer
 ↓
Dispose

57. Supporting Utilities

Critical equipment may depend on:

Electricity

Cooling

Telecommunications

Water

Disruption can affect availability.

58. Cabling Security

Power and telecommunications cabling should be protected where relevant.

This helps reduce:

Interference.
Damage.
Unauthorized interception.

59. Equipment Maintenance

Equipment should be properly maintained to support availability and integrity.

60. Secure Disposal or Reuse of Equipment

Before disposal or reuse:

Identify Data
      ↓
Securely Erase
      ↓
Verify
      ↓
Dispose / Reuse

Evidence may include destruction certificates.

61. A.8 — Technological Controls

A.8 contains 34 Technological Controls.

These address technical security across:

Endpoints

Identity

Infrastructure

Networks

Applications

Cloud

Development

Monitoring

Data

These controls are particularly relevant to security engineering teams.

62. User Endpoint Devices

Endpoints should be appropriately protected.

Examples:

EDR

Encryption

Patch Management

Configuration Baseline

Screen Lock

63. Privileged Access Rights

Privileged access should be restricted and controlled.

Example:

Admin Request
      ↓
Approval
      ↓
PAM
      ↓
Time-Limited Access
      ↓
Monitoring

Privileged access is a major enterprise risk area.

64. Information Access Restriction

Access should be limited according to established access-control requirements.

Common principles include:

Least Privilege

Need to Know

Role-Based Access

65. Access to Source Code

Source code should be appropriately protected.

Possible controls:

Repository Access Control

Branch Protection

MFA

Code Review

Audit Logging

66. Secure Authentication

Authentication should be implemented based on risk and security requirements.

Modern controls may include:

MFA

Phishing-Resistant Authentication

Conditional Access

SSO

67. Capacity Management

Organizations should monitor resource usage and plan capacity.

Security relevance includes availability.

Example:

Resource Exhaustion
      ↓
Service Degradation
      ↓
Customer Impact

68. Protection Against Malware

Organizations should implement malware protections appropriate to risk.

Examples:

EDR

Email Security

Application Control

User Awareness

69. Management of Technical Vulnerabilities

A practical lifecycle:

Discover
   ↓
Assess
   ↓
Prioritize
   ↓
Remediate
   ↓
Verify

This may include vulnerability scanning and patch management.

70. Configuration Management

Systems should maintain secure configurations.

Examples:

Secure Baselines

Hardening Standards

Infrastructure as Code

Configuration Monitoring

Misconfiguration is a major cloud and infrastructure risk.

71. Information Deletion

Information should be securely deleted when no longer required.

Deletion should consider:

Retention Requirements

Backups

Cloud Copies

Legal Holds

72. Data Masking

Sensitive data may need masking.

Examples:

Production Database
      ↓
Masked Dataset
      ↓
Development Environment

This reduces unnecessary exposure.

73. Data Leakage Prevention

Organizations may use technical measures to detect or prevent unauthorized data transfer.

Examples:

Endpoint DLP

Email DLP

Cloud DLP

CASB

74. Information Backup

Backups should support business and recovery requirements.

Important factors include:

Backup Frequency

Retention

Encryption

Isolation

Recovery Testing

A backup that cannot be restored provides little assurance.

75. Redundancy

Critical processing facilities may require redundancy.

Examples:

Multiple Availability Zones

Multiple Network Paths

Redundant Systems

This supports resilience.

76. Logging

Security-relevant events should be logged.

Examples:

Authentication

Privilege Changes

Administrative Actions

Security Alerts

System Events

Logging supports detection and investigation.

77. Monitoring Activities

Organizations should monitor systems and networks for anomalous behavior.

Example:

Logs
 ↓
SIEM
 ↓
Detection
 ↓
SOC Investigation
 ↓
Incident Response

78. Clock Synchronization

System clocks should be synchronized appropriately.

Why?

Because incident timelines depend on accurate timestamps.

79. Privileged Utility Programs

Powerful system utilities should be tightly controlled.

These tools may bypass normal controls.

80. Software Installation

Software installation on operational systems should be controlled.

This reduces:

Malware.
Unsupported software.
Licensing issues.
Configuration drift.

81. Network Security

Networks should be secured and managed.

Examples:

Firewalls

Segmentation

Secure Routing

Network Monitoring

Zero Trust Controls

82. Security of Network Services

Security requirements should be defined for network services.

This applies to:

Internal services.
Telecom providers.
Cloud connectivity.
Managed network services.

83. Network Segregation

Networks may be segmented based on risk.

Example:

User Network
      │
      X
      │
Production Network

Segmentation limits lateral movement.

84. Web Filtering

Organizations may restrict access to malicious or inappropriate internet resources.

This can reduce:

Malware

Phishing

Command-and-Control Traffic

85. Cryptography

Cryptographic controls should be appropriately defined and managed.

Examples:

Encryption at Rest

Encryption in Transit

Key Management

Certificate Management

86. Secure Development Lifecycle

Security should be incorporated throughout software development.

Requirements
      ↓
Design
      ↓
Development
      ↓
Testing
      ↓
Deployment
      ↓
Monitoring

This is often called a Secure SDLC.

87. Application Security Requirements

Security requirements should be identified before applications are built or acquired.

Examples:

Authentication

Authorization

Encryption

Logging

Data Protection

88. Secure Architecture and Engineering Principles

Organizations should define principles for secure system design.

Examples:

Least Privilege

Defense in Depth

Zero Trust

Secure by Default

Fail Securely

89. Secure Coding

Development teams should follow secure coding practices.

Examples:

Input Validation

Output Encoding

Secrets Management

Error Handling

Dependency Security

90. Security Testing

Security testing should occur during development and acceptance.

Examples:

SAST

DAST

Dependency Scanning

Penetration Testing

Security Acceptance Testing

91. Outsourced Development

Security should also be governed when development is outsourced.

Consider:

Vendor Security Requirements

Secure Coding

Code Ownership

Testing

Access Control

92. Separation of Environments

Development, testing, and production environments should be appropriately separated.

Example:

Development
      ↓
Testing
      ↓
Production

Production access should be tightly controlled.

93. Change Management

Changes should follow a controlled process.

Example:

Change Request
      ↓
Risk Assessment
      ↓
Approval
      ↓
Testing
      ↓
Deployment
      ↓
Validation

94. Test Information

Test data should be appropriately selected and protected.

Avoid unnecessarily copying sensitive production information into lower environments.

95. Protection During Audit Testing

Audit and assurance activities should be planned to minimize disruption or security risk to operational systems.

96. Translating Annex A into Enterprise Controls

Annex A provides reference controls.

Organizations often translate them into more detailed internal controls.

Example:

Annex A Concept:
Secure Authentication

      ↓

Enterprise Control:
IAM-003

      ↓

Control Statement:
All privileged workforce identities must use approved phishing-resistant MFA before accessing production environments.

This creates a testable control.

97. What Makes a Good Control Statement?

A useful control statement should explain:

Who?

Does What?

To What?

How Often?

For What Security Purpose?

Example:

The IAM team reviews privileged production access quarterly and removes access that is no longer supported by an approved business requirement.

This is testable.

98. Weak Control Statement

Access should be secure.

Problems:

No owner.
No action.
No frequency.
No scope.
Difficult to test.

99. Strong Control Statement

The IAM Operations team performs a quarterly review of all privileged production accounts and removes unauthorized access within five business days of approval.

Now an auditor can test it.

100. Control Attributes

An enterprise control record may contain:

Control ID

Control Name

Control Statement

Control Objective

Control Owner

Control Operator

Frequency

Evidence

Mapped Risk

Mapped Policy

Mapped Framework

This becomes part of the control library.

101. Preventive Controls

Preventive controls attempt to stop an unwanted event.

Examples:

MFA

Firewall

Access Approval

Secure Configuration

102. Detective Controls

Detective controls identify unwanted activity.

Examples:

SIEM

EDR Alerts

Access Reviews

Security Monitoring

103. Corrective Controls

Corrective controls help restore or remediate after an issue.

Examples:

Incident Response

Backup Recovery

Patch Deployment

Account Disablement

A mature control environment usually combines these types.

104. Manual Controls

Example:

Quarterly Access Review

A person performs the review.

Evidence might include:

Review Report

Approval

Remediation Ticket

105. Automated Controls

Example:

Cloud policy blocks public storage deployment.

Evidence might include:

Policy Configuration

Enforcement Logs

Exception Records

Automated does not automatically mean effective.

106. Hybrid Controls

Many controls combine automation and human oversight.

Example:

Automated Vulnerability Scan
      ↓
Human Prioritization
      ↓
Engineering Remediation
      ↓
Automated Rescan

107. Control Frequency

Examples:

Continuous

Daily

Weekly

Monthly

Quarterly

Annual

Event Driven

Frequency should match the control objective and risk.

108. Control Evidence

Every testable control should have expected evidence.

Examples:

Control	Evidence
MFA	Coverage report
Access Review	Review records
Vulnerability Management	Scan + remediation records
Backup	Recovery-test result
Vendor Assessment	Assessment report
Training	Completion report

Evidence demonstrates operation.

109. Design Effectiveness

Control design asks:

If this control operates as designed, can it reasonably address the risk?

Example:

Risk:
Privileged credential compromise

Control:
Annual security awareness

The control may help, but alone it is unlikely to sufficiently address privileged-access risk.

110. Operating Effectiveness

Operating effectiveness asks:

Did the control actually operate as designed?

Example:

Control:

Quarterly Access Review

Evidence:

Q1 — Completed

Q2 — Completed

Q3 — Missing

Q4 — Completed

The control did not operate consistently.

111. Control Testing

A simple control test may include:

Understand Control
      ↓
Review Design
      ↓
Select Sample
      ↓
Inspect Evidence
      ↓
Identify Exceptions
      ↓
Conclude Effectiveness

This connects Annex A implementation with assurance.

112. Risk-to-Control Mapping

Example:

Risk:
Credential Compromise
      │
      ├── Identity Management
      ├── Authentication
      ├── Access Rights
      ├── Privileged Access
      └── Monitoring

Multiple controls can work together to reduce one risk.

113. Control-to-Risk Mapping

A single control may address multiple risks.

Example:

MFA
 │
 ├── Phishing
 ├── Privileged Compromise
 ├── Remote Access
 └── SaaS Account Takeover

This many-to-many relationship is important in GRC tooling.

114. Policy-to-Control Mapping

Example:

Access Control Policy
      ↓
Identity Management
      ↓
Authentication
      ↓
Access Rights
      ↓
Privileged Access

Policies provide governance direction for controls.

115. Control-to-Evidence Mapping

Example:

Control:
Privileged Access Review

      ↓

Evidence:
Quarterly Review Report
Approval Record
Remediation Tickets

This makes audits easier.

116. Cross-Framework Mapping

Organizations often map one enterprise control to multiple frameworks.

Example:

Enterprise Control:
Privileged MFA

      ↓

ISO/IEC 27001

SOC 2

PCI DSS

NIST

Internal Policy

This reduces duplicated compliance work.

117. Common Control Framework

Instead of building:

ISO Controls

SOC Controls

PCI Controls

NIST Controls

separately, mature organizations may build:

Enterprise Control Library
          ↓
    ┌─────┼─────┐
    ↓     ↓     ↓
   ISO   SOC   PCI

This creates one source of truth for control management.

118. Annex A and the SoA

For each Annex A control, the SoA should answer:

Applicable?

Why?

Implementation Status?

Owner?

Risk?

Evidence?

This converts Annex A into an operational governance framework.

119. Annex A and Risk Treatment

Example:

Risk:
RISK-005 — Cloud misconfiguration

Treatment:
Implement configuration governance

Controls:
Configuration Management
Logging
Access Control
Network Security

The SoA records the relevant applicability decisions.

120. Annex A and Internal Audit

Internal audit may test:

Annex A Control
      ↓
Enterprise Control
      ↓
Evidence
      ↓
Sample
      ↓
Exception
      ↓
Finding

This is why controls must be testable.

121. Annex A and Certification Audit

An auditor may ask:

Why is this control applicable?

How is it implemented?

Who owns it?

What evidence exists?

Is it operating effectively?

The SoA helps answer the first question.

The control environment and evidence answer the others.

122. Common Annex A Mistakes

Mistake 1 — Treating Annex A as a Checklist

93 Controls
↓
Tick Everything

This misses risk-based thinking.

Mistake 2 — Memorizing Without Understanding

Knowing control numbers is less important than understanding control objectives and implementation.

Mistake 3 — No Control Ownership

Controls exist but no one operates them.

Mistake 4 — No Evidence

Controls are claimed but cannot be demonstrated.

Mistake 5 — Vague Internal Controls

Example:

Maintain good security.

Not testable.

Mistake 6 — No Risk Mapping

Controls appear disconnected from risk treatment.

Mistake 7 — Copying Generic Control Descriptions

Controls should reflect the organization’s environment.

Mistake 8 — Ignoring Cloud Responsibility

Provider and customer responsibilities become unclear.

Mistake 9 — Assuming Automated Means Effective

Automation still requires configuration, monitoring, and assurance.

Mistake 10 — Framework Silos

Separate duplicate controls are maintained for every certification.

123. Practical Activity — Build an Annex A Control Register

Create:

01 Annex A Control Register

Recommended fields:

Field
Annex A Reference
Control Name
Theme
Control Objective
Applicable
Internal Control ID
Control Owner
Operator
Frequency
Evidence
Risk Mapping
Implementation Status

124. Practical Activity — Build Enterprise Controls

Select ten Annex A controls and translate them into internal enterprise control statements.

Use:

Control ID

Control Name

Control Statement

Owner

Operator

Frequency

Evidence

Example:

Control ID:
IAM-001

Control:
Privileged Access Review

Statement:
The IAM team reviews all privileged production access quarterly and removes unauthorized access within five business days.

Owner:
IAM Director

Frequency:
Quarterly

Evidence:
Privileged access certification report

125. Practical Activity — Build Control Evidence Matrix

Create:

02 Control Evidence Matrix

Use:

Control	Evidence	Owner	Frequency	Retention

This prepares controls for assurance.

126. Practical Activity — Build Risk-to-Control Mapping

Create:

03 Risk-to-Control Mapping

Select ten risks from your ISO risk register.

Map relevant Annex A and enterprise controls to each risk.

127. Practical Activity — Build Control Ownership Matrix

Create:

04 Control Ownership Matrix

Use:

Control	Owner	Operator	Evidence Provider

This clarifies accountability.

128. Practical Activity — Build Framework Mapping

Create:

05 Common Control Mapping

Example:

Enterprise Control	ISO	SOC 2	PCI DSS	NIST
MFA	✓	✓	✓	✓
Logging	✓	✓	✓	✓
Vulnerability Mgmt	✓	✓	✓	✓

This demonstrates how one control can support several compliance obligations.

129. Annex A Review Checklist

Before considering the Annex A review complete:

All 93 controls considered.
Organizational controls reviewed.
People controls reviewed.
Physical controls reviewed.
Technological controls reviewed.
Applicability determined.
Exclusions justified.
Internal controls mapped.
Owners identified.
Operators identified.
Frequencies defined.
Evidence identified.
Risks mapped.
Policies mapped.
Implementation status verified.
SoA updated.

130. GRC Analyst Responsibilities

A GRC professional may:

Maintain the Annex A control register.
Coordinate control applicability reviews.
Map risks to controls.
Translate requirements into control statements.
Assign control ownership.
Maintain the control library.
Define evidence requirements.
Coordinate evidence collection.
Map policies to controls.
Track control implementation.
Support control testing.
Track control deficiencies.
Maintain the SoA.
Map controls across frameworks.
Support internal and certification audits.

GRC does not necessarily operate every control.

Instead, GRC helps ensure controls are:

Defined

Owned

Implemented

Evidenced

Tested

Mapped

Governed

131. Annex A Governance Model

A practical operating model is:

Risk Owner
      ↓
Identifies Treatment Need

GRC
      ↓
Maps Control Requirement

Control Owner
      ↓
Owns Control

Control Operator
      ↓
Performs Control

Evidence Provider
      ↓
Provides Evidence

Assurance
      ↓
Tests Effectiveness

This separates accountability from execution and assurance.

132. Annex A Control Lifecycle

Risk Identified
      ↓
Control Required
      ↓
Control Designed
      ↓
Owner Assigned
      ↓
Control Implemented
      ↓
Evidence Generated
      ↓
Control Tested
      ↓
Deficiency Identified
      ↓
Remediation
      ↓
Retesting
      ↓
Continuous Monitoring

Controls should therefore be managed throughout their lifecycle.

133. Annex A Maturity

Level 1 — Checklist

93 controls marked Yes / No

Level 2 — Documented

Owners
Procedures
Evidence

Level 3 — Risk Integrated

Risk Mapping
Treatment Mapping
SoA Integration

Level 4 — Assured

Control Testing
Exceptions
Remediation
Metrics

Level 5 — Common Control Model

Enterprise Control Library
      ↓
ISO
SOC 2
PCI DSS
NIST
Cloud Frameworks

This is where GRC becomes scalable.

134. Annex A Mindset

When reviewing any Annex A control, ask:

What risk does this control address?

Why is it applicable?

What does the organization actually do?

Who owns the control?

Who operates it?

How frequently does it operate?

What evidence does it produce?

Can an auditor test it?

Is it working effectively?

Which other frameworks can reuse it?

If these questions are answered clearly, Annex A becomes a practical security framework rather than a compliance checklist.

Key Takeaways

ISO/IEC 27001:2022 Annex A contains 93 reference controls.
The controls are organized into 37 Organizational, 8 People, 14 Physical, and 34 Technological controls.
Annex A is part of the wider ISMS and should not be confused with the entire ISO/IEC 27001 standard.
Annex A supports risk treatment and Statement of Applicability decisions.
Organizations should consider all Annex A controls but do not automatically need to implement every control.
Control applicability should reflect risk, legal, regulatory, contractual, and business requirements.
Controls should be translated into clear and testable enterprise control statements.
Controls should have owners, operators, frequencies, and evidence.
Control design and operating effectiveness are different concepts.
Risk-to-control and control-to-evidence mappings provide important traceability.
One enterprise control can support several compliance frameworks.
A common control framework can significantly reduce duplicated compliance work.
GRC plays a major role in converting Annex A into an operational, auditable control environment.

Knowledge Check

Before continuing, make sure you can answer:

What is the purpose of Annex A?
How many controls are included in ISO/IEC 27001:2022 Annex A?
What are the four Annex A themes?
How many Organizational Controls are there?
How many People Controls are there?
How many Physical Controls are there?
How many Technological Controls are there?
Must every organization implement all 93 controls?
How does Annex A connect to risk treatment?
How does Annex A connect to the SoA?
What makes a good enterprise control statement?
What is a control owner?
What is a control operator?
What is control evidence?
What is design effectiveness?
What is operating effectiveness?
What is a preventive control?
What is a detective control?
What is a corrective control?
Why is cross-framework control mapping valuable?

What’s Next?

➡️ Next: 10 — Internal Audit

In the next lesson, you will move from designing and implementing the ISO/IEC 27001 control environment into independently evaluating whether the ISMS and its controls are operating as intended.

You will learn the complete internal-audit lifecycle:

Define Audit Program
        ↓
Establish Scope & Criteria
        ↓
Maintain Auditor Independence
        ↓
Prepare Audit Plan
        ↓
Select Samples
        ↓
Collect Evidence
        ↓
Conduct Interviews
        ↓
Test ISMS Requirements
        ↓
Test Annex A Controls
        ↓
Document Findings
        ↓
Issue Audit Report
        ↓
Track Corrective Actions
        ↓
Retest & Close

You will also build practical GRC artifacts including an Internal Audit Plan, Audit Checklist, Evidence Request List, Control Testing Worksheet, Audit Findings Register, and Corrective Action Tracker.

These artifacts will prepare the ISMS for management review and ISO/IEC 27001 certification readiness.