# ISO/IEC 27001:2022 Annex A Controls: 93 Information Security Controls and Implementation Guide

**URL:** https://securesys.com.tr/en/learning/cyber-security-compliance-advisory/iso-27001-2022-annex-a-93-security-controls-guide

![ISO/IEC 27001:2022 Annex A Controls: 93 Information Security Controls and Implementation Guide](/images/bilgi-merkezi/covers/cover-uyum-05.webp)

### What Is ISO/IEC 27001:2022 Annex A?

**ISO/IEC 27001:2022 Annex A is the section containing the 93 reference security controls that organisations can consider when managing their information security risks.**

The controls are organised into four main groups:

- 37 organisational controls.
- 8 people controls.
- 14 physical controls.
- 34 technological controls.

Annex A is not simply a list that requires technical security products to be installed. It covers a broad field, from information security policies to human resources processes, and from physical security to software development activities.

While ISO/IEC 27001 defines the requirements for a management system, ISO/IEC 27002 provides detailed guidance on implementing information security controls.

**Short answer:** ISO 27001 Annex A is the structure containing 93 reference controls that can be used to treat information security risks. Whether a control is necessary is assessed together with the risk assessment, the risk treatment decisions and the relevant obligations.

### \1. Why Does ISO 27001:2022 Contain 93 Controls?

The 2013 edition of ISO/IEC 27001 contained 114 reference controls.

In the 2022 edition, the control structure was reorganised and reduced to 93 controls.

This change does not mean that the scope of information security has been narrowed.

Some controls were merged, some were restructured, and new controls addressing modern technology environments were added.

In particular, areas such as cloud services, threat intelligence, data masking, data leakage prevention, configuration management and secure coding have become more visible.

#### Control groups

| Control group | Number of controls | Main focus |
| --- | --- | --- |
| A.5 Organisational | 37 | Policy, governance, processes and supplier management |
| A.6 People | 8 | Employee security, awareness and responsibilities |
| A.7 Physical | 14 | Security of facilities, equipment and the physical environment |
| A.8 Technological | 34 | System, network, application and data security |
| Total | 93 | Integrated information security |

How the controls are implemented may vary according to the organisation's activities and risks.

### \2. The Difference Between ISO 27001 Annex A and ISO 27002

ISO/IEC 27001 and ISO/IEC 27002 are complementary standards, but they serve different purposes.

**ISO/IEC 27001** defines the requirements for establishing, operating and improving an Information Security Management System.

**ISO/IEC 27002** provides guidance for implementing information security controls.

For example, ISO/IEC 27001 Annex A includes a control on the management of technical vulnerabilities.

ISO/IEC 27002 then offers more detailed explanations on how to implement that control.

#### Key differences

| Characteristic | ISO/IEC 27001 | ISO/IEC 27002 |
| --- | --- | --- |
| Main purpose | Management system requirements | Security control guidance |
| Certification | Can be the basis for ISMS (Information Security Management System) certification | On its own, it is not an ISO 27001 ISMS certificate |
| Risk management | Defines the requirements | Supports the implementation of controls |
| Annex A | 93 reference controls | Implementation guidance for the controls |
| Use | Organisational ISMS | Control design and implementation |

For this reason, when assessing an organisation's conformity with ISO/IEC 27001, it is not sufficient merely to complete a control checklist.

The management system requirements must also be met.

### \3. Are All ISO 27001 Annex A Controls Mandatory?

This is one of the most commonly misunderstood areas in ISO/IEC 27001 implementations.

**ISO/IEC 27001:2022 does not require every organisation to implement all 93 controls in the same way.**

The organisation must assess its information security risks and determine the controls necessary to treat them.

The selected controls must be compared against Annex A.

The Statement of Applicability (SoA) must show the justification for the necessary controls, their implementation status, and the justification for any Annex A controls that are excluded.

#### Example

An organisation may not have its own data centre.

However, this does not mean that physical security risks disappear altogether.

Employee devices, the office environment, remote working and the physical security responsibilities of cloud providers must still be assessed.

#### The critical distinction

The fact that a control has not yet been implemented does not mean that the control is not applicable.

If a necessary control has not been implemented, this must be addressed in the risk treatment plan.

### A.5 – Organisational Controls

### \4. What Are the A.5 Organisational Controls?

Organisational controls ensure that information security is managed across the whole organisation.

Policies, responsibilities, information assets, suppliers, incident management and compliance processes fall within this group.

ISO/IEC 27001:2022 contains 37 organisational controls.

