Audit Methodology·~15 min read·2,910 words

Ten things to do in the four weeks before any compliance audit

Practitioner reference for CISOs, compliance leads, and audit project owners · 2026-05-24 · Written from twelve years of running pre-audit reviews across ISO 27001, SOC 2, RBI CSF, SEBI CSCRF, PCI DSS, and DPDPA engagements

Why this list exists

The single largest factor in whether an audit goes well is what happened in the four weeks before the auditor arrived. Not the year of policy work. Not the maturity of the control programme. Not the QMS. The four weeks before. Specifically, what you did to make sure the auditor's first impression matched the reality of your control posture, and what you did to surface and pre-empt the questions you knew were coming.

This is the operational checklist I run when a client engages me to do a pre-audit review. It is not a substitute for the control work itself — if your controls are not in place, four weeks will not save you. It is the difference between a control programme that audits cleanly and a control programme that creates twelve findings because of mostly fixable presentation, documentation, and evidence-trail issues.

The list is opinionated. I am writing this from the perspective of someone who has been on both sides of the table — running internal audits, running pre-audit reviews as an external consultant, and being the one in the conference room when the external auditor arrives. The order matters. The first five items are non-negotiable; the rest are high-leverage but skippable in time-pressed engagements.

1. Lock the evidence library at T-minus-4-weeks

The single most common reason audits go badly is that the evidence the auditor asks for either doesn't exist, can't be located, or is out of date.

Four weeks before the audit, do an evidence sweep. For every control in scope, identify:

  • The artefact that demonstrates the control's existence (policy, procedure, standard)
  • The artefact that demonstrates the control's operation (log, ticket, report, screenshot)
  • The artefact that demonstrates the control's effectiveness (test result, KPI metric, exception report)

Put them in a single location — typically a shared drive folder structured by control family. Tag each with the period it covers. Verify the dates haven't drifted. If the evidence is 18 months stale and the audit period is 12 months, that's a finding.

You do not need a fancy tool for this. A spreadsheet that maps control_id → evidence_artefact → location → period_covered → owner → last_reviewed is enough. The goal is not elegance. The goal is that when the auditor asks for evidence of control X, the person taking the request can find it in 90 seconds.

I've watched audits go off the rails because someone said "let me get back to you on that" forty-seven times in three days. By the third day the auditor has decided that the control programme is not real. By the fifth day they're writing findings.

2. Run a tabletop on the three highest-stakes scenarios

Pick three scenarios that are likely audit deep-dives. For an RBI inspection at a bank: ransomware response, a major fraud incident, a vendor breach. For an ISO 27001 surveillance: access removal on termination, BCP test execution, vendor risk assessment cycle. For DPDPA: a Data Principal rights request, a personal data breach, a Consent Manager flow.

Run a tabletop. Walk through the scenario end-to-end with the actual people who would be involved. Note where the process is ambiguous, where ownership is unclear, where the documented procedure diverges from what someone would actually do under pressure.

Then fix the gaps. Either by updating the procedure to match what would actually happen (most common), or by training people on what the procedure says (rare and often unrealistic in four weeks).

The auditor will simulate exactly this kind of scenario walkthrough during fieldwork. If the team's first practice run is in front of the auditor, that's an avoidable disaster.

3. Resolve all open exceptions

Go through your exception register. Anything open at audit time becomes a question. Anything that should have closed but didn't becomes two questions.

For each open exception:

  • Is it actually still applicable? Many exceptions are residue from changes that long since occurred. Close the ones that no longer apply with a documented rationale.
  • Is it within the agreed expiry? If it has expired without renewal, that's a process failure. Either renew with proper approval or remediate. Don't leave expired exceptions floating.
  • Is there compensating control documentation? If the exception is "we can't enforce MFA on system X because of legacy auth," the compensating story needs to exist: how is this risk being managed in lieu of MFA? Without that story, the auditor will write up the absence of MFA as a finding regardless of the exception.

A clean exception register signals control discipline. A messy one signals the opposite. Auditors read the register before deciding which controls to dig into.

4. Walk the access lists with someone who actually knows the team

Three days before fieldwork starts, sit down with someone who knows your organisation's people — typically an HR business partner or a long-tenured manager — and walk every privileged access list together.

