How should teams manage SaaS renewals when usage data is incomplete?

Why This Matters for Security Teams

Incomplete usage data is not just a reporting gap. It means renewal decisions are being made without a trustworthy view of who or what is still active, which licenses are being consumed, and whether the underlying access is still justified. That is especially risky for SaaS tools that hold secrets, integrate with CI/CD, or expose API access that can outlive a human owner. In practice, renewal becomes a control point for cleanup, not a clerical extension. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both point to the same operational problem: identity sprawl often hides inside ordinary software renewals. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any team trying to justify spend from incomplete telemetry. In practice, many security teams discover overprovisioned SaaS access only after an audit, incident, or vendor true-up has already forced the issue.

Renewals should start with evidence gathering across three sources: contract records, identity records, and application telemetry. Contract records show what was bought, identity data shows which users, service accounts, or integrations still exist, and telemetry shows whether the product is actually being used. When those views conflict, the safest assumption is that the data is incomplete, not that the license is safe to keep.

A practical workflow is to create a renewal review packet that includes last login activity, assigned owners, active integrations, admin roles, and any secrets or API keys tied to the SaaS platform. For NHI-heavy environments, that packet should also include service account usage and credential age, because a “seat” may actually conceal a machine identity with broader access. NHIMG’s NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Static vs Dynamic Secrets are useful references when a SaaS renewal includes long-lived tokens or integration keys.

Best practice is to treat renewal approval as conditional. If evidence is missing, teams can use a short grace period to validate usage before approving a full term. If evidence shows low or no activity, the renewal should trigger access reduction, license reclamation, and owner revalidation before procurement signs off. This aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance and asset visibility. These controls tend to break down in federated SaaS estates where multiple business units buy the same tool independently because no single team owns the complete access record.

How It Works in Practice

The most reliable renewal process is a three-way reconciliation. First, confirm the contracted license count, renewal date, and named owner. Second, pull identity data from your IdP, SCIM feed, or directory exports to identify active accounts, groups, and non-human identities. Third, gather telemetry from the SaaS platform itself, such as last activity, admin usage, automation traffic, and connected integrations.

• Match each paid seat or subscription to a current business owner.
• Separate human accounts from service accounts, bots, and API integrations.
• Flag inactive accounts, dormant entitlements, and credentials with no recent use.
• Require a decision for each exception: keep, remove, reassign, or investigate.

Where visibility is weak, teams should use risk-based thresholds instead of waiting for perfect data. For example, a long-idle admin account, a stale OAuth token, or a SaaS app with no assigned owner should be treated as a renewal blocker until validated. NHIMG’s Top 10 NHI Issues is relevant here because renewal often exposes the same lifecycle failures seen in NHI sprawl: orphaned access, stale secrets, and absent offboarding. When auditability matters, document who approved the renewal, what evidence was reviewed, and what cleanup followed.

Teams should also distinguish between usage and value. A seat may be technically active but still unnecessary if the process it supports has moved elsewhere. Likewise, a low-login administrative account may be essential if it governs a critical workflow. The point is not to maximise deletion, but to validate entitlement against current business need. In this model, renewal becomes the moment to re-baseline access and reclaim waste before costs roll into another term. These controls tend to break down when SaaS data cannot be tied back to a named owner or a reliable identity source because no one can prove whether the account is still required.

Common Variations and Edge Cases

Tighter renewal controls often increase coordination overhead, requiring organisations to balance better governance against slower procurement cycles. That tradeoff is usually worth it for platforms with privileged access, sensitive data, or embedded automation, but it can feel heavy for low-risk tools.

There is no universal standard for this yet, but current guidance suggests a few common exceptions. Shared departmental licenses may need manager attestation rather than per-user activity logs. Transactional tools may show low logins even when they are critical to back-end jobs. Vendor-managed automations can also obscure usage, especially when the SaaS platform is accessed by machine identities rather than employees. In those cases, renewal review should include service ownership, integration scope, and credential lifecycle, not just human sign-ins.

For organisations facing merger activity, rapid hiring, or tool consolidation, incomplete usage data is normal. The safer approach is to renew only with a cleanup plan attached: reconcile identities, remove duplicates, and retire access that no longer maps to a working process. NHIMG’s Guide to the Secret Sprawl Challenge is especially useful when SaaS renewals are hiding API keys or stored credentials that never appear in seat reports. Where the process breaks down most often is in multi-tenant environments with decentralized purchasing, because duplicate subscriptions and shadow owners make “usage” look cleaner than it really is.

Related resources from NHI Mgmt Group

• How should security teams identify shadow data across cloud and SaaS environments?
• How can teams use KYC and CDD data more effectively in monitoring?
• What do security teams get wrong about permissioned data access?
• What should security teams do when AI usage spikes unpredictably?