#### A.5 control list

| Control | Subject |
| --- | --- |
| A.5.1 | Policies for information security |
| A.5.2 | Information security roles and responsibilities |
| A.5.3 | Segregation of duties |
| A.5.4 | Management responsibilities |
| A.5.5 | Contact with authorities |
| A.5.6 | Contact with special interest groups |
| A.5.7 | Threat intelligence |
| A.5.8 | Information security in project management |
| A.5.9 | Inventory of information and other associated assets |
| A.5.10 | Acceptable use of information and other associated assets |
| A.5.11 | Return of assets |
| A.5.12 | Classification of information |
| A.5.13 | Labelling of information |
| A.5.14 | Information transfer |
| A.5.15 | Access control |
| A.5.16 | Identity management |
| A.5.17 | Authentication information |
| A.5.18 | Access rights |
| A.5.19 | Information security in supplier relationships |
| A.5.20 | Addressing information security within supplier agreements |
| A.5.21 | Managing information security in the ICT supply chain |
| A.5.22 | Monitoring, review and change management of supplier services |
| A.5.23 | Information security for use of cloud services |
| A.5.24 | Information security incident management planning and preparation |
| A.5.25 | Assessment and decision on information security events |
| A.5.26 | Response to information security incidents |
| A.5.27 | Learning from information security incidents |
| A.5.28 | Collection of evidence |
| A.5.29 | Information security during disruption |
| A.5.30 | ICT readiness for business continuity |
| A.5.31 | Legal, statutory, regulatory and contractual requirements |
| A.5.32 | Intellectual property rights |
| A.5.33 | Protection of records |
| A.5.34 | Privacy and protection of personal data |
| A.5.35 | Independent review of information security |
| A.5.36 | Compliance with policies, rules and standards |
| A.5.37 | Documented operating procedures |

These headings are given as descriptive English equivalents of the Turkish titles; they do not replace the official standard text.

### \5. A.5.1 – Policies for Information Security

Information security policies define the organisation's approach to security.

It is important that policies are appropriately approved by top management, communicated to the relevant parties and updated when necessary.

#### Implementation examples

Corporate information security policy.

Access control policy.

Remote working policy.

Data classification policy.

Backup policy.

#### Audit evidence

Approved policy documents.

Revision history.

Announcement and communication records.

Policy review records.

The existence of a policy alone does not show that the control is effectively implemented.

The policy must be consistent with actual operations.

### \6. A.5.2–A.5.4 – Roles, Segregation of Duties and Management Responsibilities

Unclear information security responsibilities can create significant operational risks.

For example, if the same person creates, approves and audits a critical financial transaction, this can create a risk from a segregation of duties perspective.

#### Example responsibilities

Top management: Security objectives and resource allocation.

CISO: Information security coordination.

IT teams: Technical control implementation.

SOC: Security monitoring.

Human resources: Employee lifecycle processes.

Internal audit: Impartial assessment.

#### Control approach

Job descriptions should be prepared.

An authorisation matrix should be created.

Segregation of duties should be assessed for critical transactions.

Conflicts of interest should be reduced.

### \7. A.5.5–A.5.7 – Communication and Threat Intelligence

It is important for organisations to establish communication channels with the relevant authorities and appropriate expert communities on information security.

Threat intelligence, in turn, supports an understanding of the threats the organisation faces.

#### Threat intelligence sources

Vendor security advisories.

National and sector-specific cyber security alerts.

The CISA KEV catalogue.

Security research.

SOC threat intelligence.

Sector information-sharing networks.

#### Example

When a vulnerability that is being actively exploited is published for the VPN product the organisation uses, the affected assets are identified.

The risk assessment is updated.

The necessary security measures are planned.

#### Audit evidence

Threat intelligence records.

Risk assessment updates.

Security advisories.

Actions taken.

### \8. A.5.8–A.5.11 – Project Security and Asset Management

Information security is not limited to protecting existing systems.

Security requirements must be assessed from the very start of new projects.

#### Project security

Security requirements should be defined in new application development projects.

In cloud migrations, access, logging and data protection needs should be assessed.

#### Asset inventory

Servers.

Clients.

Databases.

Cloud resources.

Source code repositories.

Critical documents.

#### Acceptable use

The conditions under which corporate devices and information assets may be used should be defined.

#### Return of assets

The return of corporate assets should be tracked during leaving or role-change processes.

### \9. A.5.12–A.5.14 – Information Classification and Transfer

The value and sensitivity of information can differ.

