How to Handle Data Subject Requests When You're Unsure of the User's Location

It's very common for companies to collect and process personal data from users located all around the world. When a company collects or processes personal data from users in locations where data subject requests (DSRs) are legally allowed, the user will have the right to submit a data subject request - and the company must honor the request.

But what happens when a data subject request comes in, and you're unsure about where the user making the request is located?

Without knowing the user's location, it will be unclear whether the business is legally required to honor the DSR. But not honoring a DSR when you're legally required to can lead to fines and legal action.

This article explores how to handle data subject requests when the user's location is unclear. We offer guidance on how to do your best at trying to determine user location, and some suggestions for what to do when you just simply cannot determine it.

Why Does a User's Location Matter For Data Subject Requests?

A user's location matters for DSR because it's the user's location that dictates what laws apply.

If the user is located in an area that allows DSR, the DSR must be honored. This is true even if the business receiving the request is located somewhere without a law that allows DSR.

Different jurisdictions grant different rights to the people within those jurisdictions, and impose legal obligations on data controllers and processors outside of that jurisdiction.

For example, the GDPR grants the right to access data to people under its jurisdiction.

What are Some Jurisdictions/Laws That Allow for Data Subject Requests?

Here are a few of the laws that allow for data subject requests for users under their protection, along with what triggers their jurisdictional reach.

Overview

Here's a visual comparison of jurisdictional response timelines and territorial scope triggers.

GDPR

Under the GDPR, all individuals within the EU/EEA are allowed to submit DSRs to companies that have collected their personal data while in the EU/EEA. Companies not based in the EU/EEA must comply and honor DSRs if they offer goods or services to EU residents or monitor their behavior.

The GDPR's Territorial Scope: Article 3 of the GDPR addresses territorial scope. It notes that the GDPR applies to the processing of data of individuals located in the EU/EEA if that data is either:

• Processed by a business located in the EU/EAA, or
• Processed by a business that's located outside of the EU/EEA if the processing relates to providing goods or services, or monitoring user behavior

DSR Response Timeline: Under the GDPR, a business has 30 days to respond to a DSR. Under certain circumstances, like complexity, this can be extended by 2 months, but if this happens, the data subject must be informed of this extension and why it happened.

CCPA/CPRA

This U.S./Californian privacy law gives California residents certain rights over their personal data. Businesses, regardless of their location, must determine whether a DSR comes from a California resident, and if so, the request must be honored.

The CCPA/CPRA's Territorial Scope: The CCPA/CPRA applies to any business, regardless of its global location, where any of the following points are met:

• The business has a gross revenue of over $25 million in the previous calendar year, or
• The business buys, receives, or sells the personal information of 100,000 or more California residents, devices or households, or
• The business derives at least 50% of its total annual revenue from sharing or selling personal information of California residents

DSR Response Timeline: Under the CCPA/CPRA, a business typically has 45 days to respond to a DSR. This can be extended under certain circumstances, like exceptionally complex cases, by an additional 90 days if the data subject is informed of this, and why.

LGPD

This Brazilian privacy law grants its citizens user rights that are similar to those available under the GDPR, and allows them to submit DSRs.

The LGPD's Territorial Scope: Article 3 of the LGPD addresses territorial scope. The LGPD applies to data that is:

• Processed in Brazil by a Brazilian-based company, or
• Processed outside of Brazil if the processing is part of offering goods or services to individuals located in Brazil, or
• If the data subject was located in Brazil at the moment the data was collected

DSR Response Timeline: Under the LGPD, a business must respond to a DSR within 15 days. In limited circumstances, this can be extended for an additional 15 days, but this extension and the reason for it must be communicated with the user within the first 15 day period.

PIPEDA

This Canadian privacy law offers limited rights that are not quite as robust as the GDPR's, but still must be honored if a Canadian citizen rightfully exercises them and submits a DSR.

PIPEDA's Territorial Scope: While Section 4 of PIPEDA addresses how the law is to be applied, its territorial scope, or when it applies, is determined by a "real and substantial link" test. In other words, is there a real and substantial link in the processing of data to make PIPEDA apply.

