Insights & Press — Ironside Risk Advisors
BLOG    ·  Inventory Management  ·  Loss Prevention  ·  12 min read
The Complete Guide to Cycle Counting: Process, Discipline, and What the Data Is Really Telling You
A step-by-step operational guide to designing, executing, and extracting insight from a cycle count program that actually works

By Mitchell Hamm  |  Founder & Principal Advisor, Ironside Risk Advisors  |  Dallas, TX

There is a question I ask every retail and distribution operator I work with when I am assessing their inventory program for the first time. I ask them when their last full physical inventory count was. Most of the time, the answer is somewhere between eight and fourteen months ago. Then I ask them what they know about what has happened to their inventory since that count.

The honest answer, in most cases, is: nothing. They know their system quantities. They do not know whether those quantities reflect reality. Between the annual count and today, anything could have happened — and without a cycle count program, they have no mechanism to find out.

This guide is about cycle counting — not as a compliance exercise, not as a checklist item, but as the primary operational tool for managing inventory integrity in real time. It covers the complete process from program design through execution, variance investigation, and KPI measurement. If you run a multi-location retail or distribution operation and you are reading this, the cycle count program described here is either the one you have and should be measuring against, or the one you need to build.

Part 1: Why Annual Physical Inventory Counts Are Insufficient

The annual physical inventory count is the standard in most retail and distribution operations. It is also, from an inventory management standpoint, one of the least useful tools available. This is not an opinion — it follows directly from what the count does and does not tell you.

An annual count tells you two things: your system quantity as of a specific date, and your physical quantity as of that same date. The difference is shrink — product that was in the system but not on the shelf. Recording that number and moving on tells you almost nothing actionable. You know shrink happened. You do not know when, where, or how. You do not know whether it was a receiving discrepancy from eleven months ago or an internal theft event that started last week. The trail is cold. The investigation, if one is even attempted, starts with nothing.

More significantly, an annual count provides the conditions for managed shrink — a situation where the parties responsible for inventory accuracy are also responsible for conducting the count that measures it. When receiving staff count the same products they received, and when location managers are compensated partly on shrink performance, the incentive to find the number rather than count accurately is present. Not because people are dishonest. Because the structure creates the opportunity.

DimensionAnnual Physical CountContinuous Cycle Program
Shrink visibilityOnce per year — lagging 12 monthsMonthly per zone — lagging 4–6 weeks
Theft detection speed12 months average detection lag4–6 week average detection lag
Operational disruptionFull store/facility closure requiredMinor — counts before/after hours
Investigation qualityRoot cause nearly impossible to traceRoot cause traceable in most cases
Data reliabilitySingle point-in-time, high error rateMultiple data points, moderate reliability
Staff accountabilityNo ongoing accountability signalMonthly accountability checkpoints
PE reporting valueAnnual — insufficient for hold mgmtMonthly — acceptable for PE reporting
Cost to operateModerate (costly one-time and temp closure)Moderate (recurring labor)
Typical shrink outcomeIndustry avg: 1.4–1.8%Industry avg: 0.8–1.2%
An annual count tells you shrink happened. A cycle count program tells you where, when, and who had access when it did. The difference between those two things is the difference between writing off a problem and solving it.— Mitchell Hamm, Ironside Risk Advisors

Part 2: What Cycle Counting Is — and What It Is Not

A cycle count program divides the total inventory into segments and counts a rotating subset of those segments on a defined schedule — such that the entire inventory is covered within a specific time window, continuously and repeatedly throughout the year.

This is different from a perpetual inventory system, which tracks inventory levels in real time through transaction-based updates. A cycle count verifies that the perpetual system is accurate. It is the audit function that confirms the system’s inventory matches the physical reality on the shelf, in the warehouse, or in transit.

It is also different from a wall-to-wall spot check. A spot check counts everything at once. A cycle count program creates a systematic, scheduled, documented, and recurring verification process that builds an ongoing data record rather than a single point-in-time snapshot.

What Cycle Counting Is Not

  • It is not a substitute for an ERP system. Cycle counts depend on a system of record — without a reliable ERP or inventory management platform generating system quantities, there is nothing to count against.
  • It is not a guarantee that shrink will drop immediately. The cycle count creates visibility. Shrink drops when that visibility is used to investigate and eliminate the root causes.
  • It is not a one-time project. A cycle count program that runs for three months and is then abandoned produces a false sense of security. It must run continuously, be measured continuously, and be enforced continuously to produce meaningful inventory integrity.
  • It is not the same as a full physical annual count. The cycle count program does not replace the annual physical count entirely in most operations — the annual count remains a reconciliation and validation event. The cycle count is what happens in between.

