Audit risk model: Formula, components, and how compliance teams use it

Most organizations that fail audits are not missing controls. The more common problem is that risk stays invisible between audit cycles, and the evidence of control effectiveness is too fragmented to hold up under scrutiny.

In a recent Scrut webinar on continuous audit readiness, the moderator opened with a live poll: if an auditor, regulator, or customer asked for evidence that your controls were working tomorrow, how ready would you be? The most common answer from the room was one to three weeks. That gap, between believing your controls work and being able to prove it on demand, is exactly what audit risk measures.

Today, compliance teams manage cloud infrastructure, distributed identities, SaaS sprawl, third-party ecosystems, and evidence scattered across dozens of systems at once. The operational complexity has grown. The frameworks used to reason about audit risk have mostly stayed the same.

Most resources still treat the audit risk model as an accounting-classroom formula, a three-variable equation for planning an external auditor's fieldwork. That framing misses the point for GRC managers, compliance leads, and security teams.

The audit risk model is not just an auditor's tool. Applied correctly, it is a practical operating model for reducing findings, prioritizing controls, improving evidence quality, and operationalizing continuous compliance. This guide explains how to use it that way.

What is the audit risk model?

The audit risk model (ARM) is a framework auditors use to plan and manage the risk of issuing an incorrect opinion on a financial statement or compliance assessment. At its core, it asks a deceptively simple question: how likely is it that something significant has gone wrong and nobody has caught it yet?

For GRC managers, the most useful framing is this: the audit risk model quantifies the probability that significant compliance or control failures go undetected before or during an audit.

The model expresses that probability through three interacting components:

Each variable is a probability between 0 and 1:

• Inherent risk sets the baseline exposure before any controls are considered.

• Control risk reflects how well your program addresses that baseline.

• Detection risk determines whether failures are actually caught in time.

Here is where auditors and compliance teams use the same model differently. An auditor uses it to decide how deeply to test each control. A compliance team should use it to diagnose where its own program is weakest, before an auditor arrives to find out.

To see the formula in practice, consider a SaaS company preparing for a SOC 2 examination:

• Inherent risk: 0.70, reflecting sensitive customer data and multi-cloud infrastructure.

• Control risk: 0.50, reflecting quarterly access reviews that are manual and inconsistently completed.

• Acceptable audit risk: 0.05, meaning the auditor requires 95% assurance before issuing an opinion.

• Detection risk: 0.05 ÷ (0.70 × 0.50) = 14.3%.

That 14.3% threshold is not abstract. It directly determines how many access logs the auditor will sample and how many weeks your team will spend producing evidence. 

According to Kush Kaushik, Co-founder at Scrut Automation, this is exactly why auditors quantify risk before testing: a departed employee who kept production access is weighted far more heavily than a contractor with access to an outdated dashboard, even when both are single access-control exceptions.

The formula does not change. What compliance teams can improve is the quality of every input that goes into it. For more on staying ahead of that formula rather than reacting to it, see continuous audit readiness.

‍Audit risk model diagram: How audit risk flows through a compliance program

Most depictions of the audit risk model show a formula. What they rarely show is how risk actually moves through an organization before an auditor ever arrives.

Each stage in this chain is a potential failure point:

Assets and inherent risk. Every system, dataset, identity, and vendor carries inherent risk specific to its nature and environment. This is where audit risk originates.

Controls and control risk. A control that exists on paper and a control that operates effectively are not the same thing. The gap between them is where inherent risk compounds into control risk.

Monitoring, evidence, and detection risk. When monitoring is periodic rather than continuous, control failures accumulate silently between audit cycles. The auditor only sees what the evidence can show, not what happened in the gaps. Fieldwork itself follows a predictable path: the auditor pulls a population, samples from it, and requests evidence for each item. 

Evidence organized by control rather than by date is what lets the team answer those requests the moment they land.

Audit testing and outcome. The auditor works only with the evidence available. Every failure that went undetected upstream flows into the final audit opinion.

This is the operational reality that the traditional formula does not capture on its own.

The 4 components of the audit risk model (and how they interact)

