IT security guideline — structure, mandatory content and implementation

The most important thing in brief:

• An IT security policy is a binding set of rules that determine how a company protects its IT systems, data and networks — it forms the basis for access controls, incident management and employee awareness.
• Since the NIS 2 Implementation Act came into force in December 2025, documented security guidelines mandatory for over 30,000 companies in Germany — Violations may result in fines of up to 10 million euros and personal liability on the part of the management.
• An effective guideline is not created by copying and pasting a template, but through a structured inventory of your own IT landscape, clear responsibilities and regular review — IT documentation is the indispensable basis for this.

What is an IT security policy?

An IT security policy is a formal document that defines the rules and procedures for protecting an organization's IT infrastructure, data, and networks. It determines How employees handle IT resources, who is responsible for which security aspects and how incidents are responded to.

The distinction is important: An IT security policy is strategic and framework. It defines goals, responsibilities and principles. The specific instructions for action — such as how long a password must be or which websites are blocked — belong in subordinate documents such as the IT usage policy (Acceptable Use Policy).

In practice, however, these boundaries are blurred. Many companies summarize both in one document. This works as long as the strategic level is not lost in detailed regulations.

Why does your company need an IT security policy?

You know the scenario: The next audit is pending, the auditor asks about your IT security policy — and you know that The three-page Word document from 2019 is no longer sufficient. Or worse: None even exists.

Since December 2025, this is no longer just a matter of comfort. With the NIS 2 Implementation Act are documented risk management measures — and this includes IT security guidelines — A legal obligation for thousands of companies became. Management is personally liable.

But even beyond legal obligations, an IT security policy creates three things that technology alone does not deliver:

• Commitment: It makes IT security a documented obligation — for everyone in the company, from management to working students.
• Orientation: In normal operation and in the event of a crisis, everyone knows which rules apply and who to contact.
• Traceability: During audits, certifications and in the event of a claim, the guideline proves that your company takes its due diligence obligations seriously.

Without this foundation, the foundation is missing — No matter how much budget goes into technical measures.

What changed in 2026?

The regulatory environment for IT security guidelines has fundamentally tightened since the end of 2025. Two developments are particularly relevant:

NIS-2 is applicable law. The NIS 2 Implementation Act has been in force since December 6, 2025. Around 30,000 companies in Germany — significantly more than under the old KRITIS regulation — must now Demonstrate binding risk management measures. This includes explicitly documented security policies and procedures. The registration deadline at BSI portal Ran until March 2026. Anyone who fails to fulfill their duties risks fines of up to 10 million euros or 2 percent of annual global turnover.

In essence, NIS-2 requires affected companies to:

• Documented risk management measures and safety guidelines
• Reporting of significant security incidents within 24 hours (initial report)
• Regular management training on cybersecurity
• Ensuring supply chain security — service providers and suppliers must also be involved
• Personal liability of management in the event of breaches of duty

BSI IT Grundschutz becomes Grundschutz++. At the beginning of 2026, the BSI began a fundamental modernization of its regulations. Instead of the extensive compendium with rigid components, Grundschutz++ uses machine-readable set of rules in JSON format, which enables automated testing. Requirements were reduced and prioritized by around 80 percent. For companies, this means: Policies must be vivid, verifiable, and adapted to current threats — the days of static PDFs in drawers are over.

What content belongs in an IT security policy?

Each IT security policy must be tailored to the specific requirements of the company. Nevertheless, there are core components that should not be missing from any set of regulations. The following elements are based on BSI IT basic protection, to ISO 27001 and to the requirements of GDPR:

• Scope and objective: Who does the Directive apply to? Which IT systems, locations and groups of people are involved? This is also where the desired level of protection belongs — based on the CIA triad of confidentiality, integrity and availability.
• Responsibilities and roles: Who has overall responsibility (management)? Who coordinates operational implementation (ISB, IT management)? What are the duties of individual employees? Without clear responsibilities, any directive remains ineffective.
• Access and authorization management: Rules based on the principle of least privilege: Everyone only receives the access rights that are necessary for their task. This includes requirements for passwords, multi-factor authentication and regular verification of authorizations.
• Incident management and reporting requirements: A defined process for detecting, reporting, and responding to security incidents. The following applies under NIS-2: Initial report within 24 hours, detailed report within 72 hours, final report within one month.
• Data backup and emergency preparedness: Backup strategies, recovery plans, and responsibilities in case of an emergency. Who decides when there is an emergency? How are systems prioritized?
• Training and awareness raising: Regular awareness measures for all employees — not as one-off compulsory training, but as a continuous process. This includes phishing simulations, short training courses and clear contacts.
• Rules for the use of IT resources: Requirements for using company hardware, private devices (BYOD), cloud services and — increasingly important — the use of AI tools in everyday work.
• Review and update: Defined intervals for the revision of the Directive (at least annually) and triggers for unscheduled revisions — for example following security incidents, legislative changes or the introduction of new technologies.

