Home | News | Understanding the Statement of Applicability requirements for ISO 27001?

News

Understanding the Statement of Applicability requirements for ISO 27001?

Understanding The Statement Of Applicability Requirements For Iso 27001?

Understanding the Statement of Applicability requirements for ISO 27001?

Understanding the Statement of Applicability requirements for ISO 27001? means understanding how your organisation turns information security risks into documented control decisions.

The Statement of Applicability, often shortened to SoA, is one of the most important records within an Information Security Management System. It explains which information security controls your organisation has determined are necessary, why you need them, whether you have implemented them, and why you have excluded any controls from ISO 27001 Annex A.

ISO/IEC 27001:2022 places the Statement of Applicability within the information security risk treatment process. Clause 6.1.3 requires the organisation to determine the controls needed to implement its chosen treatment, compare those controls with Annex A to make sure it has not overlooked anything necessary, and produce a Statement of Applicability recording the resulting decisions. ISO committee guidance describes these as the organisation’s necessary controls.

This makes the SoA much more than an Annex A checklist. It provides a clear connection between risk assessment, risk treatment, business requirements, legal duties, contracts, customer expectations and the controls your organisation actually operates.

UK Cyber Compliance supports organisations through this work using an automated and AI-driven platform. UK Cyber Compliance (a part of UK Cyber Security Group) provides these services and has a platform to make certification much easier and cheaper. Its platform helps businesses manage ISO 27001 risks, controls, documentation, evidence and audit readiness through a structured process.

Why the Statement of Applicability matters

The SoA gives management and auditors a clear picture of the organisation’s information security control environment.

Imagine reviewing a company without one.

The risk register identifies account compromise, supplier failure, ransomware and unauthorised disclosure as important concerns. Several policies exist. Security tools operate across computers and cloud services. Staff receive awareness training.

Without a central control record, however, it becomes difficult to answer some basic questions.

Why does the organisation use each control?

Which risk does it help manage?

Has management implemented it?

Who owns it?

What evidence supports it?

Did the organisation consider every relevant Annex A control?

Why did management decide that another Annex A control was unnecessary?

The Statement of Applicability brings those decisions together.

A well-maintained SoA makes the ISMS easier to understand because it creates traceability from business need to security action.

What is ISO 27001 Certification?

ISO 27001 certification provides independent assurance that an organisation operates an Information Security Management System that meets the requirements of ISO/IEC 27001.

ISO describes ISO/IEC 27001 as the world’s best-known standard for information security management systems. It provides requirements for establishing, implementing, maintaining and continually improving an ISMS.

An ISMS connects areas such as business context, leadership, scope, information security risk, objectives, policies, controls, suppliers, people, technology, internal audit, management review and continual improvement.

Certification does not mean that a business has eliminated every cyber security risk.

Instead, the organisation demonstrates that it understands its risks and manages them through a structured system.

The Statement of Applicability plays an important role because it demonstrates how management converted risk and other requirements into control decisions.

An auditor can use it to understand what the organisation claims to have implemented and then test those claims against actual evidence.

What is iso 27001

ISO 27001 is the commonly used name for ISO/IEC 27001:2022, the international requirements standard for information security management systems.

The standard helps organisations manage information security risks that could affect confidentiality, integrity and availability.

Confidentiality means information remains accessible only to authorised people and systems.

Integrity means information remains accurate, complete and trustworthy.

Availability means authorised users can access information and services when they need them.

Your SoA should reflect the controls needed to protect these security principles within your ISMS scope.

For example, a risk involving unauthorised access may lead to identity management, authentication, access rights and logging controls.

A risk involving loss of data may lead to backup and resilience controls.

A supplier risk may require supplier security and cloud service controls.

The Statement of Applicability records the control position that results from those decisions.

The SoA begins with risk treatment

A common mistake involves opening Annex A first and deciding that ISO 27001 requires all 93 controls.

That does not accurately reflect the standard.

The correct starting point is information security risk.

Your organisation identifies risks, analyses them and evaluates whether they meet the approved acceptance criteria.

When a risk remains above tolerance, management determines how to treat it.

The organisation then determines the controls needed to support that treatment.

Clause 6.1.3 requires the organisation to compare those necessary controls with Annex A so it can check that it has not unintentionally omitted something important. ISO committee guidance describes Annex A as a reference that supports this comparison.

This sequence matters because it keeps ISO 27001 focused on real information security needs.

Annex A contains 93 controls

ISO/IEC 27001:2022 Annex A contains 93 information security controls.

They sit within four broad groups:

Organisational controls

People controls

