METHODS AND SYSTEMS FOR A COMPLIANCE FRAMEWORK DATABASE SCHEMA

Abstract

Generating a compliance framework. The compliance framework facilitates an organization's compliance with multiple authority documents by providing efficient methodologies and refinements to existing technologies, such as providing hierarchical fidelity to the original authority document; separating auditable citations from their context (e.g., prepositions and or informational citations); asset focused citations; SNED and Live values, among others.

Description

CROSS-REFERENCE TO RELATED APPLICATION(S)

The present application is continuation of U.S. patent application Ser. No. 15/794,405, filed on Oct. 26, 2017 and entitled “METHODS AND SYSTEMS FOR A COMPLIANCE FRAMEWORK DATABASE SCHEMA,” which is a divisional of U.S. patent application Ser. No. 14/685,466, filed on Apr. 13, 2015 (now U.S. Pat. No. 9,996,608) and entitled “METHODS AND SYSTEMS FOR A COMPLIANCE FRAMEWORK DATABASE SCHEMA,” which is a continuation of U.S. patent application Ser. No. 13/723,018, filed on Dec. 20, 2012 (now U.S. Pat. No. 9,009,197) and entitled “METHODS AND SYSTEMS FOR A COMPLIANCE FRAMEWORK DATABASE SCHEMA,” which claims the benefit of U.S. Provisional Application No. 61/722,759, filed Nov. 5, 2012 and entitled “METHODS AND SYSTEMS FOR A UNIFIED COMPLIANCE FRAMEWORK DATABASE SCHEMA,” all of which are incorporated herein by reference in their entireties. This application is related to U.S. patent application Ser. No. 13/952,212, filed on Jul. 26, 2013 (now U.S. Pat. No. 8,661,059) and entitled “METHODS AND SYSTEMS FOR A COMPLIANCE FRAMEWORK DATABASE SCHEMA,” and U.S. patent application Ser. No. 16/026,524, filed on Jul. 3, 2018 and entitled “METHODS AND SYSTEMS FOR A COMPLIANCE FRAMEWORK DATABASE SCHEMA,” both of which are incorporated herein by reference in their entireties.

BACKGROUND

Authority Documents (e.g., policies, guidelines, regulations) used for auditing organizations are written for humans. They are commonly written and presented in hierarchical format (e.g., with sections and subsections) as a set of questions intended for the human reader to navigate. Written in a hierarchical format, Authority Documents (ADs) use visual cues to instruct the reader that certain questions in the audit can be ignored. For example, if a person answers “not applicable” to question 1, then common reading skills allow the person to logically skip questions 1.1, 1.2, and so on, moving instead to question 2 in order to continue. Authority Documents are often the basis for an audit to ensure an organization's compliance.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present invention is illustrated by way of example and are not limited to the figures of the accompanying drawings, in which like references indicate similar elements.

FIG. 1 shows an environment of a basic and suitable computer that may employ aspects of the compliance framework.

FIG. 2 shows the various elements within the Meta Data portion of a Compliance framework table.

FIG. 3 shows the process for adding or editing a record and that interaction with the Meta Data.

FIGS. 4A-4B (referred to herein as FIG. 4) show diagrams depicting features of an Authority Document and Authority Document Table.

FIGS. 5A-5C (referred to herein as FIG. 5) are examples of features associated with a Citation Table.

FIGS. 6A-6B (referred to herein as FIG. 6) are examples of features associated with a Record Examples Table.

FIGS. 7A-7B (referred to herein as FIG. 7) are examples of features associated with an Assets Table.

FIG. 8 is an example of features associated with a Configuration Items Settings Table.

FIG. 9 is a simple workflow for mapping an Authority Document and associated Citations.

FIGS. 10A-10B (referred to herein as FIG. 10) depict the mapping process shown in FIG. 9 at a record and linkage level.

FIGS. 11A-11B (referred to herein as FIG. 11) are examples of features associated with a Controls Table.

FIG. 12 is a simple workflow for matching a Citation to a Control through its verbs and nouns.

FIGS. 13A-13B (referred to herein as FIG. 13) depict the matching process shown in FIG. 12 at a record and linkage level.

FIGS. 14A-14B (referred to herein as FIG. 14) are examples of features associated with an Audit Table.

