IT-Security – What is important after the decision

Part 2 of 2

The first part of this article looked at how to prepare well-informed IT security decisions. However, the real work is not done once technologies or service providers have been selected; in fact, that is when it really begins.

For IT managers, this means that the decision taken must be translated into a stable, transparent and sustainably functioning security operation. It is precisely here that the biggest gaps arise in practice. Systems are implemented but not integrated. Processes are defined but not put into practice. Responsibilities are unclear.

This article shows what really matters once the decision has been made.

From decision to implementation

A product has been procured, a service provider commissioned – and so the project appears to be complete. In fact, this is where the crucial phase begins: translating the project into an operational model.

In practical terms, this means that a technical or strategic decision must be transformed into a clearly defined service. One with a clear scope, defined responsibilities, documented processes and measurable objectives.

Key questions include:

Which specific systems and data are covered?
Who is responsible for technical and operational matters?
How are incidents identified, assessed and handled?
What escalation procedures apply in the event of an emergency?
What evidence must be provided?

Without this translation, IT security will not become a robust part of the company’s operations.

The launch determines the success

The initial phase following the decision is crucial. A structured onboarding process helps to lay the right foundations and put security measures into practice.

The main focus in the first few weeks is on establishing clarity. The scope must be defined, a responsible service owner appointed, and escalation procedures established. At the same time, systems, data sources and interfaces are identified.
The next phase involves technical implementation: log sources are connected, initial use cases defined and alert mechanisms set up. It is important not only to implement the technology but also to test processes – such as reporting channels or emergency contacts.
A pilot operation should then take place. Here, initial metrics are collected, false alarms reduced and processes refined.
The final stage involves not only the go-live but also an initial review: Do incident playbooks work? Can systems actually be restored? Have reporting and control mechanisms been established?

The key point: This phase is not a one-off, self-contained implementation project, but a handover of the service to regular operations.

Operating models: Who does what – and who is responsible?

Once a solution has been chosen, one question in particular arises in practice: who takes on which tasks during day-to-day operations?

Regardless of the model chosen, the responsibility always remains with the company. Even when services are outsourced, IT managers must ensure that requirements are met and processes are followed.

Typical operating models include:
In-house operation	Managed Services	Hybrid models
In this scenario, all tasks are handled in-house. This offers maximum control, but requires significant human and technical resources – particularly for areas such as 24/7 monitoring or incident response.	External service providers take on specific tasks, such as monitoring or operations. This provides quick access to specialist knowledge and reduces the workload on internal staff.	In many larger companies, this is the most practical solution: management and governance remain in-house, whilst some operational tasks are outsourced. This requires a clear separation of roles and responsibilities.

Choosing a model is less a technical decision than an organisational one. The key factor is whether it works in practice.

Monitoring and Incident Response: Security through Analysis and Application

Security is not achieved through tools alone, but through analysis and application – security monitoring is a good example of this. Logs alone do not ensure security; it is their analysis and the resulting response that make the difference.

In practice, a clear division of roles has become established:

A SIEM system collects and correlates security-related data.
A SOC (Security Operations Centre) evaluates this data, prioritises incidents and coordinates the response.

What matters here is not the technology, but the ability to monitor continuously and respond quickly.

This leads to an uncomfortable but important question: is operating during office hours sufficient? For many companies, the honest answer is: no. Attacks do not follow a schedule – and critical systems are often accessible around the clock. When a security incident occurs, the extent of the damage is determined within a short space of time. This is precisely why incident response should not be an emergency issue, but a prepared process.

Incident Response: Structure rather than improvisation

An effective incident response process comprises several steps:

Detection and initial assessment of the incident
Containment and securing of systems
Analysis of the cause
Restoration of operations
Follow-up and improvement

Regulatory requirements must also be taken into account. In many cases, there are reporting obligations – for example, to authorities or under the GDPR. This means that, in addition to the technical response, communication must also function effectively. Who reports what, when and to whom? Without clear playbooks, delays will occur here – and these are precisely what prove critical in an emergency.

Resilience starts with the basics

Many IT security issues do not stem from anything particularly dramatic. They arise from a failure to implement basic principles, or from implementing them inadequately.

These include, in particular:
Patch and Change Management	Backup and recovery	Identity and Access Management
Security vulnerabilities must be addressed promptly. At the same time, changes must be implemented in a controlled manner. In practice, this requires both formalised processes and contingency measures for critical situations.	Backups are often considered to be sorted once they have been set up. However, what really matters is something else: will the restore work when it really counts? A backup without a tested restore is no guarantee of security.	Access is one of the most common attack vectors. That is why privileged accounts must be given special protection – for example, through multi-factor authentication and clear authorisation structures.

The common thread: these measures are not optional. They form the basis for everything else.

Measuring what works

A common weakness in IT security is the lack of measurability. Measures are implemented – but their effectiveness remains unclear.

Yet this is precisely what matters: IT managers must be able to assess whether their security strategy is working.

Typical metrics include:

Time to incident detection
Time to response
Proportion of unprocessed critical alerts
Patch status of critical systems
Success rate of recoveries

These metrics are not an end in themselves. They show whether theoretical security translates into actual operational capability.

Organisation and roles: clarity breeds confidence

Alongside technology and processes, organisation is the third key factor.

In practice, a clear division of responsibilities has proven effective:

The management bears overall responsibility

IT Management / CISO / ISB oversees and reports

Security Operations is responsible for day-to-day operations

Departments and other functions are integrated into processes

One thing is particularly important here: responsibilities must be clearly defined and documented.

Unclear lines of responsibility are one of the most common causes of delays in an emergency.

Awareness: Safety is also a matter of behaviour

Technical measures fall short if organisational and human factors are not taken into account.

Phishing attacks, social engineering and misconfigurations often arise where processes are not understood or not put into practice.

That is why awareness is an integral part of security operations:

regular training
realistic simulations
measurable results

Here, too, the perspective is crucial: the goal is not the training itself, but a change in behaviour.

Documentation and compliance: safety must be verifiable

Particularly in regulated environments, it is not enough simply to implement security measures. They must also be verifiable.

This applies, amongst other things, to:

Process documentation

Evidence of measures implemented

Records of tests and exercises

Reports for management and audits

In practice, this means that there needs to be a central location where this information is stored in a structured manner. Without this documentation, a gap arises – not only technically, but also legally.

The key insight: security is a system

As in the first part, a key insight applies here too: IT security is not a product. It arises from the interplay of technology, processes, people and governance. Only when these components work together seamlessly can a robust security operation be established.

Conclusion: The difference becomes apparent in use

The quality of an IT security decision only becomes apparent in day-to-day operations. Technologies and concepts alone do not guarantee security – what matters is how consistently they are integrated into processes, responsibilities and workflows.

For IT management, this means that a strategic decision must be translated into a manageable operational state. Processes must function effectively, be regularly reviewed and prove effective in an emergency. At the same time, there needs to be transparency regarding whether measures are actually effective.

Ultimately, it is not about individual tools, but about controllability. Those who know what is critical, how incidents are handled and how effective their own measures are can actively manage security – rather than merely reacting.

IT security is therefore not a project, but a permanent operational state.