PDPA Singapore | DPDPA India Compliance Checker:
India - Digital Personal Data Protection Act, 2023 - DPDPA
Singapore - Personal Data Protection Act 2012 - PDPA
Created by: Ankit Bhargava.
If you have customers located in Asia Pacific, including Singapore and/or India, this compliance checker can help you identify what data privacy rules apply to you and what steps you need to take next. It's free, easy, and simple. No email or sign up required.
If you have customers located in Asia Pacific, including Singapore and/or India, this compliance checker can help you identify what data privacy rules apply to you and what steps you need to take next. It's free, easy, and simple. No email or sign up required.
When your users/customers are located in: India & Singapore. (Asia Pacific.)
Your Takeaway:
Your customers are in Singapore and India. That means you need to follow two completely different privacy laws: Singapore's Personal Data Protection Act (PDPA) and India's Digital Personal Data Protection Act, 2023 (DPDPA). Unlike the EU and UK, which are nearly identical, these two laws are built differently. Singapore's PDPA has been around since 2012 and is mature, with clear enforcement. India's DPDPA is brand new (passed in 2023), and some rules are still being finalised. Both require consent or clear legal grounds, but they differ significantly on data localisation, breach notification timelines, and the role of a Data Protection Officer. You cannot treat them as the same.
Your Privacy Best Practices:
– Get a copy of Singapore's PDPA (the PDPC website has a great plain‑English guide) and India's DPDPA (the Ministry of Electronics and IT has summaries). Read the overviews, not the full laws.
– Check if you need a Data Protection Officer (DPO) in Singapore. Under PDPA, you must appoint a DPO and make their contact details public. Most businesses need one, even small ones.
– Check if you need a local representative in India. Under DPDPA, if you process significant volumes of Indian customer data and you're based outside India, you likely need a local representative.
– Keep separate compliance files for Singapore and India. Do not mix them – the rules are different.
How I Can Help:
I can walk you through both the "Singapore and India" data privacy regulations session. I can help you know exactly what you need to do for Singapore (usually DPO appointment and consent management) and what you need to do for India (often local storage and a representative).
Select Your Scenario Below — I'll Show You What To Fix & How.
QUESTION 1: What type of personal data do you collect?
QUESTION 3: What is your legal basis for processing personal data?
QUESTION 5 : Do you share customer personal information with others or third parties?
QUESTION 2: Why do you collect customer data?
QUESTION 4: How long do you keep customer personal information?
We collect only basic personal data of our users/customers:
Your Takeaway:
You collect only basic contact or identification details – name, email, phone number, and address. Under both the Singapore PDPA and India DPDPA, basic data is considered lower risk than sensitive data. However, the legal paths are different. Singapore allows "deemed consent by notification" – meaning if you tell customers what you're doing and they don't object, that can count as consent. India requires explicit, affirmative consent for collection – no deemed consent. Both require you to inform customers of the purpose (PDPA) or provide a notice (DPDPA). The good news: basic data is manageable. The bad news: you need two slightly different consent approaches.
Your Privacy Best Practices:
– Document what basic data you collect and why. Do this separately for Singaporean and Indian customers if you process them differently – but usually the same list works.
– Publish a privacy notice that covers both Singapore and India requirements. For Singapore, explain your purposes clearly. For India, include the mandatory DPDPA notice elements (what data, why, how to withdraw consent, how to complain).
– For Singapore customers, you may rely on "deemed consent by notification" for basic data – but you must give them a clear opt-out, and they must not opt out. Document this.
– For Indian customers, get explicit consent for basic data collection
– an unchecked checkbox or a clear "I agree" button. Keep records.
– Set a retention period – For example, 2 years after last activity is reasonable for basic data in both countries.
How I Can Help:
I can help create a dual-jurisdiction privacy notice template that covers both Singapore PDPA and India DPDPA. I'll also explain the difference between Singapore's deemed consent and India's explicit consent – and help you set up separate flows for each if needed. Most of my clients end up using explicit consent for everyone to keep it simple, but I'll show you both options.
We collect both basic and sensitive personal data of our users/customers.
Your Takeaway:
You collect sensitive data – under Singapore PDPA, this includes health, biometrics, financial information, and more. Under the India DPDPA, sensitive data is similarly defined but with additional rules. Both require explicit consent – not just regular consent, but explicit, written, unambiguous agreement. India goes further: you may need to store sensitive data only on servers located in India (data localisation). You also need additional safeguards, and in some cases, a Data Protection Impact Assessment (DPIA). This is high risk in both countries, but India's localisation requirement is the biggest difference. If you process sensitive data of Indian citizens, you likely need to move your data storage to India or use an Indian cloud provider.
Your Privacy Best Practices:
– First, challenge yourself: do you really need this sensitive data? Many businesses collect it without thinking. If you can deliver your service without it, stop collecting it. This is the single best way to reduce risk.
– If you truly need it, get explicit written consent. Not a pre‑ticked box. Not a hidden clause. A clear, separate "Yes, I agree" that you store as proof. Do this separately for Singapore and Indian customers.
– For Indian customers, check where you store sensitive data. If it's outside India, you likely need to move it to an Indian server or use an Indian cloud provider that guarantees local storage. This is not optional under DPDPA.
– Conduct a DPIA. Both PDPA and DPDPA expect this for sensitive data. Document the risks and how you mitigate them.
– Limit access to sensitive data to only those employees who absolutely need it. Keep access logs. Encrypt the data wherever possible.
How I Can Help:
I can help you understand India's data localisation requirements for sensitive data – and whether you need to move your servers or switch providers. If you don't actually need the sensitive data, I'll help you plan a safe deletion process.
We collect our users'/customers' personal data for Selling our products/services.
Your Takeaway:
Your customers expect you to use their data only to deliver what they bought from you. Under both the Singapore PDPA and the India DPDPA, this is the lowest-risk expectation. You still need to inform customers of the purpose (Singapore) or provide a notice (India). However, no extra consent is needed for delivery – that's fine. The key difference: Singapore's "deemed consent by notification" can apply to delivery purposes if you notify customers properly. India requires explicit consent for collection, but delivery is a legitimate reason that customers would expect. The biggest risk is accidentally using delivery data for marketing or analytics without separate consent.
Your Privacy Best Practices:
– Write a one‑sentence notice on your checkout page. For Singapore: "We use your information to complete your purchase and provide customer support. If you do not wish us to use your data for this purpose, please contact us." For India: "We collect your name and email to deliver your purchase. You can withdraw consent by contacting us."
– Do not add customers to any marketing list unless they separately and actively opt in. In Singapore, deemed consent for marketing is separate and requires a clear opt-out. In India, you need explicit opt‑in.
– Train your team: if someone asks, "Can we use this customer's email for a newsletter?" the answer is no unless there's a separate, unchecked checkbox that they ticked (India) or a clear opt‑out they didn't use (Singapore).
– Review your order confirmation emails. They should not contain marketing messages unless the customer opted in separately.
How I Can Help:
I'll look at your checkout flow, order confirmation emails, and any automated messages you send. I'll tell you exactly where you might be accidentally using data beyond "delivery only" – and how to fix it.
We collect our users'/customers' personal data for Marketing & Promotion.
Your Takeaway:
Your customers expect you to use their data for marketing or promotions. Under Singapore PDPA, you can rely on "deemed consent by notification" for marketing if you gave customers a clear opt-out at the time of collection and they didn't opt out. This is unique to Singapore – it doesn't exist in India or the EU. Under the India DPDPA, you need explicit opt‑in consent for marketing – no exceptions, no deemed consent, no soft opt‑in. For both countries, you must keep records of consent (or deemed consent for Singapore) and offer an easy way to unsubscribe. The safest approach: treat all customers as needing explicit consent.
Your Privacy Best Practices:
– For Indian customers, always use an unchecked checkbox: "Yes, please send me offers and updates." Keep records of who checked it, when, and the exact wording.
– For Singapore customers, you have two options: 1) Use explicit consent like India (safest and simplest), or 2) Use deemed consent by notification – but you must have given a clear opt-out at collection, and the customer must not have opted out. Document this carefully.
– Keep a consent log: customer email, country (Singapore or India), date of consent, exact wording they agreed to, and whether it's explicit or deemed.
– In every marketing email, include a one‑click unsubscribe link that works immediately. Both PDPA and DPDPA require this.
– Separate your Singapore and Indian marketing lists if you use different consent models. Or just use explicit consent for both to keep it simple.
How I Can Help:
I'll audit your current email signup forms and marketing setup. I'll tell you which customers you can email under Singapore's deemed consent versus which need explicit consent. For Indian customers,
We collect our users'/customers' personal data for Monitoring & Profiling.
Your Takeaway:
You monitor customer behaviour – tracking clicks, time on site, and pages viewed – or you build profiles based on that behaviour. Under Singapore PDPA, there are no specific profiling rules, but you need consent for any collection of data for new purposes. If you started collecting data for delivery and now want to use it for profiling, you need separate consent. Under the India DPDPA, profiling for automated decisions that affect customers (like credit scoring, loan decisions, insurance pricing, and job applications) requires notice and an opportunity for the customer to challenge the decision. This is significant – India has explicit rules that Singapore doesn't.
Your Privacy Best Practices:
– For Singapore customers, get consent for any monitoring or profiling that isn't strictly necessary for your service. A consent banner works.
– For Indian customers, do the same – but if your profiling leads to automated decisions that affect the customer (e.g., "you don't qualify for this loan", "your price is higher based on behaviour"), you must provide notice before processing and give the customer a way to challenge the decision. Document this process.
– Use a consent management banner that lets people say no to non‑essential tracking – and honour that choice. This works for both countries.
– If you use profiling that affects customers, write down your process for handling challenges. Who receives the challenge? How do you review it? How long does it take?
– Document your monitoring and profiling activities separately for each country.
How I Can Help:
I can help you understand who needs consent in Singapore versus India. If you're doing any kind of automated profiling that affects customers, I'll help you set up a simple challenge process – a form, an email address, and a review workflow
We collect our users'/customers' personal data for Third‑Party sharing.
Your Takeaway:
You share customer data with third parties – analytics providers, advertising networks, payment processors, or business partners. Under Singapore PDPA, you must disclose sharing in your privacy notice. If you share for a purpose different from the original collection purpose, you need separate consent. Under the India DPDPA, you must also disclose sharing. Consent is required unless the sharing is with a "consent manager" (a new concept under DPDPA) or for legal reasons. India's consent manager framework is unique – it's a registered entity that manages customer consent on your behalf. Most small businesses won't need one, but you should know it exists.
Your Privacy Best Practices:
– Create a vendor table with columns: vendor name, what data they see, where they are located (country), and why you share with them. Put this table on your website – not buried, but easy to find.
– For Singapore, if you share for a purpose different from the original collection (e.g., you collected data for delivery but now share with an advertiser), get separate consent.
– For India, do the same – get separate consent for non‑essential sharing. Understand that "consent managers" exist, but you likely won't need one unless you're a large platform.
– Sign data processing agreements with all vendors. Both PDPA and DPDPA expect this.
– For cross‑border sharing, Singapore restricts transfers outside Singapore unless the receiving country has comparable protection. India has similar rules but is still finalising its list of permitted countries.
How I Can Help:
If you have cross‑border transfers, I'll help you understand whether Singapore or India allows them – and what you need to comply with the respective privacy regulation.
We have not informed our users/customers anything.
Your Takeaway:
You haven't told your customers what you do with their data. Under the Singapore PDPA, this violates Section 20 – the notice obligation. Under the India DPDPA, this violates Section 5 – the notice requirement. Both laws are clear: you must inform customers at or before the time of collection. The good news: fixing this is simple and cheap. A basic privacy notice takes an hour to write. The bad news: ignoring it is expensive if you get caught. Singapore's PDPC has fined companies for lack of transparency. India's DPDPA is new, but enforcement is coming.
Your Privacy Best Practices:
– Publish a privacy notice by the end of this week. For Singapore, include: what data you collect, why, how long you keep it, who you share it with, and how to contact your DPO. For India, include the same, plus how to withdraw consent and how to complain to the Data Protection Board.
– Put a link to your privacy notice everywhere you collect data: signup forms, checkout, email footers, website footer.
– If you already have customer data, send a short email or notification: "We've updated our privacy notice. You can read it here."
– Make sure your notice includes a contact email for Singapore (your DPO) and for India (your nominated representative or yourself).
– Use double opt-in for important data: the customer checks a box, then you send a confirmation email, and they click a link to verify. This gives you clear proof for both countries.
– Keep a consent log: customer ID, country (Singapore or India), date and time, exact wording they saw, and a copy of the form.
– For India, ensure consent is "unconditional" – don't say "you must agree to marketing to use our service" unless marketing is truly necessary for the service (rare).
– For Singapore, understand that consent can be withdrawn anytime make it easy. A one‑click unsubscribe or a simple email request.
– Review your consent requests every year. Do they still make sense? Are they still specific?
How I Can Help:
I'll review your consent mechanism and tell you if they meet both PDPA and DPDPA standards. If it does not, we can create a whole new consent management system specific to your processing activities and business objectives.
We do 'personal data processing' based on our users’/customers’ consent.
Your Takeaway:
You rely on customer consent as your legal basis. Under Singapore PDPA, consent is the primary basis – it must be given voluntarily with knowledge of the purpose. Under India's DPDPA, consent is also the default basis – but it must be free, specific, informed, unconditional, and with a clear affirmative action. The key difference: India's consent must be "unconditional" – you cannot tie consent to service provision unless the data is strictly necessary. Singapore allows slightly more flexibility. Both require you to keep records of consent and make withdrawal as easy as giving consent.
Your Privacy Best Practices:
– Use double opt-in for important data: the customer checks a box, then you send a confirmation email, and they click a link to verify. This gives you clear proof for both countries.
– Keep a consent log: customer ID, country (Singapore or India), date and time, exact wording they saw, and a copy of the form.
– For India, ensure consent is "unconditional" – don't say "you must agree to marketing to use our service" unless marketing is truly necessary for the service (rare).
– For Singapore, understand that consent can be withdrawn anytime; make it easy. A one‑click unsubscribe or a simple email request.
– Review your consent requests every year. Do they still make sense? Are they still specific?
How I Can Help:
I’ll review your consent forms and consent logs. I’ll tell you if they would survive an inspection by a regulator. If not, I’ll show you exactly how to fix them – usually with required wording changes. I can also help you set up a consent logging system for your users’ consent management.
We do 'personal data processing' based on contract.
Your Takeaway:
You rely on contract as your legal basis. This means you collect and process data only because you need it to fulfil a contract with the customer – delivering a product, providing a service, sending invoices, or handling support tickets. A contract is a strong basis, but it has a hard limit: you can only process data that is strictly necessary for that contract. You cannot use a contract as an excuse to collect data for marketing, analytics, or any other purpose. If the customer doesn't provide the necessary data, you can refuse to enter into the contract. After the contract ends (customer stops using your service), you must delete the data unless another basis applies (like legal obligation for tax records).
Your Privacy Best Practices:
– In your signup or checkout form, clearly mark which fields are "required for contract" and which are "optional". The required ones are the only ones you can rely on contract for.
– Create a simple list: each piece of data you collect and a one‑sentence explanation of why it's strictly necessary for the contract. Keep this list in your files.
– Do not use contract‑collected data for any other purpose without a separate legal basis (like consent for marketing).
– After the contract ends, set a timer to delete the data – or move it to a different basis if one applies.
How I Can Help:
I’ll help you separate your “contract necessary” data from your “nice to have” data. We’ll go through your forms together, and I’ll point out which fields you can remove or make optional. This often simplifies your business and reduces your privacy risk at the same time.
We do 'personal data processing' based on legal obligation.
Your Takeaway:
You collect data because a specific law requires you to – for example, tax laws, anti‑money laundering rules, or health and safety regulations. Under the Singapore PDPA, this is valid if required by written law. Under the India DPDPA, it's valid if required by any law in force. You must be able to point to the exact law that creates the obligation. You cannot collect more data than that law requires, and you cannot keep it longer than the law says. India's "any law in force" is broader – but still, be specific. Don't claim "legal obligation" for something that's just good practice.
Your Privacy Best Practices:
– For each legal obligation data point, write down the exact law name, article number, and section. For Singapore: "Income Tax Act, Section 67" or "Personal Data Protection Act (for DPO appointment)". For India: "Income Tax Act, 1961, Section 139" or "Companies Act, 2013".
– Keep a one‑page "legal basis register" that lists the following: data point → law → retention period required by that law.
– Do not use data collected for legal reasons for any other purpose (like marketing) without a separate legal basis.
– Review your legal obligations once a year. Laws change.
How I Can Help:
I’ll help you create a legal basis register. You fill in what you collect and why. I’ll review it and tell you if any of your claimed legal obligations are actually too broad. I’ve seen many businesses claim “legal obligation” for things that aren’t really required – I’ll help you clean that up.
We do 'personal data processing' based on legitimate interest.
Your Takeaway:
You believe it's in your legitimate business interest to collect and process the data – for example, to prevent fraud, improve your website, or send service updates. Here's the critical point: Singapore PDPA does NOT recognise legitimate interest as a standalone legal basis. India's DPDPA does NOT recognise legitimate interest either. Do not rely on this basis for any customer in Singapore or India. If you have existing processing that uses legitimate interest, you need to change it immediately to consent or contract. This is one of the biggest differences between Asia Pacific and Europe.
Your Privacy Best Practices:
– Do not use legitimate interest for any processing involving Singapore or Indian customers. Period.
– Review all your current processing activities. If you have "legitimate interest" written anywhere for Singapore or India, change it to consent or contract.
– For fraud prevention, use a contract (if it's part of your terms) or get consent.
– For website improvement, get consent via a banner.
– For service updates, use a contract (if it's necessary for the service) or get consent.
– Document the change. Keep a record showing that you moved away from legitimate interest.
How I Can Help:
I’ll help you conduct a LIA pre-processing of personal data. I’ll review your answers and tell you if your legitimate interest claim would hold up. If it won’t, I’ll help you switch to a safer basis like consent or contract.
We are not sure about our lawful basis of users' personal data processing.
Your Takeaway:
You don't have a clear legal reason for collecting customer data. Under both the Singapore PDPA and the India DPDPA, this is a problem. Singapore requires a valid basis (usually consent or contract). India requires consent or a legitimate use (contract, legal obligation, etc.). There's no "I didn't know" exception. The good news: both countries accept consent and contract as valid bases. The bad news: legitimate interest does NOT work. You need to stop collecting any data you can't justify immediately. For data you already have, assign a basis – consent or contract are your safest options. If you can't assign a basis within two weeks, delete the data.
Your Privacy Best Practices:
– Stop all optional data collection right now – you can always restart after you have a legal basis.
– For existing data, go through each type and ask, "Do we have a contract with this person? If yes, the contract may work. If no, can we get consent? If no, delete it."
– Document every legal basis you assign. Write it down simply: "Data type X → Basis: contract because we need it to deliver service."
– Remember: legitimate interest is NOT an option. Don't write it down.
– If you cannot assign a basis within two weeks, delete the data. Keeping it is not safe.
How I Can Help:
If you are unsure about your legal basis for processing your personal data, I can assist you in deciding the appropriate lawful basis to use for your users’ personal data processing.
We keep our users’/customers’ personal information for a Definite time.
Your Takeaway:
You keep customer data only for a defined period of time – for example, two years after their last purchase. Under both the Singapore PDPA and the India DPDPA, this is exactly what the law expects. Singapore's PDPA requires that data not be kept longer than necessary for the purpose. India's DPDPA requires deletion when the purpose is met. Having a definite retention period is compliant – you're already ahead of many businesses. The remaining tasks: document that definite time in writing, include it in your privacy notice, and make sure your team actually follows the rule. For India, note that DPDPA has specific expectations about deletion timelines – you need to be able to delete promptly when the purpose ends.
Your Privacy Best Practices:
– Write down your retention periods in a simple document. Example: "Customer contact data → deleted 2 years after last activity." Transaction data → kept 7 years for tax purposes (Singapore/India tax laws). Support tickets → deleted 1 year after the ticket is closed."
– Add a sentence to your privacy notice: "We keep your data for [X years] after your last interaction." For example, for tax records, we keep transaction data for 7 years as required by law."
– Set up an automated reminder or script to delete old data – don't rely on memory. Many CRMs and email tools have auto‑delete rules.
– For India, ensure your deletion process is prompt. Don't keep data "just in case" after the purpose is met – DPDPA doesn't allow that.
– Test your deletion process once a quarter. Delete a small batch of old data and confirm it's gone from all systems.
How I Can Help:
I’ll review your current retention practices. I’ll ask you a few simple questions about each data type, and then I’ll write a custom retention schedule for you – including exactly what to put in your privacy notice.
We keep our users’/customers’ personal information for an Indefinite time
Your Takeaway:
You keep customer data for an indefinite period – basically, forever. Under both the Singapore PDPA and the India DPDPA, this is a direct violation. Singapore's PDPC has fined companies for keeping data longer than necessary. India's DPDPA explicitly requires deletion when the purpose is met – indefinite retention is not allowed. You need to set a retention period, even a rough one, and you need to be able to delete data when that period ends. You also need to be able to delete an individual customer's data if they withdraw consent or request deletion. This is urgent – indefinite retention is an easy violation for a regulator to spot.
Your Privacy Best Practices:
– This week, pick a default retention period. For example: For most businesses, 2 years after the last activity works well for customer data. For transaction data, 7 years for tax purposes (both Singapore and India have similar tax record requirements). Write it down.
– Go through your existing customer data. Delete anything older than your new retention period. Yes, delete it. You can keep aggregated statistics if you need them – but no personal data.
– Set a calendar reminder every quarter to review and delete old data.
– Make sure you can find and delete one customer's data on request. Test this with a colleague pretending to be a customer.
– Document your retention policy. Both PDPC (Singapore) and the Data Protection Board (India) expect to see it if they ask.
How I Can Help:
I’ll help you set up a simple retention policy specific to your business. We’ll decide on retention periods for each data type, write them down in a document, and add the right wording to your privacy notice. I’ll also help you create a step‑by‑step process for deleting old data from common tools like your CRM, email platform, and cloud storage.
We do No Sharing of our users’/customers’ personal information with others/third parties.
Your Takeaway:
You don't share customer data with anyone outside your business. Under both the Singapore PDPA and the India DPDPA, no sharing is the cleanest scenario. However, "outside your business" includes third‑party tools like your website hosting provider, email delivery service, analytics tool, customer support software, and even your CRM if it's cloud‑based. If any of those tools can see customer data – even temporarily – that counts as disclosure. Under PDPA, that's sharing. Under DPDPA, that's sharing. You need to verify each tool carefully. Even with no sharing, you still need a privacy notice and a legal basis.
Your Privacy Best Practices:
– List every single online tool your business uses, including free ones, one‑off tools, and even tools you forgot about. For each tool, ask: "Does this tool ever see a customer's name, email, IP address, or any other personal data?" Be honest.
– If the answer is yes, you are sharing. Update your answer to "Yes, sharing" and follow those best practices.
– If the answer is truly no (very rare – only possible if you run everything on your own servers with no external services), document your verification and keep it on file.
– Even with no sharing, publish a privacy notice that says, "We do not share your data with anyone outside our company" – but only if it's true.
– For India, note that cross‑border sharing has additional rules – even if you're not sharing, still document that you've checked.
How I Can Help:
I’ll help run a “data flow scan” of your business. We can identify which tools are silently receiving customer data – you’re often surprised. Once we have the real picture, I’ll help you either stop the sharing or disclose it properly.
Yes, We Do Share our users’/customers’ personal information with others/third parties.
Your Takeaway:
You share customer data with third‑party vendors or business partners. Under both the Singapore PDPA and the India DPDPA, sharing is allowed but with obligations. For Singapore: you must disclose sharing in your privacy notice, get consent if sharing for a new purpose, and sign data processing agreements. For India: you must disclose sharing, get consent unless sharing is with a "consent manager" or for legal reasons, and be aware of cross‑border restrictions. India's DPDPA also introduces the concept of "consent managers" – registered entities that manage customer consent on your behalf. Most small businesses won't need one, but you should know it exists. For cross-border sharing, Singapore restricts transfers outside unless comparable protection. India is still finalising its rules, but expect restrictions.
Your Privacy Best Practices:
– Create a vendor table with columns: vendor name, what data they see, where they are located (country), whether you have a DPA signed, and whether consent is needed.
– Sign data processing agreements with all vendors that process data on your behalf. Most major vendors have them.
– For Singapore, ensure cross‑border transfers have comparable protection. If you're sending data to a country without adequacy, you need contractual clauses or binding corporate rules.
– For India, check if you need a consent manager. You probably don't unless you're a large platform, but understand the concept.
– For Indian sensitive data, check localisation requirements – you may need to store it in India.
– Put your vendor table on your website as part of your privacy notice.
How I Can Help:
I’ll review your vendor list and tell you exactly what’s missing. I can also help you create a plain English DPA template you can send to any vendor that doesn’t have their own. If you have cross-border transfers, I’ll help you add SCCs (if required).
Ready to take your next step?
Let's put people first in your data & technology.
I'm just one click away!
Spread the word. Someone out there may need this.
Disclaimer: This information is for general informational purposes only and does not constitute legal advice. Privacy laws vary by jurisdiction and change over time. Feel free to connect with me for further clarification or your specific case matter.