Vendor Management – Page 6

31 Aug 2011

Hot Topics Tom Hinkel 0 comment

Online Transactions – Defining “Normal”

I’ve gotten several inquiries about this since I last posted so I thought I’d better address it. The new FFIEC authentication guidance requires you to conduct periodic risk assessments, and to apply layered controls appropriate to the level of risk. Transactions like ACH origination and interbank transfers involve a generally higher level of risk to the institution and the customer, and as such require additional controls. But here’s the catch…given the exact same product with the exact same capabilities one customer’s normal activity is another customer’s abnormal. So defining normal is critical to identifying your abnormal, or “high-risk”, customers.

Most Internet banking software has built-in transaction monitoring or anomaly detection capabilities, and vendors that don’t are scrambling to add it in the wake of the guidance. As the guidance states:

“Based upon the incidents the Agencies have reviewed, manual or automated transaction monitoring or anomaly detection and response could have prevented many of the frauds since the ACH/wire transfers being originated by the fraudsters were anomalous when compared with the customer’s established patterns of behavior.“

So automated anomaly detection systems can be a very effective preventive, detective and responsive control. But I think there is a very real risk that a purely automated system may not be enough, and may even make the situation worse in some cases. For one thing, any viable risk management solution must strike a balance between security and usability. A highly secure automated anomaly detection and prevention system may be so tightly tuned that it becomes a nuisance to the customer or a burden to the institution. Customers are already reluctant to accept any constraints on usability, even if they can be presented as in their best interest. And if your requirements are just a little bit more than your competitor, you risk losing the customer to them. Interesting paradox…you implement additional controls to protect them, and lose them to a (potentially) less secure competitor!

But another way a purely automated solution may not achieve the desired result is that it may actually lull the institution into a false sense of security. I’ve already heard this in my discussions with our customers…”My vendor says they will fully comply with the new guidance, so I’m counting on them.” And indeed the vendors are all saying “Don’t worry, we’ve got this…”. But do they? In at least one incident, transaction monitoring did not stop an account take-over because according to the automated systems the fraudulent transactions were all within the range of “normal”.

So what more should you do? One thing is to make sure that you don’t rely solely on your vendor to define “normal”. Just as with information security, you can, and (because of your reliance on the vendor) should outsource many of the risk management controls. But since you can not outsource the responsibility for transaction security, you must take an active role with your vendor by sharing responsibility for monitoring. One way to do this is to participate in setting the alert triggers. For example, high account inquiries may trigger an automated anomaly alert, but really don’t carry a high risk of loss. (However, they could be indicative of the early stages of an account takeover, so they shouldn’t be completely ignored either.) On the other hand, a slight increase in interbank transfers may not trigger an alert, but could carry a potentially large loss. Rank the capabilities of each product by risk of loss, and work with your vendor to set anomaly alerts accordingly.

Once you’ve established “normal” ranges for your products by capability, and set the anomaly triggers, your vendor should be able to generate reports for you showing deviations from normal for each product. The next step is to separately assess each customer that falls outside those normal ranges. Anomaly triggers for these customers should necessarily be set more tightly, and your vendor should be able to provide deviation reports for those as well. By regularly reviewing these reports you are demonstrating a shared security responsibility approach, and most of all, demonstrating an understanding of both the letter and spirit of the guidance.

Remember, although your vendor can help, “normal” transaction frequency and dollar amounts must be defined by you based on your understanding of the nature and scope of your on-line banking activities.

14 Jun 2011

Hot Topics Tom Hinkel 4 Comments

SOC 2 vs. SAS 70 – 5 reasons to embrace the change

The SOC 2 and SOC 3 audit guides have recently been released by the AICPA, and the SAS 70 phase-out becomes effective tomorrow. The more I learn about these new reports the more I like them. First of all, as a service provider to financial institutions we will have to prepare for this engagement (just as we did for the SAS 70), so it’s certainly important to know what changes to expect from that perspective. But as a trusted adviser to financial institutions struggling to manage the risks of outsourced services (and the associated vendors), the information provided in the new SOC 2 and SOC 3 reports are a welcome change. In fact, if your vendor provides services such as cloud computing, managed security services, or IT outsourcing, the new SOC reports provide exactly the assurances you need to address your concerns. Here is what I see as the 5 most significant differences between the SAS 70 and the SOC 2 reports, and why you should embrace the change:

Management Assertion – Management must now provide a written description of their organizations’ system (software, people, procedures and data) and controls. The auditor then expresses an opinion on whether or not managements’ assertion is accurate. Why should this matter to you? For the same reason the regulators want your Board and senior management to approve everything from lending policy to DR test results…accountability.

Relevance – The SAS 70 report was always intended to be a your-auditor-to-their-auditor communication, it was never intended to be used by you (the end-user) to address your institutions’ concerns about vendor privacy and security. The SOC reports are intended as a service provider to end-user communication, with the auditor providing verification (or attestation) as to accuracy.

Scope – Although the SAS 70 report addressed some of these, the SOC 2 report directly addresses all of the following 5 concerns:

