Access, least privilege, and just give me prod

The request lands in Slack at 4:55 p.m.: “Need prod access to customers for a quick pull. Board deck tomorrow. Just read-only.” You have two bad instincts. One is to say yes and hope nothing leaks. The other is to say no and become the villain while someone exports the same rows through a personal dashboard token you never saw.

Least privilege is not a personality trait. It is a habit of matching need to the smallest safe surface: sample data when the question is shape, masked analytics when the question is trend, production read when the question truly needs live identifiers, write never-by-default. Stewardship is how that habit survives real deadlines.

This is Part 3 of Data stewardship at work. Part 1 named steward, owner, and custodian. Part 2 mapped truth and catalog cards. Here we handle access: the ladder from samples to prod write, a request matrix of need vs ask vs avoid, and scripts you can use without turning into a compliance bot. Program-layer governance, privacy reviews, and clean rooms still own policy architecture. This post is the Tuesday practice when someone wants the keys.

What you’ll learn

Why “just give me prod” is usually a mis-specified need
A least privilege ladder from synthetic samples to production write
How stewards, owners, and custodians split access decisions (RACI for grants)
A filled access matrix: need, ask for, avoid
Patterns for time-boxed grants, masked views, and audit-friendly tickets
Common mistakes and a one-hour cleanup practice

What people mean when they say “prod”

“Prod” is ambiguous on purpose. Clarify which of these they want:

Live operational database (OLTP) used by the product
Production warehouse schema with full history
Production BI workspace with customer-level rows
Production secrets, service accounts, or write paths
Yesterday’s certified analytics table that happens to be “live enough”

Many “prod” requests are really “I need a complete, current, trustworthy grain for analysis.” That often means a certified warehouse table from your pipeline path, not a login to the checkout primary. Querying OLTP for heavy analytics is a reliability risk even when privacy is fine. Put that distinction in the first reply.

Rule of thumb: Grant the data product that answers the question, not the environment with the scariest name.

The least privilege ladder

Climb only as high as the task requires. Default to the lowest rung that still produces a correct decision.

Least privilege ladder from samples to prod write

Rung 1: Synthetic or public samples

Use for shape, join logic, notebook demos, onboarding, and vendor proofs. No real people. If an analyst is learning SQL patterns, they do not need yesterday’s emails. Keep a small sample pack next to the domain catalog card from Part 2.

Rung 2: Masked or aggregated analytics

Trends, funnels, and regional rollups without re-identifying individuals. Great for most growth questions and many board charts. If the metric is already defined in the metrics series style, aggregated certified tables often suffice.

Rung 3: Pseudonymous row-level analytics

Hashed IDs, no direct contact fields. Enough for cohort work, churn models, and many quality investigations. Still sensitive: join risks and small-cell re-identification exist. Document sensitivity on the catalog card.

Rung 4: Identified production read (analytics plane)

Named customers, emails, tickets, or payment references in a warehouse or controlled BI model. Justify by task: support remediation, fraud review, contractual reporting. Prefer views that project only needed columns. Time-box the grant when the task is temporary.

Rung 5: Operational production read (OLTP / admin tools)

Direct access to systems that run the product. High blast radius: locking tables, reading secrets adjacent to data, creating load. Reserve for engineers and rare break-glass support with audit.

Rung 6: Production write / admin

Inserts, updates, deletes, grant management, job deploys. Dual control where possible. Never “for convenience” on a shared analyst account. Custodians live here with procedure; stewards rarely need it for stewardship alone.

OWASP and general security guidance keep repeating the same idea: give the least privilege required for a function, and separate duties so one account cannot do everything quietly. You do not need to become a security engineer to apply the ladder in tickets.

Who decides: RACI for access

Reuse Part 1 language.

Task	Steward	Owner	Custodian	Security / Legal
Confirm business need and data product	R	C / A for sensitive domains	I	C when PII or regulated
Approve identified PII access	C	A or co-A with policy	I	C or A per policy
Implement grant / role	I	I	R / A	C
Time-box / revoke	R (track)	I	R (apply)	I
Break-glass emergency	C	I	R	I / audit after