Physical controls

Technological controls

These measures cover subjects such as policies, roles, threat intelligence, assets, access, suppliers, cloud services, incidents, continuity, staff responsibilities, physical security, authentication, malware protection, backup, logging, vulnerability management, networks and secure development.

An organisation must consider Annex A during risk treatment.

That does not mean every Annex A control must automatically become necessary.

Your organisation evaluates its own circumstances and records the result in the Statement of Applicability.

UK Cyber Compliance also describes the SoA as the record that shows which Annex A controls apply, why they apply, whether the organisation has implemented them and why exclusions exist.

What the Statement of Applicability must contain

ISO 27001 places clear requirements on the SoA.

The document needs to contain the necessary controls that the organisation has determined through its information security risk treatment process.

It needs to explain why the organisation included those controls.

It needs to state whether the organisation has implemented the necessary controls.

It also needs to explain why the organisation has excluded any Annex A controls.

These points form the formal core of the Statement of Applicability.

Many businesses add further fields because they make the document easier to manage.

For example, an organisation may record the control owner, related risks, policy references, evidence, review information and outstanding actions.

Those additional fields can provide useful traceability, but organisations should understand the difference between what the standard specifically requires and what they add for practical management.

Necessary controls are not limited to Annex A

Another important point often gets missed.

Your necessary controls can include measures that do not appear in Annex A.

ISO 27001 asks the organisation to determine what controls it needs to treat its risks. Annex A then acts as a comparison reference.

If your organisation needs an additional security measure because of a specialist technology, customer obligation or particular business risk, that measure can become a necessary control.

You should include it in the SoA because the SoA records the necessary controls, not merely the Annex A controls that management selected.

This gives ISO 27001 flexibility.

A specialist technology provider can implement additional measures that reflect its environment rather than forcing every requirement into an Annex A label.

The reason for inclusion matters

A Statement of Applicability should explain why each necessary control belongs within the ISMS.

Good reasons can come from several sources.

Risk treatment may require the control.

A law may create a security obligation.

A customer contract may require a particular safeguard.

A supplier arrangement may create a dependency.

A business objective may require stronger resilience.

An internal policy may create an operational requirement.

Customer expectations may justify additional assurance.

For example, your organisation might include access rights controls because the risk assessment identifies unauthorised access to customer information as significant.

Supplier controls may apply because several third parties process information or support critical services.

Backup controls may apply because loss of information could cause unacceptable operational disruption.

The explanation does not need unnecessary complexity, but it should make the reasoning clear.

Exclusions need credible justification

Excluding an Annex A control should involve genuine analysis.

Do not exclude a control simply because implementing it appears inconvenient.

The justification should explain why the control does not apply to the organisation’s circumstances or why no necessary requirement calls for it.

An auditor may challenge an exclusion that appears inconsistent with the ISMS.

For example, excluding supplier-related measures would be difficult to justify if the business depends heavily on cloud and outsourced services.

Excluding remote working measures would raise questions if most employees routinely work away from business premises.

A good justification should make sense when compared with the organisation’s scope, risk register, contractual duties and operational reality.

Applicability is not the same as implementation

These ideas should remain separate.

A control can be necessary but not yet fully implemented.

For example, management may determine that a logging control is necessary because monitoring forms part of the treatment for unauthorised access risk.

The organisation may still be working towards full implementation.

The SoA should reflect that position accurately.

Do not mark a necessary control as excluded simply because implementation has not finished.

Likewise, do not mark the control as fully implemented merely because a project exists.

Accurate status information gives management a realistic view of certification readiness.

Planned controls need actions behind them

When the SoA identifies a necessary control that has not yet reached the required implementation position, management should connect it with a clear action.

The action should identify what needs to happen, who owns the work and when management expects completion.

Suppose the organisation identifies stronger supplier assurance as necessary.

The action could involve reviewing critical suppliers, obtaining security evidence and documenting the resulting decisions.

Another control may require periodic restoration testing for important information.

The organisation could assign the action to the relevant technical owner and retain the test record after completion.

This approach turns the SoA into an active management tool rather than a static document.

Link the SoA to the risk register

The risk register and SoA should support each other.

The risk register explains what could go wrong.

Risk treatment explains what management intends to do.

The SoA records the controls required to support those decisions.

For example, the risk register may contain a scenario stating that an attacker could compromise a cloud administrator account and gain access to sensitive information.

Treatment might require stronger authentication, restricted privileged access, logging and regular access review.

The SoA should reflect those necessary controls.

An auditor can then follow the logic from risk to treatment to control.

