Fixing the process

Ned Thomas, CRO

Ned sees several layers in the process for "fixing the process." SteadyBank's enterprise GRC solution will factor into them all, and will serve to not only affect the needed changes, but also communicate what is expected, and monitor and report on performance relative to those changes.

At the top layer, there is needed improvement to the internal controls. That will entail modifications to policies. The next layer involves changes to business processes and procedures associated with the affected policies and related to the recent loss events and communication issues and execution failures (these represent additional layers).  In addition, there needs to be stepped up audit frequencies and/or validation requirements to ensure that policies are being followed. Ned decides to deal first with the immediate process fixes and deal with the monitoring aspects afterwards.  For exposures that cannot be well managed and pose too great a threat, either risk transfer should be sought or the activities causing those exposures should be either scaled back or eliminated.

SteadyBank's GRC system -- Ned's biggest asset!

Ned sees the GRC solution as his biggest asset as he attempts to button things down.  This is because linkages between all of the GRC components have already been created within the system in order to ensure that nothing slips through the cracks.

Ned quickly pulls up the causes of the problems and notes them:

  • Lack of communication/ miscommunication
  • Lack of management attention and monitoring
  • Failure in planning and risk assessment
  • Insufficient monitoring of third-party provider
  • Inadequate software testing prior to deployment
  • Malfunctions in software or hardware

Ned is also interested in any regulatory violations, plus business disruption and customer impact. He decides to examine incidents related to disclosure and information privacy.  To do so, Ned simply clicks on the incidents tab, applies a defined filter, and selects only those incidents that are under current investigation.

Ned uses a pre-defined view he created to zero in on the relevant disclosure issues

Next, Ned is easily able to trace through the linkages, which he opts to do through the tabular sections under each incident which he clicks through in turn. He maps out the information and he probes deeper into an apparent lack of management attention and monitoring by Tech & Ops when passing non-public customer information to third-party providers (TPPs). This is a clear violation of SteadyBank's Gramm-Leach-Bliley Act (GLB) Policy. "Boy, we're looking at some additional fines for SteadyBank -- that will certainly put some salt on our wounds," Ned told himself. Ned calls Tech & Ops Manager Paul Winkler to get the straight scoop.

Process fix or people fix?!

Paul Winkler, SVP, Tech & Ops Manager

"Ned, I have determined that this was brought on by turnover of key resources and lack of motivation due to the staff reduction initiative which hurt employee morale in the division and caused longer working hours for those who retained their jobs," reported Paul. Hearing no response, Paul continued, "I had a conversation with Pete, who has been one of my most trusted lieutenants. Pete was very upset over having to let go a couple of his long-time staff due to the corporate ten percent staff reduction initiative."

Paul's voice trembles a bit as he relates, " I pressed him pretty hard, and he finally admitted that he and his remaining two system programmer/analysts failed to exercise careful oversight of the TPP consultants who were brought in to handle the system conversions for check payment posting and electronic (checkless) payment processing. They blamed Bill Cutter, CFO, for the layoffs and I suppose Pete thought it might teach Bill a lesson. I am very angry with Pete, but the fact is that we do not have his area well-documented and I can't really discipline him until the situation stabilizes." "It is a royal mess over here," Paul concluded.

"Thanks for your candor, Paul. I will take this up with the management team and Jake Jabber will circle back with you. By all means, try to get going on a knowledge transfer initiative before all of the walls go up," Ned advised and he ended the call. Ned could see that, at the root, there were serious people issues, which he proceeded to note in the system.

A fix will entail some people-related controls!

Putting heads together

Ned heads down the hallway to Jake’s office. When he arrives, Jake is sorting through some conference material on his desk and he pauses as Ned appears in his doorway. “Can I buy you a cup of coffee?” Ned inquires. “No thanks Ned.  Come in and have a seat!” Jake replied. Ned shares what he has learned from the GRC system and his subsequent conversation with Paul.

Jake Jabber, COO

“Just as I suspected,” Jake remarked, and he continued, “I attended a conference on governance and risk management and two of the top five risks were human capital risk and third-party risk. Hence this comes as no surprise.” Jake punched the speaker phone button and speed-dials to bring Paul into the conversation.

Paul answers the call, saying “Hi Jake! Ned told me I would be hearing from you. I must confess that I have been racking my brain trying to decide whether I need to use the carrot or the stick at his point with these knuckle heads. What do you think I should do?”

Without a pause, Jake answered, “Paul, I suggest you use the frozen carrot!”

“What’s the frozen carrot?” asked Paul.

“You give them the frozen carrot and you tell them they have to eat it or give it back," replied Jake, concluding, “And in the latter case, you then use it as a stick!”

Ned inserted himself into the conversation at this point, insisting, “Listen, all kidding aside, I have worked hard to foster an open and honest culture at SteadyBank where we all listen to each other’s opinions respectfully, we hold ourselves and other accountable for results, and we trust the judgment of our leaders.”

Jake agreed, and chimed in saying, “We can and must do better Paul, and you need to make it a top priority to set the proper tone and instill those values throughout SteadyBank’s Tech & Ops workforce.”

Giving direction

Jake tasks Paul to get answers to the following five key questions on the third-party front:

  1. Are our contractors obligated contractually to abide by our policies and regulatory requirements?
  2. Do our risk assessments cover third-party risks, and if so, what risk areas are covered?
  3. How do we supervise third-party activities and what structures, key performance measures (KPIs) and incentives/penalties do we have in place to control TPPs?
  4. How thoroughly do we check out TPPs before hiring them?
  5. Do we have insurance coverage for outsourced activities and is it adequate?

