Compliance Documents is very much a made up term, much like Authority Documents. It is the term that the Unified Compliance Framework™ team uses when discussing the various types of compliance documents within an organization, such as policies, standards, procedures, etc. We made up the term because it is much easier than saying policies, standards, procedures, etc. each time we refer to this genre of documentation, and you really can't call an XML specification a policies, standards, procedures, etc. specification. And to make it even simpler in our XML files, we call them cDocs there.

The reason that the UCF team has taken this approach to crafting Compliance Documents is because we have had a very hard time (as well as everyone else) connecting the dots between Authority Documents stating your organization has to have certain policies, standards, and procedures, versus what gets put into the policies, standards, and procedures your organization uses. Until now, there hasn't been a direct correlation, or "norm" for what should go into these documents and how these documents should be linked back to the sources that call for them.

As a case in point, when we examined many of the online "policy builder" or "policy template" websites, we couldn't even find a policy for managing cryptographic controls in their "must have" lists. And of those websites that we did find advertising such a policy, we couldn't find any direct reference to the Authority Documents' controls specifically called for.

So our first aim is to create a structure to directly relate the content of Compliance Documents to the Authority Documents that call for the controls contained within them.

Our second aim is to dispel the myth that everything is a Policy. Many organizations are creating Policies that are really standards or checklists. And many folks who are purportedly "in the know" are calling procedures standards and visa versa. So after a lot of hoopla, angst, and research, we've broken things down as follows:

• • Policies deal with high-level behaviors. Therefore, a policy is put into play when the organization needs to coordinate and execute various activities or compliance controls.

  • Procedures are the operational how-to's or "do this then do that's" and therefore document processes or steps that people take in their functions, roles, and jobs. Groups of procedures form organizational Plans.

  • Standards and their informal counterparts, checklists, are normally used as a list of items to be appraised ("examine this, that, and the other") or acted on ("configure this, that, and the other").

Therefore, the UCF employs all of the Compliance Document types mentioned above in our Compliance Documents.

The structure of Compliance Documents

After reviewing, oh, about 500 variations of Compliance Documents, we found that there is a generic structure that can be derived and applied across all of the document types. That structure is defined here.

Title and Description

For now, we've chosen to "anchor" all of our Compliance Documents on a chosen control from within the UCF. For example, our first Compliance Document (which is a policy) is entitled Create and maintain a policy for encryption management and cryptographic controls, and that title is drawn directly from a harmonized control title within the UCF's Controls List (UCF CE ID 04546).

The description for the policy is a brief and to the point version of the Control Title that the Compliance Document is based upon.

Content of the Compliance Documents

The content of each of these Compliance Documents, whether they are policies, standards, procedures, or whatnot, can all be taken directly from the list of the UCF's controls. Beginning with version 2.1 of the UCF, all controls are written as active verbs. Therefore, "Digitally Sign Emergency and Critical e-mail notifications" [UCF CE ID 04841], can be used as a policy statement.

The great part about using the UCF as a basis for the content of Compliance Documents is that

1. the content can be linked directly back to each and every Authority Document that has called for it (by using the UCF CE IDs as references),

2. the UCF's inherent taxonomic genealogy can be brought directly into the document structure, and

3. as additions, changes, and deprecations to the UCF are made, they can easily be incorporated into the Compliance Documents.

The format of each content element

Our current methodology is to directly restate the UCF control as the main content element for each item in the list, followed by the Roles associated with that control and then the Assets associated with that control.

Generate strong keys [UCF CE ID 01299] Assigned to Role IDs: (0000101); Assigned to Asset IDs: (0001478)

This allows the end user to "de-scope" the individual elements within each policy if they don't have any of the assets (or assets like those) currently assigned to the control. It also serves as an indicator for which roles need to be assigned to the individual items.

The taxonomy of the content element

The UCF is a hierarchical taxonomy based upon control dependencies. In plain English, that means if the UCF says "do this" at level one, and then "do that" at level two, the "do that" is dependent upon the "do this" getting done. And if you think that was plain English, you need to be a lawyer. Even more plainly, we figured out what to do when you want to add section 2, and 2.1 to a document, followed immediately by section 5.8.7.2.2 and 6.3.9.2. Without a "taxonomic slider", you'd get an outline like this:

1 do this

1.1 do that

5.8.7.2.2 do something else

6.3.9.2 get some coffee

Not good. So we've built a "taxonomic slider" into our system to figure out that 2.1 must show up as dependent upon 2. And that in this particular schema, since neither 5.8.7.2.2 nor 6.3.9.2 have any dependent controls, they should both be at level 1. In the UCF's Compliance Documents taxonomy, the outline looks like this (much better):

1.0 do this

1.1 do that

2.0 do something else

3.0 get some coffee

Tracking content changes

Again, we come back to the database problem faced in the original Jurassic Park movie: they weren't tracking their dinosaurs the right way. We won't make that mistake. Once any particular UCF control has been added to a Compliance Document, it is in there and can't be removed. In order to not show the UCF control in an exported document, we mark the UCF controls as being deprecated like we do in each of our other lists. That simply means that the control has been deprecated from this particular Compliance Document, not the main UCF Controls list.

And speaking of that list, a control is automatically deprecated from a Compliance Document if the control is deprecated in the main UCF Controls List.

Scope and Assignment

Because each of the content items are individually mapped to both Roles and Assets, we can easily create a consolidated Scoping (Assets) and Assignment (Roles) section of the Compliance Document. The contents in each of these sections are automatically rolled up from the complete list of controls found within the document plus the addition of the mapped Assets and assigned Roles found in the base control used for the Compliance Document title.

This allows the organization to more easily go through the Compliance Document and pick out the controls that don't apply to them because they don't have those types of assets in their organization. It also helps them determine which Roles need bodies assigned to them if the Roles can't be traced back to actual humans who have to perform the tasks mentioned.