An Acknowledgement Is Not a Control
A global logistics company onboards 1,100 vendors a year through a shared service center. Policy requires risk-based due diligence before any vendor receives system access or handles customer data. In practice, business sponsors email the procurement director for 'urgent business need' exceptions. Last year 38% of new vendors were onboarded before due diligence was complete; 14 of those received access to shipment or customer data. The only automated control is a policy acknowledgement at onboarding, and 92% of vendors have acknowledged it. Internal audit recently tested the control and rated it 'operating effectively' because the acknowledgement rate exceeded the 90% target. A mid-sized vendor that skipped due diligence suffered a credential-stuffing breach and exposed 3,000 customer records. You lead compliance operations.
1. Distinguish control design from operating effectiveness in this case. Was internal audit's conclusion defensible?
Read the worked answer
Control design asks whether the control, as designed, would achieve the control objective. The objective is to prevent vendors from receiving access or customer data before risk-based due diligence is complete. A policy acknowledgement does not achieve that objective; it confirms that someone read a policy. The actual gate is missing, and the exception route is informal and unlimited. That is a design deficiency.
Operating effectiveness asks whether the control operated as designed and whether the design was adequate. Internal audit tested the acknowledgement rate, found 92%, and concluded the control was effective. That conclusion is not defensible because the test measured the wrong thing. A 92% acknowledgement rate is consistent with 38% of vendors bypassing due diligence. The control can operate exactly as designed and still fail the objective.
The 14 vendors with access and incomplete due diligence are the evidence that matters. Audit should have tested whether access was granted only after due diligence, whether exceptions were approved at the right level, and whether exception volume and aging were monitored. Rating the acknowledgement control effective gave management false assurance.
2. Recommend a remediation plan for the Perform component, prioritizing changes. Explain how you would treat the exception backlog and the vendors already onboarded.
Read the worked answer
The first priority is containment, because the breach has already occurred and 14 vendors currently have access without completed due diligence. I would inventory all exceptions from the past 12 months, risk-tier them by data access and shipment exposure, and suspend or restrict access for the highest-risk vendors until due diligence is complete. This is not a punitive step; it is a stop-the-bleeding step while the process is redesigned.
Second, redesign the gate so that system access cannot be provisioned until the vendor's risk tier is assigned and the required due diligence is complete. The exception route should be formal, time-bound, approved by a named authority above the procurement director, and reported monthly. The acknowledgement can remain as an administrative step but should not be treated as the control.
Third, clear the backlog with a risk-based sequence: high-risk vendors first, then medium, then low. For vendors already onboarded without due diligence, I would document compensating checks and decide whether to retain, restrict, or terminate. Metrics should shift to the percentage of vendors with completed due diligence before access, exception aging, and the number of high-risk vendors with open exceptions. Acknowledgement rate should be retired as a primary compliance metric.