Every Data Store Has an Owner. The Column Is Full of Distribution Lists.

Every row has a value and the decisions still stall

An owner register comes together quickly, because the field can be filled from what the platform already knows. A storage account carries a tag, a site collection has an owners group, a workspace records its creator. Every row gets a value, and a column with no blanks reads as finished work.

Then read the column. Some rows name a team alias that reaches nine people. Some name a distribution list built for a program that closed two years ago.

Routing works anyway. The finding generates, the notification lands, somebody acknowledges it. For a whole class of finding that is close to the entire job: an anonymous sharing link comes down as soon as the notice reaches somebody holding rights on the item itself or across the tenant. Whoever opens the alert first holds a login to the console, which is a different grant, so the route carries the finding one step further and it still closes.

The register holds until a finding needs a decision. A site collection retired in a migration turns out to hold an export of customer records. Somebody has to say delete it, or record a decision to keep it and who approved that. Send it to an alias and nine people read it, agree it belongs to someone, and move on. The row is still open at the next review, and the routing did its job on every pass.

Read the column row by row and the values fall into a few shapes.

• A team alias that reaches everyone on a rotation and obliges nobody on it
• A distribution list built for a program that finished, still delivering to whoever was on it
• A group a reorganization dissolved, kept alive in case something depends on it
• A named individual who left, on an account that stayed enabled for a service dependency
• The platform team, on every row where the estate's own signals point at whoever provisioned it

The custodian runs the system, the owner answers for what is in it

The platform team lands in the owner column for mechanical reasons. They provisioned the resource, their group holds the subscription, their service principal sits on the access control list. Every signal the platform can read points at them, so the register does too.

Microsoft Purview holds two contact roles against a catalog asset, an owner and an expert, set on the asset's contacts tab. Both fields start empty. What fills them is whoever ran the scan, working from the evidence the scan returned, and what a scan returns about a store is the container and the administrator who provisioned it. So the column fills completely, and the value in each row is a fact about the container.

The platform team's authority over the store is real. They rotate the keys, change retention on the container, remove a role assignment, and delete the whole thing within the hour when asked. That authority stops at the contents. The business process the data serves sits outside their view, and the business treats an approval from the process owner as the one that counted.

A data engineering team runs the lake. A finding says one table carries unmasked account numbers. Masking the column is an afternoon of work and they will do it on request. Whether masking breaks the reconciliation finance runs at month end is the question that decides the finding, and finance answers that one.

So the row needs two names. The owner decides, the custodian carries it out, and a finding that needs both stalls where either is missing.

• The custodian provisions the store, configures access, holds the keys and makes the change once it is agreed
• The owner knows what the data is for, which process stops without it, and what the business loses if it is exposed
• The owner accepts the risk, approves the deletion, signs the exception and answers for that afterward

The team that can delete the container is a different team from the one that can decide whether it should be deleted.

The cheap evidence points at the custodian

CWS has delivered three data security posture engagements, on Microsoft Purview and on Securiti. In each one the ownership column had to be rebuilt from evidence before routing produced anything the program could use.

That pattern has a cause. The evidence easiest to gather is custodial evidence: provisioning identity, resource tags, subscription, access control list. All of it is one query away, and all of it describes who runs the system.

Evidence about the contents costs more to assemble, and it is the evidence that produces an owner. Access telemetry separates the people who opened a file once from the team whose work runs through the store every week, and across much of an estate the first step is switching it on. Storage diagnostic logging and file share auditing ship in the off position, so the sequence starts with enabling them on the stores in scope and waiting for a window long enough to hold a monthly process. The classification results name the business process, and payroll records come from a process with a named leader.

Then the question gets asked in a form somebody can answer. Ask a governance forum who owns a set of storage accounts and the room goes quiet, because a claim creates an obligation and returns little. Name a person, attach the evidence that pointed at them, and ask them to accept or redirect. A redirect moves the row and costs the person almost nothing, which is why the named question gets an answer.

The signals are worth gathering in this order.

• The provisioning event and the identity that created the resource, which names the custodian
• Read and write telemetry over a window long enough to hold a monthly process, enabled first wherever it is switched off, which separates occasional readers from the team the data belongs to
• The classification results, which name the business process the data came from

Propose a name and attach the evidence behind it. Being wrong about somebody is what gets you the right answer.

The store that comes back unclaimed

Some stores reach the end of that process with the field still empty. An application was decommissioned and its storage kept running, or an acquisition arrived carrying file shares that predate everyone in the acquiring company. The nominations come back declined.

The two easy exits both cost you later. A blank row drops out of every report that filters on owner, so the store leaves the program while the data stays where it is. Assigning it to the platform team puts it back under a custodian whose authority stops at the contents.

Business function outlives the team that built the store. Payroll data belongs to whoever runs payroll now, and handing that person a file share they have never opened is a fair ask against the alternative. Where a live process claims the data, that process names the owner. Where none does, records management decides retain or dispose against the schedule.

The last route is disposal, and it works better than its reputation. Publish an intention to delete a named store on a named date, leave a notice period long enough for a monthly process to run once, keep a restorable copy, and wait. The restore path goes in first.

Four routes close an unclaimed row honestly.

• Route it to the business function the data belongs to, which outlives the team that created it
• Send it to records management where no live process claims it, and let the retention schedule decide
• Give an executive sponsor the unclaimed class as one line they answer for, so the gap has a name against it
• Publish a dated deletion notice with a restore window, and treat every objection as an ownership claim

The two easy exits from an unclaimed row, a blank field and the platform team, both leave the data exactly where it is.

The register starts drifting the day it is signed

An owner register is accurate on the day it is written. People leave. Two teams merge and the surviving manager inherits stores that appeared in no handover. A business unit is sold and its data stays in the tenant under a name that means nothing.

One check is mechanical and it runs on a schedule. Reconcile every owner value against the directory and flag anything that fails to resolve to an enabled individual account. A group, a shared mailbox, a disabled account and an empty field are the same defect, and a script finds all four.

The rest arrives through provisioning. New stores appear between scans, and each one carries whatever the request that created it asked for. Requiring a name at creation stops the backlog growing while the rest of the work draws it down.

Both platforms recorded the owner values the organization already held. What the organization held was a directory built for mail delivery and access control, and neither of those uses asks the value to be a person who can accept a risk.

The custodian and owner separation, the evidence-based reconstruction and the handling of unclaimed stores are CWS practice. They are set out at length so the reasoning can be argued with as readily as the conclusion.

Five checks keep the register true once it is.

• Every owner value resolves to an enabled individual account
• Every owner has confirmed in writing, with the date of that confirmation recorded
• Every store created since the last cycle has a name against it
• Every unclaimed store has a route recorded and a date for the next look
• The custodian is recorded separately, so a finding that needs both reaches both