How do you create an IT security policy step by step?

Downloading a template, using a name, having it signed — that's how many people imagine the process. The result is documents that fail the first audit or are ignored by employees because they ignore the reality of the company.

The better way is through four phases:

1. Inventory of the IT landscape
2. Risk analysis and assessment of protection requirements
3. Formulation and coordination of the Directive
4. Introduction, training and ongoing review

Inventory of the IT landscape. Before you write a single line, you need an up-to-date picture of your IT infrastructure: Which systems are in use? Who has access to what? Where is the critical data? Without this basis, you are writing a policy for an IT environment that no longer exists. Many companies are already failing to take this stepbecause their IT documentation is out of date or incomplete.

Risk analysis and protection requirements. Based on the inventory, you will assess: Which systems and data have which protection requirements? What are the biggest risks? Die Protection requirement assessment in accordance with BSI standard 200-2 offers a proven framework for this. Not every asset needs the same protection — and It is precisely this differentiation that makes the difference between a practical guideline and a theoretical guideline.

Formulate and vote on guidelines. Only now does the actual writing begin. It is crucial that it is not just the IT department that is involved. Management, data protection officer, works council and ideally also representatives of the specialist departments should be involved. A guideline that was created on the IT drawing board is rarely accepted in practice.

Use language that even non-technicians can understand. Phrases such as “Only use approved USB sticks” sound obvious — but what exactly is a “approved” stick? How do you recognize him? Practicality determines whether a guideline is lived or ignored.

Introduction, training, and review. The completed guideline needs formal approval by management and must be made available to all employees. More importantly, it needs accompanying training that not only informs but also motivates. And it needs fixed audit dates — at least once a year, in addition after relevant changes.

What mistakes do companies make most often?

A typical scenario from consulting practice: A medium-sized mechanical engineering company with 200 employees has its IT security policy drawn up externally by a lawyer. The document is legally sound, but No one in the IT department has ever read it. The password complexity requirements contradict the technically configured group policies. In the event of a ransomware incident, no one knows who will report it to the BSI for the first time.

The four most common mistakes:

• No inventory before writing. You regulate access rights for systems that you do not fully know. Without up-to-date IT documentation, any security policy is speculation.
• Create in isolation without coordination. If only the IT department — or worse: just an external service provider — defines the content, There is a lack of acceptance by specialist departments. The managers, who will later have to answer for compliance, do not know the document.
• Once written, never touched again. IT environments are constantly changing. New cloud services, new employees, new threats — A policy without regular updates quickly loses its value. Particularly critical: When the guideline does not contain any regulations on AI tools, even though employees have been using them for a long time.
• Too long and too complicated. A 40-page document full of legal German is not read. Better: a compact framework document of just a few pages, supplemented by specific instructions for action for individual areas.

What is the role of IT documentation?

This is a blind spot that is missing in most IT security policy guides: A guideline can only be as good as the database on which it is based.

Without up-to-date IT documentation, you lack the basis for key components of the guideline:

• Scope of application: Which systems are running on your network? Without inventory, there is no scope.
• Authorization concept: Who has access to which resources? Without authorization analysis, there is no least-privilege principle.
• Protection zones: How is your network architecture structured? Without visualization, there is no meaningful segmentation.
• Emergency planning: Which systems are critical? Without dependency analysis, there is no prioritization in an emergency.

Automated IT inventory tools such as Docusnap create this basis: They record hardware, software, user authorizations and network structures regularly and without manual effort. On this basis, Carry out well-founded protection requirements, analyze authorizations and draw up emergency plans — all requirements for an effective IT security policy.

How do you check the effectiveness of your policy?

An IT security policy is not an end in itself. It must work. Three approaches help with the review:

• Internal audits: Check regularly whether the defined measures are actually being implemented. Are the permissions up to date? Are backups carried out as required? Are the reporting channels known?
• Key figures: Make progress measurable — through the proportion of trained employees, the number of reported incidents, response times to security events, and results of phishing tests.
• External reviews: Penetration tests or certification audits in accordance with ISO 27001 provide an independent assessment and uncover blind spots that are overlooked internally.

The decisive factor is that the results of the review must be incorporated into the revision of the Directive. Only this cycle of guidelines, implementation, testing and adjustment makes IT security sustainable.