A.5.8 Audit Evidence Pack

What the auditor wants to verify

Audit objective

This is the core audit assertion. Evidence should prove design, implementation, and operation.

The auditor wants to confirm that information security is integrated into the project management method and applied in real projects from initiation through transition to operations.

Evidence to request

Evidence	Purpose
Project methodology or delivery framework	Shows security is required in project governance
Project security risk assessments	Shows information security risks were identified
Project risk register cross-reference	Shows security risks are visible to project governance
Security requirements register	Shows requirements were defined and tracked
Requirements documents	Shows security was included with functional requirements
Design or acquisition review records	Shows security was assessed during solution selection
Supplier or COTS security assessments	Shows purchased systems and add-ons were evaluated
Project RACI	Shows security responsibilities were assigned
Change request security reviews	Shows project changes triggered reassessment
Security test results	Shows requirements were validated
Defect and remediation records	Shows gaps were tracked and resolved
Transition or go-live checklist	Shows controls were handed over into operations
Residual risk acceptance	Shows unresolved risks were approved appropriately

Strong evidence

Strong evidence test

Prefer dated, owned, reviewed records that show the control operated for real cases.

Methodology requires security objectives, risk assessment, requirements, checkpoints, testing, and transition controls.
Sampled projects have security risk assessments separate from delivery risk.
Security requirements are traceable to risks, controls, owners, and tests.
Project changes include security impact review.
COTS, customizations, and integrations are assessed.
Security test failures are remediated or formally risk-accepted.
Operational handover includes control owners, evidence, monitoring, and support.

Weak evidence

Weak evidence warning

Weak evidence usually shows a document exists but does not prove operation or effectiveness.

Security appears only as a late go-live approval.
Project risk register contains vague security items with no control owner.
Requirements documents omit security.
Testing covers only functionality.
Commercial software is accepted without security review.
Security controls are descoped without risk acceptance.
Operations receives the deliverable without security evidence or owners.

Sample interview questions

Ask project managers

Where does the project method require security review?
How are information security risks identified separately from delivery risks?
How are security requirements tracked?
What happens when project scope or architecture changes?
Who approves unresolved security risks?

Ask security or risk staff

How are projects identified for security involvement?
How do project risks feed the ISMS risk process?
How do you verify security requirements before go-live?
Can you show a recent project where security changed a design or requirement?

Ask business or system owners

What security controls were delivered with the project?
Who owns those controls after go-live?
Where is the evidence that the controls work?

Common nonconformities

Project methodology does not mention information security.
Security risk assessment not performed for sampled projects.
Security requirements not documented.
Requirements not tested.
Security responsibilities not assigned.
Project changes do not trigger security reassessment.
Residual security risks not escalated.
Transition to operations does not include security controls or evidence.

Iso27001
ISO27002
Audit
Evidence
A5 8

Note Metadata

Aliases: A.5.8 Evidence

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

Graph-sourced resources

Templates and evidence

Auditor evidence packs

Evidence collections and audit-facing verification material.

A.5.8 Audit Checklist