Almost nobody writes ISMS procedures from scratch. You start from a template — from a consultancy, a book, or a certification body's guidance material. That is reasonable, and it genuinely helps you avoid gaps against the standard's requirements.
The problem is what happens when the template is adopted unchanged. Stage 1 passes, because the documents are coherent on paper. At stage 2, though, the auditor turns to the person who does the work and says: "Your procedure says this inventory is performed monthly — could I see the last three months of records?" If the records are not there, the finding is not against the standard. It is a finding that you are not following your own rules — harder to explain and slower to correct.
This article turns template adaptation into a procedure: where it surfaces, what criteria justify cutting a clause, and how to apply the principle of never writing a rule you cannot keep. For the surrounding architecture see ISMS Document Architecture; for the standard as a whole, 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 Trips People Up
Templates are written for the widest case, erring on the strict side
Template authors do not know who will use them, so they assume an IT department, a server room, a development team, entry logs. And because they want to avoid users being told something is missing, templates are often stricter than the standard requires — an inspection that would be fine quarterly is written as monthly.
That bias is correct design for a template. It is built on the assumption that cutting is the user's job. But cutting requires knowledge of the standard, so many organisations adopt without cutting.
Fear that cutting will fail the audit
This is the main psychological obstacle, and it has the truth backwards. Written but not done is worse than not written. A control the standard never required, written into your procedure and then ignored, becomes evidence that your management system does not function.
Reading the template before writing down how you actually work
Read the template first and its framework pulls you into "maybe we should do it that way too." Reverse the order — write your current practice first, then compare against the template — and the differences become explicit and the decisions easy.
Ignoring what the verb form commits you to
Templates mix "shall," "must," "is to," "should" and "may." At audit, anything written as an obligation is checked as an obligation. "Should" left undone is not automatically a nonconformity; "shall" means records will be requested. Adopting without noticing the distinction means taking on obligations you never intended.
Proper nouns and numbers left in place
Example department names, system names, frequencies and retention periods survive into the final document remarkably often — and they are the first thing an auditor looks for. The moment a department you do not have appears in a procedure, the document is visibly unadapted.
What You Have to Decide
Sort every clause into keep / rewrite / cut.
| Category | Condition | Example |
|---|---|---|
| Keep | Explicitly required by the standard and matching your practice | "The information security policy is approved by top management" |
| Rewrite | The intent is needed but frequency, role, scope or method differ | "monthly" → "quarterly"; "IT department manager" → "head of the responsible department" |
| Cut | The event, asset or activity does not exist in your organisation | Detailed secure-coding clauses in an organisation that does no in-house development |
Always check cuts against the SoA. Deleting the clause for a control you marked applicable leaves nothing to demonstrate its implementation. Conversely, clauses covering controls you excluded have no reason to remain. See Writing the Statement of Applicability.
The principle: never write a rule you cannot keep.
Ask three questions of each clause:
- Can we do this starting next week? If not, rewrite to a level you can sustain, or leave it out until you can
- Will there be evidence? A clause that produces no record cannot be demonstrated at audit. Design the form before keeping the clause
- Will it survive a change of personnel? A clause that depends on one person's habits becomes a nonconformity the day they leave
Things you want but cannot yet sustain belong in the risk treatment plan or the security objectives, not in a procedure. "Introduce automated log monitoring during FY2027" is managed as an objective and promoted into the procedure once delivered. See Setting Security Objectives and KPIs.
Fix a rule for verb forms. Using only two — obligation and discretion — and banning "should" from procedures is the easiest architecture to manage. Anything merely advisable belongs in a work instruction or guide.
How to Do It
Step 1: Write down current practice before opening the template
List what you already do: joiner and leaver steps, account provisioning and removal, backups, device issue, supplier contracts, who gets called during an incident. You almost certainly already do more than you are about to start doing, and this list becomes the raw material for the procedures.
Step 2: Classify every template clause
Number the clauses and mark each keep / rewrite / cut, with a reason for the latter two. That list is your answer sheet when an auditor asks why a clause is absent. Keep it.
Step 3: Adapt frequencies, roles and scope
| Typical template wording | What goes wrong | Direction of rewrite |
|---|---|---|
| "The IT department manager performs a monthly access rights review" | No such department; not done monthly | "The head of the department responsible for information systems performs a quarterly access rights review" |
| "Retain server room entry records" | No server room — everything is cloud | Cut; move to supplier management as a cloud provider control |
| "Affix a classification label to every information asset" | You cannot put a physical label on a file | "Record classification in the asset register and state it on documents" |
| "Passwords are changed every 90 days" | No forced rotation in reality | Match reality; state the compensating control (MFA) instead |
| "External vulnerability assessment twice a year" | No budget; not performed | Reduce to a sustainable frequency, or move to objectives and promote once delivered |
| "Training is delivered as classroom sessions" | Actually e-learning and video | "Training is delivered by classroom session, e-learning or equivalent means" |
| "Confidential material is stored in a lockable cabinet" | You hold no paper confidential material | State that you hold none and simplify or cut |
Step 4: Replace proper nouns with roles
Rewrite "Microsoft 365," "IT Department," "Manager Yamada" as roles. Where a tool or person genuinely must be named, put it in an annex or work instruction and have the procedure say "as set out in Annex 1." A tool change then only touches the annex.
Step 5: Have the people who do the work read it
Review should sit with the person who performs the clause daily, not the ISMS secretariat that wrote it. "We don't actually do that" is the single most valuable piece of feedback available. Skip this step and divergence is close to certain.
Step 6: Build the form alongside the clause
Whenever you decide to keep a clause, decide in the same moment which form records its execution. A clause with no form produces no evidence. And if designing the form reveals the record is too heavy, that is a reason to revisit the clause.
Step 7: Keep the diff
A list of departures from the template lets next year's reviewers understand why things are as they are. When people change, that context disappears and the document drifts back toward the original template.
Where It Goes Wrong
Not knowing how templates surface
Auditors reconcile documents against reality for a living, and the routes are predictable.
| What the auditor does | What an unadapted template produces |
|---|---|
| Asks for records at the stated frequency | Only one or two months of a "monthly" record exist |
| Asks to speak to someone in a named department | The department does not exist |
| Asks floor staff about terms used in the procedure | They do not know the term, or have never read the procedure |
| Compares the procedure's form against real records | The form is unused; work happens in a different spreadsheet |
| Looks for clauses covering excluded controls | They were never deleted; SoA and procedure contradict |
| Checks the revision history | Still at first issue, dated during the certification project |
| Compares the same rule across several procedures | Frequencies, retention periods and owners disagree |
Believing that stricter wording is safer
The opposite. A procedure is a rule you imposed on yourself; failing it is evidence the management system is not working. For the recurring patterns, see Common Nonconformities.
No record of why a clause was cut
Asked "why is there no clear-desk clause," answering "we removed it from the template" leaves the auditor unable to distinguish a decision from an omission. A one-line reason in the classification list answers the question.
Mixing several templates
Stitching a consultancy's pack, a book's examples and a procedure inherited from another company leaves the terminology inconsistent — "information asset," "information system" and "critical information" coexisting undefined. Define terms in one place and use them consistently across every procedure.
A template written for a different size of organisation
Enterprise templates bring committees, subcommittees, a secretariat and departmental champions. Adopt that at twenty people and one person holds four roles, which destroys internal audit independence. See ISMS in a Small Organisation.
Your own strengths disappear from the documents
Easy to overlook: adopting a template verbatim means the genuinely good controls you already operate never appear. Mandatory security review in code review; every production data access announced in Slack. None of that is in a template. Writing it in and recording it turns it into an asset at audit and in customer conversations alike.
"We'll fix it later"
Submitting the template unchanged because time is short, intending to revise after certification, essentially never happens. Finish adaptation before stage 1. For the project timeline, see How Long ISMS Certification Takes.
Healthcare Examples
A healthcare SaaS provider
Generic templates contain nothing about controls over handling production patient data — investigation access, data corrections, migrations. You write those clauses yourself. Conversely, the template's detailed server-room, entry-control and media-handling clauses mostly do not apply in a fully cloud-hosted estate and belong in supplier management as provider-side controls. See also Cloud Security for Healthcare Institutions.
Equally: do not absorb every hospital customer's requirement into the corporate procedures. A specific contractual condition written company-wide binds you to every other customer as well. Handle specifics in contract management.
A PHR operator
Consent acquisition and withdrawal clauses do not exist in templates; you write them. Meanwhile the template's personal-data clauses tend to paraphrase the statute and need grounding in your actual data flows to function. See ISMS for PHR Operators.
A SaMD developer
With ISO 13485 documents already in place, adding template procedures wholesale produces the worst outcome: the same subject written two different ways in two systems. For training, document control, internal audit and corrective action, adapt by adding information security requirements to the existing QMS documents. See SaMD, ISMS and ISO 13485.
A contract developer or maintainer for hospitals
The safeguards the three-ministry guidelines expect are absent from generic ISMS templates. Clauses for remote maintenance connection procedure, work records and responsibility demarcation must be added. See The Three-Ministry Guidelines and Integrating ISMS Documents with the Three-Ministry Guidelines.
Conclusion
- Templates are written for the widest case and on the strict side, on the assumption that the user does the cutting
- Written but not done is worse than not written. Strict wording you cannot keep is evidence the system does not work
- Classify every clause keep / rewrite / cut and record the reason for each cut and rewrite — that list is your audit answer sheet
- The principle is never write a rule you cannot keep: can we start next week, will there be a record, will it survive a change of personnel
- Things you want but cannot yet sustain go in the risk treatment plan or the objectives, and get promoted into procedures once delivered
- Proper nouns and mutable numbers move to annexes or work instructions. Write procedures by role, and have the people who do the work review them
Pottech supports ISMS builds with a focus on healthcare. We do supply templates — but the value is not in the template; it is in deciding which clauses stay and where the wording has to meet how you actually work. 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.