Paul Gogan — Manager, Cloud Platform Protection and Storage, EMC IT
Creating a data protection strategy for your organization is a little bit like selecting the right insurance policy for your home. It isn’t the most flashy of endeavors and nobody likes paying those insurance premiums, but when a hurricane rips the roof off your house, you’re glad that you took the time to do it right.
Structuring your data protection strategy is not exclusively an IT decision. It’s primarily a business decision involving a range of stakeholders (not just IT) which provides the products, solutions and processes to execute that strategy based on the value of the data and the objectives of the business.
Data protection is not a one-size-fits-all process, as we in EMC IT, have come to learn. The following are best practices and lessons learned that EMC IT uses to create and maintain our data protection strategy.
Start with critical stakeholders
Whether you’re putting together a new data protection strategy or updating an existing one, all the stakeholders with an interest in the data need to have a seat at the table. Most importantly, that includes the business group that owns the data and IT, but also should include representative(s) from legal, the compliance department, engineering and executives who support the effort. These stakeholders will make decisions not just about the high-level, near-term protection and retention of the data, but also about requirements that will impact the business long term.
Odds are you won’t be starting your data protection strategy from scratch. Most organizations have many legacy data practices that have evolved into protection requirements. Oftentimes organizations don’t consider what their needs will be 25 years out while they set up these protection solutions. Data Protection strategy should include an initial cadence of review and audit and allow for adjustments as the needs of the business change and grow.
Each of the stakeholders will have a unique set of needs to be considered in the formulation of the business requirements. These needs will identify the data types and sources to be protected, the level of protection each will require and, finally, the duration of the protection and retention. They may require changes in behavior in your organization as well as vetting your current protection solutions.
Your legal department will be able to weigh in about what data requires protection and retention to enable the business to meet litigation requirements. Compliance stakeholders can spell out data access needs by federal regulators or accounting standards, as well as corporate compliance expectations. Large data custodians such as Finance and Engineering departments will have critical input on the protection and retention expectations for their specific datasets.
All of these factors need to be assessed against the cost of data protection. The bottom line in this process is simple: unless you are mandated by some regulation, the lifecycle of a data set should never exceed its value to your organization.
Establish data protection requirements
Once you understand your data protection needs or high level data protection deliverables, you can map these to data protection requirements spelling out how data and related applications are going to be protected, for how long and why.
Requirements should define, for example, the custodian or owner of the data; the data types included /excluded, the period of active backup accessibility, the backup frequency and types, and the longer term retention requirement. Finally, the requirements should define the end of data lifecycle to ensure data of no business value is destroyed for efficiency, cost control and risk management.
Data protection requirements can have multiple deliverables that change throughout a data set’s lifecycle. For example, documentation created by a company tech writer to document a corporate hardware or software product is categorized as higher value and needs to be backed up daily and be accessible for 90 days. After that timeframe, it becomes an archived engineering document, and a single quarterly version should be archived and be retained for 10 years. This addresses protection while the documentation is an active valuable asset. When the product this documentation supports reaches ‘end of life,’ the protection requirement will change and should be reviewed.
Such lifecycle provisions are important. Everyone holds on to data they don’t need to avoid making lifecycle decisions up-front. We trust that we will have better data later with which to make more informed decisions, but in reality, we rarely revisit such decisions and typically have a vast amount of low value data consuming valuable management resources.
Choosing the right tools
Once your organization’s high-level deliverables are translated into protection requirements, IT can determine the technology and processes required to meet those requirements. As IT has become more service-focused, the requirements may fit into a protection delivery package already being offered by IT. Where requirements are not met by current service offerings, new service levels will need to be developed.
Product decisions are based on how critical the data is and how rapidly the resumption of service needs to be following an event. We approach these protection services in a tiered fashion, with layers of appropriate technology and process to provide protection ranging from very cost-intensive, low-loss scenarios to more economical solutions providing service for more flexible protection requirements.
Re-evaluate your protection requirements
Finally, your organization needs to regularly revisit your data protection strategy, to make sure the requirements remain valid. Not only are policies, regulatory requirements, and data values changing, but new data types are constantly emerging for which your previous protection strategy may not make sense. How does the growing use of social media—chat, screen sharing, or other collaborative solution—impact your current data protection approach? You should have a regular cadence of communication with relevant stakeholders to address these questions.
Like so many business strategies, data protection needs to be a collaborative and agile process to keep ahead of a changing data-driven world.
This post was originally published on the EMC IT Blog and was shared with permission from EMC and the author.