Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Tips Database Forum Rss Feed

» Database Journal Home
» Database Articles
» Database Tutorials
MS Access
SQL Scripts & Samples
» Database Forum
» Slideshows
Free Newsletters:

News Via RSS Feed

Rss Feed

Database Journal |DBA Support |SQLCourse |SQLCourse2

Featured Database Articles


Posted Jan 13, 2011

GRC 101 for DB2 LUW DBAs

By Rebecca Bond

Rebecca Bond attended IOD recently where the "hall conversation" centered on Governance, Risk Management and Compliance (GRC) and the potential impact for DB2 DBAs. Read what she discovered as she researched answers to some basic GRC questions.

When I attend a conference, sometimes the conversations that are held in the hall are as interesting as the material presented in session. This year, my favorite "hall topic" was Governance, Risk Management and Compliance (GRC) and how DB2 DBAs are being impacted. No one seemed to have a clear idea of what GRC actually was and the acronym seemed new and cutting edge, so I did some research. The questions I set out to answer were:

  • Is GRC really new?
  • Will DB2 DBAs be impacted by GRC?

Since GRC initiatives are typically driven by management as they strive to meet regulatory compliance requirements or perform the tasks that are necessary from an organizational standpoint to ensure business continuity, you may not immediately see a connection to DB2 DBAs. It is true that DB2 DBAs don't usually set management direction. However, in thinking about GRC, technology plays such a large role in governance, risk management and compliance efforts that it seems reasonable that DB2 DBAs will be integral to successful GRC outcomes. The lack of definition of the terms, a perceived "change of direction" and potential "additional workload" from GRC initiatives is what was driving those interesting and enlightening DBA discussions in the halls at IOD.

From a DB2 DBA perspective, GRC should appear different than it does to management. Management deals with GRC at the macro level with policies, processes and procedures, but DBAs or other technical staff who deal with the organization's data will be involved with GRC at the micro level. That much makes sense, but what is GRC? This question reminds me of many DB2 questions and answers. No matter what the DB2 question, the answer is often "it depends". GRC seems to have one of those "it depends" types of answers. The entire definition of GRC has some blurred lines and there is no standard correct answer that I have been able to discover. Of course, there are some core concepts that allow us to generalize about GRC and a possible impact on DBA workload. In looking at those core concepts, however, GRC does not seem new at all. In fact, DB2 DBAs may have been doing GRC work for years and just not recognized it as such.

Breaking it Down

The G -- Governance

What does governance mean to DB2 DBAs? When thinking about governance, my mind goes to the issue of trust. Can I trust the data I have? Is the overall data confidence level sufficiently high enough to enable my organization to say that the resulting data output is accurate? Can the data be relied upon to provide correct information regarding business objectives and regulatory compliance? Can it be reliably used for business forecasting? Can it be used to identify risk?

Perhaps you recognize this scenario. Your organization tasks you with incorporating some new data into your database environments. The data may have been supplied by a third party or it could be from a legacy environment. You receive the data, but there is no data model. You aren't given the metadata, or if you are, it doesn't sync with the metadata that you already have. The ability to accurately perform data reconciliation is obviously hampered. Decisions on how to incorporate the data are made based on limited information and guidance. Because something must be accomplished, the data is moved into the database under this imperfect scenario and the task is marked complete.

How many times does this cycle repeat? How many times is new data brought into an environment in a similar manner? As a consultant, I see a lot of database environments. Most are struggling to manage disparate models of metadata without the benefit of a cohesive master data management approach. Redundancy and sustainability are obvious issues. The inability to accurately report on the data, due to this lack of unified metadata management, becomes another. If cleanup isn't done, the potential for returning inaccurate data results increases.

An example of data challenges can be demonstrated when thinking about the variety of ways you can store a Date of Birth in a database. First, we suffer from different column naming approaches. Is the column DOB, DateofBirth, Birthdate, or something else? Then we have to deal with what is stored. Are the values only Month and Day; Month, Day, 4 digit year; Month, Day, 2 digit year? Depending on how the date value is stored, there are also complexities. Are the values stored as YYYYMMDD; DDMMYY; YYYYMONDD; MM-DD-YYYY or some other pattern? Are the values stored as character, date or numeric values?

Another complexity surrounds the actual meaning of the values that are being stored. Column names can be the same for two different tables, but that does not mean that the data values they represent belong together. Consider this scenario. In my database, I have an INVENTORY table with column named COST. What does the data value in that column represent? I've now been asked to incorporate data from another database. This database also has a table named INVENTORY that has a column named COST. Does this mean that the data values in the two COST columns represent the same type of information? The answer is "it depends". Perhaps COST in one table represents the original purchase price of the article in inventory without factoring in any additional costs, such as shipping. In comparison, the COST column in the new table represents a value that is composed of the original purchase plus shipping and any associated ancillary charges. In this case, the values in the two COST columns may look the same, but they aren't. They represent different data values.

In situations such as this, how can we be assured that the information provided toward GRC initiatives is accurate, complete and valid for the information request? Yes, I recognize that DBAs are not the data owners and that the data owners are ultimately responsible. Despite that fact, I also recognize that data owners and management need DBAs to help them sort through these types of issues.

The R - Risk (Management)

Every day, every human deals with risk. Obviously, DB2 DBAs can't avoid risk and neither can organizations. In thinking about risk from the GRC perspective, we are typically dealing with business objectives and risks that might impact them. How does your organization recognize and deal with risk? Are there opportunities to use current and forecasted data to help with risk identification, avoidance or mitigation? Again, we are back to data - reliable, believable data.

Of course, risk management is tightly correlated with security (including database security). It's obvious that DB2 DBAs (or, more accurately, the designated SECADM) can expect to be involved in implementing database security controls such as:

  • Separation of Duties
  • Trusted Contexts
  • Roles, Authorizations and Privileges
  • Encryption of data in flight and at rest
  • Label Based Access Controls
  • Database and Instance Auditing

The C -- Compliance

How does your organization measure and report? What regulatory bodies are involved and what data is needed by them to prove compliance? How are areas that might need remediation identified? Obviously, data is involved.

When it comes to compliance, DBAs might be involved in writing SQL, designing reports, scheduling job streams to meet deadlines and providing audit trail information to appropriate parties. In preparation for these tasks, this might be a good time to learn about some of the newer features of db2 auditing that can help eliminate some of the overhead of auditing. For example:

  • A new audit category, EXECUTE, provides information on SQL without the overhead that was a typical issue with CONTEXT auditing.
  • The location of the active log is now configurable which enables a move to faster disks for better performance.
  • New options provide additional granularity. Choose to audit only what is important without any additional overhead.

Final Thoughts

When looking at GRC from the DB2 DBA's vantage point, GRC initiatives can have a significant impact on DBA workloads. Have you ever worked in an organization that experienced a data downsizing? I suspect the answer is 'no'. Instead, most of us work in organizations that are driven to store more data each year while keeping all the previous data intact. Corporate mergers, regulatory requirements, new initiatives, new business models or organizational and managerial changes are some of the reasons for the data overload. As storage costs have declined, barriers to storing more data have eroded. More data means more DBA work is necessary to provide relevant information for GRC initiatives.

As DB2 DBAs, we play a critical role toward providing information that organizations use for their Governance, Risk Management and Compliance efforts. Whether GRC is simply a repackaged acronym for what is already being done or if GRC serves as motivation toward unique new approaches, DBAs will likely be involved. The more we learn about how our organization approaches GRC, the better prepared we will be to continue to provide exceptional results.

Is GRC new? My answer would be "no". The concepts have been around for a long time. Perhaps just the focus is new. Is GRC going to impact DB2 DBAs? Most likely, but then it seems that most initiatives impact DB2 DBAs to some extent. I guess that is good for job security. Maybe that is why GRC kept coming up in my discussions with other DBAs at IOD. Job security is always a good thing.


Separation of Duties:

IBM DB2 9.7, DBADM and my Rubik's Cube


DB2 LUW Security -- Did they, or Didn't they?

DB2 LUW Security - DB2Audit Part 2 of (Infinity and perhaps beyond)

DB2 LUW Security -- DB2 Audit Log Olympics

Database Auditing in IBM DB2 9.5 & 9.7: How do I know...

Secure DB2: Auditing Presentation


Database Security Puzzle Solving with IBM DB2 LUW Roles

Putting IBM DB2 Database Security Setup Work on a Diet


IBM DB2 LUW Database Hardening with Data Classification and LBAC

IBM Data Governance Blueprint

» See All Articles by Columnist Rebecca Bond

DB2 Archives