PIPEDA applies to commercial private sector organizations engaged in commercial activity (think selling, leasing, transacting) with Canadian citizens, and using their personal information to engage in the commercial activity.

Note that these are not the only laws that offer user rights and have global territorial scope. They are just some of the most commonly applied laws. Always become familiar with privacy laws of regions where your users reside, as they may likely apply to you.

DSR Response Timeline: Under PIPEDA, a business must respond to a DSR with "undue delay" and within 30 days. In limited circumstances like complex requests, this period can be extended for an additional 30 days, but this must be communicated to the user along with the reason for the extension.

Why is it Important to Assess a User's Location?

Not properly assessing the location of your users means that you won't know what law applies to them when it comes to data subject requests. This can can result in:

• Non-compliance with applicable laws if you ignore valid requests.
• Over-compliance if you respond to ineligible requests, which can end up being an unnecessary financial cost.

What Common Things Can Cause a User's Location to Be Unclear?

Many things can cause a user's location to be unclear, for example:

• Geolocation errors: Sometimes IP-based geolocation data can be inaccurate because of VPNs or proxies.
• Incorrect location data provided: Users may not always provide their accurate or complete location information, such as in forms where they share personal data.
• Accessing the site from many locations: If someone travels very often, they will be accessing your website and potentially sharing personal data from multiple jurisdictions. For example, a U.S. resident who frequently travels to the EU for work.

VPNs and Proxies

It's very common for users to mask their locations using privacy tools like VPNs. Unfortunately, this can lead to your business or a third-party analytics tool collecting inaccurate and misleading IP geolocation information. What's worse is that this can be done without you knowing it, so you may not even know that the location you have is inaccurate.

Incomplete, Incorrect or Conflicting Data

A user may not give you correct or complete locational data. Or, they may manually say they are in one location while an IP address says they're in another.

Additionally, data may be conflicting. For example, consider a user who registers for an account on your site with a U.S. address, but they frequently travel to Europe, access your services from Europe, and even have items mailed to addresses in both the U.S. and Europe.

What are Some Things to Check When Trying to Determine User Location When it Isn't Clear?

We recommend taking a multi-factor approach to location assessment and not just relying on one factor.

For example, companies too often rely solely on IP address data for determining a user's location. But as we mentioned earlier, this is risky because it can be inaccurate due to VPN and IP masking.

Instead of relying on only one location indicator, look at as many as you can to find consistency.

Here are some key things to check and consider together when you're trying to figure out a user's jurisdiction.

IP Geolocation

Even though this may be misleading if a VPN is used, you can still use it to cross reference with other data points. It isn't useless data by any means.

You can improve the likelihood of the IP geolocation being accurate by using a high-quality geolocation service over free tools, and by regularly refreshing your IP databases.

User-Provided Information

Check any location data that a user has provided himself, such as during an account registration form or during a checkout process.

This can be details such as a home address collected on a form, a shipping address entered when making a purchase, the currency type used, or a phone number added to an account, just to name a few.

General User Device Details

If you have access to things like a device's default language preferences, time zone settings, GPS data or other user details, check them for clues as to where the user was located.

Account Usage Patterns

Check to see if a user regularly and repeatedly logs in to your system from a specific geographic region.

Users may move often between jurisdictions, which can create mixed-use scenarios. For example, an EU resident who's traveling abroad in the United States may submit a DSR from a non-EU IP address.

Explicit ID Verification Request

If all else fails and you still can't confidently verify the individual's location, you have the right to request that a user verifies his/her identity - including location - for purposes of handling the DSR.

According to the ICO, you should only ask for minimum information and documentation necessary to identify the individual. You must be "reasonable and proportionate" in your identity verification request, and you must send it out promptly, as soon as you realize you are unable to verify the information you have on hand.

When you reach out to the individual making the DSR, make sure to explain to them why you're requesting verification of their identity and location - for determining legal jurisdiction.

Keep records of your efforts to verify the user's location and identity, including what questions you ask the user and what responses you receive back.

Take a Conservative Approach to Jurisdiction

If you're truly unable to determine the user's location for the DSR, we suggest you err on the side of caution.

Assume that the GDPR or another law applies, and that the DSR must be honored. This will greatly minimize your legal risk.

