The information security policy is the first document an ISMS produces, and also the one written fastest and read least. Take a template, insert the company name, add the CEO's name and a date. One page. Publish it on the website and never touch it again for three years. Plenty of organisations treat it exactly that way.
As a formality, that sometimes passes audit. The problem is that the policy then does not do its job. A policy is the reference you return to when a treatment decision is contested, and the framework that sits above the security objectives of Clause 6.2. Questions like "does customer impact or internal convenience win here?" arise constantly. If the policy says nothing, every one of them is argued from scratch.
This article covers what the standard requires, how to split public and internal versions, and how the policy connects to objectives. For the planning detail see Clause 6: Planning; for the standard overall, What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
Why This Is Where People Get Stuck
1. Settling for a declaration
"Policy" suggests a statement of principle from the leadership, so the document fills with sentences like "we recognise information security as an important management issue and address it company-wide" — a document that decides nothing. A declaration is necessary, but on its own it does not do the policy's work.
2. Writing for publication
Writing with the website in mind rules out specifics. "Multi-factor authentication is mandatory" or "access to production patient data is prohibited by default" are too detailed to publish. The result is a document written at public-facing abstraction that is also supposed to guide internal decisions — and serves neither. Split the two versions.
3. Losing the connection to objectives (Clause 6.2)
The standard requires objectives to be consistent with the policy. If the policy is too abstract, consistency cannot be judged. Nothing logically connects "we value security" to "100% annual training completion." Write the policy as the framework objectives are derived from.
4. Never revised
The policy should be reviewed as the ISMS changes: scope widened, the nature of the data changed, a serious incident occurred. Unreflected, it drifts from reality.
What You Are Actually Deciding
| What the standard asks for | How to satisfy it in practice |
|---|---|
| Appropriate to the organisation's purpose | Reference your actual business and the nature of the information you hold; do not stop at template generalities |
| Provides a framework for setting objectives | State the priorities and principles objectives will be derived from |
| Commitment to satisfying applicable requirements | State compliance with law, regulation and contract |
| Commitment to continual improvement | State that the cycle keeps turning |
| Available as documented information | Maintain under version control |
| Communicated within the organisation | Readable by all workers, with a record of communication |
| Available to interested parties as appropriate | "As appropriate" — there is no duty to publish it in full |
That last point is the basis for splitting versions. The standard does not require full publication. So the detailed internal version can be authoritative while an extract or summary goes on the website.
Public version versus internal version
| Public | Internal (authoritative) | |
|---|---|---|
| Purpose | Show posture and structure to customers and users | Serve as the decision basis for workers |
| Length | About one page | Two to four pages, referencing subordinate procedures |
| Granularity | Principles and structure | Priorities, prohibitions, how exceptions work |
| Where it lives | Website | Intranet, document management system |
| Approval | Top management | Top management |
| Revision | On significant change | Reviewed annually at management review |
Things that belong in the internal version and not the public one:
- Which wins when customer data protection collides with internal convenience
- The rule and the exception conditions for access to production customer data
- Whether personally owned devices are permitted
- The rule on entering business information into generative AI services
- Whether suppliers may sub-contract
- Whether reporting or recovery takes priority during an incident
These are the contested questions. Settle them in the policy and teams stop re-arguing them. Put the other way round: what belongs in a policy is the organisation's position on the questions where judgement divides.
How to Do It
Step 1 — Collect the contested questions
Before writing, gather the points where internal judgement has divided or is likely to. Past incidents, near misses and questions from the floor are the raw material. Starting from a template without this step guarantees an abstract document.
Step 2 — Have top management take a position on each
This is the substance of policy writing: a decision-making exercise, not a drafting exercise. Questions that cannot be settled stay out of the policy and are handled in subordinate procedures.
Step 3 — Reflect the risk assessment
The policy is sometimes written before the assessment, sometimes after. The ideal order is a provisional version first, finalised after the assessment, so that the company-specific risks that surfaced are visible in the policy and consistency with objectives is easy to demonstrate. See How to Run a Risk Assessment and Risk Treatment Plans and Acceptance.
Step 4 — Write the internal version
A workable structure: purpose (referencing your business and data); scope (including which employment types are bound); basic principles (with your own priority ordering among confidentiality, integrity and availability made explicit); compliance obligations; roles and responsibilities; principles for contested decisions; setting and reviewing objectives; training; treatment of violations; continual improvement; revision history.
Sections three and six are the core. Without specificity there, the rest can be boilerplate.
Step 5 — Produce the public version
Extract principles and structure. Four things are needed: management commitment; scope (which business and services); basic principles (what is protected, what takes priority); and a statement of compliance with law, regulation and industry guidelines.
For a healthcare company, naming the three-ministry guidelines in that fourth item is worth doing. It changes how hospital customers read the document during vendor evaluation. See Three-Ministry Guidelines.
Step 6 — Communicate and record it
Communicate the policy to all workers and keep a record that you did. Noting "includes the policy briefing" in training records, or recording acknowledgement, both work. Auditors ask workers on the floor what the policy says, so the method and its record need designing. See Designing Security Awareness Training.
Step 7 — Link it to objectives (Clause 6.2)
| Policy statement | Objective derived | Metric and target |
|---|---|---|
| Confidentiality of entrusted medical information takes priority over internal efficiency | Bring access to production customer data under control | Uncontrolled accesses: 0 per quarter |
| Every worker understands their own responsibility | All workers complete annual training | Completion rate: 100% by year end |
| Suppliers are held to an equivalent standard | Complete annual supplier reviews | Review completion: 100% |
| Incidents are reported promptly and never concealed | Shorten detection-to-response time | Mean time: within 4 hours |
| Availability required for business continuity is maintained | Verify recoverability from backups | Restore test: annually, with a record |
Whether you can build this table is the test of a policy's specificity. If the left column can only say "we value security," the policy is too abstract. See Setting Security Objectives and KPIs.
Where It Goes Wrong
So abstract it decides nothing — the most common failure.
| Decides nothing | Guides a decision |
|---|---|
| We recognise information security as an important management issue | For medical information entrusted to us by customers, confidentiality takes priority over internal operational efficiency |
| We apply appropriate access management | Access to production customer data is prohibited by default; exceptions require request, approval, a time limit and a record |
| We provide employee training | Every worker must complete annual security training; non-completion is treated as an employment matter |
| We manage suppliers appropriately | Suppliers handling medical information are contractually held to our own standard, and undisclosed sub-contracting is prohibited |
| We respond appropriately to incidents | Suspected incidents are reported immediately, even without confirmation; no adverse treatment follows from reporting |
| We comply with laws | We maintain conformity with the personal information law and the MHLW guidelines for safe management of medical information systems |
What the right column shares: a reader can change their behaviour because of it.
No split between public and internal. One document covering both drifts to publishable abstraction and stops working internally.
No references to subordinate procedures. Trying to say everything in the policy makes it long and unread. State principles; delegate detail. See ISMS Document Structure.
No named approver, or a stale date. The policy is approved by top management; a missing approver or a date several years old invites a finding on its own.
Template generalities with no mention of your business. The standard requires appropriateness to the organisation's purpose. One line naming the nature of the information you hold changes this substantially.
No record of communication. The document exists but nobody can show workers read it. Auditors ask the workers.
Consistency with objectives cannot be explained. Build the step 7 table and the audit answer is already written.
Healthcare Examples
A SaaS provider for healthcare institutions
The distinctive sentence for section three is the priority ordering among confidentiality, integrity and availability. Confidentiality is not automatically first here: if the system stops during clinic hours, care stops, so availability loss reaches patients directly. Wording such as "both the availability required for continuity of clinical work and the confidentiality of patient information are treated as top operational priorities" stabilises later treatment decisions.
Section six must cover the production-data access rule — the most contested question, and where a stated position pays off most.
A PHR operator
Because data is entrusted by individuals, stating at policy level that data will not be used beyond the scope of consent is effective. It overlaps the personal information law, so draft the wording jointly with legal. See ISMS for PHR Operators.
A clinical trial systems company
Integrity has to sit alongside confidentiality at the top. "Data integrity and preservation of the audit trail are among the highest operational priorities" is the sentence that justifies defining integrity as its own axis in the risk scale.
A SaMD developer
The security policy coexists with the quality policy (ISO 13485). Referencing the relationship inside the policy keeps the dual system tractable: "this policy governs protection of information assets; matters of product safety and effectiveness follow the quality policy and related procedures." See SaMD, ISMS and QMS.
Common ground: one sentence for the public version
Hospital customers actually read supplier policies. A sentence committing to conformity with the MHLW guidelines for safe management of medical information systems shortens procurement conversations. See Implementation Steps and Cloud Security for Healthcare Institutions.
Conclusion
- A policy is not a declaration but the reference for contested decisions. The real work is deciding, not drafting
- Split the public and internal versions. The standard does not require full publication
- What belongs in it is the organisation's position on the questions where judgement divides — production data access, BYOD, generative AI, sub-contracting
- "We value security" decides nothing. Replace it with statements that change behaviour
- Objectives must be derivable from the policy. If you cannot build the linkage table, the policy is too abstract
- Keep top management approval, a record of communication, and an annual review
From the policy, derive objectives in Setting Security Objectives and KPIs and build out procedures via ISMS Document Structure. The prerequisite is Defining the Scope of Your ISMS.
Pottech supports ISMS certification with a focus on healthcare — templates, plus help surfacing the contested questions and drafting the healthcare-specific clauses. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee (JISC)
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Personal Information Protection Commission, Japan
Note: interpretation of requirements and the handling of accreditation and certification are governed by the standard itself and by the publications of the accreditation and certification bodies, and may change with revisions.