Last Updated on September 30, 2025 by Melissa Lazaro

Introduction

When I first started guiding companies through ISO/IEC 27001, one of the biggest surprises for most teams was realizing just how few procedures are truly mandatory. They’d expect binders of documents, when in reality, the standard only requires a clear, focused set.

Here’s the problem: a lot of organizations either over-document (creating procedures no one uses) or under-document (skipping the essentials auditors expect). Both mistakes cost time, money, and credibility during certification.

In this article, I’ll walk you through the official mandatory procedures required by ISO/IEC 27001:2022. You’ll see exactly what’s on the list, why it matters, and how to build them without drowning in paperwork.

By the time you’re done, you’ll know:

• Which procedures you absolutely need to pass an audit.

• How to avoid the most common mistakes I’ve seen during real audits.

• Practical tips for keeping your documentation lean but compliant.

Now that we’ve set the stage, let’s dive into what’s actually mandatory.

Understanding Mandatory vs. Optional Documentation

Here’s something I’ve noticed again and again: teams often confuse mandatory procedures with best-practice documents. The standard itself doesn’t demand dozens of manuals—it only points to a handful of procedures that auditors must see. Everything else? Helpful, but optional.

This distinction matters because I’ve seen companies waste weeks writing documents that nobody reads, while missing the few that actually decide whether they pass or fail an audit.

To make it crystal clear, here’s how I usually explain it during a client workshop:

Here’s the takeaway: ISO/IEC 27001 only forces your hand on a short list of procedures and records. Everything else should be driven by your risks and your organization’s reality—not by a generic template pack.

In my experience, companies that keep their ISMS documentation lean and role-based (instead of writing “for the auditor”) not only pass audits faster but also get people to actually use the procedures.

The Core ISO/IEC 27001:2022 Mandatory Procedures List

When clients ask me, “What do we actually need in writing to pass the audit?” — this is the list I show them.
It’s not about drowning in paperwork; it’s about proving you have control, consistency, and evidence.

Here’s the complete breakdown of the mandatory procedures for ISO/IEC 27001:2022:

Why This List Matters

Here’s the truth: if you miss even one of these, your audit is at risk.
I’ve seen companies with strong controls fail certification just because they didn’t have a clear documented Internal Audit Procedure or forgot to update their SoA.

On the flip side, when you nail these core procedures, everything else flows. Auditors don’t just look at the paper—they test whether your team understands and follows them. That’s why keeping these lean, practical, and alive (not just written once and forgotten) is the real secret.

Practical Guidance for Developing Each Procedure

Here’s what I’ve noticed: most organizations don’t fail ISO/IEC 27001 because they’re missing procedures. They fail because the procedures they do have are either way too long, way too generic, or nobody follows them.

The key is to keep things short, practical, and role-based. Let me break this down for each of the mandatory procedures:

1. Risk Assessment Procedure

• Keep it simple: Define who does the assessment, how often, and the criteria you use.

• Pro Tip: Use a 1–5 scoring system (Impact × Likelihood). It’s easy for both IT and non-technical staff to understand.

• Mistake I see often: teams download a template with 20 scoring levels, then nobody actually uses it.

How I do it with clients: I usually build a one-page risk register in Excel. Clear columns: Risk, Impact, Likelihood, Score, Owner, Treatment Decision.

2. Risk Treatment Procedure

• Action-driven: Define how you pick controls (reduce, transfer, accept, avoid).

• Pro Tip: Tie treatments directly to your Statement of Applicability (SoA) so auditors see the link.

• Common Pitfall: People accept risks without documenting why—auditors hate that.

Example: One SaaS company I worked with used Jira to track risk treatments as tickets. Easy to assign, track, and close.

3. Statement of Applicability (SoA)

• Make it a living document: Update it every time you change controls.

• Pro Tip: Add a column for “Rationale for Inclusion/Exclusion.” Saves hours of debate with auditors.

• Mistake: Copy-pasting Annex A controls without context—auditors instantly know it’s fake.

4. Information Security Objectives Monitoring

• Be measurable: Objectives must have KPIs (e.g., 100% of staff complete awareness training by Q2).

• Pro Tip: Use SMART format (Specific, Measurable, Achievable, Relevant, Time-bound).

