ISO 27001 Statement of Applicability Common Errors

Part of the process of achieving ISO 27001 certification is creating the fundamental documents necessary to outline and prove your security. One of those fundamental documents is the SoA, or Statement of Applicability.

The statement of applicability is a rundown of all of the ISO 27001 security controls, and a discussion of whether or not that control applies to your business. It’s a very important document that you need to get right, but it’s also very easy to get it wrong and, consequently, fail an audit.

To help you make sure you’re getting the paperwork right, we put together this guide to common reasons why a statement of applicability might be deemed inappropriate and fail an audit. As long as you avoid these problems, you’ll have one less reason why you might fail in the certification process.

Understanding the Goal of the Statement of Applicability

First, it’s worth going over why you need a statement of applicability. It’s not paperwork for the sake of paperwork. It’s an important document that forms the basis of what auditors will be looking for when they check over your compliance.

ISO 27001 Annex A outlines the 93 security controls deemed critical for a business to implement to be considered secure. From organizational controls like asset management and incident response, to physical controls like data center security, to technological controls like MFA and data backups, every element of information security has been considered and condensed into this list.

However, there’s no such thing as a perfect framework that fits everyone. If your business doesn’t have a physical location, how can you comply with office or data center physical security controls? If your business doesn’t handle company technological assets, how can you have asset management?

The statement of applicability is the guidebook you create for your business. It assesses the risks posed by the systems and processes you use, the applicable security controls, and how they are implemented to address those risks. In a sense, it’s like an outline of your overall ISMS.

The statement of applicability serves many purposes.

• It identifies when a control applies to your business, and how you’ve understood the risks that the control addresses.
• It identifies controls that are not applicable to your business, and includes justification for why that control is excluded.
• It documents the implementation status of each control on an ongoing basis.
• It serves as a guide for when your business changes, how the risks change and what controls need to be adjusted.

One of the biggest areas of failure is here, when a business does not understand the depth and utility of the statement of applicability, and only provides partial information.

What Goes Into a Statement of Applicability

The statement of applicability is a comprehensive document and includes a lot of information. It can also be variable; a bare-minimum SoA can be pretty different from a robust and complete SoA.

Usually, having a more comprehensive SoA will serve you better. Organizations that put together the bare minimum tend to find that they have to repeat a lot of work as their business grows and changes, while organizations that put in the work up front find it easier to keep the living document up to date.

The bare minimum statement of applicability needs to include:

• A line item for each of the 93 controls in ISO 27001 Annex A, regardless of whether or not you believe they’re applicable to your business. Note that the core mandatory controls in sections 4-10 are not part of the SoA.
• A description of whether or not the control is applicable to your business and implemented.
• If yes to the above, an assessment of why the control is necessary.
• If no to the above, a justification for why the control is not applicable.

A more robust and useful statement of applicability will also include:

• The owner of the control, being the role or specific person responsible for overseeing it.
• An assessment of the risks the control addresses, and how.
• Whether a control is planned to be implemented, but has not been completed yet.
• Relevant dates for implementation and updates to the control.
• Reference documentation for implementation and proof.

Consider that an auditor will be looking at this document in one of their first steps, and will analyze whether or not they think you’ve adequately justified everything you claim. Many ISO 27001 audits fail here, before any of the actual implementation is even assessed.

Common Errors in ISO 27001 Statements of Applicability

Now let’s dig into the common errors that crop up in the statement of applicability. While some of these can be minor and won’t halt an audit process, many of them can lead to a failed audit and cost both time and money to fix. Thus, it’s better to address them before an auditor points them out, which is why we made this guide.

You Failed to Include Every Control

One of the most common reasons why a statement of applicability fails to pass muster is that it’s incomplete.

Broadly, we see three reasons why this happens. Two of them stem from an incorrect understanding of the purpose of the statement of applicability, while the third is more likely a clerical error.

1. You only include the applicable controls and leave off the ones that aren’t applicable. This overlooks the fact that your auditors need to see why you’ve justified leaving off a control.
2. You only include the non-applicable controls and leave off the ones you implement. It’s easy to assume other ISMS documents cover those bases, like your risk assessment, but the SoA is still critical.
3. You leave out seemingly random controls. In rare instances, whoever creates the initial document might accidentally skip or overlook a single control and leave it off the document. While this is easily fixed, it does indicate a flaw in your processes that allowed it to be consistently overlooked by stakeholders who should be verifying the data.

All of these reasons can get your statement of applicability rejected, which can put the entire audit on pause until you complete the document.