UK Cyber Compliance highlights this relationship and describes the SoA as a central connection between information security risk and control decisions.

Link legal and contractual duties as well

Risk is not the only reason a control becomes necessary.

Legal requirements can influence control selection.

Contracts can do the same.

For example, a customer agreement might require encryption of particular information.

A privacy obligation may influence access management, secure disposal or incident controls.

A contract may require the organisation to maintain recovery capability.

A regulator may expect particular records.

The Statement of Applicability can document these reasons.

UK Cyber Compliance notes that legal, regulatory, contractual and business needs can all justify control inclusion.

This creates useful evidence that control selection follows genuine requirements rather than guesswork.

Make ownership visible

Although ISO 27001 does not require a control owner field within the SoA itself, recording ownership can make the document much more useful.

A control needs somebody to maintain it.

For example:

Human resources may own employee screening activity.

IT may own authentication controls.

Procurement may own parts of supplier management.

Operations may own business continuity processes.

A security manager may own incident coordination.

Clear ownership helps management understand who needs to provide evidence and who should respond when the control does not work as expected.

It also helps during audit interviews.

Evidence turns SoA claims into assurance

An SoA that says “implemented” creates an expectation.

The organisation should be able to demonstrate that implementation.

Evidence will depend on the control.

Access management may use account reviews and approvals.

Supplier assurance may use assessments, contracts and review records.

Backup measures may use completion reports and restoration test records.

Awareness measures may use participation records.

Incident management may use incident logs and exercises.

Vulnerability management may use scanning and remediation records.

Logging controls may use monitoring output.

The SoA does not necessarily need to contain all evidence itself.

It should help the organisation locate appropriate evidence quickly.

Avoid generic justifications

Generic wording weakens the SoA.

Consider this reason:

“Required for security.”

That statement says very little.

A stronger explanation might say:

“Necessary to reduce the risk of unauthorised access to customer information and support contractual access-control requirements.”

Another weak explanation might say:

“Not relevant.”

A stronger exclusion explains the actual reason.

Clear wording helps auditors, control owners and senior managers understand the decision without having to reconstruct it.

Keep the SoA aligned with policies

Policies describe how the organisation expects people and systems to operate.

The SoA should agree with those policies.

Suppose the SoA says the organisation has implemented periodic access reviews.

The access control policy should support that approach.

Operational evidence should then show that the reviews actually occur.

If the SoA says supplier monitoring operates, supplier processes and records should demonstrate the same position.

Contradictions weaken confidence in the ISMS.

Good alignment creates a simple chain:

Requirement

Control

Policy or process

Operational activity

Evidence

Keep the SoA aligned with actual technology

Technology changes quickly.

A company may move from internally managed servers to cloud platforms.

It may adopt a new identity service.

It may outsource monitoring.

It may replace its backup platform.

These changes can affect control implementation.

The SoA should reflect the environment that actually exists.

Do not leave descriptions in place simply because they were correct during the original certification project.

If the way a control operates changes, update the relevant records and evidence.

The SoA should reflect the ISMS scope

The Statement of Applicability only makes sense in relation to the defined ISMS scope.

A focused scope may produce different control decisions from a whole-organisation scope.

For example, a certification scope covering a cloud software service needs to consider the people, information, development activity, infrastructure and suppliers that support that service.

A control exclusion should make sense within that boundary.

When the scope changes, review the SoA.

Adding another office, acquiring a company or bringing another service within certification may introduce new information security requirements.

Review the SoA after risk changes

The SoA should not remain fixed while the risk register changes around it.

A new high risk may require additional treatment.

That treatment may require a control that management had previously considered unnecessary.

An incident may show that an existing control needs strengthening.

A customer may introduce a new contractual requirement.

A new supplier may create additional dependency.

Each of these events can change the control position.

Review the SoA whenever changes materially affect the organisation’s information security needs.

Internal audit should test the SoA

Internal audit provides an excellent opportunity to check whether the SoA remains accurate.

An internal auditor can select controls and ask:

Why did management determine this control was necessary?

Which risk or requirement supports the decision?

Has the organisation implemented the control as claimed?

Can the control owner explain how it works?

Does supporting evidence exist?

Does the risk register agree with the SoA?

Are exclusions still reasonable?

Have business changes affected applicability?

This review can identify problems before the external certification assessment.

Management review should use the SoA

Senior management does not need to review every line of the SoA in every meeting.

It should, however, understand major control gaps and significant changes.

Useful management information may include:

Necessary controls that remain incomplete

Controls with recurring failures

Major changes in applicability

Significant audit findings

Resource shortages

