How to write an information security policy

An information security policy is the reference document, approved by senior management, that sets an organisation's security objectives, organisation and rules. It derives from risk analysis and applicable obligations, and is then broken down into topic-specific policies and procedures that everyone can apply.

In France it is called a PSSI (politique de sécurité des systèmes d'information). This guide gives you a template outline detailed chapter by chapter, reviews the official French references and proposes a seven-step drafting method, all the way to the annual review.

An information security policy answers three questions: what are we protecting and why (stakes, security needs), who is responsible for what (organisation), and which rules apply (principles and requirements). It covers the whole information system, including people, premises, suppliers and cloud services, not just servers.

It is neither a technical procedure nor an acceptable use policy. It is the top-level document: it sets the direction, and more operational documents explain how. In an ISO 27001 information security management system, it is the information security policy required by the standard, supplemented by topic-specific policies.

A well-written policy delivers three very practical benefits:

• Alignment of management, IT and business units on a chosen level of security, instead of case-by-case decisions;
• An enforceable basis for rules: you cannot require multi-factor authentication or refuse a cloud service without an approved policy;
• Proof for auditors, customers, insurers and authorities that security is managed.

Several texts also expect one:

• ISO 27001 requires top management to establish an information security policy (clause 5.2), and Annex A provides for topic-specific policies (control 5.1).
• NIS 2: Article 21 of Directive (EU) 2022/2555 lists "policies on risk analysis and information system security" first, and Article 20 requires management bodies to approve the measures.
• GDPR: Articles 24 and 32 of the regulation require appropriate technical and organisational measures, including data protection policies where proportionate.
• French public sector: government bodies apply the state policy, PSSIE (see section 4).
• French healthcare: for CaRE programme funding, the national digital health agency lists "a security policy" among the prerequisites, with the policy document to be provided (February 2026 webinar).

There is no mandatory outline, but solid policies share the same structure: a governance foundation, then rules by domain, then control and review arrangements. The template below follows that logic and the themes of ISO 27002:2022, which makes mapping to an ISO 27001 audit easier. Expand each chapter to see what it should contain.

Adapt this outline to your size: an SME will merge several chapters, a group will point each domain to a topic-specific policy. The golden rule stays the same: every requirement must be verifiable. "Passwords must be strong" cannot be checked; "multi-factor authentication is mandatory for all remote access and all administrator accounts" can.

ANSSI's policy drafting guide

The French reference guide was published in March 2004 by DCSSI, which became ANSSI in 2009. It proposes a four-phase method (preparation, strategic elements, choice of security principles, finalisation and approval) and a catalogue of security principles by domain. It is still listed among the resources on ANSSI's security rules page, but has not been updated since: the method remains sound, the technical references have aged. For controls, supplement it with ISO 27002:2022 (93 controls in four themes) and ANSSI's IT hygiene guide (42 measures).

PSSIE, the French state's security policy

The PSSIE was introduced by the Prime Minister's circular no. 5725/SG of 17 July 2014. It applies to ministries and their public bodies, which adapt it into their own ministerial policy. ANSSI now presents a digital security governance framework for the state that is meant to replace the 2014 circular eventually; until then, both coexist, particularly for security rules.

PGSSI-S for healthcare

In the French health and social care sector, the general information system security policy for healthcare (PGSSI-S), published by the national digital health agency, provides a body of frameworks and guides. Some frameworks are made binding by ministerial order, others are recommendations. The PGSSI-S sets the sector framework; each facility's own policy sets its organisation and rules.

Writing a policy is not a writing exercise: it is a project, with a sponsor, contributors and a timeline. Here is the approach we recommend, inspired by ANSSI's method and the ISO 27001 continual improvement cycle.

1. Frame the project. Appoint a sponsor in senior management and a lead, often the CISO. Set the scope (whole organisation, a subsidiary, a site) and the contributors: IT, DPO, legal, HR, procurement, business units.
2. Take stock. List obligations (NIS 2, GDPR, contracts, sector frameworks), existing documents and actual practices.
3. Analyse the risks. Identify business assets, their availability, integrity, confidentiality and traceability needs and feared scenarios. A risk analysis, for example with the EBIOS Risk Manager method, provides the rationale for each rule.
4. Set objectives and principles. Turn risks into security objectives, then principles by domain, using the template above.
5. Write verifiable rules. For each rule: who it applies to, what is expected, who is responsible and how it is checked.
6. Get management approval. Present the policy to the executive committee, with the resources required and the residual risks. Management's signature gives the document its authority.
7. Publish, apply and check. Publish the policy, break it down into an acceptable use policy and procedures, raise awareness, then measure compliance and schedule the review.

A policy that tries to say everything becomes unreadable. Good practice is to organise documentation as a pyramid, which the CNIL also recommends for data protection policies: a management document, broken down into topic-specific policies and then procedures.

• The top-level policy: objectives, organisation, main principles. Approved by senior management.
• Topic-specific policies: access control, backup, vulnerability management, remote working, supplier relationships, secure development. Approved by the security committee.
• Procedures and work instructions: how to create an account, how to restore a backup. Owned by the teams.
• The acceptable use policy: rules for users, in their language. ANSSI's guide to IT acceptable use charters points out that, in France, it must be accepted by users or annexed to the internal regulations, after consulting staff representatives, before it can be enforced.

Supplier requirements deserve special attention: they feed your contracts, security assurance plans and third-party risk questionnaires.

A policy is only useful if it is applied and kept up to date. Three mechanisms help.

Reviews

Plan at least an annual review. The CNIL also recommends at least an annual management review of security, to take stock and decide on resources. Trigger a revision after a major incident, a reorganisation, a merger, a regulatory change or a significant change to the information system. Each version should be dated, approved and archived.

Exceptions

There will always be a business application that cannot meet a rule. Rather than turning a blind eye, formalise the exception: rule concerned, justification, risk accepted by a named owner, compensating measures and expiry date.

Indicators

Measure how a few key rules are applied: share of administrator accounts protected by multi-factor authentication, time to fix critical vulnerabilities, success rate of restore tests, share of critical suppliers assessed. These indicators feed the security committee and the review.

• Copying a template without adapting it: a sample policy found online knows nothing of your risks or constraints. Auditors notice quickly.
• Writing unverifiable rules: "secure", "ensure", "where possible".
• Leaving out senior management: a policy signed only by IT does not bind business units.
• Putting everything in one document: a hundred pages of technical detail nobody reads.
• Neglecting suppliers and the cloud: much of the information system is now run by third parties.
• Never revising it: a 2019 policy ignores widespread remote working, NIS 2 and the use of AI.

The signed document remains essential. But to know whether the policy is applied, you need to turn its rules into requirements that can be assessed site by site or subsidiary by subsidiary, and track gaps in an action plan. That is the point of a governance, risk and compliance approach.

In Phinasoft, the policies editor lets you bring in your security policy: you define your security objectives, enter its structure and import your requirements, then enrich each requirement (links to other frameworks such as ISO 27001 or NIS 2, expected evidence). These requirements are then used to launch compliance campaigns or questionnaires, and successive versions of your policy are kept for your reviews. To see how your own policy would fit, you can request a demo.