Findings, Reporting and Follow-Up

Findings, reporting and follow-up. This is the last lesson in Domain 1, and it is about turning what you found into something management can act on, and then making sure they actually did.

Start with a finding that is true and useless. You write: user access reviews are not being performed in accordance with policy. Management reads it, agrees that it is true, and asks what they should do about it. And you realise you have not told them, because you never established why it is happening. A finding that only says a rule was broken leaves everyone stuck.

A complete finding contains four elements, and the exam tests which one is missing far more often than it tests the list itself. The four are condition, criteria, cause and effect. Miss any one and the finding cannot do its job.

Condition is what you found, the factual state of affairs, stated without judgement. Access reviews were performed in two of the four quarters. Just the fact.

Criteria is what should be the case, and by whose authority. Policy, standard, regulation, contract, or accepted good practice. The information security policy requires quarterly reviews. Without criteria, a finding is just an opinion.

Cause is why the condition exists, and this is the element most often absent. It is what makes the finding actionable. Review scheduling depended on a single manual reminder held by one administrator, who left in March. Now management knows what to fix.

And effect is the consequence or risk that arises, the second most often absent. It is what makes the finding matter, and what tells management how urgently to act. Inappropriate access may persist undetected for up to six months, including access still held by leavers. Condition and criteria tell them a rule was broken. Cause tells them what to fix. Effect tells them how much to care.

One warning on cause: it is not the same as the immediate trigger. The reminder-holder leaving is the trigger. The root cause is that a control depended on one person calendar with no process ownership behind it. Fix the trigger and you get a new reminder for a new person. Fix the root cause and you get a scheduled, owned and monitored process. Exam scenarios often offer both, and expect the structural answer.

Now, management disagrees and decides to accept the risk. This is the point candidates get wrong most. Accepting risk is a management prerogative, not an audit decision. So you report the finding regardless, you record the acceptance, and you satisfy yourself that whoever is accepting it has the authority for a risk of that size. A team leader cannot accept an enterprise-level risk. What you do not do is remove a supported finding, soften it, accept the risk yourself, or run to a regulator. If you believe the accepted risk is genuinely unacceptable to the organisation, the route is escalation to the audit committee or board, the parties who can overrule it.

Then follow-up, and this is where audit functions quietly fail. Follow-up determines whether the agreed remediation was implemented and is effective. The essential point: closure requires audit evidence, not management confirmation. A written statement that the control is now working is a representation, which sits at the very bottom of the reliability hierarchy. You test the remediated control, at a scale proportionate to the risk, before you close the finding. Closing on assurance is the single most common real-world audit failure, and it is heavily tested.

Two more concepts to know. Control self-assessment has process owners evaluate their own controls, with audit facilitating rather than performing. It widens coverage and raises control awareness, but it is not independent, so it supplements audit and never replaces it. Any option treating self-assessment results as a substitute for audit testing is wrong. And quality assurance of the audit function itself, internal review of engagements plus periodic external assessment, exists because the function that assures everyone else is expected to be assured too, and internal review of your own function has the same independence problem audit exists to solve.

And that is Domain 1. You have covered the standards, independence, planning, materiality, the types of testing, design versus operating effectiveness, sampling, evidence, the test methods, and now findings and follow-up. The best next step is not to re-watch, it is to test yourself under time. Go to marcoweb dot org, sit the timed practice exam, and let the score by topic tell you exactly which of these lessons to come back to.