Process Documentation

The Risk, Security & Compliance Assessment (RSCA) approach is used to evaluate the current state of security and compliance activities for SOx remediation initiatives. RSCA is a three-step methodology that covers Planning and Data Collection, Risk and Security Assessment, and Tracking and Reporting.

Each organization has their own Audit process to define the scope of an audit, the methodology for implementing that audit and how findings are reported. When findings fall into the realm of GRC, they should be handed off to a RSCA team for tracking and oversight for remediation.

See my IT Governance section for more information about IT Audit, and Governance, Risk Management & Compliance (GRC) and Risk, Security & Compliance Assessments (RSCA).

Accountability
Internal Audit, SOx Oversight, IT Organizations, Process Owners and external Assessment Agency

RSCA Tracking and Reporting
When a finding has been identified as a risk to the company, it needs to be tracked to resolution. But that’s not all, it should also be packaged in a final report back to Audit for review and closure.

Deficiency Identification
Control deficiencies are typically identified through an Audit review of some type.  The two big ways are audits typically performed by the companies Internal Audit department or through an External Audit of the entire company through a reliable and reputable audit/accounting company. Here in the U.S.  the Big Four auditors, are PricewaterhouseCoopers (PwC), Deloitte, Ernst & Young (E&Y) and KPMG.

The Corporation may have its own IT specific Compliance Oversight group (ITC) that helps their departments remain compliant and in the clear when Corporate Audit or an External Audit comes calling. Resolving deficiencies before the big boys come to find it is a feather in anyone’s cap! Additionally individual departments might conduct a risk assessments with outside vendors so they come out on top of their fellow IT groups. And finally individual groups or teams within an IT department may self identify a deficiency. Hoping that freely bringing light onto an issue will gain them some favor in the long run. And it actually can.

Self Identification can help with a great many things for that team. First you’re being honest and up front with an issue that could be critical for the entire group. Identifying it before a formal audit comes down the pike, gives the Manager and Director time to resolve it before they arrive. It can also help the team budget for remediation, especially if that requires replacement software, upgrades, or a project plan that will require excessive employee-hours  and effort to correct the deficiency. It’s all about the time and money; if you can point out the issue sooner; you might win favor by those who have the budget strings to purchase equipment or software or upgrades or even contractors who can come in and dedicate their day to your issue. While other managers struggle with requiring their personnel to work double shifts to complete regular duties and remediation responsibilities at the same time.

Once the Deficiencies have been identified, they are tracked and managed through the Risk, Security and Control Assessment (RSCA Methodology – Managing Remediation) by ITC.

Deficiency Ownership:
Deficiencies should be identified with a Process Contact and an IT Contact if they’re not the same group/person. For instance the Process might be owned by the business side, but the deficiency is owned by IT. At the deficiency level, these should be managers directly responsible for the item in question.  An IT Manager maybe both the Process and IT contact for a deficiency. But they should always have a back up so as not to create a single point of failure.

Deficiency Action Plans:
All deficiencies are broken down into action plans. All deficiencies must have at least 1 action plan to remediate the identified issue. Action plans can be assigned to team members who have been given the task to resolve that action item. These individuals are not the owners of the deficiency, but can be identified as subject matter experts for the assigned action plan.

The identified Deficiency Owners have ultimate accountability for planning, implementing solutions by the specified remediation date and reporting of the action through RSCA reporting.

An individual deficiency item may contain multiple action plans that are assigned to various groups for remediation. In these cases, accountability for the overall remediation of the deficiency is shared between senior directors of each group.

For example, one of the most common deficiencies discovered in the first decade of the century was for the Lack of User Authentication Security. You might be amazed at how many companies did not encrypt passwords back in the day. Nor were passwords changed very often. And when a user typed in their password and sent it off to be authenticated it was transmitted in clear text. Even some retail stores didn’t encrypt ATM codes at the checkout register. Your card number and your pin number were both transmitted in clear text. Imagine that?!

