My path into ISO 27001

Over the last months I’ve spent a lot of time with ISO 27001, mainly because I wanted to move forward with my personal certifications.
My first idea was: memorize stuff – pass exam – done.

That’s not how it turned out.

Once you go a bit deeper into the standard, you realize pretty quickly that the core ideas make a lot of sense.
Many things look like pure formalities at first glance, but in practice they add real value –
especially in small and medium-sized companies.

If you apply it properly, ISO 27001 can bring a lot of structure:
for your own understanding, but also for the actual work at a client.
It all feels bureaucratic at first, but in the end it sorts exactly the things that would otherwise be ignored for years.

The same is true for personal development in IT security – whether you aim for a certification or “just” want to sort your knowledge:
The standard gives you a shared language and a clear framework.
That also makes future work with potential customers much easier.

But there are two real risks I see:

Blindly filling out templates, just so something exists on paper
Expensive ISMS tools that offer almost no value for small companies

In many cases, a normal, well-maintained document structure is absolutely enough.
And templates can be bought once or are included anyway if you work with a consultant.

Before we go into ISO 27001 details

First I want to talk briefly about what ISO 27001 is actually about – or more precisely:
what helped me personally to keep an overview.

After that come the concrete contents – ⚠️ warning, wall of text.

ISO 27000 & ISO 27001 in short

ISO 27001 is the international standard for Information Security Management Systems (ISMS).
In essence it is about:

Building a system that lets you implement information security in a planned, traceable and risk-based way – fitting to the organization, not as a goal in itself.

ISO 27000 is the related family, for example:

terminology and vocabulary
guidance such as ISO 27002
extensions like ISO 27701 (privacy)
audit guidelines (ISO 19011)

1. Responsibilities & Governance (ISO 27001:2022 – A.5.x)

Without clearly defined responsibilities there is no working ISMS –
and in general no working information security.
This is what your security level stands or falls with.

Minimum requirements:

A short information security policy (1–2 pages)
→ A.5.1 Policies
A named person responsible for information security (not necessarily full-time)
→ A.5.2 Roles
A structured risk assessment (lightweight is fine)
→ A.5.4 Risk management
At least minimally documented core processes: incident, change, access

These points form the basis for all other building blocks of information security.

2. Asset, Patch & Vulnerability Management (A.8.x)

This is the area that in practice reduces most of the security risk –
and at the same time is one of the most common blind spots.

What you need:

A complete asset inventory (servers, cloud, endpoints, data)
→ A.8.1 Inventory
A patch and update process (monthly or risk-based)
→ A.8.8 Technical vulnerabilities
Documented baseline configurations (e.g. admin rights, firewalls, MFA)
→ A.8.9 Configuration management
At least roughly defined logging & monitoring
→ A.8.16 Monitoring activities

Without this foundation, every other security concept is just cosmetics.
Many security incidents start exactly here: unclear assets, missing updates, weak hardening.

3. Incident Response & Security Monitoring (A.5.24–A.5.28)

A stable incident response process prevents escalation and makes sure that security incidents are detected, assessed and handled properly.

Key elements:

Incident response policy (definition of event/incident, reporting paths)
Clear roles & escalation paths
→ A.5.24 Information security incident management planning and preparation
Standardized IR process
Identify → Contain → Eradicate → Recover → Review
→ A.5.26 Response to information security incidents
Incident log or tickets as evidence
→ A.5.27 Learning from information security incidents
Evidence preservation (log export, permissions)
→ A.5.28 Collection of evidence

Again: start simple, then build it up over time.

4. Secure Development & Supply Chain (A.5.19–A.5.20 & A.8.25–A.8.29)

(Especially important for software companies)

A clear and documented development process is the key factor for software companies – and often one of the toughest customer requirements, for example in the energy or industrial sector.

Important elements:

A lightweight Secure Development Lifecycle (SDLC):
Plan → Dev → Review → Test → Deploy
→ A.8.25 Secure development lifecycle
Secure coding rules (e.g. code reviews, secrets management, dependency updates)
→ A.8.28 Secure coding
Security testing (automated is fine)
→ A.8.29 Security testing
Separation of Dev/Test/Prod
→ (Note: the exact wording should be cross-checked with ISO/IEC 27002:2022 – I am not 100% sure here.)
Third-party risk checks (SaaS, libraries, vendors)
→ A.5.19 Supplier relationships
Security requirements in contracts
→ A.5.20 Supplier agreements

ISMS – Basics

An ISMS (Information Security Management System) is the framework
that an organization uses to implement information security in a planned, traceable and continuously improving way.

Goals: confidentiality, integrity, availability
Objects to protect: information, systems, processes, people, reputation
Elements: policies, processes, procedures, roles, evidence
Controls: technical, organizational, physical, personnel
Approach: risk-based and process-oriented
Logic: PDCA cycle (Plan–Do–Check–Act)

ISMS

Basics

