The risk office wants measurable signals on both a payment-card control and a fraud risk for the transit authority. What IRM common object fits that need?

Measurable signals on both a payment-card control and a fraud risk for a transit authority use indicators as common measurement objects that can attach to controls or risks. The same indicator framework mounts on different IRM objects, so the authority does not invent separate metric systems for control health versus risk residual context. Common indicators are how CIS-RC connects monitoring across the stack.

Authority documents that only store regulatory text without metrics cannot measure signal. Entity classes used solely to rename departments in the CMDB are structural, not measurement objects. Policy acknowledgments that prove users read a handbook demonstrate awareness, not ongoing fraud or payment-control performance metrics.

Exam caveat: indicators attach to controls or risks; citations, entity classes, and acknowledgments are different object types with different purposes.

Operational check: create indicators for the payment-card control and the fraud risk; set thresholds and collection; confirm both use the indicator framework; report breaches to the risk committee without substituting acknowledgments or citation text for metrics.

For transit fraud and payment-card monitoring, name indicator owners and review cadence so breaches page the right civic operators. Keep acknowledgment campaigns separate from indicator evaluation—reading a handbook never substitutes for a failed payment-control threshold. Publish indicator definitions in the GRC catalog so Risk and Compliance reuse the same measurement object types.