NIS2 READY
Security documentation does not have to mean dozens of policies that nobody reads. What matters is having the rules your organisation actually needs – and knowing who is responsible for them and whether they are followed in practice.
Having a Security Policy Does Not Mean You Are Secure
When building cybersecurity, it is easy to start with documents. Find a security policy template, add your organisation’s name, have it approved and file it away.
Formally, the document exists. But does it actually describe what happens in the organisation?
If a policy states that user access rights are reviewed regularly, it should be clear who performs the reviews, how often they take place and what happens when a problem is identified. If a business continuity plan states that the organisation can restore a critical service, the organisation should know whether that procedure has ever been tested.
Security documentation should therefore not be an end in itself. It should describe the rules, responsibilities and procedures the organisation actually uses to manage its security. This principle is also reflected in the Slovak Cybersecurity Act, which requires approved security documentation to be up to date and reflect the actual situation.
The worst security policy is not a short one. It is one that describes security measures that do not actually exist in the organisation.
How Many Security Policies Do You Need?
There is no universal number.
A smaller organisation does not necessarily need a separate document for every security topic. Related rules can be combined into a single policy. As the organisation grows, introduces new systems, works with more suppliers or faces additional obligations, some topics may later need to be addressed separately.
It is therefore more useful to ask:
“Have we covered the rules we actually need?”
rather than:
“How many security policies must we have?”
A Practical Starting Point: Key Areas to Cover
If a smaller organisation is starting from scratch, it can initially organise its basic security rules into six documents, for example.
1. Security Policy and Security Governance
The document should explain the basic cybersecurity rules and, above all, who is responsible for what.
Who manages security? Who owns assets and risks? Who approves security measures? Who should serious issues be reported to?
It does not have to be a lengthy document. What matters is that roles and responsibilities are clear. Security cannot be left to the IT department alone. Management approves security measures, oversees their implementation and is accountable for them. In a smaller company, this often means that important decisions, such as risk acceptance, are approved directly by the managing director.
2. Asset and Risk Management
An organisation needs to know what it is protecting.
Initially, it does not need to record every monitor or cable. However, it does need to identify its important services, information, systems and other assets, and know who is responsible for them. A simple classification of information by sensitivity – for example, public, internal and confidential – can also help employees understand how different types of information should be handled.
Risk management builds on the asset inventory: how risks are identified and assessed, how they are treated, who is responsible for security measures and who can decide that the organisation will accept a particular risk.
3. Access Management and Operational Security
This area includes rules for granting and revoking access, reviewing permissions, updating systems, protecting against malware and other basic requirements for secure operations.
It also includes performing backups – what is backed up, how often and who is responsible.
However, performing backups is different from knowing whether systems and data can actually be restored from them. We will return to this in the business continuity section.
4. Security Incident Management
When an incident occurs, it is not the right time to start figuring out whom to call.
It should be clear how an incident is reported, who handles it, when it is escalated, who informs management and who is responsible for any required reporting to the relevant authorities.
Up-to-date contact information is also essential. An incident response plan containing the phone number of someone who left the organisation two years ago will not be much help.
5. Business Continuity and Recovery
An organisation should know which services are essential to its operations, how long they can be unavailable and how they will be restored in the event of an outage.
This is no longer just about whether backups are performed, but whether systems or data can actually be restored from them and whether recovery can be completed within the time the organisation requires.
This is why business continuity and recovery plans, as well as their testing, belong in this area.
6. Security Rules for Employees
Employees need to know what is expected of them when using passwords, email, work devices or handling information, and what they should do if they notice something suspicious.
The rules should also cover employee onboarding, changes in job roles and departures from the organisation.
What About Suppliers?
If an external supplier has access to the organisation’s systems or data, operates a system on its behalf or contributes to the delivery of an important service, supplier security must also be addressed.
The organisation should know what security requirements it imposes on suppliers, what access they have, what they must do in the event of an incident and what they are required to report.
In a smaller organisation, these rules can form part of another security policy. Where dependence on suppliers is greater, it may be practical to address them in a separate document. For organisations subject to NIS2, supply chain security is also one of the areas covered by cybersecurity risk management measures.
This Overview Is Not a Regulatory Minimum
The areas outlined above provide a practical way for a smaller organisation to get started. They are not a checklist that automatically ensures compliance with NIS2 or Slovak legislation.
For example, Decree No. 227/2025 Coll. issued by the Slovak National Security Authority (NBÚ) sets out more detailed requirements for security documentation applicable to operators of essential services. Under Section 4, these include an approved cybersecurity strategy and security policies, information classification, categorisation of ICT and OT, risk analysis together with an asset inventory, documentation of the scope and manner of implementation of security measures, and other specified documents.
Under the decree, the scope of general security measures is determined based on risk analysis.
If your organisation falls within the scope of the legislation, treat this overview of key areas as a way to organise your documentation, not as a substitute for the requirements of the decree. When combining documents, make sure that no mandatory elements are omitted.
A Template Is a Starting Point, Not a Finished Policy
There is no need to start every document from a blank page. A good template can provide structure and remind you of topics that should not be overlooked. However, it must be adapted to the specific organisation.
If a template describes roles, processes or security measures that do not actually exist in the organisation, keeping them in the document does not create better documentation. It simply creates a gap between what is written and what happens in practice.
A policy without records does not prove anything. If a policy states that access rights are reviewed, backups are tested and employees receive training, there should be evidence to support these activities – a review record, a recovery test result or a list of trained employees. During an audit or inspection, it is not only what is written that matters, but also what you can demonstrate is actually being done.
Before approving a security policy, ask yourself:
- Does the document have a clearly identified owner?
- Does management understand what it is approving and support it?
- Does it reflect how our organisation actually operates?
- Are responsibilities assigned to specific roles?
- Do the people affected by the policy know what they are expected to do?
- Will we be able to demonstrate that these rules are followed?
- Do we know when and by whom the document will be reviewed again?
If the answer to any of these questions is “no”, adding another policy is unlikely to solve the problem.
How Tazilla Helps with Security Documentation
Tazilla includes a Library of security documentation templates, so CISOs do not have to start from scratch for every topic.
The available templates cover individual areas in greater detail. However, this does not mean that every organisation must automatically adopt each template as a separate policy.
For someone new to the CISO role, it may be useful to look at them as follows:
| Key Area | Templates in the Tazilla Library |
|---|---|
| Security policy and governance | Security Policy; Information Security Organisation |
| Assets and risks | Asset, Threat and Risk Management |
| Access and operational security | Access Management; Operational Security Management; Network and ICT Security Management; Cryptographic Measures; Physical and Environmental Security; Security Monitoring, Testing and Audits |
| Incidents | Cybersecurity Incident Management |
| Business continuity and recovery | BCM Policy; Business Continuity Management; Business Continuity Plan (BCP); Disaster Recovery Plan (DRP) |
| Employee security rules | Rules of Conduct and Good Practice; Personnel Security |
| Suppliers | Supplier Services Management |
These key areas can help you navigate the templates available in the Library. Each organisation can select and adapt those it needs based on its operations, risks and obligations.
A template helps you get started. It becomes your organisation’s policy only when it reflects how your organisation actually operates.
Documentation Must Evolve with Your Organisation
A security policy should not remain unchanged for years simply because it was approved once.
A new system, supplier, change in responsibilities, security incident, audit or recovery test may reveal that certain rules are no longer valid or sufficient. Documentation should therefore be reviewed regularly and updated when necessary.
The requirement for security documentation to remain up to date and reflect the actual situation is also established in Slovak cybersecurity legislation.
This is where documentation connects with other parts of the Tazilla platform. Risks and security measures, incident records, business continuity and employee training provide information about whether established rules are working and where they need to change. Documentation therefore does not have to exist separately from day-to-day security management.
Conclusion
Good security documentation does not have to be extensive. However, it must reflect the organisation, its risks and its obligations.
If you are just getting started, focus first on the most important areas, clear responsibilities and rules that can realistically be followed. Add further documents where your organisation genuinely needs them or where its obligations require them.
The goal is not to have as many security policies as possible. It is to make sure that the policies you have describe what you actually do.