Skip To Content

Privacy and anti-spam 101: Addressing risks and maintaining compliance

Mar 21, 2017

Emerging companies face a range of privacy and anti-spam issues that can arise at various stages of the business life cycle. Issues can come up during the due diligence and financing phase or even at a later stage when the company is being bought and it may be too late to address the risks.

In this presentation, available in both webinar and PowerPoint format, John Salloum, a partner in Osler’s Privacy and Data Management Group, provides you with information you can use to help identify and address privacy and anti-spam issues and associated risks as they occur. Topics covered include the following:

  • drivers behind privacy compliance
  • sources of privacy obligations (including privacy legislation, common law and privacy regulatory authorities)
  • definition of personal information
  • addressing privacy in the online/mobile context
  • social media
  • online behavioural advertising and guidelines of the Office of the Privacy Commissioner of Canada
  • Canada's anti-spam legislation (CASL)

Transcript

For more information, contact John Salloum, Partner, Privacy and Data Management, at jsalloum@osler.com or 416.862.6492.

This presentation is part of Osler’s Emerging and High Growth Companies 101 series, designed to help emerging ventures navigate through the various issues and legal requirements they will encounter throughout their growth cycle.


Video transcript

SIMON LEITH: So I'm Simon Leith. I know many of you and wanted to just welcome everyone to our second session of our Lunch and Learn series. Many of you were at the last one, last month on employment issues.

And today, we're fortunate enough to have John Salloum, who's a partner in our Privacy and Data Management Group. And he's going to be speaking today about data privacy and Canadian anti-spam issues that our emerging company clients should be thinking about. Many of you have probably dealt with John or some of his colleagues in our privacy group.

And so we thought it would be good to bring him in just to give you an idea of some of the issues that some of our other clients are facing. And some of the risks and challenges that they're going through on a day-to-day basis because the idea of these series is just to give you an idea of some of the issues and risks that you should be thinking about. And bring those back to the company so that you know who to call when you have a problem because sometimes these things come up in the diligence process, either when a company is going through a financing or even at a later stage when a company is being bought.

And oftentimes, at that point, it's too late to address some of those issues and risks. And so it's always much better to address them upfront. And so the idea today is to present those to you and give you some background and issues to be thinking about. So without further ado, I'll turn it over to John. He's promised to keep it under 30 minutes and leave some time for Q&A at the end.

JOHN SALLOUM: All right. Thanks, everyone. All right. So this is intended to be sort of a privacy 101. We're going to try to arm you with enough information that you can issue spot as things come up. So I'll just start off by talking a little bit about the drivers behind privacy compliance and things like that.

The area is exploding. The data that we can collect, the data that we can process, as you all probably know already, the explosion in the volume there. A lot of the stuff that we-- especially computer programmers, they want to keep all the data because if I have the data, I can then analyze it later and do something with it. And if I fail to store it, I can't go back and get it retroactively.

So there tends to be a default to storing it and then for later usage, that can be at odds at times with interest in the context of security incidents and breaches when they happen. Because the more data you have kicking around, the more of a problem it becomes. So there's kind of a balance there. We'll talk a little bit about that.

There's also a much more prominent privacy advocacy movement that's out there now. And I think part of what we're going to talk about today is the shift of privacy from a legal sort of construct to one of more of the expectations of the customer. And customer, it's not as much a legal thing anymore, purely. Now it's about setting the expectations of your customer and meeting them, really. So it becomes a public relations issue as well. That's kind of one of the big shifts over time.

And then just there's a ton of coverage about privacy related issues these days. And all of those, it becomes a bit of a forward feedback loop.

There is some legislative change, certainly in the anti-spam context. We're going to talk about that a little later. But also, as time goes on, privacy is getting more and more regulated. Europe is undergoing a fairly large transition right now in the privacy context that really emanates sort of in a post-Snowden context.