• Mistake: Writing fluffy goals like “Improve awareness.” That’s not measurable.

5. Documented Information Control Procedure

• Focus on version control & access: Who approves changes? Where are docs stored? Who gets access?

• Pro Tip: Cloud tools (SharePoint, Confluence, Google Drive) make it easy if you define permissions.

• Pitfall: Teams keep docs scattered—some in email, some in personal drives. That’s an audit nightmare.

6. Internal Audit Procedure

• Make it repeatable: Define audit frequency, scope, methodology, reporting, and follow-up.

• Pro Tip: Rotate auditors if possible—fresh eyes spot blind spots.

• Mistake: Using the same checklist every year. Your ISMS evolves, so should your audit approach.

7. Corrective Action / Nonconformity Procedure

• Keep it structured:

  1. Identify the issue.

  2. Contain the problem.

  3. Root cause analysis.

  4. Corrective action.

  5. Verification of effectiveness.

• Pro Tip: Use the “5 Whys” method for root cause analysis. Simple but powerful.

• Mistake: Closing NCs without evidence of effectiveness. Auditors always dig here.

Quick Visual Recap

Here’s the bottom line: Write your procedures for the people who will use them, not for the auditor. Ironically, when procedures are short and practical, auditors are happier because staff can actually explain them in practice.

Aligning Procedures with Annex A Controls

Here’s what I’ve seen in practice: during audits, one of the first things auditors do is cross-check your mandatory procedures against Annex A controls. If the connection isn’t obvious, they’ll ask tough questions.

Now, here’s the good news: you don’t need a separate written procedure for every Annex A control. Instead, you just need to map your mandatory procedures to the relevant control categories and show how they’re applied.

Mapping Table – Mandatory Procedures ↔ Annex A

Why This Mapping Matters

• For Auditors: They want to see the logical chain → Risk → Control → Evidence.

• For You: It helps avoid duplication. Instead of writing 50 mini-procedures, you show auditors how Annex A is embedded into your existing mandatory ones.

Example from a client: Their risk treatment plan referenced controls like A.8.12 Data Leakage Prevention. Instead of creating a separate DLP procedure, they simply pointed to the section in their risk treatment and SoA. The auditor was satisfied because the mapping was crystal clear.

Key Takeaway:
Don’t fall into the trap of writing a new procedure for every Annex A control. Instead, map controls to your core procedures, keep the SoA updated, and prove effectiveness with audits and records. That’s exactly what auditors expect.

Maintaining and Reviewing Procedures

Here’s what I’ve noticed: most organizations do a solid job drafting their mandatory procedures before certification, but after passing the audit, those documents sit untouched for years. By the time the next surveillance audit comes, the procedures are outdated, people aren’t following them, and the ISMS looks like it’s collecting dust.

ISO/IEC 27001:2022 expects your procedures to be living documents—reviewed, updated, and actually used.

When to Review Procedures

Here’s a simple rule I teach clients: “Review when reality changes, not just when the calendar says so.”

Ownership & Responsibility

One of the biggest pitfalls I’ve seen is nobody knowing who owns a procedure. When an auditor asks, “Who’s responsible for updating the Internal Audit procedure?”—silence in the room is a red flag.

Practical Tips:

• Assign one owner per procedure (e.g., Risk Assessment → CISO or Risk Manager, Document Control → Quality/Compliance Manager).

• Use a responsibility matrix (RACI) so staff know if they’re Responsible, Accountable, Consulted, or Informed.

• Keep approvals simple: draft → review → approve. Don’t create 6-step bureaucratic sign-offs that stall updates.

Pro Insight from Audits

I once worked with a mid-sized financial services company that had great risk assessment and SoA documents—back in 2019. By 2022, they hadn’t touched them, even though the business had moved half its systems to the cloud. The result? Major nonconformity for having outdated risk treatment and SoA. They spent weeks scrambling before surveillance audit.

The lesson? Procedures age fast when your technology, risks, or team changes. Regular reviews save you from panic mode.

Key Takeaway: Treat your procedures as living tools, not static binders. Assign clear owners, review them at least annually, and update them whenever reality shifts. That way, you’ll always be audit-ready—without last-minute chaos.

