The table below provides a description of the worksheets available within the Governance Portal and the actions that may be completed with each worksheet.

Each worksheet within the utility includes two standard fields and additional fields based on the object (e.g. risk description, risk significance, control type etc.). The Action Field and the Entity Id are required for all worksheets. The action field identifies the process that will be taken on the data (e.g. create, update, move or delete). The Entity Id is a system assigned number. To locate this number, execute the Org Unit and Processes search available through the RCM Content Utility Searches sub tab.

All fields within each worksheet are color coded to assist users in completing the utility.

Red - Required fields

Orange - Optional fields

Green - Required fields when utilizing the move action

Blue - Used for RCM Template import only (may be required or optional)

Purple - Required for acton plans generated from assessment surveys.

Gray - For user information only - not read by the application

Key Implementation Considerations

• Maximum Character Values - Object Name (i.e., Objectives, Risks, Controls and Tests) have predefined character limits. For example, Control and Risk names are truncated at 250 characters. As such, a short name should be considered for key controls or risks associated to key controls. For your reference, a listing of all fields and associate maximum character values is provided on the “Tab and Fields Descriptions” tab of the content utility spreadsheet.
• Duplicates - The first step in the data conversion process is the removal of unnecessary duplicate values. Occasionally, records can be double entered or values can be repeated (due to human error, different abbreviations, etc.). Duplicates should be identified by sorting through the data and then carefully removed.
• Accuracy - In systems that have been in operation for several years, data can often become corrupted or inaccurate over time. By scanning carefully through the data, it is possible that all of the records are valid and current. If there is data present that is no longer needed, remove it from the system. If there is data present that is inaccurate or not current, update it accordingly. Only current and accurate data should be uploaded into the new system.
• Spelling - Spell-checking is a simple step that is often overlooked. If possible, run an automated spell-checker on the data to identify and correct spelling mistakes. If the data cannot be spell-checked in the host system, spell-check it once it has been extracted, using Excel or similar.
• Spacing - In addition to spelling and accuracy, spaces in words or values are interpreted like any other character in the system. Therefore, it is especially important to remove additional or erroneous spaces from data. For example, a frequency value of “Weekly” is seen as something completely different and distinct from “Weekly ” (with the trailing space at the end), even though they may look similar. Spaces are often hard to spot, and generate duplicate values that could be overlooked. When data is uploaded, the system (actually SQL) automatically cleans trailing spaces and double spaces between words. This can be problematic when attempting to link data through the utility. The reason? When the data is uploaded, the erroneous spaces are removed, but they still may exist within the Excel spreadsheet when attempting to link two data objects together. Thus, when attempting to create the linkage, the system is unable to recognize the values to be linked since there is no longer a corresponding name in the system. BEFORE uploading data, all trailing and double spaces should be cleaned from the Excel spreadsheets by using the TRIM function.
• Special Characters
  • In a similar way to spacing, special characters can also affect the uniqueness of values, and therefore need to be used consistently. For example, “ACME & Co” is different from “ACME and Co”. Additionally, the placement of special characters in a value can cause issues. Be careful to check the placement and consistent usage of dashes “-”, colons “:”, periods “.”, etc.
• Naming Conventions - The collective standards that are generated as a result of these previous steps are known as naming conventions. Once the data has been fully cleansed in the host system, there should be a set of obvious and consistent naming conventions in place for Risks, Controls and Tests.
• Completeness - If extracting data from Access to Excel or copying sheets from Excel to Excel, data may be truncated at 255 characters. Review that your extraction or copy method is not truncating data at 255 characters. Also by determining the population of your source data (i.e., total number of objectives, risks, controls and tests) you can ensure that the complete population of data is uploaded.
• Frameworks Match - The Entity ID and Entity Name listed on the spreadsheets must represent valid values that currently exist in the system. This information is most easily and accurately obtained from the Entity Search.
• Formatting for Database Upload
  • Preparing the upload requires that data be entered in a flat file where each potential system linkage represents a single record in the system. When data has been historically captured via spreadsheets, there are often merged cells as well as rows that actually represent multiple database records. It is important to unmerge cells and also create distinct records for each record. Example:
  • Spreadsheet templates often capture assertions by placing them in columns with X marks as shown below.
  • Spreadsheet templates often merge data together in cells as outlined below where one risk is linked to two rows.

    

  • In the above example, the data provided actually represents 4 records. Before uploading, the data needs to be represented as individual records as shown below: