ISO 27001 Controls: The Complete Guide to Implementation and Security Control Assessment

ISO 27001 controls are the measures an organization uses to manage information security risks. They can include policies, technical protections, access rules, monitoring activities, and other safeguards used within an Information Security Management System.

The important part is not simply having controls in place. You need to choose the right ones, apply them correctly, keep evidence of how they work, and review them when something changes or a weakness is found.

That is what this guide focuses on. You will learn how to approach ISO 27001 controls during implementation and how a security control assessment can help you check whether those controls are doing what they are supposed to do.

What Are the 93 ISO 27001:2022 Annex A Controls?

Annex A of ISO/IEC 27001:2022 provides a reference set of 93 information security controls. Organizations use it after determining which controls are needed through their information security risk treatment process. The selected controls are then compared with Annex A to check whether anything important has been missed.

You are not expected to implement every Annex A control simply because it appears in the standard. A control should be included when your risks, legal duties, contractual commitments, business requirements, or other security needs justify it. ISO guidance also allows organizations to use controls from other sources or create additional controls where Annex A does not fully address a specific need.

The 2022 structure divides the controls into four themes:

This four-theme structure is also used in ISO/IEC 27002:2022, which provides implementation guidance for information security controls.

Organizational Controls

Organizational controls deal with the policies, responsibilities, and business processes that support information security across the organization.

They cover areas such as:

• Security policies and assigned responsibilities
• Separation of duties and contact with relevant authorities
• Threat intelligence and asset management
• Classification, acceptable use, and secure information transfer
• Identity and access governance
• Supplier and cloud security
• Incident preparation and response
• Security during disruption and ICT continuity readiness
• Legal, contractual, privacy, and compliance obligations
• Independent reviews of information security arrangements

Together, these controls provide the management structure needed to coordinate security across people, suppliers, information, and business operations.

People Controls

People controls address security risks linked to employees, contractors, and other personnel throughout their relationship with the organization. They cover more than awareness training and apply across the personnel lifecycle.

Key areas include:

• Background screening and employment terms
• Security awareness and training
• Disciplinary procedures
• Role changes and departures
• Confidentiality agreements
• Remote working
• Reporting security events

Together, these controls help keep security responsibilities clear as access, duties, and employment status change.

Physical Controls

Physical controls protect facilities, equipment, information, and supporting infrastructure from unauthorized access, damage, interference, and environmental risks.

They cover areas such as:

• Security perimeters and controlled entry
• Offices, rooms, and secure areas
• Physical monitoring
• Environmental and physical threats
• Clear desk and clear screen practices
• Equipment placement, maintenance, and off premises use
• Storage media, utilities, and cabling
• Secure equipment disposal or reuse

Technological Controls

Technological controls address security within systems, applications, networks, infrastructure, and development activities. They cover a broad set of technical areas, including:

• Endpoint protection, authentication, and privileged access
• Malware, vulnerabilities, configurations, and software installation
• Deletion, masking, leakage prevention, backups, and redundancy
• Logging, monitoring, and clock synchronization
• Network security, web filtering, and cryptography
• Secure development, coding, testing, and change management
• Separation of development, test, and production environments
• Protection of test information and systems during audit activities

These controls focus on how technology is operated and protected.

What Changed From ISO 27001:2013 to ISO 27001:2022?

The 2022 edition changed the way Annex A is organized. The 2013 version had 114 controls spread across 14 domains. The current edition has 93 controls grouped under four themes.

You should not read the lower number as 21 security requirements being dropped. A large part of the change came from bringing related controls together, removing overlap and reshaping the structure around current security needs. BSI records 24 merged controls, 58 revised controls, and 11 new controls in the 2022 update.

The 11 new ISO 27001 security controls are:

1. A.5.7 Threat intelligence
2. A.5.23 Information security for use of cloud services
3. A.5.30 ICT readiness for business continuity
4. A.7.4 Physical security monitoring
5. A.8.9 Configuration management
6. A.8.10 Information deletion
7. A.8.11 Data masking
8. A.8.12 Data leakage prevention
9. A.8.16 Monitoring activities
10. A.8.23 Web filtering
11. A.8.28 Secure coding

