How To Think About Buying Privacy Technology
• read
Determining the best privacy technology for your organization can be overwhelming. As Alyce director of data security and governance, Jeff Mayse notes, “it touches every system, and crosses all borders.” In other words, choosing, implementing, and maximizing the value of privacy technology for both external and internal stakeholders requires careful consideration, planning, thoughtful execution, and management.
Joining Mayse to examine How to Think About Buying Privacy Technology, is his colleague Andy Dale, General Counsel and CPO of Alyce and WireWheel’s Director of Product Marketing, Emily Schwartz. Held at the 2022 Summer Spokes Technology Conference (June 22-23), this wide-ranging discussion was moderated by Kevin Donahue, Sr. Director, Privacy Engineering at Ethos Privacy.
Identifying the privacy tech value for external stakeholders
Often, clients will say, ‘we have to do data subject rights (DSAR) so we’re going to look at some solutions.’ But, there’s a whole lot of elements to doing data subject rights from ingestion, validating, and finding their data, to tracking things.
It’s not just one big black box, it is an entire workflow needed to satisfy their users.
—Kevin Donahue, Ethos Privacy
It’s important, suggests Dale, “to understand what it is we’re trying to do – not from a technical perspective and not from a GDPR or CCPA perspective – but the business problem or solution that we’re trying to get to. That helps all your privacy champions around the business get context and understanding.
“Law and regulation don’t really move the needle as much as folks like us might think it would. Risk surface area doesn’t do that either. What does move the needle is customer sentiment. “I don’t think everybody starts there. There is a tendency to dive right into spreadsheets and data mapping.”
Identifying the privacy tech value for internal stakeholders
“It’s really hard” he continues, “to work towards a successful outcome if everyone’s not on the same page from that 30,000-foot view. What are you trying to do and what are the impacts? This includes the internal stakeholders as well.”
“If you neglect any aspect here – external or internal– you’re at risk of pain. This is one of the most complicated systems that you will implement at a company,” warns Mayse.
It touches every system. It crosses all borders. It has no domains. And it can quickly spiral out of control.
You need to consider your internal users, at least as carefully as your external users. And when we talk about implementation, it is easy for this to become a problem.
—Jeff Mayse, Alyce
Mayse insists, when you understand what that process is like for both internal and external stakeholders, and what that would look like with privacy technology versus without, it’s easier to sell internally.
“As time wears on, I think it’s going to become increasingly clear that there are internal stakeholders benefits [and this] needs to be part of the equation,” adds Schwartz.
Buyer be aware
You can sell into legal. You can sell into a separate privacy function. You can sell into privacy engineering, into InfoSec, into the CIO, and you can sell into the IT department. There are too many vectors, too many personas to think through.
It’s a good idea to encourage the buyer, once they’ve engaged in that cycle of learning about the software, to bring a lot of relevant stakeholders to the table.
—Andy Dale, Alyce
That includes stakeholders like business intelligence and analysts who “need to pull data out of the product and manipulated somewhere: it is truly everyone,” notes Schwartz.
“When you start talking to every team in the company, the magnitude of the problem can become overwhelming,” cautions Mayse. “So, it’s not only important to bring in internal stakeholders…and raise issues early, but also to constrain the problem. You have to eat the elephant one bite at a time.”
It is critical for buyers to have this awareness.
Accepting that sales call without knowing what it’s going to take to implement a solution and how to perform the initial step of the development lifecycle when you’re evaluating build v. buy – if you don’t have somebody functioning in a product management role it can be very difficult to get it accomplished.
—Jeff Mayse, Alyce
Interestingly, both Dale and Schwartz have found that when it comes to awareness, the learning curve is much steeper in larger organizations than it is in the small and midsized firms (SMBs).
At Alyce, a privacy technology consumer (and WireWheel customer), they think about what they need to do first, relates Dale. “What engineering work needs to be done here to make sure that we’re even in a position to buy privacy tech?
“The issue is always, what do we have to solve first? What is our workload to implement a solution? There’s this myth about technology in general: buy it, turn it on, and magically it just happens.”
Privacy tech success metrics
How do you define success?
Privacy people think of success as ‘I’ve deployed a tool to do something, because I want to do that thing.’ And it’s oftentimes somewhat divorced from other stakeholders, whether it’s engineering, marketing, infrastructure teams, or even the users themselves.”
—Kevin Donahue, Ethos Privacy
“It comes down to why you bought it in the first place,” says Mayse. “What you wanted to achieve. You went in with a problem – maybe an intangible – but you have a problem that you’ve defined.”
“How do you track that problem now? Do you have a process for DSAR ticketing details and following through on the fulfillment through all systems and tracking time? Simply deploying a solution isn’t ‘the solution.’”
Pointedly, Mayse asks, “How did you measure the problem? Presumably you had to get dollars for this and justify the spend. How did you sell it internally (this is an $X/year problem, or a $Y/year risk surface). You can track against that.”
“One of the big ones for Alyce has been ‘time of effort.’ If it took you so many days/hours/minutes to fulfill [DSAR] requests, what does that look like after you buy the service? How many are you able to accomplish with how many people working on them?”
Sometimes it is a little bit of trial and error.
With experience you start to realize what is truly important. It may also be things like how the privacy technology integrates into your stakeholders workflows and processes. Is it efficient for your team? At the end of the day, a lot of this is about managing risk.
—Emily Schwartz, WireWheel
“Look at this through a risk lens,” offers Schwartz. “What are the building blocks that contribute to an acceptable risk profile for your organization and measure those.”
Project managing privacy tech: it’s all about communication
“There’s a big language challenge between legal and engineering,” opines Dale, “particularly in the privacy world where we live in the grey. Engineers and product teams, want the requirements. What are the milestones? What do we need to deliver, and the metrics behind it?”
“It’s going to be a little bit of iteration, trial, test, and learn as we go. But clearly discussing how this is a grey area can increase velocity in these projects.”
“You need somebody who can help translate the legal principles,” says Mayse. To draw lines in the grey legal sand and say “‘on this side of the line we think this is a good faith effort that’s compliant with the law’ while knowing that legal decision may indeed change. This must be translated into something that an engineer can build, or a product manager can run.”
Having embedded privacy champions in a development team really helps. It becomes a bi-directional communication between privacy (or compliance or legal), and the engineering team. In this way, engineering can communicate what they need from privacy to work effectively.
—Emily Schwartz, WireWheel
Evaluating privacy technology
“One of the most beneficial things you can do is ask your peers what they’re using, what they’re doing, what’s working for them and what’s not,” proffers Schwartz. “If you’re working with an agency or a consulting group, ask what they’re implementing for their clients. It shows what’s working what’s not working.
“You can do all the research in the world and see all the demos in the world, but just word of mouth and referrals are very powerful.”
My superpower recommendation is – while maybe not in the first call – when it comes to the demo, and especially to the technical discussion, bring an engineer who will ask questions you didn’t think of asking.
Those questions will be necessary, because an engineer is going to immediately start thinking about how they would actually do this…You can have an engineer say, ‘we won’t build this, it’s not going to happen,’ and you want to know that.
—Jeff Mayse, Ethos Privacy
“There is a lot of the tech… a lot of it does the same stuff, so I would have a list of your top needs and priorities,” avers Dale. “But if you’re not attentive to it and if you don’t have a person that is going to learn and administrate it,” he cautions, you’re going to get nothing out of it.
“It can be the best software in the world, but any system requires a lot of TLC to get the most out of it. So go in knowing that it’s going to be a system you need to spend time with. Otherwise, you just won’t adopt it and you won’t get value.
“You’ll turn off that software and you’ll try another one. And if you don’t change something, the same cycle will happen again.”