So you may have heard about some of those changes. We can talk about that maybe in the questions a little later. Obviously, national security counterterrorism issues may or may not be relevant for some of you. It depends in the context of some stuff that's not, in the context of payments, it may be more relevant. I mean, that's kind of the high level stuff, the governance issue, I'm going to hammer it on governance a fair bit in a moment.

So just to start, there are a series of different sources of privacy obligations. Legislation is the one that usually pops to mind right away. We do have private sector privacy legislation in Canada. That's a little bit different from-- certainly, if you're ever talking to people in the United States, they don't have a comprehensive federal statute. They regulate privacy in a slightly different way.

And the difference is there, we're kind of similar to Europe in many respects but also similar to the US in other respects. Canada is taking that very typical sort of middle ground in that context. So it's important to remember that if you're ever talking to or looking at competitor products and services in the US, for example, they tend to approach things in a more contractual manner, where you're getting agreement to the privacy policy. That's a fairly common thing.

That's not as common an issue in Canada. We don't tend to approach it quite the same way. So I'll talk a little bit about that.

The common law has a new tort that is really sort of starting to come into its own recently, which is sort of a tort of privacy and the intrusion upon seclusion. The classic case in that context involved a bank employee looking at the financial records in the context of sort of a bit of a love triangle. So you can appreciate fairly sensitive data. And so anyway, the court used that case to develop the tort.

We've got privacy regulatory authorities. Parliament doesn't change our laws on a regular basis. They're intended to be, in the case of privacy legislation, it's principle based. And the idea is that the letters of finding and things that come out of the privacy commissioner's investigations help the law evolve over time. Certainly, in the span of our privacy to privacy legislation, a lot of the stuff that we see today wasn't around when the law came in and so it's had to evolve.

We've also got industry standards that are developing. And importantly, sometimes industry is trying to avoid having parliament dictate a change. And so they get organized to try to implement standards that most of the industry is going to try to abide by. And it's important to step up on those because as those change, you don't want to be left behind while everyone else is doing something slightly better than you are.

Privacy obligations can also-- depending on what you write in your privacy policy-- can be relevant. Contractual arrangements with third parties, depending on what kind of work-- what you're doing. If you're providing service to clients and your clients are in the financial services sector, you can expect your agreements with the financial services entities are going to have some fairly strict privacy-related obligations, and less so in other industries, for sure. So be conscious of that.

And then privacy impact assessments and privacy and security audits. In this context, usually after there's been a problem, you may be more attuned to auditing and monitoring and things like that. And you can have obligations that come out of that.

So privacy 101-- what's personal information? So in Canada, personal information is information about an identifiable individual. You may have heard the term PII-- personally identifiable information. It's a little different. PII would be sort of if you had a Venn diagram, there'd be a giant circle of personal information, and PII would be a smaller circle wholly within the larger circle.

So personal information doesn't have to have a name and an address attached to it. It can be a unique identifier that tracks you over time. So for those of you that do online behavioral advertising where a cookie is usually created when a user visits a website and it's got some unique identifier of letters and numbers, that alone can be personal information in certain contexts. So important to think about in that context.

If you're talking to people in the US, they will often define this term more narrowly. And they will, not always, but sometimes, expect you have a name attached to it. That's not the case here. So personal information can be location data, contact lists, IP address, biometrics, as I mentioned, online behavioral advertising stuff.

What else? Search queries. There was a time when one of the-- I forget which-- if it was AOL or who released it-- but they released a bunch of search query data and they had allegedly anonymized it. But of course, a journalist-- if you look for something that's so specific, you can sometimes identify stuff.

So a journalist went through the search queries-- and even though there was no IP address, even though there was nothing that you could really tell that much-- people search for themselves, and they search for hyper-specific things, and they managed to go knock on someone's door and say, are these your search queries? And the person said, oh my God, how did you get those?

So as I said, the definition of personal information is fairly flexible in that context. I'm not going to go through all of this in super detail. I mean, suffice it to say, an IP address can be personal information. Not always, but it can be. I already mentioned before, it doesn't always have to have a name attached to it.