Understanding the components is what separates compliance teams that react to findings from those that prevent them. Each maps to a specific point of failure, and knowing where those points are is the first step toward closing them before an auditor does.

1. Inherent risk

Inherent risk is the level of risk that exists because of the nature of the environment, before any controls are considered. It is not a reflection of poor governance. It is a reflection of operational reality. During audit planning, inherent risk is typically scored on a qualitative or semi-quantitative scale: High/Medium/Low or 1 to 5.

Start with asset inventory. If a system or data type is not visible, it cannot be classified or controlled, and any elevated risk it carries stays invisible until an auditor finds it. Environments with high inherent risk include organizations handling sensitive customer data, managing privileged access across engineering teams, deploying AI systems with limited auditability, or running rapid release cycles with thin change management.

Context matters more than the label. A SaaS company with 50-plus engineers holding elevated AWS production privileges and no automated access review process carries higher inherent risk than an equivalent company with enforced least-privilege IAM policies, even before any control testing occurs.

How compliance teams reduce inherent risk:

• Implement data classification policies that map sensitivity levels to access controls.

• Enforce least privilege architecture to limit the blast radius of any single failure.

• Conduct vendor due diligence before onboarding third parties with access to critical systems, and standardize change management so rapid release cycles do not introduce unreviewed risk.

Inherent risk cannot be eliminated.

2. Control risk

Control risk is the probability that your internal controls fail to prevent or detect a compliance issue. Having a control and having an effective one are not the same thing. That gap is where control risk lives, and it is exactly what the SOC 2 Type I/Type II distinction is designed to measure.

Type I attests that a control is suitably designed. Type II attests that it is suitably designed and operating effectively over time. Those are different questions. A well-designed control that never actually operates still carries high control risk.

Controls fail in predictable ways: access reviews get skipped when teams are stretched, offboarding checklists are not enforced across all systems, policies are published but ownership is never assigned. Sometimes the gap is procedural and small. For instance, using the example of a real audit, a quarterly firewall review has been completed but is missing a single CTO sign-off email for one quarter. That kind of gap is precisely what drives an auditor to expand sampling.

Automated controls are not automatically effective, either. Automation reduces human error, but a misconfigured automated control can fail silently and consistently, producing false confidence until someone asks for evidence. Automated controls still need regular testing.

How compliance teams reduce control risk:

• Automate evidence collection so control operations are captured as they happen, and pair every control with a named owner who takes documented sign-off on each evidence artifact.

• Monitor policy compliance rather than assuming it, and build alerting into control workflows so failures surface in real time.

• Test control effectiveness through internal reviews, not just before external audits.

3. Detection risk

Detection risk is the risk that existing problems are not discovered, either by the compliance team during monitoring or by the auditor during fieldwork. It is the most underestimated of the three components.

Detection risk and auditor testing are inversely related. When your evidence is clean, timestamped, and continuously generated, the auditor can reach a conclusion faster. When evidence is manually assembled under deadline pressure, the auditor must test more extensively to reach the same level of confidence. This is the ROI case for continuous evidence collection.

The conditions that drive detection risk higher are usually mundane: evidence stored in spreadsheets that cannot be queried, screenshots taken at the wrong time, logging that captures some systems but not others, audit trails fragmented across tools that do not talk to each other. Evidence organized by date instead of by control turns fieldwork into a scavenger hunt.

Clean evidence does not always reduce testing volume. At Scrut's own audit, when EY sampled endpoint monitoring and kept finding clean results, they expanded the sample to go deeper, specifically because the results were green. Clean evidence did not shrink the sample, but it did keep the findings clean and the opinion risk low.

How compliance teams reduce detection risk:

• Centralize evidence collection so data pulls automatically from integrated applications.

• Replace point-in-time screenshots with continuous, timestamped records.

• Ensure logging is complete and consistent across all in-scope systems.

• Keep audit trails auditor-ready at all times, not assembled under deadline pressure.

4. Acceptable audit risk

Acceptable audit risk is the threshold of residual uncertainty an auditor is willing to tolerate before issuing an opinion. It is set by the auditor, not the organization, and it directly determines how much testing your team faces. If the acceptable audit risk is 5%, audit assurance is 95%, meaning the auditor requires 95% confidence before issuing an unqualified opinion.

