ISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified

If you run an ISO 9001 system, ISO/IEC 27001 has probably already arrived on your desk in disguise. It comes as a customer's security questionnaire with forty questions you have never been asked before, as a clause in a new supply agreement that says "the supplier shall maintain an information security management system aligned to ISO/IEC 27001", as a cyber-insurance proposal form, or as a question from the board after a competitor's ransomware incident made the news. In South Africa it also comes from the law: POPIA requires "appropriate, reasonable technical and organisational measures" to protect personal information, and since June 2025 every supplier to a bank, insurer or retirement fund has been feeling the FSCA and Prudential Authority's Joint Standard on cybersecurity flow down through its contracts.

The good news is that you are closer than you think. ISO/IEC 27001:2022 is built on the same Harmonized Structure as ISO 9001, ISO 14001, ISO 45001 and ISO 22000. Clauses 4 to 10 ask for context, leadership, planning, support, operation, performance evaluation and improvement — the same seven headings, in the same order, with most of the same wording. A quality manager reading ISO 27001 for the first time recognises about four fifths of it. This article is about the other fifth: what the standard actually requires, the four things that are new if you come from quality, where implementations fail, how it meets POPIA, and a realistic path from decision to certificate. The free gap analysis checklist at the end scores all of it — the 30 management-system requirements and the 93 Annex A controls — in an afternoon.

A note on sources. This article paraphrases ISO/IEC 27001:2022 (including Amendment 1:2024) in plain English and reproduces no standard text. It is a planning aid, not the standard. Work from your licensed copy — the SANS adoption is sold through the SABS webstore — and from ISO/IEC 27002:2022 for control guidance before you close a gap. Qlause is an independent training and templates provider, not a certification body.

What ISO/IEC 27001 is, and what it is not

ISO/IEC 27001 is the requirements standard for an information security management system — an ISMS. It tells you what a management system for protecting the confidentiality, integrity and availability of information must contain; it does not tell you which firewall to buy. Certification means an accredited certification body has audited your ISMS against the standard, in a two-stage initial audit followed by surveillance audits in years two and three, exactly as with ISO 9001.

The standard has two halves. Clauses 4 to 10 are the management system: mandatory, non-negotiable, and familiar. Annex A is a reference list of 93 information security controls in four themes — organizational (37), people (8), physical (14) and technological (34) — which you use as a completeness check against your own risk assessment. Annex A is not a checklist of things you must do; it is a list of things you must consider and either apply or justify leaving out. The sister standard ISO/IEC 27002:2022 gives implementation guidance for every one of the 93 controls and is the document most implementers actually spend their time in.

A few facts about the edition worth having straight, because competitor pages get them wrong. The current edition is ISO/IEC 27001:2022, published in October 2022. The 2013 edition is dead: the transition period for certified organisations closed on 31 October 2025. The only change since publication is Amendment 1 of 2024, which adds one requirement to clause 4.1 — determine whether climate change is a relevant issue — and one note to 4.2, the same climate text every management-system standard received. The standard is in routine systematic review and no revision is in progress, so what you build now has a long shelf life. Worldwide there were just under 97,000 valid certificates in the ISO Survey 2024, roughly double the year before — partly a change in how the survey is compiled, but the direction is not in doubt.

Clause by clause: what you already know, and what is different

Read the two standards side by side and the pattern is immediate. The clause numbers match, the headings match, and in most sub-clauses the requirements match with "quality" replaced by "information security".

