ISO 27001 SOP Requirements: Documentation, Records & Controls

ISO 27001 is often described as "documentation heavy," but that framing misses the point. The standard doesn't ask for a wall of documents for its own sake — it asks for documented information that demonstrates how your information security management system actually operates. The distinction matters, because it tells you exactly which SOPs you truly need and which ones you're over-building.

The 2022 revision (the current one) is explicit: you must keep documents only where the standard says so, and you determine the level of documented information proportional to your size, risk, and complexity. This guide maps the ISO 27001 SOP landscape — the mandatory documents, the Annex A operating procedures, the records auditors check, and the smart way to capture them without shipping sensitive process detail out of your control.

Mandatory Documents (Clauses You Cannot Skip)

A handful of documents are mandatory under ISO 27001:2022 regardless of your organization. These form the spine of your ISMS and are the first things a Stage 1 auditor reviews:

• Scope of the ISMS (Clause 4.3) — what's in and out of the certification boundary.
• Information security policy and objectives (Clauses 5.2 and 6.2).
• Risk assessment and risk treatment methodology (Clause 6.1.2).
• Statement of Applicability (SoA) (Clause 6.1.3d) — which Annex A controls apply and why.
• Risk treatment plan (Clauses 6.1.3e, 6.2, and 8.3).
• Risk assessment report (Clauses 8.2 and 8.3).

Beyond these, many Annex A controls only become mandatory if you've declared a relevant risk. That's why a realistic SoA is so important: it converts an intimidating list into a bounded set of controls you've justified, whether selected or consciously excluded.

The Annex A Procedures That Function as SOPs

This is where ISO 27001 and your standard operating procedures converge. Several controls explicitly require documented operating procedures — in effect, SOPs a person or an automated agent follows. The most common ones:

• Security operating procedures for IT management (A.8.1, formerly A.12.1.1) — the day-to-day operating procedures for your infrastructure.
• Access control policy (A.9.1) — who gets access, how it's approved, and how it's revoked.
• Incident management procedure (A.8.8, formerly A.16.1.5) — how you detect, respond to, and review security incidents.
• Business continuity procedures (A.5.30, formerly A.17.1.2).
• Acceptable use and asset inventory (A.5.9, A.5.10).
• Supplier security policy (A.5.19) — how third parties are on-boarded and managed.

These procedures live somewhere between high-level policy ("access is approved via IT") and step-by-step execution ("in the admin panel, under Access, click Add user …"). The step-level detail is exactly what most teams fail to capture, and it's the part that goes stale within weeks. That's the gap automated workflow capture is built to close: you record the real clicks, not an idealized version of the process.

Mandatory Records: Evidence, Not Brochures

A record is different from a document. A document describes; a record proves. ISO 27001 requires records of evidence that the system ran as documented. The mandatory ones include:

• Training, skills, experience, and qualifications of information security personnel (Clause 7.2).
• Monitoring and measurement results (Clause 9.1).
• Internal audit programme and results (Clause 9.2).
• Management review results (Clause 9.3).
• Results of corrective actions (Clause 10.1).

Your log retention policy governs how long these records survive. An auditor is less impressed by a pristine policy and more impressed by proof the procedure was actually followed last quarter. If your retention periods are defined but no one can produce a recent training record or a completed access-review, that's a finding waiting to happen.

Where Privacy-First Recording Helps With ISO 27001

Here's the tension most security teams hit: documenting a sensitive process (say, how you grant access or handle an incident) produces material that is itself sensitive. If you write that SOP in a cloud tool, you're now storing a description of your most critical controls with a third party — the exact thing ISO 27001 asks you to think hard about under the documented-information controls.

A local-first recorder sidesteps that exposure: the workflow recording and the exported procedure stay on your device, encrypted, until you decide otherwise. That aligns cleanly with the standard's emphasis on controlling access to documented information. It also makes your SOPs dramatically faster to produce and to keep current — which, for the SOP staleness problem every ISMS fights, is the difference between documentation that's audit-ready and documentation that's a trap.

A Practical Build Sequence

1. Publish the handful of mandatory documents — scope, policy, risk methodology, SoA, risk treatment plan, risk report.
2. Write the control SOPs only where a declared risk makes them relevant, starting with access control, incident response, and acceptable use.
3. Capture each procedure from the real system by recording the actual workflow rather than reconstructing it from memory.
4. Define retention and version control so every record has a current version, an owner, and a review date — ties into SOP version control.
5. Prove it with records: training logs, audit results, management reviews, monitoring outputs.

For teams in regulated manufacturing or life sciences, note that ISO 9001 and FDA expectations often layer on top of 27001's information-security controls — see how the broader regulated-industry compliance controls (audit trails, signatures, approval flows) interact before you design a single system.

FAQ