메뉴
Use when defining ownership, stewardship, access control, privacy, lineage, retention, compliance, and change management for data products.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | des-governance-and-security |
| description | Use when defining ownership, stewardship, access control, privacy, lineage, retention, compliance, and change management for data products. |
Use before production release and whenever sensitive data, shared metrics, external access, compliance obligations, or cross-team ownership is involved.
Create governance and security controls that make the data platform trustworthy, compliant, and accountable — covering PII classification, access control, retention enforcement, and audit logging.
This skill must stop when a required decision cannot be safely inferred.
The agent must not continue if any of these are unresolved:
Use the detailed HALT checkpoints in steps/: readiness HALT in step 01, phase decision HALT in step 02, and validation HALT in the final step. HALT asks for a decision, not permission to continue.
12-data-contract-specification.md).| Sensitivity Level | Examples | Access Policy | PII Treatment |
|---|---|---|---|
| Public | Aggregated stats, published reports | Open read access | None needed |
| Internal | Revenue by region, product metrics | Authenticated employees only | None needed |
| Confidential | Raw orders, pricing data | Role-based; need-to-know only | No PII but still restricted |
| PII | Names, emails, phone, IP address | Strict RBAC; masked in Silver+ | Hash / Redact / Tokenize |
| Regulated | Credit card, health data | RBAC + RLS + encryption at rest | Tokenization + audit trail required |
| PII Category | Recommended Method | Reversible? | When to Use |
|---|---|---|---|
| Email, name, username | SHA-256 hash + salt | No | Join keys where value not needed |
| Phone, ID numbers | Partial redaction (+84-***-1234) | No | Display only, no join requirement |
| Credit card numbers | Tokenization (format-preserving) | Yes (authorized roles) | PCI-DSS regulated data |
| IP address | Pseudonymization (mask last octet) | Partial | Analytics requiring geo, not identity |
| Health records | Encryption at column level | Yes (with key) | HIPAA regulated data |
The output_file path is configured in customize.toml. Default:
Write the final artifact to:
{project-root}/_des-output/planning-artifacts/19-governance-and-security.md
Use the matching template from:
{skill-root}/../../templates/19-governance-and-security-template.md
After writing the file, summarize the file path and recommend the next skill.
bronze-raw-readers role only.| Anti-Pattern | Why It Fails |
|---|---|
| Treating governance as documentation after release | Access control gaps are exploited before documentation is written |
| Broad read access to Bronze/raw data | Raw PII is exposed without masking; compliance breach risk |
| Service accounts with admin permissions | A compromised service account can exfiltrate or delete all data |
| No audit log on data exports | GDPR requires proof of who accessed PII data and when |
| Retention policy documented but not enforced | Over-retained PII is a GDPR violation; documentation is not a defense |
| Manual GDPR deletion without testing | Partial deletions leave PII in derived tables; incomplete compliance |
| Undercurrent | Action Required at This Phase |
|---|---|
| Security | This is the core security phase — all access control, encryption, and audit logging defined here |
| Data Management | Catalog entries updated with classification; stewards assigned; lineage verified |
| DataOps | Schema change control process enforced via CI/CD PR gates for PII datasets |
| Data Architecture | RBAC/RLS design may require architectural changes (separate schemas, federated catalog) |
| Orchestration | Retention lifecycle deletion jobs scheduled and monitored |
| Software Engineering | Credentials never in code; column masking implemented at Silver transform layer, not ad-hoc |
Next use des-cost-and-performance-optimization to review partitioning, compute, query performance, and platform cost before final CI/CD and release controls.
Use when designing the global data architecture, including storage, compute, integration patterns, layer strategy, environment promotion, security posture, observability, governance, cost, operational burden, and decision reversibility.
Use when creating the Bronze Layer Specification for raw/near-raw storage, source fidelity, ingestion metadata, schema drift, replay, quarantine, retention, access control, and lineage before Silver design.
Use when designing CI/CD, testing strategy, release gates, deployment promotion, rollback, release evidence, and environment validation for data products.
Use when designing cost, performance, scalability, storage, compute, query, serving, monitoring, and FinOps optimization strategies for data products.
Use when creating the Data Contract Specification for source feeds, Silver datasets, Gold datasets, serving outputs, dashboards, semantic models, APIs, ML/AI datasets, external exports, or downstream systems that need stable structure, meaning, freshness, quality, access, ownership, lineage, and change behavior.
Use when defining or designing data quality dimensions, rules, thresholds, severity, gates, failure handling, ownership, and validation expectations across Bronze, Silver, Gold, contracts, transformations, and serving outputs.