You do not need a programme, a vendor workshop or a six-month plan to start looking after your data properly. You need an audit you can actually run — short, honest and repeatable. This one takes ninety days in three sittings, uses tools you almost certainly already own, and ends with a scorecard your whole team can read. Call it a DataSecOps audit if you like the label; the checklist works regardless of what the slide deck calls it. Everything below has been stripped to what a small team can finish between other work.

Before You Audit: Two Facts That Set Expectations

Fact one: the word itself is young. Ben Herzberg, then chief scientist at Satori Cyber, wrote the definition on 4 August 2021 — an agile method of keeping data safe while data and its users keep moving. Standards bodies never signed it; the long-standing name for the practice is data security governance. And Satori Cyber has since joined Commvault — that deal was announced on 28 August 2025, carrying a preliminary price of roughly USD 28.3 million. Fact two: the working unit is small. You are not securing “the company’s data”; you are deciding, row by row, column by column and query by query, who may see what at the moment they ask. The full cycle behind that decision — spot, tag, encode, enforce, watch the exits, read the history, review — is spelled out in the Ops Atlas entry on DataSecOps, and our own glossary of essential DevOps terms covers the neighbouring vocabulary if any of that feels new.

The DataSecOps Checklist for the First 30 Days

The first month is about seeing clearly. Four items, all finishable:

• Write a one-page classification standard. Three or four levels, plain words, examples for each. If a table cannot be graded in under a minute, the standard is too clever.
• Run discovery once across every schema you own. Machines do the sweep; people confirm the IDENTIFIER and SENSITIVE tags, because scanners from Google, Presidio or anyone else are never completely right.
• Pick your top fifty tables and grade only those. Coverage of what matters beats a stalled census of everything.
• Turn on MFA for every human login, and note which service accounts still use static passwords. Providers are phasing out plain password logins during 2026, so this item is already moving under your feet whether you act or not.

Watch the room while the grading happens. If two people cannot agree whether a column is sensitive, that argument is the audit working — write the ruling down and move on. Rulings, unlike opinions, can be reused, and by week four you will have a small case law of your own.

Days 31 to 60: Wiring the DataSecOps Workflow

Month two turns sight into structure:

• Attach tag-driven policies on the tier-1 tables — masking where values must hide, row filters where regions or roles divide.
• Stand up the request flow: a petition that names dataset, purpose and duration; an owner who approves; CI that applies the grant with an expiry attached. Routine asks should clear the same day, and anything strange gets a ticket plus a recorded risk sign-off.
• Install a drift check that compares intended policy with actual state and complains out loud when they disagree. Copies and certain overwrite-style loads are known to shed tags, so drift is a matter of when, not whether.

Keep the policies in version control from day one of this phase. A rule in a console has no author, no history and no rollback; the same rule in a repository has all three.

Days 61 to 90: Proving It Works

Month three is where audits usually go soft, so these three items are deliberately blunt:

• Hold the first review and actually revoke. Walk the grant list, ask what justifies each access today, and cancel the orphans. A review whose answer is always keep-everything is paperwork wearing a control’s clothes.
• Rebuild one non-production environment from masked sources instead of raw clones, and retire the habit of copying customer tables into staging.
• Publish the scorecard. Four figures carry it: sensitive columns covered, plain-text read share, principals holding more than their role needs, and grants untouched for ninety days.

Scoring the Audit Without Fooling Yourself

The Atlas ladder gives the scoring rules: Ad hoc, Classified, Enforced, Evidenced, Adaptive. Realistic exits keep it honest — reaching half of tier-1 coverage is the level-two bar, while level three needs ninety-percent-plus coverage and not a single console-only policy left anywhere. The top rung, Adaptive, has the strictest definition of all: a newly created sensitive table is protected before its first grant, every single time. If your scorecard says 87.5% coverage but seventeen policies live only in a console, you know exactly which fix next quarter buys the most progress. When the conversation drifts to formal frameworks, anchor it with named documents rather than vibes: NIST SP 800-53 Revision 5, refreshed on 27 August 2025, CSF 2.0 for programme structure, and SP 800-207 together with the zero-trust maturity model CISA maintains at version 2.0 whenever architecture questions surface. An audit that cites real clauses is much harder to argue with than one that cites adjectives. Teams wanting the risk-management frame around this can borrow heavily from our piece on DevOps and risk management, which covers the same owner-plus-deadline logic for change and release risk.

Make the Audit a Habit, Not an Event

The ninety-day list above is round one, not the finish. Rerun it quarterly: the sweep gets faster each time because tags persist, the review shrinks because expired grants leave automatically, and the scorecard turns into a one-slide fixture of the ops review. The cultural part matters more than the tooling — protection sticks when the people who own tables also own the decision about who reads them, which is the same ownership principle our article on DevOps and culture change argues for in delivery teams. Run the audit twice and you will stop calling it an audit at all; it will simply be how the warehouse works. The first pass is the expensive one because every tag is new; the second costs an afternoon. By the third, the sweep, the confirm and the revoke fit into a single sprint, and the scorecard arrives before anyone asks for it. And if a colleague asks where to begin, send them the checklist, not the vocabulary — the ladder can wait until month four.