The Elements of IT Compliance

Compliance is about process

Compliance rules from authority documents (laws, contractual obligations, international and national standards, audit guidelines, etc.) are conveyed either as "thou shalts" (do this or don't do that), or even step-by-step instructions (think PCI Audit Guidance). In other words, compliance is conveyed as process and definitions – defining a common language as well as a series of actions or operations that lead to an end. That is different than methodology. Compliance defines the actions we must take (or refrain from) or the ends we must achieve. What it doesn’t define is how to get there.

Therefore, when breaking compliance down into its base elements, what we are searching for are the sources that define the language and content of our governance controls.

compliance table of elements illustration

 

Compliance Elements

The UCF team have dug into the hundreds of Authority Documents, mining them for these five compliance elements:

Rs – Research Sites: Where do we go to look for all Authority Documents that pertain to the topic at hand, or that cover our organization and industry?

Ad – Authority Documents: Which specific Authority Documents fit us? For those that do, catalog them for future reference.

Gl – Glossary: How do each of the Authority Documents use their document-specific terminology, and how does that terminology harmonize (or not) with other Authority Documents of the same type?

Ac – Acronyms: How do each of the Authority Documents use acronyms, and do the acronyms they use match the same usage as other Authority Documents?

Ct – Citations: How do we break down each of the Authority Documents into individual citations that can easily be digested and cross referenced?

Governance is about methodology

Governance is rooted in methodology—a body of methods and rules employed within a given discipline. In other words, given the action at hand being called for, what are we going to do about it and how are we going to do it?

Within the world of information compliance, governance is by necessity an amalgam of software driven solutions that either bind the compliance activities together or provide the underpinning of support for those activities.

Governance Elements

So far, the UCF team has found thirteen base governance elements within the Authority Documents we’ve mapped:

Ce – Controls: What are the harmonized “to do” items that the Authority Documents speak of?

Me – Metrics: How do we measure the success or failure of those harmonized Control items?

Ro – Roles: To whom, as a defined role, should each of the Controls be assigned to?

Cd – Compliance Documents: Which policies, standards, procedures, and framework documents does the organization need?

As – Assets: Which Assets are affected by each of the Controls?

Ci – Configurable Items: If the Control speaks of configuration, what is the Configurable Item (and its proper configuration) that is in question?

Cm – Configuration Methods: All assets are different. There can be multiple Configuration Methods for each Configurable Item.

Ve – Vendors: You have to be able to track Assets back to their vendors.

Re – Record Examples: Which Record Examples (including forms), such as reports, tables, logs, contracts, whatever, pertain to the Control in question?

Rc – Record Category: Which Record Categories do the Record Examples belong to?

Ot – Organizational Tasks: Which organizational tasks handle the record category in question?

Of – Organizational Functions: Which organizational tasks belong to which business functions?

Ev – Events: How do we know when something happened of significance, or when a process needs to be triggered?

Au – Audit: How can we tell if we are performing the control in question?

The Information Architecture of Compliance and Governance

We’ve seen way too many models, architectures, structures, or frameworks without the supporting data elements needed as a foundation. When looking at those other models, structures, and architectures, you’ll sometimes see them all connected together into a nice, neat web, forming a nice neat picture.

In reality, it doesn’t work that way. In reality, there’s no need for Research Sites to interconnect directly to Compliance Documents. Or Metrics to interconnect directly with Configuration Methods.

What we are presenting here, with the Unified Compliance Framework™, is a real, working, fully connected information architecture that both can and does support applications in the real world.

This isn’t a pie in the sky, utopian vision of what should be. This information architecture is based upon the examination, mining, and mapping of over 700 Authority Documents and turning that process into usable governance materials.