Part 3: Designing the Cycle Count Program

The design decisions made at program inception determine whether the cycle count produces useful data or becomes a compliance theater — counts that are completed on a schedule but do not produce actionable insight. These are the five core design decisions.

Design Decision 1: Segmentation Strategy

Segmentation determines how the inventory is divided into count zones or SKU groups that rotate through the count schedule. There are two primary approaches:

  • Location based segmentation: SKUs are grouped by physical location — aisle sections, bin ranges, rack zones. Each count event covers a defined physical area. This is the most practical approach for most retail environments because it maps to how product is physically organized and makes it easy to assign count responsibility to specific staff.
  • ABC classification segmentation: SKUs are grouped by value and velocity. A-class items (high value, high movement) are counted most frequently. B-class items (moderate value or movement) are counted less frequently. C-class items (low value, low movement) are counted least frequently. This approach optimizes counting effort against financial risk. It is typically used in distribution and warehouse environments where SKU volume makes full-rotation counts impractical on a monthly cycle.

Most multi-location retail operations benefit from a hybrid approach: location-based segmentation as the primary framework, with ABC classification applied as an overlay that increases count frequency for high-value product categories regardless of their position in the rotation schedule.

Design Decision 2: Count Frequency

Frequency determines how often each segment is counted and, therefore, how current the inventory accuracy data is. The minimum effective standard for most retail operations:

  • Full inventory rotation: Every SKU in the inventory should be physically counted at least once every 90 days. A 30-day cycle where 33% of inventory is counted each month is the standard best-practice starting point. In larger format stores, this becomes difficult and in order to be cooperative with operations and labor expenses, a compromise may be needed.
  • High-theft and high-value categories: Count every 30 days regardless of where they fall in the general rotation. If a location carries product above a defined per-unit value threshold — spirits, electronics, jewelry, high-end apparel — those SKUs get a dedicated monthly count, not just the rotation count.
  • Receiving verification: Count inbound product at receipt as a standard procedure. This is not part of the cycle count rotation — it is a separate receiving control. But it feeds the same variance data and should be tracked and reported alongside cycle count results. 
  • Post-incident counts: Any time a theft event, a system anomaly, or a significant discrepancy is identified in a product category, conduct an immediate full count of that category before the next scheduled rotation. Do not wait.  

Design Decision 3: Blind Counting

This is the most important design decision in the program and the one most frequently compromised in practice. A blind count means the person conducting the count does not know the system quantity before they count. They record their physical count. The system quantity is revealed afterward for comparison.

NON-NEGOTIABLEEvery count in a properly designed program is conducted blind. A count where the counter knows the expected quantity before counting is not a count — it is a confirmation. It will not catch process errors, it will not catch theft, and it will not produce reliable variance data. There are no exceptions to this rule.

The practical implementation of blind counting depends on the technology in use. In operations with mobile count devices, the ERP or inventory management system can suppress the on-hand quantity display during the count session and reveal it only after the count is submitted. In operations still using paper-based count sheets, the system quantity column is left blank until after the counter records their physical count and the sheet is returned for entry.

Design Decision 4: Who Conducts the Count

Segregation of duties is the principle that the person who performed a transaction should not be the person who verifies that transaction. Applied to cycle counting, the person who received a shipment should not be the primary counter for that product. The person responsible for a location’s shrink performance should not be the only counter for that location’s inventory.

In practice, perfect segregation of duties is difficult in small-location operations with limited staff. Pragmatic approaches that maintain the integrity of the principle include: rotating count assignments across staff members, having a designated count supervisor conduct spot recounts on a percentage of counted locations, using cross-location counting where staff from one location count at another, and scheduling management-supervised counts for high-value and high-variance categories.

Design Decision 5: Count Timing

Counts must be conducted when the inventory is static — when no receiving, picking, transferring, or selling activity is occurring that would move product between the time the counter starts and finishes. In retail, this means before store opening or after closing. In distribution, it means during a defined shift gap or during the slowest operational window.