For this reason, an information classification approach should be established.

#### Example classification

Public.

Internal.

Confidential.

Strictly confidential.

These classes are illustrative.

The organisation's own information classification policy should be used as the basis.

#### Control implementations

Labelling sensitive documents.

Restricting unauthorised sharing.

Secure file transfer.

Controlling the sending of sensitive data by email.

Encryption.

#### Example risk

A customer report classified as strictly confidential being sent to the wrong recipient.

This risk can be reduced not only through employee awareness but also through appropriate technical controls.

### \10. A.5.15–A.5.18 – Access and Identity Management

Access control is one of the fundamental areas of corporate information security.

The aim is for users to access only the resources they need for their duties.

#### Implementation examples

Role-based access.

The principle of least privilege.

MFA.

Centralised identity management.

Account lifecycle.

Periodic access reviews.

#### Example

When an employee moves to a different department, the access associated with their previous role should be reviewed.

When new permissions are defined, unnecessary privileges should not be granted.

#### Audit evidence

Authorisation matrix.

Access approval records.

Account creation and deactivation records.

Periodic access reviews.

MFA coverage reports.

### \11. A.5.19–A.5.23 – Supplier and Cloud Security

Suppliers may have access to corporate systems or may process sensitive data.

For this reason, supplier security should be assessed from before the contract through to the termination of the service.

#### Supplier security

Supplier risk assessment.

Contractual security obligations.

Access control.

Incident notification processes.

Assessment of service changes.

#### Cloud security

Selection of cloud services.

The shared responsibility model.

Identity and access management.

Data retention and transfer conditions.

Logging.

Service termination and data retrieval processes.

#### Example

When the use of a SaaS service ends, how the data will be retrieved, which records will be deleted and how access will be removed should be planned in advance.

### \12. A.5.24–A.5.28 – Information Security Incident Management

Managing information security incidents is an important part of security monitoring and response processes.

#### Key stages

Incident management preparation.

Assessment of security events.

Incident classification.

Response.

Post-incident review.

Preservation of evidence.

#### Example

The SOC team detected a suspicious administrator account session.

The incident is verified.

The affected account and systems are assessed.

If unauthorised access is confirmed, the response plan is applied.

The necessary records are preserved.

Post-incident improvement activities are defined.

#### Audit evidence

Incident response procedure.

Incident records.

Response reports.

Exercise results.

Improvement activities.

### \13. A.5.29–A.5.30 – Security During Disruption and ICT Continuity

Information security is not limited to the times when systems are operating normally.

An appropriate level of security must also be maintained during disruptions and crises.

#### Example risks

Ransomware attack.

Data centre outage.

Failure of a critical cloud service.

Backup system not working.

Power outage.

#### Implementation areas

Business continuity plans.

Disaster recovery plans.

Alternative working methods.

Backup and restore.

Recovery tests.

Crisis communication.

#### RTO and RPO

**RTO:** The target for the acceptable downtime of a service.

**RPO:** The target for the acceptable recovery point in terms of data loss.

These values should be determined according to business requirements.

### \14. A.5.31–A.5.37 – Compliance, Records and Independent Review

This group of controls covers topics such as legal obligations, intellectual property, protection of records, privacy and independent review.

#### Example practices

Inventory of applicable legislation.

Tracking of contractual security obligations.

Licence and intellectual property management.

Record retention policies.

Personal data security controls.

Independent security assessments.

Documenting operating procedures.

#### An important distinction

An ISO/IEC 27001 certificate does not automatically guarantee full compliance with regulations such as KVKK (Turkish Personal Data Protection Law) or GDPR.

Legal obligations must be assessed separately.

### A.6 – People Controls

### \15. What Are the A.6 People Controls?

ISO/IEC 27001:2022 contains eight people controls.

| Control | Subject |
| --- | --- |
| A.6.1 | Screening |
| A.6.2 | Terms and conditions of employment |
| A.6.3 | Information security awareness, education and training |
| A.6.4 | Disciplinary process |
| A.6.5 | Responsibilities after termination or change of employment |
| A.6.6 | Confidentiality or non-disclosure agreements |
| A.6.7 | Remote working |
| A.6.8 | Information security event reporting |

The purpose of people controls is not to treat employees merely as a source of error.

It is to ensure that organisational processes are operated securely.

### \16. A.6.1–A.6.2 – Recruitment and Employment Security

Security requirements related to the role should be assessed during recruitment processes.

#### Example practices

Role-based security assessments.

Explaining authorities and responsibilities.

