General Controls archives - Regulatory Reality
Home > IT Blogs > Regulatory Reality >

Regulatory Reality:

general controls

Oct 29 2009   5:23PM GMT

Regulatory compliance bits and bytes



Posted by: David Schneier
Regulatory Compliance, FDIC, GLBA, NCUA Sheila Bair, SOX, Pandemic Planning, business continuity planning, bcp, DR, disaster recovery, password, policy, procedure, audits, assessments, risk assessments, general controls, NCUA

Many years ago I found myself in one of those awkward moments where I needed to pay for something but didn’t have enough cash on hand to cover the bill. Rather than do the smart thing and find an ATM I instead elected to rip through my car and dig up all of the change that had been accumulating over the months and miles. After about five minutes and some disturbing encounters (food can morph into some bizarre forms when left under a car seat for too long) I somehow managed to come up with enough change to cover the shortfall. It’s amazing what you can pull together when you scavenge around and piece together disparate parts into one coordinated effort.

And so it goes with this week’s post. Here are some nuggets that I’ve gathered over time:

Policy and procedure: I was talking to a client today about password reset lengths. Turns out for one of their products they changed the password frequency to expire after 1,000 days. Their logic was that it was low risk because the application didn’t store NPPI and the security was really only necessary to ensure proper segregation of duties. So I asked them if they had a password policy (they did) and if so were they in compliance with the policy (they weren’t). After a momentary silence, their quiet reply was “good point.” Being the auditor that I am I couldn’t help point out that the worst thing any institution could do was to deviate from a documented policy or procedure, regardless of the reason. Once an examiner discovers something like that, they figure it’s an indication of related issues and wind up digging a bit deeper. Document what it is you do and than make sure you’re doing it; while it may seem simple enough, you’d be surprised how many companies fail on that point.

Pandemic planning: There’s still heightened concern regarding the swine flu and my industry continues to beat the drum about needing to have a pandemic response plan in place. While it’s a valid point, I’ve been polling my clients over the past few months regarding their first hand experiences with the flu epidemic. Only a few have been confronted with any legitimate outbreaks and none of them have experienced an absentee rate that required unusual planning or intervention. While I’m not advocating that a pandemic response plan is superfluous, I am questioning my peers who are pushing this as a top of the list agenda item. For my money I’d rather spend time making sure that a properly vetted and tested business continuity plan is in place and spend less time and effort getting caught up in the hype.

SOX: Banks that are required to be SOX compliant need to take some time to make sure that they’re thinking things through. GLBA is a fairly rigorous and encompassing regulation and extends deeply into a financial institution’s infrastructure. To a certain extent, it serves to drive a bank’s general controls framework, be it informal or otherwise, and as a byproduct goes a long way towards establishing controls typically associated with SOX. So when I encounter clients who are tackling SOX as if though it’s its own separate set of requirements I throw up the caution flag and try and force a reset. While it may be true that larger institutions need to extend significantly from GLBA to controls around financial reporting within the infrastructure, that would only represent a subset. Before doing anything different, the bank should bring in someone who has experience working with both SOX and GLBA to identify the (many) commonalities and produce a consolidated framework so that efficiencies are both identified and realized.

Year-end activities: In my last post I discussed how there’s an uptick in services work this time of year when many banks and credit unions remember that they still need to conduct a wide range of audits and assessments in support of GLBA/NCUA regulations. If you spend some time reading through FFIEC guidance (seriously, it’s not nearly as dry and boring as you might think) there are multiple references to “your most recent audit or assessment.” For those of you who think that the need to conduct this work is suggested rather than required, consider how it looks to your examiner(s) when they discover that your most recent risk assessment was either conducted several years ago or not at all. Do you really think it reflects well on your institution that you haven’t taken a serious look at the myriad risk factors swirling about your infrastructure for any considerable length of time? In a day and age when new threats emerge almost daily if not hourly how can you justify neglecting such a critical task? The examiners expect a current set of reports not only because it’s required but also because it’s a clear indication of solid management and oversight activities.

And on a final note, I’d like to share this link to the FDIC website. You’ll find a video message from Chairman Bair on the current state of both the FDIC and the banking industry. It’s really more of a “happy recap” (with all due respect to Mets fans) of similar messages she’s released over the last year. But I think it’s worth your time (about four minutes total) to hear it for yourself and gain a sense of calm about the security of your own deposits. And for those of you who might think I’m keeping to some sort of schedule regarding Sheila Bair references, as long as she keeps doing the right things I’m going to keep bringing her name up.

AddThis Social Bookmark Button     0 Comments     RSS Feed     Email a friend

Sep 1 2009   3:29PM GMT

IT audits versus reviews



Posted by: David Schneier
Regulatory Compliance, Audit, risk, risk assessment, GLBA, NCUA, general controls, IT, ITGC, governance, compliance, GRC