Never conduct cycle counts during operational hours if any product movement is possible in the areas being counted. A count conducted while receiving is active in the warehouse produces variance data that is indistinguishable from actual loss — which makes it worthless.

Part 4: The Cycle Count Process — Step by Step

A cycle count event is not simply ‘go count the product.’ It is a structured process with defined steps, roles, and documentation requirements at each stage. Here is the complete process sequence.

01Generate the Count Work Order
The ERP or inventory management system generates a count work order for the scheduled segment. The work order lists every SKU and location to be counted, with system quantities suppressed. The count supervisor assigns the work order to specific counters and documents the assignment. Count date, time window, and assigned personnel are recorded before counting begins.
02Pre-Count Verification
Before counting begins, the count supervisor walks the count zone and confirms that no product movement activity is occurring or scheduled during the count window. Inbound receiving is halted in the count zone. Replenishment picks from the count zone are completed before the count begins or suspended until after. Any in-progress transfers are resolved and the product is located before counting starts.
03Physical Count Execution
Counters work through the assigned locations systematically, counting every unit of every SKU listed on the work order. Count is conducted blind — system quantities are not visible. Each counter records their count on the work order or mobile device. Product is counted where it is located, including display fixtures, backstock, and receiving staging areas. If a SKU is found in a location not listed on the work order, it is noted as an exception for the count supervisor.
04Recount Protocol
When a counter finishes their assigned zone, a second counter or the count supervisor recounts a random sample of 10–15% of the counted locations — without seeing the first counter’s results. This catch-and-release recount validates counting accuracy, identifies training gaps, and creates a second data point for variances. Any location where the recount differs from the original count by more than the variance threshold triggers a full third count before the work order is closed.
05System Entry and Variance Generation
After physical counts are complete, counts are entered into the ERP and the system reveals the on-hand quantity for comparison. The system automatically generates a variance report showing every SKU where the physical count differs from the system quantity, the dollar value of the variance, and the percentage variance relative to on-hand quantity. The count supervisor reviews the variance report before approving the work order close.
06Variance Triage and Threshold Application
The count supervisor applies the variance threshold: any SKU-level variance below the defined minimum (e.g., one unit or $[X] in retail value) is logged but not investigated individually — it is tracked in aggregate for pattern analysis. Any variance above the threshold is flagged as requiring root cause investigation and assigned to the responsible investigator. Variances in high-value product categories are always flagged regardless of dollar amount.
07Root Cause Investigation
Each flagged variance is investigated within 48 hours of the count. The investigator reviews the transaction history for the SKU in the ERP, pulls CCTV footage if applicable, reviews receiving records and PO documentation, checks access logs for the count zone, and interviews relevant staff. The investigation is documented with the finding, the evidence reviewed, the conclusion reached, and the root cause category assigned. Investigation must be closed within 72 hours.
08Inventory Adjustment and Recovery
Variances confirmed as process errors or system errors are corrected with an inventory adjustment transaction. Variances confirmed as receiving discrepancies are documented and submitted to the vendor or carrier for resolution. Variances confirmed as theft are escalated to LP for case opening and law enforcement contact as appropriate. All adjustment transactions are logged with the root cause code and investigation reference number.
09Count Completion and Reporting
The work order is closed in the ERP with all variances resolved or documented. The count supervisor generates the count summary report: total SKUs counted, total variances identified, total dollar variance, variances above threshold, root cause distribution, and adjustment summary. This report is transmitted to the LP Director and, on a monthly rollup basis, to PE ownership through the standard inventory KPI dashboard.
10Pattern Analysis and Program Adjustment
After each count cycle (monthly), the LP Director reviews the cumulative variance data across all locations. Pattern analysis identifies whether variances are concentrated in specific locations, specific product categories, specific time periods, or specific staff assignments. Patterns that suggest systematic theft, vendor fraud, or process failure trigger a deeper investigation. Count schedules and thresholds are adjusted based on where variance risk is demonstrating itself in the data.

Part 5: Root Cause Investigation — The Most Important Step

If there is one section of this guide that determines whether a cycle count program produces value or merely produces numbers, this is it. The root cause investigation is where the cycle count data becomes actionable. Without it, you have a system that finds variances and records them. With it, you have a system that finds variances, explains them, and eliminates the conditions that created them.

Every variance above the defined threshold requires a documented root cause investigation completed within 48 hours. This is not a suggestion. It is the non-negotiable requirement that separates a functional cycle count program from compliance theater.

