data-security-compliance-and-regulated-data

Name: data-security-compliance-and-regulated-data
Author: vaquarkhan

19stars4forks

How to install data-security-compliance-and-regulated-data?

vaquarkhan/data-engineering-agent-skills/data-security-compliance-and-regulated-data

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-security-compliance-and-regulated-data

Installs into the current project.

Summary

Guides agents through regulated-data security and compliance workflows for PII, PCI, HIPAA, PHI, and similar obligations. Use when data products handle sensitive fields, regulated records, control evidence, or audit-bound publish paths.

Files · 1

View on GitHub

SKILL.md

1	# Data Security, Compliance, And Regulated Data
2
3	## Overview
4
5	Use this skill when the data platform handles regulated or highly sensitive data and the change must satisfy engineering, governance, and audit expectations together. It helps agents treat controls, lineage, access, retention, deletion, evidence, and publish safety as one delivery surface.
6
7	## When to Use
8
9	- handling `PII`, `PCI`, `HIPAA`, `PHI`, or other regulated data classes
10	- moving sensitive data between raw, curated, serving, and partner-facing layers
11	- designing masking, tokenization, encryption, or access controls
12	- proving that published data meets audit or policy requirements
13	- changing lineage, retention, deletion, or evidence paths for regulated assets
14	- preparing a system for compliance review, internal audit, or control sign-off
15
16	Do not treat regulated-data handling as a documentation-only exercise.
17
18	## Workflow
19
20	1. Classify the data and obligations.
21	Clarify:
22	- what fields are sensitive
23	- whether the scope includes `PII`, `PCI`, `HIPAA`, `PHI`, or contractual controls
24	- what the allowed usage, retention, and deletion rules are
25	- which teams own the control and audit evidence
26
27	2. Map the data flow end to end.
28	Include:
29	- ingestion and landing zones
30	- transformation and quality layers
31	- serving, BI, feature, reverse-ETL, and extract paths
32	- replication, caching, backup, and replay surfaces
33	- lineage and consumer touchpoints
34
35	3. Define the required controls explicitly.
36	Controls may include:
37	- encryption at rest and in transit
38	- tokenization or masking
39	- row-level and column-level access
40	- environment separation
41	- secrets and key management
42	- restricted publish paths
43	- retention and deletion enforcement
44	- audit logging and evidence capture
45
46	4. Align implementation with policy and platform behavior.
47	Verify that code, SQL, orchestration, and platform configuration all enforce the same control intent.
48
49	5. Define compliance evidence and release gates.
50	Require:
51	- lineage updates
52	- ownership and escalation path
53	- test or validation evidence for masking, access, and deletion behavior
54	- publish approval criteria when regulated data leaves the producing boundary
55
56	6. Plan for incidents and replay.
57	Regulated data failures need:
58	- containment path
59	- audit trail preservation
60	- replay or backfill safety
61	- communication path for impacted consumers or control owners
62
63	## Common Rationalizations
64
65	\| Rationalization \| Reality \|
66	\| --- \| --- \|
67	\| "The warehouse already encrypts everything." \| Encryption alone does not satisfy access, minimization, retention, lineage, or audit evidence obligations. \|
68	\| "This is only internal analytics data." \| Internal use does not remove obligations for `PII`, `PCI`, `HIPAA`, or contractual data-handling controls. \|
69	\| "The source system already handles compliance." \| Downstream copies, extracts, feature stores, and dashboards create new control surfaces. \|
70	\| "We can document the control evidence later." \| Missing evidence often turns routine changes into release blockers or audit findings. \|
71
72	## Red Flags
73
74	- regulated fields are copied without a control matrix
75	- lineage is incomplete for a sensitive publish path
76	- retention or deletion rules stop at one storage layer
77	- replay or backfill behavior for sensitive data is undefined
78	- access controls are described in docs but not enforced in code or platform config
79	- compliance approval depends on tribal knowledge instead of explicit evidence
80
81	## Verification
82
83	- [ ] Sensitive fields and regulatory scope are classified explicitly
84	- [ ] End-to-end lineage and storage locations are mapped
85	- [ ] Access, masking, encryption, retention, and deletion controls are implemented or clearly planned
86	- [ ] Audit evidence and release gates are defined for the regulated-data path
87	- [ ] Incident, replay, and rollback paths preserve both correctness and compliance obligations

