The ISO logo surrounded by various icons including a checklist, settings, magnifying glass, check mark, handshake, thumbs up, graph, and award ribbon

Implementing ISO standards is a time-honored way to demonstrate that your business takes excellence seriously — that you strive for rigorous standards in quality, cybersecurity, and information management. 

ISO 27001 is the ISO standard for information security management systems. Organizations around the world strive to achieve compliance with ISO 27001 so they can manage modern information security challenges (which are many), and position themselves as trustworthy business partners to their customer base. 

All that sounds great, but one of the principal challenges of ISO 27001 compliance is simply knowing what you want to do to achieve that compliance. Your organization must first write a Statement of Applicability, outlining which controls in the ISO 27001 standard are the appropriate ones to implement at your organization and which ones aren’t necessary.

In other words, the Statement of Applicability helps to determine the scope of your ISO 27001 project. Crafting the right Statement of Applicability is a tremendously important part of the entire process. Let’s take a deep dive into how to do that.

A crash course on ISO 27001

The ISO 27001 logo

As we mentioned earlier, ISO 27001 is an internationally recognized standard for information security management systems (ISMS). Implementing the standard in your business provides a systematic, disciplined approach to managing and protecting sensitive information within your company: personally identifiable information, health or financial data, intellectual property, or other valuable information you need to keep secure. Compliance with ISO 27001 demonstrates your company’s commitment to safeguarding data, which impresses potential customers and also helps you comply with data privacy laws such as the Health Insurance Portability and Accountability Act (HIPAA), the California Consumer Privacy Act (CCPA) in the United States, or the General Data Protection Regulation (GDPR) in Europe. 

Achieving ISO 27001 compliance is not easy. It entails a risk assessment, where you compare your current information security processes to those dictated by ISO 27001 and then a process of implementing new policies, procedures, and other controls to close whatever gaps you find. You might need to implement new employee training, and you’ll need to perform regular internal audits and management reviews of your ISMS. The list of potential corrective actions you might need to take — and new practices you’ll need to follow — is long.

The finish line of ISO 27001 compliance is an external audit performed by an independent auditor accredited by a recognized certification body. Your business is then certified as ISO 27001-compliant.

The controls that constitute the ISO 27001 standard are listed in an appendix to the standard that’s known as Annex A. It contains 93 individual controls grouped into four larger control categories:

  1. Organizational
  2. People
  3. Physical
  4. Technological

Not every company needs to implement all 93 controls listed in Annex A. You only need to implement the controls that make sense for your specific company, business objectives, and information security risks.

ISO 27001 Statement of Applicability: The Basics

A checklist of portion of the SoA that should always be included: Scope clarification; control selection; rationale and justification; implementation status; and references

Your Statement of Applicability reduces that list of 93 controls in Annex A to the smaller number of controls you plan to implement at your company. At the start of your ISO 27001 journey, the Statement of Applicability helps to define the scope of your information security management system and serves as a roadmap of what work needs to be done to align your information security practices with ISO standards. 

Along the way, however, auditors (both internal and external) will use the Statement of Applicability as a reference document to assess your compliance with ISO 27001. The auditors will examine your controls, check whether those controls align with the controls outlined in the Statement of Applicability, and verify that the controls have been implemented appropriately. 

Simply put, a well-structured and accurate Statement of Applicability is essential for you to understand what you need to do to achieve ISO 27001 compliance and for others to verify that you have done everything necessary. 

More formally, we can define several portions of the Statement of Applicability that should always be included:

Scope clarification

The Statement of Applicability helps define the scope of your ISMS. That is, it specifies the business processes, IT systems, data, and other IT assets covered by the Annex A controls you decide to implement. This assures that auditors and anyone reading the Statement of Applicability will understand exactly what your ISMS entails and how it fits into the larger business.

Control selection

This is where you list the security controls you’ve selected from Annex A. You can organize them by the four control categories mentioned earlier, then list each selected control in its relevant category. Include the objective for each control as well.

Rationale and justification