New customer requirements

Important supplier issues

Controls connected with high residual risks

This gives leaders a clearer view of where the ISMS requires attention.

Current UK cyber statistics reinforce the value of structured controls

The UK Government’s Cyber Security Breaches Survey 2025 to 2026 found that 43 per cent of businesses identified a cyber breach or attack during the previous 12 months. That represented approximately 612,000 UK businesses.

Medium businesses reported a 65 per cent incidence, while large businesses reported 69 per cent.

Only 30 per cent of businesses reported conducting a cyber security risk assessment during the previous year. The figure for small businesses fell to 41 per cent from 48 per cent in the previous survey period.

Supplier risk assessment remained limited as well. Fifteen per cent of businesses formally reviewed immediate supplier risks and only 6 per cent reviewed their wider supply chain.

These findings show why organisations benefit from a structured relationship between risk assessment and control selection.

Security measures create more value when management can explain which risk or requirement each measure addresses.

Who needs iso 27001 certification

ISO 27001 certification can benefit organisations that manage important information or need to demonstrate structured information security governance.

Technology providers, cloud businesses, managed service providers, software companies, professional firms, manufacturers, healthcare suppliers, financial organisations, charities and public-sector suppliers may all find value in certification.

Customers often drive the requirement.

A client may want independent assurance that a supplier manages information security using an internationally recognised framework.

Tender requirements can create another reason.

Supply-chain assurance may also make certification commercially useful.

The Statement of Applicability supports these relationships because it shows that control decisions follow a managed process.

It demonstrates that the organisation considered its risks and requirements instead of applying security measures without clear reasoning.

ISO 27001 Certification Levels

ISO 27001 does not use formal achievement bands such as bronze, silver or gold.

An organisation either holds certification for its declared ISMS scope or it does not.

Businesses still move through practical stages on the journey towards certification.

They define scope, understand interested parties, identify legal requirements, assess information security risks, plan risk treatment, determine necessary controls, compare them against Annex A, prepare the SoA, implement controls and gather evidence.

The organisation then completes internal audit and management review before the external certification assessment.

After certification, it continues operating, reviewing and improving the ISMS.

A more mature organisation may have stronger evidence, better automation and clearer control ownership, but that maturity does not create another official certification band.

How the Certification Works

The certification journey begins with understanding the organisation and defining the ISMS scope.

Management identifies relevant interested parties and their information security requirements.

The organisation creates a risk assessment methodology and identifies information security risks.

It evaluates those risks against approved criteria.

Risks that need further attention move into treatment.

The organisation determines the controls required to implement that treatment and compares its necessary controls against Annex A.

Management then produces the Statement of Applicability.

The SoA records the necessary controls, the reasons for including them, their implementation position and the reasons for excluding Annex A controls.

The organisation operates the controls and gathers evidence.

Internal audit checks whether the ISMS meets the organisation’s own requirements and ISO 27001 requirements.

Management review gives senior leadership a formal opportunity to examine performance, risk, audit findings, resources and improvement needs.

An independent certification body then assesses the ISMS against ISO/IEC 27001.

Certification demonstrates that the management system meets the standard within its defined scope. ISO itself develops the standard but independent certification organisations perform the certification activity.

What auditors look for in the SoA

Auditors often review the Statement of Applicability closely because it provides a useful map of the control environment.

They may select a control and trace it backwards.

Why is it necessary?

Which risk or requirement supports it?

Who operates it?

Does the organisation really implement it?

Where is the evidence?

Does the risk treatment plan agree?

They may also test exclusions.

Why did the organisation decide the Annex A control was unnecessary?

Does that reasoning make sense given the scope?

Has anything changed since management made the decision?

A clear SoA makes these questions much easier to answer.

Common SoA mistakes

Several recurring mistakes can create problems.

One involves treating Annex A as a checklist and marking every control as applicable without analysing whether it is actually necessary.

Another involves excluding controls simply because the organisation has not finished implementing them.

Generic justifications also create weak records.

Further issues include outdated implementation information, missing links to risk treatment, controls marked complete without evidence, poor ownership and contradictions between the SoA and policies.

Some organisations also forget that necessary controls can extend beyond Annex A.

A good SoA reflects the organisation rather than a downloaded template.

Do not make every justification identical

Repeated wording can make it look as though the organisation never considered each control properly.

For example, writing “required because of risk” against dozens of controls gives little insight.

Provide concise but meaningful reasoning.

Some controls may relate directly to specific information security risks.

Others may support legal requirements.

Some may arise from contracts.

Another control may support an important business continuity requirement.