Stewards should not be silent yes-machines. Their job is to reframe “prod” into a rung and a specific object. Owners accept residual risk for sensitive domains. Custodians apply technical controls without inventing business purpose. If your company has a formal access governance tool, feed it honest tickets, not theater checkboxes.

Need vs ask vs avoid: the access matrix

Train requesters (and yourself) to speak in needs. The matrix below is a teaching tool you can paste into an intake form.

Access request matrix of need vs ask for vs avoid

Real need	Ask for	Avoid
Learn table shape / write a first query	Synthetic sample or narrow sandbox	Full prod dump
Board chart on weekly revenue	Certified aggregated metric table or locked dashboard	Customer email export “to double-check”
Debug a join bug in a model	Pseudonymous rows + documented grain	OLTP write user
Support a single customer complaint	Support tool or time-boxed identified view for that ID	Warehouse SELECT on all customers
Build a churn model	Feature table with hashed IDs, approved retention	Unlogged CSV on a laptop
Partner measurement across companies	Clean room or contracted aggregate exchange	Emailing raw customer lists
Fix a bad load	Custodian runbook + restore rights for eng	Shared admin password in a channel
Ad-hoc executive curiosity	Existing dashboard with filters	New permanent prod role “just in case”

When the ask and the need diverge, rewrite the ticket before the grant. That one sentence saves months of leftover privileges.

Worked example: three requests on a Monday

Domain: customers and orders. Catalog cards exist for analytics.certified.weekly_order_facts (no email) and analytics.restricted.customer_contact (email, phone). Steward is the orders domain analyst. Owner is the Finance analytics lead for revenue; Support lead owns contact data purpose.

Request A: “Prod for board revenue check”

Need: validate weekly net revenue against last week’s pack. Ask received: “warehouse prod, all tables.” Better grant: read on certified weekly facts + metric definition link. Rung 2 or 3, not 5. No contact table.

Request B: “List of emails for churned users in EU”

Need: outreach campaign. This is marketing purpose, not analytics debugging. Route to approved marketing tools and legal basis, not a free SQL select. If analytics must help, use an approved export job with logging, suppression lists, and retention limits. Stewards should not become silent CRM engines.

Request C: “I need to DELETE bad test orders in prod”

Need: clean operational mess. This is custodian territory with runbooks, not analyst curiosity. Prefer fixing in the app admin with audit, or a controlled script under dual review. Rung 6. Steward Consulted on analytics side effects; not Responsible for the delete.

Ticket template you can require (even in Slack, as a form-like paste):

ACCESS REQUEST
Requester:
Team:
Deadline:
Business question (one sentence):
Decision this unlocks:
Data product requested (table/view/dashboard):
Columns needed (list):
Row filter needed (time range, region, customer id):
Sensitivity (none / pseudonymous / identified PII):
Environment (analytics warehouse / BI / OLTP / other):
Duration (hours/days; default 7 days if blank):
Why lower rungs fail (sample / aggregate / masked):
Will data leave the platform? (no / yes + where):
Owner notified? (yes/no):

Custodian implementation sketch (warehouse roles, illustrative):

-- Illustrative only: patterns, not a copy-paste for every cloud
-- 1) Prefer role per purpose, not per person forever
CREATE ROLE analyst_orders_certified_read;
GRANT SELECT ON analytics.certified.weekly_order_facts
  TO ROLE analyst_orders_certified_read;

-- 2) Identified contact data in a separate role
CREATE ROLE support_customer_contact_read;
GRANT SELECT ON analytics.restricted.customer_contact
  TO ROLE support_customer_contact_read;

-- 3) Time-box by process: calendar reminder + scheduled revoke job
-- (Platform-specific: temporary grants, access reviews, SCIM)
-- Steward tracks; custodian applies REVOKE when the ticket ends.

