Data protection and security protocols have become more robust in the last decade. This has been driven both by increasing incidents of data breaches – statutorily by acts of Congress such as the Gramm-Leach-Bliley Act, HIPAA, and the Fair and Accurate Credit Transactions Act – and by the Payment Card Industry Security Standard, to name just a few drivers. In general, most entities have implemented strong safeguards to ensure that issues such as inadvertently sharing identifying information with third parties and the existence of sensitive data (credit/procurement card numbers, tax IDs, social security numbers, vendor/customer bank account numbers, etc.) for their current and active data are addressed.
The problem arises when a company has legacy or inactive ERP data. Prior to the enhanced security protocols of the last decade-and-a-half, it was common practice to put sensitive data into an ERP system’s unsecured fields, such as memo and descriptive fields, or in otherwise re-purposed fields. As a result, much legacy data does not meet privacy and security standards. This risk can be managed without having the expense of a hygienic data purge when the legacy data is buttressed by access controls. The biggest risk is when a third party is given access to or possession of either a portion or clone of an existing ERP instance. This most commonly occurs in divestiture or partial divestiture situations.
This risk cannot be understated. A single inadvertent unauthorized disclosure of private customer or vendor information could result in large penalties, sometimes into the hundreds of thousands of dollars. If the clone instance is provided to a competitor in a partial divestiture, added to this risk is the possibility of damage resulting from inadvertent disclosure of the non-divested business’ proprietary strategic information, such as vendor and customer credit lines, customer and vendor contractual details, etc. Finally, to magnify these risks, the threat of litigation losses respective of inappropriate data disclosure can dwarf the costs of other risks.
So what is an appropriate risk management strategy to adopt during a divestiture? An entity has three choices: minimize the risk, accept the risk, or ignore the risk.
Minimizing the Risk:
This strategy involves a variety of steps, including non-disclosure agreements with third-parties, contractual obligation, and other due diligence around the risks. However, the ideal way to minimize the risk is to purge old/legacy non-divestiture related data from the clone instance provided to the divested or acquired entity.
Accepting the Risk:
Accepting the risk can be an effective risk mitigation strategy. However, to accept the risk, entity management must have a relatively accurate estimate of the risky data exposure accompanied by a what-could-go-wrong quantification of the potential risk respective losses.
Barring a means to quantify the risks associated with the divested clone instance’s legacy and non-divested entity related data, entity management is not accepting the risk. Instead, by default, entity management has chosen the riskiest approach – Ignoring the Risk.
Ignoring the Risk:
If an entity’s management cannot be provided with a reasonable estimate of quantified risks associated with the divested clone instance’s legacy and non-divested entity related data, then barring minimizing the risk by purging unrelated and legacy ERP information, management has chosen to ignore the risks. This is the worst possible strategy, because it leaves the entity open to the risk of being deemed negligent, which can significantly exacerbate litigation, business and other risks.
In conclusion, during the rapid transition of a divestiture, it is critical to ensure that due attention is given to the risk of legacy, inactive, and unrelated to the divestiture ERP data. The best strategies are to either minimize or accept the risk and avoid the unacceptable act of ignoring the risk.