Defining confidentiality obligations.

Information security responsibilities within the terms of employment.

#### Key point

Personnel screening should be carried out in a way that is consistent with applicable legislation, confidentiality and data protection obligations.

Applying the same scope of review to every position may not be appropriate.

### \17. A.6.3 – Information Security Awareness

Employee awareness is an important component of information security programmes.

#### Training topics

Phishing.

Social engineering.

Password security.

MFA.

Sharing of sensitive data.

Remote working security.

Safe use of artificial intelligence tools.

Incident reporting.

#### Measuring effectiveness

Training participation rate.

Knowledge assessment results.

Simulation results.

Real incident reporting behaviour.

Awareness training should not be run solely to produce attendance certificates.

Its effect on behavioural change and risk reduction should be assessed.

### \18. A.6.4–A.6.6 – Discipline, Leaving the Organisation and Confidentiality

Information security obligations must be managed throughout the employee lifecycle.

#### Leaver checklist

Closing corporate accounts.

Removing VPN access.

Terminating cloud access.

Returning corporate devices.

Revoking physical access cards.

Reminding the individual of confidentiality obligations.

#### Example

A personal device belonging to a departing employee may contain corporate data.

In this case, appropriate actions should be carried out in line with data protection and device management policies.

### \19. A.6.7 – Remote Working Security

The remote working model can create different security risks.

#### Example risks

Use of insecure networks.

Device loss.

Unauthorised screen viewing.

Uncontrolled file sharing.

Access to corporate systems from personal devices.

#### Recommended controls

Managed devices.

Disk encryption.

MFA.

Endpoint protection.

Secure remote access.

Session locking.

Data sharing policies.

#### Audit evidence

Remote working policy.

Device compliance reports.

MFA coverage.

Endpoint management records.

### \20. A.6.8 – Information Security Event Reporting

Employees need to know how to report suspicious security events.

#### Situations that can be reported

Suspicious email.

Lost device.

File sent to the wrong recipient.

Suspected unauthorised access.

Suspicious sign-in notification.

Signs of malware.

#### Important approach

The reporting process should be easy and accessible.

Unnecessary obstacles that could lead employees to conceal incidents should be reduced.

Assessment and response processes following a report should be defined.

### A.7 – Physical Controls

### \21. What Are the A.7 Physical Controls?

ISO/IEC 27001:2022 contains 14 physical security controls.

| Control | Subject |
| --- | --- |
| A.7.1 | Physical security perimeters |
| A.7.2 | Physical entry |
| A.7.3 | Securing offices, rooms and facilities |
| A.7.4 | Physical security monitoring |
| A.7.5 | Protecting against physical and environmental threats |
| A.7.6 | Working in secure areas |
| A.7.7 | Clear desk and clear screen |
| A.7.8 | Equipment siting and protection |
| A.7.9 | Security of assets off-premises |
| A.7.10 | Storage media |
| A.7.11 | Supporting utilities |
| A.7.12 | Cabling security |
| A.7.13 | Equipment maintenance |
| A.7.14 | Secure disposal or re-use of equipment |

### \22. A.7.1–A.7.4 – Physical Access and Monitoring

Access to areas containing critical information assets should be controlled.

#### Example controls

Card access.

Visitor logs.

Definition of authorised areas.

Camera monitoring.

Server room access control.

Physical security alarm.

#### Example

Access to the server room can be limited to authorised personnel only.

Entries and exits can be recorded.

Physical access authorisations can be reviewed periodically.

#### Audit evidence

Access authorisation lists.

Visitor logs.

Physical security procedures.

Monitoring records.

### \23. A.7.5–A.7.8 – Environmental Security and Work Areas

Physical security does not consist solely of preventing unauthorised entry.

Environmental threats must also be assessed.

#### Example threats

Fire.

Flooding.

Excessive temperature.

Humidity.

Power outage.

Physical damage.

#### Control implementations

Fire detection.

Appropriate climate control.

Power protection.

Secure positioning of equipment.

Clear desk policy.

Clear screen policy.

#### Example

Leaving sensitive customer files out in shared work areas can create an information security risk.

Clear desk and clear screen practices help reduce this risk.

### \24. A.7.9–A.7.14 – Equipment and Storage Security

Corporate information assets may also be located outside the office.

Laptops, portable drives and mobile devices must be appropriately protected.

#### Example controls

Device encryption.

Secure transport.

Storage media management.

Restricting unauthorised device use.

Equipment maintenance records.

Secure data erasure.

