Punit Rajpara is Head of IT and Business Systems at GoCardless. In this Q&A he tells us how GoCardless won over the entire organization—from employees to board members—with their forward-thinking data loss prevention (DLP) program.

Dig deep into the intuitive and effective user warnings, powerful analytics, and reporting tools that helped prove their business case.

Could you please give us a quick introduction to yourself and your role at GoCardless?

I’m the Head of Business Systems at GoCardless. I’ve been here just over a year—joined at the crazy pandemic time so it’s been an interesting year. Plus, prior to GoCardless, I was at WeWork and Uber, so I clearly love the hot startup journey and putting in core tools. GoCardless is in the space solving for payments—so whether that’s recurring or one-time payments.

We’ve just really done some really cool stuff at the Urban Bank and you should check it out. We service payments across 30 different countries and we process about 20 billion in revenue for other merchants every year.

DLP can be a really daunting project, for many. At GoCardless, was your starting point in DLP?

Yeah, I think I’d say boring and daunting. It’s one of those things that just kind of there, and it can be disruptive to users. So, I guess our starting point was we… like I said, it was kind of just there. We used Google DLP to kick off, and the inbuilt DLP tools, and we found those a little bit complex to configure.

So we’re coming to this realization—just when everything just happened and we went to market—to look for somebody better. We realized it needs an admin of its own—it’s just configured a bunch of policies that just block stuff for our users all the time. And it didn’t seem very “user-in-mind.” So that’s our starting point: Google-based DLP tools. A bit boring, a bit daunting, like you said, and just… there.

What was it that instigated you to start thinking: “OK, we need a new approach”?

We had an incident where somebody sent a file to a friend, instead of to the right recipient. And we got a bit lucky, where the friend said: “Oh, did you really mean to send me this file?” and it was an important file that probably shouldn’t have gone to the friend. And the person that caught that and came straight to us and said, “Hey—do we have a way of stopping me from sending things I shouldn’t to the wrong people?” And we’re like: “Maybe… Let’s go and have a look at it.” 

So, we weren’t intentionally looking at DLP, but it’s one of these things where it allows us to be used a little as well, so users will come and talk to the problem, and go: “Hey, I’ve made this stupid mistake—what should I do?” and “Can you do anything to help me not make that mistake again?”

So, that’s what really led us down the road of going: “We should look at this problem. We should look at inbound and outbound DLP and see if we can make it easy for our users not to do things that are going to be harmful to them and the business.”

How have you got your employees to that state, where they’re actually coming forward and saying “Hey, how can we stop it going forward?”

I think it’s part of that kind of scale-up workforce culture, where people are expecting not to do things by themselves constantly. If you look at all aspects of… mostly business systems and IT, there’s a huge focus today on ultimate automation and self-service. So people are used to working in organizations where you’re not having to report things, you’re not being blocked by things, you’re really being enabled to just go on with your work.

And the expectation is that IT teams and business teams and security teams are becoming more and more “self-service,” and putting the control in the hands of the users. And that just really allows people to not worry about these things, and just get on and just be productive and work.

What were you looking for when you set out to try to find a security partner?

When we went looking for the right partner, the things that were front-of-mind were: whatever we chose had to be easy to use, it had to be easy to implement, and it had to be easy to administer. I was managing a small team last year, so it couldn’t be anything that required tons and tons of work for my team to implement.

It couldn’t be something that required tons and tons of documentation to be written. It couldn’t be something that required using huge amounts of user training. 

It had to be quick, easy to use, quick to deploy, easy to deploy, with a lot of support from the vendor will be required to get it out if we need that support, and it had to be self-service. It will have to be really really intuitive. So that’s our approach to how we were looking for the right partner. I think it actually hit the nail on the head with Tessian… 

How was the feedback when you implemented Tessian? How did you garner that feedback and how did it change their perception of what security controls can be like?

I’d say overwhelmingly, there was a positive response to our deployment of Tessian at the business. People—especially the exec team—would come into us quite quickly and say: “Hey, this is really cool. We’re going to stop data leakage.”  We were able to catch a couple of incidents that we maybe wouldn’t have otherwise, so overwhelmingly there was this really really positive response: “Hey, this tool is really awesome, didn’t know we could do this kind of stuff.”