One of the first questions asked in any ISMS build is "how many procedures do we need?" The honest answer — "the standard does not say" — sounds unhelpful, but it reflects the actual structure: the standard explicitly requires a limited set of documents, and everything else is what the organisation decides it needs. Miss that distinction and you fail in one of two directions.
The first is too much. Twenty procedures and fifty work instructions, modelled on someone else's architecture, while the real work runs differently and revision has stalled. At stage 2 the floor contradicts the documents and findings follow. The second is too little. A policy and an SoA exist, but nothing supports day-to-day decisions, so operation mutates whenever a person changes.
This article sets out the scope of documented information the standard requires, how to design the policy / procedure / work-instruction / record hierarchy, and the criteria for deciding where to stop. For the documentation requirement itself see Clause 7: Support; 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
There is no single list of required documents in the standard
The separate clauses for control of documents and control of records that existed in the 2013 edition were consolidated into one concept — documented information. The requirements are distributed across Clauses 4 to 10, so the whole picture only emerges from a full read. The practical consequence is that a consultancy's template pack gets mistaken for "what the standard requires." Most of a template pack is the provider's design, not a requirement.
Abdicating the "what we decided we need" judgement
Beyond what it explicitly requires, the standard asks for documented information the organisation determines is necessary for the effectiveness of the ISMS. That is discretion — and with it, accountability for how the discretion was exercised. The ideal state is being able to say what you chose not to write, and why. In practice, adopting the entire template pack avoids making the judgement at all. That is the main cause of over-documentation.
Confusing documents with records
A procedure is an agreement about how things will be done; a record is evidence of how they were done. They differ in update frequency and approver. Embedding a results table inside a procedure means every new result triggers a revision and re-approval, and operation stalls. Do not put the changing and the unchanging in the same document.
Too many layers
Policy → framework procedure → area procedure → work instruction → work standard → form: six layers, copied from large-enterprise document control. In a fifty-person organisation the same content simply gets written three times, and every revision requires reconciling the copies. Layers should match the organisation's size and the number of approval levels it actually has.
Not planning for revision to stop
Documents go stale. If the design phase never settles "who reviews what, annually," the year-two surveillance audit finds every document still carrying its original revision date. Document currency is a recurring theme in Preparing for a Surveillance Audit.
What You Have to Decide
Start with what the standard explicitly requires as documented information. This is the "always write it" boundary.
| Clause | Documented information required | Typical artefact |
|---|---|---|
| 4.3 | Scope of the ISMS | Scope definition |
| 5.2 | Information security policy | Information security policy |
| 6.1.2 | The risk assessment process | Risk assessment procedure |
| 6.1.3 | The risk treatment process / Statement of Applicability | Risk treatment procedure, SoA |
| 6.2 | Information security objectives | Objectives register |
| 7.2 | Evidence of competence | Training records, qualification records |
| 7.5.1 | Required by the standard plus what the organisation determines is necessary | (see below) |
| 8.1 | Documentation to the extent needed for confidence that processes ran as planned | Operational procedures and records |
| 8.2 | Results of risk assessments | Risk assessment table |
| 8.3 | Results of risk treatment | Risk treatment plan, implementation records |
| 9.1 | Evidence of monitoring and measurement results | Measurement records |
| 9.2 | The internal audit programme and audit results | Audit plan, audit report |
| 9.3 | Results of management reviews | Management review minutes |
| 10.2 | Nature of nonconformities, actions taken, results of corrective action | Corrective action reports |
On top of that, the organisation decides which of the Annex A controls it has included cannot be operated without a written procedure. Anything marked applicable in the SoA has to be explainable as an operating reality. See Writing the Statement of Applicability.
Next, settle the four layers.
| Layer | Content | Update frequency | Approver | Typical length |
|---|---|---|---|---|
| 1: Policy | Organisational intent — what is protected, who is accountable | Every few years | Top management | 1–2 pages |
| 2: Procedures | Mandatory rules per area — what must be done | Reviewed annually | ISMS manager / executives | A few pages per area |
| 3: Work instructions | Concrete method — how it is done | Whenever practice changes | Department manager | As needed |
| 4: Records and forms | Evidence that it was done | Continuously | (per form) | — |
Draw the line between layers 2 and 3 by who approves. Anything requiring a management decision is a procedure; anything a department can change on its own is a work instruction. Doing this frees work instructions from executive sign-off, which is what lets documents actually move.
Finally, record what you decided not to write. A note such as "clear-desk practice is covered by one clause in the procedure; no standalone work instruction" in the remarks column of the document register lets you show at audit that the absence is a decision, not an omission.
How to Do It
Step 1: Start with what the standard explicitly requires
The fourteen rows above apply to every organisation. Fill them first. Using someone's template at this stage is fine, provided step two follows. See Adapting Template Procedures to Your Organisation.
Step 2: Derive documentation needs from the SoA
List every included control and judge for each: does one clause in an existing procedure suffice, is a standalone work instruction needed, or is a form enough? The three tests:
- Do the consequences of doing it wrong matter? (granting and revoking access, incident first response)
- Do multiple people perform it? (single-person tasks are never revised anyway)
- Will an auditor or customer ask to see the procedure? (supplier management, backups)
Three "no"s mean no standalone document. One clause in a procedure covers it.
Step 3: Set the number of procedures by area, not by control
Per-control procedures would give you 93. Group by area. A set like the following is manageable at fifty people.
| Procedure | Area covered | Annex A theme |
|---|---|---|
| Information security management | Governance, roles, document control, risk, audit | Core organisational controls |
| People security | Hiring, transfer, exit, training, discipline, confidentiality | People controls |
| Physical security | Entry control, locking, equipment maintenance and disposal, removal | Physical controls |
| Acceptable use of IT | User obligations, authentication, endpoints, email, cloud | Technological (user-facing) |
| Systems operation | Change control, logging, backup, vulnerabilities, development | Technological (operations) |
| Supplier management | Selection, contract clauses, review, sub-processors | Supplier relationships |
| Incident response | Detection, reporting, first response, post-incident analysis, external notification | Security events |
| Business continuity | Availability, continuity during disruption | Continuity |
For theme-by-theme reading see Organisational Controls, People Controls and Physical Controls.
Step 4: Decide the document control rules first
Version numbering, revision history, storage location, access rights, retention, handling of superseded versions. Settle these before writing, or you will retrofit every document later. Keep one storage location and make sure everyone can answer "where is the master?" Copies scattered across a shared drive and a file server always become an audit issue.
Step 5: Design the forms before the work instructions
Building forms first keeps the architecture realistic, because a form forces you to decide what is actually recorded — and that is where you discover items nobody can record. Adding an "approver" field and finding no one holds the authority is a common and useful discovery.
Step 6: Set the review cadence and owner
Add "next review due" and "review owner" columns to the document register. Rather than reviewing everything at once, cycle a subset each quarter to level the load. Making document currency an internal audit checkpoint surfaces anything missed — see Running an Internal Audit.
Where It Goes Wrong
Adopting a template pack verbatim
The most common failure. Procedures written for another organisation name departments you do not have, controls you do not operate and tools you do not use. Stage 2 checks operation against what is written, so written but not done is a nonconformity waiting to happen. See Adapting Template Procedures to Your Organisation.
Proper nouns and variable numbers inside procedures
"The Microsoft 365 tenant administrator shall be the IT section manager" means a revision and re-approval every time the tooling or the org chart changes. Put proper nouns and mutable figures in layer 3 or an annex. Write procedures by role: "administrative privileges for cloud services are held by the head of the department responsible for information systems."
The same rule written in several documents
"Passwords are changed periodically" appearing in the policy, the management procedure and the acceptable use procedure. Fix one and the others linger, and the documents contradict each other. Write each rule once and reference it from everywhere else.
No retention period for records
Without one, records either accumulate forever or disappear at someone's discretion. Auditors ask for the previous internal audit record, so design for at least one full certification cycle (three years). Where medical information is involved, contracts or law may set longer periods, which take precedence.
Paper and electronic mixed, with no clear master
Only the forms needing a seal live on paper, filed in a cabinet with no index. If paper is used, note "paper — location" in the electronic document register.
Producing documents becomes the goal
"We have twenty procedures" says nothing about ISMS maturity. What says something is operation matching what is written, with records to prove it. A voluminous architecture cannot be maintained by a small team; as covered in ISMS in a Small Organisation, cutting to fit the organisation is the correct judgement.
Revised but never communicated
A procedure is updated and the floor keeps working from the old version. The documentation requirement includes being available where and when it is needed. Write the communication method for revisions — email notice, team meeting, folding it into training — into the document control rules. See Designing Security Awareness Training.
Healthcare Examples
A healthcare SaaS provider
Beyond the generic set, you need work instructions for any task touching production patient data: incident investigation, data correction requests, migrations. Unless "who requests, who approves, what is recorded" is fixed, you cannot answer a hospital that asks to see the procedure. Write these expecting to hand them over in a customer audit.
Equally important: do not absorb customer-specific requirements into the corporate procedures. A condition negotiated with Hospital A, written into a company-wide procedure, now binds you for every other customer. Manage specifics in the contract register and, if needed, customer-specific annexes. On demarcation, see Shared Responsibility in AI EMR Security Design.
A PHR operator
Consent management needs its own document: the in-product flow, the fields recorded, and the treatment of data after withdrawal, for grant, change and withdrawal alike. Because it overlaps the personal information law, put the privacy policy and the internal procedure through the same review so their wording cannot diverge. See ISMS for PHR Operators.
A SaMD developer
A QMS (ISO 13485) document architecture already exists, so the first design decision is how the ISMS documents connect to it. Document control, training, internal audit and corrective action can be shared; risk management should not be, because the purposes differ. Note on each shared document which management system's requirements it satisfies, and it serves both audits. See SaMD, ISMS and ISO 13485.
Any supplier to healthcare institutions
Keeping three-ministry-guideline documents in a separate architecture doubles the maintenance. The workable approach is clauses inside the same procedures, linked by a mapping table. See Integrating ISMS Documents with the Three-Ministry Guidelines and The Three-Ministry Guidelines.
Conclusion
- The standard explicitly requires only a limited set — scope, policy, risk processes and SoA, objectives, competence evidence, monitoring results, internal audit, management review, nonconformity and corrective action, among others. The rest is your call
- "What the organisation determines is necessary" is discretion and accountability. Record what you decided not to write
- Four layers — policy, procedure, work instruction, record — is enough. Draw the layer 2/3 boundary by who approves
- Group procedures by area, not by control; around eight is manageable at fifty people
- Keep proper nouns and mutable figures out of procedures, or every tool and org change forces a revision
- Settle document control rules — versioning, master location, retention, communication — before building the architecture, not after
Pottech supports ISMS builds with a focus on healthcare. Document architecture is where the ability to decide "how far is far enough" determines your operating burden for years afterwards. 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.