In regulated environments, healthcare organizations under HIPAA or financial services firms with SOC 2 obligations, acceptable audit risk is set considerably lower. The auditor requires more evidence, tests more controls, and samples larger populations.

Audit firm quality plays a role here too. Better-resourced firms with dedicated QA processes tend to hold themselves to more rigorous acceptable audit risk thresholds, which is part of why their engagements feel more intensive.

How the four components multiply (not add)

Overall audit risk is not the sum of the components. It is the product of their interaction, which is why improving any single input has outsized impact.

A program with inherent risk of 0.80, control risk of 0.60, and detection risk of 0.25 carries an overall audit risk of 12%, already above a typical 5% acceptable threshold. Reducing control risk to 0.30 by improving access review consistency drops it to 6%, still short. Reducing detection risk to 0.10 by automating evidence collection gets the program to 2.4%, within acceptable bounds.

Audit risk model scenarios, detection risk adjustment, and compound impact

Because the components multiply, improving one is not marginal. It moves the whole program.

How auditors use the audit risk model in real audits

When an auditor begins planning, the ARM is not theoretical context. It is an active decision-making tool that shapes where they look, how deeply they test, and how much evidence is enough.

The workflow typically follows five steps:

Identify high-risk areas. The auditor maps the client environment to understand where inherent risk is concentrated. Regulated data, complex vendor networks, and frequent system changes get immediate attention.

Evaluate controls. The auditor assesses whether controls addressing those areas are well-designed and actually operating, reviewing policies, testing configurations, and interviewing process owners.

Determine evidence reliability. Automated, system-generated records are treated as more reliable than manually assembled documentation. Evidence quality directly influences how much of it the auditor needs. An automated, timestamped log from your cloud provider carries more weight than a screenshot taken the morning the auditor asked for it.

Adjust testing depth. Using the formula, the auditor sets detection risk at a level that brings overall audit risk to an acceptable threshold, determining the nature, timing, and extent of substantive testing.

Increase substantive testing where confidence is low. Where uncertainty remains, the auditor expands testing rather than accepting the gap.

The workflow also recalibrates across audit cycles. During Scrut’s own EY audit, the auditor went deep on BCP testing and access reviews because these were second-year focus areas. Policies had already been tested in year one, so the auditor shifted attention to technical operating effectiveness, even requiring screen recordings that captured system clock time during BCP testing.

Not all auditors apply the model with the same discipline. Better-resourced firms with dedicated QA processes tend to quantify control risk more granularly, which is why their engagements feel more intensive and why companies that pass them carry more credible opinions.

Understanding this workflow tells compliance teams what they are preparing for and why preparation should start long before the auditor arrives.

How compliance teams actually use the audit risk model

Most resources explain the ARM from the auditor's perspective. What they leave out is more useful: how internal teams can apply the same framework to run a stronger program year-round.

Use case 1: Prioritizing control implementation. When resources are limited, the ARM gives you a decision rule. Controls with high inherent risk and low existing coverage are P1. For a SaaS company handling customer data, that typically means access reviews and offboarding before vendor questionnaire management. Controls with low inherent risk and strong existing evidence can wait until the high-risk areas are stabilized.

Use case 2: Identifying evidence weaknesses. Evidence weaknesses show up before the auditor asks a single question. How your evidence is organized is itself a signal: a package organized by control tells the auditor the program is well-managed. One organized by date tells them the opposite, and turns detection risk into a live problem the moment fieldwork begins.

Use case 3: Preparing for SOC 2 audits. SOC 2 assesses operating effectiveness over a defined period. Use the ARM before the observation period starts, not during it. Identify which Trust Services Criteria carry the highest inherent risk for your environment, confirm those controls are well-designed, and make sure evidence collection is already running. A control that starts operating on day one of the observation period is not the same as one that has been running for three months.

Use case 4: Improving ISO 27001 monitoring. ISO 27001 surveillance audits in years two and three focus on whether the ISMS is actually functioning, which is the operating-effectiveness dimension of the ARM. Use it to find which Annex A controls have the weakest monitoring coverage and direct improvement there.

