What ISO 27001 makes you put in writing, and what it leaves to you.

The table holds two kinds of item. Set and revisit items describe how you mean to work, and change only when something about the business changes. Builds up items are produced as the ISMS runs; their worth lies in being complete and untouched. An auditor reads the first kind to judge design and samples the second kind for proof.

Clause 7.5.1 is the open end of the list: you decide what else the ISMS needs in writing, so the real total grows with your control choices. How to version, approve and protect what you write is covered on our documented information page.

• You employ staff and contractors. Acceptable use rules (5.10), screening and training records (6.1, 6.3) and signed confidentiality agreements (6.6).
• You depend on vendors. A supplier list rated by risk, and the security terms in each relevant contract (5.19, 5.20).
• You run production systems. Operating runbooks (5.37), backup and restore-test records (8.13), change tickets (8.32) and access reviews (5.18).
• You handle incidents. A response plan (5.24) and a file for each incident, from triage through to lessons learned (5.25 to 5.27).
• Laws and contracts bind you. A register of the obligations in scope (5.31), plus privacy records wherever personal data is involved (5.34).
• You set rules on a subject. Subject policies under 5.1, for instance on access or encryption, written at a level your teams can apply.

An ISMS manual

Not required by any edition. A one-page index pointing to your scope, policy and SoA does the same job for a new joiner.

A stakeholder register

Clause 4.2 asks you to work out the interested parties and their needs, not to keep a register. A short table is still the easiest proof.

A RACI chart

Clause 5.3 needs roles assigned and made known. A chart is one tidy way to show that.

A communication plan

Clause 7.4 needs decisions on what gets communicated, to whom and when. A table answers it; ten pages do not help.

A document control procedure

The controls in 7.5 must exist. Writing them up as a procedure is a choice, often a sensible one in larger teams.

1. Scope first, because everything else is judged against it.
2. Policy and objectives next, to see what leadership has committed to.
3. The risk method, then the latest risk results, to confirm the method was really used.
4. The SoA, read line by line against the risk treatment results.
5. Internal audit and management review records, to confirm the ISMS has completed one full loop.
6. A sample of control documents for controls the SoA marks as applicable.

Trouble often starts at step four: a control marked applicable with no owner, or one excluded while the risk register plainly calls for it. Fixing those mismatches before the audit is cheaper than answering for them in a report.

Notice what is absent: no manual, no separate procedure per control, and policies short enough to read in one sitting. Merging the two risk processes into one document is acceptable as long as each one is clearly covered and easy to point to.

Sources: ISO/IEC 27001:2022, clauses 4 to 10 and Annex A (clause numbers, clause titles and control titles only; the descriptions are Auditify's own wording); ISO/IEC 17021-1:2015 for how Stage 1 is used.