FlowTux and global privacy laws: GDPR, CCPA, DPDP, and more

Privacy law is no longer one regime. A team running internal support may answer to half a dozen at once. FlowTux is built so the same controls — consent, access, deletion, residency, audit — satisfy the common core across them, with jurisdiction-specific handling where the laws diverge.

Nearly every modern privacy law shares the same skeleton, because most of them were drafted with the GDPR on the desk. There is a party who decides why data is processed and a party who processes it on their behalf; individuals hold rights over their own data; personal data must be kept no longer than needed; breaches must be reported on a clock; and moving data across borders requires a documented mechanism.

That is why "configure once, satisfy several" is achievable rather than marketing. Region, retention, sensitive-field rules, deletion tooling, sub-processor review, and an auditable log of what the system did cover the shared core of every regime below. The divergences are real but narrower than the questionnaires suggest.

The EU GDPR and UK GDPR set the high bar: lawful basis, data subject rights, records of processing, breach notice, and DPA-backed processor obligations. A team that satisfies these has usually done most of the work required everywhere else.

The UK diverges mainly on transfer paperwork rather than substance — the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, rather than the SCCs alone. Same controls, different signature page. How FlowTux handles GDPR goes through the detail, including which obligations stay with you as controller.

California's CCPA, as amended by the CPRA, gives consumers rights to know, delete, correct, and opt out of sale or sharing. FlowTux does not sell or share personal data in the statutory sense, honours deletion and access requests through the admin console, and logs fulfilment for your records.

The vocabulary trips people up more than the substance. US state laws generally use "business" and "service provider" where Europe uses controller and processor, and the service-provider designation carries contractual requirements that a DPA needs to state explicitly. The concepts map; the wording does not, which is why a European-only DPA sometimes fails a Californian review.

The newer Virginia, Colorado, Connecticut, and Texas laws follow the same shape closely enough that the same configuration holds. Where they differ most is on sensitive-data consent and on universal opt-out signals, both of which land on you as the business rather than on an internal support tool.

India's Digital Personal Data Protection Act introduces notice-and-consent obligations, a right to erasure, and a blacklist model for cross-border transfers — permitted except to countries the government restricts. Its vocabulary differs again: data fiduciary rather than controller, data principal rather than data subject.

Two India-specific points worth planning around. Sector regulators can impose stricter in-country requirements on top of the Act, which is why financial services and health teams often need the India region regardless of where the rest of the company sits — that region runs on Microsoft Azure. And consent obligations are framed more tightly than under GDPR's legitimate-interests route, so employee-facing processing deserves a deliberate basis rather than an assumed one.

Canada's PIPEDA centres on meaningful consent and on accountability for transfers: you remain responsible for a processor's handling, which makes the sub-processor list and the DPA the operative documents rather than geography.

Brazil's LGPD tracks the GDPR structure closely — lawful bases, data subject rights, and an ANPD reporting path — so a GDPR-shaped configuration carries over with little adaptation. Australia's Privacy Act and the APPs emphasise purpose limitation and notifiable breach reporting, with reforms tightening obligations in recent years, so check the current position rather than a two-year-old summary.

Across all three the practical requirement is the same: export and delete tooling that works without engineering involvement, a breach-notice path, and documentation of who processes what and where.

Three places, and they are worth knowing because they are the ones a single configuration cannot paper over.

Breach clocks differ. GDPR gives the controller 72 hours to notify a supervisory authority; other regimes use different triggers and different windows, some tied to harm thresholds rather than fixed hours. Our commitment is to notify you without undue delay so that whichever clock applies to you is still runnable.

Transfer mechanisms differ: SCCs for the EU, the IDTA or Addendum for the UK, a restriction list for India, accountability-based rules for Canada and Australia. The mechanism is paperwork, but it is paperwork a reviewer will ask to see.

And consent models differ most of all. GDPR permits legitimate interests for a lot of ordinary processing; DPDP leans harder on consent; US state laws focus on opt-out rights rather than opt-in. This is the one area where the same configuration genuinely produces different obligations for you as controller, and no vendor setting resolves it.

Determining and documenting the lawful basis for your own processing. Maintaining your own record of processing activities. Setting retention periods that match your obligations rather than our defaults. Responding to data subjects within statutory windows. And deciding which categories of ticket belong in the tool at all — the most consequential control, and the one no vendor can operate for you.

A vendor can supply mechanisms, documentation, and evidence. It cannot supply the assessment. Any page claiming a product makes you compliant with a list of acronyms is describing something that does not exist.

The practical takeaway: configure the workspace once — region, retention, sensitive-field rules, sub-processor review — and you cover the overlapping core of every major regime. Where a law adds something specific, like DPDP transfer restrictions or a CPRA opt-out, it lands on top of that configuration rather than requiring a different one.

One honest caveat to end on. We are not SOC 2 certified; the Type II audit is in progress and we do not present it as complete. Privacy law compliance is also not something a vendor can be certified in — what exists is a DPA with the right transfer paperwork, a published sub-processor list, region pinning, deletion and export tooling, and an auditable record of what the system did. That is what a reviewer should be assessing, from us or anyone else.