The wording does not need to become lengthy.

It needs to demonstrate thought.

Make exclusions understandable to somebody outside the project

An exclusion should still make sense six months later when a different employee reads it.

Avoid relying on knowledge held only by the person who built the ISMS.

A useful justification explains the relevant circumstance.

For example, management may determine that an Annex A measure does not apply because the activity addressed by the control does not occur within the ISMS scope and no risk or other requirement creates a need for that measure.

The organisation should revisit the decision if circumstances change.

Which UK-based firms offer ISO 27001 consultancy services?

UK organisations can obtain ISO 27001 assistance from information security consultancies, compliance specialists, managed service providers, internal audit professionals and platform-led services.

UK Cyber Compliance provides ISO 27001 support through an automated and AI-driven platform.

Its current information describes functionality covering ISO 27001 tasks, risk management, controls, evidence, documents and audit readiness. The service also provides specific guidance around the Statement of Applicability and its relationship with risk assessment and Annex A.

A capable provider should help the organisation understand why controls apply rather than simply complete the SoA on its behalf.

Useful support can include risk assessment, treatment planning, Annex A comparison, SoA preparation, control ownership, evidence mapping and internal audit readiness.

Management should remain able to explain its own control decisions during the certification assessment.

How UK Cyber Compliance can simplify the SoA

A Statement of Applicability becomes harder to manage when information sits across separate spreadsheets and documents.

The risk register may exist in one file.

Control information may sit elsewhere.

Policies may occupy another folder.

Evidence can become scattered across email, cloud storage and technical systems.

UK Cyber Compliance provides a central environment designed to connect these activities.

Its platform and current guidance describe a structured relationship between risk, controls, documentation, evidence and audit readiness.

A central approach can make it easier to see:

Which controls are necessary

Why management selected them

Which risks they support

Who owns them

Whether they operate

Which evidence exists

Which actions remain open

Whether exclusions still make sense

This improves day-to-day management as well as audit preparation.

A practical Statement of Applicability checklist

Before your certification assessment, check that your organisation has:

  1. Defined the ISMS scope clearly.
  2. Completed an information security risk assessment.
  3. Established risk treatment decisions.
  4. Determined the controls necessary to implement that treatment.
  5. Considered legal, contractual, customer and business requirements.
  6. Compared the necessary controls with all Annex A controls.
  7. Checked that no necessary control has been overlooked.
  8. Included all necessary controls within the SoA, including measures outside Annex A where relevant.
  9. Provided clear reasons for including necessary controls.
  10. Recorded whether necessary controls have been implemented.
  11. Justified every Annex A exclusion.
  12. Kept implementation information accurate.
  13. Linked controls with appropriate risks or requirements.
  14. Assigned ownership where this improves accountability.
  15. Identified relevant supporting evidence.
  16. Connected incomplete controls with actions.
  17. Reviewed the SoA after significant business or technology change.
  18. Checked alignment with policies and operational practice.
  19. Used internal audit to test control claims.
  20. Given management visibility of significant control gaps.

If several of these areas remain unclear, strengthen the SoA before the external audit.

Make the Statement of Applicability a working management record

Understanding the Statement of Applicability requirements for ISO 27001? means recognising that the SoA records the logic behind your information security controls.

Risk assessment identifies what could harm the organisation.

Risk evaluation determines which exposure needs attention.

Risk treatment decides what management will do.

Necessary controls support that treatment.

Annex A provides a reference that helps the organisation check whether it has missed anything relevant.

The Statement of Applicability records the necessary controls, why management needs them, whether they operate and why any Annex A controls have been excluded.

Evidence then demonstrates that the control environment works in practice.

This makes the SoA one of the most useful documents in an ISO 27001 ISMS.

It supports control ownership, audit preparation, management oversight and continual improvement.

UK Cyber Compliance provides an automated and AI-driven platform that helps organisations bring risk, controls, documentation, evidence and SoA activity together within a structured compliance environment.

A strong Statement of Applicability does not merely help an organisation satisfy an auditor. It shows that management understands why its security controls exist, how they relate to risk and whether they genuinely protect the information and services that matter to the business.

UK Cyber Compliance is here to help

For more information, please do get in touch.

Please check out our Free Cyber Insurance

Other blog posts, Your ISO 27001 Questions AnsweredGet ISO 27001 Certified ,

If you would like to know more, do get in touch as we are happy to answer any questions. Looking to improve your cybersecurity but not sure where to start? Begin by getting certified in Cyber Essentials, the UK government’s scheme that covers all the technical controls that will provide the protection that you need to help guard against criminal attacks.