A city finance clerk and a wastewater historian both need scores from new RBA content. How should the risk objects be typed?

In Splunk Enterprise Security for a municipal SOC, the risk framework attaches a numeric score to a typed risk object—most often a user or a system—so later risk notables aggregate the right civic entity. The finance clerk’s identity-centric activity must increment a user risk object; the wastewater historian’s host-centric SCADA activity must increment a system risk object, each with its own score and contributing events. Scoring both as user objects because every asset has a human owner fails by concept because it blames people for host-only telemetry and breaks Asset and Identity joins that expect system keys. Scoring both as system objects so lookups attach department and priority fails by concept because clerk logons and mailbox events belong on the identity, and system typing hides who actually acted. Skipping object type and writing the score only to the correlation-search name fails by concept because search names are not risk objects and cannot build an entity risk notable story for Incident Review. Exam caveat: SPLK-5001 expects analysts to choose the risk object type that matches the civic entity being scored—user versus system—rather than collapsing types or scoring the search itself. Operational check: inspect a recent risk event for the clerk and for the historian, confirm risk_object_type is user for the clerk and system for the historian, verify Asset and Identity enrichments attach to each type correctly, and ensure the risk notable that fires names the entity leadership expects.