The 48-hour window exists because the evidence needed to investigate a variance is perishable. CCTV footage is overwritten. Transaction logs become harder to isolate. Staff recall degrades. Vendor delivery documentation gets filed. Waiting a week to investigate a variance identified in Monday’s count means investigating with a fraction of the available evidence. Waiting a month means investigating with almost none.

The Root Cause Taxonomy

Every closed investigation must be assigned one of the following root cause categories. The distribution of root causes across a quarter of cycle count data is one of the most diagnostic analytics available to an LP program — it tells you whether your shrink problem is structural, behavioral, or operational.

Root Cause CategoryDescription & Investigation Action
Receiving DiscrepancyProduct received in different quantity than PO or invoice. Vendor short-shipment, carrier damage, or receiving error. Investigate by pulling vendor invoice, delivery receipt, and receiver’s count record.
Internal Theft / DiversionProduct removed by an employee — cashier refund fraud, back-door diversion, receiving manipulation, or direct theft. Investigate with CCTV, exception reporting review, and access log analysis.
External Theft / ORCShoplifting, organized retail crime, or cargo theft. Investigate with CCTV, incident log review, and law enforcement coordination.
Process / Scan ErrorProduct scanned incorrectly at front-end, duplicate entry, or UOM mismatch in ERP. Investigate by reviewing transaction history in system and re-counting physical product.
Damage / Spoilage / Write-OffProduct damaged, expired, or otherwise rendered unsellable without a corresponding write-off transaction. Investigate with receiving records and damage log.
Vendor FraudVendor knowingly ships short quantities, substitutes product, or invoices for product not delivered. Investigate by comparing PO, invoice, and receiving record across multiple shipments from same vendor.
System / Data Migration ErrorInventory record created or modified incorrectly by ERP transition, integration, or system error. Investigate by comparing system transaction log to physical count and prior cycle data.
Unknown / UnresolvedVariance cannot be explained by any available evidence. Document thoroughly, keep open for 30 days, escalate to LP for investigation before administratively closing.

What Root Cause Distribution Tells You

After 90 days of documented root cause investigation, the distribution of root cause categories across all closed variances becomes the most actionable diagnostic in the LP program. Here is how to read it:

  • Receiving Discrepancy dominates (>40% of variances): Your receiving controls are the primary problem. Blind receiving is likely not being practiced consistently. Vendor-specific patterns suggest fraud. The fix is receiving procedure redesign and vendor audit. 
  • Internal Theft / Diversion dominates (>30%): You have an active internal theft problem. CCTV gaps, access control weaknesses, or a specific staff member or location are likely implicated. This is an LP investigation priority, not a process problem.  
  • Process / Scan Error dominates (>35%): Your ERP usage is inconsistent. Staff are scanning product incorrectly, entering wrong quantities, or failing to complete transactions. The fix is ERP training and workflow redesign, not an LP investigation.
  • Unknown / Unresolved dominates (>25%): Your investigation process is failing. Variances are being closed without documented root cause because the 48-hour investigation window is not being enforced or the investigator does not have the skills or access to complete the investigation. This requires immediate attention — unknown variances that accumulate represent both undetected loss and undetected process failures.
  • Even distribution across categories: Multiple contributing factors are present. No single intervention will address the full shrink problem. A systematic review of receiving, access control, CCTV, and ERP procedures is warranted.
The root cause distribution is the most diagnostic data in your LP program. If 40% of your variances have no documented root cause, you do not have a cycle count program — you have a variance recording system. Those are not the same thing.

Part 6: KPIs — How to Know If the Program Is Working

A cycle count program without defined KPIs and regular measurement is not a program — it is an activity. The following eight KPIs define a well-managed cycle count program and give LP leadership, location managers, and PE ownership the metrics needed to assess inventory integrity across the portfolio.