Physical destruction.

#### Example

A decommissioned SSD may contain sensitive data.

Merely formatting the device through the operating system does not amount to secure disposal in every case.

A secure erasure or destruction method appropriate to the storage technology should be defined.

### A.8 – Technological Controls

### \25. What Are the A.8 Technological Controls?

ISO/IEC 27001:2022 contains 34 technological controls.

| Control | Subject |
| --- | --- |
| A.8.1 | User endpoint devices |
| A.8.2 | Privileged access rights |
| A.8.3 | Information access restriction |
| A.8.4 | Access to source code |
| A.8.5 | Secure authentication |
| A.8.6 | Capacity management |
| A.8.7 | Protection against malware |
| A.8.8 | Management of technical vulnerabilities |
| A.8.9 | Configuration management |
| A.8.10 | Information deletion |
| A.8.11 | Data masking |
| A.8.12 | Data leakage prevention |
| A.8.13 | Information backup |
| A.8.14 | Redundancy of information processing facilities |
| A.8.15 | Logging |
| A.8.16 | Monitoring activities |
| A.8.17 | Clock synchronisation |
| A.8.18 | Use of privileged utility programs |
| A.8.19 | Installation of software on operational systems |
| A.8.20 | Networks security |
| A.8.21 | Security of network services |
| A.8.22 | Segregation of networks |
| A.8.23 | Web filtering |
| A.8.24 | Use of cryptography |
| A.8.25 | Secure development life cycle |
| A.8.26 | Application security requirements |
| A.8.27 | Secure system architecture and engineering principles |
| A.8.28 | Secure coding |
| A.8.29 | Security testing in development and acceptance |
| A.8.30 | Outsourced development |
| A.8.31 | Separation of development, test and production environments |
| A.8.32 | Change management |
| A.8.33 | Test information |
| A.8.34 | Protection of information systems during audit testing |

### \26. A.8.1–A.8.5 – Endpoints, Privileges and Authentication

These controls support the secure management of devices and user access.

#### Endpoint security

EDR or appropriate malware protection.

Disk encryption.

Device management.

Security updates.

Secure configuration.

#### Privileged access

Limiting administrator accounts.

Monitoring privileged accounts.

Using PAM where necessary.

Periodic review of privileges.

#### Source code access

Role-based access to code repositories.

Secure authentication.

Access logs.

#### Audit evidence

Endpoint compliance reports.

Administrator account lists.

MFA reports.

Source code access logs.

### \27. A.8.6–A.8.9 – Capacity, Malware, Vulnerabilities and Configuration

Organisations need to operate their systems in a secure and sustainable way.

#### Capacity management

Monitoring resource consumption.

Capacity planning.

Assessing performance bottlenecks.

#### Malware protection

Endpoint protection.

Email security.

Monitoring malware incidents.

#### Vulnerability management

Regular scanning.

Risk-based prioritisation.

Patch management.

Re-verification.

#### Configuration management

Secure configuration standards.

Configuration change records.

Security hardening.

Configuration compliance checks.

#### Example

Unnecessary management services may be enabled on a firewall device.

A configuration review can identify these services.

By closing access that is not needed, the attack surface can be reduced.

### \28. A.8.10–A.8.12 – Data Deletion, Masking and DLP

Data security controls support the protection of sensitive information throughout its lifecycle.

#### Information deletion

Appropriate deletion of data whose retention period has expired.

Secure sanitisation of decommissioned devices.

Assessing data deletion processes in cloud environments.

#### Data masking

Protecting sensitive data in test environments.

Limiting the information shown to unauthorised persons.

Supporting data minimisation.

#### Data leakage prevention

Controlling the sharing of sensitive data by email.

Data transfer policies on endpoints.

Sharing controls for cloud storage.

#### Example

When an employee attempts to upload the customer database to a personal cloud account, appropriate DLP policies can detect or block this action.

The effectiveness of the control should be tested.

### \29. A.8.13–A.8.14 – Backup and Redundancy

Backup and redundancy serve different purposes.

**Backup** supports the ability to restore data.

**Redundancy** supports service continuity if certain system components fail.

#### Backup controls

Backup policy.

Protection of backups.

Access control.

Restore tests.

Backup monitoring.

#### Redundancy controls

Redundant network connections.

Redundant power supplies.

High availability architecture.

Alternative system components.

#### Critical point

A RAID configuration alone is not a backup.

Similarly, having backups does not guarantee that the system will operate without interruption.

