Protection of information systems during audit testing

What the requirement 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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Audit testing must not break the system. The guidance asks for the plan, the window, the supervision and the record.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep management approvals of auditor access requests and agreed scopes for technical audit tests and one live sample together.

Evidence an assessor asks for

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

The question an assessor will ask

An assessor will ask for management approvals of auditor access requests and agreed scopes for technical audit tests, then trace it to the system it protects. For A.8.34 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: external auditors are given full administrative accounts on production systems.