A birth chart is a strangely intimate thing to hand to a database. It bundles a person’s full name with the exact date, minute and town of their birth — the few facts a stranger could use to pick one individual out of a whole city. If you run an astrology or stargazing app, you hold thousands of those bundles, and the habits that protect them have lately collected under a name worth knowing: DataSecOps. Ben Herzberg, chief scientist at Satori Cyber, coined the label on 4 August 2021 for an agile, security-embedded way of working with data and the people who use it, both of which change constantly. He said so as a vendor, not a lawmaker — no standards body has adopted the term, and the practice most firms already run goes by the older name data security governance. Whatever you call it, the steps below turn it into a routine a small app team can actually keep.
Step 1: List every fact your charts actually store
Start with discovery, because nobody protects a table they have forgotten. Walk your schema and write down where names, birth timestamps and locations sit: the profiles table, the transit-notification queue, the CSV a founder exported in 2023 and left in a bucket. Include the copies nobody remembers — a chart rebuild, a test snapshot, the analytics clone that quietly holds everything the production database does. A screenshot on the wall of an observatory control room gets the same treatment as any instrument: you check it before you trust it, and data is no different.
Step 2: Classify With DataSecOps Tags You Only Half-Trust
Automated classifiers — Google’s Cloud DLP and the open-source Presidio are the usual suspects — will find most identifiers for you. The catch is that they never reach one hundred percent accuracy, so a human still confirms which columns deserve the tags IDENTIFIER and SENSITIVE. Treat the scanner like a telescope’s auto-guider: it keeps the field steady, but the astronomer decides what is actually in the frame. For a birth-chart app this step is unusually easy to reason about, because a hospital-style list already exists. HIPAA’s Safe Harbor method counts eighteen identifiers, and birth date is on it: places with twenty thousand or fewer residents must have the ZIP code zeroed out, and ages above eighty-nine get folded into one bucket. Your users’ natal data sits in exactly that territory, so classify it that way from day one.
Step 3: Write the rules as code, not console clicks
A rule that lives only in a cloud console is a rule nobody can review, test or restore. Policy-as-code means the masking rule for birth timestamps lives in a repository, goes through the same pull-request review as app code, and gets applied by your pipeline. When a product manager asks who approved hiding a mother’s maiden name from the analytics team, the answer is a commit, with a reviewer attached and a date. That paper trail is the quiet difference between a governance programme and a set of good intentions.
Step 4: Enforce at the row, column and query
Decide what the smallest protected unit is, then enforce there. A horoscope writer needs birth times but not names; a support agent needs one user’s record, not the whole table; the daily-aggregation job needs aggregates and nothing else. Row filters, column masking and query-time checks deliver exactly those slices, so each person sees the narrowest view that lets them work. Setting the unit of control at the row, column or query level is what makes the narrowness practical — you are not choosing between full access and no access, you are carving a precise window.
Step 5: Guard the exits before the front door
Data rarely leaks by walking out the front door; it leaves through exports. Egress controls sit on the ways information leaves: downloads, COPY-style bulk reads, shares with other accounts, connections from analytics tools. Put limits on volume, alert on unusual destinations, and require a second pair of eyes for anything bulk. A chart PDF is harmless; a million-row dump of natal data is a headline, and the difference between them is usually one unmonitored export path.
Step 6: Read the access history you are already paying for
Most warehouses record who read what. That log answers the questions an incident raises hours later: which principal touched the affected table, when, and from where. Make a habit of reading it weekly rather than only after something frightens you. Two minutes on Friday skimming the week’s reads against your sensitive tables finds the over-curious intern long before they become a story. The history also feeds the review step, because you cannot judge whether a grant is needed until you know whether anyone used it.
Step 7: DataSecOps Review — Every Grant Gets a Birthday
Permanent access is how small leaks become large ones. The pattern borrowed from software delivery is the pull request: an access request spells out which dataset is wanted, why it is needed and for how long, the data owner approves it, continuous integration applies the rule, and the grant carries an expiry date. Every quarter, someone walks the list and revokes what no longer has a reason to exist. A transit-alert subscription lapses when the comet is gone; access should lapse the same way.
One belief to retire this week
Teams often reassure themselves that a hashed email address is anonymous, so it can flow freely into analytics. A deterministic hash of an email is joinable across every dataset that used the same hash, and for common addresses it is guessable outright. What you have made is a pseudonym, not anonymity — the row still tracks one person. Keep hashed identifiers inside the same controls as the originals, and the marketing dashboard stops being the weak link in an otherwise tidy setup.
Keeping the routine alive
Those seven steps compress into a loop worth memorising: discover, classify, write policy as code, enforce, control egress, read the history, review and revoke. Run it once as a project, then again each quarter as a habit. For the label’s own vocabulary and history, most teams begin at the Ops Atlas page devoted to DataSecOps. Two of our earlier pieces pair well with it: our look at securing software architecture with DevSecOps discipline covers the code side of the same mindset, and this guide to data engineering and automated infrastructure explains where the pipelines under your tables come from, and our piece on engineering digital resilience through cloud infrastructure rounds out the infrastructure view.
- Discover: name every table that holds birth names, dates or places.
- Classify: let scanners propose tags, then confirm the IDENTIFIER and SENSITIVE ones by hand.
- Policy-as-code: masking rules reviewed like code, with authors and dates.
- Enforce: row filters, column masks and query-time checks for the smallest slice that works.
- Egress: watch exports, bulk reads and shares as closely as logins.
- History: skim access logs weekly; investigate reads against natal data.
- Review: expiry dates on grants, a quarterly walk, and revocations that actually happen.