menu
Citations

Citations

Ct

Short Description: A passage or expression in a document that is quoted or cited.

Long Description: A citation is a passage or expression in a document that is quoted or cited. The example below shows a total of eight Citations (1, then 1(a) through 1(f), and 2):

There are four classes of Citations that you will encounter in each and every Authority Document, though not all Authority Documents will have all four classes (because Configuration Citations are only found in certain types of Authority Documents). The four classes of Citations are Configuration Citations, Citations with Mandates, Stub Citations, and Information Gathering Citations.

This element connects to the following elements:

Citations covered in the Education section of our websites:

Mapping Projects that reference this element:

This element is comprised of the following fields:

FieldTypeDescription
liveboolean

This is either a 1 or a 0. It indicates whether the record is live within the database, or should be redacted.

Because the UCF™ treats every ID as both unique and persistent, we never delete an ID once used, nor do we re-use the ID. Therefore, if we have to redact a record, we merely mark the Live Status as moving from 1 (live) to 0 (redacted).

All records are initially created and marked by the system as Live (1). There are certain scripts that the UCF’s database team will run to ensure that two instances of automated deprecation takes place:

1. If an Authority Document has been deprecated, all of its citations will be deprecated.

2. If a control has no citations pointing to it, the control in question will be deprecated.

Other than the instances noted above, records must be deprecated as an editorial process and approved by both the editorial reviewer and the editorial approver. When the Live Status is set to deprecated (0), there might also be a corresponding setting for the Deprecated By element, but this is not mandatory.

deprecation_notesstring,null

Deprecation notes are new to version 2.1 of the UCF, and we’ve done as good a job as possible back-filling them to ensure that we have covered our bases.

In a nutshell, when our mappers, reviewers, or approvers have made the decision to deprecate one of the records in the various XML tables, they will add their deprecation notes, their reasoning, to this field. There is no set format for what they are writing, so there aren’t any hard and fast editorial rules, other than something has to be added to the field during deprecation.

date_addedstring,null

Date_Added is a date stamp for when the record was created.

This element is created when the record is entered into the UCF’s Master Content database and not the working database. We chose this method because the UCF team’s editorial process is a fluid one which allows, during the editing process, for records to be added, moved, deleted, or even "un-deleted" fluidly until the lock-date that ends the editorial process. Once the lock-date has been reached, all of the records are then finalized from the "working" list and uploaded as a batch to the Master Content database, which also triggers the change log process. Therefore, it is common to see all new records for any given quarter being added on the same date.

Because the Date Added element is controlled post-editorial process, the UCF database system manages everything automatically.

date_modifiedstring,null

Date_Modified is a date stamp for when the record was modified. We use this as a key field for tracking all roll forward and roll backward field calculations. The initial date reflects the date the authority document was added to the database.

This element is created and updated when the record is entered into the UCF’s Master Content database and not the working database. We chose this method because the UCF team’s editorial process is a fluid one which allows, during the editing process, for records to be added, moved, deleted, or even "un-deleted" fluidly until the lock-date that ends the editorial process. Once the lock-date has been reached, all of the records are then finalized from the "working" list and uploaded as a batch to the Master Content database, which also triggers the change log process, which relies on this field to trigger that a change has taken place in the record. Therefore, it is common to see all new records for any given quarter being "modified" on the same date, and all modifications for the quarter to happen on the same date as well.

We have heard from multiple XML licensees that they would rather have the exact date and time that the record was modified instead of the batch upload date. That isn’t possible, given that all of the XML licensees also want us to produce a compact and digestible change log. A change log based upon the exact date of modification would have already produced several instances with over ten changes for certain records. Changes that were of no consequence to either the XML licensee or an end user, because those changes were simply a part of our internal editorial process. Therefore, to save processing time on the change log and to shorten the length (of the already very heavy) change log, we made the strategic decision to limit both date modified and date created to be the batch upload dates.

Because the Date Added element is controlled post-editorial process, the UCF database system manages everything automatically.

languagestring