Any questions on what is personal information before I move on? Not yet? OK. Sounds good. We'll have time for questions later as well, but.

All right. Well, so now that we talked about what personal information is, I want to talk about ways of addressing the collection of personal information, the use, and the disclosure of it. The privacy commissioners in Alberta and BC and at the Federal Office the Privacy Commissioner of Canada got together and released guidance that talks about getting accountability right.

And this is really where we start to talk about the shift from privacy as a legal obligation to more of the governance related stuff. Right? Are you setting your customers' expectations? Are you meeting them? Are you looking at privacy as a whole and not just as a check a box? Did you agree to the privacy policy?

If there is ever an investigation by these regulatory authorities, they will ask to see what your privacy management program is, and they're expecting to see a fairly-- I mean, there's 100-plus regulatory expectations embedded in those. Now, in an emerging company context, I think it's fair to say that a regulatory authority is not going to expect to have like a office of compliance and a regulatory officer and a super-insane detailed plan that's an inch thick. They'll adjust their expectations relative to the size of the operation.

But I think it's important to keep these in mind because some of these things that we're going to talk about are going to be more relevant than others, and more key. Especially if you're contemplating selling a company later, a buyer will want to see a lot of the elements that are contained in that document. Particularly, if what they're buying is the data and the relationships you have with customers. Right?

The high level version of the getting accountability right document involves organizational commitment, like an internal privacy governance structure. So someone at a high level that is taking ownership and responsibility and is accountable for what data is coming into the company. How are we using it? How is it getting disclosed? When are we destroying it? Most people don't spend a lot of time on that last piece.

But someone needs to own that. And usually it needs to be a senior-level person. Part of that process, to some extent, is getting an inventory because it's really hard to govern a universe of data if you don't know what the universe consists of. That's always tough, but trying to develop an inventory and figure out what's the data we're even collecting. Because where a lot of this goes wrong is when the left hand doesn't realize what the right hand is collecting, and how it's using and where it's getting stored, it gets left in some database for a very long time and can become a problem later on. So that's kind of the first step.

Program controls is another component. Well, part of that's the personal information inventory, but also, the development of some kind of policy or protocol in terms of how we're dealing with this. If you're transferring data between other parties, have you got some kind of agreed upon system to transfer in a secure manner, and we're not just throwing it on Dropbox somewhere and going from there.

And then once you have some kind of privacy management program in place, maintaining it in some form. Did someone bother to take a look at how we changed in the last six months? Do we need to update this thing? So those are the types of things-- and again, I appreciate, depending on where you're at in this context, you're not going to have all of that, but give it some thought. I'm happy to flip you the actual document if you want to see it in more detail.

You know what, we'll go with the development for mobile apps. Privacy in a mobile app context can be somewhat challenging because you've got a far reduced screen size. It's hard to put a lot of really helpful information with a small amount of real estate. The key in this context, I think, is user interface design. Right?

The best privacy notices do not look like privacy notices. They look like a user interface. So the OPC and the Alberta British Columbia Regulatory Authorities have released guidance on mobile app development and their expectations for privacy in that context. And they're concerned because this thing sits by my bedside and wanders around with me all day, like there's a fairly-- my phone is essentially my own portable surveillance device in one way or another, collecting data.

And so they want notice and they want my ability to be able to control what my phone is talking about me, to some extent, to be clear to me. So really what their guidance is about is making privacy choices meaningful. And so what I'm about to talk about is how they expect that to happen.

We've talked about accountability in this context. Openness and transparency refers to giving information about what it is you're collecting, and how you're going to use it in a way that ideally isn't creepy so you don't scare off your customer base. And communicating sometimes what's going on in the background can sound super creepy until you learn more about it. And so a lot of it's about the user interface and trying to communicate what can be complex algorithms or complex data flows in a easily digestible, understandable way for your average user.

