The meeting request that introduced Priya’s team to DataSecOps was one line long and arrived on a Tuesday: bring the list of every account able to read the model-training tables. Priya Nair, who runs platform engineering at Harbourlight — a fictional AIOps vendor this case study follows — expected nine names, because her team has nine people. The inventory query returned one hundred and forty-two principals. Most were service accounts left behind by a monitoring migration nobody had pruned in two years; a few belonged to engineers who had left the company earlier than the migration did. The distance between nine and one hundred and forty-two is the reason this story is worth telling, because Harbourlight’s situation is ordinary. Alert models are only as trustworthy as the data behind them, and the crowd holding access to that data is rarely the crowd you would name from memory.

The requester was Tomás Rey, the security reviewer assigned to Harbourlight’s upcoming customer audits. He did not want the list as a formality. He wanted to know why each of those one hundred and forty-two accounts needed what it had, when it had last been used, and who would notice if it vanished. His questions were three; Priya’s documentation for answering them was zero. The models in question — the ones that classify and suppress noisy alerts for customers — trained on live telemetry: event streams, host metadata, and the occasional on-call note where an exhausted engineer had pasted a credential into a free-text field and gone to bed.

Where the team first met DataSecOps

Priya went looking for a name for the work she now owed Tomás, and found one that fit. The label was proposed by Ben Herzberg, chief scientist at Satori Cyber, in a definition published on 4 August 2021 that called for an agile, security-embedded way of handling data and users while both keep changing. It is honest to say what the term is and is not: a vendor-coined label rather than a standard, with no standards body behind it — the practice most organisations already run under the name data security governance. A fuller treatment, including the scope lines summarised below, sits in the Ops Atlas entry on DataSecOps. What drew Priya in was the stated unit of control. Not the database, not the cluster: the row, the column, the individual query. For a team whose product is judgement about other people’s alerts, that granularity matched the problem exactly.

A loop instead of a project

The reference describes a circle, not a checklist with an end, and Harbourlight walked the circle once across a quarter:

• Discover — scan every store feeding the training pipeline, including the ones everybody had forgotten.
• Classify — tag what the scan found, then let people correct the tags.
• Policy-as-code — write row, column and cell rules in files that version control can argue with.
• Enforce — apply those rules at query time, so the check happens where data actually leaves.
• Egress control — watch what tries to exit, and block exports nobody requested.
• Read access history — keep evidence of who looked at what, and when.
• Review and revoke — put grants on trial on a schedule, not after an incident forces one.

Classification is where the team learned humility. Automated scanners — Google’s detector and the widely used Presidio library are the usual examples — never reach full accuracy, so humans must confirm the IDENTIFIER and SENSITIVE tags before any rule leans on them. Ines Okafor, the data lead, spent two working days confirming tags across the fifty tables the models touch most. She found a column called customer_ref that was actually free-text, and a hostname field that sometimes carried an engineer’s laptop name, which mapped cleanly back to a person. No scanner would have settled either call.

Grants that arrive with expiry dates

The structural fix replaced standing access with requests. Each request spells out the table involved, why it is needed, and the date on which access should end. The data owner approves it the way engineers approve a pull request; the CI pipeline tests and applies the resulting grant; the grant carries an expiry. Standard requests are meant to clear the same day. Exceptions need a ticket, a risk sign-off, and an expiry of their own. Priya’s team retired the one hundred and forty-two standing principals and reissued eleven dated ones — nine humans and two pipelines, each able to show a purpose and a death date.

Tomás had a precedent ready when Priya asked why the effort was urgent. The 2024 campaign against customers of a well-known cloud warehouse began with credentials, not exploits: infostealer malware had swept those logins up long beforehand, and in four hit accounts out of every five — the reference’s figure is 79.7 percent — the same machines had already met such malware. MFA was switched off. Some passwords had not been touched in as much as four years. In the end roughly 165 organisations filed notifications, while the warehouse itself never fell: records left through export commands any analyst runs daily. Standing access without expiry is exactly the surface such campaigns feed on, which is why reviewers like Tomás keep asking.

What DataSecOps changed by review day

Harbourlight’s quarterly scorecard borrowed its four ratios from the worked example in the reference material, so the figures below are that illustration, not Harbourlight’s private numbers. Protected columns stood at 1,085 out of 1,240, or 87.5 percent. The share of reads landing on plain-text copies was 17.1 percent. Principals holding more access than their role justified came to 212 out of 940, or 22.6 percent. Dormant grants — unused for ninety days — were 310 of 1,900, or 16.3 percent. In the template, each ratio carries a named owner and a deadline, which is what turned a report into a plan.

One caveat earned its own slide. Read-history evidence in the platform they run — Snowflake’s ACCESS_HISTORY view — holds 365 days, runs up to three hours behind, and omits failed queries. Good enough to see who reads a table; not the instrument for reconstructing an incident minute by minute.

What the reviewer signed

By the next audit, Tomás signed off on nine people and eleven dated service grants, a classification file with human sign-off recorded beside scanner output, and a review meeting that had actually revoked things. The habits mattered more than the tooling, and the team’s existing reading helped. Their telemetry collection follows a practical guide to AI for multi-cloud monitoring, their models lean on machine learning applied to alert management, and the reason a classification pass was affordable at all is that smart event-noise reduction had already shrunk the number of tables worth classifying. Security work got cheaper the moment the data work got smaller. That is the quiet lesson of the quarter: the loop is not a tax on an AIOps roadmap — run well, it is how the roadmap survives its next reviewer.