The DSPM Findings Land in a Queue No Business Unit Reads

The queue is correct and the person who could act works somewhere else

The deployment did what it was scoped to do. Connectors are attached, classification runs on a schedule, and findings appear with a location, a severity and an owner against each one. They appear in the console, which is where a platform is built to put them.

The owner on the row is a director in finance. Her week runs through an inbox, a service management queue her team works down every morning, and a planning board her manager reads on Thursdays. The console is a fourth place, holding work that arrived without a conversation.

So the finding sits. Security ends up performing the remediation itself, which holds for a few dozen findings and puts an engineer in the position of deciding whether a finance report should be deleted. Or an analyst starts sending emails, and throughput becomes the number of replies one person can chase in a week.

The finding arrived. It arrived in a place that sits outside the recipient's working week, which is a delivery question with a delivery answer. Read as evidence that the business has no appetite for data risk work, it sends you off to build something else.

A second queue is a second habit, and somebody has to agree to build one

The reflex is to treat this as adoption. Send the credentials again, run a training session, build a filtered view per business unit. That reaches the people who were going to engage anyway.

A queue gets worked because something makes it get worked. It carries a due date that appears in a report somebody senior reads. It sits inside the tool the team's morning standup runs from. Its state is visible to a second person, so an item that stops moving gets noticed. Destinations compete for the same hour, and the one carrying all three wins it.

Email is the fallback and it fails in its own way. A message asks for a favor, and a favor gets granted when the reader has a free hour. Its state lives in one person's inbox, where a second person can ask about it and that is all.

So the destination is chosen per business unit. Finance lives in a service management queue. Engineering lives in the tracker where its sprints are planned. Microsoft Purview and Securiti both deliver findings wherever they are configured to deliver them, and a console is the sensible default. Which queue a business unit actually works is a fact about that business unit, and choosing per unit is work your organization does once.

A finding placed in a system the team already works inherits five things from that system.

• A position in a queue somebody sorts, on terms the team already accepts
• A due date that shows up in the report the recipient's manager reads
• A state a second person can see, so a stalled item gets noticed
• An assignment history, so a handoff leaves a record
• A closure that survives the person who closed it

Two weeks after the email, nobody can say whether the finding was declined, missed, or handled by somebody who never wrote back.

The finding arrives in the platform's vocabulary

Routing gets the finding in front of somebody. The wording decides whether they can do anything with it. A finding describes an object: a storage account with anonymous access enabled, a site collection holding records that match a payment card rule, a severity band.

Every word of that is correct, and a description built to hold across every customer is the only kind a platform can write. The local facts sit alongside it: that this company calls the file the monthly billing extract, that the folder it lands in was created by somebody who left in the spring, that the process behind it runs on the last working day of the month. Putting those into the finding is the operator's work.

Without them, the director does the translation herself before she can act. She has to work out which of these files belong to her team, whether her team put them there, and what stops working if they go. That is real work arriving in a message she did not ask for, and it gets set aside for the work that came with a due date.

The translated finding says the same thing in the reader's language, and it is shorter than the original.

• The business process that produced the content, named the way that business unit names it
• The location in a form the recipient recognizes, with the resource identifier alongside it
• Who can reach it today, taken from the platform's effective-access reporting where it computes one, or worked out from group membership by hand, with the method stated either way
• What remains true if nothing changes, stated once and without escalation language
• The one action being asked for, and the date it is wanted by

Translation is a paragraph of work for the sender and the difference between a decision and a deferral for the reader.

The action has to be completable from where the reader already is

If closing the finding requires opening the console, locating the object and changing a setting, the request has circled back to what failed at the start.

A finding reduces to a small set of asks: confirm the sharing is sanctioned, approve removal, name a different owner, ask for help deciding. Each of those is a reply, and a reply fits in a ticket field or a form.

The decline path is the one that keeps the loop honest, and it is the easiest of the four to leave out of a field mapping. A recipient with no way to say no says nothing, and silence and refusal look identical in a report. Give the decline an approver, a reason and an expiry, and it lands in the exception register with a date to come back on.

Splitting the decision from the execution makes the ask small enough to answer. The finance director approves the removal of a folder. The team that runs the storage removes it. Asking one person to do both requires an access level that belongs to the platform team.

Four replies close a finding honestly, and all four fit in a ticket.

• This is sanctioned, here is the process behind it, and here is who approved it
• Remove it, and the platform team executes under this approval
• This belongs to another team, and here is the name
• I cannot decide this yet, and here is what I am missing

Build the routing before the second scan runs

CWS has delivered three data security posture engagements on Microsoft Purview and on Securiti. Findings were produced accurately in all three and delivered exactly where they were pointed. The variable that moved closure was whether the destination was somewhere the recipient already opened.

The routing layer is small. Three parts: a map from data store to business unit, a destination for each unit, and a field mapping that turns a finding into an item that destination will accept. Building it before the second scan runs costs a fraction of what it costs to work the first cycle twice.

Owner assignment is a separate exercise, and where it is already running, routing adds one question for the same person: which system does your team work from, which queue inside it, and who administers it. Ask in the message that confirms they own the store.

The return path is the piece to specify at the same time. Closure happens in the ticket, and unless that state comes back, the two systems hold different numbers within a cycle. A status write back keeps the reported number defensible, and a manual one on a fixed cadence is enough to start.

Destination selection per business unit, the translation a finding needs before a business unit can act on it, and the decline path are CWS recommendations. All three sit outside what vendor documentation sets out to cover.

Treat this as a routing problem and the next thing built is an integration. Treat it as an engagement problem and the next thing built is another training session. Four things settle before anybody writes the integration.

• The destination system and queue for each business unit, named by the owner and confirmed by whoever administers it
• The field mapping from finding to item, including the fields that stay inside the security team
• The write back that returns closure state to the platform, and how often it runs
• The severity at which a finding also gets a phone call, and the person who makes it

A finding that lands in the queue a team already works down every morning closes on the cadence the plan assumed.