Limitation on collection and retention. I talked about having someone senior think about OK, what data's coming in? What are we storing? How are we getting rid of it on the other end of it? There is a positive obligation under privacy law to destroy personal information when it's no longer required for a valid legal or business purpose.

A legal purpose would be-- let's say you have a transaction where you make a sale. The Income Tax Act, for example, or the Excise Tax Act and others, will require you to retain books and records to evidence the transaction so you can prove that you've paid tax and you've sold this much and et cetera, et cetera. That would be a legal obligation, and you would have whatever the relevant time period is-- six to seven years depending on what the tax is.

A relevant business obligation is a lot more flexible. That's what are you doing? Why are you retaining it? You know, usually, especially in a start-up context, your first year or two, you generally don't have to deal with the retention problem too much because you have new users, and they've just come in the door, and it's only been a year or two.

At some point, if you still have this data hanging around 40 years from now, it might be a problem. So the question, of course, the big question is, where between 40 years and two years is the line where you want to start destroying information? And that depends upon the business.

The other consideration is, as I said before, if you don't have extra data hanging around, you can't lose it, you can't have it stolen from you, you can't get hacked into, which then reduces your liability when you have a security incident at some point down the road.

The other focus of mobile app of these guidelines refers to the safeguards-- how are we protecting data? On the phone, usually often done by encryption but not always. And then also, obtaining meaningful consent. And in the mobile app space, the timing component for meaningful content is critical. Just-in-time notices, for example, are probably the most useful from a privacy perspective because the user wants to perform a function.

And so, when you then give them information about the privacy data flow that's going to occur in connection with that function, they're far more disposed to agree to it, for one. As opposed to when they sign up, just agreeing to all of the things in some abstract concept when they've never actually used the app. So they're an advocate of just in time notices.

Well, one last thing would be, as I said before, the best notices for privacy purposes don't look like privacy notices in the text version. An example of that would be if you've ever posted content on social media and there's a location pin that's located usually around the post in some form, that's a great example of a privacy notice in a graphic form.

And if you press the pin and the icon kind of indicates that it's been selected, for example, it's telling you it's going to attach your geolocation, in some form, to the post, or you can tap it again and it deselects it, and it will not attach a location to your post. Great example of a really useful just-in-time privacy notice. The user can toggle, you're giving them choice, they can opt in, they can opt out, and it's not text based. Right?

Another example would be the audience that you're selecting in connection with the post. Are you sharing it with your friends? Everybody on the internet? Only certain people? Are you excluding people? You're giving user control, to some extent. And that's another form of privacy notice. You're telling them, you're reminding them that you're going to share this with everybody. Did you really want to do that?

Sometimes people will have a tool tip, maybe, that pops up the first time a user sees that, to inform them what this particular selector does or does not. All of those are really great examples in the mobile context that don't require you to scroll through 43 different screens of a privacy notice and instead, communicate something about end user interface context, so.

All right. Social media-- I'm sure a lot of you have presences on social media. It's such a rapid sort of ecosystem, I suppose is what I'm trying to say. Things move very quickly. Many of the modern advertising strategies are now retargeting through social media, for example.

And so everything is kind of getting magnified on that. Canada is one of the leading jurisdictions to investigate a variety of different businesses in the context of social media platforms. That's the short list. And that's not even the most recent stuff that's in the pipeline.

I won't get into all of them, but there's a number of Facebook investigations and Google investigations on there. And then there's a few sensitive ones, like positive singles, which was an HIV positive dating website. Nexopia, which was one for youth. You can appreciate a more sensitive approach in the context of the collection, use, and disclosure of the personal information of minors.

Yeah. So I'll keep on going here. I mentioned before that a lot of social media deals with online behavioral advertising. It doesn't need to be limited to online behavioral advertising. If anyone doesn't know what online behavioral advertising is, if you've ever gone to a travel website and you've searched for some destination and then you proceed to get followed around on the web for every YouTube CAD video you're watching and there's an ad for Varadero travel or something on the right hand side, that's usually online behavioral advertising.