KPIDefinitionTargetWhat It Tells You If Off-Target
Count Completion Rate% of scheduled counts completed on time≥ 95%< 85% = program not running; investigate accountability gap
Blind Count Compliance% of counts conducted without system qty visible100%Any % below 100% invalidates the count’s integrity
Variance Rate (by location)% of counted SKUs with any variance< 3%> 5% indicates process or theft issue; > 10% = critical
Dollar Variance as % of InventoryTotal $ variance / total $ inventory counted< 0.3%> 0.5% requires root cause review; > 1% = LP escalation
Root Cause Resolution Rate% of variances with documented root cause within 48 hrs≥ 90%< 75% = investigation discipline failing
Recount Accuracy Rate% of recounts that confirm original count variance≥ 80%< 60% = counting methodology or counter training issue
High-Value SKU Variance RateVariance rate on HVP-designated product only< 1%Any variance on HVP triggers immediate investigation
Vendor Discrepancy Recovery Rate$ recovered from vendor via discrepancy claims / $ discrepancy≥ 70%< 50% = claim process not being followed

Reporting Cadence

  • Weekly: Count completion rate and variance rate by location reported to LP Director and location managers. Any location below 85% completion or above 5% variance rate receives immediate attention.
  • Monthly: Full cycle count KPI dashboard distributed to LP Director, Operations leadership, and PE Operating Partner. Includes root cause distribution, trend comparison to prior month and prior quarter, and top-variance locations identified by name.
  • Quarterly: Deep-dive pattern analysis by LP Director. Variance trend against shrink benchmark. Cycle count effectiveness assessment — is the program finding losses or missing them? Recommendation for program adjustments.
  • At Physical Inventory: Cycle count accuracy validation — compare the full physical count results against the most recent cycle count data for each zone. A well-run cycle count program should produce full physical count results within 0.1–0.2% of the cycle count running total.

Part 7: The Seven Most Common Cycle Count Mistakes

In every LP program assessment I conduct, at least three of these seven errors are present. Some operations have all seven. Each one independently reduces the effectiveness of the cycle count program. In combination, they produce a cycle count that generates data without producing insight.

Mistake 1: Non-Blind Counting

The most common and most damaging error. Counters see the expected quantity before counting. This does not catch discrepancies — it confirms the system number, whether or not it is accurate. Fix: configure the ERP to suppress on-hand quantities during count sessions. If technology does not support this, use paper count sheets with the quantity column left blank until after submission.

Mistake 2: Counting During Operating Hours

Product moving through sales, receiving, and replenishment simultaneously with the count produces variance data that cannot be attributed to actual loss versus in-process movement. Fix: schedule all counts outside operating hours. In 24-hour operations, define a dedicated count window where movement in the count zone is suspended.

Mistake 3: No Recount Protocol

A single count with no verification produces data of unknown reliability. One counter, one pass, no challenge — any error in counting methodology produces variance data that looks identical to actual loss. Fix: implement a mandatory recount of 10–15% of counted locations by a different counter before the work order closes.

Mistake 4: Variance Investigation Without a Timeline

Variances flagged for investigation that sit open for weeks or months without resolution are effectively not being investigated. The evidence degrades. The pattern becomes untraceable. Fix: 48-hour investigation window, non-negotiable. Any variance not closed within 72 hours escalates to LP Director.

Mistake 5: Closing Variances as ‘Unknown’ Without Escalation

‘Unknown’ is a valid root cause category for variances where all available evidence has been exhausted without a conclusion. It is not a valid catch-all for variances where no investigation was actually conducted. An operation where 40% of variances are closed as ‘unknown’ is an operation where the investigation process is failing. Fix: require LP Director approval for any ‘unknown’ classification. Unknown variances trigger a secondary review.

Mistake 6: Same Staff Counting Their Own Product

When the receiving team counts the products they received, and the location manager reviews the results of a count zone they manage, the segregation of duties principle is compromised. The incentive to find the expected number is present, even if no deliberate manipulation occurs. Fix: rotate count assignments. Use cross-training, cross-location counting, or LP-supervised spot recounts on high-value zones.

Mistake 7: Running the Count Without Pattern Analysis

Count completion at 95% with zero pattern analysis means the count is running but not producing insight. Individual variance investigations find individual root causes. Pattern analysis finds structural problems — the vendor that is consistently short-shipping, the location that consistently has variance in a specific category on a specific day of the week, the staff member whose assigned zones consistently produce higher variance than others. Fix: mandatory quarterly pattern analysis by LP Director. The pattern data is the most valuable output of the cycle count program.

Part 8: Cycle Counting in a PE Portfolio Context

For private equity Operating Partners managing retail or distribution portfolio companies, the cycle count program serves a function beyond inventory management. It is the primary mechanism for validating that the shrink rate reported in the company’s financials reflects actual inventory integrity — not a convenient annual count that has not been challenged since the acquisition.

