Every year, without fail, I see the same pattern. An audit notification arrives. A flurry of activity begins. Evidence is hunted down from inboxes and personal drives. People are briefed hurriedly on what auditors will ask. A week later, fieldwork starts — and the organisation is hoping it has done enough.

This is not audit readiness. This is audit panic dressed up as preparation. And the organisations that operate this way — however experienced they are — consistently receive more findings, spend more time on remediation, and have more uncomfortable conversations with their boards than they need to. The pre-audit sprint is expensive, stressful, and almost entirely avoidable.

Audit readiness is not something you achieve in the two weeks before fieldwork. It is something you build, maintain, and improve throughout the year. And once it is genuinely embedded, audits stop being events that disrupt your team — and start being structured confirmations of what everyone already knows. The question is what that building actually looks like in practice — and it starts well before any audit notification arrives.

Start with design — because everything else rests on it

The foundation of audit readiness is a documented control framework — a structured map that connects your key risks to the controls designed to manage them. Without this, everything else is being built on uncertain ground. You cannot evidence what has not been defined. You cannot own what has not been specified. You cannot test what exists only in someone's head.

Most organisations have some version of this — a Risk and Control Matrix, a process document, a control register. The more common problem is that it was built once and never maintained. It describes how the organisation operated two years ago, before the restructuring, before the new system, before three people changed roles. When auditors trace transactions through documentation that no longer reflects reality, the gap they find is immediate and telling.

So before anything else, review your control framework against how your organisation actually operates today. Work through your five highest-risk processes and confirm that every key control is documented with enough specificity to be tested — who performs it, how often, what it produces, and what evidence confirms it ran. A control named "management review of reports" is not specified. A control that names the reviewer, the report, the frequency, and the sign-off location is. That level of specificity is what makes everything that follows possible.

Once it is designed, someone has to own it

A well-designed control framework tells you what should happen. Ownership is what determines whether it actually does. Every key control needs a single named individual who is accountable for its execution — not a team, not a function, a person. That person is responsible for performing the control consistently, producing the required evidence, and escalating any issues that arise. Without that named individual, a control that exists on paper has no one watching whether it runs in practice.

The most common ownership failure I see is not the absence of names — it is names that were assigned and never revisited. Someone left the organisation. Someone moved roles. Someone was listed as owner of a control they have never heard of. Go through your framework and ask, for each key control: is the named owner still in the right position, and do they know what ownership requires of them? If you cannot answer both questions confidently, that is where to start. A brief conversation with each control owner — covering what evidence they must produce, how to escalate, and what to do if the control cannot run — takes very little time and makes the accountability real rather than nominal.

Ownership without evidence is just an assertion

When a control owner performs their control consistently and correctly, what do they leave behind? That is the evidence question — and it is where audit readiness most visibly succeeds or fails. A control that operated but left no retrievable evidence did not operate as far as an auditor is concerned. The auditor can only conclude what the evidence tells them. If it is absent, incomplete, or stored somewhere only one person can find, the conclusion will not be favourable.

This is directly connected to ownership. When control owners understand what evidence their control must produce, where to store it, and to what standard, evidence gaps stop being a documentation problem and start being a managed process. The practical steps are: define the evidence requirement for every key control — what record is produced, what it must contain, and where it is filed. Centralise storage so that any authorised colleague can retrieve it without asking. Then test it — pick two controls at random and try to retrieve last month's evidence without help. If you cannot do it in five minutes, you have found a gap that needs closing before your next audit.

With design, ownership, and evidence in place — now you can test

Pre-audit testing is only meaningful once the foundations above are in place. There is little value in testing a control that is poorly designed, has no clear owner, or cannot produce evidence. But once your controls are specified, owned, and evidenced, testing becomes the most powerful tool you have for staying ahead of findings.

For each of your highest-risk controls, work through two questions before any audit arrives. First — is this control designed to actually prevent or detect the risk it addresses? Second — did it operate as designed across the full period under review, consistently, by the right person, with evidence to prove it? Both questions are necessary. A well-designed control that ran inconsistently fails the operating effectiveness test. A consistently operated control with a design flaw fails regardless of how diligently it was performed.

The critical point is timing. Testing completed the week before fieldwork is not preparation — it is documented exposure with no time to act. Schedule your control self-assessment at least six weeks before planned fieldwork, put it in the governance calendar at the start of the year, and treat it as non-negotiable. Six weeks gives you time to investigate what you find, implement fixes, and confirm those fixes are operating before auditors arrive.

And none of this is sustained without governance oversight

Design, ownership, evidence, and testing — done well, these four things produce a strong audit outcome. But they only become a discipline rather than a one-off effort when leadership is actively invested in maintaining them. The organisations that consistently produce strong audit outcomes are the ones where the board and audit committee receive regular structured reporting on control effectiveness throughout the year — not just after fieldwork concludes — and where significant weaknesses are escalated before auditors find them. This means building audit readiness into the governance calendar as a year-round programme: framework review at the start of the year, pre-audit testing six weeks before every planned audit, quarterly reporting to the audit committee on control performance, and a standing process for tracking findings to properly validated closure. When leadership is seeing this picture regularly, the pre-audit sprint becomes unnecessary — because the discipline has already done the work.

If your organisation is preparing for an upcoming audit and wants support strengthening its control environment, closing evidence gaps, or conducting pre-audit testing — BECAH works with finance, risk, and assurance teams across all sectors to build audit readiness that holds up under scrutiny. Get in touch at hello@becah.co.uk or visit our contact page to start a conversation.

The word "assurance" is used freely in governance and risk circles — but in my experience, there is a significant gap between how often the word is used and how well the concept is actually understood. And that gap has real consequences for the organisations that rely on assurance to know whether things are working as they should.

So let me offer a plain, practical view of what assurance is, what it is not, and why most organisations are not getting as much of it as they think they are.

What assurance actually is

Assurance is the independent, evidence-based comfort that something is working as intended. It is not a feeling, an assumption, or a verbal confirmation from the person responsible for the thing being reviewed. It is a structured, objective assessment — carried out by someone independent of the activity — that examines whether controls are designed properly and operating effectively, whether processes are being followed, and whether the outcomes being reported are accurate.

Assurance answers the question: "How do we know?" Not "we think so" or "we were told so" — but how do we actually know, based on evidence, that what we believe is true?

What assurance is not

Assurance is not the same as management reporting. When a manager tells the board that controls are operating effectively, that is a management assertion — not an assurance opinion. The manager is telling you what they believe. Assurance tells you what can be independently evidenced.

Assurance is also not a one-time exercise. An annual internal audit that reviews the same three processes every year is not a comprehensive assurance programme. Proper assurance is planned, risk-based, and covers the full range of significant risks and controls across the organisation — not just the areas that are easiest to review.

And assurance is not the same as compliance monitoring. Compliance tells you whether a rule has been followed. Assurance goes deeper — it looks at whether the control environment is designed to prevent non-compliance in the first place, whether it is consistently applied, and whether the evidence exists to demonstrate it.

The three lines model — and where it often falls down

The Three Lines Model is the most widely used framework for thinking about assurance. The first line is management — the people doing the work, who own the controls and are responsible for managing risk day to day. The second line is oversight functions — risk, compliance, and finance — who monitor, challenge, and support the first line. The third line is internal audit — who provide independent assurance to the board and senior leadership that the control environment is working.

In theory, this creates a layered, comprehensive assurance structure. In practice, many organisations have a first line that does not formally monitor its own controls, a second line that is under-resourced or too close to the business to be genuinely independent, and an internal audit function that is small, underfunded, or not empowered to follow its findings through to resolution. The result is that the board receives assurance that is more fragmented and thinner than anyone would be comfortable acknowledging.

What good assurance looks like

Good assurance starts with a clear assurance map — a structured document that sets out what risks and controls exist across the organisation, who provides assurance over each of them, at what frequency, and how that assurance is reported. Without this, it is almost impossible to know where your assurance gaps are.

