What you need to know about the SoA
Your Statement of Applicability (SoA) is a key part of documenting your ISMS. A SoA contains a list of security measures that an organization either opts in or out of when working with information security.
When does it make sense to opt out of controls?
You can opt out of controls if they aren’t relevant to your operations or services. It's important that you document a decision for each opt-out.
Note: Some controls will almost always be relevant, such as "access rights" and "Information backup", while others will depend on your organization and its services/products.
How you get started
- If you haven't already enabled a framework, you can do so under Maintain & Control > Controls.
- To opt out of a control and start your SoA, choose Archive as Non-Applicable from the chosen control
Tip:
If you use NIS2 or DORA frameworks, the controls are minimum requirements and should therefore generally not be archived. However, it makes sense to opt out of controls that are clearly not relevant for your business. For example, secure programming can be removed as a control if you don't do programming.
Make your SoA
Below you will find several ISO 27001 and ISAE 3402 controls that in practice can often be considered irrelevant depending on your organization's context.
The list is not exhaustive but gives an overview of the controls that can typically be deselected in the SoA when they have no impact on the organization's information security.
Note: Each opt-out should always be based on a concrete assessment and documented with a clear justification.
| Control ID | Title | Typical reason to opt-out |
|---|---|---|
| 5.32 |
Independent information security assessment |
If the organization has not decided to have an external/independent information security assessment |
| 7.9 |
Securing cables |
If the organization has no responsibility for physical network infrastructure |
| 8.4 |
Access to source code
|
If there is no internal code base or access to source code |
| 8.9 |
Managing configurations |
If you don’t configure systems yourself but use standard SaaS solutions |
| 8.24 |
Use of cryptography* |
If all encryption is fully managed by vendors without you implementing it yourself |
| 8.25 |
Secure development lifecycle
|
If the organization does not develop software or systems internally |
| 8.26 |
Application security requirements
|
If no software/applications are developed, customized or configured |
| 8.27 |
Secure system architecture and development principles |
If the organization does not develop its own information systems and is not responsible for customization or system design. |
| 8.28 |
Secure programming |
If no code is written within the organization (e.g. no internal software development) |
*Be aware that some Data Protection Agencies (for instance the Danish DPA) requires encryption of emails containing sensitive or other confidential personal data.