Several of these controls deal with areas that have become harder to ignore in modern environments. Cloud services now have a dedicated control. Threat intelligence and monitoring receive clearer attention. Configuration, data leakage, and secure coding are also addressed directly rather than being left within broader control wording.

How to Implement ISO 27001:2022 Controls Step by Step

Most control problems start much earlier than implementation. A team picks a safeguard, configures it, and only later asks what risk it was meant to reduce.

ISO 27001 takes the opposite approach. First identify the risk or requirement. Then decide what the control needs to achieve, who is responsible for it, how it should work, what evidence should exist, and how its performance will be checked.

Annex A is useful for checking whether anything important has been missed, but it should not become the implementation plan itself.

Start With the Risk or Requirement the Control Addresses

Every control needs a reason. That reason might be:

• A risk identified during assessment
• A legal or regulatory obligation
• A contract or customer requirement
• An internal policy
• A supplier condition
• A continuity objective

Take MFA as an example. Adding it simply because it is considered good security practice gives you very little context. Linking it to the risk of unauthorized access to privileged accounts makes the purpose much clearer.

You are also not limited to Annex A. If a particular risk needs a control that is not covered there, you can use another suitable control or define one yourself.

Define the Control Objective

Set out what the control needs to achieve before deciding how it will work. Identify the event it should prevent, detect, or correct, what it covers, and what a successful result looks like. Also define expected outputs and signs of failure. A clear objective gives you something concrete to measure when effectiveness is reviewed later.

Assign Clear Control Ownership

A control should not automatically become the cybersecurity team’s responsibility just because it relates to security. Ownership needs to follow the process, system, or business activity involved. ISO/IEC 27001 requires relevant information security roles and responsibilities to be assigned and communicated within the organization.

Depending on the control, you may need separate people for:

• Control ownership
• Process ownership
• Technical operation
• Evidence collection
• Review or approval

A control register can help keep those responsibilities visible. Useful fields include:

• The control ID
• Objective
• Related risk
• Scope
• Owner
• Supporting policies
• Implementation status
• Evidence source
• Review frequency
• Effectiveness measure

The register itself is a practical management tool rather than a specific ISO 27001 requirement. What matters is that responsibilities are clear and that you can monitor whether the control continues to perform as expected. ISO guidance on Clause 9.1 also supports defining what needs to be monitored and how effectiveness will be evaluated.

Design the Control Before Implementing It

Before putting a control into use, decide exactly how it will work.

Define:

• Who performs the activity
• What triggers it
• Which systems, assets, or processes it covers
• How often it runs
• Required inputs and approvals
• Expected output
• Exceptions and escalation steps
• How long evidence should be kept

A vague control is difficult to review during an iso assessment. A well-designed one gives you clear points to test later.

Implement the Control

Once the design is agreed, put the control into use across the full scope it was meant to cover. Depending on the control, implementation may involve:

• Policies and procedures
• System configurations
• Security tools
• Contracts
• Employee training
• Physical safeguards
• Monitoring
• Workflow automation
• Assigned responsibilities

Do not stop after applying the control to one team, system, or location if the approved scope is wider. Partial implementation can leave the original risk only partly addressed. ISO/IEC 27001 expects controls to be implemented as part of the organization’s risk treatment process and within the scope of its ISMS.

Make Evidence a Natural Output of the Control

Do not wait for an audit to start looking for proof that a control has been working. The better approach is to let normal operations create the records you will need later.

That evidence may include:

• Access review reports and approvals
• Vulnerability scans and remediation records
• SIEM alerts and incident tickets
• Training records
• Supplier assessments
• Backup and restoration logs
• Configuration histories
• Code reviews and change records

ISO management system guidance treats retained documented information as evidence of results achieved.

Assess Whether the Control Is Effective

Having a control in place does not prove that it works. Check whether it is properly designed, covers the intended scope, runs when expected, produces the required output, creates evidence, handles exceptions correctly, and achieves its security objective.

Record Findings, Exceptions, and Corrective Actions

When a control does not work as expected, record enough detail for someone to understand the problem and follow it through to closure.

