An ISO 27001 audit often triggers more stress than is necessary.
People sometimes expect a kind of exam where every answer must be right immediately and every missing rule leads to a rejection.
That's not how a good audit works.
The auditor tries to determine whether the Information Security Management System, the ISMS, is properly designed and whether the organisation is demonstrably functioning according to that system.
The auditor looks at documents, talks to people and asks for proof from the practice.
First the distinction: internal audit and certification audit
Within ISO 27001 you will encounter several audits.
Internal audit
The internal audit is part of your own management system.
This will allow you to examine before the certification body comes to see whether:
- arrangements are well-designed;
- processes are carried out;
- evidence is available;
- the identification of defects;
- improvements are being monitored.
The auditor shall be sufficiently independent of the work being assessed.
An internal audit is not a dress rehearsal where you only try to predict the questions the certifying auditor will ask.
It's a control tool of its own.
Certification audit
The certification audit shall be carried out by an independent certifying body.
The first certification is usually made up of two phases:
- Stage 1;
- Phase 2.
After certification, periodic surveillance audits and final recertification will be followed.
What happens during phase one?
Phase 1 is mainly about the question:
Is the organisation sufficiently prepared for the deeper certification audit?
The auditor looks at, among other things:
- Scope;
- context;
- ISMS design;
- relevant documentation;
- risk analysis;
- risk treatment;
- Statement of Application;
- internal audit;
- management review;
- the extent to which the system has been implemented.
Phase 1 is important because it assesses whether phase 2 can be useful.
What does the auditor want to understand?
Not just or documents exist.
The auditor wants to understand:
- why the scope was chosen;
- which risks are important;
- how measures have been selected;
- who is responsible;
- how performance is monitored;
- how the organisation learns and improves.
A folder with documents without a clear story therefore works less convincing than a relatively compact ISMS whose employees understand how it works.
What happens between phase 1 and phase 2?
If phase 1 is to be of interest, it will take time to pick it up.
These may include questions about:
- Scope;
- missing parts;
- insufficient internal audit;
- management review;
- unclear risk analysis;
- insufficient evidence of implementation.
Use that period in a targeted manner.
Don't suddenly rewrite dozens of documents when the core question is somewhere else.
My preference is to determine per point:
- what the auditor actually saw;
- the risk or standard component involved;
- any improvement required;
- What evidence will show that it's been solved?
What happens during phase two?
Phase 2 goes much further into practice.
The auditor shall verify whether the management system is actually functioning.
This is done by:
- interviews;
- samples;
- document examination;
- checking of registrations;
- assessment of checks carried out;
- monitoring risks;
- review of incidents;
- assessing supplier management;
- monitoring access management;
- evidence of monitoring and improvement.
The precise topics depend on the scope and the organisation.
What people speak an ISO 27001 auditor?
Often more people than just the security manager.
Remember:
- management;
- IT;
- HR;
- procurement;
- facility;
- privacy;
- process owners;
- supplier management;
- staff with specific management tasks.
That makes sense.
If information security can only be explained by one person, the security is vulnerable.
An auditor wants to see responsibilities in the organisation land.
What questions does an auditor ask?
The exact questions differ.
Yet the way of asking often comes down to the same thing.
“Let's see how this Working.”
When policy states that access rights are assessed quarterly, the auditor may ask:
- who performed the last review;
- when;
- any anomalies found;
- what happened to it;
- what evidence exists of that.
“Why did you choose this?”
In the case of risks and controls, the foundation is important.
Why does a measure apply to system A and not to system B?
Why is a risk accepted?
Why is a branch outside scope?
♪ What happened last time? ♪
That's a strong audit question.
Examples include:
- when was the last incident;
- when the last restore was executed;
- when the last employee has left the service;
- when the last supplier was assessed.
This will quickly bring the audit to its actual functioning.
What evidence are useful?
Think of, for example:
- risk register;
- Statement of Application;
- policy;
- decisions;
- incident records;
- account reviews;
- backup reports;
- Restore tests;
- vulnerabilities reports;
- supplier assessments;
- awareness registrations;
- change tickets;
- audit reports;
- management review;
- improvement register.
My advice is not to collect evidence specifically for the audit if that's preventable.
Set up processes to produce evidence during normal work.
Then audit preparation costs far less energy.
What's an anomaly?
Where an auditor finds that a relevant requirement is not met, a derogation may be registered.
The precise classification and terminology depends on the certification body and the situation.
More important than the label is what you do with it.
A good cause analysis looks beyond:
.Forgot about the employee.
Question:
- Why could this happen?
- Why didn't the normal check see it;
- is a single case or structural;
- any modification that prevents recurrence;
- how do we check if that adjustment works?
That makes a deviation part of improvement.
Does everything have to be perfect?
No.
ISO 27001 is about a working management system and continuous improvement.
An organisation may therefore have points of improvement.
It becomes problematic when important requirements are not set up, risks are not adequately controlled or the organisation cannot demonstrate that the ISMS is operating in practice.
I usually find it stronger when an organisation can explain:
- where there is a weakness;
- the risk involved;
- who owns the property;
- improvement;
- when it's due.
That's a sign of control.
What does an auditor expect from management?
The board has a real role within ISMS.
That should be visible, too.
Remember:
- direction;
- linking information security to organisational objectives;
- organise responsibilities;
- making funds available;
- assess risks;
- follow performance;
- carry out management assessment;
- support improvements.
A board member doesn't need to know all the controls by heart.
However, it must be clear that information security is managed by the authorities.
What does an auditor expect from the IT manager?
For the IT manager, the emphasis is often on demonstrable implementation.
Examples include:
- patching;
- accounts;
- management rights;
- logging;
- Endpoint management;
- backup;
- monitoring;
- configurations;
- vulnerabilities;
- incidents;
- suppliers.
My advice: not only is the technique in order, but it is also visible how you check that it stays in order.
How do you prepare yourself?
I'd do five steps of preparation.
1. Check the scope
Know which parts, locations, processes and systems fall within the ISMS.
2. Run the risks
Are risks topical? Are owners clear? Are measures still in place?
3. Check evidence
Don't just take documents. Look at recent examples from the practice.
4. Close Open Actions
Not by making things cosmetically green, but by actually creating clarity about status and residual risk.
5. Prepare people for content
No rehearsed answers.
Explain:
- the reasons for the audit;
- that people can answer honestly;
- that evidence is important;
- that they should be able to explain their own process.
An auditor quickly notices when answers are memorized.
What would I not do just before the audit?
I wouldn't start a major document operation.
If you suddenly rewrite 20 procedures a week before the audit, you run the risk of getting the formal text further off the ground.
Look at this:
- actual operation;
- recent examples;
- open risks;
- known abnormalities;
- follow-up;
- Evidence.
That's where the value is.
How long does an ISO 27001 audit take?
This varies from organisation to scope.
Factors include:
- number of employees;
- complexity;
- locations;
- technology;
- outsourcing;
- Scope;
- - Mature.
The certifying body shall determine the audit time required on the basis of the applicable certification rules.
Therefore, ask in advance in the tender.
For the cost side we have a separate article:
What does ISO 27001 certification cost?
When are you audit-ready?
For me, an organisation is audit-ready when it can show without a play:
- This is our scope;
- These are our main risks;
- This is what we agreed to;
- That's how we do it;
- This is evidence we have;
- There are still weaknesses here;
- This is what we're doing;
- That's how the board is steering it.
That's much more important than a perfectly-looking document library.
You want to know where there are gaps first? Then there's a ISO 27001 GAP Analysis a logical step before certification.


