Protection of information systems during audit testing

What the control asks

Audit tests and other assurance activities that assess operational systems need a plan agreed in advance by whoever tests and the relevant managers. Purpose: keep the effect of audits and other assurance work on operational systems and business processes as small as possible. Guidance: get the relevant managers to agree what systems and data auditors may reach; agree and control the scope of technical audit tests; keep audit tests to read-only use of software and data, and where read-only access cannot obtain the needed information, have an experienced administrator with the required rights run the test for the auditor; if access is granted, set and check the security requirements, such as anti-virus and patching, of the laptops or tablets used before allowing access; allow wider access only to separate copies of system files, removing those copies after the audit or protecting them appropriately if audit documentation rules require keeping them; identify and agree requests for special or extra processing such as running audit tools; run tests that could affect availability outside business hours; and monitor and record every access made for audits or tests. Audits and assurance tests on development and test systems can also affect code integrity or expose sensitive information held there.

Purpose in the standard’s terms, in our words: Keeps the disruption audits and assurance work cause to live systems and business processes small.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; System and network security, Information protection; Governance and ecosystem, Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• Management approvals of auditor access requests and agreed scopes for technical audit tests
• Evidence that auditor access was read-only, or that tests were run by an authorized administrator on the auditor's behalf
• Security checks of auditor devices (patching, anti-malware) before access was granted
• Records of isolated file copies provided for audit and their deletion or protection afterwards
• Schedules showing availability-affecting tests run outside business hours
• Logs of all access performed for audit and testing purposes

Where audits commonly find gaps

• External auditors are given full administrative accounts on production systems
• Audit tools are run in production during peak business hours without agreement
• Auditor laptops connect to internal networks without any security check
• Audit accounts remain active after the audit ends

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 2 operational capabilities, so two teams share the work and the owner column matters. Its earlier numbering (12.7.1) is kept in the register so an older audit file can still be traced. It serves more than one security domain, which is why a domain count taken by row understates the view.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 8.30 Outsourced development
• 8.7 Protection against malware
• 5.10 Acceptable use of information and other associated assets

Read the five attributes All 93 controls