{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/statement-of-applicability","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/statement-of-applicability/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/statement-of-applicability/"},"term":{"en":"Statement of Applicability (SoA)","da":"Statement of Applicability (SoA)"},"aka":{"en":["SoA"],"da":["SoA","anvendelseserklæring"]},"domain":["security"],"cluster":"compliance","layer":"governance","status":"current","era":2005,"summary":{"en":"A document listing every control in the ISO 27001 annex, saying whether each is used, and giving the reason.","da":"Et dokument, der gennemgår hver kontrol i ISO 27001's anneks og angiver, om den anvendes, og hvorfor."},"body":{"formal":{"en":"The document required by ISO 27001 clause 6.1.3(d) that lists the controls needed to treat the assessed risks and, for each Annex A control, states whether it is included or excluded, why, and whether it is in place.","da":"Det dokument, som ISO 27001 punkt 6.1.3(d) kræver, og som angiver de kontroller, der er nødvendige for at håndtere de vurderede risici, og for hver kontrol i anneks A oplyser, om den er med eller udeladt, hvorfor, og om den er gennemført."},"plain":{"en":"Like a builder answering the fire officer's checklist item by item - installed, or not needed and why, such as “no sprinklers - one floor only, with two exits”.","da":"Som en bygherre, der besvarer brandmyndighedens tjekliste punkt for punkt - installeret, eller ikke nødvendigt og hvorfor, fx “ingen sprinklere - kun ét plan og to udgange”."},"inPractice":{"en":"A small Danish software company with no office of its own marks the control on securing office premises as not relevant, since all its servers sit with a hosting supplier holding ISO 27001 certification; the auditor reads the reason and accepts it.","da":"En lille dansk softwarevirksomhed uden eget kontor markerer kontrollen for sikring af kontorlokaler som ikke relevant, fordi alle dens servere står hos en hostingleverandør med ISO 27001-certificering; auditoren læser grunden og godtager den."},"whyItMatters":{"en":"Without it, a control can quietly be dropped with no one noticing; the statement ties every risk decision to a control in one place, so gaps and weak excuses are easy to spot.","da":"Uden den kan en kontrol stille og roligt blive droppet, uden at nogen opdager det; erklæringen knytter hver risikobeslutning til en kontrol ét sted, så huller og svage undskyldninger er lette at få øje på."}},"deepDive":{"en":"The SoA is the output of a specific sequence in ISO/IEC 27001:2022 clause 6.1.3. The organisation selects risk treatment options (a), determines all controls necessary to implement them from whatever source it chooses (b), compares those controls with Annex A to verify that no necessary control has been omitted (c), and then produces the SoA (d), which must contain the necessary controls, the justification for including them, whether they are implemented or not, and the justification for excluding any Annex A control. The treatment plan (e) and the risk owners' approval of it and acceptance of residual risks (f) follow. The SoA is therefore not a checklist filled in from Annex A downwards but a reconciliation between the risk register and the catalogue.\n\nJustifications for inclusion are usually one of three kinds: a treated risk (referenced by risk ID), a legal or regulatory requirement (for example NIS2 Article 21(2) or GDPR Article 32), or a contractual or business requirement. A good SoA keeps these traceable in both directions: from each risk to the controls that treat it, and from each control to the risks, laws or contracts that justify it. Controls from outside Annex A, such as specific CIS safeguards or sector requirements, belong in the SoA as well, because clause 6.1.3(d) speaks of the necessary controls, not only Annex A.\n\nExclusions are where auditors probe. \"Not applicable\" is acceptable only if no risk, legal requirement or contract calls for the control within the scope; excluding secure development (8.25-8.28) while the organisation writes code, or physical controls while it still has staff in an office, will be challenged. Implementation status should be honest: a control can be included but only partially implemented, with the gap tracked in the treatment plan. The 2022 transition forced every certified organisation to rebuild its SoA from 114 to 93 controls, typically using ISO/IEC 27002 Annex B to map old controls to new.\n\nPractically, the SoA is a controlled, versioned document; certification bodies commonly reference its version on the certificate, so a material change in the SoA can affect what the certificate covers. Many organisations maintain it as a spreadsheet or in a GRC tool with columns for control, applicability, justification, status, owner, evidence location and linked risks, and use ISO/IEC 27002 attributes to produce filtered views. It is also the document customers most often request, sometimes under NDA, when assessing a certified supplier.","da":"SoA'en er resultatet af en bestemt rækkefølge i ISO/IEC 27001:2022 afsnit 6.1.3. Organisationen vælger muligheder for risikohåndtering (a), fastlægger alle de kontroller, der er nødvendige for at gennemføre dem, fra en hvilken som helst kilde (b), sammenholder kontrollerne med anneks A for at sikre, at ingen nødvendig kontrol er udeladt (c), og udarbejder derefter SoA'en (d), som skal indeholde de nødvendige kontroller, begrundelsen for at medtage dem, om de er implementeret eller ej, og begrundelsen for at udelade en kontrol fra anneks A. Risikohåndteringsplanen (e) og risikoejernes godkendelse af den og accept af de resterende risici (f) følger efter. SoA'en er altså ikke en tjekliste, der udfyldes fra anneks A og nedad, men en afstemning mellem risikoregistret og kataloget.\n\nBegrundelser for at medtage en kontrol er som regel af tre slags: en håndteret risiko (med henvisning til risikoens id), et lovkrav (fx NIS2 artikel 21, stk. 2, eller GDPR artikel 32) eller et kontraktligt eller forretningsmæssigt krav. En god SoA bevarer sporbarheden i begge retninger: fra hver risiko til de kontroller, der håndterer den, og fra hver kontrol til de risici, love eller kontrakter, der begrunder den. Kontroller uden for anneks A, fx bestemte CIS-safeguards eller sektorkrav, hører også hjemme i SoA'en, fordi afsnit 6.1.3(d) taler om de nødvendige kontroller og ikke kun om anneks A.\n\nDet er fravalgene, auditorerne går efter. \"Ikke relevant\" holder kun, hvis ingen risiko, lovkrav eller kontrakt kræver kontrollen inden for omfanget; at fravælge sikker udvikling (8.25-8.28), mens organisationen skriver kode, eller fysiske kontroller, mens der stadig sidder medarbejdere på et kontor, vil blive udfordret. Implementeringsstatus skal være ærlig: en kontrol kan være medtaget, men kun delvist gennemført, med hullet fulgt op i risikohåndteringsplanen. Overgangen til 2022-udgaven tvang alle certificerede organisationer til at bygge deres SoA om fra 114 til 93 kontroller, typisk med ISO/IEC 27002 anneks B som nøgle mellem gamle og nye kontroller.\n\nI praksis er SoA'en et styret, versioneret dokument; certificeringsorganer henviser ofte til dens version på certifikatet, så en væsentlig ændring i SoA'en kan påvirke, hvad certifikatet dækker. Mange organisationer vedligeholder den i et regneark eller et GRC-værktøj med kolonner for kontrol, anvendelighed, begrundelse, status, ejer, placering af dokumentation og tilknyttede risici og bruger attributterne fra ISO/IEC 27002 til at lave filtrerede visninger. Det er også det dokument, kunder oftest beder om, nogle gange under fortrolighedsaftale, når de vurderer en certificeret leverandør."},"edges":[{"type":"requires","to":"security/risk-treatment","confidence":"high","strength":"normal"},{"type":"requires","to":"security/annex-a","confidence":"high","strength":"normal"},{"type":"part-of","to":"security/iso-27001","confidence":"high","strength":"normal"}],"depth":6,"sources":[{"title":"ISO/IEC 27001:2022 - Information security management systems - Requirements, clause 6.1.3(d)","tier":"standard","publisher":"ISO/IEC"}],"draft":true}