Compliance and Oracle databases

Compliance is the general term used to describe the efforts made by many - typically larger - organizations to meet regulatory standards.

In the US, the most important compliance regulation is the Sarbanes–Oxley Act of 2002 (SOX) for public companies and the Statement on Auditing Standards No. 70: Service Organizations (SAS70) for private organizations.

Other compliance regulations include:

  • The Health Insurance Portability and Accountability Act (HIPAA)
  • The PCI Data Security Standard (PCI DSS)
  • The Gramm–Leach–Bliley Act (GLB)
  • The Federal Information Security Management Act of 2002 (FISMA)
  • The International Organization for Standardization (ISO) standard ISO17799.

In the UK, the Financial Services Authority (FSA) also maintains regulatory requirements.

The majority of this legislation deals with increasing accountability in the wake of some highly visible and damaging breaches of public trust. It gives rise to a need for more reliable paper trails, security and access controls, detailed and reliable monitoring, and change histories.

The impact on database professionals

Regulatory compliance has an impact throughout an organization, from finance departments and CIOs to individual developers and database administrators (DBAs). For example, compliance auditors will require DBAs - the custodians of a company's critical data - to account for all changes to a database, and detail all those with access to it.

This means they must be able to demonstrate that they have processes in place to:

  • Manage how schema and data changes are made
  • Document the changes that are made
  • Maintain a detailed history of who made which changes
  • Document database schema and access permissions
  • Revert to previous versions if problems occur

Unfortunately, these are areas where database development has long lagged behind wider application development.

The nature of database code has historically been seen as a barrier to the implementation of change management, and therefore the maintenance of an audit trail. Many databases even go into production without any clear and meaningful history of changes, and auditors may regard this as an unacceptable avenue of risk.

An audit trail for Oracle Development

Introducing source control to the development process lets you know who changed what, when, and why. It is therefore the first step in getting databases ready for compliance.

Source Control for Oracle integrates with existing source control systems, so there's no need to change the way you work. This eases adoption, giving you a database development audit trail with minimal disruption.

Preparing for compliance with the Redgate tools for Oracle

Compliance requires strict process enforcement and information management. Although no single tool can solve an organization's compliance problems in their entirety, Flyway Enterprise presents a package of solutions to some of the most painful and costly database development and deployment problems. Undocumented code and poor change tracking expose you to risk, and the tools in the Deployment Suite for Oracle seek to mitigate that risk with minimal overheads.

To give a simple example: it is compliance best practice to document changes to schemas and application data. Source Control for Oracle allows you to preserve an incremental history of these changes, who they were made by, why, and when. Schema Compare and Data Compare can not only deploy these changes, but produce detailed reports of the differences between databases, and the final changes you deploy. This means you can begin to form a database audit trail with minimal extra investment and disruption.