Use case 5: Diagnosing whether your tools address detection risk. If detection risk remains high despite a GRC platform being in place, the issue is evidence completeness, integration coverage, or monitoring frequency, not the platform brand. Treat persistent detection risk as a diagnostic, not a purchasing decision.

Audit risk model example for SOC 2 and ISO 27001 teams

The model becomes most useful when applied to a specific scenario. Consider a mid-market SaaS company preparing for a SOC 2 examination and an ISO 27001 surveillance audit in the same year.

The scenario: Access management program

Inherent risk: High. The company handles sensitive customer data across a multi-cloud environment, with engineering teams holding elevated production privileges. Third-party integrations add access vectors that the compliance team cannot always see.

Control risk: Medium to high. MFA is enforced for most users, but access reviews are quarterly and rely on a manual spreadsheet. Role assignments have drifted, and offboarding is inconsistent across departments.

‍Detection risk: High. Evidence lives across email threads, shared drives, and a project management tool. When the auditor requests evidence for the access review control, the team scrambles to reconstruct documentation that should have been captured automatically.

The depth here is easy to underestimate. When EY ran Scrut’s first access review, the requirements went well beyond a spreadsheet: an HR-generated active employee list with a timestamp, user lists from every in-scope application, department head review and approval for each user, and documented justification for every instance of privileged access. All of that, for a single quarterly access review. Because it was done manually during fieldwork, it took the IT manager roughly 20 to 25 days.

After automation

With continuous evidence collection in place, access review records are generated and stored automatically at each cycle. Automated access reviews surface role drift and flag exceptions for remediation without manual intervention. A centralized dashboard gives near-real-time visibility, and remediation tracking ties every exception to a resolution.

The outcome is measurable. Detection risk drops because evidence is no longer reconstructed under deadline pressure. It exists as a continuous, timestamped record from the moment each access review runs. When Scrut moved this process onto its platform for the next audit, the effort was cut roughly in half.

There is an ISO 27001 dimension too. Surveillance audits require the auditor to confirm the ISMS is functioning, which means the same access review evidence that satisfies SOC 2 fieldwork can serve as ISO 27001 operating evidence, provided it is mapped to the relevant Annex A control.

Evidence collection transformation: manual vs. automated workflows

Common mistakes compliance teams make with audit risk models

Applying the ARM well is about avoiding the operational habits that keep audit risk high even when a program looks healthy on the surface.

Treating audits as point-in-time exercises. Scheduling compliance around audit windows means failures accumulate undetected for months.

Over-relying on documentation. A well-written policy reduces nothing on its own. Enforcement, monitoring, and evidence are what close the gap.

Ignoring evidence quality. Volume is not the same as quality. Auditors weigh system-generated, timestamped records far higher than manually assembled screenshots and exports.

Assuming automated controls are automatically effective. When the auditor arrives and your evidence lives in a spreadsheet, the scramble is visible. Version issues, reconstruction effort, missing timestamps: the auditor watches all of it, and that observation raises their risk assessment before a single question is answered.

Failing to define ownership. When no one is explicitly responsible for a control, monitoring lapses and remediation stalls. Undefined ownership is one of the most reliable predictors of audit findings.

How to reduce audit risk continuously

Reducing audit risk is not a pre-audit activity. It is an operational discipline that runs alongside the program every day. The practices below are not a checklist to run before the auditor arrives. They are the program.

Operationalize continuous evidence. Move from point-in-time checks to continuous monitoring and tie every in-scope control to a live automated evidence source. Evidence should exist as a continuous record, not something reconstructed under deadline pressure.

Build centralized visibility across systems. When evidence lives across multiple tools, detection risk rises because no single view of control health exists. Centralizing visibility lets teams find gaps before auditors do.

Run internal audit rehearsals regularly. A minimum-viable rehearsal is simple: assign an internal reviewer who did not implement the controls, ask them to retrieve evidence for the 10 highest-risk controls as if they were the auditor, and document what they cannot find. The reviewer must be someone other than the implementer, ideally a cross-functional swap, so blind spots surface before fieldwork does.

