The Statement of Applicability is explicitly required by ISO 27001:2022 Clause 6.1.3 and is one of the documents most thoroughly examined at Stage 1. It is the document that answers a fundamental question about every one of the 93 Annex A controls: does this control apply to our organization, and if so, is it implemented? The quality of the SoA — the specificity of its justifications, the honesty of its implementation statuses, and the coherence of its control decisions with the rest of the ISMS — tells auditors more about the maturity of an ISMS than almost any other single document.
Organizations approach the SoA in two fundamentally different ways. The first approach starts with Annex A and works toward the risk register — selecting controls because they appear standard, marking most as applicable because it seems safer, and populating justifications retrospectively. This approach produces an SoA that looks complete but cannot be defended under audit interrogation. The second approach starts with the risk register and works toward Annex A — each control is either applicable because it treats a specific identified risk or satisfies a specific regulatory obligation, or it is not applicable because the associated risk context does not exist in this organization. This approach produces an SoA that is specific, defensible, and coherent with every other ISMS component.
This article covers the complete SoA discipline: what the standard requires, the full column architecture with mandatory and optional elements, the seven applicability decision types with quality standards for each, worked SoA entries for five controls, the six trigger events that require SoA updates, and the pre-audit quality assurance checklist.
What ISO 27001 Requires: Four Mandatory Elements
Clause 6.1.3 is the most specific clause in ISO 27001 regarding a named documented artifact. It requires four explicit elements in the SoA — absence of any one of them is a nonconformity. Understanding each element precisely prevents the common mistake of producing an SoA that satisfies three of the four requirements and misses the fourth:
| Clause | Requirement | What it means | Most common error |
| 6.1.3(b) | Determine all necessary controls | Compare the controls resulting from the risk treatment process with those in Annex A to verify that no necessary controls have been omitted. The SoA is the output of this determination — it shows every control considered and the decision made for each. | SoA is populated from Annex A as a starting template without reference to the risk assessment. Controls are selected because they appear standard rather than because they treat identified risks. |
| 6.1.3(c) | Produce the SoA | Produce a Statement of Applicability containing: (a) all Annex A controls, (b) justification for inclusion or exclusion, (c) whether each control is implemented, and (d) justification for any excluded controls. All four elements are required — absence of any one is a nonconformity. | SoA lists controls and implementation status but lacks specific justification. Or: SoA excludes controls without explanation. Or: SoA does not include all 93 controls — typically misses new 2022 controls. |
| 6.1.3(d) | Implement the risk treatment plan | Implement the controls identified in the SoA as applicable. The SoA implementation status column must reflect the actual state of implementation — not the intended state. | SoA shows 'Implemented' for controls that Stage 2 evidence testing reveals are not deployed. Implementation status was optimistic rather than accurate. |
| 8.3 | Implement the IS risk treatment | Clause 8.3 requires the organization to implement the IS risk treatment plan. The SoA serves as evidence that the planned controls have been identified. Evidence of implementation is produced by executing the controls and retaining records. | The SoA exists as documentation but the controls it references have not been built into operational processes. The ISMS has a document of intent, not a document of implementation. |
| THE FOUR ELEMENTS TEST | Before submitting the SoA for Stage 1: verify all four mandatory elements are present. (1) All 93 controls are listed. (2) Each control has a justification — for applicable controls: why it applies; for excluded controls: why it does not apply. (3) Each applicable control has an implementation status. (4) Excluded controls have specific justification — not just 'N/A'. Run this test by selecting 5 controls at random: an applicable one, an excluded one, a new 2022 control, a high-risk area control, and any control at random. If any of the four elements is missing for any of these five, the SoA fails the basic completeness test before an auditor examines it. |
The SoA Column Architecture
ISO 27001 specifies what the SoA must contain but not how it must be formatted. The column architecture below represents the complete SoA — five mandatory columns that satisfy the standard's requirements and five optional columns that transform it from a compliance document into a management tool. The mandatory columns must be present before Stage 1; the optional columns add value progressively:
| Column | Mandatory? | Content and quality standard | What auditors look for | Example |
| Control reference | Required | The Annex A reference number — e.g. 5.1, 8.28. Must match the 2022 numbering exactly. Organizations transitioning from 2013 SoAs must renumber to the 2022 structure. | Auditors check that all 93 controls are present. Missing controls — particularly the 11 new 2022 controls — are immediate Stage 1 findings. | 8.28 |
| Control name | Required | The exact name from Annex A. Paraphrasing or renaming controls creates ambiguity and audit friction. Use the standard names. | Used for quick navigation during the audit. Auditors jump to controls by name — non-standard naming slows the process and signals unfamiliarity with the standard. | Secure coding |
| Control statement | Optional | The one-to-two sentence control statement from Annex A. Optional but adds clarity — particularly useful for organizations where non-ISMS staff read the SoA. | Not directly tested but demonstrates depth of engagement with the standard. Auditors appreciate SoAs that include the control statement — it signals the authors read the standard. | 'Secure coding principles shall be applied to software development.' |
| Applicable? (Yes/No) | Required | The binary applicability decision for each control. Must be populated for all 93 controls. 'Not decided' or blank entries are not acceptable — every control requires a decision. | Auditors scan the applicability column first. Blank entries or patterns of exclusion that appear convenience-driven (all controls for an entire sub-group excluded) trigger deeper scrutiny. | Yes |
| Justification for inclusion | Required | Why this control is applicable. Must reference specific risks from the risk register, regulatory obligations, or contractual requirements that drive the control's inclusion. 'Best practice' is not a justification — it is a tautology. | One of the most scrutinized columns. Auditors test whether the justification is genuine: 'You have justified A.8.5 with risk R-007 — show me R-007 in the risk register.' Generic justifications generate follow-up questions. | Treats risk R-007 (credential compromise of payment API — score 20/25 CRITICAL) and satisfies POJK 11/2022 Pasal 37 authentication requirements. |
| Justification for exclusion | If excluded | For controls marked Not Applicable: a specific, defensible reason why the control does not apply. Must address why the risk or context the control addresses is absent from the organization's environment. Reasons that are not defensible: 'Not applicable', 'Out of scope', 'Not relevant'. | Exclusion justifications receive the most scrutiny of any SoA column. A control excluded with weak justification when the organization clearly has the associated risk will generate a major nonconformity. | Not applicable — the organization has no software development activities in scope. All software is procured from vendors (addressed through supplier security controls 5.19–5.22). No in-house code is written. |
| Implementation status | Required | Current state of implementation: Implemented / Partial / Planned / Not started. Must reflect operational reality at the time of the audit, not aspiration. Update this column whenever implementation status changes. | Auditors test 'Implemented' entries directly. Evidence is requested and reviewed. An 'Implemented' status without supporting evidence is a nonconformity. 'Partial' with an honest explanation is far better than 'Implemented' that testing disproves. | Partial — SAST tool deployed in main CI/CD pipeline; 2 legacy repositories not yet integrated (planned Q2 2026, TRP-015) |
| Control owner | Optional | The role or team responsible for implementing and maintaining the control. Optional in the SoA but highly recommended — it makes the SoA a governance document, not just a compliance record. | Not directly required by the standard but auditors ask about ownership. A SoA with named owners demonstrates a managed ISMS. A SoA without ownership information signals that controls were catalogued, not governed. | Engineering Lead (SAST integration); ISMS Manager (policy and training) |
| Evidence reference | Optional | Pointer to the evidence that demonstrates implementation status. Particularly valuable for 'Implemented' controls — enables auditors to navigate directly to evidence without requesting it during the audit. | Not required by the standard but dramatically improves audit efficiency. Auditors who can follow evidence pointers directly save time and demonstrate a well-organized ISMS. Missing evidence references mean auditors must request evidence verbally — slower and more stressful. | ISMS Evidence Library: /Dev-Security/SAST-CI-Config-2026.pdf; /Dev-Security/Scan-Report-Q1-2026.xlsx |
| Regulatory mapping | Optional | Indonesian regulatory requirements addressed by this control — UU PDP article references, POJK clause numbers, BI regulation references, BSSN framework elements. Transforms the SoA from an ISO 27001 document into a multi-framework compliance reference. | Not an ISO 27001 requirement but highly valuable for Indonesian regulated organizations. OJK and BI examiners who receive an SoA with regulatory mapping can verify compliance alignment without a separate mapping document. | UU PDP Pasal 35 (technical measures); POJK 11/2022 Pasal 45 (secure development) |
| The most scrutinized column: Justification for exclusion receives more auditor attention than any other SoA column. A well-justified exclusion — specific, contextual, connected to the scope statement — satisfies the auditor. An exclusion justified as 'Not applicable' without explanation, particularly for a control that clearly applies to the organization's context, generates either a Stage 1 nonconformity or a pointed Stage 2 inquiry. The test: could the auditor independently verify the exclusion rationale by examining the scope statement, risk register, and context analysis? If yes, the justification is defensible. If no, rewrite it. |
The Seven Applicability Decision Types
Every control decision in the SoA falls into one of seven categories — three types of 'Applicable' and four types of 'Not Applicable'. Understanding the category precisely produces justifications at the right quality level. The decision framework below also shows when each type is legitimate and the quality standard for its justification:
| Applicability decision | When to use | Justification quality standard | Implementation status |
| Applicable — risk-driven | A risk in the risk register with score HIGH or above maps to this control as a treatment measure. | 'Applicable — treats risk R-012 (ransomware via phishing and lateral movement, inherent score 18/25 CRITICAL). Control reduces impact through network segmentation that limits lateral movement post-compromise.' | Implemented / Partial / Planned depending on deployment state. |
| Applicable — regulation-driven | An applicable Indonesian regulation (UU PDP, POJK, PBI, BSSN) requires implementation of this control regardless of the internal risk score. | 'Applicable — required by POJK 11/2022 Pasal 37 (authentication controls for financial institutions) independent of internal risk assessment. Also treats risk R-007 (credential compromise, score 20/25).' | Implemented / Partial / Planned — regulatory controls must be treated with the same priority as high-risk controls. |
| Applicable — contract-driven | A client contract, supplier agreement, or industry standard requires implementation of this control — e.g. a payment processing client that requires PCI DSS controls or a government client that requires specific access control configurations. | 'Applicable — required by customer contract with [enterprise client] whose security addendum mandates MFA for all accounts with access to their data. Also treats risk R-007.' | Implemented — contractual controls generally must be implemented before the contract is active. |
| Applicable — best practice (secondary) | The control represents established best practice for the organization's sector even when no specific risk or regulation requires it — used rarely and always as a secondary justification alongside a primary risk or regulatory driver. | 'Applicable — best practice for financial technology organizations operating in the Indonesian market (primary: also treats R-015, score 14/25).' Note: best practice alone is not sufficient — there must be a primary risk or regulatory driver. | Implemented / Partial / Planned. |
| Not applicable — no assets in scope | The control protects assets or addresses threats that do not exist within the organization's ISMS scope. Must be specific about what is absent. | 'Not applicable — the organization has no physical premises or owned servers; all information processing occurs in certified cloud facilities. Physical perimeter controls (7.1–7.3) are addressed through supplier security (5.22, 5.23) for the cloud provider.' | N/A — excluded controls require no implementation status. |
| Not applicable — no development activities | The control addresses a specific organizational activity (software development, manufacturing, physical operations) that the organization does not conduct within scope. | 'Not applicable — the organization purchases all software from external vendors. No in-house software development occurs within the ISMS scope. Vendor software security is addressed through supplier security controls 5.20 and 5.21.' | N/A. |
| Not applicable — risk below threshold | Used rarely and with extreme caution. The control addresses a risk that has been assessed and scored below the organization's risk treatment threshold. Must be supported by a documented risk assessment entry. | 'Not applicable — the risk of physical asset theft from secure off-site storage has been assessed at LOW (score 4/25, Likelihood 1 × Impact 4) given 24/7 guarded facility used. Cost of implementation exceeds residual risk value at this score.' | N/A — but this exclusion justification will be probed by auditors. The risk register must contain the assessment supporting this claim. |
| The most defensible exclusions reference what does exist rather than just what does not. 'Not applicable — no physical premises' is stronger when followed by 'physical security of processing facilities is addressed through supplier security (5.22, 5.23) applied to our cloud providers.' This demonstrates that the risk the excluded control addresses has been considered and is managed through a compensating control — not simply ignored. Auditors who see compensating control logic in exclusion justifications are satisfied; auditors who see exclusions without any reference to the underlying risk will probe deeper. |
Worked SoA Entries: Five Controls
The worked examples below demonstrate complete, audit-quality SoA entries for five controls — including three new 2022 controls (5.7, 5.23, 8.9) and one excluded control (7.1). Each entry shows the justification quality, implementation status detail, and evidence reference format that satisfies Stage 1 and Stage 2 auditors:
| 5.7 ★ · Threat intelligence | ||||||||
| ||||||||
| 5.23 ★ · Information security for use of cloud services | ||||||||
| ||||||||
| 7.1 · Physical security perimeters · NOT APPLICABLE | ||||||||
| ||||||||
| 8.9 ★ · Configuration management | ||||||||
| ||||||||
| 8.28 ★ · Secure coding | ||||||||
| ||||||||
| Partial status is not failure — it is honesty. The worked examples above show several controls in 'Partial' status with specific descriptions of what is missing and references to treatment plan items. This level of specificity — 'SAST deployed in main pipeline; 2 legacy repositories not yet integrated (TRP-011, target Q3 2026)' — demonstrates a managed implementation. Auditors who encounter 'Partial' with honest specifics form a better view of the ISMS than auditors who encounter 'Implemented' for a control that evidence testing reveals is only partially deployed. Partial + specific + treatment plan reference = acceptable. Implemented + no evidence = nonconformity. |
The SoA Lifecycle: When to Update
The SoA is a controlled document that must be maintained as a living record of the organization's control decisions. Six trigger events require SoA review and potential update. Organizations that update the SoA only before audits produce a document that reflects aspirational states rather than operational reality:
| Trigger event | What changed | Required SoA action | Timing | Evidence |
| Risk assessment completed or updated | New risks identified, risk scores recalculated, or existing risks removed from register. | Review all applicable controls — do new risks require controls not currently in the SoA? Have risk score changes moved risks above or below the treatment threshold, affecting control applicability? Update justifications for controls now linked to new risks. | Within 30 days of risk assessment update. | SoA version with updated date. Risk assessment records showing new/changed risks. Change log noting which control justifications were updated. |
| New control deployed | A control that was 'Planned' or 'Partial' has been fully implemented. | Update implementation status from Planned/Partial to Implemented. Add or update evidence reference. Recalculate residual risk score in the traceability matrix for affected risks. Brief risk owner that their risk posture has improved. | Within 7 days of confirmed deployment. | Updated SoA with new implementation status and date. Evidence reference pointing to implementation proof. |
| Significant organizational change | New service launched, cloud platform migration, acquisition, significant expansion of staff or geographic reach. | Reassess scope — does the change bring new assets, systems, or risks into scope? Review Annex A for controls whose applicability decisions change (e.g. a cloud migration makes 5.23 cloud services newly essential). Update justifications for affected controls. Notify CB if change is material. | Within 60 days of change confirmation. | Updated SoA reflecting scope and applicability changes. Change management record linking organizational change to SoA update. |
| New Indonesian regulation published | New POJK circular, KOMINFO regulation, BI payment system standard, or BSSN requirement with IS implications. | Map the new requirement to affected Annex A controls. Update regulatory mapping column for newly relevant controls. If new regulation requires a control currently marked Not Applicable — reconsider the exclusion justification. Update IS policy regulatory references. | Within 30 days of regulation publication date. | SoA version with updated regulatory mapping column. IS Policy update reflecting new regulation. Context analysis update. |
| Annual review (minimum) | Annual SoA review cycle regardless of other changes. | Verify all applicability decisions are still current. Verify all implementation statuses reflect current reality. Update all justifications that reference risk scores to reflect current risk register. Confirm all evidence references are still valid and accessible. | Annual — concurrent with annual risk assessment review. | Reviewed and re-approved SoA version. ISMS Manager and CEO sign-off on current version. |
| Pre-audit update (Stage 1 and Surveillance) | 4–6 weeks before Stage 1 document submission or surveillance audit date. | Conduct a full SoA consistency check — verify every control's status against actual deployment. Ensure all 93 controls are present (especially the 11 new 2022 controls). Verify exclusion justifications are specific and defensible. Confirm evidence references are accessible. Address any 'Implemented' statuses where evidence cannot be produced. | 4–6 weeks before audit. | Current SoA version submitted to CB. Evidence library confirmation that all 'Implemented' controls have accessible evidence. |
The SoA version history is itself an ISMS evidence artifact. A SoA that has remained unchanged for 18 months while the organization launched new services, migrated to new cloud infrastructure, and updated its risk register signals that the SoA is not being maintained as a living document. Auditors at surveillance will ask: 'The SoA has not been updated since your Stage 2 audit — does it still accurately reflect your current control environment?' The honest answer, for most organizations that do not maintain their SoA, is no.
SoA and the Indonesian Regulatory Context
Adding a regulatory mapping column
For Indonesian regulated organizations, one of the highest-value enhancements to the SoA is a regulatory mapping column showing which UU PDP articles, POJK clauses, PBI provisions, and BSSN framework elements each applicable control addresses. This column transforms the SoA from an ISO 27001 tool into a multi-framework compliance reference that can be submitted to OJK examiners, BI supervisors, and KOMINFO in response to regulatory inquiries.
The regulatory mapping column is built from the same source as the regulatory link column in the traceability matrix (Article 5.6). For organizations using a GRC platform like Bitlion, this mapping is pre-populated with Indonesian regulatory references aligned to each Annex A control, reducing the build time from days to hours.
Controls that satisfy UU PDP obligations
Several Annex A controls directly address UU PDP obligations — when these controls are implemented to ISO 27001 standards, the corresponding UU PDP articles are simultaneously addressed. The most direct mappings are:
- 5.34 (Privacy and PII) → UU PDP Articles 20–40 (data subject rights: access, correction, deletion, portability) and Articles 41–53 (processor obligations including DPA requirements)
- 5.12 (Classification) + 5.13 (Labelling) → UU PDP Article 67 (data minimization and classification of personal data by sensitivity level)
- 8.10 (Information deletion) → UU PDP Article 28 (right to erasure; data minimization — retain only what is necessary)
- 8.24 (Cryptography) → UU PDP Article 35 (appropriate technical measures including encryption for personal data in transit and at rest)
- 5.26 (Incident response) → UU PDP Article 46 (breach notification to KOMINFO within 14 calendar days of discovery)
- 8.11 (Data masking) → UU PDP obligations on personal data in non-production environments and data minimization principles
Organizations that implement these controls to ISO 27001 standards and record the UU PDP mapping in their SoA can demonstrate to KOMINFO inspectors that their information security management system directly addresses the technical and organizational measures required by UU PDP — without needing a separate compliance program.
Pre-Audit SoA Quality Assurance Checklist
Conduct this quality assurance check on the SoA at least 4 weeks before any Stage 1 or surveillance audit. Every unchecked item represents either a completeness gap that an auditor will find or a quality issue that will generate clarification questions:
| Completeness |
☐ All 93 Annex A controls are present — verified by counting and spot-checking the 11 new 2022 controls (5.7, 5.23, 5.30, 7.4, 8.9, 8.10, 8.11, 8.12, 8.16, 8.23, 8.28) ☐ Every control has an applicability decision — no blanks, no 'TBD', no 'Under review' ☐ Every applicable control has an implementation status — no blanks ☐ Every excluded control has a specific exclusion justification — no 'N/A' without explanation ☐ The SoA is version-controlled — version number, date, and approver on the document |
| Justification quality |
☐ Every inclusion justification references a specific risk ID from the risk register OR a specific regulation — not generic statements ☐ Risk IDs referenced in justifications exist in the current risk register ☐ Regulation references include specific article/clause numbers — not just regulation names ☐ No inclusion justified solely as 'best practice' without a risk or regulatory driver ☐ No exclusion justified as 'Not applicable' or 'Out of scope' without a specific reason ☐ Exclusions for controls that clearly apply to the organization's scope have defensible justifications |
| Implementation status accuracy |
☐ 'Implemented' status has accessible evidence — attempt to retrieve evidence for 5 randomly selected 'Implemented' controls ☐ 'Partial' statuses include a specific description of what is missing and a treatment plan reference ☐ 'Planned' statuses reference a specific treatment plan item with a target date and owner ☐ No 'Implemented' status for controls that Stage 2 testing would disprove ☐ Implementation status was reviewed within the last 90 days |
| Internal consistency |
☐ Every control appearing in the traceability matrix is marked Applicable in the SoA ☐ Controls in the SoA risk treatment plan are consistent with risk register treatment decisions ☐ Scope statement and SoA applicability decisions are consistent — controls for out-of-scope areas are excluded with scope-based justification ☐ Controls excluded due to 'no physical premises' are consistent with the scope statement ☐ The IS policy references the SoA as the control selection document |
| Governance |
☐ SoA is approved by the ISMS Manager and CEO (or equivalent top management) ☐ SoA is in the document register with the correct version and review date ☐ Version history shows previous SoA versions are retained for audit history ☐ SoA review date has not lapsed — reviewed within the last 12 months or since last significant change ☐ The SoA has been provided to the certification body as part of Stage 1 package |
| Bitlion SoA module: Bitlion's GRC platform maintains the SoA as a live, connected document — each control entry is linked to the risk register risks it treats, the traceability matrix rows it appears in, and the evidence records that demonstrate its implementation status. When a risk register entry changes, the SoA entries for affected controls are automatically flagged for review. When a control's implementation status changes, the SoA is updated automatically with the date and triggering change. The regulatory mapping column is pre-populated with UU PDP, POJK, PBI, and BSSN references. The SoA consistency check runs automatically before each audit milestone, flagging gaps 6 weeks before the audit date. |
The SoA as Organizational Commitment
The Statement of Applicability is ultimately an organizational commitment — a formal declaration by top management that certain security controls apply to this organization, are implemented to a stated degree, and are justified by specific risks and obligations. When it is built with rigor and honesty, it is one of the most credible governance artifacts an organization can produce. When it is built as a compliance exercise to satisfy a Stage 1 checklist, it becomes the document that exposes the gap between aspiration and reality most clearly.
The SoA quality audit that is most revealing is not the one conducted by an external auditor — it is the one an ISMS Manager conducts on their own SoA six months after its initial creation. Pull five randomly selected 'Implemented' controls from the SoA and attempt to retrieve the evidence that proves each one is implemented. If the evidence is accessible, current, and specific — the SoA is a living document. If the evidence cannot be found, is stale, or does not match what the SoA claims — the SoA has drifted from operational reality. That drift, left unaddressed, is what surveillance auditors find.