Backups are a necessity. They’re important in any computing environment, and you would be hard pressed to find anybody who would disagree with the criticality of having backup copies of their data. In the event that primary systems or data sets are unavailable, backups are designed to provide the assurance that significant amounts of work, time or money aren’t lost.
To protect the partners, customers and constituents of organizations from risks associated with potential data loss, the U.S. federal government has established various compliance requirements that must be met and maintained. In addition to general business-compliance requirements, many industries have additional regulations that must be met. Examples include Sarbanes-Oxley Act of 2002 (SOX), Payment Card Industry Data Security Standard (PCI DSS), the U.S. Health Insurance Portability and Accountability Act of 1996 (HIPAA), Gramm-Leach-Bliley Act (GLBA), and the Federal Information Security Management Act (FISMA); it’s easy to see why compliance is often referred to as regulatory alphabet soup (which is not far off from the storage industry, I would add).
Depending on the industry, the mandated data-retention timeframe can vary from a few as seven years to as many as 100 years. At the upper end of that spectrum, a significant amount of infrastructure investment and planning is necessary. Unfortunately, systems complexity becomes a byproduct of trying to solve these challenges and that complexity evolves over time until it becomes unmanageable.
Just as the specific requirements for these regulations vary, so do the consequences of being non-compliant, which is often discovered during periodic industry audits or following a breach. Failure to meet compliance requirements could result in warnings or fines, and in extreme cases, termination of operations and prison time. The trouble is: Compliance testing can be difficult to do, and it can come down to having a confidence in whether or not systems will be able to perform adequately under trial.