For each selected control, your Statement of Applicability should include a few sentences about why the control’s inclusion is necessary and how it supports your security needs. This helps auditors and stakeholders understand the thinking behind your cybersecurity program.

Implementation status

Your Statement of Applicability should indicate whether each selected control has been fully implemented, partially implemented, or not implemented at all. In some cases, a control might be deemed not applicable, and the Statement of Applicability should provide reasoning for that decision, too.

References

The Statement of Applicability should include references to related documents or evidence that support the implementation and effectiveness of the selected controls. For example, you could point to employee training data, results of vulnerability scans, user access policies, and so forth.

You’ve probably also realized that the Statement of Applicability is not a static document. On the contrary, you and your security team should review and update the Statement of Applicability often, to reflect changes in your security posture, risk assessment, or control implementations. So, in that respect, the Statement of Applicability helps auditors understand your cybersecurity journey over time as much as it helps them understand what you planned to do from the start.

Crafting the ISO 27001 Statement of Applicability

A step by step road map for crafting the ISO 27001 SoA

Crafting your Statement of Applicability can be challenging. It has many components, and precision is important. You’ll need to proceed carefully through every step. 

First, consider involving an experienced ISO 27001 auditor or consultant to help you write the Statement of Applicability. They can provide guidance about what makes sense to include, what format to use, and otherwise offer guidance and assurance that your Statement of Applicability will meet the needs of your ISO 27001 project.

As early as possible, consult other important business functions in your enterprise such as IT, legal, compliance, marketing, and others as necessary. They can provide valuable insights about what your biggest information security risks truly are, and help determine which controls are necessary and practical given your operations.

Next will come an exercise in documentation. Remember what we said before about “references” within the Statement of Applicability, where the selected controls are tied back to relevant policies, records, and other information. You’ll need to identify that supporting evidence and keep it preserved in a single, secure database. Be sure that each selected control lists all its relevant evidence, and no more; now is not the time for your Statement of Applicability to be derailed by duplicative, outdated, or incorrect supporting materials.

The Statement of Applicability should also be reviewed and approved by senior management. You want to be sure that it accurately represents the company’s ambitions for ISO compliance and is endorsed by senior management so that other parts of the enterprise will understand the urgency of taking your ISO project seriously.

Then, as necessary, review and update the document. For example, you might replace obsolete policies with new ones; that should be captured in the supporting documentation. Or you might decide that upon further testing, it’s appropriate to drop some Annex A controls but add others. Any such changes should be incorporated into the Statement of Applicability on a timely basis.

Use the right tools

Icons representing the right tools to use for a SoA including a technology tool like Hyperproof

CISOs might look at all these demands and wonder: isn’t the Statement of Applicability more like a spreadsheet? Well, yes and no. 

Yes, the information that the Statement of Applicability needs to contain is best organized in a grid format, and that’s the structure a spreadsheet uses. You need to be meticulous in listing each Annex A control, its supporting references, its latest implementation status, and so forth. So, when viewing all that data at a glance, you’ll likely see something that looks like a spreadsheet. 

That said, spreadsheets are terribly risky as tools to compile your Statement of Applicability. You need to bring together information from across the enterprise, and that information might evolve. That means you need the fabled “single source of truth” to maintain version control. 

Ideally, you also want a technology tool with strong control-mapping capabilities, so you can track your controls and remediation more easily. You’ll also want a platform with automatic alerting and escalation capabilities since you’ll be dealing with so many people inside and outside your organization.

With the right tool, however, drafting your Statement of Applicability won’t be nearly as daunting as it seems. Then you can embark on your ISO 27001 project confidently with and ultimately succeed.

How to create an ISO 27001 Statement of Applicability in Hyperproof in 10 simple steps

Creating a Statement of Applicability in Hyperproof is simple and can help you get ahead. Here’s how to do it:

1. Set up the ISO 27001 program

ISO 27001 dashboard in Hyperproof

If you haven’t set up ISO 27001 as a program in Hyperproof already, here’s how to do it:

Navigate to the Programs menu option and select +New. Select ISO 27001 from the programs list. After you’ve created your new program, open it and go to the Requirements tab.

2. Inspect requirements in Tree View

ISO 27001 requirements view in Hyperproof

For an organized layout of Annex A controls, switch to Tree View in the upper-right corner.

Please note that Annex A controls serve as references for controls. You can adopt, tailor, or replace these controls based on your organization’s needs.

3. Tailor controls to your organization

ISO 27001 details view in Hyperproof

To tailor controls to your organization:

First, modify Annex A controls by adding in details like exemption policies, department responsibilities, or organizational documents. Then, replace Annex A controls with custom descriptions or controls from frameworks (like NIST 800-53 if preferred). Finally, ensure the controls are aligned across programs for consistency.

4. Create custom fields for your SoA

A screenshot of how to create custom fields in Hyperproof

Here’s how you can create custom fields for your SoA in Hyperproof:

  1. Go to Settings > Custom Fields.
  2. Select +New create the fields required for your SoA. 
  3. Assign them to requirements.
  4. Collaborate with your auditor to confirm which fields are necessary.

Examples of common fields include: 

  • Associated assets: Multi-line text or multiple-select field
  • Date of implementation: Date picker
  • Implementation details: Multi-line text or select options for approach (e.g., NIST 800-53)
  • Justification: Multiple-select or text (e.g., business, contracting, legal, risk).
  • Owner: User picker or open text field 

It’s important to note that Hyperproof’s Status field is generally used as the standard SoA In Place field.

5. Populate fields for each Annex A requirement

A screenshot of how to populate fields for each Annex A requirement in Hyperproof

To populate fields for each Annex A requirement, review each Annex A control and provide the following:

  • Status (In Progress, Complete, Not Started, Not Applicable)
  • Implementation details
    • Include customized approaches or references
  • Date of implementation and last assessment
  • Owner assignment and associated assets
  • Justification

Mark controls as Not Applicable where necessary, but be sure to add justification. For example, you could add “No facilities” for a clear desk rule. 

6. Build the SoA report 

A screenshot of how to build the SoA report in Hyperproof

To build your SoA report in Hyperproof, switch to Grid View in the upper-right corner. Then, filter by section to include only Annex A requirements.

7. Export the filtered view 

A screenshot of how to export the filtered view report from Hyperproof

Here are the steps to export a filtered view in Hyperproof: 

  1. If you have additional custom fields or fields you don’t want to include in the report, select the gear icon in the upper right then unselect any wanted fields.
  2. Select all requirements in the filtered view. 
  3. Select Export to download the initial report, which includes:
    1. IDs
    2. Sections
    3. Statuses
    4. Mapped controls
    5. Custom fields
An example of an exported filtered view from Hyperproof

8. Generate an additional export using Export Program  

A screenshot of how to export from the ISO 27001 requirements tab in Hyperproof

Additional exports can be generated using the Export Program via the ellipsis menu for justifications of non-applicable requirements. To do this, follow these steps:

  1. Go to the downloaded file. 
  2. Select requirements.csv for a list of requirements that include Not Applicable justifications. 
  3. Identify all the controls linked to your ISO 27001 requirements by selecting combined.csv for requirement and control information
  4. In requirements.csv, create a filter in the excel file. 
  5. Filter to those requirements with a status of Not Applicable. 
An example of the requirements.csv export

9. Combine reports (optional) 

This step is completely optional, however if justifications from the second report are needed in the primary report you can use Excel or another tool to merge the data.

10. Finalize the SoA

The final step in this process is finalizing the SoA. To start, check the report and ensure all fields are complete. Then, validate that the data in the report aligns with your auditor’s expectations. Finally, you need to  review the final report to confirm it includes all necessary information for Annex A compliance. 

Hyperproof optimizes your workflows to achieve ISO 27001 compliance

Hyperproof is the compliance operations software solution that helps organizations implement, monitor, and maintain an ISMS that conforms to the ISO 27001:2022 standard in the most effective way possible. With Hyperproof, Glance Networks was able to create a single source of truth for compliance and automated routine, and repetitive work, streamlining workflows, and reducing work for teams across the organization. Read the case study.