Good assurance is also risk-based. Resources are focused on the areas that matter most — the highest-risk processes, the controls that would have the greatest impact if they failed, and the areas where management confidence is highest but independent evidence is thinnest.

The organisations that get assurance right are not necessarily the ones with the largest internal audit teams. They are the ones where assurance is genuinely valued — where findings are taken seriously, where the board asks hard questions about the quality of its assurance coverage, and where "how do we know?" is treated as a legitimate and important question rather than a challenge to be deflected.

If your organisation wants support designing or strengthening its assurance framework — BECAH works with assurance teams and boards across sectors to make assurance more structured, credible, and genuinely useful. Get in touch at hello@becah.co.uk or visit our contact page.

A risk register is one of the most fundamental governance tools an organisation can have. Yet in my experience working across finance, risk, and assurance functions, it is one of the most misunderstood — and most misused — documents in any organisation.

I have seen risk registers that are updated once a year and filed away. I have seen registers with 200 risks that nobody owns. And I have seen organisations that have no register at all — and genuinely believe they are managing risk effectively because nothing has gone wrong yet.

What a risk register actually is

A risk register is a living document that records the risks facing your organisation — what they are, how likely they are to occur, what impact they would have, who owns them, and what is being done to manage them. It is not a box-ticking exercise. Done well, it is one of the most powerful management tools you have.

The three most common mistakes

The first mistake is treating the register as a one-off task. Risk is not static. Your risk register should be reviewed regularly — at least quarterly — and updated whenever something significant changes in your organisation or operating environment.

The second mistake is listing risks that are so vague they are useless. "Operational risk" is not a risk. "Key finance staff member leaves and month-end close process fails" is a risk. Be specific. The more precise your risk statements, the more useful your register becomes.

The third mistake is assigning ownership to a team rather than a named individual. Shared ownership is no ownership. Every risk in your register should have one named person who is accountable for managing it.

How to build one that actually works

Start with a risk identification workshop. Bring together key people from across your organisation — not just senior leaders — and ask a simple question: what could go wrong, and what would the impact be? Capture everything. You can prioritise later.

Score each risk by likelihood and impact. Use a simple matrix — high, medium, and low — rather than trying to build a complex quantitative model you will never maintain. The goal is a clear sense of your most significant risks so you can focus your effort appropriately.

Assign a named owner to each risk. Make it clear that ownership means actively monitoring the risk, maintaining the controls around it, and escalating when things change.

Finally, schedule regular reviews. A risk register that is reviewed regularly and acted upon is worth a hundred registers that sit on a shared drive untouched. Build the review into your governance calendar and treat it as non-negotiable.

If your organisation needs support designing a risk register, facilitating a risk identification workshop, or building a risk framework that works in practice rather than just on paper — BECAH can help. Get in touch at hello@becah.co.uk or visit our contact page to start a conversation.

In my experience delivering ICT and transformation projects across multiple sectors, one of the most common reasons projects fail — or at least struggle — is not the technology. It is the gap between what the business needs and what gets built. That gap exists when there is no Business Analyst in the room.

Yet Business Analysis remains one of the most misunderstood roles in a project team. I have seen organisations cut the BA from the project plan to save money — and then spend far more fixing the problems that followed. I have seen projects go live with a system that technically works but does not do what the business actually needs. In almost every case, the root cause was the same: nobody properly defined the requirements before the build began.

What a Business Analyst actually does

A Business Analyst is the bridge between the business and the technology or solution being delivered. Their job is to understand what the business needs — deeply, not just at surface level — and translate that into clear, structured requirements that developers, system implementers, and project teams can actually work from.

A good BA does not just write documents. They map current processes, identify inefficiencies, design future state workflows, facilitate workshops, manage the requirements backlog, support testing, and stay involved through to go-live to ensure what gets delivered matches what was agreed.

When should you bring in a BA?

As early as possible — ideally at the very start of the project, during the discovery and scoping phase. This is when the BA adds the most value and when the cost of getting things wrong is lowest. Bringing in a BA after the build has started is possible, but it is always harder and more expensive to course correct than to get it right from the beginning.

