A vendor breach can be every bit as devastating as a breach taking place within your own enterprise.

It’s late Friday afternoon and mentally you’re out the door for the weekend, until a phone call from your biggest vendor informs you that they’ve been breached... their data has been compromised. A split second later your stomach flip-flops….their lost data is actually your lost data.

If your enterprise is like a great many of us, you are moving data offsite. Streams of information literally fill the clouds, constant flows crisscrossing the world in never-ending migrations. We outsource data for many reasons:  processing, storage… and more. But once your data arrives at its new home… how secure is the vendor?

Taking it on faith that your business partner is utilizing safe practices is at best naïve. Like Hansel and Gretel happily strolling into the witch’s gingerbread house, we tend to visualize our vendor through rose-colored glasses. They’re the experts –  they host dozens of companies, right? What can possibly go wrong?

Suddenly though, there’s a data breach. Prized data has been handled as confidentially as recycled junk mail!

While no enterprise’s processes are identical, there’s a checklist of items to follow to safeguard our data.

Step One: Vetting Your New Vendor

Vet him/her as thoroughly as you would a new employee. The relationship is similar. Your customers have entrusted their personal information with you, and in essence, you’re giving the vendor – just as you would your employee – the keys to the castle when you outsource that confidential client data to him.

Ask yourself: who selects the vendor? Is it your IT area or the business side? All too often, it’s exclusively a business-side decision. This is a recipe for trouble. We understand that business drivers are important, but the IT department’s ability to add technological advice is vital to the selection process.

Remember, as you vet the potential vendor, you’re building a risk-profile. Clearly, this relationship works best when the risk is low. If the data’s compromised, it’s all the same to your client. His/her personal information has been compromised.

Whittle that risk down as much as possible. Here’s some thoughts on vetting that provider:

• Will the application be hosted internally or externally? Today’s discussion focuses on data-sharing, but clearly this is a non-issue if the data your internally-hosted application uses never leaves your company’s doors. Your risk profile just got quite a bit smaller!
• What type of data are you sharing? A breach is a breach, but some breaches have more implications than others. We need only consider lost credit card data and the accompanying PCI ramifications to appreciate this. Ask yourself (and ask the prospect): is the vendor PCI compliant? Have they met HIPAA guidelines… other business-specific standards? Is an SSAE-16 on file and available? And, remember, today’s business drivers shouldn’t be your only barometer. Look down the road too. Is the data that’s out-sourced now representative of what your business area will want to send a year from now? No one has a crystal ball, but some forward-thinking now can save a lot of headaches later.
• How is the data moving across the transom? A VPN connection helps with data encryption and is generally more secure, but how practical is it? If your vendor is using older technology, that can come back to haunt you.
• What happens to your data after it reaches your vendor? Is it stored separately, or co-mingled with other firm’s information? Is the data securely protected (think firewalls, IDS, etc. here). Who has access to that information? Is it sold or otherwise moved off the vendor’s site? These questions give rise to others, such as: is your prospect’s disaster recovery plan current and tested regularly? Their data breach plan? Most of the questions you answer while reviewing your own organization’s security are questions you should pose to the prospective vendor.

Let’s assume you’ve answered these questions to your satisfaction. You’ve chosen a vendor. Naturally, your business area is frothing at the mouth…anxious to book deals and make money! Time to sign the contract and send some files? No, not quite. While you have a clearer understanding of what your vendor offers, you and your business areas have another job to complete, which is easily as important as Step One.

Your enterprise must establish just what the provider (and your firm) is responsible for in this new relationship.

In the event your vendor is breached, no agreement (or an agreement where your firm is left holding the bag), is practically worthless. Weak agreements are probably all too common.

When to negotiate that agreement is all-important too. It’s hard to overstate how important it is to assign these responsibilities at the onset. Your business-seeking vendor is going to be more motivated to work with you on this now than he will be after the deal’s signed.

Terms of the agreement are often in flux, though. No one size fits all. Each side wants to protect its own interests, and negotiations can (and will) move in wildly different directions.