An ISMS (Information Security Management System) is a set of related elements of an organization that define policies, objectives, processes, procedures, rules and related resources used to achieve the organization’s objectives – here: appropriate information security.

At the core, it protects:

information that is valuable to the organization
devices, facilities, software and services
people and their skills
the organization’s reputation and image

To do that, you need:

rules and requirements (policies, processes, procedures)
roles and responsibilities (e.g. ISB/CISO, process owners)
suitable controls in four categories:
- technical
- organizational
- physical
- personnel
  (preventive, detective, corrective)

Typical ISMS outcome artifacts

ISMS handbook / ISMS wiki

Information security policy

Roles and responsibilities matrix

Process and procedure descriptions

Overview “objects to protect & security objectives”

Process orientation

ISO 27000, ISO 20000 and ISO 9000 follow a process-oriented approach:
The focus is not the org chart, but the actual flows (e.g. incident management, change management, access management).

Outcome

High-level process map

List of ISMS-relevant core processes

Plan–Do–Check–Act

The ISMS is meant to be a dynamic system. Assets, risks and requirements change – that is why we use the PDCA cycle:

Plan – set objectives, analyze risks, plan controls
Do – implement controls
Check – check conformity, effectiveness and efficiency
Act – define and implement improvements and corrections

Outcome

Visualization of the PDCA cycle

Overview of ongoing improvement actions

Link between PDCA and ISMS processes

4. Requirements and specifications

From section 4 onward, we reach the actual normative core of ISO 27001.
The requirements in sections 4–10 together with Annex A form the basis for audits.

4. Context of the organization

4.1 Understanding the organization

The organization needs to understand its environment: political, legal, cultural, social, technical, economic and regional aspects, as well as important trends and external relationships.
The ISMS should fit existing structures and create processes that are actually workable – not just “paper processes”.

Outcome

Document “Context of the organization” (internal/external topics)

Basis for scope definition and risk management

4.2 Understanding the needs and expectations of interested parties

Relevant stakeholders (e.g. customers, regulators, suppliers, employees) and their information security requirements must be identified and evaluated. It also needs to be clear which of these requirements are addressed by the ISMS.

Outcome

Stakeholder analysis

List of interested parties

Mapping of their requirements

Marking “covered by ISMS / outside of scope”

4.3 Determining the scope of the ISMS

The scope defines which locations, processes, IT systems and organizational units are covered by the ISMS – including interfaces to other companies and service providers. The results from 4.1 and 4.2 feed into this.

Outcome

Scope statement

Description of what the ISMS covers (what is in, what is out)

Named locations, systems, processes

Defined interfaces and boundaries

Approval by top management

4.4 Information Security Management System

The organization must establish, implement, maintain and continually improve an ISMS in accordance with the requirements of the standard.

Outcome

ISMS description

Short description of how the ISMS is structured (document structure, roles, main processes)

Reference to the ISMS handbook / wiki

Overview “building blocks of the ISMS”

5. Leadership

Leadership and commitment

Top management is responsible for making sure that information security:

fits the organization’s strategy,
has clear objectives and policy,
is provided with enough resources,
is communicated and lived in the organization,
is effective and continuously improved.

Outcome

Decision / statement on the ISMS (management commitment)

Minutes of management meetings where ISMS is discussed

Link between information security objectives and business objectives

Policy (information security policy)

Top management must define an information security policy that:

is appropriate to the purpose of the organization,
provides a framework for security objectives,
contains a commitment to fulfil requirements and improve,
is documented, communicated internally and – where relevant – made available externally.

Outcome

Information security policy

1–2 pages, approved by top management

describes objectives, security objectives, scope and roles

evidence that it has been published and communicated

Roles, responsibilities and authorities

Roles for information security (e.g. ISB/CISO, process owners, system owners) must be clearly assigned – including responsibilities, authorities and reporting to management.

Outcome

Roles and responsibilities matrix (including deputies)

Org chart including ISMS roles

Formal appointment of ISB/CISO

6. Planning

6.1 Risks and opportunities

The organization must identify risks and opportunities related to:

the ISMS itself,
achieving objectives and
unwanted effects on information security

and plan how to address them.

Outcome

Overview “risks and opportunities for the ISMS”

List of actions to handle these management system risks

6.1.2 Information security risk assessment

You define criteria (e.g. risk tolerance, assessment methods), then:

identify risks related to confidentiality, integrity, availability,
assign risk owners,
evaluate impact and likelihood,
prioritize risks.

6.1.3 Information security risk treatment

Based on the risk assessment you:

choose treatment options (avoid, reduce, transfer, accept),
define appropriate controls (from internal or external sources),
check all risks against Annex A (“Have we missed anything?”),
create the Statement of Applicability (SoA),
build a risk treatment plan,
and get risk owners to accept residual risks.

Outcome

Statement of Applicability (SoA)

List of all Annex A controls

Decision “applicable / not applicable” with justification

References to implementing measures / documents