FIG. 15A-15B (referred to herein as FIG. 15) depict connecting a Citation to an Audit Question, and a Control to an Audit Question.

FIG. 16 is a flowchart of a simple process used to map a new or existing Authority Document's citation.

DETAILED DESCRIPTION

The inventors have recognized that current technology has failed to efficiently address parsing a portion of an Authority Document to determine an audit question from its contexts or other text. For example, “Implement firewall and router configuration standards that include the following:” is text from an actual audit guide. This text isn't to be interpreted as an audit question per se. Instead, it is a prepositional placeholder for text that follows so that each following citation, when displayed, doesn't have to contain “do the firewall standards include . . . ”. For purposes of asking audit questions, the prepositional placeholder can be ignored; however, for purposes of displaying it in Reports of Compliance, it cannot be ignored.

In a similar manner, instructions within an audit question regarding how to attach certain evidence to the working papers of the audit process may readily be understood by a person. For example, an instruction such as, “obtain document X and compare it to record Y—are they are the same?” can be interpreted by a person to mean: add both documents to the working papers library of this audit and compare them for their similarities; however, a computer cannot interpret what to do without further instructions.

When an edited version of an audit guide is distributed for reading, the edited version can include common editing symbols and methodologies, such as strikethrough to show deleted text (e.g., text) and underline to show new text (e.g., new text). A person trained to understand these symbols may readily read and interpret changes between different versions of the same document. However, computer audit tools, such as Governance Risk and Compliance (GRC) tools, that utilize these guides must be given explicit instructions to do all of the above.

The inventors have recognized that a problem with existing technology is a lack of harmonized governance processes to support an organization's efforts in gathering evidentiary support when being audited. A compliance framework tool is described herein that allows an organization to efficiently navigate through myriad overlapping policies, guidelines, regulations, etc. to locate evidence for use in an audit, based on questions derived from a hierarchy of citations from authority documents applicable to the organization's environment.

In some embodiments, the compliance framework provides systems and methods of a unified compliance framework for generating audit-based questions based on citations that are derived from an aggregation of hierarchical formatted authority documents. For example, the compliance framework can convert hierarchical information (e.g., structured citations and their corresponding content from the authority documents) into a modular format (e.g., markup language, such as XML) for integrating into a variety of existing and emerging operating environments (e.g., various database techniques, schemas and methodologies) used by an organization.

Various embodiments of the technology are described below. The following description provides specific details for a thorough understanding and enabling description of these embodiments. One skilled in the art will understand that the compliance framework may be practiced without many of these details. Additionally, some well-known structures or functions may not be shown or described in detail, so as to avoid unnecessarily obscuring the relevant description of the various embodiments. Certain aspects of this technology relate to U.S. Provisional Application No. 61/722,759, which is incorporated herein in its entirety by reference.

The terminology used in the description presented is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the technology. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

The techniques introduced below can be implemented by programmable circuitry programmed or configured by software and/or firmware, or entirely by special-purpose circuitry, or in a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.

FIG. 1 and the following discussion provide a brief, general description of a suitable computing environment in which aspects of the compliance framework can be implemented. Although not required, aspects of the technology may be described herein in the general context of computer-executable instructions, such as routines executed by a general or special-purpose data processing device (e.g., a server or client computer). Aspects of the technology described herein may be stored or distributed on tangible computer-readable media, including magnetically or optically readable computer discs, hard-wired or preprogrammed chips (e.g., EEPROM semiconductor chips), nanotechnology memory, biological memory, or other data storage media. Alternatively, computer-implemented instructions, data structures, screen displays, and other data related to the technology may be distributed over the Internet or over other networks (including wireless networks) on a propagated signal on a propagation medium (e.g., an electromagnetic wave, a sound wave) over a period of time. In some implementations, the data may be provided on any analog or digital network (packet switched, circuit switched, or other scheme).

The compliance framework can also be practiced in distributed computing environments where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a Local Area Network (LAN), Wide Area Network (WAN), or the Internet. In a distributed computing environment, program modules or sub-routines may be located in both local and remote memory storage devices. Those skilled in the relevant art will recognize that portions of the compliance framework may reside on a server computer, while corresponding portions reside on a client computer (e.g., PC, mobile computer, tablet, or smart phone). Data structures and transmission of data particular to aspects of the technology are also encompassed within the scope of the compliance framework.

