Most protection failures begin as a favour. Somebody needs a table for a festival campaign, an analyst says yes over chat, a file lands in three inboxes, and six months later nobody can say who still holds what. The remedy is procedural, not technological: a DataSecOps programme treats every grant of access as a formal request with a stated purpose and a date on which it dies. This guide walks through building that request flow in seven steps, in the order they should be built, with the pass condition for each. The tone is deliberately procedural — this is a checklist you can implement in an afternoon per step, not an essay about why access matters.
Why DataSecOps begins with the request, not the rule
The instinct in most small teams is to write rules first and hope people ask nicely. Invert it. The request is where intent gets recorded, where an owner takes responsibility, and where an end date gets attached; rules merely automate what the request already decided. A request that names its dataset, purpose and duration can be approved in minutes, applied by a pipeline, and cancelled exactly on schedule — no memory required from anyone involved. The wider loop this flow slots into, from initial discovery through the final review, is set out with its sources in the Atlas DataSecOps page. Build the seven steps below and the quiet virtues follow: nothing is granted without a name attached to it, nothing lasts longer than its stated need, and every cancellation is automatic rather than heroic.
Step 1: Name the dataset and a single line of purpose
Every request starts by identifying one dataset — a table, a view, an export — and one sentence explaining what the work needs from it. Force the sentence to be concrete: “subscriber emails for the Diwali campaign reminder” passes; “marketing stuff” does not. The one-line discipline does three jobs at once: it narrows the grant to what the sentence covers, it gives the approver something checkable, and it gives a future auditor the context that a bare permission record never carries. Teams that skip this step end up approving bundles, and bundles are how over-access begins.
Step 2: Attach a duration before anything else
Duration is the field that changes everything downstream, so collect it early. A request without a duration defaults, silently, to forever — which is precisely the default this whole exercise exists to abolish. Publish default durations by request type: a campaign task might get thirty days, a seasonal report sixty, an ongoing dashboard role a quarter with renewal required. The number goes into the request itself, so the end date is arithmetic rather than a negotiation somebody must remember to reopen later.
Step 3: Route the ask through a single owner
Access without a named approver is access without accountability. Each dataset gets exactly one owner — a person, never a department — and every request lands in their queue. The mechanic that works is borrowed from software teams: the request arrives as a pull request against the rules file, and approval means merging it. Owners like this format because the decision is reviewable, reversible, and leaves a comment thread where objections get written down instead of muttered. Departments resist the “one person” part until they see the alternative, which is a mailing list where everybody approved and nobody decided.
Step 4: Let the DataSecOps pipeline apply what was approved
Once merged, the request should be carried out by machinery, not by whoever is nearest an admin console. Continuous integration picks up the changed rules file, runs checks — does the referenced table exist, does the stated policy compile, is the duration within published defaults — and then applies the grant. This is policy as code doing its quiet work, and its benefit is the audit trail: the applied state of the world is a file in version control with a history of who changed it and when. Console-clicked changes, by contrast, vanish into a vendor interface with no memory, which is why hand-typed policies sit on every anti-pattern list worth reading.
Step 5: Handle exceptions as a separate class
Some requests will not fit the defaults — an urgent audit pulls three months of records, a partner needs a longer window. Handle them through a deliberately heavier door: a logged ticket, a risk sign-off from somebody senior enough to carry it, and an expiry date that cannot extend by verbal agreement. Standard requests should still clear within the same working day; the process is meant to be fast for the normal case and slow only where the risk is real. If exceptions become the majority, the defaults are wrong — widen the standard path rather than letting the exception path swallow the workflow.
Step 6: Calendar the quarterly review
Expiry handles the predictable endings; review catches everything else. Once a quarter, the owner walks their datasets and answers two questions per grant: is this still serving the purpose written in its request, and did anyone actually use it in the last ninety days? Grants that fail either question get revoked on the spot. A review that revokes nothing is not evidence of health; it is evidence the walk never happened. Put the review on the shared calendar as a recurring event with the grant report attached, so the meeting starts with facts instead of recollections.
Step 7: Keep the reading of history honest
The flow above generates evidence, so plan for its limits. On Snowflake, the query history is kept for a year at most, lags the present by as much as three hours, and never records attempts that failed; in PostgreSQL’s world, pgAudit cannot reliably capture what a superuser does. Practical consequences follow: export the history on a schedule rather than trusting the platform to hold it, and pair database evidence with application logs so the gaps in one are covered by the other. An evidence plan that ignores retention limits produces confident answers right up until it does not.
Running the flow on a real calendar
Assembled, the seven steps take a small team roughly two weeks to stand up and less than an hour a week to operate. Start with one dataset — the busiest one — and run a full cycle: request, approval, expiry, review. The first cycle surfaces every weakness in the defaults while the stakes are low, which is the cheapest tuition available. Teams in other industries run comparable planning rhythms; a visitor planning a first trip works from structured steps in much the same way, whether following a plan for a first visit to Bhopal, choosing among the best first-time experiences the city offers, or working through a full guide to attractions, heritage and day trips — sequence, duration and review, applied to days instead of grants. The request flow is the same discipline with a login screen attached, and the first audit that asks who still holds access will repay the entire build.
The seven steps, numbered for the fridge door:
- Name one dataset and a single-line purpose.
- Set the duration before anything else moves.
- Route the ask through one named owner.
- Let the pipeline apply whatever got merged.
- Handle exceptions through the heavier door.
- Calendar the quarterly walk; revoke there.
- Export the history on a schedule; respect its edges.
