IT Operations Management (ITOM)

How to improve how you test, patch and prevent compliance issues through automation

How to improve how you test, patch and prevent compliance issues through automation


Guest post by Klaus Muehlbradt, HP Software Database and Middleware R&D


When it comes to Data Base as a Service (DBaaS), there are two fundamental questions regarding compliance testing and remediation:

  1. Who is responsible for database compliance testing—the provider of DBaaS or the consumer?
  2. Who is responsible for remediation of the database problems discovered—the provider or the consumer?


Depending on the provider, the answer could be either of those two options or a blend of both; although it is likely that the provider will have some responsibility for database compliance.




Fig. 1: HP Database and Middleware Compliance Dashboard


Commercial vs. internal clouds

In a commercial cloud environment, in which an external third party provisions the database, it depends on the actual scope of the service provided. The scope of the service may only be a basic database provisioning and the consumer might be able to customize at will; the provider would only be responsible for the initial compliance of the provisioned database. However, if the service is a fully managed database, the provider will likely share compliance responsibility or own it completely.


For internal cloud services, the same basic principles apply, with one difference; as both provider and consumer belong to the same legal entity, a provider rarely has the opportunity to move all responsibility to the consumer. At the very minimum, the in-house provider has to provide a mechanism that allows the in-house consumer to understand if databases are compliant. This mechanism can be a testing tool, for example, or regular compliance status reports.


Sharing test results

Testing is a prerequisite for remediation, of course—nothing will be fixed unless you are aware of a problem. The provider must be prepared to test for compliance in the first place and share the results with the consumer.


HP Database and Middleware Automation (DMA) tests databases according to the established CIS benchmarks and maps the results to SOX and PCI, and then automatically sends results of the compliance scans via email (Figure 2). The compliance runs can be scheduled to execute at regular intervals or could be started by a monitoring tool using DMA’s RESTful API. These types of small features often make a big difference.


DBaaS for Production - Remediation - Details.png


Fig. 2: An example of HP DMA Compliance scan results


Remediating compliance issues

When an issue is identified, actual remediation is guided by DMA’s detailed explanation of why a database failed the automated compliance test and, wherever possible, any information it can provide about how to resolve the compliance issues. Additionally, DMA offers a set of database patching and database configuration workflows that can be applied (Figure 3).


 oracle compliance.jpg


Fig. 3: Example of Oracle Compliance Audit workflow in HP Database and Middleware Automation


Preventing compliance issues

Standard database configurations and regular patching of database systems are two proven mechanisms to prevent compliance issues in the first place, and DMA can help improve both.


The DMA concept of deployments allows senior DBAs to define standard configurations for databases. With many configuration parameters locked down in the DMA deployment, human error is significantly reduced if not completely eliminated. Regular patching processes, such as with Oracle’s quarterly patch, are also improved through the standardization imposed by deployments, as well as from the automation services offered by DMA.


Learn more

Using automation can greatly streamline how you as a provider meet your obligations to test and remediate compliance issues in DBaaS.





  • infrastructure management
0 Kudos
About the Author


This account is for guest bloggers. The blog post will identify the blogger.


It should be responsiblity of provider to test their data base issues for compliance against certain data exchange standards.