What's happened in that context is that the travel provider has partnered with a third party, they've got their cookie saying that this person is likely interested in some travel, and for the next 30 to 60 days, advertisers will spend money trying to sell travel because it's a very saleable thing on the web. You can search for airline tickets and hotels and deals and et cetera, so.

For those of you that are doing it, there are guidelines from the Office of the Privacy Commissioner on what's required in online behavioral advertising. I did mention before that when you're creating that cookie, you're creating what is effectively a unique identifier that is following you around the web. It's tracking you.

And I gave you a really simple example, but a different version of that would be especially where you have a solid connection with the user, and you have a profile, and you've learned things about their-- something about them over time. Right? You know an age range, you know a gender, you know usually some kind of geolocation information, whether that's just their address at home or work or where they happen to be at the time that they're using your app.

And then you kind of layer on a few other pieces, you start to put together a pretty comprehensive profile about a user, and you can infer a lot of things, and that can become valuable in an advertising context.

So in that context, the OPC and the privacy and regulatory authorities expect that individuals-- you have to give notice and make them aware of the purposes for which you are retargeting them in a way that's clear and understandable. And that's hard because making online behavioral advertising data flows clear and understandable can be really tricky. They need notice to be provided at or before the time of collection.

So our privacy law is consent based. And if you don't have consent, subject to some exceptions, you may not have a lawful authority to do the things with the data that you're trying to do. So in an online behavioral advertising context, the only way that eco-system really works is using what's called implied consent. Implied consent is implied based on that data flow in question.

And so that's typically things that are nonsensitive in nature. So you wouldn't find, like, drug advertising, health issues, casino gaming, things like that to be done using implied consent.

Things that are less sensitive than that, you provide notice when it's happening. Often, you'll have seen those cookie banners that pop up on websites, usually provide you a little bit of notice of what's happening, then you can opt out. That's often how it's accomplished. Happy to chat about that sometime if you're doing that.

The guidance requires that you enable people to easily opt out. It has to take effect immediately, be persistent. I already talked about the non-sensitivity of the information.

And then you have to clean it up at some point. Some of the cookies will last a year. It depends on what you're marketing. I mean, some of the advertising cycles, a year would be way too long, and you really only got, like, 30 days to make it useful, but.

All right. So we're coming up on the last sort of five and change minutes. Chat for a little bit about anti-spam legislation and then I'm happy to take questions. So hopefully, you are all aware, in some form, of our strict anti-spam legislation.

It is probably stricter than almost every other anti-spam statute that I am aware of on the planet. It governs what are called commercial electronic messages. That is a very broadly defined term-- that's any telecommunication where it's reasonable to conclude is one of the purposes that you're encouraging participation in commercial activity.

And it looks at things like your contact info to judge that. If you're sitting in this room, I suspect you are probably trying to encourage participation in commercial activity in some form, and consequently, you are probably sending commercial electronic messages. It is not limited to B2C. It includes B2B.

So if you use email, you have a CASL problem. If you use more than email, it can regulate text messages, refer a friend. When I say emerging forms of messaging, I mean the new technologies we haven't even contemplated that are sort of more self-contained platforms. So be aware of it.

The reason you want to be aware of it is because of the penalties. So administrative monetary penalties, the big one would be $10 million per violation. So that's per message. For clarity, we haven't seen anyone get hammered with a $10 million violation for an email yet.

The worst that we're aware of at this point is about $1.1 million, and that was for a fairly bad actor in the marketplace. But it's not been limited to-- I mean, most of the enforcement so far has been B2C-- sorry, B2B, actually, which is surprising. We thought it would be B2C. But it's more B2B stuff.

I mean, Rogers agreed to pay a $200,000 undertaking. Plenty of Fish got nailed for an unsubscribe system that wasn't working or took too many steps to kind of accomplish. Porter Airlines got nailed. They're moving forward with it.

