An MSSP delivers detections as Sigma but your team owns the SIEM. Who owns the field mapping?

### Why the boundary is the problem Split responsibility across an organisational line is what makes portable detections fail quietly. A provider authors in Sigma because it is the only artefact that survives being handed to a customer running a platform the provider does not control. The customer runs the SIEM because it holds their data. The mapping between the two - which of the customer's columns each taxonomy field means, and which of the customer's hosts populate them - belongs to neither party's natural scope, so by default it belongs to nobody. The asymmetry is worth stating plainly, because it is the answer to "why can't they just test it": - The **author** has the detection intent, knows what benign activity looks like for that technique, and has no access to the customer's data or agent coverage. - The **customer** has the data and the sensor estate, and does not know what the rule was trying to catch or which field mattered most. Give either one the validation task alone and you get a plausible answer that nobody can defend. ### Three ownership models, and what each costs **Provider owns the pipeline.** They maintain the mapping to your schema. Cleanest for you, but it obliges you to notify them of every schema or agent change, and it means an external party's artefact silently decides what your queries read. It only works if change notification is a contractual event rather than a courtesy. **Customer owns the pipeline.** You keep control of your schema and can fix one mapping for every rule at once. The cost is that you must be told what each rule assumes, and you inherit the work of resolving fields you have never heard of. **Split, with a validation artefact.** The provider ships the rule plus a way to exercise it; you own the pipeline and run the exercise. This is usually the honest answer, because it puts each obligation where the knowledge is and produces evidence both sides can read. ### Define what "deployed" means, in writing The word does the most damage. "We deployed 214 detections this quarter" is compatible with 214 valid, permanently empty queries. Escalate the standard until it means something: 1. **Converted** - the backend expressed the rule, and you know which clauses, if any, it could not. 2. **Mapped** - every taxonomy field the rule uses resolves to a real column in a table you actually collect from the hosts in scope. 3. **Validated** - the rule was observed firing on a deliberately executed instance of the behaviour it describes. Only the third produces evidence. And note what it is *not*: replaying a captured input through the rule proves the query still parses your stored records; executing the behaviour proves the whole chain from sensor to alert is intact. In a co-managed estate the second is what you need, because the parts most likely to be broken - collection, parsing, mapping - sit between the behaviour and the record. ### Contract the reporting in the other direction The artefact that changes the conversation is an **unmapped-field report** produced on every conversion run: the taxonomy fields the pipeline could not resolve, and the rules affected. A conversion exit code tells you the query compiled. This report tells you which rules compiled into something that can never match - the honest inventory of where the library is blind. Reviewing it jointly is a five-minute meeting that replaces a year of assumption. The second contractual trigger is estate change. An agent swap, a schema migration, a new table, a parser change: each is a mapping event that can empty dozens of queries at once with no error anywhere. If those changes do not fire a re-conversion, a report review and a re-validation pass, the library rots at the exact moment you are least likely to look. ### The strategy question underneath How much of your detection library should be portable at all? For a shop that will only ever run one SIEM, authoring your own bespoke logic in Sigma is an abstraction tax: you lose expressiveness the backend already has, you accept the conversion risks in this whole discussion, and you may never collect the portability benefit. What always pays is *consumption* - taking a published rule the day it appears, and keeping an exit if you change platform. The common settlement is native for bespoke logic, portable for imported behaviour, and a pipeline good enough that imported rules are validated rather than merely counted. ### What a strong answer sounds like Not a preference between the three models, but the recognition that the mapping is an *owned deliverable* with a name against it, that "deployed" needs a definition harsher than the tooling's default, and that the evidence which settles it is a detection observed firing on behaviour somebody deliberately performed.