Audit readiness assessment: the dress rehearsal for your IT audit

An audit readiness assessment is the last check before the auditor arrives. The question is no longer what is missing, because the gap analysis at the start of the project answered that. The question is whether what has been put in place since then actually works, whether that can be proven, and whether the audit date can therefore stay where it is. The assessment produces no certificate and no assurance report. It produces an answer to that one question, with the supporting evidence per control.

The difference from a gap analysis lies in timing and method. A gap analysis compares the design with the standard: is there a policy, is there a process, is there an owner. A readiness assessment tests operation: has the process been followed over the past months, by whom, and where is that recorded. An organisation can have worked through the gap analysis list neatly and still not be ready, because the controls have only been running for two months or because nobody can pull the evidence together.

Test the way the auditor tests

The assessment only has value if it uses the same method as the audit that follows. That means three steps per control. First a walkthrough with the control owner: show how it works, from trigger to record. Then a population: all changes in the period, all new joiners, all leavers, all access reviews performed. Then a sample from that population, with the request to produce the evidence for each selected item.

That last step is what separates the assessment from a conversation. In an interview the owner says every change is approved. In a sample it becomes clear whether that approval was recorded for the five selected changes, by someone other than the requester, and before the change went to production. In an ISO 27001 certification audit the auditor works with samples; in a SOC 2 Type II or an ISAE 3402 Type II sampling is the core of the engagement. Anyone who limits the readiness assessment to interviews is rehearsing something other than what is about to happen.

Apply the same rules to the evidence as well. An auditor sends a request list with a deadline and expects evidence from the source: the ticket, the log, the export from the system, and not a screenshot made for the occasion. Measure during the assessment how long it takes before a request is answered. If the evidence for a routine control takes days of searching, that is a finding in itself, even if the evidence turns up in the end. What a usable evidence file looks like is covered in evidence in an IT audit.

Completeness of the population

For most organisations the list the auditor selects from is a bigger problem than the evidence per item. A sample only means something if the population is complete. Can you produce a list of all changes in the period, including manual adjustments and emergency changes outside the regular process? Of all accounts created, including service accounts and accounts for external staff? Of all incidents, including the ones handled entirely in a chat channel?

If the population has to come from several systems, the reconciliation is the work: the deployment list from the pipeline next to the change tickets, the HR list next to the account list. Whatever appears in one list and not in the other is exactly what the auditor is going to ask about. Do that reconciliation during the assessment, not during the audit.

Two kinds of gaps, only one of which can still be closed

The report should say for each finding what kind of gap it is. A documentation gap can be closed before the audit: a procedure that is followed but not written down, an approval that is recorded from now on, a policy document without an owner or version date. An operating gap cannot. A quarterly access review that was skipped in the second quarter stays skipped. Logs that were purged after thirty days while the observation period covers six months do not come back. A control introduced halfway through the period has no operation over the first half.

In a Type II report, operating gaps appear as exceptions. In a certification audit they lead to a nonconformity, and for a major one the correction must be verified before the certificate is issued; for a control that needs a period to run, that can mean the auditor has to come back. The outcome of the assessment is therefore a decision, with the action list as an appendix: the date stays, the period moves, or the organisation accepts that a specific exception will appear in the report and prepares its response to it. All three are defensible choices, as long as the organisation makes them itself rather than having them forced by the auditor.

What is often still missing just before the audit

A few topics come up in almost every assessment. For ISO 27001 it is the internal audit and the management review. Clauses 9.2 and 9.3 require both to have been carried out, and a certification auditor will not issue a certificate while they are still outstanding. An internal audit put together a week before stage 2 is recognisable to an auditor by the absence of follow-up. So do not schedule it as the closing act of the readiness assessment, but well before it, so the findings can still get a corrective action.

For SOC 2 and ISAE 3402 it is the system description. That belongs to the organisation, not the auditor, and describes the service, the boundaries of the system, the controls and the role of subservice organisations. In practice it is often written only when the auditor asks for it, and then it turns out the description and the control list do not match. The order in which to tackle this is in preparing for a SOC 2 audit.

And under every standard: the owner who cannot explain the control. A control that sits on paper with the head of IT but is in reality performed by an administrator who is not in the walkthrough makes for an awkward conversation in the audit. Put the people who do the work at the table during the assessment and let them point to the evidence.

Who performs the assessment

A readiness assessment can be done by the organisation's own internal audit function, provided it is sufficiently independent from the department that operates the controls and knows the audit method. For an organisation in its first cycle that is often too much to ask, and an external party is brought in.

Pay attention to the division of roles. For ISO 27001, the certification body may not advise on the management system it subsequently certifies, so the assessment comes from a different party. For SOC 2 and ISAE 3402, the reporting auditor may in principle assess beforehand whether the organisation is ready, as long as the organisation designs the controls and takes the decisions itself. The line is at designing and implementing controls: whoever does that can no longer report on them independently.

When you can skip it

Not every organisation needs a separate readiness assessment. If you are heading for a SOC 2 report, a Type I report can serve as the baseline. It tests the design at a point in time, enforces the same discipline, and produces a report you can show to customers. An organisation in its second or third cycle with a working internal audit programme has usually built the check in already. For a first certification or a first Type II period, skipping it is a gamble with the audit date as the stake.

If you want to know in advance whether the date can stay, see our compliance services. Where the assessment sits in the overall project is described in the ISO 27001 certification roadmap.