A red flag is not a finding. It is a probability shift — a fact pattern that appears more often around fraud than around honest work — and its only legitimate job is to tell you where to test next. That distinction is what separates a useful red-flag library from a paranoia generator: most flags have innocent explanations most of the time, single flags mean little, clusters mean more, and nothing in this library ever justifies an accusation — only a procedure. Which is why this library is built the way it is: every flag comes paired with its confirming test, the specific move that converts “that looks odd” into evidence or into a closed question.
Forty-eight flags across seven categories — procurement, payroll, sales and receivables, inventory, treasury, financial reporting, and the behavioral layer that cuts across all of them. Use it at three moments: during the fraud risk assessment, when choosing which schemes deserve standing coverage; during fieldwork, when something in the data or the interviews snags; and during triage of analytics output from our AP, payroll, and journal entry catalogs, which automate many of these flags at population scale.
This library was rewritten in September 2026 to add what the September 1 version left out: a triage method that scores a cluster of flags and decides between closing, expanding and referring; six flags from the engagements on this site, three that turned out to be real and three that did not, with the confirming test that settled each; the analytics query behind each cycle’s flags; and the triage note that records what was done with a flag so that the next auditor, or the investigator, can see it. The forty-eight flags and their confirming tests are unchanged.
In this guide
- How to use a red-flag library without embarrassing yourself
- Triage: from a cluster of flags to a decision in four steps
- Procurement and vendors (8 flags)
- Payroll (6 flags)
- Sales and receivables (7 flags)
- Inventory (6 flags)
- Treasury and disbursements (6 flags)
- Financial reporting and override (7 flags)
- The behavioral layer (8 flags — handle with care)
- Six flags from the engagements on this site: three real, three not
- The query behind each cycle’s flags
- The triage note
- Where to go next
How to use a red-flag library without embarrassing yourself
Four rules keep the library honest. Flags trigger tests, never conclusions — the confirming test exists precisely because the innocent explanation is usually true, and the test is how you find out cheaply and quietly. Clusters outrank singles: a vendor with a PO-box address is a small fact; a PO-box vendor created by a buyer who also approves its invoices, with prices creeping since award, is a pattern worth an afternoon. Corroborate before you escalate: whatever the test finds becomes a matter for documented evidence, and anything pointing at a named person goes through counsel and the fraud-response protocol before it goes through anyone’s hallway conversation. And mind the base rate: in a large population, every flag below will fire on innocent cases — the discipline of false-positive notes from the analytics catalogs applies to human judgment too.
Triage: from a cluster of flags to a decision in four steps
The four rules above say what not to do with a flag. This is what to do, in the order that keeps the work quiet and the conclusions defensible. It assumes what is usually true: several flags have fired in one span of control, some from analytics, some from the interviews, and the question is whether they add up to anything.
Step one: catalogue the cluster. List every flag that has fired in the same span of control, the person, vendor, customer, account or location they share, and the source of each: an analytic, a document, an interview, an observation. Discard nothing at this stage, but mark each flag as independent or derived; three analytics that all key off the same vendor master field are one flag, not three.
Step two: score it. Four properties decide how much a cluster is worth, and the table converts them into a rough score. Independence: how many of the flags come from different data or different sources. Concentration: whether the flags converge on one person or one counterparty, or are spread across a process. Direction: whether the flags all point the same way, toward money leaving in one direction, or are noise that points everywhere. Magnitude: whether the exposure inside the span of control is large enough to matter if the flags are real, measured against the rating anchors in the severity matrix.
| Property | Score 0 | Score 1 | Score 2 |
|---|---|---|---|
| Independence | One flag, or several flags from one source or one field | Two independent flags | Three or more flags from different sources, including at least one that is not an analytic |
| Concentration | Spread across the process, no common person or counterparty | Concentrated on one location, team or counterparty | Concentrated on one person, or on one person and one counterparty together |
| Direction | Flags point in different directions, consistent with error | Mostly one direction | All one direction, toward value leaving, and consistent with a named scheme in the fraud tree |
| Magnitude | Exposure in the span of control below the Low anchor | Exposure at the Moderate anchor | Exposure at the Major anchor or above, or any exposure with signs of concealment |
Step three: run the confirming tests, cheapest and quietest first. The score decides the depth, not the conclusion. A cluster scoring 0 to 2 gets its confirming tests run inside the normal fieldwork and a triage note; 3 to 5 gets the tests run before anything else in the area, with the population expanded around the concentration and the sample drawn by the auditor rather than by the process; 6 to 8 gets the tests run without the process owner’s narration, from raw data the auditor pulls, and the audit manager informed the same day. Order the tests by two properties: cost, because a registry lookup is cheaper than a re-performance, and visibility, because a test that can be done from data already in hand does not tell anyone what is being looked at. Tests that require asking the person at the center of the cluster for anything come last, and only after counsel has been consulted if the score is 6 or more.
Step four: decide, in writing. Three outcomes, and only three. Closed: the confirming tests produced the innocent explanation, and the triage note records the tests and the evidence so nobody re-runs them next year on the same suspicion. Expanded: the tests neither confirmed nor cleared, so the population, the period or the flags are widened and the cluster is re-scored, with a date. Referred: a test confirmed what the flag suggested, and from that moment the first 48 hours protocol governs; testing stops, the evidence is preserved, counsel is engaged, and the matter leaves the engagement’s findings and enters the protocol’s record. What is never an outcome is a conversation with the person, a note in the report that hints, or a rating that quietly reflects a suspicion the tests did not confirm.
| Cluster score | What it usually is | Depth of confirming tests | Who knows |
|---|---|---|---|
| 0 to 2 | Noise, error, or a control weakness with no actor | Inside normal fieldwork; sample as planned; triage note | The engagement team |
| 3 to 5 | A pattern worth an afternoon; most often a control failure that someone has learned to use | Tests run first, population expanded around the concentration, auditor-drawn samples | The audit manager, before the tests |
| 6 to 8 | A scheme-shaped cluster | Tests from raw data without the process owner’s narration; no contact with the person at the center until counsel says so | The audit manager the same day; the CAE and counsel before any contact |
Procurement and vendors (8 flags)
The richest habitat — covered in depth in our procurement and vendor master guides:
| Red flag | Why it matters | The confirming test |
|---|---|---|
| Sole-source awards clustering under one buyer | Competition avoidance is the front door of procurement fraud | Pull the sole-source justifications; re-quote a sample of the awards in the open market |
| Bid specifications only one vendor can meet | The spec was written backward from the winner | Trace spec authorship and revision history; compare to the winning vendor’s catalog language |
| Losing bidder appears as the winner’s subcontractor | Classic bid-rotation signature | Match subcontractor disclosures against the original bidder list across awards |
| Vendor invoices arrive in unbroken sequence | You are their only customer — the profile of a created vendor | Footprint verification: registry, address, phone, web presence, tax standing |
| Price creep after contract award | Low-ball bid recovered through the back door | Compare invoiced prices to contract rates for the life of the award |
| Purchase orders split just under approval thresholds | Authority limits being engineered around | Sum same-requester/same-vendor POs in short windows against the DOA matrix |
| Change orders shortly after award | Scope sold cheap, expanded immediately | Rank change-order percentage by buyer and vendor; read the early ones |
| Shell-profile vendor (PO box, no phone, generic email) | Minimal footprint is how fake vendors economize | Run the vendor-master red-flag battery: employee-match joins, bank-change history, creation-to-payment speed |
Payroll (6 flags)
| Red flag | Why it matters | The confirming test |
|---|---|---|
| Payments after termination date | The leaver kept alive is the easiest ghost | Trace post-term payments to final-pay entitlements; anything past the second cycle gets the full trail |
| Two employees, one bank account | Ghosts get paid somewhere real | Join payroll accounts across employees; resolve pairs against HR relationships and addresses |
| Overtime concentrated under one approver | OT padding needs a friendly signature | Compare the crew’s OT to peer crews; check hours that snap to identical values weekly |
| Off-cycle payment spikes by one processor | The side door sees the traffic | Rank off-cycle runs by processor and beneficiary; read the justifications |
| Rate changes with no HR event behind them | Raises should have paper | Join rate-change log to HR events; changes made by payroll-processing users get priority |
| Manual leave-balance adjustments recurring for the same people | Leave is money with worse logging | Pull the adjustment log by adjuster and beneficiary; recompute entitlements |
Sales and receivables (7 flags)
| Red flag | Why it matters | The confirming test |
|---|---|---|
| Credit memos clustering by one rep or one approver | Credits are the eraser of the revenue cycle | Rank credit-memo volume and value by originator; trace a sample to underlying disputes |
| Period-end sales spikes followed by early-period returns | The pull-forward signature | Compare last-week shipments to first-week returns by customer, quarter over quarter |
| Shipment volume to one distributor jumping at quarter end | Channel stuffing needs a willing warehouse | Distributor sell-through vs. sell-in; payment terms granted on the spike orders |
| Non-standard terms living in emails, not contracts | Side letters defeat revenue recognition from outside the system | Interview sales ops; sample large deals for term amendments and return rights — per our revenue guide |
| Unapplied cash aging while customers dispute balances | The lapping signature: money arriving, ledgers disagreeing | Match customer complaint log to application history; confirm balances directly on a sample |
| Write-offs initiated by the person who applies cash | Lapping needs write-offs to close the loop | Test the SoD; re-age written-off accounts and look for payment activity after write-off |
| Receivable growth persistently outpacing revenue growth | Sales that don’t convert to cash may not be sales | DSO trend by segment; collections testing on the oldest growth cohort |
Inventory (6 flags)
| Red flag | Why it matters | The confirming test |
|---|---|---|
| Persistent shrinkage at one location | Randomness spreads; schemes concentrate | Location-normalized shrinkage trend; surprise count at the outlier site |
| Count adjustments always booked by the same person | The adjuster owns the eraser | Pull the adjustment log by user; re-perform a sample of counts behind their entries |
| Negative inventory balances | Selling what the system says you don’t have means records are being managed | Trace negative-balance SKUs through receipts and issues; check for backdated entries |
| Scrap and salvage sold for cash with thin records | The classic off-books revenue stream | Reconcile scrap weight/volume records to sales proceeds; compare to production yield norms |
| Receipts recorded without inspection sign-off | Short shipments and substitutions enter here | Sample receipts for inspection evidence; compare received-vs-ordered specs |
| Stock movements to holding locations just before counts | Hiding the hole from the counters | Movement log for the pre-count week; count the holding locations too |
Treasury and disbursements (6 flags)
| Red flag | Why it matters | The confirming test |
|---|---|---|
| Reconciling items aging on bank recs | Old unexplained items are where diverted cash hides | Age every reconciling item; resolve or escalate anything past one cycle |
| Wires just under approval thresholds | Same engineering as split POs, faster money | Distribution of wire amounts vs. thresholds, by initiator |
| New beneficiary followed immediately by a large transfer | The BEC and insider-diversion signature | Beneficiary-creation log joined to first-transfer size and timing; verify callback evidence |
| Payment batch edited after approval | The approved list is not the paid list | Compare approved batch files to transmitted files; investigate every diff |
| Activity in dormant accounts | Forgotten accounts have forgotten reviewers | Map all accounts to owners and review cadences; trace the dormant activity end to end |
| Void and reissue patterns concentrated by one user | Voids are disbursement’s eraser | Void log by user; trace a sample of void-reissue pairs to the payee change between them |
Financial reporting and override (7 flags)
The category where the fraudster outranks the controls — which is why every test here runs on full populations and independent recomputation:
| Red flag | Why it matters | The confirming test |
|---|---|---|
| Topside entries at consolidation | Adjustments above the ledger bypass every process control | Pull all consolidation-level entries; demand business purpose and support for each |
| Round-number entries at period end | Real accruals are rarely tidy | The JE risk-scoring battery: round amounts × timing × poster |
| Entries posted by senior management or unusual users | Executives posting their own entries is override in progress | Poster-role analysis against expected posting populations; read every executive entry |
| Suspense and intercompany balances growing quietly | Where differences go to be forgotten | Age and decompose the balances; force resolution of the oldest layer |
| Estimates that always land favorably | Honest estimation error goes both ways | Back-test estimates against outcomes over several periods; a one-directional miss pattern is bias with a paper trail |
| Reserves released in the quarter that needed them | Cookie jars open when targets wobble | Reserve roll-forward against the earnings trajectory; support for each release’s trigger |
| Late adjustments that flip a metric across a line | Miss-to-beat conversions cluster around thresholds | Recompute the metric before and after final-week entries, every period |
The behavioral layer (8 flags — handle with care)
Behavioral flags are different in kind: they are context, never evidence, and they carry real potential to be unfair. A person can live expensively on family money, guard their work out of pride, and skip vacations out of anxiety — none of it fraud. The rule: behavioral flags re-weight where you point transactional tests; they never appear in a workpaper as support for a conclusion, and concerns about a specific person route through counsel and HR, not through audit fieldnotes. With that said, investigators keep finding the same patterns next to confirmed schemes:
| Behavioral flag | Why it recurs | The legitimate response |
|---|---|---|
| Never takes vacation; resists cross-training | Schemes need daily tending | Check enforcement of mandatory-leave and rotation policies; run analytics on the area during their absence |
| Control-hoarding — nothing documented, everything through them | Opacity is the scheme’s shell | Test the process without their narration: raw data, independent walkthrough |
| Unusually close vendor or customer relationship | Collusion has a social layer | COI declarations vs. transaction flow; the cross-file joins from the analytics catalogs |
| Hostility to routine review | Pressure leaks as defensiveness | Don’t escalate the interpersonal — escalate the sampling depth, quietly |
| Lifestyle visibly beyond known means | The classic, and the least reliable alone | No response by itself; weight it only alongside transactional flags in their span of control |
| Repeated “just this once” override requests | Overrides normalize in small steps | Log and trend exception requests by requester; read the pattern, not the instance |
| Turnover clustering under one manager | People leave rather than participate — or rather than watch | Exit-interview themes for the area; expanded testing where the leavers worked |
| Reluctance to promote or hand off a role | Succession exposes what handoffs reveal | Force the handoff question in continuity planning; audit the role at transition |
Six flags from the engagements on this site: three real, three not
The flags below fired in the worked engagements written up elsewhere on this site. Three were confirmed and went to the protocol; three had innocent explanations that the confirming test produced in an afternoon. They are shown together because the point of a library is the second group as much as the first: a function that only remembers the flags that were real starts treating every flag as an accusation, and a function that only remembers the innocent ones stops running the tests.
| Flag and engagement | Cluster | Score | Confirming test | What it found | Disposition |
|---|---|---|---|---|---|
| Unapplied cash aging while balances disagree (MidState order-to-cash) | 3,900 unapplied receipts over thirty days, $1.2 million; at one acquired depot, fourteen accounts whose postings alternated for five months; one settlement clerk applying all of them | 7 | Application pattern analytic on the depot’s receipts, then the payments traced customer by customer against remittances | A settlement clerk covering a $28,600 shortfall with later customers’ payments, for five months | Referred on day six; substantiated; kept out of the report; the control finding on cash application reported as a Low |
| Credit memos clustering by one originator (MidState order-to-cash) | 610 credit memos with no return receipt or pricing claim behind them, $410,000, concentrated in fourteen accounts served by two representatives, with the issuer approving their own credits | 6 | Credits traced to disputes and returns; the fourteen accounts’ balances confirmed with the customers | The control failure was real and rated High; the concentration was referred for the protocol to resolve | High finding on the credit memo control; the concentration referred |
| Gift cards coded as staff recognition with no recipients (MidState purchasing cards) | Fourteen gift card purchases at grocery and pharmacy merchants, $2,900; nine by one depot administrator; no recipient list for any | 6 | Recognition records requested for the depot through HR rather than through the cardholder; recipients asked to confirm receipt | Six of the nine could not be substantiated as given to anyone | Referred on day four; substantiated for six of nine; a Medium finding on the recognition policy’s documentation requirement |
| Contracts awarded just under a threshold, several to one vendor (Brightwater procure-to-pay) | Seven contracts between $90,000 and $99,900 in a year against a $100,000 tender threshold; four to one vendor for what management confirmed was a single project | 4 | Scope documents read for the four awards; the buyer’s other awards profiled; the vendor’s ownership and the buyer’s declarations checked | A single project split to avoid the tender, by a buyer under schedule pressure, after a prior remediation had closed the same behavior at the plant limit; no relationship between buyer and vendor, no personal benefit | Medium finding on displaced threshold circumvention, $380,000 of scope awarded without competition; no referral |
| Assets on the register that cannot be found (Brightwater fixed assets) | Nine of 180 value-weighted sampled assets not located, $84,000 net book value, across three plants | 2 | Maintenance and scrap records for the nine; transfer records between plants; interviews with the plant engineers | Seven scrapped without a disposal being raised; two moved between plants without a transfer; every one accounted for | Medium finding on physical verification and disposal discipline; no referral |
| Review performed at implausible speed (Lakeshore reconciliations) | One reviewer approving 210 reconciliations in forty minutes; queries on 2 percent of reviews in a year; three reviewers making 61 percent of approvals | 3 | The 210 reconciliations re-performed by a second reviewer; the reviewer’s assignment compared with the other eighteen | Two errors under $10,000; an assignment of 210 accounts against a median of 80, a one-click approval and a day-three deadline; no concealment | Medium finding on review quality, written about the program, not the person |
Three lessons sit in the table. The two clusters that scored highest were both found by an analytic and confirmed by a trace that never involved the person at the center until the protocol took over, which is what quiet means in practice. The threshold case is the shape most clusters take: a real control failure with a person’s fingerprints on it and no fraud, where the confirming test’s most important output was the absence of a relationship, recorded in the note so the finding could be written about the control without an accusation hanging over it. And the fixed asset case scored two and was closed by records that already existed, which is the base-rate rule doing its job; the same nine assets, at one plant, scrapped by one person with no scrap proceeds recorded, would have scored six.
The query behind each cycle’s flags
Most of the forty-eight flags can be run as a query at population scale before fieldwork starts, which changes what fieldwork is for: instead of hoping to notice a flag in a sample of forty, the auditor arrives with the clusters already scored and spends the time on confirming tests. The table gives the query shape for each cycle, the data it joins, the false-positive class that will dominate the output, and the catalog on this site that specifies it in full. Run them on a schedule for the cycles in the fraud risk assessment‘s top tier, and run them once, early, in every engagement that touches the cycle.
| Cycle | Query shape | Data joined | Dominant false positive | Catalog |
|---|---|---|---|---|
| Procurement and vendors | Sole-source share by buyer; awards within 10 percent below each threshold by buyer and vendor; invoice price against contract price by line; subcontractor names against bidder lists | Purchase orders, contracts, tender records, vendor master, invoices | Legitimate framework agreements and indexed price increases the contract permits | Procurement fraud analytics |
| Vendor master and payables | Employee-to-vendor joins on bank account, address, phone and tax number; bank changes followed by payments inside ten days; creation-to-first-payment interval; duplicate invoice near-matches | Vendor master with change log, employee master, payment file, invoice register | Employees who legitimately are vendors, rebates, and near-matches that are instalments | Accounts payable analytics |
| Payroll | Payments after termination; shared bank accounts and addresses across employees; rate changes without an HR event; off-cycle runs by processor; overtime hours snapping to identical values by approver | Payroll register, employee master with change log, HR events, time system | Final-pay entitlements, family members on the same payroll, and legitimate retroactive corrections | Payroll analytics |
| Sales and receivables | Credit memos by originator and approver with self-approval flagged; last-week shipments against first-week returns by customer; application patterns that alternate across accounts; write-offs by the person who applies cash | Sales orders, shipments, invoices, credit memos, cash application log, customer master | Seasonal quarter-end demand and genuine disputes resolved by credit | The order-to-cash guide‘s analytics section |
| Inventory | Shrinkage by location normalized for volume; count adjustments by user; negative balances by SKU; movements to holding locations in the pre-count week; scrap weight against proceeds | Perpetual inventory, count records, adjustment log, movement log, scrap sales | Timing differences between physical and system movements, and known process loss | The inventory section of the fixed assets guide‘s companion tests |
| Treasury and disbursements | Wire amounts against thresholds by initiator; new beneficiary to first transfer size and interval; approved batch file against transmitted file; activity in accounts with no review owner; void-and-reissue pairs by user | Payment platform logs, bank statements, beneficiary master with change log, batch files | Legitimate urgent payments and beneficiary corrections | The payables analytics and the treasury section of the fraud tree guide |
| Financial reporting and override | Entries scored on round amounts, timing, poster role, description quality and account pairing; consolidation-level entries in full; estimates back-tested against outcomes; reserve releases against the earnings path | General ledger with poster and approver, consolidation entries, estimate models, prior-period outcomes | Standard month-end accruals that are round by design, and estimates revised for real reasons | Journal entry analytics and the financial statement fraud guide |
The triage note
Every cluster that is scored gets a note, whatever the outcome, and the note is the workpaper that protects everyone: the person at the center of a cluster that was closed, who is never named in a report; the auditor, whose decision not to refer is recorded with its evidence; and the investigator, if there is one later, who needs to know exactly what was tested and who was told. Keep it to one page and keep it out of the engagement’s shared findings file until the outcome is known; where the score is six or more, the note goes in the restricted file the protocol describes.
Triage note — engagement, date, prepared by, reviewed by.
Span of control: [the person, counterparty, account or location the flags share, described by role and reference, not by name where the note may be shared]. Flags fired: [each flag, its source, and whether it is independent of the others]. Score: independence [0 to 2], concentration [0 to 2], direction [0 to 2], magnitude [0 to 2], total [n], with the exposure in the span of control stated.
Confirming tests run, in order: [test, data used, whether it required contact with anyone in the span of control, result, workpaper reference]. Innocent explanations considered: [the base-rate causes for each flag and the evidence that supports or rules out each].
Outcome: [Closed / Expanded, with the wider population and the re-score date / Referred, with the date, the protocol reference and the point at which testing stopped]. Who was informed and when: [audit manager, CAE, counsel, and nobody else]. What appears in the report: [the control finding, if any, written without reference to the individual].
The last field is the one that gets forgotten. A cluster that was referred still usually leaves a control finding behind it, a credit memo approval that lets the issuer approve their own, a cash application process with no pattern review, a recognition policy with no recipient requirement, and that finding belongs in the report in the language the five C’s guide prescribes, with the individual matter handled entirely outside it. The report examples library shows the one sentence that says a matter was referred without saying anything else.
Final thoughts
Forty-eight flags, one discipline: suspicion is a direction, tests are the vehicle, and evidence is the only destination. Keep the library in the fieldwork kit, run the analytics versions on a schedule, score clusters instead of counting flags, and write the note whatever the outcome. When a test confirms what the flag suggested, stop testing and start the protocol: counsel, evidence preservation, and the documentation standard that survives what comes next. And when the test produces the innocent explanation, which it will most of the time, record that with the same care, because the next auditor who sees the same flag deserves to know it was already run to ground.
Where to go next
The fraud shelf this library indexes: procurement, vendor master, payroll, travel and expense, purchasing cards and journal entry testing for the cycle guides, and the AP, payroll and journal entry analytics catalogs that automate the hunt. The fraud program guides take each cycle further: the ACFE fraud tree explained maps every scheme to the control it defeats and the analytic that finds it, how to run a fraud risk assessment turns the flags into a scored register, procurement fraud schemes and financial statement fraud go deep on the two most expensive branches, and the first 48 hours protocol covers what to do when a flag turns out to be real. The Fraud Risk and Fieldwork & Testing categories hold the rest.
Related guides
- The ACFE Fraud Tree Explained — every scheme mapped to the control it defeats and the analytic that finds it.
- How to Run a Fraud Risk Assessment — the flags turned into a scored register of schemes.
- When Internal Audit Finds Fraud: The First 48 Hours — what happens the moment a confirming test confirms.
- Procurement Fraud Schemes — the richest habitat, scheme by scheme.
- Financial Statement Fraud — the override branch at full length.
- Procurement Fraud Analytics — the queries behind the procurement flags.
- Accounts Payable Analytics — the vendor master and payment queries.
- Payroll Analytics — the ghost and rate-change queries.
- Journal Entry Analytics — the risk-scoring battery for override.
- How to Audit Procurement — the cycle guide behind the procurement flags.
- The Vendor Master Audit — the footprint and change-history tests.
- How to Audit Payroll — the cycle guide behind the payroll flags.
- How to Audit Travel and Expense — the double-dip and approval tests.
- How to Audit Purchasing Cards — the engagement behind the gift card case.
- How to Audit Order-to-Cash End to End — the engagement behind the lapping and credit memo cases.
- How to Audit Procure-to-Pay End to End — the engagement behind the threshold case.
- How to Audit Fixed Assets — the engagement behind the missing assets case.
- How to Audit Account Reconciliations as a Program — the engagement behind the review speed case.
- Journal Entry Testing — the manual tests behind the reporting flags.
- Audit Evidence: Sufficiency, Appropriateness and the Hierarchy — the documentation standard a referral has to meet.
- Finding Severity Ratings: The Calibrated Matrix — the magnitude anchors the triage score uses.
- Preventive, Detective and Corrective Controls — why the corrective entries in this library are often concealment.
Leave a Reply