If the record is in a specific language, that’s what needs to be entered here. However, we are not using the name of the language, but rather the ISO 639-2 Codes for the Representation of Names of Languages reference. A complete and up-to-date reference can be found online at http://www.loc.gov/standards/iso639-2/php/code_changes.php. By default, all records are in English (code eng).

license_infostring

Because some of the records within the UCF are being provided by external sources, we now indicate this with a URI stored here. By default, the URI will point to Unified Compliance usage license information.

If the record is subject to external (outside of the UCF) usage terms, the URI will point you to those usage terms.

sort_valueinteger,null

The Sort Value is relative to its siblings, sort ID is relative to the entire hierarchy. Developers should be using the Sort ID instead of the Sort Value.

genealogystring,null

Within the UCF, a record’s genealogy is a set of UCF IDs strung together as distinct words (e.g., 0000000 0000001 0000002) that represent (from right to left) the current record’s parent, grand-parent, great-grand-parent, on back to the very root element that spawned the list. At minimum, every record will have a genealogy of 0000000 which represents the root record within the list.

The genealogy element is initially created by the UCF database system when the record in question is created. If the record in question is moved lower or higher in the taxonomy, the genealogy is automatically re-calculated and the value will change to reflect the new taxonomic structure. Because the UCF editorial team does not have edit privileges for this element, the genealogy will always reflect the taxonomic position the record was last stored in. If there is a dispute about the record’s genealogy, the dispute is an editorial one, and not a programming one.

sort_idstring,null

We sort our displayed information according to a taxonomic display hierarchy (which means that the genealogy plays a vital role). For the most port, each element in any of our lists is given a three digit sort identifier. We then append the record’s sort identifier to its parent’s sort identifier to create its Sort ID. We treat this numeric Sort ID as a text field so that we can run our sort routine from left to right in the character string.

There are some exceptions to the numeric Sort ID field, namely in the glossary and vendor lists wherein the Sort ID is actually the genealogical name of the record’s predecessors through its title. For instance, in the vendor list one of the vendors might be Sybari, which is a subsidiary of Microsoft. Therefore, its Sort ID would be "Microsoft Sybari".

The Sort ID is created and managed in the same manner as the genealogy (it is a dynamic calculation). It directly reflects the record’s place within the taxonomic hierarchy and is therefore uneditable by the UCF’s editorial team (although the team does set the sort order, the system handles the ID to manage the sort order). Any disputes with the validity of the sort ID are in effect a dispute with where the UCF’s editorial team placed the record in question within the taxonomic structure.

idinteger

The unique and persistent identifier for each record.

We use the id as the identifier so that if there is a discrepancy in how we any of the record’s information, any linked references to the record will not change. And as obvious from the previous sentence, we use the id field as the linking field when referencing this list from other lists.

The ID element is created when the record in question is created and is always assigned the next highest non-used, non-reserved ID in the system for that particular list.

check_digitinteger

We humans have to use numbers. However, when entering numbers, we humans also have a tendency to screw up the entry or copying of those numbers. A Dutch mathematician named Jacobus Verhoeff conducted a study of 12,000 numerical errors J. Verhoeff, Error Detecting Decimal Codes, Mathematical Centre Tract 29, The Mathematical Centre, Amsterdam, 1969, cited in Wagner and Putter, "Error Detecting Decimal Digits", CACM, Vol 32, No. 1 (January 1989), pp. 106-110. and from that, proposed a check digit calculation scheme http://www.augustana.ab.ca/~mohrj/algorithms/checkdigit.html#verhoeff that catches all single errors as well as all adjacent transpositions and most other errors.

To ensure that the IDs assigned by the system have integrity during input as well as distribution while being transferred into various formats (such as Excel, Word, Text, XML), each ID will also have its own checksum value stored in a checksum field.

Currently, the methodology for creating and verifying the checksum follows the Verhoeff calculation format.

The CheckDigit is created along with the record’s ID as a calculation by the UCF database system. As such, once assigned it should never change because the ID will never change. A sample calculation format is shown in the use case scenarios.