There's a private right of action that takes effect, at the moment, on July 1. A private right of action means that an individual recipient of a message can go to court and seek statutory damages for up to $200 per message. That means they don't have to demonstrate actual damage and say, look this email message damaged me for $200 and here's why. It's statutory damages. And that's get capped at a million per day.

So that's the sort of context in why you need to care about CASL. The general gist of CASL-- and forgetting all of the stuff that I got on the screen for a second. If I was to boil the messaging portion of that statute down into one sentence, it would be that organizations are not permitted to send commercial electronic messages without consent unless an exception applies. So if you have an exception, great, you're done.

Otherwise, you need consent. It's way too much detail to talk about right now. Consent can exist in a variety of ways.

There's express consent, which is what you would think it would be. Express consent is you go and you check a box, or you take some affirmative proactive action to say, yes, I want you to send me commercial electronic messages. You've got to disclose a bunch of stuff when you get that consent. If you fail to disclose the stuff, you don't have a valid consent and therefore, you don't have a lawful authority and you might be violating the statute.

The other way you can get consent is through implied consent. And implied consent, similar to what I was talking about in a privacy context, exists by virtue of a relationship between parties. Right? So if two people who are doing business, the law implies that consent is going to exist for you to send commercial electronic messages.

But the catch for implied consent is that, like any relationship, you have to maintain it. And relationships decay over time unless you have some reason why you're keeping them up. So under the implied consent provisions, they all have time attached to them.

So for example, if you have someone who purchases a product or a service from you, including a monthly service, the implied consent continues for a period of two years and is a constantly rolling window while they're buying stuff from you. But as soon as they stop transacting, the window stops moving, and when you hit the two year mark, your content expires.

So express goes for infinity until they unsubscribe. implied, you got to track time. If you don't have systems to track time built, there's a trade off. You have to make a decision to go with express. So that that's like the super high level.

There are some form and content requirements. And when I refer to form and content, what I mean is often at the bottom of a footer-- like, if you're using Mailchimp, SendGrid, any of those sort of services to fire out emails, they're mostly going to have the footer stuff there. There are some required components-- the name of the company, mailing address, a website. Most of you are probably going to have that anyway so you probably got that part mostly squared away.

Before I go to the question section, the other thing I would just mention for CASL is that there is a defense of due diligence. And the defense of due diligence, essentially, means that if an allegation is made that you violated CASL for some reason, if you can show that you took diligent steps to prevent a violation of the anti-spam law, it's a complete bar to finding that the violation even occurs. In other words, if you violate CASL and you were diligent, the law deems that you didn't actually violate CASL.

So the question then is, well, how do I get a defense of due diligence? All of the policies, practices, procedures that I talked about earlier on in terms of the accountability and the governance come in there. Right? You're going to want to be able to show a court or the CRTC, which enforces CASL, that you were diligent.

You had thought about these issues and a human error occurred. Someone made the unsubscribe list the mailing list and the mailing list the unsubscribe list. Don't joke-- I've had that happen. Someone sent their list to Salesforce, Salesforce swapped the lists by accident and they started sending stuff out to all of the people that had unsubscribed, which is generally not recommended.

But they had policies, practices, procedures in place, there was a human error, but they had been diligent otherwise. Right? So I mean, that's what you're kind of aiming for. But that takes work upfront to get that in place.

So we are now at our 30 minute mark, so I'm happy to take questions if anyone has any. Yes?

PARTICIPANT: So we--

PARTICIPANT 1: Yeah, sorry. Would you like to use this one?

PARTICIPANT: We partner with grocery stores. So as we build a business relationship with them and they put us in some of their stores, does that qualify as them being able to send out to their people that are signed up to their loyalty program an email about the partnership? And how detailed can that be? Like, can there be a link to click through and download our app?

JOHN SALLOUM: So are they sending the message, or are you sending message?

PARTICIPANT: They'll be sending the message.