It can help to think of the statement of applicability as a sort of operational table of contents or index for the other documents and artifacts within your ISMS. If what you have in the SoA isn’t in order, it indicates deeper problems with the rest of your implementation as well.

Your Justifications for Excluding a Control are Invalid

One of the most common reasons a statement of applicability fails inspection is when you deem a control to be irrelevant, but your justification doesn’t fit.

Obviously, certain justifications won’t work at all. Now and then, a company tries to waive a control by saying implementation would be too time-consuming or too expensive. To that, an auditor says: tough. Do it anyway. If it’s too expensive, maybe ISO 27001 is not for you.

On the other hand, valid justifications require thought. Examples of valid justifications might include:

• A control that addresses a risk that you mitigate in other ways. The existing mitigation needs to be equivalent or better at addressing the risk, and must be something you’ve proactively done.
• A control that Annex A wants you to implement would be ineffective for your situation if done according to the standards. You need specific proof and empirical data to back up this claim.
• Legal requirements or exceptions mean that a control doesn’t apply to your business. This is very rare, but it can occasionally happen in edge cases.

A lot of the justifications used to exclude controls don’t end up standing up against scrutiny. It’s a very high bar to meet, so make sure you have extremely good justification for any you wish to exclude, and be prepared in case even that is not enough.

Your Assessment of Applicability for a Control is Too Narrow

The flip side of justification is explanation. For controls that you know are applicable and you are implementing, you need an assessment of what parts of your business they apply to, and how. This is part of the overall scoping and assessment of security and risk.

When you define a control’s range of applicability, it’s possible to be overly narrow. If that’s the case, it can indicate that you haven’t thought through the entire scenario and have left a gap in your implementation of that security control.

This is one of the trickiest parts of implementing ISO 27001, making it one of the more common failure points of the SoA as well. This is also why the risk assessment is such a big deal; it needs to be as comprehensive as possible.

Scoping helps you narrow the overall breadth of a control’s applicability, and is the acceptable way to reduce the surface a control needs to cover. Narrowing the justification of the control just leaves you with gaps in your defenses.

You Failed to Include References and Proof of Control Implementation

Technically speaking, a statement of applicability does not need to include a section with references for the implementation and proof thereof. However, most auditors will want to see it, or a secondary document that compiles all of the same information (at which point, just add it to the SoA).

Again, the SoA frequently serves as an index or table of contents for referencing the security efforts implemented along Annex A rules. The more useful information that can be added to the statement of applicability, the less an auditor has to go hunting for it, and the more reliably it can all be tracked.

You Have a Serious Disconnect Between Your SoA and Other ISMS Documents

As much as the statement of applicability is a core reference document, it also needs to be part of the overall implementation package.

If you perform an overall risk assessment and document it (which you need to do for ISO 27001 implementation), the risks used to justify and implement Annex A controls should be the same. If there’s a serious disconnect between these documents, it becomes difficult to know which is the canonical information and which is outdated or incorrect.

This also ties into the next reason as well.

Your Statement of Applicability is Not Kept Updated

Your ISMS as a whole, and the documents used as part of it, are not static. They are not one-and-done parts of an application process. They are living documents that reflect the state of your security implementation.

That means they need to be kept up to date as you go. When you perform internal audits or undergo external recertification audits, those documents need to be up to date. It’s also helpful to maintain a version history to further prove that you didn’t just re-make them with new data in time for the audit, but have kept them updated all along.

Some controls won’t change frequently, or at all. Others change more often, as the legal, regulatory, or security atmosphere surrounding them changes. You also need to make sure you’re using the ISO 27001:2022 framework, and not the older 27001:2013, which had more controls and was less streamlined. By now, everyone should have updated, but if you’re a holdout, it’s time to adapt.

Smoothing the ISO 27001 Statement of Applicability Process

A lot of the information in the ISO 27001 Statement of Applicability can be at least partially automated. You can also use a platform like the Ignyte Assurance Platform to track and maintain documents, artifacts, and proof, which can be the source cited in your SoA’s implementation records.

We designed the Ignyte Assurance Platform to be framework-agnostic, so it works for NIST frameworks, ISO frameworks, and others like SOC and HIPAA. It helps you track your implementation, document your ISMS, and accumulate all of your relevant documentation in one place, no matter how widespread or disparate your teams working on it all are.

To see how our platform can help you, schedule a call and book a demo to see it in action. Alongside the platform, we can also help you with our deep familiarity with ISO 27001, and can help ensure you pass your audits the first time through.