Fourteen Months of Untested Backups and a Risk Acceptance Nobody Approved
It is day 3 of a 5-day Stage 2 audit. While interviewing a backup administrator, you learn that nightly database backups to tape have not been restore-tested since the platform went live 14 months ago, although procedure BKP-04 requires a quarterly restore test. The administrator shows a risk-register entry added by the IT manager eight months ago reading "restore testing not performed - risk accepted". The ISMS procedure requires risk acceptance by the named risk owner, and the register names the CTO as owner of that risk. In the opening meeting the CTO stated that restore testing is performed quarterly. The IT manager asks you not to write the finding up, because "we'll fix it next month" and it would embarrass the CTO in front of the board.
1. What is your criteria basis, and how do you grade this?
Read the worked answer
Criteria are concrete: procedure BKP-04 (quarterly restore test), clause 8.1 (processes carried out under controlled conditions, as planned), and 6.1.3 (risk treatment approved by the risk owner).
Before grading, I confirm the evidence, because a single interview is not enough:
- Any restore or disaster-recovery test record that would satisfy BKP-04 in substance.
- Monitoring or alerting that would detect failed or untested backups (a compensating control).
- Whether the backup media are even readable / whether the process is otherwise verified.
On what is described, there is a total absence of the control for 14 months and no compensating control, so the process cannot deliver its intended outcome. That is a major nonconformity. The "risk acceptance" does not neutralise it: acceptance by someone who is not the named risk owner is not acceptance under the organization's own procedure, so the risk was never validly treated.
I would also test whether the same authority problem affects other register entries - one invalid acceptance is rarely unique.
2. How do you handle the request to suppress the finding and the contradiction with the CTO's opening-meeting statement?
Read the worked answer
The finding is reported. An auditor reports what the evidence shows; embarrassment, timing and "we'll fix it next month" are not criteria for omission. A correction promised for next month is still, today, a nonconformity.
Process, though, matters as much as the conclusion:
- Verify and triangulate. Put the observation to the CTO and the backup administrator, separately, and give them a genuine opportunity to produce contrary evidence. Contradictory statements are themselves significant; I would record both statements, dated, with who said what.
- Report during the audit, not at the closing meeting. Nonconformities should be communicated to the auditee as they arise, so they can be understood and, if wrong, corrected with evidence.
- Escalate. The conflicting statements go to the audit team leader and are reflected in the report. If the CTO has given the board an inaccurate assurance, that is a matter for the auditee's management and for the management review, and I say so plainly.
- Confidentiality. I discuss it through the agreed reporting channel - the auditee's designated representative - not by circumventing management.
What I do not do is trade the finding for a commitment to fix it later.
3. Should the invalid risk acceptance be a separate nonconformity, and what else does it change about your audit?
Read the worked answer
There are two distinct failures: the control did not operate (BKP-04, 8.1), and risk acceptance authority was bypassed (6.1.3 plus the ISMS's own procedure). Separate requirements, separate evidence.
Whether to report as one or two: if the underlying cause is the same - the IT manager treating the register as a personal notebook - then two nearly identical findings add paperwork but not insight. My rule is that the auditee must be able to see exactly what failed and who must act. Typically that means reporting the untested backups as the major, and including the invalid acceptance in its description, while raising the acceptance-authority failure separately only if the sample shows it is systemic elsewhere.
What it changes in the audit:
- Expand the sample of risk-register entries to test who approved acceptance against the named owner.
- Test the treatment plan (6.1.3 e/f) and management review, to see whether unapproved acceptance was ever detected.
- Revisit the CTO interview to establish whether the owner knew of the risk at all - which determines whether this is one manager's error or a failing of the risk governance layer.