Common Audit Findings Related to Mandatory Procedures

Here’s the reality: most organizations don’t get hit with a nonconformity because they don’t have procedures. They get flagged because their procedures are incomplete, outdated, or not followed in practice.

I’ve seen the same audit findings come up again and again. Here are the big ones:

1. Outdated Statement of Applicability (SoA)

• Finding: The SoA didn’t reflect recent control changes or cloud migration.

• Example: A software company adopted new cloud security controls but never updated its SoA. The auditor flagged a major NC because the document didn’t match reality.

• How to Avoid: Review and update your SoA whenever you add or drop controls—not just once a year.

2. Incomplete Risk Assessment Records

• Finding: Risks were identified but scoring criteria weren’t consistent, or treatment wasn’t recorded.

• Example: A healthcare startup listed risks but left treatment decisions blank. The auditor marked it as a minor NC, forcing them to rework their risk register.

• How to Avoid: Always close the loop: identify → score → assign owner → document treatment.

3. Internal Audit Procedure Not Followed

• Finding: Internal audits were planned but not executed, or reports weren’t retained.

• Example: An e-commerce firm scheduled audits in their procedure but skipped one cycle. The auditor gave a minor NC, saying “procedure not implemented as written.”

• How to Avoid: Don’t overcommit. If you can only realistically audit once a year, say so—and stick to it.

4. Weak Corrective Action Process

• Finding: Nonconformities were logged but without root cause analysis or verification of effectiveness.

• Example: A logistics company kept closing NCs by just saying “fixed” without proving it. The auditor demanded evidence of effectiveness, turning it into a major NC.

• How to Avoid: Always document root cause and follow up with proof (screenshots, logs, updated records).

5. Poor Document Control

• Finding: Multiple versions of the same procedure were floating around. Staff weren’t sure which was current.

• Example: A financial services company had two versions of the Document Control procedure in circulation. The auditor issued a minor NC for lack of control.

• How to Avoid: Use one central repository with clear versioning and access rules.

Quick Recap Table

Key Takeaway:
Auditors don’t just check if you have procedures—they check if they’re current, consistent, and applied in practice. The best way to avoid NCs is to keep procedures lean, assign owners, and actually use them day-to-day.

FAQs (Strengthen Trust & Address User Intent)

Q1. Do I need a documented procedure for every Annex A control?

No. This is one of the biggest misconceptions. ISO/IEC 27001:2022 requires documented procedures only for a short, defined list (risk assessment, treatment, SoA, audits, corrective actions, etc.). Annex A controls don’t each need their own written procedure—what matters is that you can show evidence of how the control works in practice.

Q2. Can I just buy templates for the mandatory procedures?

You can, but here’s the catch: auditors spot generic templates instantly. I’ve seen companies fail audits because their documents were clearly copy-pasted and didn’t reflect their operations. Templates are a good starting point, but you need to customize them—language, roles, systems, and actual practices.

Q3. What’s the real difference between policies and procedures in ISO/IEC 27001?

• Policy = direction and intent (the “what” and “why”).

• Procedure = the steps and responsibilities (the “how”).
  Think of it this way: your Information Security Policy says “We protect customer data,” while your Access Control Procedure explains exactly how you manage logins, privileges, and monitoring.

Conclusion (Reaffirm Authority & Prompt Action)

If there’s one thing I’ve learned guiding organizations through ISO/IEC 27001, it’s this: success doesn’t come from having piles of documents, but from having the right ones—and keeping them alive.

The mandatory procedures we walked through—risk assessment, treatment, SoA, objectives monitoring, document control, internal audit, and corrective actions—are the backbone of your ISMS. When they’re clear, practical, and regularly updated, certification becomes far less stressful.

I’ve seen companies overcomplicate this and fail, and I’ve seen others keep it lean and pass with confidence. The difference was always in how well they aligned procedures with reality, not just the standard.

If you want to fast-track this process, you don’t have to start from a blank page. You can use ready-to-customize ISO/IEC 27001 procedure templates or follow a step-by-step implementation plan to save time and avoid common mistakes.

Your next step: Pick one procedure—often the risk assessment—and make sure it’s crystal clear, practical, and used by your team. Once that’s in place, build the others around it. That’s how you move from theory to certification.