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.
Related notes
- 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.