Referring to FIG. 1, the compliance framework employs a computer (100), such as a personal computer, workstation, phone or tablet, having one or more processors (101) coupled to one or more user input devices (102) and data storage devices (104). The computer (100) is also coupled to at least one output device such as a display device (106) and one or more optional additional output devices (108) (e.g., printer, plotter, speakers, tactile or olfactory output devices). The computer (100) may be coupled to external computers, such as via an optional network connection (110), a wireless transceiver (112), or both. For example, network hubs, switches, routers, or other hardware network components within the network connection (110) and/or wireless transceiver (112) can couple one or more computers (100).

The input devices (102) may include a keyboard and/or a pointing device such as a mouse. Other input devices are possible, such as a microphone, joystick, pen, game pad, scanner, digital camera, video camera, and the like. The data storage devices (104) may include any type of computer-readable media that can store data accessible by the computer (100), such as magnetic hard and floppy disk drives, optical disk drives, magnetic cassettes, tape drives, flash memory cards, digital video discs (DVDs), Bernoulli cartridges, RAMs, ROMs, smart cards, etc. Indeed, any medium for storing or transmitting computer-readable instructions and data may be employed, including a connection port to or node on a network, such as a LAN, WAN, or the Internet (not shown in FIG. 1).

Compliance Framework

The compliance framework is a framework to make implementing, testing, managing and or monitoring audit questions easier and more rigorous. In one embodiment, database tables associate portions of a modular data (e.g., Meta Data, basic information; and references); however, other techniques capable of organizing referential data have been contemplated by the inventors.

Compliance Framework Meta Data

In one embodiment, the compliance framework (CF) uses a set of tables presented in a hierarchical-based markup language (e.g., XML) to facilitate ease of integration. Each row of a table organizes the table into individual records (215) that may include Meta Data, custom content, and possible references to other tables. The common Meta Data format and content of each row is used by GRC tools and other data driven applications to interpret what to do with each of the records in the table. The standard and optional elements of the Meta Data elements of each table are further described below.

FIG. 2 illustrates example Meta Data elements (201-213) of a compliance framework table (200). Each record (215) of each table (e.g., (200)) in the CF is associated with a unique and persistent identifier. For example, Citation ID column (202) has unique and persistent identifiers (e.g.; “39307,” “39311,” 32431,” etc.) for each respective record (215) in the table (200) (see also, FIG. 5). Other tables in the CF have unique and persistent identifiers associated with each record in their respective tables. The Release Version (201) is used to indicate the table's release date. To ensure that the Citation IDs (202) have integrity during input as well as distribution while being transferred into various formats (e.g., Excel, Word, Text, and or XML), in one embodiment, each Citation ID (202) is associated to a checksum value (203).

The compliance framework treats each Citation ID (202) as both unique and persistent, A Citation ID (202), in some embodiments, is maintained and or persistent within a database or other retention system. Therefore, if a record (215) must be redacted, its Live Status (204) is changed from a first value (e.g., “1”) to indicate a live record (220) to a second value (e.g.; “0”) that indicates a withdrawn record (222). A SNED element (205) indicates an editorial status of a record (215). SNED stands for Same, New, Edited and Deprecated. To calculate a SNED element value, a checksum is created (not shown) for each record (215) based on the fields' contents in that record (215). For example, upon each new release of a record (215), values in the current release's checksum are compared to checksum values in the previous record's (215) release. If the two checksum values are the same, the result is “S” (230); if there is no previous checksum value; the result is “N” (234); if the current checksum does not match the previous, the result is “E” (232); if the current checksum's first digit is 0 and the previous release was 1, the result is “D,” (236) for example. The Citation Date Added (206) element indicates the date the record (215) was added. The Citation Date Modified (207) element indicates the date the record (215) was last modified. If the record (215) is deprecated, the Deprecated By (208) element indicates the surviving record's ID (240). The Deprecation Notes (209) element indicates why (242) the record (215) was deprecated. The language used in the record (215) is indicated in (212). If a record (215) is licensed outside of the normal compliance framework licensing scheme, for example, a License Info (213) URL (or other indicator and or description) may be used to indicate a location for additional information.