Whether you are implementing a new finance system, upgrading your CRM, delivering a digital transformation programme, or running any project that involves people, processes, and technology — a Business Analyst is not optional. They are the difference between delivering what was asked for and delivering what was actually needed.

If your organisation is planning or currently running a technology or transformation project and needs experienced Business Analysis support — BECAH provides skilled, deployable BA professionals who can work with your team from discovery through to go-live. Get in touch at hello@becah.co.uk.

One of the most common sources of confusion I encounter when working with finance and operations teams is the difference between a process and a control. The two are related — but they are not the same thing. And confusing them is one of the fastest ways to end up underprepared for an audit.

A process describes how work gets done

A process is a sequence of steps that produces an outcome. In accounts payable, for example, the process might be: receive invoice, match to purchase order, obtain approval, post to ledger, schedule for payment. The process tells you what happens and in what order.

A control reduces the risk within that process

A control is an action — built into or applied to a process — that reduces the likelihood or impact of something going wrong. In the same accounts payable example, the three-way match between the invoice, purchase order, and goods receipt note is a control. It exists to prevent incorrect or fraudulent invoices from being paid.

The distinction matters because during an audit, your auditors are not just looking at whether your processes exist. They are looking at whether your controls are designed properly and operating effectively. You can have a beautifully documented process with no meaningful controls embedded in it — and that is a significant audit finding waiting to happen.

What auditors are actually looking for

Auditors want to see three things. First, that you have identified the key risks within your processes. Second, that you have controls designed to address those risks. Third, that those controls are actually being operated — consistently, by the right people, with evidence to prove it.

The practical takeaway — Go through your key processes and ask: where are the risks, and what controls do we have in place to manage them? If you cannot answer that question clearly, you have work to do before your next audit. The good news is that it is entirely fixable — and the organisations that do this work proactively are always better positioned than those who wait to be told.

If your organisation is preparing for an internal or external audit and wants support mapping key processes, identifying control gaps, or strengthening your control environment — BECAH works with finance and assurance teams to get audit-ready in a structured, practical way. Get in touch at hello@becah.co.uk to find out how we can help.

The term "Centre of Excellence" gets used a lot — but in my experience, many organisations are not entirely sure what it means in practice, or why it is worth building. Let me share a straightforward view of what a CoE actually is, what it does for a team, and how to start building one without it becoming an overwhelming project.

What a Centre of Excellence actually is

A Centre of Excellence is a structured operational home for a professional function — whether that is finance, risk, internal audit, or assurance. It is the combination of the tools, templates, processes, governance, and ways of working that allow a team to operate consistently, efficiently, and to a high standard.

Think of it as the infrastructure of a function. Without it, teams often reinvent the wheel on every engagement, store documents inconsistently, operate without clear standards, and struggle to demonstrate the quality of their work. With it, everything has a place, a standard, and an owner.

Why it matters more than people think

A well-structured CoE does several important things. It ensures consistency — everyone on the team is working to the same standards and using the same tools. It supports quality — because when processes and templates are well designed, the work product is better. It enables scalability — when the function grows, new team members can be onboarded quickly because everything is documented and accessible. And it supports accountability — because ownership of processes, documents, and activities is clear.

Where to start

The most important thing is not to try to build everything at once. Start with three things: a clear folder structure for your team's documents, a small library of core templates (risk register, control template, meeting minutes, action log), and a simple governance document that sets out how your function operates.

From that foundation you can build — adding more templates, documenting processes, setting up dashboards, and establishing review cycles. The key is to start simple, make it practical, and build incrementally. A CoE that is used every day by a team of three is worth far more than an elaborate structure that sits untouched on a SharePoint site.

BECAH supports organisations in designing and building Risk and Assurance Centres of Excellence — from folder structure and template libraries through to SharePoint implementation and governance frameworks. If you are ready to build yours, or just want to explore what is possible, we would be glad to talk. Reach us at hello@becah.co.uk or explore our CoE products.