Root Cause: Three Control Principles Violated
This incident was caused by governance gaps in how ToysMakers SARL designed and oversaw its vendor payment process.
1. Segregation of Duties Was Not Enforced
Within the outsourced platform, the same account had the authority to modify vendor master data and approve those changes. There was no structural separation between data entry, data approval, and financial execution.
Once that account was compromised, the attacker was able to alter vendor bank details and allow those changes to flow through the normal approval and payment process without challenge. No single user — whether internal or external — should be able to change sensitive financial data and approve it independently.
2. Vendor Master and Payment Governance Was Weak
Changes to vendor bank account numbers and communication details were treated as routine operational updates rather than high-risk financial events. There were no red flags, no escalation triggers, and no independent validation requirements attached to such changes.
Vendor master data directly determines where money is sent. Any modification to payment details should require additional scrutiny, formal approval, and independent confirmation with the vendor through a trusted channel.
3. Third-Party Tool Oversight Was Inadequate
ToysMakers outsourced invoice processing but did not sufficiently assess the risks associated with relying on an external platform for critical financial controls. There was no evidence that ToysMakers required: Segregation of Duties within the third-party tool, strong authentication controls for sensitive roles, automated alerts for vendor detail changes, or independent audit rights over vendor master modifications.
A bank confirms that funds were transferred. It does not confirm that funds were transferred to the correct party.
GRC Actions to Prevent Recurrence
The payment lifecycle must be divided into independent control stages — no single role should have authority across more than one critical stage:
- Vendor master data creation or modification
- Vendor master data approval
- Invoice approval
- Payment release
Actions required:
- System-enforced dual control for vendor bank changes
- Prevent users who modify vendor data from approving those changes
- Maker-checker controls for all payment-related updates
- Multi-factor authentication for high-impact financial roles
- Automatic alerts to ToysMakers finance when vendor bank details change
- Mandatory out-of-band confirmation with the vendor using pre-verified contact details
- A cooling-off period before the first payment to a modified account
- Logging and periodic review of all vendor master changes
- Formal third-party control assessments
- Documented SoD matrices required from service providers
- MFA mandated for privileged roles at the vendor
- Contractual obligations for breach notification and change transparency
- Audit rights over financial data modification logs
- Exception reporting for payments to newly added or modified accounts
- Quarterly review of vendor master changes
- Automated pattern analysis on vendor payment destinations
- Independent reconciliation of vendor confirmations against payment records
- Assign clear ownership for vendor payment governance
- Define RACI across Finance, Procurement, IT, and Risk
- Document the payment control framework within internal policy
- Include vendor master governance in the internal audit scope
