Thirty Days Out: Audit Evidence and Dry Runs
Thirty days out, the work turns from planning to proof. Every line on the request list should now have an owner, and the job is to gather audit evidence, test it the way the auditor will, and decide what to do about any gap you find.
This is also where a generic IT audit checklist stops being useful. A checklist tells you which topics an audit usually covers, whereas your request list tells you which documents this auditor will ask for, and it is the only list worth working from at this stage.
Build the Audit Trail From System Records, Not Memory
The strongest audit evidence is generated by a system at the time the control ran. An access review exported from the identity platform with a date and a reviewer's name. A change ticket showing the request, the approval and the deployment, or a backup job log. Auditors trust records like these because nobody had to remember anything to produce them.
The weakest evidence is assembled afterwards, such as a spreadsheet typed up last week to show reviews from last year. A screenshot of a settings page, which shows one moment and says nothing about the months before it. An email saying the check was done. Each may be true, but none leaves an audit trail an outsider can follow.
For each item on the request list, find the system record first. If only a reconstructed version exists, say so plainly in your tracker. Good IT audit documentation is not a thick folder. It is a record that shows the control ran, when, and who ran it, pulled straight from the place where the work happened.
Store the evidence in the same structure as the request list, with one folder per request number, so that the liaison can find any item in seconds when the auditor asks a follow-up question. Record in the tracker where each file came from and who pulled it, because an auditor who asks how a report was produced deserves an answer from the person who produced it, not a guess from whoever happens to be in the room.
Run a Self-Assessment on Controls That Failed Before
A self-assessment is a dry run of the audit on a small scale. Pick the controls that produced findings last time, plus any that changed owner or system this year, and test them the way an auditor would.
That means sampling, not reading policy. Take a handful of users and check their access against their current role. Take five production changes and look for the approval and the test record. Pick one quarter and look for the access review. Pick one system and check when it was last patched. What you are doing is a gap analysis, and it works only if the person doing it is not the person who runs the control.
Write down what the self-assessment found, even when it found nothing, and keep the notes with the evidence. If a sample fails, look at a few more before you decide what it means, because the auditor will do the same thing and you want to know first whether you are looking at a single slip or a control that stopped working for a whole quarter.
Focus on access review and change management first. They are the two areas where evidence most often fails to cover the full period. If application security is in scope, check that your testing records exist too. Our post on security testing explains what those records should show.
Fix, Disclose or Document: Handling Remediation Gaps Before Fieldwork
Every self-assessment finds something. At thirty days you have three honest options for each gap, and pretending it is not there is not one of them.
Fix it, if the fix is small and the evidence will then cover a meaningful part of the audit period. A missing log setting corrected now is a real improvement. Document it, if a compensating control covered the risk while the main one failed. If quarterly reviews were missed but every leaver was removed on the day by HR's own process, that is worth writing down with evidence. Disclose it, if neither applies, and plan remediation with an owner and a date so the finding arrives with its answer attached.
When to Raise a Known Information Security Gap Yourself
Raise a gap yourself when the auditor is going to find it anyway, which, with a sampled control, is almost always. A gap raised in the opening meeting reads as a team that knows its own environment. The same gap found in week three reads as one that does not, and it colours how the auditor treats everything after it.
Bring it with your own risk assessment: what the gap exposes, what reduced the risk in the meantime, and what remediation is under way. Auditors still record the finding, but a disclosed information security gap with a plan behind it usually carries a lower rating and a calmer conversation than a discovered one.
