How to write an Information Security Policy (ISSP)?

ANSSI, the French cybersecurity agency, defines the Information Security Policy as the document that formalizes, at management level, the rules, responsibilities and security measures applicable to an organization's information system. Its own ISSP guide stresses a point often overlooked: a policy only has value if it reflects an observed reality. An ISSP copied from a generic template, without a prior assessment, will not withstand an audit or a real incident.

What is an ISSP, concretely?

An ISSP is not an isolated technical document. It is the expression, at management level, of the security requirements the organization imposes on itself, later broken down into operational procedures: access management, backups, incident response. It serves as a shared reference for internal teams, vendors and, where relevant, auditors or cyber insurers, who increasingly ask to review it before agreeing to cover a claim.

The steps to write an ISSP

1. Carry out a factual assessment of the current state: infrastructure, access management, backups, monitoring, past incidents.
2. Identify critical assets (data, applications, infrastructure) and the risks associated with each.
3. Define security rules and objectives per domain, consistent with the identified risks: no rule should be set without an operational justification.
4. Assign responsibilities (who decides, who applies, who checks) and have the policy validated by management.
5. Translate the ISSP into operational procedures and tracking indicators.
6. Review the ISSP at regular intervals and after any significant change (new tool, incident, headcount growth).

The domains an ISSP must cover

What auditors and cyber insurers actually check

More and more cyber insurers ask to review the ISSP, or failing that a detailed questionnaire covering the same ground, before issuing a policy or covering a claim. In both cases, what gets checked is never the form of the document but the consistency between what it states and what is actually in place: an ISO 27001 auditor will systematically ask for evidence (log extracts, access review tickets, security committee minutes), not just a signed policy. An ISSP that claims a quarterly access review with no trace of any review having taken place is an immediate red flag, often more damaging than a more modest policy that is fully followed.

Connecting the ISSP to ISO 27001 and NIS2

The ISSP is not a standalone exercise: it is the cornerstone of the information security management system (ISMS) required by ISO 27001, and largely overlaps with the ten domains of minimum measures imposed by the EU NIS2 directive (risk management, incident management, business continuity, supply chain security, among others). A company that drafts its ISSP with both frameworks in mind avoids having to rebuild it from scratch if it later pursues certification or falls within NIS2 scope.

Best practices for a living ISSP

• Limit the first version to what is genuinely achievable within 90 days, rather than aiming for completeness from the start.
• Attach a measurable indicator to each important rule (MFA coverage rate, average access revocation time) to make its application verifiable.
• Plan a formal annual review, in addition to reviews triggered by a significant change.
• Publish a version accessible to non-technical teams, alongside the full version intended for auditors.

Common mistakes to avoid

• Writing the ISSP without a prior assessment, by copying a template found online.
• Setting rules too strict to actually be followed day to day.
• Never reviewing the ISSP after its first publication.
• Not involving operational teams in drafting it, which produces a theoretical document disconnected from reality.
• Stating controls in the document without keeping any evidence that they are actually applied.

An ISSP, however well written, does not protect anything by itself: it sets a framework, not a shield. Its value comes from how consistently it is applied and reviewed, far more than from the quality of the writing. A domain by domain assessment, backed by evidence, remains the best starting point to draft a realistic, enforceable version, rather than a style exercise that will not survive the first incident.