To resolve this one deficiency, several action plans needed to be implemented to encrypt passwords within authentication databases, set expiration dates on passwords, and to encrypt transmission of password packets to the database for verification. Each one of these remediation action plans might generate additional steps needed to resolve those issues. For instance, encrypting the password for transmission means you have to transmit it in a format that can be compared for authentication on the back-end. An organization might need to modify their security system to allow encryption and then install software that provides the ability to encrypt on the front-end and un-encrypt packets on the back-end with a security key.

Additionally each step within an action plan might require cross departmental ownership or multiple project lead assignments. There maybe a priority differences or dependencies that require different remediation completion dates. All this must be tracked and reviewed within RSCA.

Deficiency Testing and Closure
Once deficiencies have been remediated, they of course must be tested. Action plans that have been resolved can be tested to verify the item has met the identified gap effectively and accurately. When the owner is satisfied with testing, a Deficiency Closure package is prepared for that item.

Closure packages maybe created for a single action plan, a fully complete deficiency, or multiple deficiencies assigned to the same process or IT owner that are common or address an overall aspect of the IT environment.

For instance, Two deficiencies may be created for a single application. A periodic review of user access for an application; and another for password reset. Both deficiencies can be addressed and reported in a single closure package because the closure of one, also addresses the resolution of the other.  Each Action Plan must be presented with approval signatures for the Closure package from the IT Manager and their Director.

Closure packages are then delivered to ITC for initial review and testing. Packages for action plans can be reviewed and closed by the ITC, then held for further resolution of additional action plans that resolve the overall Audit Finding Deficiency. When all actions have been resolved and the Deficiency has been fully remediated, the ITC will create a final Deficiency Resolution Package. This package must include copies of all the action plan closure packages complete with management signatures. The package is presented to the Division head who reviews the remediation with ITC and the accountable department heads. Once satisfied, the Division head signs off on the package.

ITC  delivers the complete closure package to the assessing body for final review and testing. ONLY the assessing body can close a deficiency completely. Once the assessing body has tested, verified and approved the remediation; they notify ITC that the deficiency can be closed and removed from RSCA. Deficiencies are not officially closed within IT until after they have been verified, approved and reported on at the next RSCA reporting cycle. This allows for the possibility that the resolution is not deemed sufficient by the assessing Audit group. In other words, the remediation was rejected and needs further action.

Procedures
Deficiency Identification
The IT General Deficiency number is a unique identifier that will act as the parent for this finding and will retire when the remediation is complete. These numbers are not reused once the deficiency has been remediated. There are 4 different formats to this number to help identify it in the tracking process. The number isn’t all of these, but rather is assigned one of these values.

1. ITGC-999 :
   Identifies the deficiency as an IT General Control deficiency. These items affect a broad range of IT services or applications. They are not unit or application specific and affect a General Control process.
2. SIC-999 :
   Identifies the item as a Self Identified deficiency, which can affect IT Services as a whole, or unit or application specific issues.
3. IA-999 :
   Identifies the item as an Internal Audit identified deficiency.
4. AA-999 :
   Identifies the item as an external Assessment Agency deficiency.

SIC deficiencies are typically minor issues that can be easily resolved. If they impact a General or Key control, they should be identified as an ITGC item and not a SIC item. (See: Writing IT Process Narratives for more information on Controls).

Deficiency Closures:
Once a deficiency has been remediated it must be reported to ITC through a Remediation Closure Package. Closure packages identify the deficiency being remediated, the actual completion date, a detailed description of the remediation solution and the attached evidence for that solution.

Evidence must be complete and comprehensive. Evidence supports (or proves) the process is effective and working. Each evidentiary specimen should come with a description of the item, how it is utilized and where it is stored or maintained for historical review. Evidence can be a security request, emails, forms, or reports. (A closure package without evidentiary documentation should not be accepted by ITC).

