ISO 27001 checklist: how well is your organisation prepared?

1. Is the scope clear?

Start with a clear line.

Can you explain?

• which organisational elements fall within scope;
• which services and processes are included;
• which locations are part of the project;
• which systems and suppliers are relevant;
• which boundaries have been chosen deliberately.

A too vague scope makes almost everything more difficult after that.

My check question

Can someone outside the project explain in a few sentences what exactly is certified?

If that doesn't work, I'd tighten the scope first.

2. Are context and stakeholders in the picture?

ISO 27001 asks that the organisation understands the context in which it operates.

Practically, this means that you know:

• which customers or clients make requirements;
• which laws and regulations are relevant;
• the contractual obligations that exist;
• which chain dependencies are important;
• what internal expectations apply.

This does not have to be a comprehensive theoretical document.

It should be particularly useful in determining risks, scope and priorities.

3. - Is ownership arranged?

An ISMS only works when it is clear who is responsible for what.

Check:

• who is responsible for the board;
• who manages the ISMS;
• who are risk owners;
• who performs controls;
• who succeeds in the event of a deviation;
• who decides on residual risk.

I prefer a simple responsibility structure that people know than an extensive matrix that nobody works with.

4. Is there an actual risk analysis?

The risk analysis is not an annex to satisfy the auditor.

Here should be visible:

• what is important for the organisation;
• the threats and vulnerabilities that are relevant;
• the potential impact;
• which risks are given priority;
• the risks to be addressed;
• which risks are deliberately accepted.

Question for management/direction

What information security risks currently call for demonstrably board-level attention?

If the risk analysis fails to answer that, it is likely to lack board-level value.

5. Is the risk treatment concrete?

A risk without ownership and measure remains mainly a finding.

Therefore, check that each relevant risk is clear:

• the measure taken;
• who owns the property;
• the period of time;
• the residual risk that remains;
• who accepts that residual risk.

This makes the risk register a steering tool.

6. Is the Statement of Application logical?

The Statement of Application, often abbreviated to SoA, shows which management measures are relevant and why.

My preference is to treat the SoA as a substantive bridge between risks and controls.

So not just:

.Control applicable: Yes.

But can also explain why this control is relevant and how the organisation set it up.

7. Are policies and procedures workable?

You need policy.

The aim is just not to produce as many documents as possible.

Check that policy:

• connects with the organisation;
• clarify responsibilities;
• is enforceable;
• is known to the right people;
• periodically assessed;
• is consistent with actual practice.

A procedure that nobody follows doesn't help ISMS much.

8. Are the main technical controls working?

Depending on risk and environment, I expect insight into topics such as:

• identity and access management;
• multi-factor authentication;
• management accounts;
• Endpoint security;
• patch management;
• Vulnerability management;
• logging;
• monitoring;
• backup;
• recovery;
• network security;
• Cloud configuration.

The exact layout varies from one organisation to another.

The audit question remains the same:

Can you show that the measure is appropriate and structural?

9. Have suppliers been demonstrable to be in control?

For many organisations, a large part of actual IT is with external parties.

Therefore, check:

• which suppliers are critical;
• which security requirements apply;
• the access they have;
• what kind of incident arrangements exist;
• which assurance is available;
• how suppliers are periodically assessed;
• what happens if the event of a failure or termination occurs.

Subcontracting IT doesn't mean you're outsourcing the risk.

10. Has incident management been arranged and trained?

An incident procedure is important.

I want to know:

• co-ordinate incidents;
• when management/direction is involved;
• which suppliers should be called;
• how communication is conducted;
• how evidence is secured;
• how recovery is controlled;
• when the last practice has been made.

An exercise quickly makes visible what seemed logical on paper.

11. Is awareness more than an annual e-learning?

Awareness should be linked to risk and behaviour.

So look at:

• relevant target groups;
• recurrent attention;
• Phishing and reporting behaviour;
• increased risks per function;
• onboarding;
• management involvement;
• measurable improvement.

The evidence is not in the number of modules sent, but in what the organisation achieves with it.

12. Are controls carried out demonstrably?

With each important measure, I would like to ask three questions:

Design

Is the measure logically structured?

Existence

- Has it actually been introduced?

Operation

Does it function as intended during the time period?

This prevents a common problem: The organisation has described everything, but can hardly show what has actually happened.

13. Has an internal audit been carried out?

The internal audit should assess independently whether the ISMS is working properly.

Check:

• there is an audit programme;
• is covered with relevant scope;
• have been documented;
• examine its causes;
• Followed up on his actions.

An internal audit is not a check mark before the certification audit.

It's an instrument to find weaknesses of its own.

14. Did the board really assess ISMS?

The management review should make board-level control visible.

There I want to see topics like:

• performance;
• risks;
• incidents;
• audit findings;
• resources;
• suppliers;
• trends;
• improvements;
• decisions.

If the management review exists only because

15. Have any abnormalities and improvements been detected?

An adult ISMS can find trouble.

In fact, if nothing is ever found, I would start asking questions.

Check that:

• the registration of deviations;
• researching causes;
• actions have owners;
• deadlines are followed;
• effectiveness is assessed.

You're showing the system is learning.

A compact board member check

As a board member, I would like to be able to answer these six questions before certification:

1. What exactly is our scope?
2. What digital risks are the top priority?
3. Who owns those risks?
4. What measures are shown to work?
5. What major deviations are still open?
6. What does the management have to prove to be doing?

If there are clear answers to this, there is usually more than just documentation.

What about the IT manager?

For the IT manager, I would look at:

• evidence of management processes;
• account reviews;
• patch reports;
• vulnerabilities;
• logging;
• backup;
• Restore tests;
• amendments;
• suppliers;
• incidents.

My advice is to get proof as much as possible from normal management processes.

Then, just before the audit, no separate evidence plant is required.

When is this checklist insufficient?

When you want to know if you are really ready for certification, your own checklist is usually not enough.

Then you want to have independent assessment:

• which standard parts are still missing;
• where evidence is insufficient;
• where policy and practice are dissimilar;
• which points are likely to receive attention during certification.

There's a ISO 27001 GAP Analysis intended.

Do you want to understand how the certification audit itself is going? Read:

ISO 27001 audit: What happens during the audit?