Include:

• Affected control
• Finding and supporting evidence
• Related risk
• Affected assets or processes
• Root cause
• Responsible owner
• Corrective action
• Due date
• Approved exception or risk acceptance
• Retest result

ISO management system requirements expect organizations to respond to nonconformities, determine their causes, take appropriate corrective action, and retain evidence of what was done and whether it worked.

Reassess and Feed the Results Back Into the ISMS

A control review should lead somewhere. Findings may change the risk assessment, affect a treatment decision, trigger a corrective action, or show that the Statement of Applicability needs updating.

The results can also feed into:

• Internal audits
• Ongoing control monitoring
• Management review
• Future security spending
• Control redesign
• Later reassessment

How to Perform an ISO 27001 Security Control Assessment

A security controls assessment looks at whether a control is properly designed, actually implemented, working consistently, and achieving the result it was created for. Evidence should support those conclusions.

A practical way to structure the work is to use Examine, Interview, and Test. NIST SP 800-53A defines these as three assessment methods for gathering evidence. ISO 27001 does not prescribe this method, so it should be treated as a useful assessment approach rather than an ISO requirement.

How far you go with each method should depend on the risk, importance of the control, criticality of the system, previous findings, known problems, and complexity of the environment. NIST allows assessment depth and coverage to be adjusted according to the assurance required.

A comprehensive ISO 27001 security audit can help evaluate whether security controls are properly designed, implemented, and supported by appropriate evidence.

Examine

Start with the records that show how the control is supposed to work and what has happened during normal operation.

Review material such as:

• Policies and procedures
• Configuration standards
• Access records and logs
• Contracts
• Tickets and change records
• Vulnerability reports
• Risk registers
• Supplier assessments
• Incident records

Then check whether the evidence is current, complete, relevant to the control, consistent with other records, and taken from the correct scope.

A written policy can show what an organization intends to do. It does not, by itself, show that the activity is happening consistently. Operational records are needed to see whether the control is actually being followed. 

Interview

Documents tell you what the process is supposed to be. Interviews help you find out what actually happens.

Speak with people who design, operate, review, or depend on the control, such as:

• Control owners
• System administrators
• Developers
• Security Operations staff
• HR or Procurement teams
• Facilities
• Managers
• Employees affected by the process

Use those conversations to check whether responsibilities are understood, exceptions are handled properly, and day to day practices match the written procedure. They can also uncover informal workarounds or show what staff do when the normal process breaks down.

Test

Some controls need to be exercised, not just reviewed. Testing lets you compare what should happen with what actually happens.

Depending on the control, you might:

• Restore a backup
• Confirm MFA is enforced
• Inspect privileged accounts
• Check whether access is removed after termination
• Follow a vulnerability from detection to remediation
• Trigger and validate security alerts
• Test incident escalation
• Review security configurations
• Trace application security findings through remediation

For technical controls, ISO 27001 penetration testing can help identify exploitable vulnerabilities and validate whether security measures are effective against real-world attack scenarios.

Validate Your Security Controls with Expert Testing.

What Evidence Demonstrates That an ISO 27001 Control Actually Works?

Good evidence should tell you more than whether a policy, setting, or procedure exists. It should show that the control has been used consistently and that its operation can be checked against the security result it was meant to achieve. ISO/IEC TS 27008 specifically covers reviewing the implementation and operation of information security controls within an ISO 27001 ISMS.

Three questions help separate documented intent from evidence of operation:

1. Does the control exist?
2. Did it operate consistently?
3. Did it achieve its intended result?

Evidence Sampling

For controls that run repeatedly, reviewing every transaction may not be practical. Sampling lets the assessor examine a selection of activity, but the sample needs enough coverage to reveal meaningful weaknesses.

Consider:

• Risk and control importance
• How frequently the activity occurs
• Transaction volume
• Number of systems and business units
• Geographic spread
• Privileged and standard users
• Known exceptions
• Significant recent changes
• Previous failures

Suppose 3,000 employees left during the review period. One correctly completed termination tells you very little about how reliably access was removed across the whole population.