To see the Hyperproof platform in action, schedule a demo with our team today.

ISO 27001 SoA in Hyperproof: Frequently Asked Questions

Generally speaking, your auditor will define the type of information they expect to see in your SoA. ISO 27001 requires that your SoA compare your controls against Annex A (6.1.3.c) and include the following information (6.1.3.d):

  • The necessary controls (see 6.1.3 b and c)
  • Justification for their inclusion
  • Whether the necessary controls are implemented or not
  • Justification for excluding any of the Annex A controls

In Hyperproof, risks are considered distinct from requirements and are not included in the report. In ISO 27001, ISMS requirement 6.1 requires the organization to identify risks and a treatment plan, but identifying risks and selecting controls (6.1.2, 6.1.3.a, 6.1.3.b) is distinct from comparing the selected controls to Annex A  (6.1.3.c). 

While Annex A provides some insight into the type of Information Security risks that should be considered, the risk assessment and treatment plans can (and should) include risks and controls not implied by Annex A.

Some auditors expect the organization to specify a risk or set of risks for each Annex A sample control determined to be in scope. However, best practice is to have two separate documents:

  • Risk Treatment plan: A list of risks with mitigating controls that identifies and selects the required controls
  • Statement of Applicability (SoA): A list of applicable Annex A controls mapped to mitigating controls to compare your selected controls to Annex A 

If this is insufficient for your auditor, risks can be manually listed within a custom field in Hyperproof. However, it is not possible to “link” requirements to risks in Hyperproof since they are only related via Controls.

The Risk Treatment plan is another required artifact of the risk assessment process, as specified in the ISMS requirement 6.1.3.e. 

Hyperproof’s Risk Module is the primary tool for generating this report. Although the ISMS does not specify any specific fields that must be included, based on requirements 6.1.2, standard fields in the Risk Treatment plan include:

  • Links to supporting documentation
  • Risk identifier
  • Risk description
  • Impact
  • Impact description
  • Likelihood
  • Inherent risk
  • Residual risk
  • Prioritization
  • Risk owner
  • Risk treatment options
  • Proposed treatment options
  • Proposed treatment controls
  • Implementation responsibility
  • Resources required
  • Timeframe
  • Residual risk assessment
  • Approval and sign-off
  • Monitoring and review mechanisms

In Hyperproof, requirement status is defined as Not Started, In Progress, Completed, or Not ApplicableNot Started and Completed are equivalent to “Not In Place” and “In Place.”  ISO 27001 does not explicitly require the use of the term “In Place,” so generally, the Hyperproof status should be satisfactory

However, if you need to convert Hyperproof’s status field to “In Place” you can do so using Excel or Google Sheets.  To do this, create a column called “In Place” and use the formula =IF({cell}=”Completed”, “Yes”, “No”).

Hyperproof’s status In Progress is equivalent to NIST’s “Partially Implemented” or PCI DSS’s “Not Tested,” though these values are generally not included in the Statement of Applicability.

Per ISMS requirement 6.1.3.d, “Not Applicable” Annex A requirements must have a justification. The standard Hyperproof Export from the grid view omits Hyperproof’s “Not Applicable” justification.

To get the “Not Applicable” justification, a second report must be generated. Here are the steps to generate a second report:

  1. Select your ISO 27001 program.
  2. Select the ellipses (…) in the Program options.
  3. Select Export Program.
  4. Download the file.
  5. Select requirements.csv
  6. Filter to the Annex A requirements marked “Not Applicable.”

No, all programs’ custom fields assigned to programs and requirements are visible on all programs and requirements, not just ISO 27001. However, most other programs, including SOC 2 and PCI DSS, can benefit from the same processes and information included in an ISO 27001 assessment, though the reports take different formats.

Monthly Newsletter

Get the Latest on Compliance Operations.
Subscribe to Hyperproof Newsletter