Who this is for
- Data Platform Engineers who implement or automate access requests, schema change approvals, and data product onboarding.
- Data Stewards and Governance leads who need repeatable, auditable decision flows.
- Analyst/ML teams interacting with governed data and seeking predictable turnaround times.
Prerequisites
- Basic understanding of data catalog concepts (datasets, owners, classifications).
- Familiarity with IAM/roles and environment separation (dev/test/prod).
- Comfort reading simple process diagrams or state machines.
Why this matters
In real teams, governance is not just policy text. You need a clear path from request to decision to enforcement. Without workflows, access is slow or inconsistent, schema changes break downstream users, and audits become painful. With well-defined approvals, you deliver safety, speed, and clear accountability.
- Granting data access with the right approvers and time-bound permissions.
- Approving schema changes, data product onboarding, and deprecations.
- Handling exceptions (e.g., expedited access) while keeping evidence for audits.
Concept explained simply
A governance workflow is a small factory for decisions. Requests go in, the right people check the right things in the right order, and a decision comes out with a timestamp and evidence. The workflow does three jobs:
- Route: send the request to the relevant owners and reviewers.
- Decide: apply policies and risk checks to approve or deny.
- Record: log who did what, when, and why (including expiration or conditions).
Mental model
Think of a state machine:
- States: Draft → Submitted → In Review → Approved/Rejected → Implemented → Verified → Closed
- Transitions: actions that move states (submit, approve, reject, implement, verify)
- Guards: rules that must be true to allow a transition (e.g., PII requires data owner + security approval)
- Events: triggers or timeouts (e.g., auto-expire after 30 days)
Core building blocks
- Triggers: request intake forms in your catalog or ticketing system.
- Roles and RACI: requester, data owner, steward, security/compliance, platform engineer (implementer).
- Risk tiers: non-sensitive vs sensitive vs highly regulated datasets.
- SLA: decision timelines (e.g., 2 business days for standard access).
- Segregation of duties: requester cannot be the sole approver; implementer differs from approver where risk is high.
- Evidence: approval comments, policy references, ticket IDs, audit logs.
- Enforcement: automated role grants, policy updates, or CI/CD gates for schema changes.
- Expiry and review: time-bound access and periodic re-certification.
Worked examples
Example 1: Analyst requests read access to PII table
- Trigger: Analyst submits access request, states purpose and duration (30 days).
- Routing: Data Owner → Security
- Checks: Valid business purpose, minimum scope, data masking available.
- Decision: Owner approves; Security approves with condition: use masked view, 30-day expiry.
- Enforcement: Platform applies role grant to masked view; sets auto-revoke after 30 days.
- Evidence: Request ID, approvers, timestamps, policy link, condition notes.
- Verification: Steward confirms role applied; analyst can query masked view.
Example 2: Schema change to drop a column used by downstream dashboards
- Trigger: Engineer proposes change in catalog or change ticket with impact analysis.
- Routing: Table Owner → Steward → Representative of downstream consumer group.
- Checks: Lineage shows affected dashboards; deprecation notice issued; fallback plan.
- Decision: Conditional approval with deprecation window of 30 days and migration guide.
- Enforcement: CI/CD gate enforces a do-not-drop before window ends; notifies subscribers.
- Evidence: Approvals, deprecation window, communications captured.
- Verification: After window, drop is executed; post-change check passes.
Example 3: Policy exception for urgent incident analysis
- Trigger: Incident manager requests elevated access for 24 hours.
- Routing: Data Owner + Security + Incident Commander
- Controls: Break-glass account, session recording, read-only where possible.
- Decision: Approve with strict time limit and retrospective review.
- Enforcement: Temporary grant with auto-revoke; monitoring enabled.
- Evidence: Incident ID, rationale, time window, reviewers.
- Verification: Access automatically revoked; review meeting outcome logged.
Design patterns
Low-risk auto-approve
Non-sensitive datasets with documented owner and usage pattern can auto-approve with owner FYI. Keep expiry and audit logs.
Two-step sensitive approval
Owner approves business need; Security approves controls (masking, read-only). Either can reject.
Delegated approvers and out-of-office
Use groups for approvers; allow delegates to prevent SLA breaches. Log who acted.
Break-glass (emergency)
Requires dual approval and short expiry. Elevated monitoring and post-incident review mandatory.
Time-bound and re-certification
Grants expire automatically. Periodic access reviews re-validate necessity.
How to implement a minimal workflow
- Define request types: Access, Schema Change, Data Product Onboarding, Exception.
- Map approvers per type and risk tier: who must approve and in which order.
- Create intake forms: required fields (purpose, dataset, duration, data sensitivity, downstream impact).
- Set SLAs and escalations: e.g., auto-escalate to steward after 48 hours waiting.
- Automate enforcement: role grants, masked views, CI/CD gates, notifications.
- Log evidence: requester, approvers, decisions, timestamps, conditions, expiry.
- Test with sample requests and a rollback path for mistakes.
Exercises and checklist
Do these exercises below. You can compare your work with the provided solutions. Then run through the checklist.
- [ ] Each request type has clear approvers and order.
- [ ] SLAs are defined and visible to requesters.
- [ ] Evidence is captured automatically for audits.
- [ ] Segregation of duties is enforced for high-risk requests.
- [ ] Grants have expiry and are re-certified periodically.
- [ ] Emergency access has tighter controls and reviews.
Common mistakes and self-check
- Mistake: Single approver for sensitive data. Fix: Require dual approval (owner + security) and log both.
- Mistake: No expiry on access. Fix: Use time-bound grants and automated revocation.
- Mistake: Approvers overloaded. Fix: Delegate via groups; set SLAs and escalations.
- Mistake: Evidence scattered. Fix: Centralize decision logs with request ID and policy references.
- Mistake: Ignoring downstream impact in schema changes. Fix: Use lineage checks and deprecation windows.
Self-check prompts
- Can you show an auditor who approved a specific access and why?
- Do you know which requests are pending and past SLA right now?
- If an approver is on leave, does the queue stall or continue?
- Do emergency accesses always auto-revoke?
Practical projects
- Access workflow pilot: Implement a two-step approval for PII read access on one domain. Success criteria: decisions within SLA, automatic expiry, single audit log.
- Schema change gate: Add a CI/CD check that blocks drops unless a valid approval ID and deprecation window are present. Success criteria: no breaking drops reach prod without sign-off.
- Quarterly re-certification: Generate a list of active high-risk access grants, route to owners for re-approval or revoke. Success criteria: 95% completion within 2 weeks.
Learning path
- Before this: Data classification and ownership; basic catalog operations.
- This subskill: Define, automate, and audit approvals.
- Next: Data quality rules, lineage-driven impact analysis, and policy-as-code integration.
Quick test and progress
Take the quick test below to check your understanding. Anyone can take it; only logged-in users have their progress saved.
Next steps
- Automate at least one approval path end-to-end, including evidence capture.
- Add expiries and re-certification to existing long-lived grants.
- Measure and improve SLA adherence with simple weekly reports.
Mini challenge
Pick one dataset in your domain and classify it. Propose an approval flow for read access that varies by sensitivity (public, internal, PII). Include roles, order, SLA, expiry, and evidence. Keep it to five steps or fewer.