From your perspective though, the contract takes on deeper significance when you consider the following:  in the U.S., there isn’t a specific federal law watchdogging third-party collection and use of personal data.  A short list of regulations addresses parts of the issue. Note the word ‘‘parts.’’  The Consumer Privacy Protection Act of 2015 (Federal Privacy Bill S.1158) is a more focused attempt at the problem, but at the time of this article the Act is in committee…its status uncertain. In the meantime we struggle through the miasma of state and federal regulations that make up today’s environment.

Needless to say, in a perfect regulatory environment a well-written service-level agreement is important. In the less-certain atmosphere we live in today, a strong SLA is even more critical.

Step Two: Establish a Strong Service-Level Agreement

A rule of thumb as you track through this process: while financial responsibility may be assigned, the regulatory liability remains with you. Your organization is responsible for the actions of the vendor you’ve chosen.

Here’s some steps to consider while drafting your SLA.

1. Define the timeline in which you will be notified in the event your vendor is breached. This goal here can be summed up with a few simple words….the sooner the better.  Worst case scenario: you read about the breach online. Your phones are ringing… calls from angry clients asking you about suspicious charges on their accounts, and your manager’s outside your office with HR and a packing box. Make sure your vendor is notifying you well before the event’s gone this far. Agree in writing on financial responsibilities. Indemnify who pays for incident investigation, legal fees, fines, claims, etc.
2. Consider requiring whether your vendor should have cyber-liability insurance and if some of that coverage may be extended to your organization.
3. Ask your vendor for a copy of their Security Policy. This may be proprietary. If so, they may be reluctant to furnish the document. If available though, this should help answer many questions that deal with the safety of your information.
4. Try to establish whether your data is co-mingled with that of other organizations? It probably will be. This may not be a risk in itself.  On the other hand, it could be. At the very least this implies that more third-party employees will be accessing your information (do you really want a long list of people pulling up your data?). Worse, it implies that there’s more potential chinks in the armor, which are more opportunities for a breach-inducing event to take place.
5. Make sure your vendor is vetting its employees. Are background checks and non-disclosure agreements part of the provider’s hiring practices? You may have answered this while screening the vendor. If not, be sure to review as part of the SLA.

Other details to examine include:

• Is confidential data encrypted at rest?
• Is that data masked when viewed?
• Does the vendor utilize role-based access practices?
• Is vendor employee (and subcontractor) security training required?
• Vendor email policy, ‘‘saving to local machines,’’ digital certificates, password guidelines… How does the provider manage these?

The list only scratches the surface, but should get the thought processes going. It’s in your best interest to address these questions in the SLA.

Last, think about an exit plan outlining how you will securely and completely remove your data in the event you and your provider part ways. And what if the provider’s breached? You should establish who’s in charge of the breach investigation. The vendor’s the one who’s been breached, but it’s your data. Decide beforehand who’s going to be doing what.

What vendor procedures are in place for breach containment and forensics? The provider should have an incident response plan in place. Are you able to get a copy? That plan should be tested on a regular basis.

Also, ensure you receive timely, regular updates to events, investigations, and notifications taking place during the breach incident. Does your organization want to interact with the provider’s forensic investigator directly?

Step Three: Managing Existing Vendors with No SLA on File

Chances are your enterprise has at least a few provider relationships that already are on the books. If that’s true, your organization may not have a service-level agreement with these firms. You may still be able to work out a late-breaking mutually-beneficial SLA with the vendor. A signed agreement is the best insurance you can have.

Realistically though, you might not be able to negotiate an agreement. If not, you still have a responsibility to your client and their data! At the very least, conduct a service audit of the provider to determine how they are managing your information. At a high level your audit should include at least the following:

• Vendor security – platform security (firewall, IDS, etc) and physical security (building, employees, etc.)
• Data management – encryption, RBAC, data transmission and other considerations.

Suggestions outlined in Step Two will offer a good lead-in to the questionnaire. (Note: keep pushing for the SLA! In the meantime, be sure to put this audit on your calendar and conduct it at least annually  – more often if there are changes in your organization-vendor environment.)

While the audit doesn’t give you the assurance that a service-level agreement offers, it does demonstrate some due diligence on your part. You may decide to switch providers after a look at the audit results! Forewarned is forearmed, and in the event your vendor is breached, the audit gives you a better understanding of your exposure.

The fallout from your organization’s unanticipated, unprepared breach of vendor data isn’t a very happy place. Don’t let it happen to you!