Protection of information systems during audit testing

Plain-language summary

Planning and agreeing audit tests and other assurance activities on live systems — penetration tests, vulnerability scans, auditors' system queries — with the right management, so the testing itself does not disrupt operations or expose information.

What the clause is really asking

Audits and technical tests touch live systems, and a badly run test can cause the outage or leak it was meant to prevent: a scan that crashes a PLC, a query that locks the ERP at month-end, an auditor's laptop leaving with a full customer extract. This control asks that nobody tests or audits live systems without a plan that the tester and the appropriate management have agreed beforehand. In practice: agree the scope and rules of engagement in writing; schedule disruptive tests outside business hours or production peaks; give auditors read-only access where possible, through accounts that are monitored and removed afterwards; take backups before intrusive testing; keep fragile systems such as OT and legacy equipment out of active scanning unless the vendor agrees; control any data the auditor takes away; and protect the findings, which are a map of your weaknesses. For penetration tests, the signed authorisation and agreed window protect both parties. The common misunderstanding is that this control is about the internal audit programme in clause 9.2; it is about protecting systems from the testing itself.

What auditors look for

Auditors ask for the last penetration test or technical assessment and look for the signed scope, rules of engagement, agreed dates and emergency contacts. They ask how the test was coordinated with operations — who knew, what was excluded, whether production equipment was protected — and whether anything was disrupted. They check that tester and auditor accounts were created for the period and removed afterwards, and how reports are stored and who can read them. They ask how data taken for audit sampling was handled. The hard question: who in operations approved the test window, and how would they have stopped the test?

Typical evidence

Procedure for planning audits and technical tests; signed scope and rules of engagement for penetration tests; authorisation letters; test schedules agreed with operations; temporary account creation and removal records; backup records before intrusive tests; exclusion list for fragile systems; secure storage and distribution of reports; records of data provided to auditors.

How to comply — recommendations

Create a one-page rules-of-engagement template for any test on live systems: scope and exclusions, dates and hours, tester identity and source addresses, emergency stop contacts on both sides, data handling and report confidentiality. Have it signed by IT and the operations owner before testing starts. Schedule intrusive tests away from month-end and production peaks, and exclude PLCs and other fragile OT unless the vendor agrees and an engineer is standing by. Create time-limited, read-only auditor accounts and remove them afterwards. Take backups before intrusive work. Store reports encrypted with restricted access.

Common nonconformities

Penetration tests run without signed scope or authorisation; testing scheduled without telling operations; scans disrupting production systems or OT equipment; auditor or tester accounts left active after the engagement; auditors given write access where read-only would do; test reports distributed by unencrypted email; data extracts handed to auditors without control.

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.