How Boston Scientific Lowered TCO of Credit Card Acceptance and PCI Compliance

Transcription

1 How Boston Scientific Lowered TCO of Credit Card Acceptance and PCI Compliance Heidi Dallal, Boston Scientific Eric Bushman, VP, Solutions Engineering, Paymetric

2 In This Session: Examine the innovative approach used by Boston Scientific to reduce the cost and scope of PCI compliance Receive an inside look at how the company: Leveraged integrated, on-demand payment processing and tokenization methods to achieve PCI compliance Removed sensitive data from its own systems, eliminated server maintenance requirements and reduced the scope of PCI DSS* compliance Integrated multiple payment processes to ease the burden of compliance Implemented and adhered to a strict project timeline * Payment Industry Data Security Standards Card

3 What We ll Cover Business Case Factors Considered Outcome Results Ongoing Challenges Wrap-up

4 About Boston Scientific Founded in 1979 World-wide developer, manufacturer and marketer of medical devices used in a range of interventional medical specialties Corporate headquarters located in Natick, Massachusetts Publicly-held company (NYSE: BSX) Products sold to multiple business units

5 About Our SAP Software and Transactions ERP Platform: SAP R/3 4.7 All transactions are Card Not Present (CNP) All in USD 50,000 transaction per year

6 Credit Card Processing Environment Platform: TSYS Payment card acceptance and integration solution Fully hosted on-demand solution that provides: Enhanced reporting Receivables management Level II and level III processing Security Fully hosted tokenization solution

7 Business Case: Three Main Drivers Decision Time: change or don t process credit cards Out of compliance with PCI DSS Existing solution at end-of-life and out of support Leverage resources and implement Level III (line-item detail) processing for benefit of interchange optimization

8 Business Case Reduce scope of PCI DSS audit Move to short form Remove sensitive data from Boston Scientific environment Remove all of the maintenance associated with sensitive data Choice to go to Level III at the same time to reduce fees Eliminate encryption key and application maintenance requirements

9 Factors Considered Limited scope to SAP-certified solution providers only PCI DSS self assessment audit footprint Unless we moved to a fully hosted SaaS solution, there was no way to get the audit short form Hosted on-demand versus on-premise solution Did we want to be in the business of managing sensitive data?

10 Factors Considered Analysis of maturity and experience of vendor in the SAP credit card processing solution space Quality of back-end user support Single source provider Tokenization Storage of secure data Processing

11 Factors Considered Size of the solution provider support organization Level of SAP integration experience Application of service maintenance Software updates Patching Security Hardware Updates People

12 Implementation Goals Go-live within 60 days Replace encrypted credit card numbers with tokens Eliminate need to maintain application server Transmit line-item detail (Level III) data at settlement

13 Before On-demand Payment Acceptance

14 Outcome Results: Integrated, On-demand Payment Acceptance

15 Outcome Results PCI DSS short audit qualification Single source solution Flawless execution of implementation On time Under budget Flawless technically Level III saving in seven digits per year = huge Rate charged by credit card companies dropped by more than one percentage point Incremental savings with AMEX Level II implementation

16 Outcome Results Decreased costs Reduction in PCI DSS costs Cost and resources required to populate the long form are eliminated Significant savings by passing Level III data (1.2% rate decrease in payment card service fees) Made BSC eligible for additional rate reduction opportunities from the payment card companies

17 Outcome Results Significant reduction for risk of breach Data and credit card information much more secure both internally and externally Total system efficiency and optimization due to tokenization Moved to PCI DSS audit short form Speed and quality of implementation due to thorough preparation

18 Key Learnings PCI DSS compliance covers a lot of ground Payment card processing is complex; there are a lot of stakeholders, and not a lot of people have experience in the space Involve business users early in the process Up front preparation will greatly reduce unplanned issues Understand your own business before you start What follows is a long list of things that would have been great to know and questions that would have been best if they were asked before we started

19 Key Learnings The following is the long list of things that would have been great to know and questions that would have been best if they were asked before we started: Understanding payment card processing Stakeholders Access Scope Know your business Infrastructure Testing

20 Understanding Payment Card Processing You must understand who is responsible for what Business, processor, card company, payment acceptance provider The more cards you accept, the more banks and processors you work with Integrating the capability with an ERP makes it even more complex PCI DSS compliance is much more than just secure credit card processing; it can involve your entire WAN, LAN and every server, PC, tablet, and smart phone connected

21 Understanding Payment Card Processing Learn what an authorization is Determine how long before an authorization should expire? If not, do you know who in your organization can provide an answer? It is not up to IS to decide Learn what a settlement is Identify each data value and formula you must pass for each card type Identify where in your own system you store required data Determine the maximum charge allowed by the card companies