Jake advised Paul, “Call Bill Cutter to find out about the insurance, and please coordinate with Ned on the rest of the items.” Paul agreed and Jake ended the call. “SteadyBank has some significant third-party risk exposure, and I have no doubt that we need to strengthen our governance around third parties ASAP,” he told Ned.  Ned agreed with Jake and he returned to his office.

Policy management a la GRC!

Ned immediately clicked on the compliance tab in SteadyBank’s GRC system to do some policy creation and revision, which he plans to circulate with the management team prior to next week’s monthly risk management committee meeting.

Fixing the process involves policy management -- an integral part of the GRC solution!

Thankfully, his GRC solution provider, SAS, provided some very helpful templates "out-of-the-box" to assist him, such as a policy on policies, a procedure for creating and updating procedures, a companion template procedure, a procedure for creating and updating policies, and a template policy, a procedure for creating forms, and so on. Also, there were lots of example procedures that addressed banking regulations.

Ned pulls up #10301 SteadyBank Guideline Policy (policy on policies) to review core elements in light of the five questions Jake posed to see if there was something that could possibly be generalized and added to the policy template.

 

 

 

Policy on policy!

In terms of structure for policy documents, Ned sees the core elements as follows:

Policy

  • Purpose
  • Scope
  • Critical Parameters
  • Citation to Companion Procedure
  • Penalty for Non-compliance

Jake decides, based on Jake's first question that the structure needs to be added to allow for citations, or linkages, relating to specific contracts and corporate agreements where the policy in question comes into play. That way:

  • SteadyBank Procurement will be more "policy aware" when negotiating contracts, and
  • Risk Management will be more "contract aware" when reviewing proposed changes to policies and gauging their impact.

"This is great!" Ned tells himself. Just then, Ned's cell phone rings, and it is Paul.

Customer data compromised

"Hey Ned," Paul beckoned, "There has been a development on the TPP front. It turns out there is a missing portable storage device that a TPP programmer took home to work on the computer processing development. It has an image of half of our credit card customer billing records, complete with social security numbers, addresses, birthdates, and the whole works! The individual in question has having home remodeling performed and there have been a dozen different workers in and out of his home on a constant basis over the period, and he suspects one of them made off with the external drive, but he has no idea even when it occurred because he got pulled out of town for several days and left the house key under the doormat, only to return and discover the device was gone."

Ned responds, "Paul, this is important. Was the device password -protected? Also, was the customer data encrypted?" "No to both!" was Paul’s reply.

"This is potentially a "worst nightmare scenario," said Ned, palm on forehead. “Paul, you need to get with Jake, Legal and our physical security department and take immediate action. By tomorrow, I need to contact our primary regulator and by then I want to know precisely which half of our cardholder customer base is affected and what your plans are to issue new cards, freeze the ones they have, and so on. We could be looking at identity theft, worst case." Ned wonders how thing can get this far out of control and he pulls up the schematic for customer data flows he work on with Paul earlier in the year.

Customer data flows through SteadyBank!

Ned thought he had everything covered, but now he knows better.  Systems are one aspect, but Ned now realizes that he forgot to consider the human element.  Ned and Paul not only needed to consider how customer data flows through SteadBank, but they also need to consider how it could flow out of SteadyBank--in other words how to make customer data secure!

More fixes needed

Two policy changes we need to make immediately are to revise our GLB and TPP policies to require device passwords and data encryption on all bank data with application to all third-party contracts going forward, and retro-actively on any projects "in play." In addition, we need to ensure that any data transmitted or "shipped" is also covered. "I don't want to worry about hackers intruding into our network and servers, nor do I want to sweat it out if any FedEx trucks getting hijacked with our data on them!" Ned tells himself.

Next, Ned calls Jake and brings him current on the situation. "Ned," Jake advises, "we need to look into the insurance side, especially to examine our financial/professional (FINPRO) insurance coverage and find out what our TPP has on their end. If identity theft is involved, the consequences might not materialize until sometime in the future, meaning we may need tail coverage on these occurrences, or set additional capital aside, i.e. self-insure. So, let's engage Bill Cutter and our friends over in the Finance Department, who can carry the water on these aspects."

[Narrator: A general realization creeps over Ned, Jake, Paul and others at SteadyBank that "fixing the process" is going to amount to much, much more than originally imagined. Fortunately, the majority of the information required and processes to achieve the desired end result reside in SteadyBank's GRC solution. Fast forward six months, the next episode takes place on October 25, 2012! At that time, we will see the full financial impact of the loss events that have occurred. We will also witness how the GRC solution can help the SteadyBank Team keep risks in check and more effectively monitor and control the operation. As a result, they will likely avoid similar loss events in the future, and they will be alerted earlier in the process when there is a problem. This will enable them to take swifter corrective action.]

Note: If you are interested in this series, you will also find value in another GRC tale that illustrates the value of a GRC solution relative to preventing and dealing with a breech in security leading to the theft of customer information. (To access it, simply click on the embedded link in the previous sentence!) For an introduction to SteadyBank and the main characters in this blog series please click on the following title: Understand GRC through SteadyBank .  Be sure you read the whole Steadybank saga, so you can learn the GRC lessons of SteadyBank. 

Drawings © 2012 Brad Abrahams

tags: steadybankgrc

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <p> <pre lang="" line="" escaped=""> <q cite=""> <strike> <strong>