Three Levels of Information Security

Information security is not a project. It is an ongoing responsibility. And like any ongoing responsibility, it needs a clear structure to work.

That structure consists of three levels: strategic, tactical, and operational. The operational level has two parts. Each level has its own purpose, its own time horizon, and its own responsibilities. Together they form the framework within which information security becomes measurable, manageable, and transparent.

A consistent example helps. Take a mechanical engineering company with 50 employees. A solid order book, their own engineering drawings, and one IT security person who is also effectively the IT manager.

The strategic level belongs to senior management. This is not where technical decisions are made. This is where the decision is made as to why information security is pursued in the first place.

The output of this level is the information security policy. It answers a single question: what needs to be protected, and why? No systems, no processes, no measures. Just the why.

That clarity is the prerequisite for everything else. Without a defined why, every subsequent measure lacks a foundation. Responsibility for this why always rests with senior management. They can delegate tasks. They cannot delegate the responsibility.

The management of the engineering company recognises: our engineering drawings are our most important asset and must remain confidential.

That is the why. It goes into the policy. Not a word about how that will be ensured. That is not the purpose of this level.

The tactical level translates the why into concrete processes. This is where decisions are made about what needs to be implemented, who is responsible, and how effectiveness is reviewed.

This is the level of the IT manager or the ISMS owner. In many SMEs, that is the same person who also works operationally. What matters is that this level is consciously filled – even if no dedicated role exists for it.

Processes at this level are vendor-neutral and system-independent. The question is not which tool is used. The question is what needs to be governed, who carries the responsibility, and where the boundaries of authority lie: what can be decided independently, and when does senior management need to be involved.

From the management's why, the IT manager derives an access management process. It defines who receives access to sensitive systems, how that access is requested and approved, and who regularly reviews whether permissions are still current.

The process also covers this: when someone leaves the company, their access rights must be revoked within 24 hours. HR notifies. IT acts. No tool, no command. Just the rule.

The first part of the operational level describes the standard. It describes how a process is carried out in practice, with clear responsibilities. Still vendor-neutral, but no longer abstract.

This is where it is documented who reports what to whom, what gets documented, and what happens when a step does not go as planned. These instructions are the link between the defined process and the day-to-day work.

An engineer leaves the company. HR notifies IT on the same day. IT reviews all active access rights for that person, revokes them in full, documents the process, and confirms completion to HR.

No tool, no command. The procedure applies regardless of which system is in use.

The second part of the operational level contains the work instructions, playbooks, and so on – and is vendor-specific. This is where concrete systems, tools, and commands come into play. A guide for a Windows environment looks different from one for Linux. Both implement the same standard.

This level is also the only one that feeds real feedback into the loop. What does not work in practice becomes visible here. That feedback flows back to the tactical level and improves the processes.

The administrator disables the user account in the directory service, removes group memberships, revokes access to the CAD system, and closes the ticket with a timestamp.

Three months later, an access review reveals that another former employee still has active permissions. The work instruction was followed. The review uncovered a gap anyway. The feedback goes back to the tactical level: the process needs to be adjusted.

That is the feedback loop in practice.

The levels are not a waterfall model where decisions are made at the top and executed at the bottom. They are a feedback loop.

The why sets the direction. The what creates the structure. The how describes the procedure. The how exactly brings it into practice – and feeds information back up.

When a level is missing, typical problems emerge. Without a why, everything else lacks a foundation. Without a what, there are no processes or responsibilities. Without a how, nobody knows concretely what to do. Without a how exactly, everything stays theoretical – and without feedback, nothing improves.

Note: This article describes the basic structure of an ISMS. What these levels look like in your organisation depends on your size, your industry, and your risks. We are happy to help you find out.