22 Understanding Payment Card Processing Determine the maximum charge that your system allows Determine the maximum your processing solution can handle Determine the maximum your merchant bank will allow All four of the above need to be aligned Determine if you need to be concerned about rounding. Rounding issues may cause settlements to fail.

23 Planning Start your project planning early Determine your hardware and software needs upfront Get hardware ordered and installed before development work begins Recommended best practice is tokenization Reduce cost and scope of PCI DSS compliance Mitigate risk of a data security breach

24 Planning Determine if Level II or Level III is applicable to your business If yes, plan to implement at the same time to leverage resources. Data requirements for each card type may be different. Find that out up front. Bundled materials may require custom handling and it many be different by card type Batch split line items may require special handling and it may be different by card type Determine if you will process consolidated accounting documents For AMEX, the discounted rates are achieved using Level II data (more complete header level data)

25 Stakeholders Identify all of your stakeholders Business Customer service Accounts receivables IS and Infrastructure Processor Merchant bank Solution provider or providers

26 Access Determine who should be allowed access to raw payment card information. Note that this is different from those who think they should have access. Determine who controls access to this information Determine how this access will be controlled

27 Scope Remember that access to payment card information includes EDI transactions, faxes, voice messages, backup systems, nonproduction systems copies from production environments A DMZ for servers handling sensitive data reduces PCI DSS footprint and reduces risk Servers in a DMS complicate managing timely updates to software (including anti-virus) because by design they are more difficult to access

28 Know Your Business Understanding your own business matters Educate yourself about how credit card processing works Identify your merchant bank Engage your bank and processor early in the process because they need to plan for resources Determine if you qualify for Level II or Level III processing If yes, do you have parent/child relationships on invoice line items? Identify the individuals that process the transactions Determine which credit cards you will accept, as data requirements for each card may differ

29 Know Your Business Determine if you use credit cards at sales order entry (SAP SD module) Determine if you allow payment of invoices with credit cards (SAP FI module) Determine if you want to apply credits for returns to a card Do you combine invoices for the same customer into a single accounting document? (SAP FI module) Do you process cards in more than one country?

30 Know Your Business Do you accept payment cards in EDI transactions? You may have to tokenize as soon as the data hits your network to keep this information secure This may be before it even gets into your ERP Do your customers fax you card numbers? If yes, is the fax machine in a secure location with restricted access? Do you shred the physical faxes with the card numbers on them?

31 Know Your Business Do you have a fax server where the inbound faxes are digitally archived? Who has access to the faxes? Do your customers actually leave card numbers in voice messages? (The answer is probably yes ) Do you have existing card data archived anywhere? If you do, it needs to be in scope to meet PCI DSS compliance Do you copy production data to non-production systems and does it contain card data? You have to remediate that information too

32 Infrastructure You will almost certainly need to add a server to your network That server will likely need to be in a DMZ Plan for how you will get regular antivirus updates to that server You will need a development and a production box You will need to ensure that you can send secure transmissions (HTTPS)

33 Testing Determine what platform you will use Make sure you arrange to have dummy cards to test with For AMEX, you may have to contact them directly to set one up Identify the limits allowed in the test environments Different test processors have specific requirements for $ values Different $ ranges drive different responses

34 Testing Payment cards and consumer credit card are not identical. If you accept both, you need to test both Test everything! Be thorough and use the roles you will assign to intended end users when testing The merchant bank and the processor will need to be involved in end-to-end testing That means you need to contact them early to plan for resources

35 Ongoing Challenges Managing servers in a DMZ These are hard to get to by design so automated updates cannot be pushed to them Once established, payment card processing tends to be outof-sight and out-of-mind and is therefore often forgotten in other development This results in post-production remediation Problems are very rare (and almost always due to user error), so when they occur, you have to relearn things to address them Unnecessary customization comes back to bite you (ask me how I know )

36 Where to Find More Information Avivah Litan, Choosing a Tokenization Vendor for PCI Compliance (Gartner, August 2012) PCI Security Standards Council Website Paymetric s company website for white paper resources explaining tokenization usage in SAP applications

37 7 Key Points to Take Home Understand your business processes concerning credit cards Determine your unique payments needs Research all payment acceptance solutions to determine which best suits your unique needs Set implementation goals with your payment acceptance solution provider Proper internal preparation enables a smooth implementation process Tokenization is a best practice which enables you to reduce cost of PCI compliance and lower the risk of security breach Passing Level III data achieve significant savings

38 Questions Heidi Dallal Boston Scientific Eric Bushman Paymetric