• 4.1 and 4.2, context and interested parties. Identical in structure. The content changes: your interested parties now include the Information Regulator, your cyber-insurer and every customer whose data you hold, and ISO 27001 adds a step in 4.2 — decide which of their requirements the ISMS will address. Read the Explorer's pages on clause 4.1 and clause 4.2 for what that looks like in practice.
• 4.3 scope. Same requirement, higher stakes. Information crosses organisational boundaries far more freely than product does, so the standard asks you to name the interfaces and dependencies with other organisations — the cloud platform, the payroll bureau, the parent company's network. Scoping errors are the most common Stage 1 failure. See clause 4.3.
• 4.4, 5.1, 5.2, 5.3. Near-identical. The policy has the same four required elements as a quality policy. Roles gain two the standard names — someone responsible for the ISMS conforming, and someone reporting its performance to top management — and, in South Africa, the POPIA Information Officer sits naturally here. See clause 5.1.
• 6.1 risks and opportunities. This is where the standards part company. ISO 9001 asks you to determine and address risks and opportunities and leaves the method to you. ISO 27001 splits the clause into three: 6.1.1 is the ISO 9001 requirement, and then 6.1.2 and 6.1.3 add a formal information security risk assessment and risk treatment process with specific, auditable rules. More on this below, because it is the heart of the standard.
• 6.2 objectives and 6.3 planning of changes. Identical. ISO 27001:2022 gained 6.3 in the same Harmonized Structure update that gave it to ISO 9001:2026, so if you have just built a change-planning record for your quality system, it works here unchanged.
• 7.1 to 7.5, support. Identical requirements for resources, competence, awareness, communication and documented information. The emphasis shifts: awareness becomes a programme rather than an induction slide, communication gains breach-notification duties, and document control must protect the ISMS's own records — the risk register and network diagrams are themselves sensitive.
• 8.1 to 8.3, operation. 8.1 is ISO 9001's 8.1 with one broadening: externally provided processes, products and services relevant to the ISMS must be controlled, which pulls every cloud service and managed provider into scope. 8.2 and 8.3 simply require you to run the risk assessment and treatment you defined in clause 6, at planned intervals and on significant change.
• 9.1 to 9.3, performance evaluation. Identical structure. Clause 9.1 now requires documented results of monitoring and measurement, and the management review inputs in 9.3.2 gained "changes in the needs and expectations of interested parties" in 2022.
• 10.1 and 10.2, improvement. Identical, and in the same order ISO 9001:2026 now uses — continual improvement first, nonconformity and corrective action second.

The practical conclusion: do not build a second management system. Extend the one you have. Your document control, internal audit programme, management review, competence records and corrective action process all carry ISO 27001 with modest additions. The organisations that struggle are the ones where IT builds a separate ISMS in a separate folder and the quality team never hears about it.

The four things that are new if you come from quality

1. A defined risk method with acceptance criteria

ISO 9001 lets you manage risk in your head if you can show the results. ISO 27001 does not. Clause 6.1.2 requires a documented risk assessment process with two sets of criteria written down before you start: risk acceptance criteria — the level of risk the organisation is willing to live with — and criteria for performing assessments, meaning the likelihood and consequence scales and how they combine. The process must produce consistent, valid and comparable results every time it is run, which is the standard's way of saying that two people assessing the same risk should land on the same score. Every risk must have a named owner. The assessment must cover loss of confidentiality, integrity and availability — not just cyber-attack — for the information in scope.

The 2022 edition does not prescribe an asset-threat-vulnerability method. A scenario-based approach ("ransomware encrypts the file server during month-end") is just as acceptable as an asset-based one, and often easier for a business to engage with. What matters is that the method exists on paper, was approved, and was followed. Auditors test it by asking how two specific scores were arrived at; "judgement" is the wrong answer.

2. The Statement of Applicability

The Statement of Applicability — universally the SoA — is the document that makes ISO 27001 different from every other management-system standard, and it is the single most common source of Stage 1 findings. Clause 6.1.3 requires you to choose a treatment option for each unacceptable risk, determine the controls needed to implement it, compare those controls against the 93 in Annex A to make sure nothing necessary has been missed, and then produce the SoA: every necessary control, the justification for including it, whether it is implemented, and the justification for excluding any Annex A control. The risk owners — not the ISMS manager — approve the treatment plan and accept the residual risk.

The failure mode is predictable. Teams open the Annex A list, mark everything applicable, type "best practice" in the justification column and move on. Auditors read that as a treatment process that never happened, because the justifications do not mention a single risk. Build the SoA from the risk register instead: a control is applicable because risks X and Y select it, or because a law or a contract requires it. Then walk Annex A once for completeness and write a real reason against each exclusion. A linked spreadsheet does this adequately for most organisations; the Qlause Risk Assessment and SoA Toolkit is built to that pattern — risks in, Statement of Applicability out.

3. Ninety-three controls across four themes

Annex A was restructured in 2022 from 114 controls in 14 domains to 93 controls in four themes, and each control in ISO 27002:2022 now carries attribute tags — control type, security property, cybersecurity concept, operational capability, security domain — so you can view the set through whichever lens your stakeholders use (a NIST-speaking customer, say). Eleven controls were new in 2022, and they are where the gaps cluster in organisations that transitioned from 2013 by renumbering their documents:

• 5.7 Threat intelligence
• 5.23 Information security for use of cloud services
• 5.30 ICT readiness for business continuity
• 7.4 Physical security monitoring
• 8.9 Configuration management
• 8.10 Information deletion
• 8.11 Data masking
• 8.12 Data leakage prevention
• 8.16 Monitoring activities
• 8.23 Web filtering
• 8.28 Secure coding

For a quality manager the themes themselves are the useful map. Organizational controls (A.5) are policy, roles, assets, access rules, suppliers, incidents, continuity and legal compliance — most of it management-system work you already know how to do. People controls (A.6) are HR: screening, contracts, awareness, discipline, leavers, remote working, event reporting. Physical controls (A.7) are the site: perimeters, entry, clear desk, equipment, media, disposal. Technological controls (A.8) are where IT lives: endpoints, privileged access, malware, vulnerabilities, backup, logging, networks, cryptography, secure development. Roughly two thirds of the 93 are not technical at all, which is why a quality or compliance manager is a perfectly good ISMS lead with the right IT partner.

4. Evidence that controls operate, continuously

The deepest difference is tempo. A quality system generates records at the pace of production; an ISMS generates them at the pace of the network. Access reviews, patch reports, backup restore tests, log reviews, supplier assessments and awareness refreshers each have a frequency, and an auditor will ask for the record from a specific week. "We have a procedure" is not evidence that a control operates; the ticket, the report from the system, the signed review is. This is why the compliance-automation platforms exist and charge what they do — they collect that evidence automatically from cloud and identity systems. For most small and mid-sized organisations a disciplined evidence register — control, owner, frequency, where the record is produced, date last collected — does the same job in a spreadsheet, as long as somebody owns it.

Where ISO 27001 implementations fail

Three recent practitioner sources — a certification body's analysis of common nonconformities, and two consultancies' accounts of Stage 1 failures — agree on the same list, and it is worth reading as a to-do list in reverse.

1. No defined risk procedure or criteria. The register exists; the method behind it does not.
2. Weak risk treatment evidence. Treatment plans with no dates, "verbal confirmations and incomplete spreadsheets".
3. A weak SoA. Generic justifications, not linked to risks, never updated.
4. Missing internal audits and management reviews, or ones that exist on paper but never tested a control.
5. No ISMS metrics. Nothing measured, so effectiveness is a feeling.
6. A poor incident process. No classification, no post-incident learning, no breach-notification route.
7. Access reviews not done, supplier security agreements missing, awareness training untracked, no asset inventory.
8. Evidence scattered across tools and inboxes with no owner or frequency.

Notice that almost none of these is technical. They are management-system failures — exactly the kind an experienced ISO 9001 practitioner knows how to prevent. The Explorer's page on each clause lists the common nonconformities in its last section; the pattern across them is "documents without operation".

How ISO 27001 meets POPIA — and where it does not

South African organisations usually arrive at ISO 27001 through POPIA, so it is worth being precise about the relationship. POPIA section 19 requires the responsible party to secure the integrity and confidentiality of personal information through appropriate, reasonable technical and organisational measures: identify the reasonably foreseeable risks, establish and maintain safeguards, regularly verify they are effectively implemented, and keep them updated — having regard to generally accepted information security practices. That paragraph is, almost line for line, clauses 6.1.2, 6.1.3, 8.2, 8.3 and 9.1 of ISO 27001. Section 22 requires notification of security compromises to the Information Regulator and to affected data subjects; that is Annex A controls 5.24 to 5.26 and clause 7.4 with the Regulator's eServices portal as the channel. Regulation 4 requires the Information Officer to ensure internal awareness sessions are conducted; that is clause 7.3 and control A.6.3 with attendance records. The Information Regulator's first R5 million fine, against the Department of Justice, followed a ransomware attack and an enforcement notice whose remedial terms included staff training — the regulator is already auditing like an ISO assessor.

Two cautions. ISO 27001 certification is not a POPIA certificate, and nobody can sell you one; the standard evidences the security-safeguards condition, not the other seven conditions of lawful processing. And as at the date of this article, section 54 of the Cybercrimes Act — the 72-hour reporting duty for communications providers and financial institutions — has still not been proclaimed, so POPIA section 22 is the only breach-notification duty actually in force for most organisations. If a vendor tells you otherwise, ask for the proclamation.

