How Osano Does DSARs

Subject rights requests can be confusing for everybody involved. 

Some consumers are savvy privacy advocates and expect their requests to be fulfilled to the letter. Others are just learning that they have subject rights and are testing the waters. Some consumers are even submitting vexatious requests, hunting for legally actionable information or hoping to gum up the works of a business they’re quarreling with. 

Businesses are in a similar position. An email lands in your inbox, and suddenly the legal department says you’ve got 30 days to find every shred of personal information you have on this person. Even organizations that understand their legal obligations when fulfilling subject rights requests struggle with translating that abstract legal knowledge into on-the-ground operations. 

But most businesses aren’t in the privacy industry—Osano is. And we like to think we’ve got a pretty good handle on our DSAR process.  

To help clarify the confusion and give other organizations a blueprint for an effective DSAR process, we figured we’d describe our own workflow and how we think about subject rights requests. 

But First: What Are DSARs or SRRs? 

Even though DSAR or data subject access request is a widely accepted blanket term for all subject rights in addition to access rights, we’ll use the term SRR or subject rights request in this article since it’s more accurate. 

Data privacy regulations give data subjects (i.e., the person whose data you’re processing) a certain set of rights. These rights allow the data subject to make certain requests of organizations that are processing their data. We mentioned access rights, but data subjects can also request the deletion, correction, or summarization of their data, among other rights. 

Most data privacy laws provide similar rights, but there are exceptions.  

We won’t dive too deep into SRR 101 here. If you want to learn more about the basics behind subject rights, you can find more information in our blog, What Is a DSAR? 

The important things to know about SRRs for the purposes of this article are: 

• There’s a time limit. SRR responses are generally (but not always) due within 30 or 45 days depending on the governing law. 

• SRRs can be easier or harder to fulfill depending on a variety of factors. Request type, your organization’s systems, the vendors you use, the volume of requests you receive—each of these influences how much time and effort goes into fulfilling an SRR. 

• SRRs are on the rise. In the EU, where data privacy rights are more widely understood, there are already thousands of SRRs being made each day. In the US, that figure is smaller. But in both jurisdictions and worldwide, SRRs are on the rise. 

Organizations’ SRR Processes Will Vary 

You can think of SRRs a bit like shoes. 

Each person has a different size shoe, some people wear boots more often than dress shoes, and if you watch a crowd of people walking about, you’ll notice they’re each wearing something different. 

SRR processes are a lot like that. Some organizations will have more or less volume and complexity, see certain request types from certain jurisdictions more often than others, and so on.  

While one pair of shoes may differ from another, they’re still recognizable as a pair of shoes. They come in sets of left and right and have soles and laces. So, while there will be differences among SRR processes, there will also be some consistent features that ensure your organization is protected—just like a good pair of shoes protects your feet. 

Here are some factors unique to Osano that impact our SRR process: 

• We’re in the data privacy industry. As a result, we see more SRRs than other businesses of a comparable size. 

• We’re a small business. While we receive a sizeable number of SRRs, we still only have so much headcount and time available to our personnel. Osanians are scrappy, wear a lot of hats, and work hard to support our customers’ compliance. This means we have to be extra efficient when fulfilling SRRs. 

• We comply with laws we don’t technically have to. As a privacy-forward business, we believe it’s best to provide all of our audience with subject rights, even if they aren’t protected by a data privacy regulation in their jurisdiction. 

• We use Osano to manage SRRs. How could we sell an SRR management solution if we didn’t? The Osano platform is our secret sauce to gaining the efficiency needed to handle the SRR volume we see despite the scale of our company. 

How Osano Does SRRs: Our Process

1. Accept Request

We have a few ways for data subjects to submit their requests. 

Most data privacy laws require at least two methods for request submission—commonly, email or a toll-free phone number. We provide an email address and a physical mailing address, but the primary way we receive requests is through our forms. 

The Osano platform enables us to embed subject rights request forms in our webpages, as well as in our “cookie drawer”—an Osano-powered widget that allows website visitors to update their cookie preferences and submit an SRR if they so desire. We call the latter our One-Click DSAR functionality. Submitting via form is the primary way data subjects submit SRRs to the Osano team. 

Here's what our DSAR Form page looks like:

Navigating to our SRR submission page gives the visitor several request types. Clicking on one of these options opens up a form with fields specific to that request type. 

Using a form to guide data subjects through the request process has some significant benefits for us. For example, we can require data subjects to provide needed information for us to action the request. If a data subject were to submit a correction request via email, they might not include information like what they want corrected or where they’re seeing the incorrect information. If that were to happen, we’d have to email the data subject back and forth—all while we’re handling other SRRs and that 30- or 45-day deadline is ticking. 

With a form, we can (and do) ask data subjects to provide this information before submitting. This way, we know that once a request is verified, we can get straight to work on it. 

Another interesting aspect about our forms—we offer every subject right universally (some of which are accessible through our “Other” request option), but if we didn’t, Osano allows us to automatically offer request types based on the data subject’s jurisdiction.  