JOHN SALLOUM: So that's good for you because CASL regulates the sender of the message, for the most part. There's a provision about causing or permitting to be sent. But if you've got a third party and you're effectively paying them to be featured in their store, for example, and they are choosing to send out a message saying, hey, we have this arrangement with this vendor, come visit them in our stores, et cetera, to their own member list, then that's probably your best case scenario. Because really, you're just sort of sitting in the background, they're the ones who are crafting the message, selecting their own members, they have the lawful authority to send a message in that context.

If you're starting to combine lists and things like that, there can be some issues that arise in that context. If you have marketing lists and people have unsubscribed to receive messages from you, then if the grocery store is sending a message featuring purely your content and nothing else, really, often they'll be a cross scrubbing where your unsubscribed list will get scrubbed from the grocery store's list.

If you have people that have come to your site and said don't send me any more messages from you guys and then the grocery store goes and sends a message, there's some low hanging fruit there for a complaint, which forget the law for a second, if you get a complaint, you're going to have to spend time and resources responding to the complaint. That's why if it's easy to just cross scrub-- take your unsubscribe list and tell the grocery store don't send to any of these people, that's usually a best practice, so.

Cool. Yeah. What's going on?

PARTICIPANT 2: One step further on that note. Are you ever allowed to con-- sorry. Are you ever allowed to contact those people that the grocery store sent the message to? Maybe notify you that they were sending the message.

JOHN SALLOUM: So OK. Here, I'm going to start with the same line before. If I was to distill that statute into one sentence-- organizations are not permitted to send a commercial electronic message without consent unless an exception applies. So the question you're asking is, is your company able to send a message to the grocery store's customers?

PARTICIPANT 2: Yes. So the grocery store sent out, let's call it an email campaign, cc'd my company and said, hey, we'd like to introduce you to this great company, blah blah blah. Are we allowed to take that introduction as some sort of consent?

JOHN SALLOUM: No.

PARTICIPANT 2: No.

JOHN SALLOUM: So you would have to have either expressed consent, which is the proactive version, which you won't have. You'll have to have implied consent, which is based on a relationship, which I'm going to assume for, like, the 30 second version here, you don't have. And so then the question is, do you have an exception? I can't think of one that would be relevant in that context. So the answer on those facts would be no.

However, the next question is, well, how do I get a lawful authority? And so, if you've got, in our grocery store example, some connection that you can make with someone that comes up to a booth in the store by signing them up for something-- a membership in something, for example, or if they're going to make a transaction-- it's tough.

If they make the transaction with the grocery store, that's not going to give you a lawful authority, but now it's, like, how do we find a way to make a connection there? Or you just get express consent in some way. But to get express consent from people in a grocery store, you're going need to offer them something of value before they agree to spend the time filling out their email address and whatnot. And so now we're into marketing land, which is how do we offer them something of value that they're going to want to receive and sign up to our mailing list.

But that's the best kind of subscriber because they really want to receive your stuff at that point, as opposed to getting spam, so. And there's on there.

PARTICIPANT 3: How would you go about categorizing all the different types of information that you have? Does, like, PIPEDA list what is financial information, what is medical information, like at the starting point for mapping everything and seeing where it goes?

JOHN SALLOUM: So, no. PIPEDA is a principle-based statute and it deliberately stays away from categorizing things in that context. It doesn't define what's sensitive and what's not. It's really a judgment call.

So in terms of starting point, what we do, typically, is we have some charts that are basically rolled out within a company based on the function of-- because sometimes it's the function within the company, depending on how they're organized. Or sometimes it's literally going through, like if there's a member database, someone looks at what data fields a member could have in that context, or an account could have, and so it's to kind of populate it from there.

And then the chart is basically, OK, like, what do we have, why are we collecting this again? Like, what's the purpose for it? How are we using it? When are we destroying it? That's kind of the flow of the chart. So you just start listing each data element that you're getting and then, like, trying to tie back to what was the purpose.

