In the United States alone, there are over 10,000 regulations which apply to industry-specific private and public companies. The regulations are mandatory and include heavy penalties for violations. Therefore, IT organizations must now operate under these regulations for corporate data retention, historical tracking and recovery.
Compliance management of corporate records has imposed a serious responsibility on the global IT community. Information is an asset which must be protected, monitored, maintained, exchanged and secured. To ensure these objectives are met, corporate information has become the focal point of a multitude of regulations and laws on the state, federal and international level. These regulations address the processes by which records must be created, stored, accessed, maintained, and retained over increasingly long periods of time.
What happens if your company loses data and you can’t recover it? We’ve been called countless times by companies AFTER a data loss disaster occurs, hoping to recover their data without having a backup and recovery solution in place. As companies cope with the growing amount of corporate information being generated every day, they face a daunting truth: without their data, they have no business. That’s why it’s so critical to have a modern and dependable solution in place to safeguard valuable business information. Companies everywhere are evaluating how to address regulatory compliance for their cloud-based customer data knowing that it needs to be backed up seamlessly, restored quickly, and protected securely. Don’t wait until it’s too late, Sesame Software’s Relational Junction can provide you with a data protection plan now!
Data backup is one of the most important areas of IT and yet is also one of the most ignored. There are measures you can take to prevent the unthinkable from happening – the unthinkable being your lost, damaged or deleted data. Here are a few instances in which cloud data can become lost data:
- User Error such as accidental overwriting and deletions
- Malicious end-user activity
- Employees covering up mistakes
- Administrative errors (mass destruction)
- Misuse of vendor tools (mass destruction)
- Update errors by automated processes
- Natural disaster
- Viruses or ransomware
In all the cases below, the customer was able to recover their data without the user community or customers even knowing there was a problem. Customers saved. Jobs saved.
- A CRM administrator at a large private wealth management bank created a master-detail relationship, then created and deleted master records, destroying 6,000 customer account records with a single mouse click. This data was used for customer service. Imagine customers calling in and being told “Sorry, we have no record of you being a customer.”
- One customer used a spreadsheet interface tool to export 80,000 contacts from their CRM into a spreadsheet, then sorted the phone numbers (instead of sorting the entire record in phone number order), and saved them back to the CRM. Every contact then had someone else’s phone number.
- One customer deduplicated contact records with another tool, but set the criteria to allow only one contact per customer account. This resulted in mass destruction of most of their contact records.
Cloud data sources such as Salesforce.com or NetSuite are maintained by the providers. While the back-end database is backed up and managed for disaster recovery, data loss due to corruption or deletion of individual records is not supported by any of these vendors. There are many solutions to back up Cloud data, but few solutions to actually recover it. With Relational Junction you can:
- Restore deleted data
- Restore corrupted data to a point-in-time
- Recover relationships between records
- Full or Partial – selective restore of some records or some objects
Flat file backups cannot be done incrementally. It is very expensive, time consuming, and error prone to take a full backup every time. Also, if the schema changes, you can’t recover multiple versions of each schema into one Cloud database. Recovery has to take into account not only parent-child relationships, but recursive relationships between records of the same type. The only way to efficiently recover user data is to back it up to an offline database, be able to recover selected or all records, and keep the original relationships in the data intact.
- All Cloud data
- Retain for 7 years
- Keep deleted records in backup set
- Permanent Audit trail of all changes to all fields in all records
- HHS Health Insurance
- EU, UK Data Commissioner
- Public US Companies: Sarbanes-Oxley
- Medical: HIPPA and 21 CFR Part 11
- Securities: SEC Rule 17A
- Europe: Data Protection Act
Among the SaaS offerings for CRM, Salesforce.com leads the market, followed by Microsoft. Regulatory compliance for companies using SaaS CRM solutions can be challenging. A simple and obvious solution is to set up a strictly maintained, local copy of the CRM data. However, management of the local or in-house CRM data repository must ensure complete audit and recoverability of change history and deleted records. Additional critical data repository functionality must be considered to meet compliance such as:
- Frequency of data replication from the cloud to the local repository
- Replication efficiency and completeness
- Data mapping requirements
- Setup and maintenance time and complexity
- Data recovery
- Data security
- Additional off-site backup options
To ensure complete backup and recovery functionality, bidirectional replication is required to allow recovery of deleted or lost cloud-based CRM data. The local database solution must never physically delete records from the local repository. Deleted records must be marked as inactive in the data warehouse, but never physically removed. Maintaining inactive records allows restoration of any of deleted or lost data in the cloud, including the entire hierarchy of an account with its contacts, opportunities, and related data – simply and with all relationships intact.
Many companies have audit requirements that demand periodic snapshots of their data, or versioning of specific changes of data. Strict federal regulations require that every version of selected record types be maintained. To effectively address this requirement, changes can be logged in the local data repository to maintain all versions of selected record types. This is efficiently accomplished using history tables that contain a complete snapshot of every record before it is modified.