Security. The service provider’s systems is protected against unauthorized access.
Availability. The service provider’s system is available for operation as contractually committed or agreed.
Processing Integrity. The provider’s system is accurate, complete, and trustworthy.
Confidentiality. Information designated as confidential is protected as contractually committed or agreed.
Privacy. Personal information (if collected by the provider) is used, retained, disclosed, and destroyed in accordance with the providers’ privacy policy.

If these sound familiar, they should. The FFIEC Information Security Booklet lists the following security objectives that all financial institutions should strive to accomplish:

The Privacy and Security elements of GLBA
Availability
Integrity of data or systems
Confidentiality of data or systems
Accountability
Assurance

As you can see, there is considerable overlap between the FFIEC requirements and the scope of a typical SOC 2 engagement.

Testing – Like the SAS 70, the SOC 1 and SOC 2 are available in both a Type 1 and Type II format. A Type I speaks only to the adequacy of vendor controls, but the Type II gives management assurance that the vendor’s controls are not just adequate, but also effective. The auditor can do this in a Type II engagement because they are expected to not just inquire about control effectiveness, but actually observe the control operating effectively via testing. And because the scope of the SOC 2 is significantly greater than the SAS 70 (see above), the test results are much more meaningful to you. In fact, the SOC 2 audit guide itself suggests that because your concerns (particularly as a financial institution) are in both control design and effectiveness, a Type I report is unlikely to provide you with sufficient information to assess the vendor’s risk management controls. For this reason you should insist on a Type II report from all of your critical service providers.

Vendor Subcontractors – This refers to the subcontractor(s) of your service provider, and again this is another FFIEC requirement that is directly addressed in the new SOC reports. The FFIEC in their Outsourcing Technology Services Booklet states that an institution can select from two techniques to manage a multiple service provider relationship:

Use the lead provider to manage all of their subordinate relationships, or
Use separate contracts and operational agreements for each subcontractor.

The booklet suggests that employing the first technique is the least cumbersome for the institution, but that either way;

“Management should also ensure the service provider’s control environment meets or exceeds the institution’s expectations, including the control environment of organizations that the primary service provider utilizes.”

The audit guidelines of the SOC 2 engagement require the service auditor to obtain an understanding of the significant vendors whose services affect the service provider’s system, and assess whether they should be included in the final report, or “carved-out”. Given the regulatory requirement for managing service providers you should insist on an “inclusive” report.

In summary, there will be an adaptation curve as you adjust to the new reports, but in the end I think this is an overwhelming step in the right direction for the accuracy and effectiveness of your vendor management program.

29 Apr 2011

Hot Topics Tom Hinkel 0 comment

Vendor Management and the SAS 70 Replacement

I’ve written about the replacement for the SAS 70, which officially phases out on June 15th, previously. But because this one report is being replaced with 3 new reports, financial institutions have an additional challenge that they didn’t have before. Your vendor management program must now determine the most appropriate report to request based on your specific concerns regarding the vendor. Of course, once the correct report is identified, you must then acquire and review it…this step doesn’t change from the old SAS 70 world.

In the past, determining the correct report wasn’t really necessary, as the SAS 70 was the only reporting tool available if you needed to validate the security controls in place at a service provider. With the SAS 70 being replaced with the SOC 1, SOC 2, and SOC 3, you have 3 options to choose from (and with Type I and Type II versions for the SOC 1 and SOC 2, you really have 5 options!). So how do you choose? It might make sense at this point to back up and take a look at the overall vendor management process.

The FFIEC considers risk management of outsourced services to consist of the following components:

Risk Assessment (assessing the risk of outsourcing)
Service Provider Selection (the due diligence process)
Contract Issues (prior to signing the contract)
Ongoing Monitoring (post contract)

Most institutions believe that their vendor management program begins once the contract is signed, i.e. once the vendor become a vendor. But it’s clear that the vendor management process must begin well before that, and in fact third-party reviews like the old SAS 70, and the new SOC reports, should be obtained during the due diligence phase. This is the proposal phase (step 2 above), well before the decision to engage the vendor.

According to the FFIEC, the due diligence process should determine the following about the vendor:

Existence and corporate history;
Qualifications, backgrounds, and reputations of company principals, including criminal background checks where appropriate;
Other companies using similar services from the provider that may be contacted for reference;
Financial status, including reviews of audited financial statements;
Strategy and reputation;
Service delivery capability, status, and effectiveness;
Technology and systems architecture;
Internal controls environment, security history, and audit coverage;
Legal and regulatory compliance including any complaints, litigation, or regulatory actions;
Reliance on and success in dealing with third party service providers;
Insurance coverage; and
Ability to meet disaster recovery and business continuity requirements.

That is a lot of information to obtain from a non-vendor, but the new SOC reports, and the SOC 2 report in particular, will go a long way towards addressing many of the above concerns. Specifically; systems architecture, internal controls, any third-party providers, insurance coverage, and business continuity would all be addressed in a SOC 2 Type II* report.