For suppliers to financial institutions, the Joint Standard 2 of 2024 on Cybersecurity and Cyber Resilience adds a second driver: in force since 1 June 2025, it requires the institutions it covers to run cybersecurity awareness programmes for all users and to write security requirements into third-party contracts. The questionnaire you received from your bank customer is that clause arriving.

A realistic path from decision to certificate

The checklist's Timeline tab lays this out at 44 weeks from a start date; organisations with a working ISO 9001 system regularly do it in six to eight months, a first management system more often takes nine to twelve. The order matters more than the speed.

1. Weeks 0 to 4 — foundations. Record leadership commitment, appoint the ISMS lead and the Information Officer, approve the budget. Run the context and interested-party exercise with an information-security lens, including the climate line. Draft the scope as a boundary diagram. Approve and publish the policy. Build the asset and information inventory with owners — Annex A control 5.9, and the raw material of the risk assessment.
2. Weeks 6 to 12 — risk and the SoA. Write and approve the risk method and criteria first. Run the assessment as workshops with process owners, name the owners, score with the method. Choose treatments, derive the SoA from the register, walk Annex A for completeness, write exclusion reasons, get the treatment plan and residual risk signed off by the owners.
3. Weeks 14 to 28 — build and operate. Set the objectives and the measures. Issue the mandatory documents and the topic policies through your existing document control. Implement controls in treatment-plan order, recording evidence as you go. Launch the awareness programme to everyone, contractors included. Start the metrics so that at least one reporting period exists before audit.
4. Weeks 32 to 36 — check. Internal audit of clauses 4 to 10 and a sample of controls, with real tests. Nonconformities into corrective action. Management review on the full input list, with decisions.
5. Weeks 38 to 44 — certify. Stage 1 (documentation and readiness) and Stage 2 (implementation and effectiveness), with the certification body chosen by week 24 so its planning time is booked. The audit-day count is set by IAF tables from your headcount and sites, as with ISO 9001.

What to reuse from your quality system

• The document control procedure and master register — add ISMS documents, a classification for the sensitive ones, and a retention schedule for security records.
• The internal audit programme — add the ISO 27001 criteria and the Annex A themes as audit areas; train your auditors on 27001 and pair them with IT for the technical controls.
• The management review — add the ISO 27001 inputs to the agenda and run one combined review.
• The competence matrix and training records — add the security-relevant roles and the awareness programme.
• The corrective action register — one register, tagged by system; incidents become nonconformities of the control that failed.
• The change-planning record from clause 6.3 — identical requirement.
• The context and interested-party analysis — extend rather than redo.

What you cannot reuse is the risk method, the SoA and the evidence rhythm. Those three are the real project.

Free download: the ISO/IEC 27001:2022 Gap Analysis Checklist

The checklist scores your organisation against all of the above in one workbook. The Clauses 4–10 tab has the 30 management-system requirements, each with what it asks in plain English and the evidence an auditor expects, with status, score, owner and target date. The Annex A tab has all 93 controls with an Applicable? column — the seed of your Statement of Applicability — the eleven new-in-2022 controls flagged, and the same scoring. The Summary tab calculates readiness by clause group and by Annex A theme, counts the controls you have excluded (each needs a reason) and the new controls still open, and flags overdue items. The Timeline tab turns your start date into the 44-week plan above. Enter your email below and it is on its way.

Every reference in the checklist matches a page in the Clause Explorer's ISO/IEC 27001 set, which explains what each requirement really asks, what auditors look for, the evidence, how to comply and the common nonconformities — the same treatment the Explorer gives ISO 9001, 14001, 45001 and 22000. The 93 Annex A control pages are there too, each with its ISO/IEC 27002:2022 attribute tags — start with the 93 controls quick reference. And because the Explorer feeds the free Audit Manager, you can plan an ISO/IEC 27001 internal audit programme and anchor every finding to its clause today.

Qlause is an independent training and templates provider. It is not a certification body and this article is not a substitute for the standard. Sources: ISO/IEC 27001:2022 and Amd 1:2024, ISO/IEC 27002:2022 (iso.org); ISO Survey 2024 via the SC 27 Journal 2026; Cyberday — the ten most common nonconformities in ISO 27001 audits; SureCloud and Elevate Consult on Stage 1 failures (2026); POPIA sections 19 and 22 and Regulation 4; Bowmans on the Information Regulator's first R5 million fine; Michalsons on the FSCA/PA Joint Standard 2 of 2024 and on the Cybercrimes Act commencement.