How to Cut Critical Audit Observations by 60%

The number that gets quoted is 60%. That is how much we reduced critical audit observations year on year at leading Bank in Bangladesh over a three-year period. Twenty-plus audits, including direct Central Bank ICT engagements, PCI DSS assessments, and ISO certifications. Throughout that period, we maintained a 'Satisfactory' Central Bank rating.

I want to tell you how we actually got there, because the honest answer involves some uncomfortable realisations about what compliance programmes typically get wrong.

And I should be upfront: this experience is not unusual in its starting point. Swimlane's 2025 GRC Chaos Report, which surveyed 500 IT and security decision-makers across the US and UK, found that only 29% of organisations say their compliance programmes consistently meet internal and external standards. 62% say their audit evidence-gathering process is at least occasionally error-prone. 96% say it is challenging to keep up with the growing number of regulations. Most GRC teams are working hard and still falling short.

Treating observations as isolated failures is the wrong approach

When audit observations accumulate, the reflex is to treat each one as a discrete problem. Close the finding, fix the control, move on. This works for genuinely isolated issues. It does not work when you are dealing with systemic weaknesses, because each observation is a symptom, not the cause.

The shift we made in year one was to categorise all observations by root cause rather than by finding type. This sounds simple. In practice, it required honest conversations about why controls were failing, not just which ones were. The categorisation exercise took about a week with the team leads involved in day-to-day GRC operations.

Here is roughly what we found, and the primary intervention each category required:

Root Cause Category	Approximate Share (Year 1)	Primary Intervention
Undocumented manual processes	~30%	SOPs, runbooks, documented ownership for every control
Change management gaps	~20%	Change Advisory Board, structured RCA, defined emergency change process
Poor or missing evidence trail	~25%	Evidence logs embedded as routine control outputs, not retrospective gathering
Outdated or absent policies	~15%	Annual policy review cycle with version control and formal approval records
Third-party and vendor gaps	~10%	Supplementary vendor assessments, contractual SLAs aligned to control requirements

Note: these percentages reflect an internal analysis from our first-year review. They are illustrative of the distribution we found, not published research figures.

Once we could see that roughly half our observations traced back to just two root causes, undocumented processes and change management gaps, the work became tractable. We addressed those two things first. The observation count dropped significantly in year two.

Evidence architecture matters more than control design

Here is something I did not expect when I started this work: a well-designed control with a poor evidence trail will fail an audit. A moderately designed control with clean, consistent, timestamped evidence will usually pass.

This is not advice to paper over weak controls. It is a practical observation about what external auditors actually assess: does the control exist, did it operate, and can you prove it? The third question is where most teams fall down. Swimlane's 2025 research found that 92% of organisations rely on three or more tools to gather audit evidence, often producing duplicated effort and disjointed workflows. The evidence is there somewhere. It is just not organised in a way that is audit-ready.

We restructured how we generated evidence. Instead of gathering it before audits, we embedded evidence collection into the routine operation of every control. Log reviews produced a signed-off artefact. Vulnerability scan results were filed against the relevant control objective immediately after each run. Change records linked to risk assessments. Training completions were tracked centrally with completion dates.

Audit preparation time dropped from a six-week sprint to roughly two weeks. Not because we had less to prepare, but because most of it already existed in the right format.

The regulator is not your adversary

This sounds obvious. In practice, I have seen compliance teams treat regulatory engagement as a confrontation to be managed rather than a relationship to be built. The result is a defensive posture that communicates uncertainty, and auditors read that.

At that Bank, when we identified a compliance gap ahead of a regulatory visit, we disclosed it proactively with a remediation plan and timeline. We did this consistently. Every time, the Central Bank's response was constructive rather than punitive. They were more interested in whether we understood our weaknesses and had a credible plan than in whether we were clean.

Proactive disclosure requires genuine confidence in your programme. If you are not confident, the answer is not to hide the gap. The answer is to fix it faster and document the journey honestly. Auditors can tell the difference between a programme that is improving and one that is managing appearances.

Audit readiness is a default state, not a six-week sprint

The teams that struggle most operate in two modes: normal operations and pre-audit panic. The sprint is exhausting, evidence is manufactured under pressure, and the team comes to dread audit season.

We rebuilt our quarterly GRC reviews to produce audit-ready outputs as a standard artefact. Risk register review: formatted consistently, version-controlled, ownership clear. Control self-assessments: structured the same way every quarter. KRI reporting: mapped to the relevant regulatory requirements and filed with narrative where thresholds were breached.

When an auditor arrived, we handed them a folder. We did not build the folder. That shift from reactive to perpetual readiness is the single most important structural change in our programme. Swimlane's research found 90% of organisations are concerned that poor collaboration between GRC and security teams undermines their audit preparation. Perpetual readiness only works if both teams are producing consistent outputs in real time, not assembling them from different systems under deadline pressure.

One honest caveat on the 60% figure

Year one had the most room for improvement, because we were starting from a lower baseline. The reduction from year one to year two was the sharpest, because the largest systematic gaps got addressed first. Subsequent years showed smaller percentage reductions, but the work to achieve them was harder.

If your programme is already mature, a 60% reduction in one year likely means you are catching up rather than sustaining excellence. If you are still building foundational controls, the gains can genuinely be that large.

What matters more than the number is the mechanism: categorise by root cause, build evidence as a routine output, invest in the regulator relationship, and make readiness your default operating state. Those four things, applied consistently, will move the number.

---