February 29 was an important day for a lot of companies. It was the day the European Commission and the U.S. Department of Commerce released the text of the EU-U.S. Privacy Shield, which thousands of companies had waited to read ever since Safe Harbor was declared dead by the European Court of Justice. For U.S.-based Merck, however, the following day was the real clincher. That's because on March 1, Merck became the first company to achieve approval for its Binding Corporate Rules based on the APEC Cross-Border Privacy Rules program.
Doing so saved the company both three-month's time off the average time for EU BCR approval as well as significant cost, said Merck's chief privacy officer, Hilary Wandall. And while it may sound like kind of poor timing to finally get a view of a potentially appealing data-transfer mechanism the day before the one you'd pursued gets approved, Wandall said it was in fact an excellent turn of events.
"The timing couldn't have been better," she said. That's because, as it turned out, everything Merck had done to comply with the requirements of the CBPR-based BCR meant compliance with the Privacy Shield was essentially automatic. "There's a tiny little bit of stuff we'll have to do more just in terms of writing text and adding it to our policy," she added, but basically, it's all there.
Wandall said there's a benefit to getting the CBPR approval first, and then turning to the EU BCR. Back in 2010, Wandall looked at BCRs and realized it was going to be an uphill battle for Merck. Not having an EU headquarters, it would be difficult to decide which data protection authority to submit an application to and to set up the required internal governance to support it. The CBPR system differs from EU-based BCRs, in part, because it doesn't require the establishment of internal enforcement structures; rather, it's enforced through the Cross-Border Privacy Enforcement Arrangement.
So when you start with CBPRs before heading toward BCRs you don't have to worry, "'How do I make this legally enforceable in a way that's recognized among APEC member economies?,' because that governance and enforcement structure is setup as part of the system," Wandall said. "So it's just simpler to start there for companies who don't have a lot of legal resources to figure that all out."
Plus, CBPRs' data protection safeguards are explicit in terms of what's expected to demonstrate compliance. It's easy, relatively speaking, to map to. In fact, it would take Wandall just a month to finish the application before handing it over to TRUSTe, Merck's "accountability agent" in this case, to look at.
Chris Babel, CEO at TRUSTe, said working with Merck on the achievement was exciting because "for the first time, we were operationalizing something that had been theoretical until now."
While it took Wandall just 15 months from start to finish, Babel said timing depends on how prepared an organization is as well as the scope of the data you're certifying. Some companies, for example, may choose only to apply to transfer a certain slice of data rather than any and all data collected. But in any case, this situation was different in that it was the first time a company was using the referential, a pragmatic checklist released at the IAPP Global Privacy Summit in 2014 by the G29 and APEC countries that aims to help companies seeking double certification under both EU BCRs and APEC's CBPRs.
So TRUSTe sat down with both Wandall and Merck's outside counsel, Covington & Burling, to take on this new methodology.
Wandall was clear: There are some bumps that need to be smoothed out in how to make the referential practical for companies.
"It's very hard to use as it exists," she said. "We did an enormous amount of mapping. It's good text conceptually, but in and of itself, it's not useful for the purposes of doing a very robust mapping of your internal requirements to see if you're actually meeting the standards."
There's plenty of good commentary and references, Wandall added, but, what the team really needed was excel spreadsheets and tables that allowed them to map how their existing standards aligned both to CBPR to BCR requirements and how the responses we provided on our CBPR application could be reused on our BCR application. Word on the street is, however, that the APEC data privacy subgroup is working on making those checklists a bit more user-friendly.
For the BCRs, Merck used the Belgian data protection authority as its lead, and the UK and French as secondary approvers. Wandall said she started talking to her Belgian Commission contact, Isabelle Vereecken, early and often to establish a relationship, and she flew to Belgium twice to meet in person.
It's a strategy Vereecken appreciated.
"Our work is to check if the commitments and privacy program are in line with the Article 29 Working Paper 153, listing the conditions for BCR controller," Vereecken said. "Merck's CPO and its law firm were very proactive and always replied quickly to all information requests and comments we sent to them. Their response was one of the fastest we have experienced in BCR matters. They even reacted around Christmas and New Year, enabling a fast and effective progress in the BCR review process."
Aside from communication, Vereecken said regulators appreciate early contact, meaning a company seeking a BCR should seek a preliminary meeting with their DPA, even before submitting the BCR application, as Merck did. It signals a commitment.
"Things are so much easier when a company has taken the decision at the board's level to take privacy issues seriously and commit to complying with the EU level of data protection," Vereecken said. "[A] DPA would probably be more inclined to consider the particular needs of the company where it would have shown good willingness, i.e. being ready to cooperate and meet the DPA's expectations, enabling a constructive conversation."
Now that the goal's been met, however, this isn't the end of the story. The goal simply shifts to annual compliance.
"It's not just getting the thing in place, but it's, 'How do you maintain this every single year?'," Babel said. "I think too often in privacy, we focus on objective: 'I need to get my Privacy Shield.' The operationalization of the process to keep you compliant is an afterthought to that point. But if you haven't thought it through up front, you come to that 'Oh, crap'" moment.
But he acknowledges Wandall has put her company in a good spot, compliance concerns aside.
"She now has a single unifying process for a company as big as Merck," he said. "That, for me, is the really special part. Yes, someone got their BCR fast, and that's a big part of the story. But operationally, she's in a better place because she has tied things together in a way that's one, cohesive methodology."
Wandall agrees. She said companies seeking a similar outcome should ask themselves if they want to operate with both a high level of assurance in regards to privacy compliance and, if so, if they want a single program within their organization to facilitate that.
"This is a way to do that, not only establishing the program but to get recognition from regulators all over the world. Starting with CBPRs, if you're a U.S. company and do business in Europe and APEC economies, is beneficial because it really does set up requirements in ways companies just looking to start out can then map to more easily than they could with BCRs," she said. "There's a lower barrier to entry."
Looking at the big picture, Wandall said now that she's been through the process, she's hoping to help other companies get there, too.
"I worry for small- and medium- sized enterprises that BCRs or even CBPRs right now might seem too hard or not clear enough," she said. "My goal is through our achievements, we can make this easier for small- and medium-sized enterprises that most of us work with and rely on as part of our supply chains. And in so doing, we can get more of them into the ecosystem and build the trust within the overall ecosystem of data being shared globally."
photo credit: Soybean Oil via photopin (license)
If you want to comment on this post, you need to login.