For example, Oregon provides data subjects with the right to know a list of the specific third parties that have received their personal data. Most privacy laws don’t provide this right. Using Osano, only Oregonians would receive this right by default. If you want to offer that right to everyone, you can do so with Osano. Or, if you want to offer that right to some people outside of Oregon or provide any other mix of data subject rights, you can do that too. The only thing you can’t do is not offer a required right for a given jurisdiction.

2. Verify Request

Because we don’t handle particularly sensitive data at Osano, we use the data subject’s name and email address to verify their identity. Some companies might choose to use a more thorough means of verification, such as receiving a scan of the data subject’s driver’s license. This is a double-edged sword. On the one hand, it’s a better fraud prevention technique. On the other, it adds yet more personal data to manage—in the case of a driver’s license, many laws would construe that as sensitive data to boot. 

When a request is received, the Osano platform sends an email with a magic link to the provided address. Clicking on the link both verifies the data subject’s identity and brings the requestor to an Osano-powered secure messaging portal, where the data subject can communicate with whoever is actioning the SRR.

3. Check Whether There Is Relevant Data

Osano automatically searches our systems for data corresponding to the request. If there’s still no data connected to the request, then we let the data subject know there’s no data for us to action on, and we can end the process there. 

Osano can search through our systems because we use another Osano module to facilitate SRRs—our data mapping functionality. Any system connected to our single-sign-on (SSO) provider is discoverable to Osano, enabling us to search through systems for a data subject’s information automatically. We use our SSO to connect to systems, but Osano also connects to customer data platforms (CDPs) like Segment or RudderStack and cloud database services like Amazon Aurora RDS. Individual data stores that aren’t connected to sources like an SSO, CDP, or cloud database can be added manually as well.

An example data map in Osano.

4. Assign Action Items Based on Request

Each request type has a different workflow.  

Summary and deletion requests are both the most common request types, and the most straightforward. Osano automatically processes these requests but keeps a human in the loop for verification. Again, this automation is possible because we also use Osano for data mapping.  

Transfer/portability requests function similarly but require the data to be packaged up and sent to the data subject. 

Opt-out requests are also executed automatically and instantaneously upon data subjects’ identity verification. This is one way of honoring requirements like the CCPA’s Do-Not-Sell/-Share request. Upon receiving this request, Osano turns off any cookies and data-tracking scripts on the website for the requestor. If we sold or shared consumer data through other means (we don’t), then Osano would also exempt the data subjects’ personal information from such transfers. 

Correction requests require more manual effort, since there are lots of different kinds of information that might need correcting. Depending on the information that needs correcting, an administrator of the Osano platform assigns an action item to a data store owner to make the necessary correction. The assignee then receives notifications and alerts if the request deadline is approaching. 

We also offer generic “Other” requests. Naturally, these may require more manual effort and review. They aren’t required by law, but we like to offer them to be privacy-forward for our audience. They also serve as a catch-all for unenumerated rights. Some laws use different terms for functionally the same request type, so the “Other” category lets data subjects submit rights requests offered elsewhere but described in unfamiliar terms. 

There are other SRR types—we mentioned Oregon’s right to know about third parties receiving data subject’s information, for example—but these can often be met through request types like those we described above or by adding additional information in the organization’s various policies and notices.

5. Communicate with the Data Subject

Because we use a form to guide our SRR workflow, we usually don’t need to engage in too much back and forth with the data subject. Osano also provides a secure messaging portal, ensuring that our conversations are private and preventing the spread of yet more personal information in email clients. Osano also provides prepopulated template emails to communicate with data subjects. It may not seem like much, but it’s a lot easier than having to write bespoke emails each time, especially as your SRR volume ramps up.

5. Keep Records

Many data privacy regulations require you to keep records of your SRRs, generally for a period of two years. Osano automatically keeps our SRR records for us. 

How Much Time Do We Save Using Osano? 

We’ve never not used Osano, so this figure is difficult to quantify. However, we can make an estimate by looking at where and how Osano saves time versus manual SRR fulfillment: 

• Streamlined data subject communication: We don’t have to go back and forth with data subjects to get them to elaborate their request; our form prompts them for all the info we need. Plus, our email templates make it easy to respond to SRRs at scale, and we know that all of our SRR communications can be found in Osano’s secure messaging portal. 

• Automated data discovery: We don’t have to look up data subject’s information manually; Osano does it for us using our data map. 

• Automated SRR fulfillment: We don’t have to manually delete each row in each record, or copy and paste each piece of data, or summarize the data types; Osano does it for us—but we make sure to keep a human in the loop for verification. 

• Automated recordkeeping: We don’t have to fill out a spreadsheet with metadata whenever we receive a request; Osano does it for us. 

Keeping all of this in mind, one of our privacy pros estimated that Osano saves them 10x the effort it would take to process SRRs manually. That’s a lot! Why not see if Osano can make your SRR workflow 10x easier at your organization?