ISO 27001 Lists 93 Controls. Your Risk Assessment Decides Which Ones You Need.

Quick Answer: ISO 27001 does not ask you to implement all 93 Annex A controls. It asks you to run a risk assessment, decide how to treat the risks you found, choose the controls that treat them, compare your choice against Annex A so nothing necessary is overlooked, and record the reasoning in a Statement of Applicability (SoA). Every control you include needs a reason, and so does every control you exclude.

Many teams open ISO 27001 at Annex A. It is the concrete part: 93 controls with names like "Information backup" and "Secure coding", which look like a to-do list. So the project starts there, and people begin working through the list from the top.

The standard is built the other way round. Annex A is a reference list. The requirement is in Clause 6.1: assess your information security risks, decide how to treat them, and only then determine which controls you need.

Start from the controls and you tend to end up with a Statement of Applicability you cannot defend. Start from the risks and every control has a reason behind it.

No. ISO 27001 requires you to consider all 93 Annex A controls and to justify what you include and what you leave out.

Clause 6.1.3 sets out the sequence. You select risk treatment options, determine the controls needed to implement them, and then compare those controls with Annex A to verify that no necessary control has been omitted. Annex A is a completeness check on your own thinking.

This cuts both ways. A company with no physical office and fully remote staff may be able to exclude some physical controls, as long as it says why. A company that develops software cannot exclude secure development controls just because they are inconvenient. And nothing stops you from adding controls that are not in Annex A at all, if a risk calls for one.

ISO 27001 Clause 6.1.2 requires a defined, repeatable risk assessment process. It does not prescribe a method, a matrix or a tool. What it does require is specific:

Many organizations use ISO/IEC 27005 as their method. It is guidance, not a requirement, and it gives a structure for exactly these steps. A qualitative scale, such as a five-by-five grid of likelihood against impact, is a common and accepted way to score.

One point surprises teams that learned the older approach. The standard does not require you to start from an asset list. An asset-based assessment is a perfectly valid method, and often the most practical one, but a scenario-based method is equally acceptable. What matters is that you defined the method and followed it.

The risk assessment, the risk treatment plan and the Statement of Applicability are three views of one chain of decisions, and an auditor will follow that chain from end to end.

The risk assessment says what could go wrong, how badly and how likely, and which risks exceed your acceptance level.

The risk treatment plan says what you will do about each of those risks. The usual options are to reduce the risk with controls, accept it, avoid it by stopping the activity, or transfer part of it, for example through insurance or a contract. A workable plan also names an owner and a timeframe for each action.

The Statement of Applicability lists the controls you determined are necessary, states whether each is implemented, and gives the justification for including it. It also justifies the exclusion of any Annex A control you left out.

The link the standard insists on is approval. Clause 6.1.3 requires that risk owners approve the treatment plan and accept the residual risks. A risk register that nobody outside the security team has signed off on does not meet that requirement, however thorough it is.

Here is one risk followed through the whole chain. The company and the numbers are invented for illustration, and the scoring scale is the company's own choice.

A 40-person SaaS company scores risks on a five-by-five grid and has decided that anything scoring 8 or below can be accepted without treatment.

The same company excludes 8.30 Outsourced development, with the justification that all development is done by employees. That is a specific reason an auditor can test, which is what an exclusion needs.

Follow any line of the Statement of Applicability backwards and you should arrive at a risk, a legal requirement or a contract. That is the test an auditor applies.

Auditors check whether the chain from risk to control holds together. The documents themselves are easy to produce. What gets tested is whether one follows from the other.

In practice that means questions like these:

The common weak points follow from that. Justifications that say "not applicable" with no reason. Every risk scored medium, which suggests the criteria were not really applied. Controls marked as implemented with no evidence. And a risk list that is plainly a renamed copy of Annex A, with one "risk" per control.

That last one is the clearest sign that the process ran backwards.

ISO 27001 Clause 8.2 requires risk assessments at planned intervals, or when significant changes are proposed or occur. The standard does not define either term, so you set the interval yourself and then have to keep to it. Once a year is the common choice.

The second trigger is the one that gets missed. The standard leaves "significant" to your judgment, which means you should decide in advance what counts. Reasonable candidates include a new product or market, a move to a different cloud provider, an acquisition, a new critical supplier, a serious incident, or a change in how staff work with company data.

The wording also matters: "proposed or occur". The assessment is meant to inform the decision, so it belongs before the change, with the result kept as a record.

A risk register dated before the last major change in the business is one of the easier findings for an auditor to raise, because it only takes comparing two dates.

Largely, yes. One risk assessment can serve ISO 27001, NIS2, SOC 2 and DORA if it is designed with that in mind. All of them ask for a documented, repeatable way of identifying and treating risk, and the underlying work is the same.

NIS2 Article 21 lists "policies on risk analysis and information system security" as the first of its required measures. SOC 2 includes risk assessment in its common criteria. DORA requires financial entities to maintain an ICT risk management framework.

What differs is the scope, the vocabulary and the output each one expects. The Statement of Applicability is specific to ISO 27001. NIS2 expects the measures to be approved by the management body, and whether NIS2 applies to your company at all is a separate question to settle first. So one assessment can feed several frameworks, but the scope has to be drawn wide enough at the start and the results mapped to each set of requirements.

The right order for ISO 27001 risk work is the one the standard itself implies, nine steps from scope to reassessment:

Done in this order, the Statement of Applicability writes itself from the decisions before it. Done in the reverse order, it has to be argued into shape afterwards, and that is the version auditors take apart.