I’ve developed this flowchart to assist you with the correct SOC report selection process, and I encourage you to discuss it with your auditor. Of course once the correct report for that vendor has been determined, you must then obtain and evaluate it…that is a topic for a future post.

*Note: We are still waiting for the AICPA to finalize the work program for the SOC 2 and SOC 3 reporting format. Check with your auditor for additional guidance.

16 Apr 2011

Resources Tom Hinkel 1 Comment

SOC Report Selection & Evaluation Aids

With the SAS 70 phasing out on 6/15, financial institutions have a dual challenge; determining the best report to request, and evaluating the report they are provided. To assist with this challenge, I’ve created two documents.

The first, or Step 1, is a SOC Selection Flowchart, which is available here. This will assist in determining the most relevant report to request from your service provider. Once you register your email address, I’ll automatically send the second (Step 2) document, the SOC Evaluation Flowchart. Step 2 is still under development, as the AICPA has not yet completed the audits guides for the SOC 2 or SOC 3.

You will also have the opportunity to opt in (or opt out) of receiving notice of future regulatory compliance resources, like webinars, white papers, etc. I hope you find the flowcharts and other resources useful.

Download SOC Selection Flowchart

22 Feb 2011

Hot Topics Tom Hinkel 1 Comment

AICPA finalizes SAS 70 replacement

I wrote about this here as well, but it’s now official: The AICPA has clarified the SAS 70 replacement reports. They are actually officially being referred to as “Service Organization Control Reports (formerly SAS 70 reports)”.

The new SOC reports provide a framework for auditors to examine controls and to help senior management understand the related risks of outsourcing to a service provider.

According to the AICPA:

“Companies had misused SAS 70 to issue reports on controls related to outsourced non-financial data rather than the correct attest standard which was in place. The SOC reports clarify which standard needs to be used and how it should be implemented to meet specific user needs.

SOC 1 reports are primarily an auditor-to-auditor communication which addresses the controls at a service organization relevant to financial reporting. These reports are restricted use reports and therefore are not designed for promotional purposes. – (This is the functional replacement for the SAS 70 only where financial controls are concerned.)
SOC 2 reports are in response to the rapid growth in cloud computing and data outsourcing, as well as the marketplace need for clarification on how reports on non-financial controls regarding information, such as data security, confidentiality and privacy should be structured. – (This will likely be the SAS 70 replacement for the vast majority of service organizations)
SOC 3 reports cover the same subject matter as SOC 2, but in a general use, short form format which may be freely distributed.”

Get used to seeing this logo instead of the myriad of SAS 70 logos:

SOC Reports

Most importantly, know what it is…and what it isn’t. Understand why your vendor chose one report over another, and determine if the report is relevant to you, and adequately addresses your concerns. The term “SAS 70” is mentioned 31 times in 8 of the 12 IT Examination Handbooks, so it is a critical element in how the FFIEC expects you to manage your vendor relationships. No word yet on how the FFIEC will address this going forward…

25 Jan 2011

Hot Topics Tom Hinkel 0 comment

Top 5 Compliance Trends for 2011 – Part 3

What do Social Media, Cloud Computing, Virtualization, Data Vaulting, Mobile Banking, and Core Services have in common? For most community financial institutions, all these products or technologies involve outsourcing, either wholly or in part.

When it comes to offering the latest products and services, outsourcing allows even the smallest institution to compete with the largest. And outsourcing makes sense, because it means that you don’t have to build and maintain the infrastructure yourself. As the FFIEC stated in their 2004 guidance “In many situations, outsourcing offers the institution a cost effective alternative to inhouse capabilities.” But the FFIEC also makes it clear that you are still responsible for the security of the data wherever it may reside. So given the increased reliance of financial institutions on outside vendors, and the regulators’ expectations, my third regulatory compliance trend for 2011 is:

Vendor Management

This is based on the following criteria:

A recent interview with the head of regulatory compliance with the FFIEC made it clear that new technologies like social media require overwhelming reliance on third parties.
The FDIC changed Part 5 of their IT Examiners Questionnaire from GLBA to Vendor Management
The largest recent data breaches were with third-party vendors (i.e. Heartland), not the financial institution itself.
The Bank Service Company Act requires financial institutions to report all service provider relationships that directly support banking functions. IT vendors are one of the dependency layers that supports the business process, and as such MAY qualify as a direct support component. I addressed this here.

I had this as a trend for 2010, and I’m carrying it over for 2011 as well. I believe that there are some very compelling reasons why the regulators will (and should) increase scrutiny in this area as asset quality issues abate. In the meantime, don’t wait. Update your vendor management program now. Include an analysis in your vendor risk assessment to determine if the vendor should be considered “reportable” under the Bank Service Company Act.

And as you request their third-party reviews, bear in mind that the vendor management process will be a bit more challenging this year with the phase-out of the SAS 70 report. There is some speculation that the new SSAE 16 will become the functional replacement, but be prepared to review and interpret whatever report the vendor provides you.

UPDATE: For further guidance, refer to the Outsourcing and Supervision FFIEC IT Handbooks.

← Previous 1…567 8 Next →