What should procurement and IT teams measure to know the catalog is working?

Why This Matters for Security Teams

A catalog is only useful if it changes buying behavior and reduces risk at the point of request. For procurement and IT teams, the core question is not whether a catalog exists, but whether it is actually absorbing demand that would otherwise turn into one-off purchases, manual approvals, and shadow procurement. That is why catalog measurement belongs in both operational and security reporting. It shows whether standard options are usable, policy is enforceable, and exceptions are shrinking for the right reasons.

This is especially important in identity-heavy environments where purchases often include API keys, service accounts, certificates, or other secrets. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why catalog control cannot be treated as a procurement-only metric. The NIST Cybersecurity Framework 2.0 reinforces the need to measure outcomes, not just policy presence. In practice, many security teams discover catalog failure only after exceptions, duplicate vendors, or unmanaged credentials have already spread across the environment, rather than through intentional measurement.

How It Works in Practice

Effective catalog measurement combines usage, speed, exception handling, and control adherence. A healthy catalog is not just popular. It should make the compliant path faster than the nonstandard path while reducing manual review. Procurement and IT should measure whether users are selecting catalog items first, whether those items cover the most common business needs, and whether the approval path stays predictable.

For NHI-related purchases, this usually means tracking whether the catalog exposes approved patterns for service accounts, secrets storage, token issuance, rotation, and deprovisioning. The strongest signal is not volume alone but the ratio of standard purchases to exceptions. If exceptions are rising, the catalog may be too narrow, too slow, or disconnected from actual delivery teams. NHIMG’s Ultimate Guide to NHIs is useful here because it highlights how weak visibility and poor rotation practices often begin with informal provisioning and one-off approvals.

• Track catalog adoption by category, department, and request type.
• Measure request cycle time from submission to fulfilment for standard items versus exceptions.
• Monitor manual intervention count, including policy overrides and rework.
• Review exception reasons to see whether they reflect genuine business need or catalog design gaps.
• Measure post-purchase control outcomes, such as whether secrets are vaulted, rotated, and offboarded on schedule.

For governance mapping, the NIST Cybersecurity Framework 2.0 is helpful because it ties measurable outcomes to risk management and continuous improvement. These controls tend to break down when catalog ownership is split across procurement, platform teams, and security because no single group is accountable for exception trends or policy drift.

Common Variations and Edge Cases

Tighter catalog enforcement often increases short-term friction, requiring organisations to balance speed against standardisation. That tradeoff is real in fast-moving engineering environments, where teams may need temporary exceptions for cloud experiments, acquisitions, or regulated integrations. Current guidance suggests that the goal is not zero exceptions, but exceptions that are rare, time-bound, and explainable.

One edge case is a catalog that looks healthy on paper because usage is high, yet most requests still require manual edits. That pattern usually means the catalog is acting as a front door to custom work, not as a true standardisation mechanism. Another common issue is “approval theatre,” where exception volume drops but only because users route around the process through direct vendor contact or informal procurement channels. That is why catalog metrics should be paired with policy compliance and downstream identity controls.

There is no universal standard for the ideal exception rate because it depends on business complexity and risk appetite. However, if the same exception categories repeat month after month, the catalog is probably lagging demand rather than constraining risk. The practical test is simple: standard requests should be quicker, easier, and safer than nonstandard ones, and any failure to preserve that ordering should be visible in the metrics.

Related resources from NHI Mgmt Group

• How do security teams know whether cloud access policy is actually working?
• How do IAM teams know if privileged access controls are actually working?
• How do security teams measure whether agent classification is working?
• How do teams know whether policy as code is actually working?