Regional data compliance and sovereignty

Skill vaquarkhan/data-engineering-agent-skills/skills/regional-data-compliance-and-sovereignty

Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.

Install

npx -y skills add vaquarkhan/data-engineering-agent-skills --skill regional-data-compliance-and-sovereignty

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Guides agents through region-specific data compliance, residency, sovereignty, and transfer design. Use when data products must operate across jurisdictions such as Europe, the USA, India, Saudi Arabia, or regulated sectors with local supervisory overlays like SAMA.

SKILL.md

3.7 KB, 690 tokens by cl100k_base, as published. Nobody here has run it

Regional Data Compliance And Sovereignty

Overview

Use this skill when data obligations differ by jurisdiction, sector, or supervisory authority. It helps agents translate legal and policy requirements into engineering decisions for storage location, transfer boundaries, access, retention, deletion, and audit evidence. This skill is not legal advice; it is the engineering planning layer that should work with legal, privacy, and compliance owners.

When to Use

operating across Europe, the USA, India, Saudi Arabia, or other multi-jurisdiction footprints
handling data residency, sovereignty, or cross-border transfer constraints
designing controls for GDPR, PDPL, DPDP, state privacy, or sector-specific obligations
working in regulated sectors where local supervisors such as SAMA add extra controls
preparing localized retention, deletion, consent, or breach-evidence paths

Do not assume one global control pattern satisfies every jurisdiction.

Workflow

Name the jurisdiction and sector overlays. Include:
- where data subjects or customers are located
- where data is stored and processed
- sector overlays such as finance, health, or public-sector controls
- supervisory bodies or internal policy owners
Map cross-border and intra-region data flows. Identify:
- ingestion location
- replication and backup paths
- support and admin access paths
- analytics, ML, and partner-sharing paths
- logs and telemetry containing regulated data
Convert obligations into engineering controls. Controls may include:
- regional storage boundaries
- localized encryption and key ownership
- access restrictions by geography or role
- data minimization and masking
- transfer approvals and evidence
- retention and deletion policies by jurisdiction
Design the operating model. Decide:
- what can be centralized
- what must stay local
- how regional exceptions are versioned and reviewed
- how incidents and regulator-facing evidence are handled
Validate the design with local proof. Require:
- lineage of regulated regional flows
- evidence for residency and transfer controls
- ownership and escalation paths
- review by legal, privacy, or compliance stakeholders

Common Rationalizations

Rationalization	Reality
"Our global standard should be enough everywhere."	Jurisdictions often differ on transfer controls, evidence, localization, and supervisory expectations.
"The cloud region solves sovereignty automatically."	Region choice alone does not control support access, backups, logs, exports, or downstream copies.
"It is only analytics data."	Analytics copies still create residency, deletion, and transfer obligations.

Red Flags

jurisdiction-specific controls exist only in policy documents, not engineering paths
support, admin, or backup access crosses borders without review
localized deletion, retention, or transfer evidence is missing
SAMA, GDPR, DPDP, or similar obligations are mentioned with no named control owner

Verification

Jurisdiction and sector overlays are named explicitly
Cross-border flows, copies, and admin paths are mapped
Residency, transfer, access, and deletion controls are engineered, not only described
Regional evidence, ownership, and review paths are defined

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most audit compliance skills give in 690 tokens

Counted across 937 of the 1,487 authors here whose files we hold, read 2026-08-07

Fetch latest guidelines before each reviewin 43 of 937, across 3 files
Group findings by severityin 43 of 937
Check files against all fetched rulesin 42 of 937, across 2 files
Output findings in terse file:line formatin 41 of 937, across 3 files
Ask user which files to review if none specifiedin 41 of 937, across 3 files
Read specified files or prompt user for filesin 39 of 937, across 1 file
Generate the audit reportin 33 of 937, across 30 files
Assign a severity to every findingin 25 of 937
Run automated accessibility scansin 23 of 937, across 13 files
Output a markdown audit reportin 22 of 937
Map findings to WCAG criteriain 20 of 937, across 10 files
Confirm audit scopein 19 of 937, across 9 files

Said here and by no other author read

name jurisdiction and sector overlays
map cross-border data flows
convert obligations into engineering controls
design operating model for local exceptions
validate design with local proof
require lineage of regional flows

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.