For tables that must be presented in hierarchical order, as opposed to a flat document, each record (215) with a Parent ID (210) and Sort Value (211) are used to indicate a record's (215) location within the hierarchy. These two elements (210 and 211) present sufficient information for an interpreting application and or tool to create its own unique sort order for the records (215) in the table (200). Every Meta Data element (201-213) is not required to implement a compliance framework. One or more of the Meta Data elements (201-213) can be associated with the Unified Framework Table (200). This also applies to other tables in the CF.

FIG. 3 illustrates an example process (300) to add or update a record (215) in or to the compliance framework and to the associated Meta Data records, as discussed in the description for FIG. 4. An initial decision is made to add or update a record (215), in step (301), based on whether the record already exists in the UFC. In one embodiment, if the record is being added, the SNED value is assigned an N (302), the Date Added field indicates when the record (215) is added to the UFC, in (303), the Live Status (204) is set to 1 to indicate that the record (215) is current (304), and the record (215) is created, in step (305). In one embodiment, if the record (215) is being updated (i.e., not added), a decision is made to edit or delete the record, in step (306). If the record is deleted, the SNED value is set to D (307), and Date Modified (207) is added (308), and the Live Status (204) of the record (215) is set to 0 to indicate the record has been edited, in step (309). If the record (215) is updated, in some embodiments, the SNED value (204) is set to E to indicate the record (215) has been edited, in step (310), the Date Modified (207) date is updated (311), and the record (215) is edited, in step (312).

Compliance Framework Tables

A combination of one or more of the disclosed technologies allows for efficiencies in preparing, sorting, presenting and or gathering evidence for an audit. Each of the above-mentioned features of the compliance framework is further described below. One or more of the elements described in the forthcoming tables may be optionally excluded in the CF while other elements have been contemplated by the inventors and can be added to one or more of the forthcoming tables.

FIG. 4 illustrates an Authority Document Table (400). FIG. 4 depicts the Authority Document Table (400) as multiple portions, including Meta Data (400a) (e.g., having one or more elements 201-213 of Meta Data portion (200) and Basic Info (400b). The Meta Data portion (400a) and the Basic Info portion (400b) are separated into two these portions (e.g., tables), however, this is an aid for the view. The inventors contemplate that the Meta Data portion (400a) and the Basic Info Table are implemented as a single table. The Basic Info (400b) of Authority Document Table (400) contains elements (403-415) for organizing the ADs into a library (not shown) having the AD's Parent Category (403) (e.g., payment card guidance); Originator (404) (e.g., the Payment Card Industry); Type (405) (e.g., a contractual obligation); and Title Type (406) (e.g., Authority Document (AD) (i.e, a document with controls), or Glossary (GL) (i.e. an AD without controls). Controls are explained in more detail below. The Universal Resource Locator (URL) (407) denotes where the Authority Document was found (e.g., at a website), however, other indicators and or descriptions can be used.

Naming information (412) of an Authority Document may include a Common Name (408) (i.e., what the AD is commonly referred as); Published Name (409); and Version (410), which together form the Official Name (411).

The Authority Document's Availability (413) Effective Date (414) and a calculated description (415) are optionally included in the Authority Document Table (400) to denote additional information.

FIG. 5 shows one example of a Citation Table (500) that is capable of implementing features of the compliance framework. The Citation Table (500), in some embodiments, has three parts; Meta Data (500a); Basic Info (500b); and associated References (500c). Meta Data (500a) is similar to Meta Data (200), therefore, to simplify the description for FIG. 5, a detailed description of Meta Data (500a) is not included as part of the description for FIG. 5.

The Basic Info (500b) of a citation may contain Citation Reference (503) and a Citation Guidance (504). In one embodiment, a Citation Reference (503) represents a section (e.g., § 1.1.1) of an AD. Citation Guidance elements (504) represents the content associated with the Citation Reference (503). In some embodiments, the Citation Guidance (504) is examined, by the CF, for their verbs and nouns. The nouns within each row of the Citation Guidance (504) are used to reference potential evidence for the compliance framework. For example, Citation ID 32431 (550a) refers to Citation Guidance entry (550b) which states, “Verify that there is a formal process for testing and approval of all network connections and firewall configurations. “The noun “router configurations” is identified and linked to a specific Record Example (e.g., “21”) (550c) and Asset ID “669” (580). Record Examples are explained in more detail in reference to FIG. 6. In another instance, the Citation ID “32436” (570a) refers to Citation Guidance (570b) “Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone. “The noun “firewall configuration standard” is identified and can be linked to a specific Compliance Document (e.g., “106”) (570c) and the noun “firewall” may be identified and linked to a specific Asset (e.g., “1524”) (570d).

In some embodiments a single citation contains more than one noun. For example, Citation ID 32431 (i.e., “§ 1.1.1 Testing Procedures”) describes both “router configurations” (mentioned above) and, additionally, “firewall configurations.” The noun “router configurations” is identified and linked to Record Example (e.g., “21”) (550c) and to Asset ID “669” (580a), for example, and the noun “firewall configurations” is linked to the same Record Example (e.g., “21”) (550c) but a different Asset (e.g., “1524”) (580b), which is the same Asset “1524” associated with the “firewall” noun in Citation ID “32436” (570a).

Nouns, in some embodiments, are maintained in external tables suited to define each type of noun. Example noun tables include Assets, Configuration Items, Roles, Events, Metrics, Organizational Functions, Organizational Tasks, Record Category; Record Examples, Data Field, and cDocs, among others.

FIG. 6 illustrates an example Record Examples Table (600) that contains information specific to nouns that are records. FIG. 6 depicts the Record Examples table (600) into a Meta Data portion (600a) and Basic Info portion (600b).

The Meta Data portion (600a) is explained in more detail in FIG. 2 and in other tables, therefore, for simplification its features are not described in detail in FIG. 6. The Basic Info portion (600b) for a record example may include, among other things, the Record Example Name (605), Record Example Retention Years (608) (e.g., “hold for 5 years,” etc.); Record Example Description (606); and a Record Example Retention Event (607) (e.g., “after the contract is closed,” “when the case opens,” etc.). In other embodiments, one or more of 605-608 are optional.

FIG. 7 illustrates an Asset Table (700) that contains information specific to nouns that are assets (e.g., routers, firewalls, etc.). FIG. 7 depicts the Asset table (700) as having a Meta Data portion (700a) and Basic Info portion (700b). The Basic Info (700b) of an asset may include, in some embodiments, the Asset's Category (703) (e.g., networks, applications, hardware, facilities,_[DC1] etc.); Asset Class (704); (e.g., a subcategory of Asset category (703); Asset Type (705); Asset Name (706); Asset Common Name (707); Asset Version (708); Asset Platform (709) (e.g., 32 bit processor; 63 bit processor, INTEL, AMD, etc._[DC2]); and Asset Update information (710) (e.g., the update's version information, such as “Revision 42a, patch 15B, etc._[DC3]).