A more useful sample could include different months, departments, locations, contractors, employees, privileged accounts, and unusual cases. 

Navigating ISO 27002:2022 Control Attributes

ISO/IEC 27002:2022 adds attributes to the control set. These attributes do not create extra controls. They also do not introduce new certification requirements.

Their purpose is to help you look at the same controls from different angles. A control can be grouped by what it does, what security property it supports, or which operational area it belongs to.

The five attribute perspectives are:

• Control type
• Information security properties
• Cybersecurity concepts
• Operational capabilities
• Security domains

For implementation and assessment, control type and operational capability are especially useful because they make it easier to understand how a safeguard works in day to day security operations. 

Control Types: Preventive, Detective, and Corrective Controls

ISO/IEC 27002 uses three control type values.

Preventive controls are intended to stop or reduce the chance of a security event. Examples include MFA, access restrictions, secure coding, network segmentation, and employee screening.

Detective controls help you notice problems after or while they occur. Security logging, vulnerability scanning, intrusion detection, monitoring, and access reviews are common examples.

Corrective controls help you respond after a weakness or incident is found. Patching, account removal, backup restoration, incident response, and corrective action after an audit can fall into this category.

No single type is enough on its own. Access restrictions may block an unauthorized user, but they will not always reveal misuse of a legitimate account. Monitoring can help detect that activity.

Operational Capabilities: Manual, Automated, and Hybrid ISO 27001 Controls

For day to day control management, it can still be useful to describe a control as manual, automated, or hybrid. This is a practical way to explain how the work gets done, not an ISO/IEC 27002 classification.

Manual controls depend mainly on people carrying out an activity. Examples include supplier reviews, management approvals, employee screening, visitor checks, and manual access reviews.

When assessing them, look for missed tasks, inconsistent execution, poor records, or too much dependence on one person.

Automated controls rely mainly on technology. MFA enforcement, endpoint protection, automated logging, scheduled vulnerability scans, and cloud security rules are common examples.

The main problems tend to be different:

• Incorrect configuration
• Disabled agents
• Failures that nobody reviews
• Systems left outside the control scope
• Exclusions that are no longer justified

Hybrid controls combine technology with human decisions. Vulnerability management is a good example. A scanner may find weaknesses automatically, while security and engineering teams validate the findings, decide priorities, assign fixes, approve exceptions, and retest completed work.

Buying a security tool is not the same as having an effective control. The surrounding process still has to work.

Why ISO 27001 Controls Fail During Assessment

A control can look complete in documentation and still fall apart when someone checks how it works. Assessment exposes the difference between what has been written, what has actually been implemented, and what can be supported with evidence.

Controls Were Selected Before the Risks Were Properly Understood

Starting with the Annex A list instead of the risk can lead to controls that do not fit the problem. You may end up with irrelevant safeguards while a genuine risk remains untreated.

This usually shows up as:

• Weak control objectives
• Missing safeguards
• Controls with no clear risk connection
• Poor justification in the Statement of Applicability

ISO guidance makes clear that necessary controls come from risk treatment and other applicable requirements. Annex A is then used to check whether anything necessary has been overlooked.

Policies Exist, but the Control Does Not Operate

A policy tells an assessor what should happen. They still need evidence that it did happen.

Common examples are straightforward:

• An access review policy with no completed reviews
• A backup procedure with no restoration testing
• An incident response process that has never been exercised

Documentation alone cannot demonstrate that a control operates as intended.

Control Ownership Is Unclear

Problems appear quickly when several teams are involved, and nobody knows who owns the final responsibility.

Security may expect HR to remove access after an employee leaves. HR may assume IT handles it. Procurement may believe supplier reviews belong to Security, while Security expects Procurement to run them. Name the owner and make the escalation path clear. Otherwise, missed actions can remain unnoticed until the assessment reaches them.

Evidence Is Created Only Before the Audit

Records created a few days before an audit show what happened at that moment. They do not show whether the control operated throughout the review period.

For recurring controls, an assessor may want evidence from different dates or operating cycles. That could include several access reviews, backup results, vulnerability remediation records, or monitoring activity rather than a single recent example.

