The information security policy (PSSI in French practice) is the first document requested in most control situations: an ISO 27001 certification audit, a customer security questionnaire, a due diligence. It is also the document most often produced the wrong way: a generic template downloaded, completed with the company name, approved once and then forgotten. This article sets out what the reference frameworks actually require of a security policy, what an auditor checks in it and why a policy must start from an assessment of the organisation, not from a template.
What the texts require
According to the ANSSI guide on drafting security policies (published in March 2004 by the DCSSI, the agency's predecessor, and still the French methodological reference), a security policy "reflects the strategic vision of the organisation's management regarding information systems security". It contains strategic elements (stakes, applicable reference framework, security needs, main threats) and applicable security rules. Two points of method matter for an SME: the document commits management, not the IT department, and it follows from a prior analysis of stakes and risks.
Clause 5.2 of ISO/IEC 27001:2022 states the same requirement in auditable terms. Top management must establish an information security policy that is appropriate to the purpose of the organisation, that contains security objectives or a framework for setting them, that includes a commitment to satisfy applicable requirements and a commitment to continual improvement. The policy must be available as documented information, communicated within the organisation and available to interested parties where relevant.
Control 5.1 of ISO/IEC 27002:2022 completes the picture: the general policy and the topic-specific policies (access control, backup, cryptography, incident management, secure development, among others) must be defined, approved by management, published, communicated to and acknowledged by the relevant personnel, and reviewed at planned intervals as well as when significant changes occur.
Why the generic template fails the audit
The generic Word template produces a document that satisfies the form and contradicts the substance. The inconsistencies are detectable by cross-reading, which is precisely how an auditor works. A policy that mandates workstation encryption when no workstation is encrypted creates a nonconformity the organisation inflicted on itself: the gap is not measured against the standard, but against what the organisation declared it does. A policy that mentions a "quarterly security committee" with no minutes, a CISO role that nobody holds, or tools the company does not use produces the same effect.
The second problem with the template is the absence of any link to the risks. In the logic of ISO 27001, the policy connects to the risk assessment (clause 6.1.2) and to the statement of applicability: the measures the policy imposes must correspond to the risks identified in the risk register and to the controls selected in the SoA. A document written before any assessment cannot show that consistency.
What an auditor checks in practice
The requirements above translate into control points. Is the document approved, dated and signed by management, with an identified version? Does the described scope match the real organisation (entities, sites, systems)? Are the policy's commitments borne out in fact: if it announces an annual review, is there a record of the last one; if it announces staff awareness, is there evidence of communication and acknowledgment? Do the topic-specific policies cover the domains relevant to the business, and only those? Finally, is the policy consistent with the risk assessment and the statement of applicability, or does it describe an organisation that does not exist?
None of these points concerns the length or elegance of the document. An auditor is not looking for a forty-page policy; they are looking for a short, accurate document that is approved, communicated, reviewed and connected to the rest of the management system.
A proportionate policy for an SME
For a structure of twenty to two hundred people, a usable security policy fits in a few pages: the stakes and the scope, the responsibilities (management, security representative, users), the commitments required by clause 5.2, and the reference to the topic-specific policies. Those only cover the domains where the company has real practices to govern. An SME with no software development does not need a secure development policy; writing one weakens the framework instead of strengthening it.
The order of operations follows from the above: assess first (scope, risks, state of the measures), write second. The policy formalises what the assessment established, setting rules the organisation is able to keep and improvement targets stated as such. This sequencing is the one in the ANSSI guide as well as in ISO 27001, where the policy (clause 5.2) builds on the context (clause 4) and feeds the risk treatment (clause 6).
Generating the policy from the assessment
This is how Komplyo works: the security policy and the associated documents are generated from the assessment answers, not from a static template. The rules restate the measures actually in place, the identified gaps become dated targets in the roadmap, and each control carries its CSF, ISO 27001, SOC 2 and GDPR correspondences derived from the mappings table. The resulting document describes the organisation as it is, which is exactly what an auditor checks. The free diagnostic (23 questions, around 5 minutes) gives a first reading of the practices this work builds on.