{"id":6000,"date":"2026-11-01T18:20:00","date_gmt":"2026-11-01T18:20:00","guid":{"rendered":"https:\/\/www.cmsgalaxy.com\/blog\/?p=6000"},"modified":"2026-11-01T18:20:00","modified_gmt":"2026-11-01T18:20:00","slug":"datasecops-agency-snowflake-case","status":"publish","type":"post","link":"https:\/\/www.cmsgalaxy.com\/blog\/datasecops-agency-snowflake-case\/","title":{"rendered":"A DataSecOps Case Study: One Agency’s Snowflake Reset"},"content":{"rendered":"

Willowmere Studio builds dashboards for clinic groups \u2014 twelve people, one warehouse, and a client list that trusts them with appointment records. On a Tuesday morning in March, their lead engineer found a query log entry that made her stomach drop: a service account had exported a 40-gigabyte slice of the client data platform overnight. It turned out to be the client’s own nightly job, running with credentials nobody had reviewed since onboarding. But the scare did its work. Here is how one twelve-person agency rebuilt its data protection in six weeks using DataSecOps<\/strong> \u2014 the discipline Satori Cyber’s chief scientist Ben Herzberg named in August 2021, which embeds security into the everyday churn of data and the people touching it. The name is vendor shorthand rather than a standard, but the six weeks changed how Willowmere works, and the specific walls they hit inside one warehouse will look familiar to anyone running a similar stack.<\/p>\n

Week one: the inventory nobody wanted to do<\/h2>\n

First came the uncomfortable spreadsheet. Every table, every copy, every forgotten sandbox. The agency found eleven locations holding client-identifying fields, of which four were clones nobody remembered creating. An old staging snapshot from a 2024 migration sat in a schema named tmp_dont_delete<\/em> \u2014 it did get deleted, but only after someone confirmed no job referenced it. The lesson the team repeats to clients now: you cannot protect tables you cannot name. Discovery ran on the warehouse’s own object listings plus a scanner pass, and the scanner’s output needed a human second look, because automated classifiers are never fully accurate \u2014 the machine flagged a free-text notes column correctly but missed that an ID field embedded birth dates in its digits. Two people spent a full day confirming tags by hand, and that day remains the cheapest insurance the agency ever bought.<\/p>\n

Week two: the paywall surprise<\/h2>\n

Then came the first hard wall. Masking policies and row access controls in Snowflake require the Enterprise edition or higher, and Willowmere was running a tier two steps below. The upgrade conversation with the founders was short once framed as a client-retention issue \u2014 the alternative was telling clinic groups their appointment data sat in an unmasked table readable by every developer account. The same week, the team retired password-only sign-ins for human users and turned on multifactor authentication, ahead of the phased deadline that runs through 2026. That single Tuesday fix would have blunted the credential-stolen campaign pattern of 2024 \u2014 the one tracked as UNC5537, where infostealer-exposed passwords without MFA let attackers walk into roughly 165 tenant organisations and pull data out through COPY INTO exports while the platform itself stayed clean.<\/p>\n

Weeks three and four: DataSecOps policies misbehave<\/h2>\n

Writing the first masking policy taught the team the engine’s personality. The rule that ties masking policies to tags allows only one policy of each data type to hang on any given tag, so planning the tag taxonomy came first \u2014 a half-hour of whiteboarding that saved a week of rework. Then a subtler trap: once a policy attaches to a tag, you cannot swap in a different policy object; the only move is modifying the policy body with a SET BODY statement. Their first attempt to “just replace it” failed with a permissions error that cost an afternoon of confusion. The team also learned what row policies do not do: they filter reads, but they do not stop inserts, so a poorly scoped writer could still stuff rows into a table it could not see. Writes got their own controls.<\/p>\n

Week five: the history that lags<\/h2>\n

The access-review habit hit the second wall: latency. The warehouse’s ACCESS_HISTORY view, the team found, keeps 365 days of read history \u2014 genuinely useful \u2014 but with up to a three-hour lag, and failed queries do not appear at all. An investigator chasing an active incident therefore sees the recent past slightly out of focus, like watching a replay with a delay. Willowmere’s compromise: weekly reviews of the history for pattern-watching, and a runbook note that anything fresher than three hours must come from live query telemetry, not the history view. Their review now has teeth, too \u2014 grants expire on dates, and the quarterly walk revokes what went quiet, not merely re-approves it.<\/p>\n

Week six: writing it down<\/h2>\n

The rebuild ended not with tooling but with a document: the classification standard (what counts as IDENTIFIER, who confirms scanner output), the request workflow (a request names the table, the reason, the end date; the client’s data owner approves it like a pull request; the pipeline applies it), and the review calendar. The founders approved one budget line \u2014 the tier upgrade \u2014 and nothing else. Everything else was habit. For teams starting from a similar scare, the sequencing matters: inventory first, tier and MFA second, policies third, history fourth, paperwork last.<\/p>\n

What the story teaches about DataSecOps<\/h2>\n

A scare is a terrible way to learn governance but an excellent motivator, and Willowmere’s six weeks compressed what the DataSecOps loop describes on paper: discover, classify, codify, enforce, watch exits, read history, prune. The order mattered more than the tools \u2014 every week’s work depended on the previous week’s artefact. The full scope and vocabulary of the approach \u2014 including how its boundaries meet neighbouring practices \u2014 is documented in the Ops Atlas DataSecOps entry<\/a>. For the pipeline discipline underneath warehouse work, our overview of DataOps courses, certifications and professional services<\/a> maps the training options; the governance habit that keeps delivery itself accountable is covered in this piece on governing the complete software delivery lifecycle<\/a>; and the perimeter side of the same story \u2014 what your own digital footprint leaks \u2014 sits in our guide to URL management and footprint protection<\/a>.<\/p>\n