Logging

Plain-language summary

Recording activities, exceptions, faults and security events on your systems, protecting those records from tampering and loss, keeping them long enough and analysing them — so you can detect incidents and reconstruct what happened.

What the clause is really asking

Logs are the evidence base for almost every incident decision you will make. POPIA section 22 requires you to notify the Information Regulator and affected people where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, and without logs you cannot tell whether the attacker read the customer database or only touched one laptop. The control asks you to decide what to log on each system — sign-ins and failed attempts, use of privileges, configuration changes, access to sensitive data, security tool alerts, system faults — with enough detail to be useful: user, time, device, source address, action. Logs must be protected so that administrators cannot alter or delete records of their own activity, stored with enough capacity, retained for a defined period, and analysed. Personal information inside logs needs protecting too. The common misunderstanding is that logging is on by default; many cloud services keep logs for a limited period unless you extend retention or export them, and many on-premises devices keep logs only locally until they are overwritten.

What auditors look for

Auditors ask for the logging standard: which systems log what, where logs go and how long they are kept. They then check a sample — the identity provider, the firewall, the ERP, a file server — and ask you to retrieve a specific event from three months ago, such as a named user's sign-ins or a configuration change. They check whether administrators can delete logs, whether logs are forwarded to a central store, and whether timestamps line up across systems. They ask who reviews logs, how often, and for evidence of the last review. The hard question: if a customer database had been accessed in March, could you prove who accessed it?

Typical evidence

Logging standard listing systems, events logged, destination and retention; log source inventory; central log collection or SIEM configuration; retention settings in cloud services and devices; access controls protecting logs from alteration or deletion; log review records; examples of events retrieved for investigations; records of logging failures and their correction.

How to comply — recommendations

Write a one-page logging standard. List your log sources — identity provider, email and cloud tenant, firewall, VPN, servers, ERP, endpoint protection — and for each state what is logged, where it goes and how long it is kept; twelve months is a common target where storage allows. Forward logs to a central store your administrators cannot edit: a SIEM, a managed detection service or at least a separate cloud log workspace. Check retention in every cloud service and extend or export where the default is short. Test retrieval quarterly by pulling a specific old event. Alert on logging failures. Agree with your MSP who reviews what, and keep the evidence. Build the link from logs to your POPIA breach assessment into the incident procedure.

Common nonconformities

No defined logging requirements; key systems not logging security events; log retention too short to support investigations; logs held only on the device that generates them; administrators able to delete or alter logs; logs collected but never reviewed; logging failures unnoticed; inability to retrieve a specific historical event when asked.

Resources for this clause

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