👥 Roles and permissions

The following roles can create a Statement of Applicability in Hyperproof:

Administrators
Compliance managers

The steps below explain how to create an ISO 27001 Statement of Applicability (SOA) in Hyperproof.

Step One: Create your ISO 27001 program

Skip this step if you already have an ISO 27001 in Hyperproof.

From the left menu, select Programs.
Click New.
The Select template window opens.
Search for ISO 27001, then select it.
The Review template window opens.
Click Next.
The Create program window opens.
Enter a name for your program and, optionally, a description.
Select the checkbox labeled I confirm that my organization has a license to this content.
Click Create.

Step Two: Create custom fields

Custom fields allow you to track anything you want on most Hyperproof objects. The custom fields you create here are linked to your program's requirements. They'll help you keep track of important information, such as implementation details and justifications. They are also visible on SOA reports.

📝 Note

Only Hyperproof administrators can create custom fields.

From the left menu, select Settings.
Select Custom fields.
Click New.
Collaborate with your auditor to determine the necessary fields. Common fields include:

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

Once the fields are determined, be sure to assign them to Requirements.

📝 Note

For more information on creating custom fields, refer to Creating a custom field.

Step Three: Modify Annex A controls

From the left menu, select Programs.
Select your program.
Select the Requirements tab.
Click the Tree view icon.
Modify Annex A controls by adding details such as exemption policies, department responsibilities, or organizational documents.

💡 Tip
Annex A controls serve as references for controls. Based on organizational needs, you can adopt, tailor, or replace them.
Optionally, replace Annex A controls with custom descriptions or controls from frameworks like NIST 800-53.
For consistency, ensure alignment of controls across all of your programs.
Review each Annex A control and provide the following:
- Status (In progress, Completed, Not started, Not applicable)
  See Changing the status of a requirement for more information.
- Implementation details (include customized approaches or references)
- Date of implementation and last assessment
- Owner assignment and associated assets
- Justification
Where necessary, mark controls as "Not applicable" and add the justification, e.g. "No facilities for a clear desk rule".

Step Four: Create reports

You will need to create two reports. The first is the primary SOA report and the second includes the justifications of non-applicable requirements.

To create the first report:

Select the Requirements tab.
Click the Grid view icon.
Click the Filter icon.Filter by section to include only Annex A requirements.
From the Sections drop-down menu, scroll to the bottom, then select Annex A.
Select the All checkbox in the upper-left corner.

💡 Tip
If you have additional custom fields you don’t want included in the report, select the Gear icon in the upper-right corner, then clear the checkbox next to any unwanted fields.
Click Export.

This initial report includes IDs, sections, statuses, mapped controls, and custom fields.:

To create the second report:

Select the ... (More options) tab, then click Export program.

In the downloaded file, you'll find:
- Requirements.csv - This is a list of requirements that includes non-applicable justifications. Note that you’ll need to create a filter in the XLSX file and filter the requirements based on a "Not applicable" status.
- Combined.csv - This file contains requirement and control information that can be used to discover all of the controls linked to your ISO 27001 requirements.

💡 Tip

Optionally, you can combine the two reports.

If justifications from the second export are needed in the primary report, use Excel or another tool to merge the data.

Step Five: Finalize and review

Finalize the SOA by ensuring all fields are complete, and validate the data aligns with the expectations of your auditor. Review the final report to confirm it includes all necessary information for Annex A compliance.

FAQs

What fields MUST be included in the SOA?

Answer

sidebar. Answer

Generally, your auditor defines the type of information they expect to see in your SOA. ISO 27001 requires that the SOA compares your controls against Annex A (6.1.3.c), and includes 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
The justification for excluding any of the Annex A requirements

How do I include risks in the SOA?

Answer

sidebar. Answer

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. The Risk Treatment Plan identifies and selects required controls and the SOA compares those selected controls to Annex A.
- Statement of Applicability - A list of applicable Annex A controls mapped to mitigating controls.
If this is insufficient for your auditor, risks can be manually listed in a custom field. However, it is not possible to link requirements to risks in Hyperproof since they are only related via controls.

What is a Risk Treatment Plan?

Answer

sidebar. Answer

A Risk Treatment Plan is another required artifact of the risk assessment process, as specified in the ISMS requirement 6.1.3.e. In Hyperproof, the Risk Register 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:

Risk Identifier	Proposed Treatment Options
Risk Description	Proposed Treatment Controls
Impact	Implementation Responsibility
Impact Description	Resources Required
Likelihood	Time-frame
Inherent Risk	Residual Risk Assessment
Residual Risk	Approval and Sign-off
Prioritization	Monitoring and Review Mechanisms
Risk Owner	Links to Supporting Documentation
Risk Treatment Options

The Risk Treatment Plan example above doesn't include the field "In Place". Should I add this?

Answer

sidebar. Answer

Hyperproof recognizes the following requirement statuses: Not started, In progress, Completed, and Not applicable. The fields "Not started" and "Completed" are equivalent to "Not In Place" and "In Place".

ISO 27001 does not explicitly require the use of the field "In Place".
To convert the Hyperproof status field to "In Place" using Excel or Google Sheets, create a column titled "In Place" and use the formula =IF({cell}=”Completed”, “Yes”, “No”)
The "In progress" status in Hyperproof 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.

I don't see my justifications for "Not applicable" requirements in the report. Where can I find this?

Answer

sidebar. Answer

Per ISMS requirement 6.1.3.d, "Not applicable" Annex A requirements must have a justification. The standard Hyperproof export via the grid view omits the "Not applicable" justification. To get the "Not applicable" justification, a second report must be generated by:

Open your ISO 27001 program.
Select the ... (More options) tab, then click Export program.
Open the downloaded file.
Open the Requirements.csv file.
Filter to the Annex A requirements marked "Not applicable".

When I view other programs, like SOC 2 or PCI DSS, I see the custom fields I created for ISO 27001. Is there a way to hide these?

Answer

sidebar. Answer

No. All custom fields assigned to a program and its 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.