To the ones who justify "not applicable" instead of ticking it
Quiet work, part 4: two days before the audit, an information security officer goes through the statement of applicability and finds "n/a" eleven times without a single sentence behind it. Instead of leaving the cells as they are, she writes down why for each one. Why these sentences are worth more than the ticks next to them and where BSI Standard 200-2 calls for them.
Two days before the audit. The statement of applicability is a table with all controls from Annex A of ISO 27001, and in the "applicable" column it says "n/a" eleven times. Next to it, in the column for the justification: nothing. The table dates from the initial certification; the colleague who filled it in back then has left the organisation.
You could leave the cells as they are. The auditor did not raise them last time either. Instead, someone takes on the eleven rows, asks around, checks, and writes one sentence for each: what does not apply, why not, and since when. For nine rows that is quick. For two, it turns out that "not applicable" is no longer true.
What the justification prevents
An "n/a" without a justification is a decision nobody can check any more. Maybe it was right when it was made. But environments change: a service that did not exist is introduced; a task that was outsourced comes back in-house. The tick stays. And sometimes it was never a finding but a shortcut: the requirement was inconvenient, so it was not applicable. Then the tick has silently become a risk acceptance that nobody signed.
Where it is required
ISO 27001 requires in clause 6.1.3 d, in substance, that the statement of applicability not only lists the necessary controls but also justifies why controls from Annex A were excluded. The text of the standard is protected by copyright, so it is paraphrased here.
In IT-Grundschutz the status is called "entbehrlich" (dispensable), and BSI Standard 200-2 is clear at this point. On documenting the IT-Grundschutz check, chapter 8.4.3 says that for requirements whose implementation appears dispensable, the justification must be given in this field. In German:
„Bei Anforderungen, deren Umsetzung entbehrlich erscheint, ist hier die Begründung zu nennen.“
And why the field exists at all: it is important so that decisions taken can be traced later. In chapter 8.4.2, the standard also draws a line that applies to every shortcut: for basic requirements, the resulting risk cannot be accepted.
Why it is invisible
An empty justification column looks finished. Nobody reads it until someone asks, and by then the person who knew has usually gone. Whoever writes the sentences produces no visible progress: the number of implemented controls stays the same, and the report looks exactly as it did before. At best even worse, because two rows have changed from "not applicable" to "open".
Those two rows are exactly why it was worth it.
To them
To the ones who want to know why for every "not applicable". Who add a date and a condition under which the answer no longer holds. And who would rather set a row to "open" than leave a tick they cannot explain.
Sources
BSI Standard 200-2, IT-Grundschutz methodology (German), chapters 8.4.2 and 8.4.3. ISO/IEC 27001:2022, clause 6.1.3 d and Annex A, paraphrased (text of the standard protected by copyright).
In the next part: to the ones who maintain the record of processing activities when nobody asks. The previous part: To the ones who say "we do not know" in the crisis exercise.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.