Between February 2005 and February 2006, in 130 separate incidents, more than 53 million private data records were lost, stolen, hacked, given away to criminals, or accidentally displayed to the public. And that’s just the ones we know about.
What was displayed? Names, addresses, birthdates, maiden names, social security numbers, bank account and loan information, credit card numbers, employment history, school records, and private business transactions.
The root cause in every single case was the same: Someone made a risky decision that never should have been made by a single individual; the organization didn’t detect and correct this situation, and the result left a security hole that turned into a data breach.
To put this in the language of risk management, the organization was at risk of a data breach, and so, per standard practice:
- The risk should have been assessed.
- A risk management strategy should have been established by those in the organization who were formally empowered to do so.
- The strategy should have been translated into an execution plan, with ongoing, supervised control activities.
- All individuals working with data should have been informed of their levels of empowerment for assuming risk, and no individual should have been allowed to assume a risk beyond his level of empowerment.
We also can express the situation using the language of compliance:
- Formal policies, standards, and requirements should have been in place to translate federal and state regulatory requirements into enterprise activities to classify, store, move, display, and protect private data. • Compliance risk should have been assessed.
- A strategy should have been established to address compliance risk.
- The strategy should have been translated into a set of procedural and automated controls to prevent noncompliant activities and to detect and correct any that slipped past preventive controls.
- The controls design should have been such that no individual—even senior management—could have circumvented these controls.
To express the situation in the language of auditors:
- In each case, the company with the data breach experienced a failure in either the design of their controls or in the execution of their controls.
- In each case, the failure required mandatory disclosure to the public of the data breach.
- In most, if not all, cases, the organization’s management and external auditors will be forced to conclude that their controls systems weren’t functioning properly. This could have severe impact on the company beyond the cost and embarrassment of the incident itself—especially if the conclusion is that the company must report a Material Weakness in accordance with the Sarbanes-Oxley Act of 2002.
To express the situation in the language of data governance:
- A situation existed that represented a severe risk for the organization, in the form of a potential data breach.
- The data management team wasn’t empowered to assume the risk for the organization.
- Protecting the company from a data breach required the design and enforcement of policies, practices and controls, which in turn required boundary-spanning input from legal, compliance, auditing, security, and business resources as well as the data management team. In short, it required data governance.
- Instead of invoking or complying with data governance, a single individual employed the standard management practice of making a decision on his own. This proved disastrous for the company.
Those of us who work with mainframe data are sometimes the last line of defense for that data. We move it and store it and grant access to it. If controls to protect it fail at the business process level or application level, it’s our database controls that prevent breaches, our procedural controls that restrict access, and our auditing tools that help detect and correct issues. More than anyone, we know when management should be replaced by governance.
What should you do if you suspect a problem? Report it! Need help expressing your concern? Look at the sets of bullet points above. In each case, if you add an introductory point (“We have a problem with a process/control/decision to be made”), you’ll be on your way to the sort of communication that could keep your organization from joining the Data Breaches Hall of Shame.
For more information about the data breaches, visit www.datagovernance.com/breaches_center.html.