### \30. A.8.15–A.8.17 – Logging, Monitoring and Clock Synchronisation

To understand security events, records must be accurate and usable.

#### Logging

Authentication records.

Administrator actions.

Critical system changes.

Security device events.

Application security logs.

#### Monitoring

Detecting suspicious activity.

Assessing anomalous sessions.

Examining indicators of unauthorised access.

#### Clock synchronisation

Synchronising systems with appropriate time sources.

#### Example

If the timestamps of firewall, server and application logs are inconsistent during a security incident, it can become difficult to reconstruct the sequence of events accurately.

For this reason, clock synchronisation is important for incident investigation.

### \31. A.8.18–A.8.19 – Privileged Tools and Software Installation

Management tools used on critical systems can hold powerful privileges.

Uncontrolled use of these tools can create a security risk.

#### Example controls

Restricting privileged utility programs.

Access control for management tools.

Defining software installation privileges.

Preventing unauthorised software installation.

Keeping installation records.

#### Example

It can be ensured that only approved software is installed on production servers.

Installation activities can be carried out by authorised personnel.

Change records can be preserved.

### \32. A.8.20–A.8.24 – Network Security and Cryptography

Network security controls support the protection of communication between systems.

#### Network security

Firewall.

Network access control.

IDS/IPS.

Secure remote access.

Network segmentation.

#### Network services

Service security requirements.

Supplier connections.

Network service monitoring.

#### Web filtering

Restricting access to malicious or inappropriate web resources.

#### Cryptography

Encryption in data transfer.

Protection of stored data.

Key management.

Certificate management.

#### Example

Critical database servers being directly accessible from the user network can create a risk.

Access can be restricted through appropriate segmentation and access rules.

### \33. A.8.25–A.8.29 – Secure Software Development

In software development activities, security needs to be addressed from the design stage onwards.

#### Secure development life cycle

Security requirements.

Threat modelling.

Secure architecture.

Secure coding.

Code review.

Security testing.

#### Methods that can be used

SAST.

DAST.

SCA.

Secret Scanning.

API security testing.

Manual code review.

Penetration test.

#### Example

If user authorisation in an application is checked only in the interface, unauthorised access may be possible through the API.

For this reason, security requirements must be verified at both the design and the testing stages.

#### Audit evidence

Secure development policy.

Code review records.

Security test reports.

Finding closure records.

### \34. A.8.30–A.8.34 – Outsourcing, Environment Separation and Change Security

In outsourced development processes, information security requirements must be clearly defined.

#### Outsourced development

Security requirements.

Code ownership.

Access control.

Delivery criteria.

Security testing.

#### Environment separation

Development.

Test.

Production.

These environments should be appropriately separated.

#### Test data

The use of production data in test environments should be assessed.

Where necessary, masking or synthetic data can be used.

#### Change management

Change requests.

Impact assessment.

Approval.

Testing.

Rollback plan.

#### Audit testing

Appropriate planning should be carried out so that security tests do not cause outages or data loss in production systems.

### ISO/IEC 27001:2022 New Controls

### \35. The 11 New Controls Introduced by ISO 27001:2022

The 2022 edition contains 11 newly defined controls.

| Control | Subject | Implementation example |
| --- | --- | --- |
| A.5.7 | Threat intelligence | Feeding threat data into risk management |
| A.5.23 | Cloud services security | Cloud security policy |
| A.5.30 | ICT readiness for business continuity | Disaster recovery tests |
| A.7.4 | Physical security monitoring | Camera and access monitoring |
| A.8.9 | Configuration management | Secure configuration standards |
| A.8.10 | Information deletion | Secure data erasure |
| A.8.11 | Data masking | Masking of test data |
| A.8.12 | Data leakage prevention | DLP policies |
| A.8.16 | Monitoring activities | SOC/SIEM monitoring |
| A.8.23 | Web filtering | Restricting access to malicious websites |
| A.8.28 | Secure coding | Secure Coding controls |

These controls make the security needs of modern corporate technology environments more visible.

### \36. How Are ISO 27001 Controls Prioritised?

There is no single standard order for implementing controls.

Prioritisation should be linked to the risk assessment and the relevant obligations.

#### Example prioritisation

**Stage one:** Critical assets, identity security, access control and known high-risk vulnerabilities.

**Stage two:** Backup, logging, security monitoring and incident response.

**Stage three:** Supplier security, data classification, DLP and process maturity.

**Stage four:** Measuring control effectiveness, automation and continual improvement.

This approach is an example.

The organisation's risk assessment may call for a different implementation order.