PE DILIGENCE NOTEWhen Ironside conducts a pre-acquisition operational risk assessment, the first inventory control question is always the same: is the business running a cycle count program? If the answer is no — or if the answer is ‘yes, but it is annual’ — the reported shrink rate is unverified data, not a measurement. The EBITDA exposure calculation begins from that finding.

The Post-Acquisition Cycle Count Buildout

Building a cycle count program from scratch at a newly acquired portfolio company is a 60-day project, not a 12-month one. The implementation sequence:

  1. Weeks 1–2: ERP assessment. Confirm the inventory management system is capable of generating blind count work orders, capturing count results, and generating variance reports. Identify any configuration gaps.
  2. Weeks 2–3: Segmentation design. Divide the inventory into count zones and assign SKU groups to count rotations. Define the count schedule and assign frequency by category based on ABC classification.
  3. Weeks 3–4: Threshold and escalation definition. Set the variance investigation threshold, define root cause categories, build the investigation workflow, and establish the escalation path to LP.
  4. Weeks 4–5: Counter training. Train all staff who will conduct counts on blind counting procedures, count work order operation, documentation requirements, and exception reporting.
  5. Weeks 5–6: First count cycle execution, supervised. LP Director or fractional advisor is present for the first full count cycle. Observe and correct any methodology errors in real time. Generate the first variance report.
  6. Week 6–8: First root cause investigation cycle. Work through every above-threshold variance with the responsible staff. Document root causes. Generate the first monthly summary report.
  7. Month 3: First pattern analysis. Review the cumulative 90-day data. Report findings to PE ownership group. Adjust count schedule and thresholds based on initial data.

By Month 3, the portfolio company has a functioning cycle count program, a populated root cause database, and the first trend data against which future performance can be measured. By Month 6, the data is reliable enough to produce a credible shrink rate that PE ownership can report with confidence.

How the Data Serves the Exit Narrative

A cycle count program that has run for 18–24 months produces something extremely valuable for a PE exit: a documented, verifiable inventory accuracy record. When a buyer’s diligence team asks about shrink methodology — and an informed buyer always does — the answer is no longer ‘we conduct an annual physical count.’ The answer is a monthly cycle count program with documented root cause investigation, trending data, and a shrink rate that has been validated by continuous measurement rather than a single point-in-time snap.

That distinction is worth something at exit. A buyer cannot argue that an unverified annual count is an accurate representation of inventory integrity. A buyer cannot make the same argument against 24 months of documented cycle count data with consistent root cause investigation and a trend line that shows shrink moving in the right direction.

The cycle count program is not just an operational tool. For a PE-backed retail or distribution business, it is a documentation asset that supports exit valuation.

A buyer can challenge an annual shrink rate. They cannot challenge 24 months of documented cycle count data, root cause investigation, and a shrink trend that moves in the right direction. Build the program early. The exit narrative depends on the data you start collecting today.
— Mitchell Hamm, Ironside Risk Advisors

The Bottom Line

A cycle count program is not complicated. It is systematic, consistent, and disciplined — which is harder than complicated, because discipline does not have a shortcut. Every shortcut in the program design — non-blind counting, no recount protocol, no variance investigation timeline, no pattern analysis — produces a version of the program that feels operational but does not work.

The businesses that hold their shrink at 0.4% in an industry where the average is 1.5% are not doing something exotic. They are running a cycle count program with absolute fidelity to the fundamentals: blind counts, segregated responsibility, 48-hour investigation windows, documented root causes, and monthly pattern analysis. They have been doing it for years, not months.

Start with the fundamentals. Run them with discipline. Measure them weekly. And when the variance data starts telling you a story, listen to what it is saying — because it is telling you exactly where your inventory is going and exactly what needs to change to stop it.

About Ironside Risk Advisors
Ironside Risk Advisors provides fractional loss prevention and cargo security advisory to private equity firms with retail and supply chain portfolio companies. Founded by Mitchell Hamm — 10+ years across a PE-backed multi-site retail operator and corporate security — the firm specializes in pre-acquisition risk assessment, post-close Loss Prevention buildout, fractional Loss Prevention director engagements, and supply chain cargo security audits.
mitch@ironsideriskadvisors.com  ·  (502) 608-7389  ·  ironsideriskadvisors.com  ·  Dallas, TX