CHAPTER 9: Internal Audit Integration

TL;DR – Key Takeaways from Chapter 9

i. Audit is a feedback loop, not a separate universe
Internal audit strengthens the programme by testing reality and feeding insights back into risk and control design.
ii. One shared issues register prevents repeat findings
Tracking audit findings alongside incidents and risks improves follow-through and accountability.
iii. Assurance should focus on top risks and services
Audit planning adds most value when aligned to what matters most, not fixed cycles alone.
iv. Audit readiness comes from operating well
Organisations are audit-ready when controls and evidence are part of normal operations, not last-minute preparation.

Internal audit is not there to run a second compliance team. Its primary job is to provide independent assurance to the board and senior leadership that:

1. Governance, risk management, and controls are designed sensibly
2. They operate as described, over time
3. The most important risks and obligations are receiving appropriate attention

For practitioners, that means:

1. Audit is one of the most valuable feedback loops you have
2. Findings should feed directly into your issues, actions, and control improvement work
3. Assurance topics should align with your risk scenarios, top risks, and key controls, not surprise you

In the language of the earlier chapters: internal audit tests how well your program loop (design) and execution loop (day-to-day work) are actually functioning.

The Compliance and Internal Control Framework chapter covers how you:

1. Interpret obligations
2. Design and document internal controls
3. Decide who owns what

Internal audit and second-line assurance answer a different question:

“Are these controls, processes, and behaviors actually working as intended?”

To keep roles clear:

1. Design and ownership sit with first and second line
2. Testing and independent verification sit with internal audit (third line) and, in some cases, second-line assurance teams
3. Issue management and remediation are shared, but tracked in one place

Across this guide, assurance and audit readiness are treated as a single, continuous activity, not as two unrelated processes.

To avoid the “we fix it for audit only” cycle, you should have:

1. One issues and actions register that captures:
1. Audit findings (internal and external)
2. Assurance test results
3. Incident postmortems
4. Regulatory inspection outcomes
5. Self-identified issues
   
   
2. Each issue linked to:
1. A risk scenario and/or top risk
2. One or more controls and processes
3. The relevant service, entity, and vendor (where applicable)
   
   
3. Simple status tracking:
1. Severity or priority
2. Owner and due date
3. Progress and verification of closure

If your audit findings live in one system, risk issues in another, and incident actions in a third, you will repeat work and lose the bigger picture. The shared register is where the execution loop for issues and remediation plays out, regardless of where a finding originated.

Internal audit and second-line assurance should focus where risk is highest and where controls matter most.

A practical approach:

1. Start with your top risks and key services
1. Use the enterprise and domain risk views to identify the scenarios that matter most.
2. Identify the controls and processes that really shape exposure for those scenarios.
   
   
2. Build an assurance plan that covers:
1. Risk themes (for example, data protection, third-party resilience, access management)
2. Critical controls and services
3. Regulatory priorities and past findings
   
   
3. Spread coverage over a multi-year horizon:
1. Not everything needs to be reviewed every year.
2. Use risk and incident data to decide what to review more or less often.
   
   
4. Coordinate with second-line teams:
1. Avoid duplication between routine testing, thematic reviews, and formal audits.
2. Share work where possible (for example, reusing testing results if they are robust).

The goal is a plan that leadership can recognize as aligned to what they care about, not just a list of topics. It should look like an extension of your risk and control program, not a separate calendar.

You can make audit and assurance work smoother by:

1. Using the same object model:
1. Scope audits by service, entity, vendor, and control, not just by department.
2. Reference the internal control framework directly in scoping and testing.
   
   
2. Standardizing test and evidence expectations:
1. For each control, agree acceptable evidence, frequency, and test types.
2. Store or reference evidence in known locations, not scattered files.
   
   
3. Keeping reporting focused on:
1. What was tested and why (linked to risks and controls)
2. What was found and how severe it is
3. What needs to change, by when, and who owns it
   
   
4. Feeding results into the issues and actions register automatically, not retyping them into spreadsheets.

This reduces friction for both auditors and control owners, and makes it easier to see patterns over time, especially when combined with continuous control monitoring where it makes sense.

Assurance and audit add value only if findings lead to real improvements. To close the loop:

1. Treat root-cause analysis as a standard step for significant findings and repeated issues
2. Look for patterns across domains:
1. Are the same themes (for example, weak change control, unclear ownership, poor data quality) appearing in different audits and incidents?
   
   
3. Use that insight to:
1. Refine control definitions and responsibilities
2. Adjust training and guidance
3. Update risk scenarios and appetite discussions
4. Inform the GRC strategy and maturity roadmap

Enterprise and operational risk teams should see audit and assurance outputs as a primary input, not just a compliance tick.

Internal audit and assurance connect to many parts of this guide:

1. Risk Management Excellence and Enterprise Risk:
1. Top risks should shape the audit plan.
2. Audit results should refine risk ratings and treatments.
2. Compliance and Internal Control Framework:
1. Testing focuses on whether controls are designed and operating as described.
3. Cyber, TPRM, and Privacy:
1. Domain-specific audits feed back into shared risks, controls, and vendor or processing records.
4. Regulatory Change Management:
1. Regulatory inspections and thematic reviews are a form of assurance; outcomes should flow into the same register and framework.

Seen this way, internal audit is another way of exercising the same shared objects and lifecycles, not a separate discipline.

Useful metrics show whether assurance work is targeted and effective, for example:

1. Percentage of top enterprise risks that have had relevant assurance work in the last 2–3 years
2. Percentage of audit and assurance findings logged in the central issues register
3. On-time completion rate for high-priority remediation actions
4. Number of repeated findings by theme across multiple audits or years
5. Time from audit report issuance to final closure of critical findings

These metrics can be shared with audit committees and leadership to demonstrate that assurance is part of a continuous improvement loop, not an isolated activity.

To better integrate internal audit into your GRC program:

1. Create or confirm a single issues and actions register and agree that all significant findings will be recorded there
2. Align audit scoping with your internal control framework and top risks, using the same IDs and definitions
3. Pilot this integrated approach on one or two upcoming audits, making sure findings and actions flow into the wider GRC data model
4. Use results from those pilots to refine how often you meet with internal audit and how you align plans, reports, and metrics

Handled this way, internal audit becomes a powerful extension of your GRC program, strengthening confidence in what is working and shining a clear light on where you need to improve next.

Continue to Chapter 10 - Data Privacy and Protection