Every serious cybersecurity framework starts with the same document: a written, management-approved information security policy (ISSP). NIS2 lists it first among the risk-management measures of Article 21, and ISO/IEC 27001 makes it a requirement of clause 5.2. Security Policy Express walks a European SME through a guided online workshop and generates a structured first version in its own name: a working draft for your advisers to review, not legal advice.
The one-minute answer, for a managing director who is not an IT specialist.
An information security policy (often abbreviated ISSP, or PSSI in French) is the document in which your management states, in writing, how the company protects its information and IT systems, who is responsible for what, and which rules everyone must follow. It is short at the top (a policy statement signed by management) and more detailed underneath (topic-specific rules and operational procedures). It is not a technical manual: it is a management decision, put on paper, that the rest of your security work can refer to.
ISO/IEC 27001 assigns the policy to "top management", and NIS2 Article 20 asks the management bodies of in-scope entities to approve the cybersecurity risk-management measures and oversee their implementation. Your IT provider can help write it; only your management can own it.
Sources: Directive (EU) 2022/2555, art. 20 · ISO/IEC 27001:2022, clause 5Good practice distinguishes three layers. The policy states principles and responsibilities. Topic-specific policies (access control, backup, cryptography, suppliers...) translate them per domain. Procedures describe who does what, step by step, when something happens. ISO/IEC 27001 control 5.1 explicitly mentions both the policy and topic-specific policies.
Source: ISO/IEC 27001:2022, Annex A, control 5.1No European text imposes a single template. NIS2 Article 21(1) asks for measures that are "appropriate and proportionate", taking into account the entity's exposure to risks, its size, and the likelihood and severity of incidents. A 40-person manufacturer and a hospital will not write the same policy, and should not.
Source: Directive (EU) 2022/2555, art. 21(1)A policy written once and filed away protects nothing. Frameworks expect it to be communicated to staff, acknowledged, and reviewed at planned intervals and after significant changes. That is why your policy should include its own review cycle, owner and version history from day one.
Source: ISO/IEC 27001:2022, clause 5.2 and control 5.1Most small and mid-sized companies already apply some security rules. What is usually missing is the written, approved, coherent version that a regulator, an auditor, an insurer or a large customer can actually read.
NIS2 extends EU cybersecurity rules to many medium-sized companies in sectors such as manufacturing, food, waste management, transport or digital services. For in-scope entities, "policies on risk analysis and information system security" are the first measure listed in Article 21(2).
NIS2 Article 21(2)(d) requires in-scope entities to address supply chain security, including security-related aspects of their relationships with direct suppliers. Even if you are outside the scope, your larger customers may ask you to show a written security policy in their supplier questionnaires.
Writing a policy means answering many questions at once: what are our critical assets, who decides, what do we do in case of a ransomware attack, how long do we keep backups? Without a structure, the exercise tends to be postponed, quarter after quarter.
Downloaded templates often describe an organisation with a security officer, a security operations centre and a dedicated budget. A document that does not match reality is worse than none: it will not be applied, and an auditor will notice the gap between paper and practice.
The same document answers several texts at once. Here is what each one actually says, with a link to the official source. Each reference links to the official source; national transpositions may add details.
Essential and important entities must take "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks, based on an all-hazards approach. The list in Article 21(2) opens with "(a) policies on risk analysis and information system security". Article 20 adds that management bodies approve these measures, oversee their implementation and follow training.
Clause 5.2 requires top management to establish an information security policy that is appropriate to the organisation's purpose, provides a framework for security objectives, and includes commitments to satisfy applicable requirements and to continual improvement. It must be documented, communicated internally and made available to interested parties as appropriate. Annex A control 5.1 extends this to topic-specific policies, approved, published, acknowledged and reviewed.
Article 24(2) states that, where proportionate to the processing activities, the controller's measures include "the implementation of appropriate data protection policies". Article 32 requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk. A security policy is the natural place to document those measures.
For certain digital entities (for example cloud computing, data centre and managed service providers), the Commission adopted detailed technical and methodological requirements. Its annex opens with a "policy on the security of network and information systems" and describes how it is approved, documented and reviewed. Even if your company is not one of these entity types, the annex is a useful, public reference for structuring a policy.
For financial entities, DORA requires them to develop and document an information security policy defining rules to protect the availability, authenticity, integrity and confidentiality of data, information assets and ICT assets. If you are an ICT supplier to a bank or an insurer, expect your customer to ask how your own policy compares.
National cybersecurity agencies publish free guidance that a policy can build on. In France, the ANSSI guide to IT hygiene sets out 42 essential measures for those responsible for an organisation's information system security. ENISA, the EU Agency for Cybersecurity, publishes guidance supporting NIS2 implementation across the Union.
Article 21(2) of NIS2 lists ten minimum measures. Point (a) is the policy itself, but a well-built policy is also where the other nine find their owner, their rule and their procedure. This is how we structure the generated document.
The policy statement, the scope, the roles, and the method you use to identify and rate risks. This is the backbone of the document.
An incident management procedure: detection, qualification, escalation, containment, notification and lessons learned.
Backup management, disaster recovery and crisis management, as the directive words it: who decides, what restarts first, how often backups are tested.
Rules for choosing, contracting and monitoring IT suppliers and service providers, including the security clauses you expect from them.
How new systems are chosen and configured, how updates are applied, and how vulnerabilities are handled and disclosed.
Policies and procedures to check that measures work: indicators, internal reviews, exercises, and management review.
The everyday rules (passwords, updates, phishing awareness) and a training plan, including for management, as Article 20(2) requires for management bodies.
When data must be encrypted (laptops, backups, transfers), which protocols are acceptable, and who manages keys.
Joiners, movers and leavers; who gets which access and who approves it; an inventory of assets with their owners.
Where multi-factor or continuous authentication is required, and how voice, video, text and emergency communications are secured.
The ISO/IEC 27001 references are indicative correspondences drawn up by us to help you navigate, not an official mapping published by ISO or the European Commission. Source for the ten measures: Directive (EU) 2022/2555, art. 21(2).
The generated document follows a structure that an auditor, an insurer or a customer will recognise. Each chapter is filled from the answers you give in the workshop, so that it describes your company, not a fictional one.
The commitment of management, in a few paragraphs, signed and dated.
Who decides, who implements, who checks, including when IT is outsourced.
A simple, repeatable way to identify, rate and treat risks.
Knowing what you protect before deciding how.
Who can access what, and how this is proven.
The technical baseline, written in plain language.
Where encryption is required and how it is managed.
Security in your relationships with IT providers and cloud services.
The human side, from hiring to departure.
Premises, server rooms and equipment outside the office.
The principles, detailed in the procedures below.
How the policy stays alive and true.
A policy says what must happen; a procedure says who does it, in which order, and with which record. These four are the ones customers and auditors most often ask to see, and the ones that matter most on the day something goes wrong.
From the first alert to the closing report: how staff report a suspicious event, who qualifies it, who isolates the affected systems, who contacts your IT provider, your insurer and the authorities, and how evidence is preserved.
How an account is requested, approved, created, modified and removed. The procedure covers arrivals, changes of role and departures, administrator accounts, shared and service accounts, and the periodic review where a manager confirms that each person still needs the access they have.
How a change to a production system (a new application, a firewall rule, a major update) is described, assessed for risk, approved, tested, carried out and, if needed, rolled back. In a small company this can be light: a short form and a log are enough, provided they exist and are used.
What is backed up, how often, where, for how long, and above all how restoration is tested. The procedure links backups to recovery objectives per critical activity and describes the crisis organisation: who decides, who communicates, which systems restart first.
The policy is written for management and IT. The acceptable use policy (AUP) is written for everyone else: the short, readable set of rules that each employee, temp or contractor accepts before using the company's IT.
Use of accounts and passwords, email and messaging, internet access, personal use tolerated or not, mobile devices and remote work, removable media, cloud services and generative AI tools, confidentiality, reporting of incidents, and what the company may monitor and why.
ISO/IEC 27001 control 5.10 asks for rules for the acceptable use of information and other associated assets to be identified, documented and implemented. Keeping these rules in a separate annex makes them easier to read, sign, update and attach to employment documents.
When the AUP mentions logging or monitoring of staff activity, data protection law applies: employees must be informed (GDPR art. 13), and Member States may adopt more specific rules for employment contexts (GDPR art. 88). Data protection authorities such as the CNIL publish guidance on what is acceptable.
Making the AUP binding on employees may require national formalities. In France, for instance (to be confirmed with your adviser against the Labour Code), rules of this kind are commonly annexed to the internal rules (règlement intérieur), which follow a procedure set by the Labour Code, including consultation of staff representatives. Check the rules of your country with your adviser.
Sources: ISO/IEC 27001:2022, A.5.10 · Regulation (EU) 2016/679, arts. 13, 88 · CNIL · Légifrance, French Labour Code, arts. L1321-4 and L1321-5.
A policy describes a company that changes: new staff, new software, new suppliers, new threats. The frameworks we cite generally expect it to be kept up to date. The generated document includes its own review calendar, owner and version table.
The first version is approved by management, dated and versioned. Under NIS2 art. 20(1), management bodies of in-scope entities approve the cybersecurity risk-management measures; under ISO/IEC 27001 clause 5.2, top management establishes the policy.
The policy is published internally; the acceptable use policy is acknowledged by each user. ISO/IEC 27001 control 5.1 expects policies to be communicated to and acknowledged by relevant personnel and interested parties.
ISO/IEC 27001 control 5.1 asks for review at planned intervals and if significant changes occur. An annual review is a sensible default for an SME; Implementing Regulation (EU) 2024/2690 also frames the review of the policy for the digital entity types it covers.
A serious incident, a merger, a new site, a move to the cloud or a new regulation are all reasons to reopen the document without waiting for the anniversary date. The lessons learned from incidents feed the next version.
Version table, approval record, list of changes, acknowledgements. On the day an auditor, an insurer or a customer asks, this history is what shows that the policy is applied and not merely written. ISO/IEC 27001 clause 7.5 governs this documented information.
Security Policy Express is designed as a self-service tool. You keep control of the content; the tool provides the structure, the questions and the references.
A short test asks about your sector, size, activities and customers, and tells you whether NIS2 is likely to apply to you, which other texts may be relevant, and which parts of the policy matter most in your situation. It points you to the official tools of your national authority for a definitive answer.
You answer, in your own words, a series of guided questions chapter by chapter: your organisation, your critical activities, your IT provider, your backups, how you handle departures, what you would do in case of ransomware. Each question explains why it is asked and which article or control it relates to. You can stop and resume at any time.
The tool generates the policy, the four procedures and the acceptable use annex in your company's name, from your answers. Where an answer is missing, the document says so explicitly instead of filling the gap with generic text. The result is a working draft, to be reviewed and validated by your own advisers (lawyer, IT provider, data protection officer) before approval by management.
If you want help to challenge your answers, adapt the document to a specific context or prepare an audit, you can ask for support from a partner consultant. This step is optional: the self-service path is complete without it.
Important: the generated document is a working basis. It does not constitute legal advice, and it does not by itself make your company compliant with NIS2, ISO/IEC 27001, the GDPR or any national law. Compliance depends on what you actually implement, and remains your responsibility.
Three building blocks, generated together from the same workshop. Availability and terms will be announced at launch.
The core document, signed by management.
What makes the policy operational.
To find your way in the texts.
Two situations must not be confused: a legal obligation for companies within the scope of NIS2 (or DORA), and a strongly recommended good practice for everyone else.
NIS2 generally applies to public or private entities of a type listed in its Annex I or II that qualify as medium-sized enterprises or exceed the ceilings for medium-sized enterprises, as defined in Commission Recommendation 2003/361/EC (art. 2(1)). Some entity types are covered regardless of size (art. 2(2)). Entities are then classified as "essential" or "important" (art. 3), which affects supervision and sanctions, but both must apply Article 21.
Annex I (sectors of high criticality): energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management (business-to-business), public administration and space. Annex II (other critical sectors): postal and courier services, waste management, chemicals, food, manufacturing (including medical devices, electronics, electrical equipment, machinery and vehicles), digital providers and research.
NIS2 is a directive: Member States had to transpose it by 17 October 2024 and apply the measures from 18 October 2024 (art. 41). Transposition status and details differ from one country to another, and national law may specify the content of the measures. Always check the law and the official eligibility tools of your country.
Outside these scopes, no general European law requires an SME to adopt a document called "information security policy". But the GDPR applies to almost every company, customers increasingly ask suppliers about security, and a written policy is the first step of any recognised framework. It is a choice of prudence, not a legal sanction.
Sources: Directive (EU) 2022/2555, arts. 2, 3, 41 and Annexes I and II · Commission Recommendation 2003/361/EC · European Commission, NIS2 Directive page · France: ANSSI, NIS 2 page (MesServicesCyber).
Every regulatory or normative statement above refers to one of these sources. Links point to the official publisher.
This page is provided for information. It does not constitute legal advice. Texts are cited in their version published on EUR-Lex; national transpositions and authority guidance may add requirements.
The self-service workshop is in preparation. Questions in the meantime: contact@syaga.eu.