Legal, statutory, regulatory and contractual requirements

Plain-language summary

Identifying the laws, regulations and contract terms that bear on your information security, writing them down with your approach to meeting each one, and keeping that list current — including the less obvious ones such as rules on cryptography and on cross-border data.

What the clause is really asking

An ISMS that is technically sound but breaks the law has failed. This control asks you to know every law, regulation and contract term that bears on your information security, to write each one down with how you meet it, and to keep that record current. That usually means a requirements register: the requirement, its source, who owns it, which controls address it and how compliance is checked. In South Africa the core set is POPIA and its regulations, PAIA, the Electronic Communications and Transactions Act, the Cybercrimes Act, company, tax and labour record-keeping laws, and sector rules such as FSCA/PA Joint Standard 2 of 2024 for financial institutions. Contractual requirements count equally: customer security schedules, TISAX expectations in automotive supply chains, card-payment rules, and GDPR where you offer services to, or monitor, people in the EU. Cryptography belongs here too, since some countries restrict it. The common misunderstanding is that 'legal handles that'. The ISMS must know which obligations exist and give each an owner. If you keep an ISO 14001 or ISO 45001 compliance obligations register, extend it rather than starting another.

What auditors look for

Auditors ask for the requirements register and test it against what they know of your business: do you process personal information, take card payments, hold customer contracts with security schedules, operate in a regulated sector? They pick a requirement and trace it to the controls that meet it and to the last compliance check. They ask how the register is kept current — who watches for new regulations, amendments and Information Regulator guidance. They ask about cryptography used across borders. The hard question: which law affecting information security changed in the last year, and what did you do about it?

Typical evidence

Legal, regulatory and contractual requirements register with source, owner, linked controls and compliance check; process and records for monitoring legal changes; customer contract security requirements summarised in the register; legal advice obtained; compliance evaluation results; records of actions taken on new or amended requirements; assessment of cryptography use in each country of operation.

How to comply — recommendations

Build the register as a spreadsheet: requirement, source (law, regulation or contract), what it demands in plain words, owner, controls that meet it, evidence of compliance and date last checked. Start with POPIA, PAIA, the ECT Act, the Cybercrimes Act and your sector regulator's rules, then add the security clauses from your ten largest customer contracts. Give one person the job of watching for changes, through a law firm's updates or the regulators' websites, and review the register every six months. Evaluate compliance at least once a year and record the result. Link each entry to the controls in your Statement of Applicability so gaps are visible.

Common nonconformities

No register of legal, regulatory and contractual requirements; register missing obvious obligations such as POPIA or customer security schedules; no owner for each requirement; register not reviewed or updated after legal changes; no evaluation of compliance; contractual security requirements unknown to the people who must meet them; cryptography import or export rules not considered.

Resources for this clause

• ArticlePOPIA section 19 and ISO 27001: how the standard evidences the law — and why a certificate is not compliance
• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Free downloadPOPIA ↔ ISO 27001 CrosswalkTwenty-four POPIA and Regulation 4 duties in plain words, each mapped to the ISO/IEC 27001:2022 clauses and Annex A controls that evidence it — with the GDPR article and NIST CSF 2.0 category alongside, the evidence to show, and a status you mark.
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.