FIG. 8 illustrates the Configuration Items Settings Table (800) that contains information specific to nouns that are configurations settings (e.g., “deny all traffic if ‘X’ occurs”). FIG. 8 depicts the Configuration Items Setting Table (800) as having a Meta Data portion (800a) and Basic Info portion (800b). The Basic Info portion (800b) contains information specific to nouns that define a Configuration Item (804) (e.g., “Rules Configuration settings”) and its Settings (805) (e.g., “deny all traffic unless explicitly allowed”).

FIG. 9 is a flowchart (900) showing how the CF adds a citation from an Authority Document and then links the nouns in the record to citation's Citation Guidance (504), as discussed above. When a new Authority Document is added to the compliance framework, its relevant information (e.g. one or more elements 403-415 of FIG. 4, for example) is assembled into the Authority Document's record, in step (902), and added to a, optional, database, in step (903). In some embodiments, once an AD ID (202) for a new Authority Document is identified, one or more new citation references can be added and linked to the AD's ID (202), in step (904). For example, as previously discussed, verbs and nouns can be defined within a citation (905) and linked to their corresponding records in appropriate tables, as processed in step (906). Citation Guidance (504) may contain one or more nouns. When a citation has more than a signal noun, each noun can be treated separate from other nouns in the citation (i.e, each noun is linked to a corresponding record in an appropriate table (906)), as further described in the description for FIG. 10.