What Technical and Operational Controls Can You Implement to Help Determine User Location?

The following things can help you determine where a user's jurisdictional location is.

Detailed DSR Intake Forms

A DSR intake form is where users can contact you about their rights request and provide you with additional information meant for verifying identity and jurisdiction.

For example, here's a standard U.S.-based DSR intake form that asks which state the person is a resident of:

The form also asks users to declare that they are entitled to make the request under the laws where they reside. While a user could easily make a mistake or even lie about this, including something like this can help prevent people from sending in requests that aren't valid:

Looking at Many Different Data Points

When trying to determine a user's location in an ambiguous case, document all the different data points you have and try to make the best determination with what you have in front of you.

If you only look at one data point and go with it, you aren't getting the full picture. However, looking at all the data points together can help create a better image for you of where the user's location most likely is.

Company-Wide Policies and Training

Have a plan in place for how to handle DSRs from users with ambiguous locations. Train the relevant employees and staff on the plan and make sure they know what to do if they receive things like anonymous DSRs.

What Should You Document to Minimize Legal Risks With DSRs?

Maintain detailed records of how you handle DSRs, especially when user location isn't clear. You should also document all the efforts you've taken to determine user location, such as direct communications with the user to get proof of location.

This helps demonstrate accountability in case of audits or complaints.

Document the following:

• The date of the DSR and what was requested
• Your actions taken: Did you honor or deny the request? Did you contact the user directly to verify location or other identity-related details?
• What sources of data you use or used: For example, IP addresses, completed order with a home address, a user's official government issued ID with address information, etc. Include data obtained both directly and indirectly from the user, and any steps you took to verify the user's identity such as requesting ID information after you received the DSR.
• How and Why you decided on what the user's jurisdiction likely was (or wasn't): Give your rationale and reasoning for why you did something like decide a user wasn't eligible to exercise GDPR rights for a DSR. For example, if 98% of a user's interactions with your U.S.-based business happen from an IP address in Florida, and not one IP address ever showed access from an EEA location, document that this is why you decided to deny a DSR under the GDPR.

If responding to a DSR under GDPR, be aware of Article 15(4), which allows you to withhold information that would adversely affect the rights and freedoms of others. Consider redacting third-party data when appropriate.

What are Some Common DSR Scenarios Where a User's Location is Unclear?

Here are a few scenarios that you may run into and how to handle them.

Scenario 1: A User Submits a DSR from a Non-EU IP Address

A user submits a DSR from an IP address that can be geolocated to the U.S., but the user's account has an EU billing address.

What should you do?

• Try to look at more information on the account and cross reference it all.
• Ask the user to provide more identification details and confirm which jurisdiction they fall under.
• Document the entire process.
• If things remain unclear, we suggest honoring the DSR to be safe.

Scenario 2: VPN or Proxy Use Masks Location

A user submits a DSR from an IP address that indicates a non-EU country, but she claims to be an EU resident.

What should you do?

• Ask the user to confirm her residency.
• Review login data to see if the IP address consistently shows one location. 
• Dig deeper into the account to see how much interaction is related to the EU.
• Document the entire process.
• If things remain unclear, we suggest honoring the DSR to be safe.

Scenario 3: No Location Data Available

A user submits a DSR without providing location information, and no IP or account data is available.

What should you do?

• Request that the user provide additional information about their location and residency
• Document the entire process.
• If things remain unclear, we suggest honoring the DSR to be safe.

Remember: If you aren't able to clearly verify the user's location one way or another, honor the DSR to help minimize your risk of violating a law.

Summary

Sometimes you'll receive data subject requests where the user's location cannot be verified. This can be because of a mismatch in data, or a lack of it.

When trying to determine how to handle a DSR when you're unsure of the user's location, look at multiple factors to try to infer jurisdiction.

For example, look at the following:

• IP address/login history
• All other account information provided by the user, such as addresses and phone numbers

Request that the user verifies identity and residence information as part of the DSR process, and document your entire process.

If you still can't confidently determine where a user's location is for purposes of the DSR, it's smart to honor the DSR regardless. This will help limit your legal liability.