And, usually, in that process, there's a few fields you hadn't remembered about. There's a few things you're collecting that you just realized that you're not actually using for anything. Someone thought it would be a good idea to collect it a while back, and no one's kind of looked back on it. Yeah. That's the best way, I find.

PARTICIPANT 3: How granular does that have to-- like with financial-- address, like would you have to go, like, post code, street address? Can you say address?

JOHN SALLOUM: So there's no magic to it, and I think it depends on the context that you're working in. If you're going to be, for example, going to get a generation five profile, which is demographic data usually built upon StatCan data, and you're going to layer that onto the customer profile so that you can better target postal codes, or people who live in postal codes with a mortgage and they spend more than $100 on cosmetics in a month, then postal code, at that point, has become a fairly relevant piece of data in the larger context.

And you'll probably want to break out your addresses and street address, city, postal code because so much is going to rely upon that postal code if address is really just the place you ship stuff and it's not really relevant otherwise, then it's probably less of an issue. Right?

PARTICIPANT: Yeah.

PARTICIPANT 1: Thank you.

PARTICIPANT 3: What would you say are best practices for when you have to transfer personal information to a third-party vendor, especially one in another country?

JOHN SALLOUM: And just to clarify, is the vendor in this case, a service provider? So they're processing information on your behalf and they're really invisible to the end user? They're not using it for their own purposes, they're using it for your purposes, right?

PARTICIPANT 3: Yeah.

JOHN SALLOUM: OK. So in that context, then the province of Alberta has a specific statutory requirement. In that context, where they want, essentially, a bit of information to be made clear in the privacy policy that you're using foreign-based service providers. Quebec has a similar obligation.

And that can take the form of something fairly simple, often as a service provider paragraph in the privacy notice. And so that paragraph would have that we may use foreign-based service providers outside of Canada. The personal information we collect will be subject to the laws of those jurisdictions.

And then Alberta also requires you to indicate how you can get more information about the practices of your service provider. So usually in the contact section, there's something that we write that's along the lines of-- for more information about our privacy practices or information about how our service providers process your personal information, please contact us at and then you give the contact information. That's sort of the notice and the transparency in the openness portion of it.

Separately, on the actual data transfers, you're going to want to contemplate an encrypted connection of some description, whether that's into an API or otherwise. And you'll want to take a look at the agreement as well.

Most of the service providers-- certainly if you're using like a Rackspace or a Mailchimp, I've used before, et cetera, their standard agreements are going to provide that they're not using it for their own purposes anyway. They don't want to go anywhere near that. They'll usually destroy whatever the instance or the data when you cancel your agreement. They may have some information on backups for 90 days, but most of those are going to be fairly straightforward.

If you got something more custom, you're going to want to think about, again, diligence in this context. And diligence for any party that's buying the company later on, they're going to want to see, well, what have you got in the agreement that's going to restrict how that's used and how it's destroyed later. And limitations of liability, are they indemnifying for a breach? How are you safeguarding the data? Sort of thinking through a lot of that stuff. So does that makes sense?

PARTICIPANT 3: Yeah.

JOHN SALLOUM: OK. Any other questions? No? All right then. Awesome. We are almost out of time.

[APPLAUSE]

Thank you.

SIMON LEITH: That was great. So thanks, John. Just a couple of announcements. So everyone, on their desks should have a feedback form, if you can take a couple of minutes just to fill that out, feedback's helpful for us just with planning future Lunch and Learn Sessions. So just to understand what type of topics are interesting for you, and also, just the time and place where we hold them. This is obviously just the second one, and we're obviously open to your feedback so be honest with us on that.

Our next one is going to be May 15. You'll get an email invitation for that. It's going to be IP strategies for emerging companies so look forward to that. And if you have any questions, I guess John maybe can stick around for a couple more minutes, or feel free to email any of us, and we can put you in touch with John. So thanks again everyone, for taking the time out of your day to be here. Thanks.