Risk treatment plan

Measures per risk

Responsible persons, due dates, status

Documented acceptance of residual risks

6.2 Information security objectives and planning to achieve them

Information security objectives must:

be consistent with the policy,
be measurable,
consider requirements and risk assessment results,
be monitored, communicated and updated when necessary.

For implementation the organization needs to plan:

what will be done,
which resources are needed,
who is responsible,
when it will be finished,
how success will be measured.

Outcome

Register of information security objectives (incl. KPIs)

Link between objectives and concrete improvement projects

Feedback of objective achievement into management review

6.3 Planning of changes

Changes to the ISMS have to be planned so that they do not create new risks or worsen existing ones.

Outcome

Change log for the ISMS (versioning, changelog)

Assessment of impact for planned changes

Documented approval of changes

7. Support

7.1 Resources

The organization needs to identify and provide the resources required to establish, operate and improve the ISMS (time, money, tools, people).

Outcome

Documentation of how resources were determined

Job descriptions that include ISMS responsibilities

Budget approvals / investment decisions

7.2 Competence

The organization must define:

which competences are required for ISMS roles,
how to make sure people are competent (education, training, experience),
what actions are planned if competences are missing,
how competences are evidenced.

Outcome

Role descriptions including competence requirements

Training and certification overview

Training / development plan

7.3 Awareness

People should know:

that there is an information security policy,
how they contribute to ISMS effectiveness,
what the consequences of non-compliance are.

Outcome

Awareness activities (presentations, e-learning, onboarding)

Evidence of participation / completion

7.4 Communication

The organization must define:

what to communicate,
when,
with whom,
and through which channel –
internally and externally (e.g. customers, suppliers, authorities, in case of incidents).

Outcome

Communication plan (topic, timing, audience, channel, owner)

Evidence of actual communication (reports, emails, status updates)

7.5 Documented information

Documents and records of the ISMS need to be:

defined (content, scope),
created and updated (identification, format, approval),
controlled (access, protection, versioning, retention).

Outcome

Document control policy

Central document register with version, owner, status

Approval and version history of ISMS documents

8. Operation – Do

8.1 Operational planning and control

The organization must plan, implement and control the processes needed to meet ISMS requirements – including criteria and controls. This also covers outsourced processes at service providers.

Outcome

Operational process descriptions (e.g. incident, access, backup, change management)

Overview of outsourced processes and responsibilities

Evidence of operation (tickets, logs, change records)

8.2 Information security risk assessment

Risk assessment must be:

conducted at planned intervals,
and when significant changes occur (e.g. new applications, locations, services).

Outcome

Regularly updated risk assessments

Versioning and history of risk registers

Defined triggers for reassessment

8.3 Information security risk treatment

The planned treatment measures must be implemented and tracked.

Outcome

Current implementation status of the risk treatment plan

Evidence of implemented controls (configs, policies, logs, test reports)

9. Performance evaluation – Check

9.1 Monitoring, measurement, analysis and evaluation

The organization must define KPIs / security metrics that:

cover processes and controls,
use clear methods for collection and evaluation,
define responsibilities and timing.

Outcome

Information security KPI / metrics catalogue

Regular reports (e.g. quarterly)

Management decisions based on these metrics

9.2 Internal audit

Internal audits must be carried out at planned intervals to check:

conformity with the standard and internal requirements,
effectiveness of the ISMS.

Important:

plan audit programme, criteria and scope,
ensure objectivity and independence of auditors,
document and report results.

Outcome

Audit programme (1–3 year perspective)

Audit plans, checklists, reports

Action lists from findings including follow-up

9.3 Management review

Top management periodically reviews the ISMS based on defined inputs (e.g. audit results, KPI trends, stakeholder feedback, status of actions).

Outcome

Minutes of management review

Management decisions (e.g. resources, priorities, direction)

Derived improvement and corrective actions

10. Improvement – Act

10.1 Continual improvement

The organization must continually improve the ISMS regarding suitability, adequacy and effectiveness.

Outcome

Controlled handling of improvement and corrective actions

Documentation in the improvement / action register

10.2 Nonconformity and corrective action

For nonconformities the organization:

reacts (correction, limiting consequences),
analyses the cause,
checks whether similar problems exist elsewhere,
implements corrective actions and
checks their effectiveness.
If necessary, the ISMS is adapted.

Outcome

Description of the nonconformity

Corrections and corrective actions

Evidence of effectiveness

Updated ISMS documents / processes

Summary

The scope defines what the ISMS covers.
The policy and risk management form the steering core.
Top management is responsible for direction, resources and priorities.
With audits, metrics and management reviews the effectiveness is evaluated.
Through corrective and improvement actions the ISMS is continuously developed further.

Overall ISO 27001 outcome

A working, auditable ISMS

Clear artifacts: scope, SoA, risk & action registers, policies, processes, evidence

Ability to get certified (if wanted) and to manage information security in a repeatable way