Addressing information security within supplier agreements

Plain-language summary

Writing the security requirements that matter for each supplier into the agreement itself — what information is involved, how it must be protected, whether work may be subcontracted, how incidents are reported, your right to audit, and what happens to your information when the relationship ends.

What the clause is really asking

A requirement that lives only in your policy binds nobody outside your organisation. This control asks you to set and agree the relevant security requirements with each supplier, scaled to the type of relationship, and to put them in writing. Typical contents: a description of the information and its classification; the controls the supplier must operate (access control, encryption, backup, screening and training of its staff); acceptable-use rules; incident notification with a time limit and a named contact; limits on subcontracting and a duty to pass the same terms down; your right to audit or to receive assurance reports; legal requirements such as data protection and intellectual property; and return or destruction of information at termination. The common misunderstanding is that a confidentiality clause is enough. Under POPIA section 21 the agreement with an operator must be in writing and must require the security measures of section 19. Financial institutions under FSCA/PA Joint Standard 2 of 2024 are expected to carry their cyber security requirements into third-party contracts, so suppliers to banks and insurers should expect these clauses.

What auditors look for

Auditors take the tier-one suppliers from the register and ask for each signed contract, then read it against your own requirements. They look for specific clauses, not a general undertaking: incident notification and its time limit, subcontracting, right to audit, return or destruction at exit, and the security measures the supplier must keep. For operators processing personal information they check the written agreement meets POPIA section 21. They ask how clauses are chosen — is there a standard schedule, or does each contract depend on the supplier's own paper? The hard question: show me the contract for the supplier with the most access to your data, and point to the breach notification clause.

Typical evidence

Supplier security requirements schedule or clause library by tier; signed contracts and service agreements; written operator agreements meeting POPIA section 21; confidentiality agreements; contract review checklist showing security clauses checked before signature; register of agreements with renewal dates; records of negotiated deviations and their risk acceptance; flow-down terms received from regulated customers.

How to comply — recommendations

Draft a standard information security schedule that can be attached to any contract, with a short version for low-risk suppliers and a full version for tier-one suppliers and operators. Include incident notification within a set number of hours, subcontracting only with consent and on the same terms, a right to audit or an annual assurance report, security measures matching POPIA section 19, and return or destruction with a certificate at exit. Agree with whoever signs contracts that no tier-one agreement is signed without the schedule or a recorded deviation. Work through existing tier-one contracts at renewal, starting with the IT provider and every operator, and add operator agreements where they are missing.

Common nonconformities

Contracts with privileged-access suppliers silent on security; no written operator agreement as POPIA section 21 requires; no incident notification clause or time limit; no right to audit or assurance requirement; subcontracting unrestricted; nothing on return or destruction of information at termination; supplier's standard terms accepted without review against the organisation's requirements.

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
• 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.