UnixTime

Research Note

A.6.8 Audit Evidence Pack

  • Updated Jun 17, 2026
  • Read 02 mins read
  • Status reviewed

The auditor wants proof that reporting channels are known, usable, timely, and connected to event assessment and incident management.

On this page

What the auditor wants to verify

Audit objective

Verify that personnel can report observed or suspected information security events through appropriate channels in a timely manner.

The auditor wants proof that reporting channels are known, usable, timely, and connected to event assessment and incident management.

Evidence to request

Evidence Purpose
Event reporting procedure Shows reporting process is documented
Reporting channel register Shows contact points are defined
Event report form Shows standard reporting information is captured
Awareness/training records Shows personnel were trained to report
Event register Shows reports are recorded
Triage records Shows reported events are assessed
Incident response records Shows confirmed incidents are handled
Corrective action records Shows root causes are addressed
External notification criteria Shows escalation obligations are defined
Interview evidence Shows personnel know what and how to report

Strong evidence

Strong evidence test

Strong evidence shows that personnel know the channel, reports are recorded, and events are assessed to closure.

  • Reporting procedure covers observed and suspected events and weaknesses.
  • Personnel can identify reportable examples across IT, paper, physical, and human scenarios.
  • Reporting channels are easy to find.
  • Forms capture useful incident-management information.
  • Reports are recorded, triaged, investigated, and closed.
  • Root causes and corrective actions are tracked.
  • Users are told not to exploit weaknesses.
  • External notification criteria and timelines are defined.

Weak evidence

Weak evidence warning

Weak evidence usually shows a mailbox exists but not that event reporting works.

  • Staff report only to informal IT contacts.
  • No reports exist and no awareness evidence explains why.
  • Staff think only confirmed cyber incidents should be reported.
  • Forms are hard to find or incomplete.
  • Reports are logged but not assessed.
  • No root-cause or closure records.
  • Users are encouraged to prove weaknesses.

Sample interview questions

Ask personnel

  • What would you report as a security event?
  • Who would you report it to?
  • Would you report a lost paper file or open safe?
  • What should you avoid doing if you find a weakness?

Ask service desk or security

  • How are reported events recorded and triaged?
  • How do you distinguish events from incidents?
  • How are root causes and corrective actions tracked?

Ask management or legal/compliance

  • What events require external notification?
  • How are contractual or regulatory timelines handled?

Common nonconformities

  • No clear event definition.
  • Reporting channel unclear.
  • Personnel unaware of responsibility to report.
  • Events reported informally but not recorded.
  • No timely reporting expectation.
  • No triage or investigation record.
  • No external notification criteria.
  • No procedure telling users not to exploit weaknesses.
  • Iso27001
  • ISO27002
  • Audit
  • Evidence
  • A6 8

Note Metadata

Aliases: A.6.8 Evidence

Source: 04 Audit Evidence Packs/A.6.8 Audit Evidence Pack.md

Graph-sourced resources

Templates and evidence

Auditor evidence packs

Evidence collections and audit-facing verification material.