Purpose | Guide the ISMS owner through correctly marking infrastructure-related controls Not Applicable in the Statement of Applicability (SoA), and updating this in the ComplyJet platform. |
Applies to | Organizations that do not own, build, or operate any IT infrastructure, network, or production systems (service-only / no cloud infrastructure). |
Audience | ISMS Manager / Information Security Lead, and anyone preparing or updating the SoA. |
Owner | ISMS Manager / Information Security Lead |
Approved by | Chief Executive Officer (CEO), or designated Management Representative |
Review cycle | Annually, or upon significant change to the technology or service model |
1. Purpose
This SOP explains when and how to mark ISO/IEC 27001:2022 Annex A Technological controls (Annex A 8) that relate to infrastructure, networks, and software development as Not Applicable in the Statement of Applicability (SoA), and how to record that change on the ComplyJet platform.
2. When This Applies
Use this SOP when the organization does not own, build, or operate any cloud or on-premises infrastructure, network, or production systems, and does not develop software — e.g. a services/consulting business that delivers its work entirely through third-party SaaS tools. If the organization hosts any system, operates any network, or writes any code, do not use this SOP without reassessing which controls genuinely apply.
3. Controls to Mark Out of Scope
Mark the following Technological controls (Annex A 8) as Not Applicable, because there is no organization-owned or operated infrastructure, network, or development activity for them to govern:
Ref | Control | Why it is Not Applicable |
8.6 | Capacity management | No owned infrastructure/systems whose capacity needs monitoring. |
8.9 | Configuration management | No systems or servers to configure or harden. |
8.14 | Redundancy of information processing facilities | No processing facilities exist to make redundant. |
8.16 | Monitoring activities | No systems/network to monitor for anomalous behaviour. |
8.17 | Clock synchronization | No systems generating logs that need synchronized clocks. |
8.18 | Use of privileged utility programs | No systems with utility programs to restrict. |
8.19 | Installation of software on operational systems | No operational systems onto which software is installed. |
8.20 | Networks security | No organization-operated network to secure. |
8.21 | Security of network services | No network services are provided or operated. |
8.22 | Segregation of networks | No network environment to segregate. |
8.27 | Secure system architecture and engineering principles | No systems are architected or engineered by the organization. |
8.28 | Secure coding | No software is developed in-house. |
8.29 | Security testing in development and acceptance | No development activity to test. |
8.31 | Separation of development, test and production environments | No such environments exist. |
8.34 | Protection of information systems during audit testing | No information systems exist to protect during audit/testing. |
Do not extend this to endpoint, identity, and data-handling controls — these remain Applicable because staff still use devices and handle business data even without owned infrastructure:
Ref | Control | Why it usually stays Applicable |
8.1 | User endpoint devices | Staff still use laptops/phones to deliver the service. |
8.2 / 8.3 | Privileged access rights / Information access restriction | Staff still hold accounts and access to SaaS tools and business data. |
8.5 | Secure authentication | Login/MFA to email, SaaS, and business systems still applies. |
8.7 / 8.8 | Malware protection / Vulnerability management | Endpoint devices still need protecting and patching. |
8.10 – 8.13 | Information deletion, data masking, DLP, backup | Business data still exists and is still processed, stored, and needs protecting. |
8.24 | Use of cryptography | Data in transit/at rest on endpoints and SaaS tools still needs encrypting. |
8.32 | Change management | Still applies to any change affecting information or access, even without owned infrastructure. |
How to Mark a Control Out of Scope on the ComplyJet Platform
Marking a control out of scope is done by unmapping it from the ISO 27001 requirement it belongs to, not by editing a status field on the requirement itself. Once you know which requirements to exclude (Section above), update each one as follows:
STEP 1 Go to Compliance → Frameworks
In the left-hand navigation, under Prove, open Compliance, then Frameworks.
STEP 2 Select ISO 27001
Click into the ISO 27001 framework card. This opens the framework's Requirements tab by default.
STEP 3 Locate the requirement
On the Requirements tab, scroll to (or search for) the specific Annex A requirement — for example 8.20 (Networks security).
STEP 4 Open Map Controls
Click Map Controls on that requirement. This opens the “Map Controls to Section” panel, listing every internal control currently checked/mapped to it (e.g. GOV-105, IAC-197).
STEP 5 Unselect the mapped controls
Uncheck every control that is currently linked to that requirement, so none remain selected.
STEP 6 Save with Remap Controls
Click Remap Controls to save. With no controls mapped, the requirement no longer counts toward the framework's Controls Readiness, reflecting that it is out of scope.
STEP 7 Repeat for each requirement
Repeat Steps 3–6 for every requirement listed in the table above.
STEP 8 Record the justification in the SoA
Unmapping controls in Compliance → Frameworks does not itself capture a written reason. Separately update the Statement of Applicability record for that control (Applicable = No, Implementation Status = Not applicable, Justification = reason — see wording below) so the SoA stays consistent with what is mapped on the platform.
STEP 9 Review before audit
Confirm the framework's Controls Readiness and the finished SoA agree, then route the SoA for CEO/ISMS Manager approval.
Justification Wording to Use
“The organization does not own, operate, or host any IT infrastructure, network, or production systems, and does not develop software. Infrastructure- and development-related controls are therefore not applicable to the ISMS scope.” |
Adjust the wording to the specific control — e.g. for 8.28 (Secure coding): “No software is developed in-house; the organization does not write or maintain application code.”
Common Pitfalls
Marking all of Annex A 8 Not Applicable instead of assessing each control — endpoint, identity, and data controls (8.1–8.13, 8.24, 8.32) almost always still apply.
Leaving the justification generic (“N/A”) instead of explaining why the control does not apply.
Forgetting to revisit this SoA section if the organization later adopts cloud infrastructure or begins developing software.
Review, Approval and Maintenance
Changes to the SoA must be reviewed and approved by the document owner (typically the CEO or ISMS Manager) before being relied on as an audit record, and revisited whenever the organization's technology or service model changes.