UnixTime

Research Note

A.5.17 Audit Evidence Pack

The auditor wants to confirm that secret authentication information is issued, managed, changed, reset, stored, and handled through a controlled process, and that users understa...

On this page

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 secret authentication information is issued, managed, changed, reset, stored, and handled through a controlled process, and that users understand their confidentiality responsibilities.

Evidence to request

Evidence Purpose
Authentication or password policy Shows credential rules are documented
Credential issuance procedure Shows allocation is controlled
Identity verification records Shows users are verified before issue/reset
User acknowledgement records Shows confidentiality responsibilities are accepted
Technical password/MFA settings Shows systems enforce policy
Password reset logs Shows reset process is controlled
Temporary/default credential change evidence Shows initial and vendor credentials are changed
Privileged credential vault logs Shows high-risk secrets are protected
Awareness training records Shows users are advised on handling
Authorized password quality assessment records Shows weak credentials are detected and addressed

Strong evidence

Strong evidence test

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

  • Credential allocation requires identity verification and authorization.
  • Initial credentials force change on first use.
  • Default vendor passwords are changed promptly.
  • Technical settings match documented policy.
  • Users acknowledge responsibility to keep credentials confidential.
  • Reset processes verify identity and are logged.
  • Urgent resets have follow-up review.
  • Privileged credentials and service secrets are controlled.

Weak evidence

Weak evidence warning

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

  • Passwords sent in clear text without forced change.
  • Default passwords remain in use.
  • Password reset relies on informal messages.
  • Users share credentials.
  • Recovery questions are weak or public.
  • Policy says one thing and systems enforce another.
  • Credential storage is uncontrolled.
  • Staff do not know how to report suspected credential compromise.

Sample interview questions

Ask users

  • What are your responsibilities for passwords, PINs, MFA devices, or recovery information?
  • Are you allowed to share credentials?
  • What do you do if you suspect your credential is compromised?
  • How do password resets work?

Ask identity or service desk staff

  • How do you verify a user’s identity before resetting credentials?
  • How are initial temporary passwords delivered?
  • Are users forced to change temporary credentials?
  • How are urgent resets reviewed?

Ask security or system administrators

  • Do technical settings match policy?
  • How are default vendor passwords controlled?
  • How are privileged credentials and service secrets stored?
  • Are password quality checks performed with authorization?

Common nonconformities

  • No authentication information management process.
  • Default or temporary credentials not changed.
  • Users not advised on credential handling.
  • Reset process lacks identity verification.
  • Shared credentials without compensating controls.
  • Technical settings inconsistent with policy.
  • Privileged or service credentials unmanaged.
  • No evidence of user acknowledgement.
  • Iso27001
  • ISO27002
  • Audit
  • Evidence
  • A5 17

Note Metadata

Aliases: A.5.17 Evidence

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

Graph-sourced resources

Templates and evidence

Auditor evidence packs

Evidence collections and audit-facing verification material.