Control Scope Does Not Match ISMS Scope

A control may work perfectly on the assets it covers and still leave a serious gap.

Consider vulnerability scanning that covers traditional servers but leaves out:

• Cloud workloads
• APIs
• Applications
• Remote endpoints

If those assets fall within the relevant ISMS and control scope, excluding them weakens the assessment result.

The Statement of Applicability Does Not Match Reality

The Statement of Applicability should reflect the controls the organization actually considers necessary and their implementation status.

Warning signs include:

• A control marked as implemented with no supporting evidence
• An owner who cannot explain how the control operates
• Only part of the stated environment being covered
• A documented frequency that is not followed

Tools Are Mistaken for Complete Security Controls

Buying or enabling a product proves very little about how the surrounding security process works.

For example:

• A SIEM does not show that alerts are investigated
• A scanner does not show that findings are fixed
• Enabled backups do not show that data can be restored
• Deployed EDR does not confirm coverage across every required endpoint

The assessment needs to look beyond the technology and check what happens after the tool produces an alert, finding, or other output.

Exceptions Are Not Properly Controlled

Some exceptions are legitimate. Problems arise when nobody can explain why they exist or how long they are allowed to remain.

For each exception, record:

• An owner
• The reason
• The associated risk
• Approval
• Compensating safeguards where needed
• An expiry point
• A review date

That gives the assessor a clear record of how the deviation is being managed rather than leaving it as an unexplained gap.

Metrics Measure Activity Instead of Effectiveness

Measures such as the number of policies written, controls marked implemented, or scans completed say little about the security result.

More useful measures might include:

• Overdue vulnerabilities
• Percentage of terminated accounts disabled within the defined target
• Backup restoration success rate
• Recurring security findings
• Unresolved access review exceptions

ISO/IEC 27004 focuses on monitoring and measuring information security performance and the effectiveness of ISMS processes and controls. 

Identify Security Gaps Before Your Next Audit

Choose a cybersecurity partner that helps you identify and remediate real security risks while supporting your regulatory compliance goals.

Talk to an Expert→

How Qualysec Can Support Technical ISO 27001 Control Assessment

An ISO 27001 program can tell you which technical safeguards matter, but you still need to know whether those safeguards hold up when tested.

Qualysec provides penetration testing for web applications, mobile applications, APIs, cloud environments, external networks, and IoT systems. Its approach combines automated checks with manual attacker-style testing to uncover issues such as weak configurations, access control flaws, business logic problems, and vulnerabilities that scanners may miss.

The assessment can also provide practical evidence through:

• Severity-rated findings
• Reproduction steps
• Remediation guidance
• Executive summaries
• Retesting support

These results can support the assessment of relevant technical controls and help confirm whether remediation has actually worked.

Penetration testing does not replace the ISMS, risk assessment, risk treatment, Statement of Applicability, internal audit, or certification audit. It only provides evidence for the technical systems and controls that were tested.

Qualysec can help if you need independent testing before an audit or want to verify fixes within your ISO 27001 scope.

Conclusion

ISO 27001 control work starts with the risk that needs to be addressed. The control then needs a clear purpose and an owner. It must be implemented across the right scope and supported by evidence.

The next question is whether it works. That means checking performance, fixing weaknesses, and testing again when needed. A control can be marked as implemented and still fail to reduce the risk it was meant to address.

Regular review keeps the ISMS aligned with changes in systems, threats, and business requirements.

FAQS

Do organizations have to implement all 93 ISO 27001 controls?

No. Organizations determine the controls they need through risk treatment and then compare them with Annex A to check whether anything necessary has been missed. Controls outside Annex A can also be used when required.

How do you assess whether an ISO 27001 control is effective?

Look beyond whether the control exists. Review how it operates, examine supporting evidence, and check whether it achieves the intended security result. ISO/IEC TS 27008 provides guidance for assessing both implementation and operation.

Does ISO 27001 require penetration testing?

ISO/IEC 27001 does not prescribe penetration testing as a universal requirement. Testing may still be necessary when it supports identified risks, technical control validation, regulatory obligations, or other security requirements within the ISMS.