FIG. 10 depicts the process of FIG. 9 at a record level. An Authority Document record, (e.g., having AD ID of 1071 (1050), has record information (1010a) associated with its corresponding Meta Data (450a), and Basic Info (450b) and any references and or additional information (not shown). A new Citation, having Citation ID ‘32431’ (1060), for example, is created with its corresponding information (1010b), such as its Meta Data (500a) and Basic Info (500b). A reference (1003) between the new Citation, (i.e., Citation ID ‘32431’ (1060)) and the existing Authority Document (i.e., AD ID 1071 (1050)) is linked together (1003) (i.e., a logical connection is made). In some embodiments, once the citation is created, its nouns are examined and associated (linked) to Record Example Tables (600). For example, the noun “network connections” (1070) found within Citation Guidance “Verify that there is a formal process for testing and approval of all network connections and firewall change requests” (1080), is linked (1005) to the Record Example Name “Network Change Control Requests” (1082) of Record Example (1010c) to form a connection between the two records (1010b) and (1010c). In some embodiments, more than one noun is in a single citation. For example, in the above example “network connections” and “firewall change control requests” are each present in the Citation Guidance (1080). In this scenario, “network connections” is linked as described above. In addition, “firewall change request,” in some embodiments, is separately linked to the same or other Record Example Table(s) (600).

A process similar to the process of FIGS. 9-10 is also applicable to nouns of other assets. For example, the process described in FIG. 9 can be used for Configuration Items, Roles, Events, Metrics, Organizational Functions, organizational tasks, record category, record example, data field, and cDocs.

FIG. 11 depicts example features of a Controls Table (1100). Table 1100 has at least Meta Data Information (1100a) and Basic Information (1100b). Controls are harmonized, or de-duplicated noun/verb pairs that originate from citations. The Basic Info (1100b) for Controls are the Control Title (i.e., a harmonized, or de-duplicated noun/verb pairs that originate from Citations) (1120); an Impact Zone categorization (i.e., the category affected by the harmonized control) of the Control (1105); the Classification for the Control (1106); and a Control's action Type (1107).

FIG. 12 is a flowchart (1200) showing how the CF maps citations to existing Controls, or creates new Controls if a citation is not matched. Initially, a citation's verbs and nouns are reviewed (1201) and then searched for in one or more Controls, in step (1202). If there is a Verb/Noun match (1203), the process flows to connect the Citation to a Control (1204). This noun matching is shown at the record level in FIG. 13.

In FIG. 13, Citation Guidance, “Verify that there is a formal process for testing and approval of all Network connections and change requests to firewall and router configurations,” (1350a) of citation record (1320a), is linked (1304) to Control record (1320b) based on at least one citation record (1320a) having the same Record Example ID 21 (1310a-b). Control record (1320b) having Control Title, “Test and Approve all firewall configuration Changes,” (1350b) is linked (1305) to the same noun/Record Example (1320c) based on their shared value for Record Example Id (i.e., 21). In some embodiments, a bridged connection (1304) links the Citation Record (1320a) and the Control Record (1320b), which corresponds to step (1208) of FIG. 12.

Returning to FIG. 12, in some embodiments, had there not been a Verb/Noun bridge between the citation (1320a) and the Control (1320c), the flow would have proceeded to step (1205). In this scenario, a new Control can be created, at step (1205), based upon the language found in the Citation. The Control's nouns and verbs can be linked, at step (1206) and (1207), to their respective tables The process ends at step (1210).

Auditing Compliance

In order to test an organization's compliance to the various Authority Documents and their Citations, the compliance framework, in some embodiments, synthesizes one or more Citation Statement into an Audit Question. Within the compliance framework Audit Questions follow the same Meta Data (e.g. 200), Basic Info (e.g. 450b), and references (e.g. 500c) format as the other previously described tables.

FIG. 14 depicts one example of an Audit Table (1400) that is capable of implementing features of the compliance framework. FIG. 14 illustrates the Audit Table depicted as three main parts: Meta Data (1400a), Basic Info (1400b) and associated References (1400c).

Audit Questions are a pairing of evidence and examination methods. The compliance framework creates an Audit Question (1405) based upon one or more of, a linguistic calculation of an examination method (1406), evidence associated with the Audit Question (e.g. information in References 1400c), and any agreed upon variables to the question (1407). An example of an Audit Question Method (1405) is “Examine the Control in the cDoc as compared to Records in the Record Category. Does this define how the control process is being carried out?” (1450), paired with a cDoc ID 30 (1451), a Control ID 548 (1452), a Record Category ID 211 (1453), and a Record Example ID 21 (1454). The compliance framework's methodology can identify the text from the relevant IDs (1451-1454) and replace placeholder terms (e.g. Control, cDoc, Records, and Record Category) with the text matching each relevant ID. The resultant Audit Item Question (1405) can be “Examine the control entitled Test and approve all firewall configuration changes [CF CE ID 00548] in the Network Change Management policy as compared to Network Change Control Requests records in the Network Management and Maintenance Records record category. Does this define how the control process is being carried out?” (1480).

FIG. 15 is a depiction of linking a Citation Record (1501) and a Control Record (1504) to an Audit Question (1510) of an Audit Record (1502). A Citation Record (1501) is linked (1503) to an Audit Question (1510) based on each record sharing the same Audit Item ID (e.g., 3443). Each Control Record (1504) is linked (1505) to that Audit Question (1510), based on each sharing the same Control Example ID (e.g. 548). Linking allows different Citations (1501) from different Authority Documents that map to the same Control (1504) to use the same Audit Question (1510) if the evidential nouns match, for example.

FIG. 16 is a flowchart (1600) showing how the CF is used to map a new or existing Authority Document's Citation(s). Once a new Authority Document is mapped, in step (1601), the compliance framework can determine whether the Authority Document is new or an update to an existing Authority Document, in step (1602). If the Authority Document is new to the compliance framework, the Authority Document can be reviewed for its applicable categories (e.g., Payment Guidance; AIPLA; Government Compliancy Statue) (1603). If the category exists in the Authority Document Table, that category is selected (1604). Following this, a new category record is created and selected (1605). If the originator of the Authority Document exists (1606), that originator is selected (1607), otherwise a new originator record is created and selected (1608). At step 1609, a new Authority Document record can be created in the Authority Document Table (1616) and, based at least on some of the selected information, a new Authority Document is created (1610). Citations are then mapped to the new Authority Document (1611) and the process ends at step 1650.

If, during step 1602, it is determined that the Authority Document is an update to an existing Authority Document, the existing Authority Document is selected, step (1612), and its version information is updated to indicate a new version (1613). A new record for the new Authority Document is created in the Authority Document Table, and optionally sorted relative to the placement of the preview version of the Authority Document (1614). At step 1615, citations are mapped to the new Authority Document. Step 1616, indicates that the previous (e.g., the original) Authority Document is deprecated based on the updated Authority Document. In some embodiments, all of the citations associated with the previous version of the Authority Document are marked for deprecations (1617). The process ends at step 1650.

The compliance framework describes a unified compliance framework for facilitating an organization's compliance with multiple authority documents by providing efficient methodologies and refinements to existing technologies, such as providing hierarchical fidelity to the original Authority Document; separating auditable citations from their context (e.g., prepositions and or informational citations); asset focused citations; and SNED and Live values, among others.

In general, the detailed description of embodiments of the compliance framework is not intended to be exhaustive or to limit the technology to the precise form disclosed above. While specific embodiments of, and examples for, the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the compliance framework, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed at different times.

The teachings of the compliance framework provided herein can be applied to other systems, not necessarily the system described herein. The elements and acts of the various embodiments described herein can be combined to provide further embodiments.

These and other changes can be made to the compliance framework in light of the above Detailed Description. While the above description details certain embodiments of the technology and describes the best mode contemplated, no matter how detailed the above appears in text, the compliance framework can be practiced in many ways. The compliance framework may vary considerably in its implementation details, while still being encompassed by the technology disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the compliance framework should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the technology with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the compliance framework to the specific embodiments disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the compliance framework encompasses not only the disclosed embodiments, but also all equivalent ways of practicing or implementing the compliance framework.

Claims

1-18. (canceled)

19. A computer-readable medium storing a citation data structure, the data structure comprising a plurality of elements, each element corresponding to a different authority document portion, each element comprising:

first information identifying an authority document containing the authority document portion to which the element corresponds;

second information identifying within the authority document identified by the element the authority document portion to which the element corresponds, the authority document portion to which the element corresponds describing a compliance requirement; and

third information identifying one or more portions of one or more authority documents that describe a compliance requirement that is related to the compliance requirement described by the authority document portion to which the element corresponds.

20. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the first information is a title of the authority document containing the authority document portion to which the element corresponds.

21. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the first information is a reference to the authority document containing the authority document portion to which the element corresponds.

22. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the first information is a URL usable to retrieve the authority document containing the authority document portion to which the element corresponds.

23. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the first information is a unique identifier separately mapped to information usable to access the authority document containing the authority document portion to which the element corresponds.

24. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the second information is a position within the authority document identified by the element at which the authority document portion to which the element corresponds occurs.

25. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the second information is a section number within the authority document identified by the element in which the authority document portion to which the element corresponds occurs.

26. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the second information is a copy of the authority document portion.

27. The computer-readable medium of claim 19 wherein the one or more portions of the one or more authority documents identified by the third information each describe a requirement that is equivalent to the requirement described by the authority document portion to which the element corresponds.

28. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the third information, for each of the one or more portions of the one or more authority documents, directly contains a reference to the portion of the authority document.

29. The computer-readable medium of claim 19 wherein, across a group of two or more entries corresponding to different authority document portions, the third information comprises the same control identifier.

30. The computer-readable medium of claim 19 wherein, across a group of two or more entries corresponding to different authority document portions, the third information identifies the same noun-verb pair.

31. The computer-readable medium of claim 19 wherein, across a group of two or more entries corresponding to different authority document portions, the third information identifies equivalent noun-verb pairs.

32. The computer-readable medium of claim 19 wherein, across a group of two or more entries corresponding to different authority document portions, the third information identifies matching nouns and matching verbs.

33. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the authority document portion identified by the third information is in the authority document identified by the first information.

34. The computer-readable medium of claim 19 wherein, for each of at least one of the elements, the authority document portion identified by the third information is in an authority document other than the authority document identified by the first information.

35. A hardware networking component that conveys a citation data structure, the data structure comprising a plurality of elements, each element corresponding to a different authority document portion, each element comprising:

first information identifying an authority document containing the authority document portion to which the element corresponds;

second information identifying within the authority document identified by the element the authority document portion to which the element corresponds, the authority document portion to which the element corresponds describing a compliance requirement; and

third information identifying one or more portions of one or more authority documents that describe a compliance requirement that is related to the compliance requirement described by the authority document portion to which the element corresponds.

36. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the first information is a title of the authority document containing the authority document portion to which the element corresponds.

37. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the first information is a reference to the authority document containing the authority document portion to which the element corresponds.

38. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the first information is a URL usable to retrieve the authority document containing the authority document portion to which the element corresponds.

39. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the first information is a unique identifier separately mapped to information usable to access the authority document containing the authority document portion to which the element corresponds.

40. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the second information is a position within the authority document identified by the element at which the authority document portion to which the element corresponds occurs.

41. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the second information is a section number within the authority document identified by the element in which the authority document portion to which the element corresponds occurs.

42. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the second information is a copy of the authority document portion.

43. The hardware networking component of claim 35 wherein the one or more portions of the one or more authority documents identified by the third information each describe a requirement that is equivalent to the requirement described by the authority document portion to which the element corresponds.

44. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the third information, for each of the one or more portions of the one or more authority documents, directly contains a reference to the portion of the authority document.

45. The hardware networking component of claim 35 wherein, across a group of two or more entries corresponding to different authority document portions, the third information comprises the same control identifier.

46. The hardware networking component of claim 35 wherein, across a group of two or more entries corresponding to different authority document portions, the third information identifies the same noun-verb pair.

47. The hardware networking component of claim 35 wherein, across a group of two or more entries corresponding to different authority document portions, the third information identifies equivalent noun-verb pairs.

48. The hardware networking component of claim 35 wherein, across a group of two or more entries corresponding to different authority document portions, the third information identifies matching nouns and matching verbs.

49. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the authority document portion identified by the third information is in the authority document identified by the first information.

50. The hardware networking component of claim 35 wherein, for each of at least one of the elements, the authority document portion identified by the third information is in an authority document other than the authority document identified by the first information.

51. A method in a computing system comprising:

accessing a set of requirements each described by a portion of one of a set of one or more authority documents;

accessing a distinguished authority document not among the set of authority documents;

identifying a portion of the distinguished authority document describing a requirement;

adding requirement described by the identified portion of the distinguished authority document to the set of requirements;

selecting two or more requirements in the set of requirements that are equivalent, the selected requirements including the added requirement; and

establishing connections among the selected requirements in the set.