Mar 17 ’09

z/Data Perspectives: Recovery Is a Compliance Issue

by Editor in z/Journal

When data professionals think about regulatory compliance we tend to consider only data in our production databases. After all, it’s this data that runs our business and must be protected. So, we implement database auditing to know who did what to which data when; or, we tackle data protection initiatives to protect our data from prying eyes; or, we focus on improving data quality to ensure the accuracy of our processes.

These are all worthwhile endeavors, but focusing exclusively on production data is insufficient to ensure compliance. Improved backup and recovery practices must be an essential component of your compliance plans.

Ensuring the integrity and availability of your databases is the primary focus of backup and recovery planning. Indeed, recoverability must be the primary objective of every DBA—not performance, as some assume. After all, it should be easy to achieve fast performance to inaccurate (or worse, non-existent) data, right? But what about compliance and regulations? Let’s examine database recovery through the lens of COBIT (the Control OBjectives for Information and related Technology).

What COBIT Does

COBIT is a framework that companies can use to improve management over their IT organizations, to improve the value of the IT organization, and to ensure the goals of the IT organization are aligned with the goals of the business. COBIT is about recognizing and safeguarding the value of information as a corporate asset by identifying and managing risks and ensuring corporate governance via effective controls. The crux of COBIT is to link IT and business goals, identify responsibilities of business and IT owners, and monitor performance, evaluating it against metrics and maturity models.

The COBIT framework consists of 34 specific control objectives, organized into four domains: Plan and Organize (PO), Acquire and Implement (AI), Deliver and Support (DS), and Monitor and Evaluate (ME). Best practice frameworks such as COBIT are vital tools for ensuring compliance with regulations such as Sarbanes-Oxley (SOX).

COBIT and Recovery

Database recovery needs to be tackled from a best-practice approach to enable your organization to do the kind of upfront planning and routine monitoring and evaluation that COBIT advocates. An organization that has adopted COBIT as a best-practice framework understands the critical value of information to the business, and the need to assure its integrity and availability.

Yes, you need to develop backup policies and procedures for all your database objects that match your business availability requirements. But most DBAs haven’t implemented regular systematic checks for the ongoing viability of their backup and recovery plans to match their recovery time objectives—or even to ensure their existing backups are valid and could be used in a recovery situation.

Recoverability is addressed by the following 19 COBIT objectives across three process domains:

• PO9.4: Assess risks—during planning and organization you must assess the risk of databases being unrecoverable from backups.

• DS1.3 and DS1.4: Define and manage service levels— metrics are required to define service level objectives for recovery. Do you know how long it would take to recover a specific database object? If not, how can you ensure that application service levels will be met or exceeded?

• DS3.2, DS3.3, DS3.4, DS3.5 and DS3.8: Manage performance and capacity—regularly checking recovery health aids capacity management by improving the availability of information and resources that depend on it.

• DS 4.10, DS4.11, and DS4.12: Ensure continuous service—again, ensuring service is impossible without being able to ensure recoverability (including mirrored backup IT sites and/or offsite backup data stores).

• DS11.9, DS11.19, DS11.20, DS11.21, DS11.23, and DS11.24: Manage data—any number of issues may require recoverability as part of an ongoing data management effort. COBIT Objective DS11.24 specifically covers verifying the usability of backups.

• M1.1 and M1.2: Monitor the processes—ongoing monitoring of recoverability is needed to verify every backup job and its effectiveness in your environment (logging, memory, system resources, etc.).

Organizations need to better acquire and implement tools and procedures that help verify the integrity of your backups, the system settings that could affect your ability to recover, and the processes associated with backup and recovery of your databases. Analyzing your database system, data, and backups, and determining their health and usability should be a regular practice. If not undertaken, a system failure, logical error, or catastrophic event could significantly impact your business.