For each high-privilege role:

  • Does this person still work here? (You'd be amazed.)
  • Does this person still need this access for their current role? (Promotions and team changes create stale entitlements that quarterly access reviews miss.)
  • Are there service accounts here that should be tagged differently?
  • Are there break-glass accounts that should be locked and audited rather than active?

The auditor will run this exercise themselves. They will pick three or four people from your access lists and ask: who is this person, what do they do, why do they need this access. If you can answer all three in two sentences, you pass. If you can't answer any of them, the auditor concludes that access review is theatre.

The reason this works is that access drift is the most common control failure I see in mature organisations. The controls exist. The reviews happen. But the reviews are rubber-stamped, and entitlement creep accumulates. A pre-audit walk-through with someone who knows the team catches the worst of it.

5. Make sure the policies on the shared drive are the ones the people in the building actually follow

The single highest-frequency finding I have ever written, across every framework, is some variant of "the documented procedure differs from observed practice."

Walk into your engineering team, your operations team, your customer support team. Ask them how they do something — patch a server, respond to a customer complaint, escalate a security alert. Compare what they say to your documented procedure.

If the answers diverge, you have a choice: update the document to match reality, or train the team to match the document. The first is usually correct; documents lag practice in healthy organisations. The second is necessary where the document represents a genuine compliance requirement (e.g., 6-hour CERT-In reporting, 72-hour DPDPA breach notification).

Either way, the document and the practice need to converge before the auditor interviews the team. This is the single largest yielder of operational findings, and it is entirely preventable.

The hardest cases are where the policy says one thing, the team has been doing another for two years, and nobody has noticed. The auditor will notice in the first interview. Better that you notice three weeks earlier and either fix the policy or fix the practice.

6. Pre-stage the awkward conversations

Every organisation has them. The vendor that hasn't been properly assessed because nobody wants to flag the executive sponsor. The legacy system on Windows Server 2012 that "isn't in scope" but actually processes regulated data. The shared admin account that everybody uses but nobody owns.

You know what they are. The auditor will find them. Better to surface them yourself, on your terms, with a written remediation plan and a mature framing, than to have them discovered.

Sit with the audit lead beforehand and frame the issue: "We have known weakness in vendor X's assessment depth; here is what we've done, here is what we plan to do, here's the timeline." Auditors are not adversaries. They are paid to surface issues. When you've already surfaced an issue with a plan, they write it up as an observation with mitigation, not as a finding. When they have to find it themselves, it becomes a finding with executive escalation.

Auditors talk to each other. Reputational signal: organisations that pre-empt issues are easier to work with and tend to get less aggressive findings on borderline calls. This is real and it compounds across multi-year engagements.

7. Confirm scope in writing, in detail, with the audit firm — before fieldwork

Scope ambiguity is the second-most-common cause of audit pain. The audit firm's engagement letter says "ISO 27001 surveillance for the EMEA business." Does that include the Indian subsidiary that delivers EMEA's IT? Does the Indian subsidiary's RBI controls show up? Does the Indian subsidiary's HR system, which holds EMEA employee data, fall under the audit?

If you can't answer these questions cleanly four weeks out, you will be answering them under duress two days into fieldwork. The audit team will expand scope on the fly. New evidence requests will appear. Your team's bandwidth will be eaten by scope renegotiation rather than substantive work.

Email exchange. Confirm scope in writing. Specifically: entities in scope, geographies in scope, systems in scope, processes in scope, data categories in scope, time period in scope. Get the audit firm to acknowledge in writing. This single hour of work saves days during the audit.

8. Train the interview targets

Decide ahead of time who will be interviewed by the audit team. Typically: the CISO, the head of IT operations, the head of compliance, the head of HR, the head of vendor management, one or two control owners.

Brief each of them on what to expect. Not in the sense of coaching them what to say (that's manipulation and the auditor will see it). In the sense of helping them understand the audit objective, the structure of the conversation, and how to answer.

Specifically:

  • Answer the question you were asked. Do not volunteer adjacent information. Auditors will follow leads; you do not need to give them additional leads.
  • "I don't know" is an acceptable answer when paired with "let me find out and come back to you." Bluffing is not.
  • Concrete examples beat abstract descriptions. "Last quarter we had three terminations. For each, access was disabled within four hours. Here are the tickets" beats "We have a robust JML process."
  • It is okay to take a break to find documentation. The audit is not a hostile interrogation.

The dynamic of being interviewed by an auditor is unfamiliar to people who don't do it regularly. Twenty minutes of preparation prevents the kind of weak answers that get noted, prompt deeper investigation, and waste fieldwork time.

9. Run the BCP/DR test results check

For most frameworks, the BCP/DR test is a hard-required artefact. RBI inspectors care about it deeply, especially after major outages in 2024-2025. ISO 27001 surveillance increasingly does too. PCI DSS v4 ramps the requirement.

Verify, three weeks out:

  • A BCP test was conducted within the audit period
  • The test results document exists, is signed off by the appropriate executive, and is dated within the period
  • Findings from the test have either been remediated or have remediation tracked
  • The test scenario was non-trivial (a full datacentre failover, not a desktop walkthrough)
  • The test had real participants (the executive sponsor showed up; the technical lead led the response; there was a real-time decision log)

The "we did a tabletop and called it a DR test" approach is increasingly being marked as insufficient by inspectors. If your last DR test was a desktop walkthrough done at year-end to tick a box, that's a finding waiting to happen.

If your test was last done eighteen months ago and you're getting audited next month, do an emergency test. A tabletop is better than nothing, but a live failover for at least one critical system is the gold standard.

10. Personally read the last three internal audit reports

Whatever your last three internal audit reports said, the external auditor read them too. They will start their fieldwork from the open findings in those reports and ask about progress on each.

You should know, for each open finding:

  • The current status (open, in remediation, remediated pending verification, closed)
  • The remediation owner
  • The remediation deadline (and whether it has been met)
  • The evidence of remediation, if claimed

If three findings from twelve months ago are still open with no movement, that's an executive-level conversation about control maturity. Better to know this and have a story before the auditor brings it up than to be surprised in the kickoff meeting.

I have seen organisations with otherwise excellent control programmes get downgraded materially because of stale internal audit findings that they had genuinely forgotten about. The auditor reads the report; nobody in the org reads the report; the auditor brings up the finding; nobody can speak to it. That's an integrity-of-process finding even if the underlying control is fine.

The five things I deliberately did not put on this list

Some popular pre-audit advice that I think is bad and don't recommend:

"Clean up your tickets so you have nothing past SLA." Don't. The auditor knows that no organisation has zero past-SLA tickets, and a too-clean queue looks suspicious. Have a normal distribution of work-in-progress, and have a clear story about prioritisation.

"Hide problem vendors." They will find them, especially in the contract register and the data flow inventory. Surface them with mitigation. Item 6 above.

"Do a deep-clean of your shared drive the week before." The audit firm will request things you didn't anticipate. Cleaning the drive removes context that you need at hand. Organise it; don't sanitise it.

"Prepare a script for what to say." Auditors are professional at detecting rehearsed responses. Be prepared; don't be rehearsed.

"Have legal sit in every interview." This signals you have something to hide. Legal should be available, not omnipresent. Reserve legal-in-the-room for the genuinely sensitive conversations.

What to do during fieldwork

Three things, briefly:

Set up a war room. Single physical or virtual location with the right people in attendance, available throughout the audit. Audit lead has one point of contact for evidence requests. Requests get triaged in 15 minutes. Responses target within 4 hours. This is not glamorous; it just works.

Keep a parallel issue log. Whatever the auditor flags during fieldwork, log it in your own tracker. Either you'll need to remediate before close-out, or you'll need to dispute the finding. Either path needs a clean record.

Don't let your team push back in real time. The instinct is to debate findings as they arise. Don't. Note them. Push back in the formal response window if needed. Real-time debates escalate the temperature of the engagement and rarely change outcomes; they often make them worse.

What to do after fieldwork

Two things:

Read the draft report immediately. Respond within the dispute window. Most reports allow 5-10 business days for management response. Use that window properly. Findings that look damning in draft often soften materially with proper context and evidence — if you respond in the window. After the window closes, the report stands.

Schedule the retrospective inside two weeks. While the engagement is fresh, sit down with your team and document what worked, what didn't, what to do differently next time. This is the institutional memory that makes the next audit easier. Most organisations skip this step. Most organisations re-learn the same lessons every year.

A final note on the human side

Auditors are people. They have good days and bad. They have egos and biases. They have firms with positioning incentives. Pretending the audit is a purely technical exercise misses 30% of what actually happens.

The professional relationship between the audited organisation and the audit team matters. Hostile relationships produce worse outcomes for everyone. Cooperative relationships produce more nuanced findings. Cooperative does not mean compromised — the auditor still has to surface real issues, and you still have to remediate them.

The best audits I have been part of, on either side of the table, had three properties: the in-scope team treated the audit as a learning exercise rather than a survival exercise; the audit team treated the in-scope team as practitioners with knowledge rather than subjects to extract findings from; and both sides understood that the report was a starting point for a longer conversation, not the final word.

If you take only one thing from this list: the four weeks before the audit determine the audit. Not the year of compliance work. The four weeks.

This guide draws on field experience running pre-audit reviews across ISO 27001, SOC 2, RBI CSF, SEBI CSCRF, PCI DSS, IRDAI Information & Cyber Security Guidelines, and DPDPA-readiness engagements. It is not legal or regulatory advice. Specific obligations vary by framework, jurisdiction, and engagement scope.

ControlForge maps audit-readiness controls across all major frameworks. The Audit Readiness Score tool generates a quick gap assessment; the Checklist Generator builds an evidence-mapped pre-audit control list. Available at controlforge.com.