Legal Requirements for Websites and Apps, by Country

Start with your business location, the markets you target, and what your product actually does. Foreign privacy and consumer laws can apply, but a website being accessible from a country is not by itself a universal legal trigger. For example, GDPR territorial scope includes processing in the context of an EU establishment, or a non-EU business offering goods or services to people in the EU or monitoring their behaviour there. Assess each law separately. The good news is that the requirements overlap far more than they differ. Across all seven markets below, the same eight things recur: know what data you collect, say so honestly, handle consent and tracking choices correctly, handle applicable access, correction, deletion and portability rights, be clear about price and cancellation, be usable by disabled people, be careful with minors, and disclose AI. These are reusable product capabilities, not proof of compliance in every market. What's left is a short list of local specifics — and that's what the country guides are for. Start with the pre-launch checklist for the universal layer and the ten prompts that build it. Then read only the markets you actually serve.

Three questions that pick your reading list

1. Where are you established, and which markets do you serve or monitor? List your intended customers, marketing, delivery coverage and tracking practices. An accessible signup form is a signal to investigate, not proof that every foreign law applies. Language also differs from jurisdiction: Spanish does not mean Spain alone, and French does not mean France alone.

2. Do you take money? If yes, consumer law joins privacy law, and consumer law moves faster and complains louder. Price transparency, refunds and cancellation rights are the sections to read first in each country guide — and they're the ones that produce actual complaints.

3. Is the service directed to, likely to be accessed by, or known to be used by minors? Different laws use different tests and age thresholds. Assess your actual audience and features before collecting extra identity data or choosing age-assurance tools.

Three yeses and a global audience is a real project. Even a one-market launch needs testing and business decisions beyond a prompt.

Seven markets, six questions

Every row is a compression. The thresholds, exemptions and dates are in the guides.

The prompt for people selling in more than one market

The expensive mistake in multi-market compliance is building seven versions of something that should have been built once. This prompt sorts your work into build-once and build-variant before you touch anything:

I am launching a product that will be used by people in: [[LIST YOUR MARKETS]].

Do not give me legal advice and do not cite laws. Instead, read this application and produce a build plan.

STEP 1 — Inventory the jurisdiction-sensitive behaviour that already exists:
- What loads on a fresh visit before the user chooses anything: analytics, advertising pixels, chat widgets, embedded video, third-party fonts and maps.
- Whether account deletion and data export exist and actually work end to end.
- Whether age is checked anywhere, and how.
- Whether prices are shown with tax included, and whether renewal date and amount appear before purchase.
- Whether cancellation is self-service, and how many clicks it takes.
- Every place AI generates or influences what the user sees, and whether that is disclosed.
- Basic accessibility: keyboard navigation, form labels, colour contrast, alt text.
- Whether any user can read another user's records.

STEP 2 — Mark each item PASS, FAIL or UNKNOWN based only on what is in the code. Say UNKNOWN rather than assuming.

STEP 3 — Split the FAILs into two lists:
- BUILD ONCE: requirements that are the same in every market I named.
- BUILD VARIANT: requirements that differ by market, with a note on what varies.

STEP 4 — Order the BUILD ONCE list cheapest-fix-first.

Do not implement anything yet. Give me the tables.
Copy prompt

Run it after the ten prompts in the pre-launch checklist, which build the universal layer that most of the BUILD ONCE list will refer to.

What every market is converging on

A useful shared implementation includes clear notices, minimal collection, secure access, accessible interactions, a working complaints channel and straightforward cancellation. These reduce repeated engineering work. The legal basis, eligibility for a right, response deadline and required evidence still vary.

A request form with a reliable response process can be valid; a universal two-click deletion button is not a rule in every country. Consent-first tracking is a conservative product choice, not the only lawful approach everywhere. AI disclosure likewise depends on the feature and applicable law.

Use the EDPB territorial-scope guidance to understand why mere website availability and targeted activity are different.

What this section doesn't cover yet

Honest limits, so you know where the edges are:

• Seven markets, not the world. France and Spain now have targeted launch notes inside the EU guide, not complete national surveys. Germany, India, Japan, the UAE, Singapore and Mexico remain outside that national detail — and Germany's identity-disclosure rules, for one, are enforced more strictly than the EU baseline suggests.
• Sector rules are out of scope. Healthcare, finance, insurance, gambling, education records and legal services each carry a regime that sits on top of everything here.
• Tax is an accountant's question, not a lawyer's, and it isn't covered beyond flagging where registration thresholds exist.
• This is a fast-moving area. Several rules on this page arrived in 2026 and several more are mid-implementation. Every page carries a "Last updated" date; if you're reading one more than six months old, verify the dated claims before relying on them.

What the build checks establish

The prompts are implementation requests, not a legal certification. Two-click controls and consent-first defaults are practical design choices, not universal statutory requirements. Confirm jurisdiction, exceptions, retention and provider contracts separately. Verify controls with test accounts and actual browser/network behaviour; a builder’s PASS based only on code inspection is incomplete evidence.

Official sources and review scope

Updated September 14, 2026. The linked sources support the scope and corrections discussed here; this is an editorial review, not an exhaustive legal opinion or a certification of your product. Check the operative rule when acting.

• EDPB territorial scope

Start with what's the same everywhere, then handle what isn't. The pre-launch checklist has the universal layer and the ten prompts that build it; the country guides have the specifics for the United States, the European Union, the United Kingdom, Canada, Australia, Brazil and Israel. Haven't built the thing yet? Start at From Idea to Live App. You can build this.