Information security management (ISO/IEC 27001)

We implement an information security management system and prepare you for the certification audit. It is not a documentation project. What decides the outcome is whether the controls have actually been running for some time before the audit, because the auditor checks practice, not intentions.

A certificate or a documented system?

Not everyone needs a certificate. The system is built the same way in both cases; what differs is whether a certification audit follows at the end — and that is months of work, so it is worth settling before the project starts.

• A certificate makes sense when a customer requires it in a contract or a tender, or when you need one piece of evidence for several customers instead of answering their questionnaires one by one.

• A documented system is enough when a customer wants to see the controls behind a security questionnaire, or when the decision is your own.

If the requirement came from a customer, ask them whether they insist on a certificate from an accredited body or accept evidence of the controls in place. Surprisingly often the second is enough. If you are not sure, tell us who is asking and in what words.

What the project involves

1. Defining the scope. Which processes, sites and systems the management system covers — as narrow as still serves the purpose. A scope that is too wide makes the project and every later audit more expensive, and widening it later is easier than narrowing it.

2. Gap analysis. We compare the current state with ISO/IEC 27001:2022 and its Annex A. The output is a list of gaps in order of priority, with an estimate of effort.

3. Risk assessment. The core of the standard, built so that it also serves other regimes. Our approach is set out under risk analysis.

4. Statement of Applicability. Which controls apply, why, and how they are implemented. It has to be consistent with the risk register — a mismatch between the two is a finding at the audit.

5. Documentation and controls in operation. Policies, procedures and records in the form an auditor expects, and the controls put into everyday practice, including training. The longest phase: the controls have to run and produce records before the audit.

6. Internal audit. Required before certification, and the last chance to find shortcomings before the certification body does. It is performed by someone who did not build the part being audited — nobody audits their own work.

7. Management review. Management goes through the results, the risks and the audit findings, and decides what follows. The auditor looks for evidence that it led to decisions.

8. Choosing a certification body. We help you choose one and prepare the information it needs for its quotation.

9. The certification audit. We accompany you through both stages and help resolve any nonconformities.

What to expect at the certification audit

• Stage 1 is a review of readiness. The auditor reads the documentation, checks the scope, the risk assessment and the Statement of Applicability, and decides whether the organisation is ready for the second stage.

• Stage 2 checks that the system works in practice. The auditor interviews the people responsible for the controls — not only the security manager — reads records and follows samples: an access right granted and later removed, an incident recorded and closed, a supplier assessed.

• Nonconformities. Where a requirement is not met, the auditor records a nonconformity. A serious one generally has to be corrected and evidenced before the certificate is issued; for a minor one, the organisation proposes corrective action, which is checked later. We help you find the cause — fixing only the symptom tends to come back at the next audit.

The certificate is valid for a fixed period, with surveillance audits in between and a recertification at the end. A system built for the audit and then left alone shows at the first surveillance audit.

Where our role ends

The certificate is issued by an accredited certification body, not by an adviser — and the same organisation may not both build a management system and certify it. It is a requirement of impartiality, and it is the right one: otherwise the certificate would mean nothing.

That is why you sign the contract with the certification body yourself and pay it separately. We prepare you and stay with you through the audit.

One system, several obligations

Risk assessment, asset management, access rights, supplier management and incident handling recur across frameworks. Built once, the management system is often the backbone of the evidence for others — done separately, the same work is paid for several times and the documents start to contradict each other.

• NIS2. ISO/IEC 27001 is often the basis on which organisations within scope document their security measures. What exactly has to be shown is set by the rules of each country.

• TISAX. The VDA ISA catalogue largely follows the structure of the same standard and adds prototype protection and higher demands on physical security. The assessment itself may only be performed by a provider accredited by ENX — we prepare you for it, we do not perform it.

• GDPR. The technical and organisational measures under Article 32 are largely evidenced through the same processes.

• DORA. ICT risk management and the management of ICT third-party providers are the same processes in a different framework.

Who does the work

Implementation is led by people who also perform audits, so they know in advance what an auditor opens first and where they ask for evidence. Our lead auditors are listed under qualifications and memberships.

In the last three years, IOSEC Slovakia has completed 50+ implementations of an information security management system; 30+ of its clients went through certification. We do not name those clients; the reason is in the code of ethics.