Passwords & Backups
Password hygiene auditing per account, and verification that your backups are actually running.
Last reviewed:
Reused passwords and backups that were "supposed to" be running are the most common cause of incidents that actually hurt — and almost nobody audits them systematically, because there is no screen to look at.
What it measures
Two things that are almost always assumed and almost never checked:
- Passwords — per account: age, whether it meets your length policy, whether it is reused on other systems, and whether it appears in a known leak.
- Backups — whether each backup job ran when it should have, and whether it finished cleanly or failed.
How to set it up
Passwords
The audit is manually entered: you record one account at a time with the employee's email, the system (Google Workspace, the VPN, the ERP), the password's age in days, whether it meets the length policy, and whether it is reused elsewhere.
Backups
- 1
Register the backup job
Name, system, and expected frequency — daily, weekly, or monthly. The frequency is what makes an overdue backup detectable: without it there is nothing to compare against.
- 2
Wire up automatic reporting (recommended)
Each job has a command with its own token that your backup system, or a script at the end of the process, runs to report each execution. It is the only way the status reflects reality rather than a checkbox someone ticks from memory.
- 3
Or confirm by hand
If you cannot automate it yet, *Mark run successful* or *failed* records the run manually. It works, but it leaves the data at the mercy of someone remembering.
The webhook token is unique per job. If it is compromised, regenerate it from the detail view — the previous command stops working immediately, so it has to be updated wherever it was configured.
How to read the result
The overview summarizes audited accounts, leaked passwords, reused passwords, and backups at risk. Each backup job also carries its own health status:
| Status | What it means |
|---|---|
| On time | Reported a successful run within the expected frequency. |
| Overdue | The window passed and nobody reported anything. It is the most dangerous status, because it looks like silence and is usually failure. |
| Failed | It ran and ended badly. At least you know. |
| No data | The job is registered but has never reported a run. |
What to do with a finding
- Leaked password — change it today and find out where else that same password was used. Cross-reference with Breach Exposure if you have that module: it is usually the same person.
- Reused password — the problem is not the account you are looking at, it is that a single leak opens several doors at once.
- Overdue backup — find out whether the backup failed or merely stopped reporting. Those are different things and only one of them is an emergency.
- Failed backup — fix it and then test a restore. A backup that has never been restored is an assumption, not a backup.