time_createdstring

The date and time the record was created.

time_updatedstring

The date and time the record was last updated.

deprecated_byinteger,null

If a record in the UCF needs to be deprecated, the record will not be deleted from the system. Instead, the record will be marked as deprecated (its "Live Status" field will be set to 0), and the Deprecated By field will be filled out with the ID(s) of the record(s) that took its place (if any).

Initially this element is blank and only a UCF editorial process can indicate a Deprecated By content change. That change is then reviewed by the editorial reviewer and editorial approver. If there are contents in this field, the Live Status field must be set to deprecated (0).

referencestring

A reference is an individual instance of guidance found within an Authority Document. ¶ 2 of the Senate Appropriations Bill says this, or ¶ 2.1.1 of the Senate Appropriation Bill says that. References are always identified by their document separators, such as the paragraph mark (¶), section mark (§), or even question number (Q).

guidancestring,null

This is the actual Citation Guidance copied directly from the Citation in the Authority Document. A citation is a passage or expression in a document that is quoted or cited. The example in the click HERE below shows a total of eight Citations (1, then 1(a) through 1(f), and 2). The guidance portion would be the text of each paragraph, stripped of the reference identifier and any parenthetical information, such that paragraph "(a)" below has "processed lawfully, fairly and in a transparent manner in relation to the data subject."

Click HERE for the Citation Guidance graphic.

guidance_as_taggedstring,null

Within the UCF Mapping process, there are times the mappers have to add additional text for tagging purposes when the original authors intended to say something but didn’t say it in a way that can be tagged within the text.

An example of this is as follows where the original text intended one thing, but said something different: "Verify that the organization has a compliance policy/procedures". In this sentence, the author intended to say "has a compliance policy and compliance procedures", but they didn’t say that. When the UCF Mapping process encounters these types of intentions and omissions, we add additional text in curly brackets "{ }" in front of the Citation Guidance to show that we are explicitly adding text (in this case, compliance procedures for mapping purposes.

Therefore, this field would look like this: "{compliance proceduers} Verify that the organization has a compliance policy/procedures."

is_audit_questionboolean

This is either a 1 or zero.

Most Citations, about 98% of them, are simple mandates; do this or that, don’t do this or that. We automatically link these Citations to the corresponding Common Control’s Audit Question.

However, there are those 2% Citations that call for the reader to examine something, test something, observe something, or interview someone. Because these Citations are audit questions in and of themselves, we flag the Citation so that the audit or GRC tool can use the actual Citation in place of the corresponding Common Control’s Audit Question.

authority_documententity-reference

This is the ID field for the Authority Document that the Citation originates from.

controlcontrol, optional

This is the record ID of the Common Control that is matched to this Citation.

audit_itemaudit-item, optional

This is the record ID of the Audit Item that is matched to this Citation.

assetasset, optional

If there is an Asset that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Asset.

compliance_documentcompliance-document, optional

If there is an Compliance Document that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Compliance Document.

rolerole, optional

If there is an Role that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Role.

data_contentdata-content, optional

If there is an Data Contents that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Data Contents record.

organizational_functionorganizational-function, optional

If there is an Organizational Function that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Organizational Function.

record_examplerecord-example, optional

If there is a Record Example that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Record Example.

metriccontrol, optional

If there is an Metric that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Metric.

monitored_eventmonitored-event, optional

If there is an Monitored Event that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Monitored Event.

organizational_taskorganizational-task, optional

If there is an Organizational Task that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Organizational Task.

record_categoryrecord-category, optional

If there is a Record Category that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Record Category.

configurable_item_with_settingsconfigurable-item-with-settings, optional

If there is a Configuration Item and associated settings that was tagged as a Named Entity in the Citation’s guidance, this is the record ID for that Configuration Item and associated settings record.

sentenceentity-reference, optional

Internal use only.

parententity-reference, optional

This is the ID of the parent record. It is used for displaying the record in a hierarchy.