regional-data-compliance-and-sovereignty

Name: regional-data-compliance-and-sovereignty
Author: vaquarkhan

19stars4forks

How to install regional-data-compliance-and-sovereignty?

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

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

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Regional Data Compliance And Sovereignty
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- operating across `Europe`, the `USA`, `India`, `Saudi Arabia`, or other multi-jurisdiction footprints
10	- handling data residency, sovereignty, or cross-border transfer constraints
11	- designing controls for `GDPR`, `PDPL`, `DPDP`, state privacy, or sector-specific obligations
12	- working in regulated sectors where local supervisors such as `SAMA` add extra controls
13	- preparing localized retention, deletion, consent, or breach-evidence paths
14
15	Do not assume one global control pattern satisfies every jurisdiction.
16
17	## Workflow
18
19	1. Name the jurisdiction and sector overlays.
20	Include:
21	- where data subjects or customers are located
22	- where data is stored and processed
23	- sector overlays such as finance, health, or public-sector controls
24	- supervisory bodies or internal policy owners
25
26	2. Map cross-border and intra-region data flows.
27	Identify:
28	- ingestion location
29	- replication and backup paths
30	- support and admin access paths
31	- analytics, ML, and partner-sharing paths
32	- logs and telemetry containing regulated data
33
34	3. Convert obligations into engineering controls.
35	Controls may include:
36	- regional storage boundaries
37	- localized encryption and key ownership
38	- access restrictions by geography or role
39	- data minimization and masking
40	- transfer approvals and evidence
41	- retention and deletion policies by jurisdiction
42
43	4. Design the operating model.
44	Decide:
45	- what can be centralized
46	- what must stay local
47	- how regional exceptions are versioned and reviewed
48	- how incidents and regulator-facing evidence are handled
49
50	5. Validate the design with local proof.
51	Require:
52	- lineage of regulated regional flows
53	- evidence for residency and transfer controls
54	- ownership and escalation paths
55	- review by legal, privacy, or compliance stakeholders
56
57	## Common Rationalizations
58
59	\| Rationalization \| Reality \|
60	\| --- \| --- \|
61	\| "Our global standard should be enough everywhere." \| Jurisdictions often differ on transfer controls, evidence, localization, and supervisory expectations. \|
62	\| "The cloud region solves sovereignty automatically." \| Region choice alone does not control support access, backups, logs, exports, or downstream copies. \|
63	\| "It is only analytics data." \| Analytics copies still create residency, deletion, and transfer obligations. \|
64
65	## Red Flags
66
67	- jurisdiction-specific controls exist only in policy documents, not engineering paths
68	- support, admin, or backup access crosses borders without review
69	- localized deletion, retention, or transfer evidence is missing
70	- `SAMA`, `GDPR`, `DPDP`, or similar obligations are mentioned with no named control owner
71
72	## Verification
73
74	- [ ] Jurisdiction and sector overlays are named explicitly
75	- [ ] Cross-border flows, copies, and admin paths are mapped
76	- [ ] Residency, transfer, access, and deletion controls are engineered, not only described
77	- [ ] Regional evidence, ownership, and review paths are defined

People who liked this also viewed

6 picks

Type

regional-data-compliance-and-sovereignty

19stars4forks

View on GitHub

How to install regional-data-compliance-and-sovereignty?

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

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Regional Data Compliance And Sovereignty
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- operating across `Europe`, the `USA`, `India`, `Saudi Arabia`, or other multi-jurisdiction footprints
10	- handling data residency, sovereignty, or cross-border transfer constraints
11	- designing controls for `GDPR`, `PDPL`, `DPDP`, state privacy, or sector-specific obligations
12	- working in regulated sectors where local supervisors such as `SAMA` add extra controls
13	- preparing localized retention, deletion, consent, or breach-evidence paths
14
15	Do not assume one global control pattern satisfies every jurisdiction.
16
17	## Workflow
18
19	1. Name the jurisdiction and sector overlays.
20	Include:
21	- where data subjects or customers are located
22	- where data is stored and processed
23	- sector overlays such as finance, health, or public-sector controls
24	- supervisory bodies or internal policy owners
25
26	2. Map cross-border and intra-region data flows.
27	Identify:
28	- ingestion location
29	- replication and backup paths
30	- support and admin access paths
31	- analytics, ML, and partner-sharing paths
32	- logs and telemetry containing regulated data
33
34	3. Convert obligations into engineering controls.
35	Controls may include:
36	- regional storage boundaries
37	- localized encryption and key ownership
38	- access restrictions by geography or role
39	- data minimization and masking
40	- transfer approvals and evidence
41	- retention and deletion policies by jurisdiction
42
43	4. Design the operating model.
44	Decide:
45	- what can be centralized
46	- what must stay local
47	- how regional exceptions are versioned and reviewed
48	- how incidents and regulator-facing evidence are handled
49
50	5. Validate the design with local proof.
51	Require:
52	- lineage of regulated regional flows
53	- evidence for residency and transfer controls
54	- ownership and escalation paths
55	- review by legal, privacy, or compliance stakeholders
56
57	## Common Rationalizations
58
59	\| Rationalization \| Reality \|
60	\| --- \| --- \|
61	\| "Our global standard should be enough everywhere." \| Jurisdictions often differ on transfer controls, evidence, localization, and supervisory expectations. \|
62	\| "The cloud region solves sovereignty automatically." \| Region choice alone does not control support access, backups, logs, exports, or downstream copies. \|
63	\| "It is only analytics data." \| Analytics copies still create residency, deletion, and transfer obligations. \|
64
65	## Red Flags
66
67	- jurisdiction-specific controls exist only in policy documents, not engineering paths
68	- support, admin, or backup access crosses borders without review
69	- localized deletion, retention, or transfer evidence is missing
70	- `SAMA`, `GDPR`, `DPDP`, or similar obligations are mentioned with no named control owner
71
72	## Verification
73
74	- [ ] Jurisdiction and sector overlays are named explicitly
75	- [ ] Cross-border flows, copies, and admin paths are mapped
76	- [ ] Residency, transfer, access, and deletion controls are engineered, not only described
77	- [ ] Regional evidence, ownership, and review paths are defined

People who liked this also viewed

6 picks

Type