People who liked this also viewed

6 picks

Type

data-security-compliance-and-regulated-data

19stars4forks

View on GitHub

How to install data-security-compliance-and-regulated-data?

vaquarkhan/data-engineering-agent-skills/data-security-compliance-and-regulated-data

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-security-compliance-and-regulated-data

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Data Security, Compliance, And Regulated Data
2
3	## Overview
4
5	Use this skill when the data platform handles regulated or highly sensitive data and the change must satisfy engineering, governance, and audit expectations together. It helps agents treat controls, lineage, access, retention, deletion, evidence, and publish safety as one delivery surface.
6
7	## When to Use
8
9	- handling `PII`, `PCI`, `HIPAA`, `PHI`, or other regulated data classes
10	- moving sensitive data between raw, curated, serving, and partner-facing layers
11	- designing masking, tokenization, encryption, or access controls
12	- proving that published data meets audit or policy requirements
13	- changing lineage, retention, deletion, or evidence paths for regulated assets
14	- preparing a system for compliance review, internal audit, or control sign-off
15
16	Do not treat regulated-data handling as a documentation-only exercise.
17
18	## Workflow
19
20	1. Classify the data and obligations.
21	Clarify:
22	- what fields are sensitive
23	- whether the scope includes `PII`, `PCI`, `HIPAA`, `PHI`, or contractual controls
24	- what the allowed usage, retention, and deletion rules are
25	- which teams own the control and audit evidence
26
27	2. Map the data flow end to end.
28	Include:
29	- ingestion and landing zones
30	- transformation and quality layers
31	- serving, BI, feature, reverse-ETL, and extract paths
32	- replication, caching, backup, and replay surfaces
33	- lineage and consumer touchpoints
34
35	3. Define the required controls explicitly.
36	Controls may include:
37	- encryption at rest and in transit
38	- tokenization or masking
39	- row-level and column-level access
40	- environment separation
41	- secrets and key management
42	- restricted publish paths
43	- retention and deletion enforcement
44	- audit logging and evidence capture
45
46	4. Align implementation with policy and platform behavior.
47	Verify that code, SQL, orchestration, and platform configuration all enforce the same control intent.
48
49	5. Define compliance evidence and release gates.
50	Require:
51	- lineage updates
52	- ownership and escalation path
53	- test or validation evidence for masking, access, and deletion behavior
54	- publish approval criteria when regulated data leaves the producing boundary
55
56	6. Plan for incidents and replay.
57	Regulated data failures need:
58	- containment path
59	- audit trail preservation
60	- replay or backfill safety
61	- communication path for impacted consumers or control owners
62
63	## Common Rationalizations
64
65	\| Rationalization \| Reality \|
66	\| --- \| --- \|
67	\| "The warehouse already encrypts everything." \| Encryption alone does not satisfy access, minimization, retention, lineage, or audit evidence obligations. \|
68	\| "This is only internal analytics data." \| Internal use does not remove obligations for `PII`, `PCI`, `HIPAA`, or contractual data-handling controls. \|
69	\| "The source system already handles compliance." \| Downstream copies, extracts, feature stores, and dashboards create new control surfaces. \|
70	\| "We can document the control evidence later." \| Missing evidence often turns routine changes into release blockers or audit findings. \|
71
72	## Red Flags
73
74	- regulated fields are copied without a control matrix
75	- lineage is incomplete for a sensitive publish path
76	- retention or deletion rules stop at one storage layer
77	- replay or backfill behavior for sensitive data is undefined
78	- access controls are described in docs but not enforced in code or platform config
79	- compliance approval depends on tribal knowledge instead of explicit evidence
80
81	## Verification
82
83	- [ ] Sensitive fields and regulatory scope are classified explicitly
84	- [ ] End-to-end lineage and storage locations are mapped
85	- [ ] Access, masking, encryption, retention, and deletion controls are implemented or clearly planned
86	- [ ] Audit evidence and release gates are defined for the regulated-data path
87	- [ ] Incident, replay, and rollback paths preserve both correctness and compliance obligations

People who liked this also viewed

6 picks

Type