Assign named owners to every control in scope. If only one person understands how a control works, that is not ownership. It is a single point of failure. Ownership means the named person can be replaced without the control going dark.

As Michael Skiles, Co-founder of ConstellationGRC, put it:

Audit risk model vs risk assessment frameworks

Compliance teams often work with both the audit risk model and broader risk assessment frameworks. Understanding where one ends and the other begins prevents confusion about which tool to apply and when.

Audit risk model vs. enterprise risk assessment framework

The audit risk model is a precision instrument. It tells you how much confidence an auditor can place in a specific set of controls and evidence at a given point in time.

Risk assessment frameworks like NIST CSF and the risk management components embedded in SOC 2 and ISO 27001 operate at a broader level, helping organizations identify, prioritize, and treat risk across the whole business. A mature ISO 27001 ISMS lowers your inherent risk inputs by keeping your asset inventory, threat landscape, and treatment decisions documented and current, which directly reduces the auditor's perceived risk at planning.

The two are complementary: a mature risk assessment framework lowers your inherent and control risk inputs, which means the auditor's perceived risk is lower before a single control is tested.

How to apply the audit risk model across compliance frameworks

The ARM is not framework-specific. Whether you're working toward SOC 2, ISO 27001, HIPAA, or PCI DSS, the same components apply. What changes is how inherent risk manifests, what control gaps look like, and what the auditor scrutinizes. All Annex A control references below are to ISO 27001:2022.

Framework-specific mapping of Audit Risk Model (ARM) components

Prioritize control investment where inherent risk is highest and monitoring coverage is thinnest; the triggering framework is secondary to that decision. Mapping SOC 2 controls to ISO 27001, HIPAA, and PCI DSS requirements lets a single piece of evidence satisfy several audits at once.

Limitations of the audit risk model

The ARM is a powerful planning tool, but it was designed for a different era of auditing. Applied without adaptation, it carries several limitations modern teams need to account for.

Scoring inherent and control risk relies on professional judgment, and two assessors examining the same environment can reach meaningfully different conclusions. That variance is not a flaw in the model. Document your scoring rationale so it can be defended when challenged. A SaaS company with 50 engineers holding elevated production access might be scored high inherent risk by one firm and medium by another, the difference being how the assessor weights the access control environment, not a difference in the underlying facts.

The model also struggles in rapidly changing environments. A SaaS company running continuous deployment with 50-plus production releases per month will find that a risk score calculated at the start of an audit cycle no longer reflects the environment by the time fieldwork begins. 

The model captures a moment; modern cloud environments are in continuous motion.

Periodic application misses real-time drift too. The ARM is typically applied during planning, not continuously. Control failures that occur and resolve between assessments may never enter the model at all.

Automation gaps create a related problem. Organizations that have partially automated evidence collection may have blind spots in uncovered systems, and those blind spots are precisely where auditors are most likely to find exceptions, because the compliance team has no visibility there either.

Finally, the model does not account for auditor quality. A less rigorous firm may accept higher detection risk with less evidence, producing a clean report that does not reflect actual control effectiveness. 

Conclusion: The audit risk model is becoming a continuous compliance model

The audit risk model has not changed. What has changed is the environment it operates in, and the standard of rigor required to use it well.

The organizations that reduce audit risk most effectively are not the ones with the most documentation. They are the ones that continuously validate controls, centralize evidence, reduce detection gaps, and operationalize monitoring across the whole environment. 

It is entirely possible to pass an audit while still carrying significant operational risk, because an audit opinion reflects what the auditor could see, not what went undetected. The formula stays the same. What improves is the quality of every input.

Reducing that gap is what Scrut is designed for. Automated evidence collection, continuous control monitoring, and centralized visibility address the manual, fragmented workflows that keep detection risk high and make control failures harder to catch before an auditor does.

Audit readiness is no longer an annual milestone. It is an ongoing operational capability, and the audit risk model is the framework that makes it measurable. If you're ready to move from periodic audits to continuous compliance, see how Scrut works in practice.