I had mentioned in my last post a recent conversation with my partner regarding a proposed IT general controls (ITGC) audit. My primary role in our practice is to head up regulatory compliance services which includes audits, assessments and program development; my partner’s primary role is head of sales and business strategy. However, there’s a significant amount of overlap between our two sides and I sometimes forget that I’m the compliance expert when we’re discussing the industry. His knowledge of the myriad regulations is impressive and there are times where I’ll vet ideas through him to validate my own thinking.

Anyway, he’d mentioned a conversation with the client around the proposed ITGC audit in which the project sponsor asked what the difference is between an audit and a review. I knew right away where the question stemmed from because of my experience in the industry. Many firms we compete with (and some I’ve even worked for in another time and place) don’t conduct audits, they conduct reviews. Sometimes they don’t even conduct a review or an audit but rather an assessment. I’ve struggled with this blurred use of terms because in my mind there are very clear delineations. The lifecycle of the governance, risk and compliance (GRC) domain is as such: identify and assess risk, design controls to mitigate those risks and test to validate that those controls are functioning as expected. And so, a risk assessment is conducted, governance elements are introduced in the form of policies and procedures, and regularly scheduled tests occur to make sure that the whole enchilada is actually getting the job done. And so when practitioners offer services that aren’t specific to one of the key areas of the GRC spectrum, it bothers me.

See, an audit is an audit is an audit; you determine the control objectives that are supposed to be supported by the entity that are in scope for the type of audit, identify the related control activities that either are or should be in place and then design a series of test steps to determine if those activities are occurring and tie back to the overall objective. The auditor has some leeway when it comes to offering an opinion as to what the results actually mean (one auditors pass is oft times another auditors finding) but fundamentally the audit results tend to be binary, you either pass or fail. It’s all fairly straight forward.

Now a risk assessment is not an audit; it’s a bit more arbitrary. Management generally is polled to determine what areas of their infrastructure (including finance, operations and technology) they are most concerned with, factor in regulatory and industry requirements and then come up with a plan for conducting the risk assessments. As these assessments occur, what they reveal would be factored into the overall audit plan to make certain that the areas presenting the greatest risk to the business are being examined closely and in a timely fashion.

So here’s my question: what exactly is a review? If you’re conducting tests and examining evidence you’re conducting an audit. If you’re interviewing stakeholders and determining what controls are in place but not testing their effectiveness then you’re conducting a risk assessment (assuming you’re asking the right sort of questions – a post for another day). Is there some odd dimension between the risk assessment and the audit I’m unaware of where this review occurs? And what exactly are you expecting from the results of this review? Because I’ll tell you this much, examiners only recognize risk assessments and audits. You can present them with a report that’s called a review in the title and tell them it’s actually an audit but you’d better be prepared to produce work papers because they’re going to ask you for them, trust me on this point. But my experience is that reviews don’t produce work papers because evidence is generally not formally collected in support of the report and requires significantly less effort to conduct. Which is why when we discussed the semantics of our industry, my partner is fond of saying that the difference between an audit and a review is about 50% of the proposed amount.

And as long as I’m ranting on the topic, how many of you out there include work papers as a deliverable when you contract with external entities to conduct audits? I’ve long been amazed at how many audit projects I’ve managed where work papers weren’t required or provided because it wasn’t included in the statement of work. I’m of the opinion that a summary audit report by itself is useless if you don’t have the supporting documentation because it’s the only true way to confirm that the testing occurred and support the findings. And of course it’s important to loop back to my earlier comment: Examiners will absolutely ask you for the work papers. I routinely receive phone calls from clients I’ve worked with at my previous firms asking if I still had access to their work papers because their examiner is asking for them. It’s awful for me because I have to tell them that while the evidence is still available (I keep everything for seven years for fieldwork I’ve conducted) there are no formal work papers to provide. Thus the reason that when we started our firm and developed the methodologies, I made certain that part of the scoping process included asking the client if work papers were to be included in the deliverables. It adds time to the project and so there’s a cost implication, but it’s the right way to run an audit and so really a need-to-have. You can take a short cut where applicable and only document findings but even so, how can you prove that a successful test was actually successful? For those practitioners looking for shortcuts it provides the wrong incentive.

If you want/need an audit, schedule an audit. If you want/need a risk assessment, schedule a risk assessment. If you’re considering a review or a generic assessment reconsider; decide which of the two proper categories your work fits into and than schedule accordingly. This isn’t rocket science; the FDIC and NCUA have been quite clear as to what you’re required to do so keep it simple. And if the resources you’re using aren’t speaking in the common audit and compliance vernacular force their hand and make them do so. Audit or risk assess, pick one.

AddThis Social Bookmark Button     0 Comments     RSS Feed     Email a friend