Strip away the vendor branding and DataSecOps makes one testable claim: that data protection works better when it runs like engineering — small reviewed changes, automatic enforcement, receipts kept — than when it runs like paperwork. That claim was put into words on 4 August 2021 by Ben Herzberg, the chief scientist at Satori Cyber, and because he wrote it as a vendor, no standards body treats the name as official; the same discipline has long been called data security governance. A claim you can test is exactly the kind this site likes, so the rest of this piece takes the claim apart stage by stage and shows what each stage asks of a team. No jargon survives unexplained.
Claim one: DataSecOps rules live where code lives
Every organisation already has data rules. They sit in spreadsheets, memory and click-paths through a cloud console, which means nobody can diff them, test them or say who approved Tuesday’s change. The first stage of the argument is that a rule about masking a salary column should be written down the way software is: as a file, reviewed by the person who owns that data, merged through a pull request, and applied by a pipeline. Nothing here is exotic. It is the same mechanics your developers already run; it is simply pointed at tables instead of functions. And the pay-off repeats weekly: when someone proposes altering a rule, the change request shows the old version beside the new one, tests run against a staging warehouse before anything production-side moves, and the merge record answers the auditor’s “who signed this off?” in one command.
Claim two: protection happens at the smallest useful unit
The second stage concerns granularity. A whole-database password is a blunt object; the practice works at the row, the column, or even the individual query. A regional analyst sees only their region’s rows. A contractor sees the delivery address column but not the phone number beside it. A dashboard service account runs aggregate queries and can never select raw records. Evidence that this granularity is practical comes from the engines themselves — PostgreSQL has shipped row-level security since version 9.5 back in January 2016, and Apache Ranger has offered row filters and column masking since release 0.6. The mechanics are old and proven; what changed is the expectation that they should be configured systematically rather than ad hoc.
Claim three: the work forms a loop, and the loop has an order
Run the stages in sequence and you get the working cycle. Each stage feeds the next, and skipping one breaks the rest — a team that enforces rules over unclassified data spends its days guessing, and a team that never reviews grants slowly accumulates permanent exceptions:
- Find the data: sweep the estate and work out what sensitive material exists and where it lives, including copies and old snapshots.
- Label it: attach classifications that say what each column holds. Automated scanners do the first pass — Google’s DLP service and the Presidio library turn up in most stacks — yet neither is fully accurate, so people confirm the final IDENTIFIER and SENSITIVE decisions.
- Codify the rules: turn “contractors must not see salaries” into policy files with owners and review history.
- Apply them: enforcement happens at query time, so the protection travels with the table into every tool that reads it.
- Watch the exits: egress controls and DLP sit over downloads, bulk exports and cross-account shares, because data leaves through doors, not walls.
- Keep the receipts: read-access history shows who saw what, which is both your alarm system and your evidence for auditors.
- Prune: a scheduled review retires grants nobody exercised.
Claim four: DataSecOps access works like a pull request
The workflow stage is where engineering habits bite hardest. Somebody needs a table; instead of messaging an admin, they raise a request that states the table, the reason and an end date. The owner signs off as if merging a colleague’s branch. The pipeline then applies the grant, and — critically — the grant expires on its own. Requests that fit existing policy clear the same day; anything unusual needs a ticket, a named risk accepter and a mandatory end date. Every quarter someone reads the list and removes what has gone quiet. Compare that with the traditional alternative, where a contractor leaves in March and their grants are discovered by an auditor in November.
What the word does not cover
Evidence-led means marking the boundaries too, and the boundary here is wider than people assume. Pipeline flow belongs to DataOps. Security telemetry belongs to SecDataOps — a split the writers themselves admit is editorial. Lawful basis and subject-access requests belong to PrivacyOps. Identity lifecycle belongs to IAMOps, privileged and break-glass access to AccessOps, database engine tuning to DBOps, and cloud posture to CloudSecOps. What sits inside: finding and labelling data, rules applied the instant a query runs, plus masking, tokenisation, format-preserving encryption, pseudonymisation, key custody, exit control, controlled sharing and the audit trail. If a vendor demo spends its time on any out-of-scope item, you are watching a different product wearing this label.
The verdict on the claim
Does treating protection as engineering work actually pay? The mechanism is unglamorous — reviewed rules, expiring grants, watched exits, kept receipts — and that is precisely why it holds up: each part can be checked, and each part fails loudly. A skipped classification surfaces as rules aimed at the wrong columns. A lapsed review surfaces as grants to people who changed jobs a season ago. Nothing in the loop relies on anyone remembering to be diligent at the right moment. A team that wants the pipeline background first can read the complete DataOps guide to training and architecture; the security side of personal key material gets an accessible treatment in our piece on wallets, blockchain and security basics; and the wider delivery context sits in this guide to enterprise software delivery governance. For the term itself — who defined it, what counts in and out — the Ops Atlas keeps a DataSecOps reference page worth bookmarking. The summary in one line: label the data, codify who sees what, expire the exceptions, and keep evidence that you did.
- A rule you cannot diff is a rumour: policy belongs in repositories with named owners.
- Protect the row, column or query — the smallest unit that still lets people work.
- Scanners propose, humans confirm: no classifier is fully accurate.
- Grants expire by default; reviews delete what went unused.
- Boundaries matter: pipelines, telemetry, lawful basis and identities are neighbouring disciplines, not this one.
