As I mentioned in the RSCA Methodology overview, there are many tools on the market to help you perform tracking and reporting for regulatory compliance. I strongly suggest you invest in one of these tools and share it with your Internal Audit, SOx Audit and IT Compliance organizations. Having a single source for your tracking and reporting needs saves a great deal of time, and will cut down on the miscommunications between these organizations.
Most audit software companies have tools that will track all these data types and more. They also provide multi-user authenticated signon where project leaders and managers who own actions plans can update their the status of their assigned remediation items directly.
If however, your organization simply cannot afford these tools, you can perform the tracking and reporting through a manual process using MS Excel spreadsheets. If that’s the method you chose, there are specific data types to keep track of.
Tracking Considerations
Some things to keep in mind for your tracking efforts manually or with a tool.
Versioning
Versioning is an important component of RSCA. If you’re not using a tool that can retain chronological status changes, then creating report versions will be important. If you’re using a manual mechanism, you can perform this by renaming your spreadsheet at the end of each cycle or after a major change to the data. Something as simple as IT RSCA Report v-201403.xls can do the trick.
Open vs Completed
You should be able to track and report on currently open deficiencies, as well as, completed or reconciled deficiencies. If you’re using a manual method to track RSCA, use multiple sheets within a single file to do this. Open deficiencies on one tab, that can be moved to closed deficiencies on another sheet.
Historical Reconciliation
You should never just delete a line item in your RSCA report. If you have a duplicate item that you want to merge with another finding, then move the duplicate to the reconciled sheet and note the reason. Don’t “close” it, just label it as duplicate and identify which deficiency it is being addressed by. I’ve also seen some companies create a third sheet within the xls file called Duplicates.
RSCA Oversight
If you’re using a tool to track your remediation efforts, you should be able to assign various security roles. The Internal Audit, SOx Audit and IT Compliance (ITC) group should be the only ones who can create a finding or deficiency. This gives you better control over your remediation efforts. Owners should be able to add and update action plans, and provide status for those actions. If you’re going to allow managers to update the Due dates for each action plan, then make sure you can implement a version control on that date. Self-identified findings should be reported to your ITC group so they can add it to RSCA.
If you’re using a manual method to manage RSCA, assign the task to a member of your IT Compliance organization and identify a back up for that person. Don’t allow all the owners to update the controlled source of the report. Instead provide them a copy of the report and require their updates to be made in the copy. Your ITC administrator can then take those updates and apply them as needed to the controlled source.
RSCA Security
Keep in mind this data is going to be your risk tracking tool. Decisions will be made based on the information contained in this system that will affect budgets, strategies and in-scope applications, if not your entire IT business. Because of the sensitivity of this information, and how they’re used for compliance reporting, these types of tools/packages are often considered to be in-scope for SOx review/testing.
Basically, you are putting all your “Risk” into one database. Anyone who has access to this database knows all the holes and weaknesses of your IT environment. Since that information can be utilized to hack into those environments and potentially cause additional risks to the in-scope applications; the security of this data would also be considered sensitive and in-scope for SOx controls.
Proposed Tracking List
The following is a list of information / data to keep track of:
Priority | Assign a level of importance to the deficiency. How quickly should it be remediated? Is it High, Medium or Low Risk. |
ITC Number | This is your IT Compliance group number.. |
Audit Numbers | This is the identifier assigned to each deficiency by an assessing agency. You may have more than one agency deficiency within an IT Remediation. In other words, your SOx department might find a deficiency that is also found in an Internal Audit finding. Both findings require the same remediation to close the issue. Instead of reporting on 2 items, you can combine findings into 1 ITC Remediation initiative. |
Deficiency Type | This identifies what organization noted the deficiency. For instance, was it self identified, or identified by Internal Audit? This comes in handy when multiple organizations identify the same deficiency. It also helps with those organizations who have multiple external assessment agencies, such the Payment Card Industry, American Express, OFEHO, JP Morgan Chase and so on. Because you’ll have to report back to those groups when the item has been resolved. |
Deficiency Description | This should be the exact wording of the deficiency provided by the assessment agency. This is a summary of the deficiency, not the detailed finding. Details should be noted in an Audit report not here in the RSCA tracking report. Remember this is just for tracking purposes; but you want to provide enough information in the summary of the finding to provide understanding of the deficiency. |
Category | It’s helpful to categorize your deficiencies. Are they Security, Change Management, Incident Management or some other process related item. You can use the categories to map the deficiencies to a COBiT process for reporting purposes. |
Related Application | Here you can specify what application or area of IT support services this deficiency is related to. Is it the ABC Application, Network Operations, Lan Security or some other infrastructure department in your IT organization. |
Process Owner | This should be the manager of the process that the deficiency is affecting. This can be a Business Unit Manager, or an IT Manager. You may also want to identify a backup or subject matter expert (SME) for an additional contact. |
IT Owner | This is the responsible IT Manager and their SME. These two contact identifications (Process and IT Owners) can be the same people. |
Action Plan Number | This is a 3 character number to track the steps for remediation of your deficiency. You may have one, or 100, depending on the depth of the deficiency. Breaking down the remediation into action plans helps you track the progress of the individual components of the process. It also helps you to assign tasks to other areas that may need to be completed before the group who owns the overall deficiency can complete their remediation work. |
Action Plan Description | This is the remediation plan for the deficiency, or the individual action plan within the deficiency. This is what the owner will do to remediate the finding. |
Scheduled Due Date | This is the target date for remediation of this action plan. |
Status | This is a status for the action plan. Is it in progress, under review, has a closure package been sent to Audit or the SOx group for review and testing, or is it in a critical state, late and over due? Or has the item been closed for this reporting cycle? |
Status Date | This is the date of the current status provided to management about the action plan efforts. |
Status Description | This is a summary of the action plan remediation effort. What has been done, what needs to be done and what issues need to be addressed. |
As you’re creating your status data keep in mind that single point of failure is a risk to the company. That includes having only one person listed as the contact, is a single point of failure.
Monthly RSCA Meetings
Your meetings with the managers on the report, their Directors and the IT Division Head should be held monthly. They should also be mandatory.
Some groups prefer to track Applications separate from Infrastructure. It’s a good idea actually, especially when you have to organize meetings and try to keep the length of these discussions to an hour or two.
Set your RSCA meetings in the final week of each month. For instance every Tuesday for IT Infrastructure RSCA reviews and every Thursday for Application RSCA reviews. This way everyone knows when the meetings are scheduled and have no excuse for not attending or creating scheduling conflicts. It also gives your ITC team time to update the Infrastructure reports that might need to be shared or used as input for the Application RSCA items that are dependent on infrastructure changes.
If everyone takes accountability for their items, the process can go much more smoothly than you might expect.
Good luck.
© 1997-2014 Springwolf, D.D., Ph.D., Springwolf’s Kosmos. All Rights Reserved.