GRC 101 for DB2 LUW DBAs

January 13, 2011

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.