Reporting:
RSCA meetings are held monthly with owners and IT Senior management to review the current status of assigned deficiencies. Managers are accountable for providing a written status to ITC prior to the RSCA meeting. IT Senior managers are required to attend RSCA meetings to review the risks and issues of remediation efforts. This is a key component to RSCA!  Directors, VPs and the IT Division head must participate to add a high level of importance and priority upon the over all process.  Without this participation, the RSCA process is not effective and remediaiton efforts will not get completed. There must be a top down message that emphasizes the level of effort and importance upon this process throughout the entire division.

Risk Acceptance:
In the event that an item cannot be remediated, the assigned IT manager can request a Risk Acceptance. No company can perform business without some level of risk. RSCA and SOx is not about keeping your house totally spotless and clean. It’s about being transparent and accountable for what risks do exist.

In these cases, a Risk Acceptance Closure package is created outlining the specific deficiency, the reason behind the current process, evidence of the risk and the most important part, the Acceptance of Risk Attestation letter. This letter must be signed by everyone within the process chain of ownership, that means the low level manager up to the Division Head, usually the CIO/CTO.  The letter outlines the approved acceptance of risk and becomes part of the companies Annual Attestation process.

Deficiency Escalation:
Failure to report status to ITC through the RSCA process, failure to meet an assigned target date, or failure to remediate a deficiency will result in an escalation to senior management.

ITC will attempt to contact owners for status or assessment of the failure. Items will be escalated to the Director of IT Risk. Additional escalation can be made to the CIO and CFO, and/or the Board Audit Committee as deemed appropriate.

Sometimes this is a good thing. On occasion a finding can be discovered or self reported that cannot be resolved without a change of direction by senior management. Or only through a costly technology change. Such major efforts require not only approval from senior management, but funding and project planning as well.

Here are a few examples I ran across in my IT Audit tenure.
Software Maintenance & Contract Agreements
One big problem many IT organizations face is the proliferation of various software on the company’s network. Especially by the business side end users. Business managers need a way to do this or that and find a software package that will give them what they need. Without talking to anyone or asking if it’s ok, they spend a few thousand dollars and install the software on their local LAN drive, giving access to everyone in their unit.

Before you know it, 20 different business managers have this exact same thing and there’s a resource issue with the overall network affecting the entire company. In addition, you might find that 5 different managers have installed the same piece of software that could have been shared by all 5 groups instead of hogging resources and spending 5 times the cost. And 5 other managers all had the same problem but used 5 different packages to address that one issue. Again spending 5 times the amount that could have been spent to resolve all 5 problems with one solution.

The business side isn’t the only ones to blame. One of the biggest issues within IT the failure to standardize technology within the infrastructure. Providing 4 or 5 different relational database platforms instead of one or two is not only costly, but it creates a convoluted environment that requires additional resources to handle maintenance and support. Not to mention support contracts from vendors.

Of course database platforms aren’t the only issue like this within a company’s infrastructure. When you’re talking technology, diversity isn’t necessarily a good thing and can not only be more expensive in product expenditures, vendor contracts and employee resources, it can also create risks that don’t need to exist in the first place.

Many organizations got into situations like this long before SOx and Compliance came along. So it’s not easy or inexpensive to get out of. Choosing 1 or 2 database platforms for your company means those applications using the platforms you want to get rid of must be updated, re-written or retrofitted in some way.

Setting policies for the business side about doing IT’s job can also bring about costs. What do you do about all those home-grown business applications that have become part of their General Controls for managing business?

Issues like this cannot be resolved by managers in IT. They require upper management to set policy changes and define direction for the entire company. But when shown the benefits and long-term cost savings, generally the upfront expense is accepted and change happens. Remember it’s all about the money and risk. And anyone can show how risk can be costly.

Next:

• RSCA Tracking – Tracking The Details

 

© 1997-2019 Springwolf, D.D., Ph.D., Springwolf’s Creations. All Rights Reserved.