### \37. How Is ISO 27001 Control Effectiveness Measured?

That a control has been defined does not mean that it operates effectively.

The implementation and effectiveness status of controls should be assessed.

#### Example measurements

MFA coverage rate.

Critical vulnerability closure rate.

Success of backup restore tests.

Privileged account review rate.

Time to detect security incidents.

Incident response time.

Access revocation time.

#### Example

Having an MFA policy alone is not sufficient.

It should be verified that critical user and administrator accounts are actually protected with MFA.

### \38. Technical Audit of ISO 27001 Controls

A technical audit helps assess how security controls are actually implemented in real systems.

#### Example activities

Firewall rule analysis.

Active Directory security review.

Server configuration assessment.

Cloud IAM analysis.

Vulnerability scanning.

Penetration test.

Source code security analysis.

Backup restore test.

#### Critical point

Technical audit results should be fed into the risk management and corrective action processes.

Producing a report alone is not sufficient.

### \39. Audit Evidence for ISO 27001 Annex A Controls

Audit evidence varies according to the nature of the control.

| Control area | Example evidence |
| --- | --- |
| Information security policy | Approved policy |
| Asset management | Up-to-date inventory |
| Access control | Authorisation matrix and access records |
| Threat intelligence | Assessment and action records |
| Supplier security | Risk assessments and contracts |
| Incident management | Incident records and response reports |
| Physical security | Access and visitor logs |
| Vulnerability management | Scanning and remediation records |
| Backup | Restore test results |
| Secure development | Code review and test reports |

It is important that evidence is current, relevant and verifiable.

### \40. The Relationship Between ISO 27001 Annex A and the SoA

The SoA shows the justification for selecting the necessary security controls and their implementation status.

#### Example

**Risk:** Loss of critical data.

**Control:** A.8.13 – Information backup.

**Justification:** Reducing the risk of data loss and of unavailability.

**Implementation:** Regular backups and restore tests.

**Evidence:** Backup records and test reports.

#### Important point

The SoA should not be a document that is independent of the risk treatment plan.

It should be possible to explain why the controls are necessary.

### \41. The Relationship Between ISO 27001 Annex A and NIST CSF 2.0

NIST CSF 2.0 contains six core functions that support the management of cyber security risks.

GOVERN.

IDENTIFY.

PROTECT.

DETECT.

RESPOND.

RECOVER.

#### Example mapping

| NIST CSF function | ISO 27001 control areas |
| --- | --- |
| GOVERN | Policy, responsibilities, supplier management |
| IDENTIFY | Asset inventory, risk assessment |
| PROTECT | Access, encryption, endpoint security |
| DETECT | Logging, monitoring, threat intelligence |
| RESPOND | Incident management and response |
| RECOVER | Backup and continuity readiness |

This mapping is a conceptual example.

It should not be treated as an official and complete control equivalence.

### \42. The Relationship Between ISO 27001 Annex A and KVKK

ISO/IEC 27001 controls can support personal data security.

They can make a significant contribution, particularly in the areas of access control, data classification, encryption, incident management and supplier security.

However, ISO/IEC 27001 and KVKK have different requirements.

#### Example

An organisation may be protecting customer data with strong encryption.

However, the legal conditions required for processing personal data must be assessed separately.

**An ISO/IEC 27001 certificate is not automatic proof of full compliance with KVKK.**

### \43. A 90-Day Sample Plan for ISO 27001 Annex A Controls

#### Days 1–15: Control Inventory

Identifying existing controls.

SoA assessment.

Gap analysis.

Prioritising critical risks.

#### Days 16–30: Identity and Access Security

MFA.

Privilege review.

Privileged access.

Critical account management.

#### Days 31–45: Technical Security

Vulnerability management.

Configuration security.

Endpoint protection.

Network security.

#### Days 46–60: Data and Continuity

Data classification.

Backup.

Restore tests.

Data sharing controls.

#### Days 61–75: Monitoring and Incident Management

Logging.

Security monitoring.

Incident response procedures.

Incident exercises.

#### Days 76–90: Audit and Improvement

Control verification.

Internal audit.

Corrective actions.

Management reporting.

This plan is an example and does not constitute a guarantee of full compliance or certification within 90 days.

### \44. SECURESYS ISO 27001 Annex A Control Assessment and Consultancy

SECURESYS offers an approach that addresses technical security assessments and organisational risk management together in information security management system work.

#### Current state and gap analysis

