How to Bridge the Gap Between Auditing Business Processes and IT Controls

Modern business processes rely heavily on technology. But when we audit those processes, we don’t always ask enough questions about the technology. 

How do you know you can rely on the data from that system-generated report if you don’t know what’s going on with its underlying technology and controls? 

You don’t. You’re making a big assumption, and that’s a big risk. 

Business Process Auditors need to better understand which technology systems matter and how they work. On the other side of the fence, IT Auditors need a stronger grasp on WHY those technology systems matter, and how ITGCs and application-level controls can impact the business. 

Toby DeRoche has been on both sides of the fence. And as he cautioned during his May 2026 webinar, “We may be missing risks at the intersection where our two worlds collide.” 

Toby is the Internal Audit Collective’s Community Manager and the instructor of our SYNERGY course, designed to help auditors bring these worlds together. (Next course starts July 7, 2026; register today.) He is also an internal controls expert and consultant, bestselling business author, and passionate GRC educator with decades of GRC experience across industries. 

How can you start bridging the gap? Here are five key takeaways from Toby’s presentation. 

1. Stop Treating Business Audits and IT Audits as Separate Worlds

Business processes are inseparable from the IT systems supporting them. Nearly every modern business process relies on layers of interfaces, applications, automated controls, and system-generated reporting.

But auditors — depending on their backgrounds — tend to separate the two:

• Business Process Auditors often review processes without understanding the supporting IT systems. Said Toby, “We overlook data integrity risks in the reports that we use for making financial decisions because we’re not thinking about it. We’re making sure that all of our processes underlying it work, but not always down to the data level. We’re mapping our business risks to system dependencies and treating IT as a completely separate domain — instead of what it really is, which is something that enables the rest of this work to happen.”
• IT Auditors often lack a real understanding of why basic ITGCs exist. Toby has too frequently encountered IT Auditors who have no idea WHY they’re doing certain control work. In many cases, this is because no one from the Business Process Audit side “took the time to explain — or if they did, they went too far, giving them the history of SOX instead of saying, this control exists because of X, Y, and Z business risks.” 

This disconnect may cause both sides to overlook significant risks. For example:

• Business Process Auditors may test manual controls without realizing that underlying systems are auto-approving transactions beyond specific thresholds — making manual steps irrelevant. 
• IT findings written in overly technical language may lack business context, leaving management unaware of what’s really at stake. 
• Siloed testing and reporting provide incomplete assurance over the full control environment, leaving gaps that limit value to the organization and undermine confidence in audit. 

2. Start Seeing Risk Through a Dual Lens

The crux of the disconnect, said Toby, is that auditors are “coming at the work with two very different perspectives”:

• Business Process Auditors assess risk through a PROCESS lens of transactions, roles, and process flow, typically relying on walkthroughs, sampling, and interviews. They tend to start at the top and work their way down, from “policies to procedures to what’s actually happening in the real world,” said Toby. They’re focused on operational effectiveness, control execution, and whether policies and procedures are being followed, looking for things like fraud, SOD, reviews/approvals, and impacts to the financial statements.
• IT Auditors assess risk through a TECHNOLOGY lens of data, systems, and technology risk, typically relying on configuration reviews, log analysis, and system queries. They start by trying to understand the entire environment, focusing on infrastructure, configurations, and user access. As Toby explained, they spend time “in the actual applications, trying to understand what’s really happening, knowing there are policies not every application can meet,” and focusing on questions around data reliability, cybersecurity, change management, access management, and insider threats.

Both sides seek to identify risks, test controls, and understand whether risks are mitigated to within management’s risk appetite. But they’re each missing big parts of the picture.

Integrating these perspectives can provide more complete assurance. This is our opportunity. 

As Toby put it, “When methodologies align, auditors can assess whether a business control is truly effective — not just whether it exists on paper, but whether the systems supporting it are reliable.”

3. Don’t Assume Systems Are Working — Validate They Are

Again, Business Process Auditors tend to assume systems are working correctly. 

Receiving a system-generated report, they test transactions as if the report is reliable. They’re thinking about process. Was the approval documented? Was the transaction authorized?

But they should also consider the technology layer, asking questions like:

• Can the underlying data be trusted? Who can modify it?
• How is the system enforcing the approval? 
• Could someone have altered the approval logic? 
• Can someone disable key controls? 

As Toby repeatedly emphasized, if key ITGCs fail (e.g., access management, change management, monitoring, backups), the reliability of the entire system is in question. 

Make sure you trust the data before testing the process. Process control testing shouldn’t happen in isolation from ITGC testing. 

4. Map Business Risks to Technology (and Vice Versa)

You won’t care about an “IT issue” unless you understand its business impact: 

• What business objective is affected? 
• What process could fail as a result? 
• What financial, operational, compliance, fraud, or other risks does it create?

For example, an IT Auditor going through an access review typically focuses on making sure that the appropriate approvals occurred. But they’re not thinking about what that approval actually does and how it could impact the business. They may say “Person X had too much access” and fix the issue in the system. But they don’t always say “and here’s what could have happened because of it, and here’s what we need to check in the system as a result.”

“There’s no such thing as a purely technical issue or a purely IT Audit. Everything always ties back to a business risk,” said Toby. 

5. Bridge the Gap by Unifying Planning and Reporting 

So how do we bring it all together? At minimum, said Toby, “Plan together; report together.” 

Do combined risk assessments. Establish clear roles and timing. Share workpapers, keeping everyone in the loop on findings. When reporting, present one view of the issues in one voice. Always include the business impact of IT findings: Basically, “Here’s what could go wrong, here’s how it happened, here’s what we’re gonna do about it,” said Toby.

Ready to start bridging the gap? Here’s Toby’s framework in more detail.

Step 1: Align Risk Assessment

• Create a single, shared set of business objectives. Any IT process supports one of those objectives. 
• Next, map risks to processes, systems, and data flows. Toby offered an example:

1. Identify the shared business objective. Toby’s example was an AP audit ensuring that the company correctly and timely pays only valid, authorized vendor invoices. 
2. Identify the process risks (e.g., duplicate payments, unauthorized approvals, late payments, and vendor fraud). 
3. Identify supporting systems (e.g., ERP systems, identity management platforms).
4. Identify supporting IT controls. Consider not only ITGCs (e.g., access, change management), but also application-level controls (e.g., calculations, automated approval configurations, field validation, completeness checks, data transfer reconciliation). 

• Review the combined risk universe together before scoping begins. 

Step 2: Coordinate Scope and Timing

• Define clear roles. Who tests what and when? Toby’s recommendation: IT Audit should conduct ITGC testing before or in parallel with process testing. “We need to validate that the system can be trusted — that it is reliable,” reiterated Toby. “If we dove straight into the business side without looking at the IT work… we missed a big chunk.”
• Next, define reliance: Which IT conclusions will help scope process testing? 

Step 3: Joint Control Testing

• Test automated controls together. Business Process Auditors provide the control objective; IT Auditors evaluate the system evidence. Said Toby, “There’s no reason we have to do this on our own.” Consider embedding an IT Auditor on a Business Process Audit team or vice versa. 
• Document shared conclusions both teams can rely on. 

Steps 4 and 5: Integrated Issues and Unified Reporting

• Connect process findings to IT root causes. “Now we’re saying, I have this IT issue, but here’s why it matters to the business. And I have this business issue that’s driven by an IT process, and here’s how it connects.”
• That’s also how you’ll report your findings in business risk terms that resonate with management and the audit committee.

THE LAST WORD: Synergy Is Needed — and It’s Within Reach

Toby deserves the last word: “We’ve split our world, for better or worse, between business process and IT. But we should get back to one common view. If we don’t, we’re working in silos. Those silos create risks, because we’re missing the places where things overlap.”

He added, “This takes work. We have to break things down and put them back together.” For example, teams used to different terms or ratings need to agree on a shared language and approach. 

But in the modern risk landscape, where technology is integral to business success and resilience, organizations need more complete assurance. That requires bringing these worlds together. 

Want more guidance, including the opportunity to get help specific to your situation? Toby’s SYNERGY course (16 CPEs over 4 weeks) helps Business Process Auditors upskill in IT Audit and IT Auditors become risk and controls experts. IT Audit has become a core competency for every auditor; think of SYNERGY as an insurance policy helping you future-proof your career. The next program runs July 7–30, 2026, so sign up today. 

‍