8.3.7 Password history
Individuals are not allowed to submit a new password or passphrase that is the same as any of the last four used.
5
artefacts
1
held by a system
0
at each review
hard
to go live
Policy repository / GRC workspace
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
- Sample audit log of password change rejections · Identity provider / directory
periodic reviewEvidence produced at each review
none for this control
governing documentDocuments that govern the control
- Directory policy setting password history to four or more · Policy repository / GRC workspace
- Test attempting to reuse last four passwords (denied) · Policy repository / GRC workspace
- Coverage list of systems enforcing history · Policy repository / GRC workspace
- Policy document specifying history depth · Policy repository / GRC workspace
First move
Mostly documents and reviews. Pull the 1 system-held artefact from your Identity provider / directory on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.
Common gaps auditors find
- History depth below four
- Some apps exempt
- No reuse rejection logging
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: • A minimum length of 12 characters (or IF the system does not support 12 · 8.3.8 Authentication policy communicated