For the purposes of regulator reporting and customer notification, it is critical that we first define an “incident”. Here is how an incident is defined by the FFIEC: (more…)
Category: From the Field
Archiving vs. retention of email and other electronic data
There is no specific FFIEC regulatory mandate for archiving, just retention1. However, there are three reasons why you might want to consider archiving, which I will address shortly. First though, the issue of retention. The key to complying with legal and regulatory guidelines regarding retention is to consider all electronic information (including email) exactly the same as paper documents for the purposes of retention and destruction in your policies and procedures. Make sure your retention periods are the same regardless of the physical or electronic nature of the information. Of course if you’re archiving email, the challenge is in being able to separate the financial emails, from the loan documentation emails, from the customer communication emails, from the jokes. All could have different (or non-existent) retention requirements, but there is no technology available to automatically classify each message by data type. Lacking that, most banks simply opt to archive all email communication regardless of the nature of the message. Simply put, there are 3 potential approaches to data retention: Save everything, save selectively, and save nothing. Given the current technical limitations, the least risky of the 3 is to save everything.
Now, retention vs. archiving: Think of an archive as a non-alterable backup. Some archive solutions also add a search feature, but the key is that the data cannot be deleted or modified in any way. So why consider archiving instead of simple retention? Three reasons:
First, a public company is subject to SOX regulation as well as GLBA. SOX is much more stringent in its retention requirements in the sense that the data must not only be retained, but the Bank must reasonably assure the integrity (non-alterability) and availability (search ability) of the data as well. This can be done in several ways, but archiving is the most common.
Second, does your institution still have TARP funds? If so, there could be retention implications in 3 areas:
• Accountability and transparency mandates
• Specific or implied record-keeping requirements
• Heightened public scrutiny
Taken in order, the accountability and transparency mandates were established via the Recovery Accountability and Transparency Board, which will coordinate and conduct oversight of recovery spending to ensure taxpayer dollars are not wasted, abused, or used fraudulently. The over-arching record requirement of this act is the broad, discretionary powers given to the inspectors general to review and examine any records related to covered funds as cited in Sec. 1515 of the act. Again, archiving is not required, but it is the best solution to assure data integrity and availability.
Third, the Federal Rules for Civil Procedures, which govern the conduct of all civil actions brought in Federal district courts (and most state courts), require the disclosure of any “electronically stored information” during the discovery process. The only exception to this is if the “electronically stored information is lost as a result of the routine, good-faith operation of an electronic information system”, OR if the data were destroyed in accordance with the institutions’ reasonable and customary data retention and destruction policy.
1The Operations Handbook mentions data retention only with regard to digital imaging systems. The Handbook was written in 2004, when electronic documents were much less ubiquitous.
DR Plans – Compliant or Recoverable?
When addressing the issue of your disaster recovery plan, the ultimate goal is both. But if you’re faced with limited resources (time, personnel, and money), and need to decide whether you’ll conduct a test or re-write your existing plan, what should you do? A successful test demonstrates that you can recover if you have to. Isn’t that the point of a DR plan? Why waste limited resources tweaking your plan when the tests validate your recovery capability?
Because if your plan doesn’t follow the FFIEC guidance, you may fail an audit or examination regardless of how many successful tests you’ve conducted. It may seem like a case of misplaced priorities, but it does make sense. The March 2006 IT Examination Handbook is (unlike most of the other handbooks) pretty prescriptive in it’s guidance. It “encourages” financial institutions to adopt a 4-phase process consisting of:
- Business Impact Analysis
- Risk Assessment
- Risk Management
- Risk Monitoring & Testing
I put “encourages” in quotes, because whenever the FFIEC uses that word what they really mean is that you better have a very very good reason NOT to adopt this process. In fact, since 12/07 the FDIC has made the Business Impact Analysis mandatory, and recent audits have faulted plans for not having a Risk Assessment. So the first reason you should focus on bringing your plan into alignment with current regulatory guidance is to avoid audit and examination deficiencies. You may never experience an actual emergency severe enough to activate your plan, but you are virtually guaranteed to have it audited and examined, and repeatedly so.
But the most important reason to focus on having a compliant plan is that the prescribed process actually makes sense. Each phase specified in the Handbook flows logically to the next phase, with the end result being a comprehensive program that:
- Identifies and prioritizes all critical business process and their inter-dependencies (Phase 1)
- Identifies threats to those processes (Phase 2)
- Develops recovery procedures in the event the threats affect the processes (Phase 3), and
- Tests all assumptions to validate all previous phases (Phase 4)
Unless you’ve completed Phases 1 & 2, how do you know your test results are valid, i.e. that you are recovering the processes that are most important to you? If you haven’t done the analysis and assessment steps, you really don’t know.
So, complaint AND recoverable is the goal, but if the question is compliant OR recoverable, you should always opt for compliant. Because if compliant is done correctly, recoverable will be the result.
The 5 trickiest FDIC IT examination questions (part 5).
In my last post, I asked you to weigh in on what question you wanted me to address in this final post of the series. This one came from a bank that was in the process of actually filling out the questionnaire, and it’s a good one. It’s found in the Vendor Management section:
“Has the bank identified and reported its service provider relationships (both domestic and foreign-based) to the FDIC (Y/N)?”
At first glance, you may be tempted to interpret this as asking “Has the bank identified and reported its MAJOR or CRITICAL service provider relationships…?”, but the question does not seem to limit your reporting requirement to a particular class or size of service provider. So are you really obligated to report ALL vendor relationships, from your core provider to your cleaning crew? Taken a face value it would certainly seem so.
To figure out exactly what is required you have to look at the 2 references listed under the question:
- “Notification of Performance of Bank Services” FDIC Rules and Regulations 304.3, and
- 12USC1867 Section 7(c)(2) Bank Service Company Act (BCSA)
In researching this, it appeared at first that it only applied to Banks that owned more than 1% of a bank service provider. But upon further review (sorry, it’s football season), Section 7(c)(2) of the Bank Service Company Act states that any FDIC-supervised institution that has services performed by a third party “shall notify such agency of the existence of the service relationship within 30 days after the making of such service contract or the performance of the service, whichever occurs first.” So again, this looks like ALL vendor relationships need to be reported.
However, in a recent interview at bankinfosecurity.com with Donald Saxinger (senior examination specialist with the FDIC), this exact issue was addressed in the context of reporting social media vendors. Simply put, his response was that only if the vendor provides “banking functions” does it need to be reported to the regulators. Banking functions are defined in Section 3 of the Bank Service Company Act as:
- check and deposit sorting and posting,
- computation and posting of interest and other credits and charges,
- preparation and mailing of checks, statements, notices, and similar items, and
- any other clerical, bookkeeping, accounting, statistical, or similar functions performed for a depository institution
Using this list as a reference, only core vendors, item processors and outsourced accounting firms fall into these categories. (Whether or not IT vendors fall into this category will be addressed in a future post. Mr Saxinger makes the point that IT vendors are one of the dependency layers that supports the business process, and as such MAY fall into one of the categories above, depending on the outcome of your risk assessment.) To be safe, since there is no penalty for over reporting, it’s best to report all vendor relationships that even come close to fitting the definition of a bank service company.
So the correct answer is “Yes, we report all of our service provider relationships that provide banking functions to us, as well as any vendors providing a critical dependency to those service providers, as determined by our risk assessment.” Of course, make sure that you do report them. The FDIC form is here, other regulators may have their own reporting mechanism.
The 5 trickiest FDIC IT examination questions (part 4).
Last time in Part 3 we discussed (at some length) the FDIC IT Exam question “Are project management techniques and system development life cycle processes used to guide efforts at acquiring and implementing technology (Y/N)?”. This time, we address a question from the Part 3 – Audit/Independent Review Program section titled:
“Are the results of your audits/independent reviews used to adjust your risk assessment findings/results (Y/N)?”
I’m going to give you a 2 for 1 bonus on this one. There is another question just after this one that is closely related, so we’ll address them both at the same time:
“Do you have a system for tracking audit and regulatory exceptions to final resolution (Y/N)?”
They should really be asked in the reverse order, because if you have a “system” in place for tracking audit findings, it would necessarily address (as the final step in the audit process) adjusting your risk assessment findings. It would serve no useful purpose to submit to the time and expense of an audit, only to discard the findings. Nevertheless, you want to answer “Y” to both questions, and the proper way to document your answer is found in the references for both questions.
Both questions share the first reference (FDIC Rules and Regulations Part 364 Appendix B Section III (C)(3) and (E)), which states:
Section III (C)(3) – “Each Bank shall…Regularly test the key controls, systems and procedures of the information security program. The frequency and nature of such tests should be determined by the bank’s risk assessment. Tests should be conducted or reviewed by independent third parties or staff independent of those that develop or maintain the security programs.”
And,
Section III (E) – “Adjust the Program. Each bank shall monitor, evaluate, and adjust, as appropriate, the information security program in light of any relevant changes in technology, the sensitivity of its customer information, internal or external threats to information, and the bank’s own changing business arrangements, such as mergers and acquisitions, alliances and joint ventures, outsourcing arrangements, and changes to customer information systems.”
Simply put, you must first test the controls in your risk management program, and then adjust your program with the results of the findings. How do you prove compliance? The answer is found in the details of your audit program, specifically with your external auditor. The terms of the contract with your auditor determine the nature, scope and objectives of the audit engagement. An information security audit (sometimes referred to as a GLBA audit), will by definition include coverage of the key controls, systems and procedures of your information security program.
But just because you have an audit program, you haven’t directly addressed the questions just yet. What do you actually do with the findings from the audit? Whenever the FFIEC mentions a “system”, what they usually mean is that its formalized (policy driven), standardized (operates in a committee, and from an agenda), and documented. So what committee in your organization is tasked with IT security? If you follow FFIEC guidelines, it’s probably your IT Steering Committee. It’s logical then that IT related audit findings would be presented there as well. (Some institutions have a separate audit committee, but if audit findings require changes to IT policies or procedures, they would still need to be presented to IT Steering for implementation.)
So the correct answer to both questions is “Yes, the findings from our information security audits are presented to the IT committee, and are used to adjust our information security program.”
We’re down to the last of the 5 trickiest questions, and I’m going to turn to you for the final post in this series. What IT audit or examination question(s) have you had the most difficulty with? Leave a comment at the bottom, or send me an email, and I’ll discuss not only the correct answer, but most importantly how to answer the “If Yes,…” part.
The 5 trickiest FDIC IT examination questions (part 3).
Last time in Part 2 we tackled “Does the bank’s strategic planning process incorporate information security (Y/N)?” from the FDIC IT Examination Questionnaire. This time we take a closer look at another question that stumps many institutions preparing for examination;
“Are project management techniques and system development life cycle processes used to guide efforts at acquiring and implementing technology (Y/N)?”
This is the last of 25 questions in the PART 2 section Operations Security and Risk Management, and as with most of the other questions, you want to be able to answer “Y” to this. Although there is no explicit “if Yes,…” followup to this question (as there is to 14 other questions), you really don’t want to answer “Y” to anything unless you can document your answer. But how, exactly, do you document compliance with this? As with many of these trickier questions, it actually carries multiple presumptions:
- You have established Project Management Techniques,
- You have established System Development Life-Cycle Processes,
- You utilize both when Acquiring and Implementing Technology.
It’s important to add here that I have not personally seen any particular increased scrutiny in this area. Most institutions simply answer “Y”, and move on without consequence. But before you decide that documenting compliance with this is too difficult (or unnecessary), remember that for every “Yes” answer, there is an implicit (if not explicit) “If Yes,…” response required. So let’s take a look at the references. The first is the FFIEC IT Examination Handbook, Development and Acquisition, December, 2003.
This is the only question in the FDIC questionnaire that references this particular handbook, so it’s easy to see why this manual is often overlooked when preparing for an IT examination. Additionally, how many financial institutions really utilize the System Development Life Cycle (SDLC) methodology when managing their technology projects? (Very, very few that I am aware of.) Still, having a basic understanding of effective project management is a good thing, because as the handbook states on page 3, “Project management in its basic form involves planning and completing a task.” This is done every day…and by most institutions, several times a day. So what does it take to demonstrate “Project Management Techniques”? Fortunately, the FFIEC does not expect you to become experts in the latest PM techniques and methodologies:
“Examiners should not expect organizations to employ elaborate project management techniques in all situations.”
However,
“The critical importance technology plays in financial institutions dictates the use of appropriate development, acquisition, and maintenance standards. Standards do not guarantee that organizations will appropriately develop, acquire, and maintain technology systems. However, standards do enhance management’s control over projects, thereby decreasing project risks.”
So, how do we define (and document) “appropriate standards”? Regardless of the exact methodology used, all successful projects have the following characteristics:
- Detailed project plans (including integration with the overall strategic plan)
- Clearly defined expectations and objectives
- Realistic budgets
- Participation by all departments impacted by the project
- Effective communication
The best way to accomplish all of these is by incorporating discussion of IT projects (proposed, in process, and implemented) into your regular IT Steering Committee meetings. If the meetings are well attended, agenda driven, and documented, the correct answer to the question is “Yes. We acquire, implement, and maintain technology according to a risk-based management process, and document the process in our IT Steering Committee.”
By the way, I mentioned that there were multiple references for this question. The other reference cited is for FDIC FIL-12-99. Although this is too complex to cover adequately in this post, the referenced FIL discusses the Uniform Rating System for Information Technology (URSIT), and it’s four critical components: Audit, Management, Development and Acquisition, and Support and Delivery (AMDS), and specifically how these components are used to assess the overall performance of IT within the organization. As the IT Composite Rating affects the institutions’ overall CAMELS rating, it is important enough to cover in more detail in a future post. (I actually covered the “Management” element in a previous post.)
Next, in Part 4: “Are the results of your audits/independent reviews used to adjust your risk assessment findings/results (Y/N)?”