 




<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Regulatory Reality &#187; general controls</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/regulatory-compliance/tag/general-controls/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/regulatory-compliance</link>
	<description>A SearchFinancialSecurity.com blog</description>
	<lastBuildDate>Wed, 06 Mar 2013 17:19:34 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
		<item>
		<title>Are banks unfairly scrutinized?</title>
		<link>http://itknowledgeexchange.techtarget.com/regulatory-compliance/are-banks-unfairly-scrutinized/</link>
		<comments>http://itknowledgeexchange.techtarget.com/regulatory-compliance/are-banks-unfairly-scrutinized/#comments</comments>
		<pubDate>Mon, 22 Oct 2012 14:09:17 +0000</pubDate>
		<dc:creator>David Schneier</dc:creator>
				<category><![CDATA[ACH]]></category>
		<category><![CDATA[assess]]></category>
		<category><![CDATA[assessment]]></category>
		<category><![CDATA[assessments]]></category>
		<category><![CDATA[Audit]]></category>
		<category><![CDATA[auditor]]></category>
		<category><![CDATA[audits]]></category>
		<category><![CDATA[banking]]></category>
		<category><![CDATA[banks]]></category>
		<category><![CDATA[business]]></category>
		<category><![CDATA[CISA]]></category>
		<category><![CDATA[CISO]]></category>
		<category><![CDATA[community bank]]></category>
		<category><![CDATA[compliance]]></category>
		<category><![CDATA[credit unions]]></category>
		<category><![CDATA[CU]]></category>
		<category><![CDATA[exam]]></category>
		<category><![CDATA[examination]]></category>
		<category><![CDATA[examinations]]></category>
		<category><![CDATA[examiner]]></category>
		<category><![CDATA[examiners]]></category>
		<category><![CDATA[exams]]></category>
		<category><![CDATA[FFIEC]]></category>
		<category><![CDATA[financial institutions]]></category>
		<category><![CDATA[general controls]]></category>
		<category><![CDATA[GLBA]]></category>
		<category><![CDATA[identify theft]]></category>
		<category><![CDATA[identity theft]]></category>
		<category><![CDATA[information security]]></category>
		<category><![CDATA[information security office]]></category>
		<category><![CDATA[Information Technology General Controls]]></category>
		<category><![CDATA[internal audit]]></category>
		<category><![CDATA[internal controls]]></category>
		<category><![CDATA[ITGC]]></category>
		<category><![CDATA[NPPI]]></category>
		<category><![CDATA[observations]]></category>
		<category><![CDATA[oversight]]></category>
		<category><![CDATA[personally identifiable informaiton]]></category>
		<category><![CDATA[PII]]></category>
		<category><![CDATA[privacy]]></category>
		<category><![CDATA[risk assess]]></category>
		<category><![CDATA[risk assessment]]></category>
		<category><![CDATA[risk assessments]]></category>
		<category><![CDATA[risk management]]></category>
		<category><![CDATA[risk-based]]></category>
		<category><![CDATA[risks]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/regulatory-compliance/?p=993</guid>
		<description><![CDATA[A few years back when I first cut over to working somewhat exclusively with financial institutions I memorized an elevator speech that still somewhat defines who I am and what I do professionally.  Part of the speech pointed out that my firm helped &#8220;banks and credit unions meet regulatory compliance with respect to GLBA 501(b) [...]]]></description>
				<content:encoded><![CDATA[<p>A few years back when I first cut over to working somewhat exclusively with financial institutions I memorized an elevator speech that still somewhat defines who I am and what I do professionally.  Part of the speech pointed out that my firm helped &#8220;banks and credit unions meet regulatory compliance with respect to GLBA 501(b) and NCUA Part 748 A&amp;B&#8221;.  To this day when anyone inquires as to what I do for a living this surfaces in some form as an answer.</p>
<p>Truth be told, while I&#8217;ve spent somewhere near seventy-five percent of my time over the past ten years working for financial institutions I&#8217;ve also done a fair amount of work for insurance companies, mostly centered on SOX with occasional diversions into general risk assessment work.  The drivers in the insurance industry are different in terms of oversight and requirements and so the volume of work isn&#8217;t nearly the same.  But that by itself begs a question: Why isn&#8217;t the insurance industry as regulated as financial institutions?</p>
<p>I&#8217;ve now done major audit and assurance work for financial institutions, insurance companies and health care providers and for most of them the risk profile is almost identical in terms of non-public personal information.  So why isn&#8217;t the level of scrutiny equal across all three of them?  While some might start spouting about how it is, about how states routinely audit insurance companies and how the health care industry has to comply with HIPAA the truth is that banks and credit unions are held to a much higher degree of accountability than any other vertical.  Why is that?</p>
<p>I&#8217;m fond of routinely, almost incessantly beating the drum about how it&#8217;s all about the risk.  I get my initial client opportunities because I have a deep resume with relevant experience but I generate repeat business because I tend to whittle things down to what matters most both to my clients and to their oversight providers (auditors and examiners alike).  Compliance exists because risks need to be addressed &#8211; if the risks aren&#8217;t credible or likely the work should be adjusted to reflect that.  But where the risks are real they&#8217;re really real.  The type  of data shared with an insurance company is in many ways even more sensitive than anything shared with a bank and most of what&#8217;s shared with insurance companies is also shared with health care providers.  Yet there&#8217;s no true Federal oversight for the insurance industry and HIPAA is about as much of a toothless tiger as anything I&#8217;ve ever encountered.</p>
<p>I recently completed a boatload of documentation to get my family on a new health insurance plan.  I turned over every piece of sensitive information I have for every member of my family minus my bank account information because that&#8217;s what was required.  I had to provide all of this online and follow that up by sending them an impressive array of hard-copy documents with even more sensitive information that should never be kicking around in the public domain.   In the past I&#8217;ve also been required to provide my bank account information because one plan in particular would only provide coverage if they could automatically deduct monthly premiums via ACH drafts.  So now the insurance industry has access to it all; name, address, social security number, date-of-birth, maiden name, medical history and banking information.  And yet there&#8217;s no true oversight agency that&#8217;s responsible for making sure they&#8217;re protecting all of MY information.</p>
<p>To compound my frustration, of the four insurance companies I&#8217;ve conducted work for since 2006 (two of which are Fortune 5oo&#8217;s) exactly none of them have something akin to a Chief Information Security Officer.  They all have risk people focused on the business side of things (because that&#8217;s necessary to protect profitability) but that&#8217;s it.  There&#8217;s typically an information security manager who&#8217;s part of the infrastructure team but who almost never reports right into the senior-most technology person (e.g. CIO, CTO).  Any audit work that occurs is coordinated across multiple IT managers and on rare occasions there will be an audit/assurance manager.  However in the one example I personally know of where that position exists the person in the role was really just a converted IT manager who obtained a CISA designation &#8211; no fundamental audit or assessment experience.</p>
<p>The question has to be asked:  Why is it that banks and credit unions are heavily regulated regarding protection of non-public personal information but other industries with similar risk profiles are  not?  Why aren&#8217;t insurance companies required to comply with FFIEC-type guidance?  Why isn&#8217;t there a Federal regulatory agency that is responsible for keeping an eye on the insurance industry the way the FDIC, OCC, FRB and NCUA do so for their financial institutions?  And trust me, whatever oversight exists for the insurance and health care industry is largely ineffective.   Why is my sensitive information considered more at risk within a banking infrastructure than it is within an insurance infrastructure?  Having been on site for both and examined their internal controls  I can&#8217;t answer that question, that&#8217;s for certain.</p>
<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/regulatory-compliance/are-banks-unfairly-scrutinized/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Risk: The core issue behind regulatory requirements</title>
		<link>http://itknowledgeexchange.techtarget.com/regulatory-compliance/risk-the-core-issue-behind-regulatory-requirements/</link>
		<comments>http://itknowledgeexchange.techtarget.com/regulatory-compliance/risk-the-core-issue-behind-regulatory-requirements/#comments</comments>
		<pubDate>Fri, 06 Jul 2012 03:18:40 +0000</pubDate>
		<dc:creator>David Schneier</dc:creator>
				<category><![CDATA[assess]]></category>
		<category><![CDATA[assessment]]></category>
		<category><![CDATA[assessments]]></category>
		<category><![CDATA[Audit]]></category>
		<category><![CDATA[audits]]></category>
		<category><![CDATA[bank]]></category>
		<category><![CDATA[banking]]></category>
		<category><![CDATA[banks]]></category>
		<category><![CDATA[compliance]]></category>
		<category><![CDATA[compliant]]></category>
		<category><![CDATA[control]]></category>
		<category><![CDATA[credit union]]></category>
		<category><![CDATA[credit unions]]></category>
		<category><![CDATA[CU]]></category>
		<category><![CDATA[enterprise risk]]></category>
		<category><![CDATA[enterprise risk management]]></category>
		<category><![CDATA[ERM]]></category>
		<category><![CDATA[exam]]></category>
		<category><![CDATA[examination]]></category>
		<category><![CDATA[examinations]]></category>
		<category><![CDATA[examiner]]></category>
		<category><![CDATA[exams]]></category>
		<category><![CDATA[FDIC]]></category>
		<category><![CDATA[Federal Reserve Bank]]></category>
		<category><![CDATA[FFIEC]]></category>
		<category><![CDATA[financial institutions]]></category>
		<category><![CDATA[framework]]></category>
		<category><![CDATA[FRB]]></category>
		<category><![CDATA[general controls]]></category>
		<category><![CDATA[GLBA]]></category>
		<category><![CDATA[governance]]></category>
		<category><![CDATA[GRC]]></category>
		<category><![CDATA[guidance]]></category>
		<category><![CDATA[information security]]></category>
		<category><![CDATA[information security office]]></category>
		<category><![CDATA[infrastructure]]></category>
		<category><![CDATA[NCUA]]></category>
		<category><![CDATA[PII]]></category>
		<category><![CDATA[policy]]></category>
		<category><![CDATA[procedure]]></category>
		<category><![CDATA[regulation]]></category>
		<category><![CDATA[regulations]]></category>
		<category><![CDATA[regulations audit]]></category>
		<category><![CDATA[risk assessment]]></category>
		<category><![CDATA[risk assessments]]></category>
		<category><![CDATA[Risk IT]]></category>
		<category><![CDATA[risk management]]></category>
		<category><![CDATA[risk rating]]></category>
		<category><![CDATA[risk-based]]></category>
		<category><![CDATA[risks]]></category>
		<category><![CDATA[threats]]></category>
		<category><![CDATA[vendor]]></category>
		<category><![CDATA[Vendor Management]]></category>
		<category><![CDATA[vendor risk]]></category>
		<category><![CDATA[vendor risk assessment]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/regulatory-compliance/?p=923</guid>
		<description><![CDATA[There&#8217;s a joke of sorts within my personal circle of family and friends regarding what it is that I do these days.  Ask me and I&#8217;ll tell you that I&#8217;m a regulatory compliance expert who advises financial institutions on how to comply with the myriad rules and regulations governing information security.  Ask my immediate family [...]]]></description>
				<content:encoded><![CDATA[<p>There&#8217;s a joke of sorts within my personal circle of family and friends regarding what it is that I do these days.  Ask me and I&#8217;ll tell you that I&#8217;m a regulatory compliance expert who advises financial institutions on how to comply with the myriad rules and regulations governing information security.  Ask my immediate family and they&#8217;ll tell you that I work with computers.  Ask my extended circle and they&#8217;ll tell you that I do a lot of work with banks and credit unions.  For those who aren&#8217;t in the banking business it&#8217;s difficult to understand exactly what it is that I do and so they find it easier to keep it simple; I do a lot of work with computers for places where people deposit their money.</p>
<p>Of course the truth is much more complicated.  I don&#8217;t just focus on computers, my scope expands to include anything that involves sensitive information.  While that always includes a variety of devices it also includes paper-based and people processes as well.  I frequently share stories about the enormous amount of printed content that&#8217;s to be found throughout an institutions physical locations.  I occasionally tell stories about how careless people can be when on the phone or in conversation and sharing all manner of sensitive information.  It&#8217;s never just about computers, it is however always about information and how it needs to be protected.</p>
<p>Truthfully though what I really do is search for controls that protect information, identify those that I find and try and measure their effectiveness and more importantly identify where controls are missing and work with my clients to remedy that.  At the heart of the regulatory requirements I focus on it&#8217;s all about the risk introduced by the presence of information, from personally identifiable (PII) to non-public personally identifiable (NPPI).  Risk: It&#8217;s what drives every single project I work on, it&#8217;s what drives every product and process I help develop.  And really, if you take the time to read through the literature, it&#8217;s what&#8217;s behind just about every piece of regulation known to the banking world.  Risk, risk, risk and risk.</p>
<p>One of the reasons I&#8217;ve enjoyed spending so much time working with the community banking and credit union sector over the past few years is that it&#8217;s a simple enough argument to make with fewer people to convince; everything you do to comply with the regulations should be risk-based.  It doesn&#8217;t really make a difference if it&#8217;s complicated to do or time consuming, you prioritize based on where they are found and make decisions accordingly.  But that gets much more difficult to do as the institutions grow in size and complexity.  Over the fifteen years I&#8217;ve been building and supporting compliance initiatives I&#8217;ve worked with Fortune 50&#8242;s, 100&#8242;s and 500&#8242;s and a whole lot of financial institutions that merely read Fortune magazine.  But while their overall size varies widely risk is still risk and that never changes.</p>
<p>I wish more practitioners embraced this simple concept.  While some do, many still don&#8217;t.  There&#8217;s often a rush to come up with a standard set of decision criteria to drive the work based on factors not necessarily aligned with risk factors.   Those who have worked with or for me will tell you that when presented with questions about which vendors or applications to assess or what to look for when conducting any type of assessment my first line of logic is to try and figure out where the greatest possible exposures to be found.   Assessing a low risk application yields little value  no matter how complete it may be.  And reviewing a vendor where the dollar spend is high but the risk factors are low does little to protect the institution.</p>
<p>Beware the practitioner who wields a hammer for they only know to look for nails.</p>
<p>Your regulator doesn&#8217;t want you to blindly implement compliance programs, they want you to identify and manage risks, real risks.  They want to be able to understand the logic and approach being used and find credible evidence that you&#8217;re focusing your efforts on the right things.   Go back and read through the library of FFIEC documentation and pay close attention to the hooks inserted throughout where they talk about conducting assessments and talk about using approaches which are appropriate for the size and complexity of your institution.  Then scan through your related program inventory and figure out if you&#8217;ve designed things accordingly.  Are they actually protecting your institution from credible threats and risks or are they just filling binders on your compliance officers shelves?</p>
<p>For me, professionally I&#8217;d prefer to always only do meaningful work and in the audit and assurance world meaningful is code for risk-based.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/regulatory-compliance/risk-the-core-issue-behind-regulatory-requirements/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>What is the practical value of compliance policies?</title>
		<link>http://itknowledgeexchange.techtarget.com/regulatory-compliance/what-is-the-practical-value-of-compliance/</link>
		<comments>http://itknowledgeexchange.techtarget.com/regulatory-compliance/what-is-the-practical-value-of-compliance/#comments</comments>
		<pubDate>Tue, 16 Nov 2010 18:07:25 +0000</pubDate>
		<dc:creator>David Schneier</dc:creator>
				<category><![CDATA[Audit]]></category>
		<category><![CDATA[bcp]]></category>
		<category><![CDATA[compliance]]></category>
		<category><![CDATA[general controls]]></category>
		<category><![CDATA[GLBA]]></category>
		<category><![CDATA[NCUA]]></category>
		<category><![CDATA[regulatory]]></category>
		<category><![CDATA[Regulatory Compliance]]></category>
		<category><![CDATA[risk]]></category>
		<category><![CDATA[risk assessment]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/regulatory-compliance/?p=553</guid>
		<description><![CDATA[If a policy exists on the Intranet but no one knows that they're there, or how or when to use them do they really serve a purpose?  And if a policy exists on the Intranet but no one ever tests to measure their effectiveness do they need to have it at all?  Until we as an industry find a more reliable method of assessing the viability of an institutions documentation and connecting it to actual activities we're falling far short of realizing their true potential]]></description>
				<content:encoded><![CDATA[<p>My practice recently wrapped up an engagement in which we conducted a tabletop test of a client&#8217;s business continuity plan.  As always with such exercises, it&#8217;s interesting to find out how much distance exists between what&#8217;s documented in an institution&#8217;s policy/program and how business is actually conducted.  In this particular case, it turned out that the client&#8217;s responses tracked fairly close to what was specified in their plan.  But what was interesting was that most of their answers were extemporaneous; they barely referenced the plan itself and instead were relying on common sense.  This begged the question: What&#8217;s the practical value of a policy or procedure if no one relies on it?</p>
<p>Everyone that participated in the test knew the nature of the exercise.  Almost everyone had recently been involved in the rewrite of their current plan.  In total there were approximately a dozen participants spread out over multiple test scenarios and of all of them, only one showed up with a printed copy of the plan.  In what can best be described as an open book exam, only one person thought to bring the book along.</p>
<p>It&#8217;s like when I&#8217;m conducting an ITGC audit and ask for the institution&#8217;s password policy in order to determine if it&#8217;s compliant with the policy.  You&#8217;d think that would be about as basic a control as possible, right?  You write down that the minimum password length is X and the reset frequency is Y and then you configure each applicable system accordingly.  This may be the purest example of low-hanging fruit in the compliance domain, and yet you&#8217;d be amazed by how my times I find significant disconnects between what&#8217;s documented and what&#8217;s done.  When you consider how much effort goes into first creating and then maintaining the broad library of documentation all financial institutions have, it&#8217;s sort of a breathtaking waste of time.  It makes you think that for the most part, the only time anyone ever references anything is when someone external from the company asks for it.</p>
<p>This is why when conducting a risk assessment I always throw a question into each interview asking if the person knows what the related documented policy states.  Do you know what the BCP directs you to do if you cannot safely access your office location?  What do you do according to your Red Flags program  if you receive a suspicious phone call about a customer account?  If someone tries to access a secured area of your facility what should you do, who should you contact according to your incident response plan?  Care to guess how many times the reply is somewhere along the lines of &#8220;I have no clue&#8221;?  But every  bank and credit union has these artifacts in place; why is it that no one either knows to use them or knows that they&#8217;re even there?</p>
<p>If a policy exists on the intranet but no one knows that it&#8217;s there, or how or when to use it, does it really serve a purpose?  And if a policy exists on the intranet but no one ever tests to measure its effectiveness, do they need to have it at all?  Until we as an industry find a more reliable method of assessing the viability of an institution&#8217;s documentation and connecting it to actual activities, we&#8217;re falling far short of realizing its true potential.  And in a time of unprecedented financial stress, can anyone really afford to waste even a single dollar on something for nothing?</p>
<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/regulatory-compliance/what-is-the-practical-value-of-compliance/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Compliance professionals need thick skins</title>
		<link>http://itknowledgeexchange.techtarget.com/regulatory-compliance/compliance-requires-hard-decisions/</link>
		<comments>http://itknowledgeexchange.techtarget.com/regulatory-compliance/compliance-requires-hard-decisions/#comments</comments>
		<pubDate>Fri, 23 Apr 2010 22:14:59 +0000</pubDate>
		<dc:creator>David Schneier</dc:creator>
				<category><![CDATA[assessment]]></category>
		<category><![CDATA[assessments]]></category>
		<category><![CDATA[Audit]]></category>
		<category><![CDATA[bcp]]></category>
		<category><![CDATA[business continuity planning]]></category>
		<category><![CDATA[controls]]></category>
		<category><![CDATA[framework]]></category>
		<category><![CDATA[general controls]]></category>
		<category><![CDATA[GLBA]]></category>
		<category><![CDATA[IT General Controls]]></category>
		<category><![CDATA[NCUA]]></category>
		<category><![CDATA[Regulatory Compliance]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[security awareness]]></category>
		<category><![CDATA[Vendor Management]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/regulatory-compliance/?p=344</guid>
		<description><![CDATA[Compliance requires hard decisions, thick skin and consistency.  If you're more inclined to be affected by acceptance rather than respect it may not be the right line of work for you. ]]></description>
				<content:encoded><![CDATA[<p>I&#8217;ve often surprised people when it comes to conducting audit/assessment work or developing compliance programs.  Generally speaking I&#8217;m a reasonable person who typically exhibits an abundance of flexibility in my day-to-day life.  However when it comes to my career, I tend to be much more of a hard-liner, someone who shuns gray areas and instead tries to view everything in a binary fashion: You&#8217;re either compliant or not, you&#8217;re either following your rules or you&#8217;re not.  I&#8217;m the guy who hates to take findings out of an audit report in order to appease the client or accept excuses (legitimate or otherwise) as to why things aren&#8217;t being done according to the rules.</p>
<p>But every now and again I find a situation that makes me think that maybe, just maybe, an exception can be made.</p>
<p>In working with a client on implementing a compliance program, it became apparent that by adhering to the exact letter of the law specified within the documentation, they&#8217;d immediately be out of compliance on day one in a very large, obvious way.  Typically when dealing with such a situation, I advise the client to develop a schedule indicating the dates by which they expect to get all their work done and be fully compliant.  For vendor management, I usually recommend twelve months, for Red Flags it&#8217;s usually six months and for security awareness it&#8217;s three months.  As long as the plan and related schedule is documented and you can prove that you&#8217;re adhering to it, examiners and auditors alike will usually give you a free pass until the next time around.</p>
<p>Even so, in this instance nearly half of all the in-scope work would be displayed as overdue right up front.  No one wants to see that on a screen or in a report, no one wants to risk having senior management see that information and absolutely no one ever wants to explain to an examiner/auditor why they have so much work still to do (even with a solid explanation and plan).</p>
<p>And so I blinked.  I considered in this instance a way to introduce a new rule that would allow the client to theoretically use my approach of scheduling all the work to be completed within a set time frame (twelve months in this case) but wouldn&#8217;t have to show anything as being overdue.  It didn&#8217;t seem so much like the right thing as much as the kind thing to do.  I even went so far as to scope out my idea in writing and share it with my fellow compliance experts in our practice.</p>
<p>As it turns out, I apparently have had an influence in how all of us view such matters because the first question I was asked was what would I do if I was managing the program.  I wouldn&#8217;t come up with any special rules to avoid being accurate and honest, that&#8217;s for certain; it is what it is.  I was then asked if I was willing to bend the rules in other projects, say like an audit for example.  Well considering I&#8217;ve excused myself from audits in the past because management (at previous companies) elected to remove findings or soften them in order to keep the clients happy I knew the answer was a resounding &#8220;no.&#8221;  So I was asked why I was looking to bend the rules now.  Good point.</p>
<p>What audit and compliance practitioners have to do is often unpopular and sometimes very difficult.  We&#8217;re often perceived as inflexible or unreasonable.  But the truth is that your compliance and/or controls framework is only as effective as its weakest link; if you start making exceptions in one area it quickly becomes expected in others.  Once one control is weakened in exchange for making things easier or more palatable, the integrity of the whole enchilada suffers.</p>
<p>Compliance requires hard decisions, thick skin and consistency.  If you&#8217;re more inclined to be affected by acceptance rather than respect, it may not be the right line of work for you.  Or as I&#8217;m fond of saying, it requires that you&#8217;d rather be right than popular.</p>
<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/regulatory-compliance/compliance-requires-hard-decisions/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Regulatory compliance bits and bytes</title>
		<link>http://itknowledgeexchange.techtarget.com/regulatory-compliance/regulatory-compliance-bits-and-bytes/</link>
		<comments>http://itknowledgeexchange.techtarget.com/regulatory-compliance/regulatory-compliance-bits-and-bytes/#comments</comments>
		<pubDate>Thu, 29 Oct 2009 17:23:52 +0000</pubDate>
		<dc:creator>David Schneier</dc:creator>
				<category><![CDATA[assessments]]></category>
		<category><![CDATA[audits]]></category>
		<category><![CDATA[bcp]]></category>
		<category><![CDATA[business continuity planning]]></category>
		<category><![CDATA[disaster recovery]]></category>
		<category><![CDATA[DR]]></category>
		<category><![CDATA[FDIC]]></category>
		<category><![CDATA[general controls]]></category>
		<category><![CDATA[GLBA]]></category>
		<category><![CDATA[NCUA]]></category>
		<category><![CDATA[NCUA Sheila Bair]]></category>
		<category><![CDATA[Pandemic Planning]]></category>
		<category><![CDATA[password]]></category>
		<category><![CDATA[policy]]></category>
		<category><![CDATA[procedure]]></category>
		<category><![CDATA[Regulatory Compliance]]></category>
		<category><![CDATA[risk assessments]]></category>
		<category><![CDATA[SOX]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/regulatory-compliance/?p=217</guid>
		<description><![CDATA[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? ]]></description>
				<content:encoded><![CDATA[<p class="MsoNormal">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.<span> </span>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.<span> </span>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.<span> </span>It’s amazing what you can pull together when you scavenge around and piece together disparate parts into one coordinated effort.</p>
<p class="MsoNormal">And so it goes with this week&#8217;s post. Here are some nuggets that I&#8217;ve gathered over time:</p>
<p class="MsoNormal">
<p class="MsoNormal"><strong>Policy and procedure:</strong> I was talking to a client today about password reset lengths.<span> </span>Turns out for one of their products they changed the password frequency to expire after 1,000 days.<span> </span>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.<span> </span>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).<span> </span>After a momentary silence, their quiet reply was “good point.”<span> </span>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.<span> </span>Once an examiner discovers something like that, they figure it’s an indication of related issues and wind up digging a bit deeper.<span> </span>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.</p>
<p class="MsoNormal">
<p class="MsoNormal"><strong>Pandemic planning:</strong> There’s still<span> </span>heightened concern regarding the swine flu and my industry continues to beat the drum about needing to have a pandemic response plan in place.<span> </span>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.<span> </span>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.<span> </span>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.<span> </span>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.</p>
<p class="MsoNormal">
<p class="MsoNormal"><strong>SOX:</strong> Banks that are required to be SOX compliant need to take some time to make sure that they’re thinking things through.<span> </span>GLBA is a fairly rigorous and encompassing regulation and extends deeply into a financial institution&#8217;s infrastructure.<span> </span>To a certain extent, it serves to drive a bank&#8217;s general controls framework, be it informal or otherwise, and as a byproduct goes a long way towards establishing controls typically associated with SOX.<span> </span>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.<span> </span>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.<span> </span><span> </span>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.</p>
<p class="MsoNormal">
<p class="MsoNormal"><strong>Year-end activities:</strong><span> </span>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.<span> </span>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.”<span> </span>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.<span> </span><span> </span>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?<span> </span>In a day and age when new threats emerge almost daily if not hourly how can you justify neglecting such a critical task?<span> </span>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.<span> </span></p>
<p class="MsoNormal">
<p class="MsoNormal">And on a final note, I’d like to share <a class="aligncenter" title="FDIC Website" href="http://www.fdic.gov/" target="_blank">this link</a> 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.<span> </span>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.<span> </span>But I think it&#8217;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.<span> </span>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.<span> </span></p>
<p class="MsoNormal">
<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/regulatory-compliance/regulatory-compliance-bits-and-bytes/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IT audits versus reviews</title>
		<link>http://itknowledgeexchange.techtarget.com/regulatory-compliance/lets-audit-the-review/</link>
		<comments>http://itknowledgeexchange.techtarget.com/regulatory-compliance/lets-audit-the-review/#comments</comments>
		<pubDate>Tue, 01 Sep 2009 15:29:17 +0000</pubDate>
		<dc:creator>David Schneier</dc:creator>
				<category><![CDATA[Audit]]></category>
		<category><![CDATA[compliance]]></category>
		<category><![CDATA[general controls]]></category>
		<category><![CDATA[GLBA]]></category>
		<category><![CDATA[governance]]></category>
		<category><![CDATA[GRC]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[ITGC]]></category>
		<category><![CDATA[NCUA]]></category>
		<category><![CDATA[Regulatory Compliance]]></category>
		<category><![CDATA[risk]]></category>
		<category><![CDATA[risk assessment]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/regulatory-compliance/?p=185</guid>
		<description><![CDATA[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 [...]]]></description>
				<content:encoded><![CDATA[<p class="MsoNormal">I had mentioned in my last post a recent conversation with my partner regarding a proposed IT general controls (ITGC) audit.<span> </span>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.<span> </span>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.<span> </span>His knowledge of the myriad regulations is impressive and there are times where I’ll vet ideas through him to validate my own thinking.</p>
<p class="MsoNormal">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.<span> </span>I knew right away where the question stemmed from because of my experience in the industry.<span> </span>Many firms we compete with (and some I’ve even worked for in another time and place) don’t conduct audits, they conduct reviews.<span> </span>Sometimes they don’t even conduct a review or an audit but rather an assessment.<span> </span>I’ve struggled with this blurred use of terms because in my mind there are very clear delineations.<span> </span>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.<span> </span>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.<span> </span>And so when practitioners offer services that aren’t specific to one of the key areas of the GRC spectrum, it bothers me.</p>
<p class="MsoNormal">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.<span> </span>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.<span> </span>It’s all fairly straight forward.<span> </span></p>
<p class="MsoNormal">Now a risk assessment is not an audit; it’s a bit more arbitrary.<span> </span>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.<span> </span>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.</p>
<p class="MsoNormal">So here’s my question: what exactly is a review?<span> </span>If you’re conducting tests and examining evidence you’re conducting an audit.<span> </span>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).<span> </span>Is there some odd dimension between the risk assessment and the audit I’m unaware of where this review occurs?<span> </span>And what exactly are you expecting from the results of this review?<span> </span>Because I’ll tell you this much, examiners only recognize risk assessments and audits.<span> </span>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.<span> </span>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.<span> </span>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.</p>
<p class="MsoNormal">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?<span> </span>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.<span> </span>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.<span> </span>And of course it’s important to loop back to my earlier comment: Examiners will absolutely ask you for the work papers.<span> </span>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.<span> </span>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.<span> </span>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.<span> </span>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.<span> </span>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?<span> </span>For those practitioners looking for shortcuts it provides the wrong incentive.</p>
<p class="MsoNormal">If you want/need an audit, schedule an audit.<span> </span>If you want/need a risk assessment, schedule a risk assessment.<span> </span>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.<span> </span>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.<span> </span>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.<span> </span>Audit or risk assess, pick one.</p>
<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/regulatory-compliance/lets-audit-the-review/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