-- 4) Never grant accountadmin-equivalent to shared human users
-- for "speed." Use break-glass with logging instead.

Quality still matters when access is tight. People escalate to broader access when certified tables are wrong or late. That is a quality and pipeline problem wearing an access costume. Keep checks healthy with habits from the data quality series.

Masked views and column discipline

If ten people need “customer-ish” rows but only two need email, do not grant the wide table to ten. Publish a view:

CREATE VIEW analytics.certified.customer_analytics AS
SELECT
  customer_id_hash,
  signup_week,
  region_code,
  plan_tier,
  is_churned
FROM analytics.restricted.customer_full;
-- email, phone, legal_name intentionally omitted

Document the view on the catalog card. Status Certified only if freshness and grain are honest. “Masked” is not a synonym for “harmless.” Location plus rare plan tiers can still re-identify. Sensitivity notes belong on the card.

Time-boxing, reviews, and leftover keys

Permanent access is how companies wake up with 400 “temporary” roles. Defaults that work:

Project access: 7 or 30 days, renew explicitly.
Role-based access for stable jobs: quarterly access review by steward + manager.
Break-glass: hours, not weeks, with automatic ticket.
Service accounts: owned by a team, rotated, no human password sharing.

Stewards can keep a simple register (spreadsheet is fine at small scale): who, what object, rung, expiry, ticket link. Custodians automate where possible. Owners care when the domain is regulated or executive-facing.

Clean rooms, partners, and “can we just send the file?”

Cross-company analysis is where good intentions leak lists. If the real need is overlap measurement or campaign lift with a partner, prefer contracted patterns such as data clean rooms or approved aggregate exchanges. “CSV by email” is not a clean room. Stewards should recognize the pattern early and pull Legal/Security in as Consulted before the first sample leaves.

Internal “partners” count too. Shipping full customer tables to a vendor POC on a laptop is still an access decision. Use samples (rung 1) until procurement and DPA say otherwise.

Common mistakes

Granting environment instead of object: “all prod” when one view would do.
Shared personal credentials: three people, one login, zero audit trail.
Permanent temporary: no expiry, no review, role lives forever.
Security as pure blocker: no lower-rung alternatives offered, so shadow access thrives.
Steward as free export service: repeating identified pulls without purpose or logging.
Ignoring BI tokens: warehouse locked, dashboard extract wide open.
Skipping catalog sensitivity: people cannot choose a lower rung if cards do not say what is PII.
Write rights for debugging: SELECT would have been enough; DELETE was muscle memory.

Practice: one hour this week

Inventory access for one domain. List humans and service accounts with read on identified tables. Mark each: still needed? correct rung? expiry date? Pick five leftovers to revoke or time-box. Publish the access request template in the team channel. Offer a masked view if three requests this month asked for email “just in case.”

Later parts of this series will cover incidents, retention, and working with Legal/Security without panic. Access hygiene makes those days less dramatic. For broader skills, browse Learn and keep linking program docs for governance and MDM when golden records and policies are the real issue.

Quick recap

Clarify what “prod” means: OLTP, warehouse, BI, or write path.
Climb the least privilege ladder only as high as the decision requires.
Rewrite asks into needs; use the matrix of ask for vs avoid.
Steward frames, owner accepts sensitive risk, custodian implements, Security/Legal consult on PII and partners.
Time-box grants, prefer masked views, log exports, treat clean rooms as constrained serving, not free files.

Sources

OWASP, access control and least privilege principles: https://owasp.org/www-community/Access_Control and A01 Broken Access Control
NIST SP 800-53 Rev. 5 (access control and audit families): https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
NIST Privacy Framework (data processing permissions and risk): https://www.nist.gov/privacy-framework
NIST SP 800-122 (guide to protecting confidentiality of PII): https://csrc.nist.gov/publications/detail/sp/800-122/final
DAMA International, data security and stewardship context in DMBOK: https://www.dama.org/cpages/body-of-knowledge
CIS Controls (account management and access control hygiene, high-level): https://www.cisecurity.org/controls