We spend an enormous amount of time talking about the benefits of data partnerships but, of course, they aren’t without their risks. No one enters into a business relationship assuming that everything will go exactly as planned (without serious problems later, anyway). But how do you identify ways to protect your business, your data, and your efforts when establishing a data partnership? In this excerpt from Data Leverage, we’ll highlight some of the ways you can do precisely that.
Taking a Tailored Approach
You should build specific elements related to data protection into your data partnership agreements. These explicit approaches help deter bad actors as well as keep even the most well-intentioned partners from straying later. Often, the people who create or negotiate a data partnership are not the individuals that will build the integration, oversee its deployment, or monitor the financial relationships it creates. And the longer a partnership is in place, the more likely it is that the people who set it up originally won’t even work at those companies anymore. Because of this, you should use the tactics below to ensure the protection you intend for each partnership.
It should go without saying, but too often, it doesn’t: the contract you execute with your partners needs a thorough legal review, and depending upon which data partnership structure you are entering into (mutually beneficial, innovator, or channel), your contract needs to preserve your ability to protect your data assets and your business reputation. Focus on the ways that data can and cannot be used rather than just the technical discussion surrounding the methods of delivery. Too many contracts in the data world spend inordinate amounts of verbiage on the data transfer method, because the IT department has hijacked the legal documentation. Remember, if it was FTP yesterday, and API integration now, in 10 years it could be — who knows? — a holographic handshake. The point is, your contract can state a mutually agreeable approach to data transfers, but it should focus far more on data usage, rights, and access.
In general, a data agreement should outline its specific purpose clearly. For example, you may be providing data for quality purposes, for matching purposes, or for the creation of a derivative dataset that combines your data with the partner’s data. Each of these is an example of a specific use case that determines the partner’s permissible use of the data. Be mindful, in particular, of derivative data rights, as covered chapter 8.
Next, focus upon the confidentiality of terms in the agreement, including pricing. The contract itself is confidential, but be sure the language specifically outlines how your relationship with each data partner is confidential.
With legislation like the GDPR, the California Consumer Privacy Act, and the wide array of regulatory requirements put in place each year, you must ensure that your data partners adhere to all applicable regulations as they handle your data, or you handle theirs. Going down with the ship is not a great strategy here, and we recommend that your DPO review your data partnership contracts as part of your company-wide dedication to compliance.
There are too many terms and potential caveats to name when discussing legal protections for your data partnership. That said, don’t let your legal team or your partner’s legal teams derail a great opportunity. The best attorneys we have worked with have been open and honest about their lack of topical knowledge when it comes to their clients’ data, so they tend to accept their role as identifying the security and privacy issues and not necessarily the nitty-gritty detail of datasets or data security.
Contractual Reporting Rights
One of the best ways to ensure that a data partnership goes well is to incorporate mandatory reporting metrics into the contract. Specify the minimum number of fields; values or categories of data; and cadence needed to ensure that both parties are upholding the contract. Many data platforms, like app markets and reseller channels, have sophisticated reporting engines already built into their systems that allow for timely or even real-time reports on usage, access, and financial projections. Other partnerships include elements like data matching, appends, or crosswalked data connections that change as the two datasets you are aligning evolve. In those cases, you typically agree on an average number of records or a “high-water” mark for a given time period of usage, which would set out a usage maximum.
What do you need to confirm that the data partnership is working? You need agreed-upon parameters that outline success, including reporting on metrics like records viewed, fields downloaded, matches made, or customers signed. Your contracts should require a meeting between the two partners, at least quarterly and ideally face-to-face, to review the progress and reports from the partnership together. These meetings are well worth the effort and help to maintain a healthy relationship. Remember, there are no shortages of substitutes for datasets these days, so maintaining a transparent reporting regime with your partners through face-to-face meetings is imperative.
Jim Barksdale, CEO of the original browser company Netscape, once said, “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” We love this quote because it is so true. So many times, with new management or new relationships, opinions can crowd out the realities of a data partnership, so make sure that you build in contractual obligations to share all necessary reporting data.
Companies dislike audits. Many a data partnership has died on this hill because one of the companies refused to give or get the right to audit their partners’ use of their data. To be fair, a data audit is usually not nearly as difficult or intrusive as a financial or accounting audit, but many lawyers don’t understand the difference. Depending upon the total value of the data partnership, audits may not be worth it. That said, the right to bring your data audit team to a partner to ask for simple access controls, use cases, and account verifications is reasonable, particularly in mutually beneficial data partnerships where the partners are of similar size and reputation.
Weigh the value of this right against the cost. You may find that a compromise is possible — not through a typical audit, but through the less disruptive right to scrape or crawl a partner’s platform. Normally, the process of crawling and scraping, in which a partner uses a bot to read all the structured data on a page and stores it for their own use, is a touchy subject. In this case, you can get valuable insights from identifying the usage of your data within the partner’s platform. We have seen this approach work to generate “audit-like” data on the usage of your data, so long as you agree not to retain other data gathered from the scrape.
Other Creative Protection Methods
Mystery shoppers and seed data are two methods that can help you protect your data assets. With mystery shopper rights, you are essentially asking for the right to pretend to be an interested prospect of your data partner’s services. Although these rights don’t have to be specifically outlined in a contract, we recommend that you add something to your agreement or at least let your partner know that you conduct these exercises. Companies are not fond of having their sales or service resources drained for someone who is only pretending to be interested. It’s justifiable because the only real way to understand how a data partner is using your data or representing your data is by convincing their staff that they are pitching a real potential customer.
The second creative approach to data protection is the use of seed data. It should probably be called “weed” data because the whole point is to spread seeds in your data to see where those weeds pop up downstream. In this creative approach, you implant small amounts of fake data into your data files. This data is identifiably unique in its format; for example, a street address that doesn’t exist, or a product description with your founder’s name spelled backwards in it as an ingredient. The point of this fake data is that you can then search for these terms or unique data points in other databases and on other platforms, in much the same way that mapmakers used to insert false town names or geographic features into their maps to help identify if a competitor was selling a copy without a license. If you find your seed data in another database, then you can identify which partner you provided those particular seeds to, and work with that partner to find out how your seed data ended up on another platform without your consent.
You must build in contractual permission to include seed data; data partners do not take kindly to learning that you’ve been supplying them fake data. If you are delivering 1 million records and 24 of them are fake seed data, you should let your partners know you are doing that. Just don’t tell them which records are fake.
Ultimately, there are many methods and tailored approaches to ensuring data privacy as a part of your data partnerships; the former shouldn’t even exist without guarantees of the latter. Taking time to develop an approach for data privacy concerns at the outset of a relationship is one of the few ways to minimize the risks that you’re doing so, later, as damage control from a breach or in a lawsuit.