Statement of Applicability

The Statement of Applicability is the document an ISO 27001 audit is run against. It carries one line per Annex A control, per main form, and each line answers four questions:

1. Does this control apply to our scope?
2. Why — or why not?
3. How far has it been put in place?
4. Who answers for it, and what evidences it?

The Statement of Applicability is required by ISO 27001 clause 6.1.3 d). It is the artefact that turns a risk register into a certifiable management system: not a report of what you did, but a statement of what you decided applies to you.

The lines are generated, not written

A statement is not authored. It is opened — and reading it is what creates the lines.

Opening a main form's statement does two things:

• Creates lines for controls the catalogue has gained since last time.
• Refreshes the register's suggestion on lines that already exist.

Three consequences follow, and all three are deliberate:

• A new main form does not get 93 rows written out when it is created. The Annex A catalogue is editable and it will grow; writing the rows out at creation time would freeze a snapshot of it.
• There is no synchronisation job. Nothing runs on a schedule, so there is no scheduled task whose failure nobody would notice.
• You cannot add or delete a line by hand. There is no New button and no delete action.

note

Why hand-editing is refused: a line added by hand would print its control twice with two different answers. A line removed by hand would come back on the next open — and until then the document would be short of one answer without saying which. Neither failure announces itself in a document an auditor reads down.

What the open writes is confined to lines that did not exist and to the suggestion column. It never touches an answer somebody gave.

The line

• Control — the Annex A control, shown as its code over its title.
• Theme — organizational, people, physical or technological.
• Applicable — your answer. See below.
• Suggested applicable — what the register implies. See below.
• Inclusion justifications — why the control is in scope. Several may apply; each is its own row.
• Exclusion justification — why it is not, where it is not.
• Implementation status — not implemented, partially implemented, or implemented.
• Responsibles — who answers for the control.
• Documents — the evidence: procedures, policies, records.

Two columns for one question

Applicable is the organization's answer. Suggested applicable is what the risk register implies — true where at least one risk under this main form has selected the control as its treatment.

They are two columns rather than one so that:

• the suggestion can never overwrite a decision, and
• the line can say when the two disagree.

caution

A control that a risk has since chosen, still marked not applicable, is exactly the contradiction an audit asks about.

The disagreement is flagged on the line and the list can be filtered on it. "Show me the lines an auditor will ask about" is the question this screen exists to answer, and it is the first filter to use before a certification visit.

What the suggestion reads

The suggestion reads selected controls only, not existing ones.

A control already in place is not evidence that the standard's clause applies to this scope — it may be there for an unrelated reason. What implies applicability is a risk assessment having chosen it as a treatment.

Superseded revisions are excluded too: a control the previous round chose and this one dropped is no longer a reason.

Inclusion and exclusion justifications

ISO 27001 asks for a justification per control, and a control may be in scope for more than one reason — so each reason is a row rather than a flag on a single column:

Justification	Means
Risk assessment	A risk assessment named this control as its treatment.
Legal requirement	A law or regulation requires it.
Contractual requirement	A contract with a customer or supplier requires it.
Business requirement	The business itself requires it, absent any of the above.

Where a control is not applicable, the exclusion justification is a free-text sentence. This is the field auditors read most carefully — an exclusion with no stated reason is a finding, and an exclusion whose reason contradicts the register is a worse one.

Implementation status

Status	Means
Not implemented	Declared applicable, but nothing has been done yet.
Partially implemented	In place for part of the scope, or in place but incomplete.
Implemented	In place across the scope the main form covers.

This is what an auditor reads first, and it is stated by the organization, not derived from anything the system can see. That is the reason the statement is a record rather than a report: the system knows which controls risks have chosen, but only a person knows whether a control is actually working.

Related risks

Each line can be asked which risks are behind it. That list is derived on demand, never stored — it asks the register each time.

It brings back the justification each risk gave for choosing the control: the sentence that is printed under the line. That reason lives on the risk's own selected-control row, which is why it belongs to the risk rather than to the statement.

Screens

Two tiers, like the register: pick the main form, then read that form's statement. If you may view exactly one main form, the picker is skipped.

The columns are the ones an auditor reads down — the control, its theme, whether it applies with the conflict badge beside it, the implementation status, and the exclusion reason.

The line's own form has a plain Save, not a flow's actions. A statement line has no state machine: it is a standing answer that is amended when the answer changes.

note

This is the one screen in the module that saves in the ordinary way. Everywhere else, writes go through the flow's actions.

What the statement does to its neighbours

Two deletions become refusals once a statement exists:

You cannot delete	While
A main form	It has a statement.
An Annex A control	Any statement answers for it.

Both matter because the lines are generated. Nobody would think of a statement as something to clear first — so the refusal comes from the guard, with a sentence, rather than from a database error.

Working with the statement

1. Open Information Security Risk Management → Statement of Applicability and pick the main form.
2. Filter on the suggestion conflict first. Those are the lines an auditor will question.
3. Work down the lines that are applicable with not implemented status — that is your implementation backlog, in the standard's own order.
4. Check that every exclusion has a reason you would defend out loud.
5. Name responsibles and attach documents as controls come into place.

tip

Open the statement early, before the register is complete. Its 93 lines are the most useful implementation checklist the module produces — and the suggestion column will fill itself in as risks are assessed, so the document gets more accurate the more of the register is done.