Preventive versus detective versus corrective is the first taxonomy every auditor learns and one of the most casually misused ideas in the profession. Textbooks teach it as vocabulary; practitioners need it as an engineering decision — because the type of a control is really a statement about when it acts relative to the error, and that timing drives everything practical: what the control costs, what evidence it leaves, how you test it, and what happens downstream when it fails. A process protected only by prevention fails silently the day someone finds the gap; a process covered only by detection runs on cleanup forever; and a detective control with no corrective loop is a smoke alarm in an empty building.
This is the reference version: crisp definitions and the conflations to avoid, the cost-and-assurance trade-offs that decide which type belongs where, the layering doctrine — prevent first, detect always, correct completely — and a categorized library of fifty real control examples across six process families, each tagged by type. It pairs with our COSO 17 principles reference, where the mix of control types is exactly what Principle 10 asks you to choose deliberately.
This reference was rewritten in September 2026 to add what the September 1 version left out: the three columns drawn for four real-shaped processes from the engagements on this site, with the empty column named in each; a calibration table of twelve controls that auditors classify wrongly and why; the two labels that are not types, directive and compensating, and how they relate to the three that are; the mapping from the taxonomy to COSO’s components, the ITGC domains and the fraud triangle; and a test procedure template for each type. The definitions, the trade-offs, the layering doctrine and the fifty-example library are unchanged.
In this guide
- The three types — and the axes people conflate with them
- Cost, assurance, and when each type is preferable
- The layering doctrine: prevent first, detect always, correct completely
- The three columns, drawn for four processes
- The 50-example library, by process family
- Classification calibration: twelve controls auditors get wrong
- Directive and compensating: the two labels that are not types
- Mapping the taxonomy to COSO, the ITGC domains and the fraud triangle
- How type changes testing
- A test procedure template for each type
- Where to go next
The three types — and the axes people conflate with them
A preventive control acts before the event: it stops the error or improper transaction from happening at all — the approval required before payment, the system edit that rejects an invalid entry, the segregation that makes single-handed fraud structurally impossible. A detective control acts after the event: it finds errors and irregularities that got through — the reconciliation, the review, the exception report, the physical count. A corrective control acts on what detection found: it fixes the error, recovers the loss, and repairs the condition that allowed it — the error-correction procedure, the adjusting entry with root-cause follow-up, the restore from backup. The three form a sequence, not a menu: detection without correction changes nothing, and correction without detection has nothing to act on.
Keep the taxonomy clean by refusing three common conflations. Type is not automation: preventive and detective each come in manual and automated forms — a system edit check and a supervisor’s pre-approval are both preventive; a matching job and a human reconciliation are both detective. The automation axis matters enormously for testing (see our ITGC reliance guide) but it is a different axis. Type is not importance: key/non-key is a risk judgment; plenty of key controls are detective. Type is not level: entity-level and transaction-level controls both span all three types. When a control seems to resist classification — the classic puzzle is the review that both catches errors and deters sloppy preparation — classify by its primary mechanism: what the control actually does when it operates, not the side effects of its existence.
Cost, assurance, and when each type is preferable
Prevention is the cheapest assurance per error — when the risk is definable in advance. An automated three-way match costs nearly nothing per transaction and stops the bad payment before money moves, which beats recovering it at collection rates every time. The limits of prevention are just as structural: it can only stop what its rules anticipate, it adds friction exactly where the business wants speed (every blocked transaction is a phone call), and over-prevention breeds workarounds — the emergency-payment channel that quietly becomes the main channel. Detection is mandatory because prevention is porous. No rule set anticipates everything, preventive controls themselves fail, and collusion or override defeats them silently — so every material process needs a detective layer that would catch what slipped through, at a precision matched to what you care about missing (the same precision logic that governs review controls). Detection’s economics run the other way: cheap to install, expensive per error found, and its value decays with delay — a reconciliation performed ninety days late detects history, not risk. Correction is where the loop earns its keep. Its cost is dominated by volume, which is why a spike in corrective activity is itself a signal: correction working hard means prevention and detection working badly. The design heuristic that falls out: spend prevention on high-volume, rule-definable risks; guarantee detection over everything material; and treat corrective workload as a dashboard, not just a duty.
The layering doctrine: prevent first, detect always, correct completely
Well-designed processes layer the types deliberately. Watch it work in accounts payable: prevention — vendor onboarding verification, the segregation between vendor maintenance and payment, the automated three-way match with tolerance blocks; detection — the duplicate-payment and vendor-change analytics, the supplier statement reconciliations, the payment-run review; correction — the recovery procedure for confirmed duplicates, the vendor-master cleanup, and the root-cause fix when the same leak reopens. Three layers, each catching what the previous one structurally cannot. The doctrine in three clauses: prevent first, because stopped errors cost least; detect always, because prevention is never complete — a process whose only controls are preventive is a process with no way to know they’re working; correct completely, meaning the fix includes the root cause, or detection will meet the same error again next cycle. When you assess any process, draw its controls in these three columns — the empty column is the finding, and it is usually the third one.
The three columns, drawn for four processes from the engagements on this site
The doctrine says to draw any process in three columns and hunt the empty one. Here it is done for four of the worked engagements written up elsewhere on this site, using what the fieldwork actually found in each layer rather than what the process documentation claimed. Read the last column first: in three of the four, the finding that carried the report sat in a layer that existed on paper and did not operate, which is the more common shape of “empty” than a layer nobody designed.
| Process and engagement | Preventive layer, as found | Detective layer, as found | Corrective layer, as found | The empty column, and the finding |
|---|---|---|---|---|
| MidState accounts payable | Three-way match and approval limits operating; vendor bank-change verification designed as a call-back to a number on file but not performed for 31 of 46 changes, most of which arrived by email | No duplicate-payment or vendor-change analytics; the payment-run review looked at totals, not at changes; one fraudulent instruction for $62,000 was stopped by the bank, not by the company | A recovery procedure existed for duplicates; nothing was defined for a diverted payment, and no one owned the retroactive verification of past changes | Detection. The preventive control had a hole and nothing behind it would have seen a payment go through the hole: a High, with the detective analytic becoming management’s monitoring control |
| Lakeshore account reconciliations | Preparer and reviewer separated in the tool; but eight preparers held posting rights to the accounts they reconciled, three of them suspense accounts | Reviews evidenced as approvals: one reviewer approved 210 reconciliations in forty minutes, queries recorded on 2 percent of reviews in a year; aging of reconciling items tracked but not reported | Differences were cleared by entry: 27 clearing journals for $640,000, eleven unapproved, and 41 write-offs of $312,000, nine beyond the approver’s authority | Detection operated in name only, and the corrective layer had become the concealment mechanism: the High finding was about entries that made differences disappear, not about the differences |
| MidState purchasing cards | Merchant blocks and limits operating on the legacy program; the acquired distributors’ cards blocked cash advances only; the single-transaction limit was porous to splitting, 61 clusters, 44 with one vendor | The administrator’s monthly review had no split-transaction query; 22 percent of statements reconciled late; the suspension rule was configured with a 120-day deadline and never fired | Recoveries made during the engagement: $4,300 of duplicated expense claims, $1,100 of post-termination transactions, a $31,000 rebate unclaimed for two years | Detection. Every preventive control was doing what its rules anticipated, and the behavior had moved one level down the spend stack where no rule looked: a High, with the split query added to the monthly review |
| Brightwater fixed assets | Capital expenditure approval against budget operating; the $5,000 capitalization threshold applied inconsistently, nine of forty repairs capitalizable; 19 of 84 disposals unapproved | No existence verification on rotation: nine of 180 sampled assets could not be found, $84,000; an idle bottling line at $1.4 million carried at cost with no impairment review; the insurance schedule stale at $6 million | Catch-up depreciation of $52,000 on two projects idle for 14 and 19 months, booked during fieldwork; a forklift disposed for $1,200 against a $6,500 carrying value with no review of the price | Detection, entirely: nothing in the process looked for assets that had left, stopped working or lost value, so the corrective entries were all made by the audit |
Two patterns generalize beyond the four. First, the preventive layer is usually present and usually rated adequate at design, and the failures come from a rule that did not anticipate the case, an email treated as a call, a limit that can be split, a threshold applied by the person who benefits from misapplying it. That is the structural limit of prevention described above, and it is why the detective column decides the rating. Second, when the corrective layer exists without an honest detective layer in front of it, correction turns into concealment: a clearing entry, a write-off, a plug, each of which removes the evidence that detection would have needed. A function that sees corrective volume rising while detective findings stay flat should assume the second pattern until it has proved otherwise; the fraud red flags library lists the specific entries to look for.
The 50-example library, by process family
Fifty real controls, tagged P (preventive), D (detective), or C (corrective). Use them as design prompts and classification calibration — and notice the deliberate pattern in every family: a preventive core, a detective net, a corrective loop.
Purchase-to-pay
| # | Control | Type | What it stops or catches |
|---|---|---|---|
| 1 | Automated three-way match with tolerance block | P | Payment without matching PO and receipt |
| 2 | Vendor-master maintenance segregated from invoice entry and payment | P | Create-a-vendor-and-pay-it fraud |
| 3 | Callback verification on vendor bank-detail changes | P | BEC payment diversion |
| 4 | System-enforced approval limits per the DOA matrix | P | Spending beyond delegated authority |
| 5 | Duplicate-invoice check at entry (vendor + invoice number) | P | Double entry of the same invoice |
| 6 | Duplicate-payment and vendor-red-flag analytics run monthly | D | Duplicates and diversion that got through |
| 7 | Supplier statement reconciliations for top vendors | D | Missed credits, duplicate payments, disputes aging silently |
| 8 | Vendor-master change report reviewed by someone who can’t make changes | D | Unauthorized master-data edits |
| 9 | Duplicate-recovery procedure with root-cause fix per recovery | C | Money returned and the leak closed, not just plugged |
Payroll and HR
| # | Control | Type | What it stops or catches |
|---|---|---|---|
| 10 | Payroll master changes require HR-sourced documentation and approval | P | Unauthorized rate and bank changes |
| 11 | Payroll processing segregated from employee master maintenance | P | Ghost employees created and paid by one person |
| 12 | System-enforced pay ranges per grade | P | Above-band payments without exception approval |
| 13 | Pre-transmission payroll register review against prior run with variance thresholds | D | Anomalous swings before the money moves |
| 14 | Payroll-to-HR headcount reconciliation each cycle | D | Register orphans — paid IDs with no HR record |
| 15 | Ghost-employee analytics: shared bank accounts, addresses, no-activity matches | D | The schemes single files never show |
| 16 | Off-cycle and manual payment approval at elevated level | P | The side door into payroll |
| 17 | Overpayment recovery procedure with tracking to collection | C | Errors recovered, not written off by inertia |
Revenue and order-to-cash
| # | Control | Type | What it stops or catches |
|---|---|---|---|
| 18 | Automated credit-limit block on order entry | P | Shipping to customers who won’t pay |
| 19 | Pricing master restricted to pricing team; sales cannot edit | P | Unauthorized discounting at the source |
| 20 | Invoice generation matched to shipping confirmation | P | Billing for what didn’t ship — or not billing what did |
| 21 | Credit memo approval independent of the originating salesperson | P | Credits used to bury lapping or side deals |
| 22 | Revenue cutoff review over period-end shipments and returns | D | Revenue recorded in the wrong period |
| 23 | AR aging review with documented follow-up on past-due balances | D | Collectability problems and misapplied cash |
| 24 | Unapplied-cash and credit-balance investigation on a cadence | D | Lapping signatures and application errors |
| 25 | Write-off approval with recovery pursuit and pattern review | C | Losses closed out deliberately — and repeat causes surfaced |
General ledger and close
| # | Control | Type | What it stops or catches |
|---|---|---|---|
| 26 | Journal entry approval workflow — preparer cannot post own entries above threshold | P | Unreviewed manual entries reaching the ledger |
| 27 | Posting-period lock after close | P | Back-dated entries rewriting a closed period |
| 28 | Suspense and clearing accounts restricted, with aging limits | P | Differences parked forever instead of resolved |
| 29 | Balance-sheet reconciliations, all key accounts, reviewed and aged | D | Account balances drifting from supportable reality |
| 30 | Flux and budget-versus-actual analysis with stated thresholds | D | Misstatements large enough to move the story |
| 31 | Journal-entry risk-scoring analytics across the full population | D | Override patterns — see the JE analytics catalog |
| 32 | Standard support requirements for manual entries (source docs attached) | P | Entries that cannot be re-derived later |
| 33 | Error-correction procedure: reviewed correcting entries plus root-cause note | C | Fixes that stay fixed |
IT and access
| # | Control | Type | What it stops or catches |
|---|---|---|---|
| 34 | Access provisioning via approval workflow with role-based defaults | P | Ad hoc access accumulation |
| 35 | SoD simulation at provisioning — conflicts shown before approval | P | New toxic combinations at the source |
| 36 | Automated deprovisioning on HR termination feed | P | Leavers keeping access |
| 37 | Authentication configuration: MFA, session limits, password policy | P | Credential-based intrusion |
| 38 | Quarterly user access review with decision-quality data | D | Access drift the JML machinery missed |
| 39 | Privileged session logging with independent review | D | What the most powerful accounts actually did |
| 40 | Change management: authorization, testing, segregated migration | P | Unauthorized or broken changes reaching production |
| 41 | Security event monitoring with alert triage | D | Intrusions and anomalies in progress |
| 42 | Revocation SLA with post-SLA re-extract verification | C | Revoke decisions that actually became removals |
Inventory and fixed assets
| # | Control | Type | What it stops or catches |
|---|---|---|---|
| 43 | Receiving inspection: counts and condition verified against PO before acceptance | P | Paying for goods not received as ordered |
| 44 | Physical access to warehouse and high-value storage restricted | P | Walk-out shrinkage |
| 45 | Cycle counts on a risk-weighted schedule | D | Record-to-reality drift, caught early |
| 46 | Periodic full physical inventory reconciled to the ledger | D | The cumulative error cycle counts missed |
| 47 | Shrinkage analysis by location and SKU against expectations | D | Theft and process-loss patterns |
| 48 | Count-variance adjustments investigated and approved before booking | C | Differences resolved with causes, not plugged |
| 49 | Capital expenditure approval against budget and policy thresholds | P | Unauthorized asset spend |
| 50 | Fixed-asset existence verification on rotation | D | Assets on the books that left the building years ago |
Classification calibration: twelve controls auditors get wrong
The fifty examples above are tagged correctly; the twelve below are the ones that get tagged wrongly in risk and control matrices every week, usually because the label was chosen for what the control is meant to achieve rather than for when it acts. The rule from the definitions section settles all of them: classify by the primary mechanism, what the control does when it operates, at the moment it operates.
| Control | Usually tagged | Actually | Why |
|---|---|---|---|
| Quarterly user access review | Preventive | Detective | It finds access that already exists and should not; provisioning approval is the preventive control in front of it. Tagging it preventive is how functions end up with no preventive control over access at all |
| Segregation of duties | Detective, or “entity-level” | Preventive | It makes the single-handed transaction structurally impossible before it happens; the SoD conflict report that finds violations is a separate, detective control |
| Management review of a reconciliation | Preventive, “because the reviewer would stop errors” | Detective | The reconciliation has been prepared and the balance already exists; the review finds what is wrong with it. Deterrence of sloppy preparation is a side effect, not the mechanism |
| Code of conduct, policy, training | Preventive | Directive (see below) | It tells people what to do and stops nothing by itself; it becomes relevant to the taxonomy only through the controls that enforce it |
| Backup and restore | Preventive | Corrective | Backups do not stop data loss; they repair it. The preventive controls are access restrictions and change management; the detective control is the restore test that finds the backup nobody can read |
| Multi-factor authentication | Detective | Preventive | It blocks the login before it happens; the detective control is the sign-in log review that finds the MFA fatigue attack that succeeded |
| Exception report that nobody reviews | Detective | Not a control | Detection requires a person or a system to act on the output. An unreviewed report is evidence that a control was designed, not that one operates |
| Whistleblower hotline | Preventive, “deters fraud” | Detective | It surfaces what has already happened; its deterrent effect is real and unmeasurable and does not change the classification |
| Insurance and indemnities | Corrective | Risk financing, outside the taxonomy | It transfers the financial consequence and neither prevents, detects nor fixes the event; listing it in the corrective column hides an empty column |
| Posting-period lock | Detective | Preventive | It refuses the back-dated entry at the moment of posting; the flux analysis that would notice a rewritten period is the detective layer |
| Post-payment audit of expense claims | Preventive, “because staff know it happens” | Detective | The money has moved; the audit finds what should not have been paid. The pre-payment approval is the preventive control, and the recovery is the corrective one |
| Automated three-way match with a tolerance block | Detective, “because it matches” | Preventive | The block stops the payment before it is made; a matching report reviewed after payment would be detective, and the difference is the whole point of the taxonomy |
Directive and compensating: the two labels that are not types
Two words appear in most control frameworks alongside the three types and cause more classification arguments than the types do. Neither is a fourth type; both describe something else about a control.
Directive controls tell people what should happen: policies, procedures, codes of conduct, training, job descriptions, tone at the top. Some frameworks list them as a type, and the temptation is to tag every policy as preventive, which is how a risk and control matrix comes to show a preventive control over fraud that consists of a paragraph in the employee handbook. The useful treatment is to record directive controls as the criteria the other controls enforce: the policy that says two approvals are required is the criteria, the workflow that refuses to route without two approvals is the preventive control, and the report of transactions approved outside the workflow is the detective control. When a matrix has a directive control standing alone against a risk, the finding is that the risk has no operating control, and the policy is the criteria the finding cites.
Compensating controls are controls that substitute, in whole or in part, for a control that is missing or not operating, and a compensating control can be any of the three types. The small company that cannot segregate vendor maintenance from payment (a missing preventive control) compensates with an owner’s monthly review of new vendors and payments to them (a detective control). Two rules keep the label honest. A compensating control has to be evaluated against the risk the missing control addressed, at a precision that would actually catch the consequence; a review of payment totals does not compensate for a missing call-back. And the compensation has to be recorded as such in the matrix, with the missing control named, so that the deficiency evaluation can weigh it and so that nobody later reads the compensating control as the design. The severity matrix treats an effective compensating control as the fact that turns a High into a bounded High, which is why the label matters to the rating and not only to the taxonomy.
| Label | What it describes | Is it a type? | How to record it in the RCM |
|---|---|---|---|
| Preventive, detective, corrective | When the control acts relative to the event | Yes: the three types | One tag per control, by primary mechanism |
| Directive | The instruction the enforcing controls implement | No: it is the criteria | Cite as the policy reference on the controls that enforce it; never as the only control against a risk |
| Compensating | The relationship of a control to a missing or failed one | No: a compensating control has a type of its own | Tag the type, and add the reference to the control it compensates for and the precision at which it does so |
| Deterrent | The behavioral effect of a control’s known existence | No: an effect, not a mechanism | Do not tag; classify the control by what it does when it operates |
| Key and non-key | Whether the control’s failure alone would leave the risk unaddressed | No: a risk judgment on a different axis | A separate column, decided per risk, not per type |
| Manual and automated, ITGC-dependent | How the control operates and what it depends on | No: the automation axis | A separate column; it drives the test approach, not the classification |
Mapping the taxonomy to COSO, the ITGC domains and the fraud triangle
The taxonomy is a timing axis, so it cuts across every framework rather than sitting inside one. The mappings below are the ones that come up in practice, and each is a place where an empty column shows up as a framework gap: a control activities layer with no detective controls fails Principle 10’s mix requirement; an IT operations domain with backups but no restore test has a corrective control with no detective one in front of it; a fraud program that is all prevention has no way to learn what its prevention missed.
| Framework element | Preventive | Detective | Corrective | The gap to look for |
|---|---|---|---|---|
| COSO control activities (Principles 10 to 12) | Authorizations, segregation, system edits, access restrictions | Reconciliations, reviews, verifications, analytics | Error correction, recovery, adjustment with root cause | Principle 10 asks for a deliberate mix; a process whose control activities are all one type has not chosen |
| COSO monitoring activities (Principles 16 and 17) | Rarely; monitoring acts after operation by design | Ongoing and separate evaluations, including internal audit itself | Remediation of deficiencies evaluated and communicated under Principle 17 | Deficiencies reported and never remediated: monitoring with no corrective loop |
| ITGC: access | Provisioning approval, role design, MFA, automated deprovisioning | User access review, privileged session review, log monitoring | Revocation with re-extract verification | Access reviews that decide and never remove: detection with no correction |
| ITGC: change management | Authorization, testing, segregated migration | Production change reconciliation to tickets, emergency change review | Backout and the post-implementation fix | Emergency changes reviewed after the fact but never reconciled to production: the detective control that trusts its own input |
| ITGC: operations and backup | Job scheduling controls, capacity thresholds | Job failure monitoring, backup success reporting, restore testing | Restore, job re-run, incident resolution | Backups reported successful that were never restored: a corrective control never proved to work |
| Fraud: opportunity, pressure, rationalization | Segregation, approvals, access limits (opportunity); tone and policy as criteria (rationalization) | Analytics, reconciliations, the hotline, the surprise count | Recovery, referral under the protocol, and the control fix that closes the scheme | Prevention aimed at opportunity with nothing that would notice the collusion or override that defeats it |
How type changes testing
Classification pays off hardest in test design, because each type fails differently. Preventive controls — especially automated ones — are configuration questions: a strong test of design, a test-of-one on the setting, and reliance on ITGCs to carry the conclusion forward; the classic miss is testing the happy path and never attempting the transaction the control should block. Detective controls need two conclusions, and auditors reliably get only the first: that the review or reconciliation operated, and that what it flagged went somewhere — the follow-through half, which is exactly where user access reviews and management reviews break in practice. Sample instances, re-perform the detection logic, then trace flagged items to resolution. Corrective controls are tested by outcome: take detected errors and confirm the fix completed, the amount recovered or adjusted, and the root cause addressed — a corrective control whose queue only grows is not operating, whatever the procedure says. And across all three, remember the taxonomy’s testing dividend: when a preventive control fails, your next question is whether the detective layer behind it caught the consequences — which is the layering doctrine turned into severity analysis.
A test procedure template for each type
The testing section above says how each type fails; the three templates below turn it into procedures you can paste into a work program, with the sample sizes left to your sampling parameters. Each has the shape the work program guide recommends: population, selection, procedure, evidence, conclusion, with the type-specific step in bold.
Preventive control. Population: every transaction the control should have blocked or required approval for in the period. Selection: the configuration (test of one) plus a sample of transactions at the boundary. Procedure: inspect the setting or the approval rule against the criteria; attempt or trace a transaction the control should refuse and confirm the refusal; for the sample, confirm the approval or block preceded the event. Evidence: the configuration screen with date, the refused transaction, the approval timestamps. Conclusion: the control operated if no transaction in the population passed without the condition the control enforces; where it is automated, state the ITGC reliance the conclusion depends on.
Detective control. Population: every instance of the review, reconciliation or report in the period, and every item it flagged. Selection: a sample of instances, and within them every flagged item. Procedure: confirm the instance occurred on time and by an independent person; re-perform the detection logic on the underlying data and compare what you find to what it found; trace every flagged item to its disposition. Evidence: the instance with its evidence of review, your re-performance, the disposition trail. Conclusion: two conclusions, that the control operated and that what it found went somewhere; state both, because a review that operated and flagged nothing over a population with errors did not detect.
Corrective control. Population: every error, exception or loss that detection recorded in the period. Selection: a sample weighted to the largest and the oldest. Procedure: confirm the fix was made, the amount recovered or adjusted and approved within authority, and the root cause addressed rather than the instance; measure the queue at the start and end of the period. Evidence: the correcting entry or recovery with approval, the root-cause note, the aging of the open queue. Conclusion: the control operated if the queue is being worked to completion and the same causes are not recurring; a queue that only grows is a corrective control that is not operating, whatever the procedure says.
Final thoughts
Prevent first, detect always, correct completely: the taxonomy is a design doctrine wearing a vocabulary lesson’s clothes. Use the fifty examples as calibration, draw any process you audit in three columns, and hunt the empty column. It is usually detection that has stopped operating or correction that has become concealment, it is always a finding, and fixing it is how control environments stop relearning the same lesson annually. The four engagements drawn above say the same thing in numbers: every one of them had a preventive layer that was rated adequate at design, and every one of them was carried by what the detective layer did or did not see.
Where to go next
The taxonomy is used in three places on this site. In the RCM template, where type is a column and the mix is what Principle 10 asks you to choose; in the test of design versus operating effectiveness guide, where the type decides the test; and in the process guides, where each layer is tested in turn: accounts payable, account reconciliations, purchasing cards and fixed assets for the four processes drawn above. The Internal Controls and Internal Audit Basics categories hold the rest.
Related guides
- COSO’s 17 Principles: The Complete List — where the mix of control types lives in the framework, Principle 10.
- The Risk and Control Matrix Template — type, key status and automation as separate columns.
- Test of Design vs Operating Effectiveness — what happens after classification.
- Segregation of Duties — the preventive control most often mis-tagged, and how to test it.
- Management Review Controls — the precision logic that decides whether a detective control detects.
- User Access Reviews — the detective control that fails on follow-through.
- ITGCs vs Application Controls — the automation axis, and the reliance an automated preventive control depends on.
- How to Audit IT Change Management — the preventive, detective and corrective layers of one ITGC domain.
- How to Audit Backup and Recovery — the corrective control that has to be proved by a restore.
- Journal Entry Analytics — detective analytics over the full population.
- Accounts Payable Analytics — the duplicate and vendor-change tests that fill the detective column.
- Evaluating Control Deficiencies — how compensating controls are weighed when a layer fails.
- Finding Severity Ratings: The Calibrated Matrix — the rating consequences of a missing or compensating layer.
- A Fraud Red Flags Library — the corrective entries that are really concealment.
- Fraud Risk Management: Prevention, Detection and Response — the taxonomy applied to a fraud program.
- How to Audit Accounts Payable — the engagement behind the first row of the three-column table.
- How to Audit Account Reconciliations as a Program — the second row.
- How to Audit Purchasing Cards — the third row.
- How to Audit Fixed Assets — the fourth row.
- Internal Audit Work Program: Template and Worked Example — the procedure shape the three templates use.
- Control Design Principles: What Makes a Control Work — what makes a control well designed, with the failure patterns and a design checklist
Leave a Reply