Existing practices are assessed against the requirements of ISO/IEC 27001:2022 and the Annex A controls.

#### Risk management and SoA

We support linking control selections to the risk assessment.

#### Technical security validation

Security assessments can be carried out on systems, networks, applications and cloud infrastructures.

#### Penetration test and vulnerability management

We help identify and prioritise technical vulnerabilities and support remediation processes.

#### SOC and security monitoring

Monitoring of security events and the development of response capabilities can be supported.

#### Secure software development

Source code analysis, application security and secure development processes can be assessed.

#### Audit readiness

We support the assessment of control implementations, evidence and corrective actions.

**In the SECURESYS approach, ISO/IEC 27001 controls are treated not merely as documents produced for certification, but as verifiable and sustainable practices that reduce real information security risks.**

### Frequently Asked Questions (FAQ)

#### \1. What is ISO 27001 Annex A?

It is the section of the ISO/IEC 27001:2022 standard that contains the 93 reference security controls which can be used to treat information security risks.

#### \2. How many controls does ISO 27001:2022 contain?

Annex A contains a total of 93 controls.

#### \3. How many groups are the ISO 27001 controls divided into?

They are divided into four groups: organisational, people, physical and technological controls.

#### \4. How many organisational controls are there?

There are 37 organisational controls.

#### \5. How many people controls are there?

There are 8 people controls.

#### \6. How many physical controls are there?

There are 14 physical controls.

#### \7. How many technological controls are there?

There are 34 technological controls.

#### \8. Are all 93 ISO 27001 controls mandatory?

It is not mandatory for every control to be implemented in the same way in every organisation. The necessity of a control is determined by risk treatment decisions and justified in the SoA.

#### \9. What is the difference between ISO 27001 and ISO 27002?

ISO/IEC 27001 defines the ISMS requirements. ISO/IEC 27002 provides guidance on implementing information security controls.

#### \10. What is the SoA?

The Statement of Applicability shows the necessary controls, the justification for their selection, their implementation status and the justification for excluding Annex A controls.

#### \11. How many new controls did ISO 27001:2022 introduce?

The 2022 control structure contains 11 newly defined controls.

#### \12. Is a SOC mandatory for ISO 27001?

There is no 24/7 SOC requirement for all organisations. Monitoring requirements are determined by the risk assessment.

#### \13. Is DLP mandatory for ISO 27001?

The necessity of the DLP control should be assessed together with the risks and the relevant obligations. Purchasing a specific commercial DLP product is not a general requirement.

#### \14. Is a penetration test mandatory for ISO 27001?

There is no general rule that requires every organisation to carry out penetration tests at the same frequency. Testing needs are determined according to risks and applicable obligations.

#### \15. Does ISO 27001 cover source code analysis?

Yes. There are controls related to access to source code, secure coding, secure development and security testing.

#### \16. Does ISO 27001 cover cloud security?

Yes. A.5.23 addresses information security in the use of cloud services. In addition, other controls such as access, logging and data protection may also be relevant to cloud environments.

#### \17. How are ISO 27001 controls audited?

They are assessed through policies, records, technical configurations, interviews, sampling and appropriate verification methods.

#### \18. Does an ISO 27001 certificate show that all security vulnerabilities have been closed?

No. Certification is an assessment of conformity with the ISMS requirements within the defined scope; it does not guarantee that no technical vulnerabilities exist.

#### \19. How often should ISO 27001 Annex A controls be reviewed?

Controls should be assessed at planned intervals and when significant changes occur. The frequency is determined according to the organisation's risks.

#### \20. What does ISO 27001 Annex A consultancy provide?

It supports the assessment of controls, linking them to risks, preparing the SoA, identifying gaps and planning improvement activities.

### Conclusion: How Do ISO 27001's 93 Controls Create Value?

The ISO/IEC 27001:2022 Annex A controls offer an integrated reference structure covering the different dimensions of corporate information security.

Organisational controls support governance and process security.

People controls address employees' security responsibilities.

Physical controls aim to protect the environments where information assets are located.

Technological controls focus on system, network, application and data security.

However, the real value of the 93 controls does not emerge merely from ticking them off on a checklist.

Controls must be based on the risk assessment.

Applicability justifications must be clear.

Responsibilities must be defined.

Technical and administrative practices must be verified.

Audit evidence must be kept up to date.

Control effectiveness must be measured regularly.

**An effective ISO/IEC 27001 implementation comes not from memorising the 93 controls, but from selecting the right controls to reduce the organisation's real risks and being able to demonstrate that they work.**