Data Protection and Information Lifecycle Management

Companies face two important difficulties with data protection: complexity and cost. As the data protection needs of organizations change and grow, the task becomes more complex. With complexity comes the opportunity for mistakes. In regulated environments or public companies, this can be a dangerous problem. Simple errors in judgment or planning can lead to data loss, lawsuits, and fines.

Another problem with many data protection strategies is that all data is assumed to be of equal value. The problems that result from treating all data the same are added expense and wasted time. When unimportant data is dealt with in the same fashion as mission-critical data, valuable resources are assigned to valueless data. Time and effort are also expended on data with little or no value to the organization. This needlessly raises the cost of protecting data. It also increases the odds that important data will not be adequately protected.

What Is Policy-Based Data Protection?

Policy-based data protection is a way of defining data protection methods, tools, and procedures as policies and then deriving rules from those policies. The goal of policy-based data protection is to alleviate some of the difficulties associated with the complexity and cost.

A policy is a set of best practices that the organization must follow. These policies are not simply guidelines or suggestions. Policies are a concrete expression of the data protection strategy. If the goal is to protect only valuable e-mail, a policy can be developed that defines what is valuable, what is not valuable, and how to manage it. From policies, a set of rules can be derived that tells the organization exactly what it must do. Policies remove ambiguity from the management of data.

It is important to point out that policies define business processes. They do not mandate that specific technology be used. Technology may be used to automate compliance with policies, but the definition of policies is not dependent on software or hardware.

Policy Development Guidelines

Writing data protection policies is a very difficult task. Despite the fact that it is helpful in the long run, in the short term it is usually an arduous process. Many constituents need to be consulted, and data protection is too critical to leave any of them out. Unfortunately, the initial effort involved inhibits organizations from doing the necessary work of data protection policy development.

Policies are, by nature, hierarchical. Broad policies covering large sections of the data protection strategy are supported by smaller components. These in turn are supported by smaller components. This continues until the desired level of detail is achieved. The level of granularity necessary to create a good policy depends on the organization and on the scope of the data protection strategy.

It is best to start small, choosing either a top-down or a bottom-up approach. In the top-down approach, the first polices developed are broad and cover the overall data protection strategy. The next set of policies drills down and fills in more details. This has the advantage of having all the individual policies governed by a root policy, providing context to the overall hierarchy. The disadvantage is that a lot of work has to go into policy development before it becomes useful to the organization.

The bottom-up approach focuses on one or two small functional areas of the data protection problem and develops detailed policies for them. Other detailed policies are developed over time, which are aggregated into higher-level policies until a full policy set is developed. This type of policy development works best in organizations that already have a clear sense of their overall data protection strategy. Specific, detailed policies can be put into action sooner.

Tip

Though the bottom-up approach allows for quick implementation of critical policies, it can create problems later. Individual policies tend not to agree with one another. When the top-level policies are written, they may force changes in the lower-level policies. This creates more work as policies are written and rewritten.

The top-down approach better assures internal consistency among policies and reduces the chance of having to rewrite policies.

Data protection policies have certain characteristics. These guide the overall process of developing policies but do not define them. Instead, policies are defined by business needs, company processes, and the data protection strategy.

Characteristics of good data protection policies are that they:

• Must be written. All policies must be written down and made available to everyone. If the people who need to follow the policies do not have access to them, they cannot comply with them.

• Must define a set of processes and rules. A policy is a failure if it does not clearly tell people what they need to do. It needs to be expressed as a process or procedure that can be easily converted in a set of rules to follow.

• Must not be vendor- or technology-specific. Policy is not about technology; it's about business and organizational needs. A good data protection policy should never define specific technology, products, or vendors. The policy should be valid even if these change.

• Must be specific to the organization. Data protection policies are like a toothbrush an individual item. Each organization is different and has different needs. Templates and best practices from other organizations are good starting points and guideposts. They are never a sufficient substitute for doing the work of policy development.

• May be hierarchical. There are advantages to arranging policies in a hierarchical tree. First, it creates clear connections among related policies, making related policies easier to find. Next, it makes it easier to see where subsequent policies have overridden statements in the parent policy. Finally, it provides a structure for future policy development.

• Must be simple to understand. Overly complex policies ensure lack of compliance. If the policy is hard to understand, the organization will make mistakes. When the policy is complex and burdensome, it will be subverted.

Many data protection policies are based a need to comply with regulatory and legal requirements. Failure to protect data in a manner that complies with regulations and laws may result in fines and lawsuits. Nonpublic companies in nonregulated industries will not be governed as much by regulations during policy development.

A Sample Data Protection Policy

In this example, assume that Widget Corporation (a fictional maker of widgets) has the following requirement regarding corporate e-mail:

All customer and prospect e-mails must be retained.

Widget Corporation defines a customer as anyone who has bought or ordered products in the history of the company. A prospect is defined as anyone who has expressed interest in Widget's products but has not yet purchased anything.

The data protection methods that Widget Corporation are using include continuous replication of e-mails and daily and monthly backups of the e-mail database

The e-mail retention policies can be described in plain language as:

Name: Customer E-Mail RetentionPolicy Type: E-MailData Type: E-Mail

Parent: E-Mail Policy

Description: Policy governing the retention of customer e-mailPurpose: To support continuing business operations by ensuring that previouse-mail communications with customers are available to Sales, Marketing, and

Customer Service.

Creation Date: MAY 4, 2004

Revision Date: FEB 28, 2005

Process:All e-mails to and from customers and potential customers (also known as

prospects) will be copied to a duplicate copy of the e-mail database as theyare received. End-users are not allowed to delete customer e-mails in any way,

including from their personal mailboxes.The primary and duplicate e-mail database will be backed up to tape eachnight; tapes will be rotated according to current IT policy (IT Tape RotationPolicy).Customer e-mail will never be archived.

Expected Results: All customer e-mail will be available online all the time.

Constraints: There is no automated method of keeping users from deleting

e-mails.

Assets: primary_email, secondary_email

Asset Type: Disk array

Asset: backup1

Asset Type: Backup server with attached autoloader

The sample clearly states what the policy is, what is expected from IT and end-users, and how it is to be accomplished. It also recognizes constraints that may affect compliance. By including parent policies, it establishes a hierarchy as well. A typical hierarchy in this case might be as follows:

Data Protection Policy:

E-Mail Policy:

    Customer Retention Policy

    Financial E-Mail Retention PolicyDatabase Protection Policy:

    Financial Database Protection Policy

    Manufacturing Database Policy

Each subsequent level of policy adds detail and overrides more general processes in the parent.

In XML, this policy can be written as such:

<policy policy_type="E-mail" data_type="E-Mail" parent="E-Mail Policy"> <name>Customer E-Mail Retention</name> <description> Policy governing the retention of customer e-mail </description> <purpose> To support continuing business operations by ensuring that previous e-mail communications with customers are available to Sales, Marketing, and Customer Service. </purpose> <date> <create>MAY 4, 2004</create> <revision>FEB 28, 2005</revision> </date> <process> All e-mails to and from customers and potential customers (also known as prospects) will be copied to a duplicate copy of the e-mail database as they are received. End-users are not allowed to delete customer e-mails in any way, including from their personal mailboxes. The primary and duplicate e-mail database will be backed up to tape each night; tapes will be rotated to according to current IT policy (IT Tape Rotation Policy). Customer e-mail will never be archived. </process> <expected_result> All customer e-mail will be available online all the time. </expected_result> <constraints> There is no automated method of keeping users from deleting e-mails. </constraints> <asset asset_types="Disk Array"> primary_email, secondary_email </asset> <asset asset_types="Backup Server">backup1</asset> </ policy>

The XML document can still be read by a nontechnical individual. Unlike the first document, it can also be read by software that might manage or use the policies later. The XML may be extended to include commands for software or devices that tell them to perform specific functions related to implementing the policy. For example, a <command> tag may be added that is read only by software that controls the tape library.

<command> backup source primary_email dest backup1 schedule daily time 20:00:00 </command>

It would be clear, even to a nontechnical person, that this was intended to be a command for a software program that would define a backup process. The plain-language and XML versions could be used together to provide maximum clarity and enhance automation of compliance.

The Reasons Policy-Based Strategies Fail

Developing sound policies is tough. The work can be tedious and tends to uncover all the places where the organization is deficient. There are some common potholes that many organizations step into when developing data protection policies. Some examples are

• Failure to use logical names for devices. One of the great strengths of the Internet is that it does not rely on raw device addresses, such as IP addresses. Instead, it uses logical names. Changes in the infrastructure are transparent to users. Designing around physical device names or addresses makes changes difficult. Changes in devices should never force changes in policies.

• Reliance on human compliance. Even simple scripts that automate processes help with compliance. Asking end-users to remember to perform tasks, especially when the tasks require multiple steps, assures noncompliance.

• Expecting users to change their behavior. The classic problem with document management systems is that they depend on check-in and check-out practices. This is not what people do normally.

  Warning

  End-users should never have to change how they work to comply with the data protection policies. Not only is it easy to make a mistake, but forcing changes in human behavior practically invites subversion. Design policies according to accepted and existing end-user practices, and people will comply.

• Focusing on the technology, not the process. It is natural for IT people to view data protection as a technology problem. Technology then becomes the natural starting point. That is the tail wagging the dog. Policies derive from the process and practices of the organization. The best place to focus attention is on the goals and policies of the organization. Technology exists only to assist compliance with those policies.

• Having IT do all the work. Remember to include the other stakeholders in the decision-making process. Even if IT has charge of the data protection policy, many other people in the organization will be affected by it. They need to be part of building and implementing data protection policies.

• Refusing to fix process problems. The development of data protection policies undoubtedly will uncover problems with existing processes. Some policies will simply be broken or obsolete; others will conflict with the data protection needs. Refusal to fix process problems first results in data protection policies that users cannot or will not comply with.

The overarching reasons that policies fail, either in development or implementation, are lack of attention to human behavior and too much attention paid to technology. IT professionals especially must focus their attention on the processes and how they affect people before considering technology.