All posts

What an Auditor Will Ask For, and Why

The evidence requests that arrive in week one of most engagements, what each is really testing, and how to have it ready.

Published 4 min readBy the Auditly teamDiesen Beitrag auf Deutsch lesenLire cet article en français

The first evidence request in an audit is where a lot of engagements go wrong. Not because the questions are hard, but because they are answered with the wrong artefact - a policy where the auditor asked for proof the policy ran, a screenshot where they asked for a list, a description where they asked for a date.

What follows is the set of requests that turns up in the first week of most information security engagements, what each one is actually testing, and what a good answer looks like.

Access reviews

Asked for: evidence that user access to key systems was reviewed, with the review's date, who performed it, and what changed as a result.

Testing: not whether you have an access review policy. Whether a review happened, on a schedule, and whether anything came of it.

A good answer: the export the reviewer worked from, their sign-off, and the tickets for the accounts that were removed or downgraded. A review that found nothing to change, every quarter, for a year, invites a question about how carefully it was done.

A poor answer: the policy document that says reviews occur quarterly.

Leaver access removal

Asked for: a list of people who left during the period, with the date each one's access was revoked.

Testing: the gap between the two dates.

A good answer: an HR list and an identity provider log that can be joined on person and date. If the gap is occasionally days rather than hours, say so and show the exception handling - auditors are considerably more comfortable with a known weakness that is managed than with a claim of perfection the sample contradicts.

A poor answer: an offboarding checklist template.

Change management

Asked for: a sample of changes to production, with evidence of review and approval before deployment.

Testing: that the process you describe is the process that ran, including for urgent changes.

A good answer: pull requests with approvals, linked to deployments, for the sample dates they pick. Be ready for them to pick the awkward dates - a release on 23 December is more informative than one in the middle of a calm week.

A poor answer: the branching strategy in your engineering handbook.

Backups and restoration

Asked for: evidence that backups run, and evidence that a restoration has been tested.

Testing: the second half. Almost every company backs up. Far fewer have restored.

A good answer: the schedule, the success logs, and a record of a restoration test with its date, what was restored, and how long it took.

A poor answer: the backup configuration screen.

Risk assessment

Asked for: your risk register, when it was last reviewed, and how treatment decisions were made.

Testing: whether risk management is an activity or a document.

A good answer: a register with owners, dates, and evidence that entries moved - risks accepted with a named accepter, risks mitigated with the work that mitigated them.

A poor answer: a register where every entry was created on the same day and nothing has changed since.

Supplier and subprocessor management

Asked for: your list of suppliers with access to data or systems, the due diligence performed, and the contractual terms covering security.

Testing: whether you know who your suppliers are.

A good answer: a maintained list that matches your actual spend and your actual integrations. The list and the invoices should not disagree.

A poor answer: the three large vendors everyone remembers, without the small tool a team adopted last quarter.

Incident records

Asked for: incidents during the period, with timelines, actions and outcomes.

Testing: whether incidents are recorded consistently, including the small ones.

A good answer: a register including minor incidents that were handled quickly. "No incidents" over a twelve-month window is not the strong answer it appears to be; it usually means small ones went unrecorded.

A poor answer: the incident response plan.

Training and awareness

Asked for: completion records for security training, with dates and coverage.

Testing: coverage, not content. Who did not complete it, and what happened next.

A good answer: the completion export including the gaps, with evidence of follow-up.

The pattern

Every one of these has the same shape. The auditor asks for evidence that something happened; the instinctive response is to send the document that says it should happen. Policies establish intent. Evidence establishes operation. An engagement runs quickly when the second is ready, and slowly when the first arrives instead and the real request has to be made twice.

Two habits make the difference, and both are cheap if you start before the engagement rather than during it.

Record the date and the actor. Most evidence questions reduce to who did this, and when. Artefacts that carry both answer the question the first time.

Keep the exceptions. The instinct is to present a clean record. A record with no exceptions, over a year, reads either as unusually disciplined or as incomplete, and the auditor's job is to work out which. Showing the exception and how it was handled is a stronger position than showing none at all.

ShareLinkedInXEmail
Keep reading