A provisioning record captures a point-in-time entitlement decision: this user was granted access to this application on this date. It records that the door was opened. It contains no information about whether anyone has walked through it since.
An access usage record captures an event: this user authenticated and launched this application at this timestamp from this device. It records that the access was exercised. It is a different dataset from the provisioning record and in most IAM architectures, it does not exist.
The absence of access usage data has three distinct consequences that are usually treated as separate problems but share the same root cause. First, dormant accounts with valid access entitlements accumulate as an unmonitored attack surface. Second, access reviews that run without usage data certify entitlements rather than evaluate continued need, which is not what ISO 27001 A.5.18, SOC 2 CC6.3, or DPDPA Rules 2025 require from a periodic access review. Third, SaaS licences assigned to users who have not launched the application in months represent recoverable budget that the organisation has no mechanism to identify without usage data.
This blog covers the technical distinction between the two datasets, what each consequence looks like operationally, and what application launch monitoring at the SSO layer produces as a usage record without requiring per-application integrations.
Provisioning is architecturally event-driven: it triggers on access requests and access removals. Between those two events, the provisioning platform has no visibility into what happens with the entitlement. Whether the user launches the application daily or not at all, the provisioning record is identical. The record reflects the entitlement state, not the usage state.
Application usage data, where it exists, lives in the application itself. Applications that generate access logs produce records of who authenticated and when. Those records live in the application’s own logging infrastructure. Pulling them into a coherent cross-application usage view requires native API integrations with each application, a CASB layer that monitors application traffic, or manual extraction on a schedule. None of these is operationally straightforward at scale across 40 to 60 SaaS applications.
The result is that most organisations have precise provisioning records and no structured usage data. The two datasets that together constitute a complete picture of access governance exist independently, and most organisations only have one of them.
An account that has not been used in 90 days is not actively monitored by the user who owns it. Password change notifications go unread. Anomalous MFA prompts go unreported. If the account’s credentials are compromised, the compromise may not surface for weeks because the legitimate user has no reason to notice anything unusual about an account they are not using.
NIST SP 800-53 Control AC-2 recommends disabling inactive accounts after a defined period. ISO 27001:2022 Annex A Control A.5.16 requires that identity management include a mechanism for reviewing and disabling inactive identities. Most organisations have a policy that specifies an inactivity threshold. Very few have a technical mechanism that enforces it, because they do not have the usage data needed to identify which accounts are inactive.
Access reviews under ISO 27001 A.5.18 and SOC 2 CC6.3 are supposed to evaluate whether access is still appropriate. Without usage data, the reviewer can confirm that the entitlement exists and that the user’s current role appears to justify it. They cannot evaluate whether the access has been exercised in the review period, whether the usage pattern is consistent with the stated business need, or whether the access should continue to exist given that nobody has used it in six months.
Under DPDPA Rules 2025, access to personal data should be granted on a need-to-know basis and reviewed periodically. A review that certifies access without any data on whether the access has been exercised is not a meaningful review of whether the need-to-know condition is still met. For financial services organisations and healthcare organisations where access reviews are part of RBI, SEBI, and HIPAA compliance obligations, a review based on usage data is qualitatively and evidentially different from a review based on entitlement records alone.
SaaS licences are priced per seat. A seat occupied by a user who has not launched the application in six months is a seat being paid for without return. Industry data from SaaS management platforms consistently indicates that between 20 and 30 percent of provisioned SaaS seats are unused in a typical month. For a mid-market organisation with 500 users and 50 SaaS applications, that percentage represents a significant monthly spend on licences that could be reclaimed and reallocated or cancelled. Identifying and reclaiming those seats requires knowing which users have not launched which applications in a defined period. That requires usage data.
Application launch monitoring captures the event that occurs when a user authenticates through the IAM platform and is directed to a specific application. It operates at the SSO layer, not at the application layer. Any application that uses SSO-based authentication through Akku produces a launch event at the identity platform regardless of whether the application has its own session logging capability. No per-application integration is required.
Each launch event captures the user identifier, the application accessed, the timestamp, the device, and the geo-location of the authentication. This data is stored per user per application, producing a usage record that sits alongside the provisioning record in the identity platform.
The immediately actionable output is a last-used date for each user-application combination. An access review showing a user has not launched an application in 120 days has a different conversation than one showing daily usage. The reviewer makes a decision based on actual usage behaviour rather than on whether the user’s role still appears to justify the access in the abstract.
For automated lifecycle management, last-used date enables a technical policy: accounts that have not accessed an application within a defined period are flagged for review or automatically suspended based on the risk profile of the application. This is the technical enforcement of what ISO 27001 A.5.16 and most inactivity policies describe but rarely implement.
Application launch data over time produces a usage baseline per user per application. A user who normally launches the CRM five times daily but whose launch events stop appearing for two weeks has experienced something: a missed offboarding, extended leave, or an account compromise that locked the legitimate user out. A user who normally accesses a specific application once a week but suddenly launches it dozens of times in a single session is also anomalous. Both signals are only available if launch data is being collected.
Usage data enables licence reclamation with evidence rather than estimation. The IT team produces a report showing per application: provisioned users, users who launched at least once in the last 30 days, and users who have not launched in 90 days. That report is the basis for a licence reclamation conversation with the application vendor. Removing dormant seats from a SaaS licence is a straightforward conversation when the usage data supports it.
Application launch data is most operationally powerful when connected to the automated user lifecycle management layer in Akku rather than existing as a standalone reporting view. When the last-used date for a user-application combination crosses a defined threshold, the lifecycle management layer triggers a review workflow automatically: the user’s manager is notified, confirmation of continued need is requested, and access is removed if no confirmation arrives within the defined period.
This closes the loop between usage visibility and access governance without requiring a manual process for each dormant account. The review is triggered by the data. The outcome is recorded in the provisioning system. The audit trail shows that dormant access was identified, reviewed, and either confirmed or removed, which is the evidence that a meaningful periodic access review under ISO 27001 A.5.18 and DPDPA is supposed to produce.
For ITeS and BPO organisations where employees frequently change project assignments and client system access needs corresponding adjustment, application launch data makes the access actually being used visible in a way that a provisioning record cannot. Access to a client system that has not been launched since a project ended three months ago is a deprovisioning candidate that the standard offboarding process may have missed.
Pick three applications in your environment that hold sensitive data. For each one, pull the list of provisioned users from your IAM platform. Then answer: of those users, how many have not accessed the application in the last 90 days?
If the IAM platform cannot answer that question from its own data, the usage visibility gap is confirmed. The provisioning record exists. The usage record does not. The security implication is a list of dormant accounts passing access reviews without any evidence of whether the access is still exercised. The compliance implication is that those reviews, under DPDPA and ISO 27001, are based on entitlement data rather than access behaviour. The cost implication is a straightforward calculation: dormant licensed seats multiplied by the per-seat monthly cost.
Explore Akku IAM and Lifecycle Management | See Akku IGA and Access Reviews | Talk to the Akku Team
Q: What is the technical difference between a provisioning record and an application launch record?
A: A provisioning record captures the entitlement lifecycle: when access was granted, by whom, under what approval, and when it was removed. It records a decision about access. An application launch record captures a usage event: a specific user authenticated and was directed to a specific application at a specific timestamp. The two records describe different things. A provisioning record answers whether a user has access. An application launch record answers whether a user has used their access. Both are required for complete access governance. Most IAM platforms maintain only the provisioning record.
Q: How does application launch monitoring differ from application-level session logging?
A: Application-level session logging is performed by the application itself and requires either native logging capability in the application or a CASB layer intercepting traffic. Application launch monitoring is performed at the SSO layer: when the user’s authenticated session is redirected from the identity platform to the application, the launch event is captured. It requires no integration with each individual application. Any application using SSO-based authentication through Akku produces a launch event at the identity platform regardless of the application’s own logging capability.
Q: How does DPDPA treat dormant access to personal data systems?
A: DPDPA requires that access to personal data is granted on a need-to-know basis and reviewed periodically. An account that has not accessed a personal data system in several months raises a question about whether the need-to-know condition is still met. A periodic access review certifying access without usage data cannot meaningfully evaluate this. The DPDPA’s access accountability requirements imply that the organisation can demonstrate not just that access exists and was approved, but that access is actively justified by current need. Application launch data provides the evidence needed to distinguish active access from dormant access.
Q: What is a practical inactivity threshold for triggering an access review?
A: The appropriate threshold depends on the application’s risk profile. For high-sensitivity applications containing personal data, financial records, or privileged system access, 30 days is appropriate. For standard productivity applications, 60 to 90 days is common. The threshold should be defined in the access control policy rather than set arbitrarily, so the automated review trigger is aligned with the policy’s stated inactivity standard. ISO 27001 A.5.16 does not specify a number but requires that inactive identities are identified and addressed within a defined timeframe.
Q: How does usage data improve the quality of access reviews under SOC 2 CC6.3?
A: SOC 2 CC6.3 requires periodic review of whether existing access is still appropriate. With only entitlement data, the reviewer confirms the access exists, and the role appears to justify it. With usage data, the reviewer can evaluate whether the access has been exercised in the review period and whether the usage pattern is consistent with the stated business need. A reviewer who sees that a user has not launched an application in 180 days makes a substantively different decision than one who sees only that the entitlement exists. The audit evidence produced by a usage-informed review is qualitatively stronger under both SOC 2 and ISO 27001.
Q: How does Akku connect application launch data to the provisioning and deprovisioning lifecycle?
A: In Akku, application launch events are captured at the SSO layer when users access applications through Akku-managed SSO. This data feeds into the access governance layer alongside provisioning records, producing a combined view of who has access and who is using it. Inactivity thresholds can be configured as policy rules that trigger automated review workflows when a user-application combination has not produced a launch event within the defined period. The full chain from provisioning through usage monitoring through periodic review to deprovisioning is traceable in a single audit trail.
If your SSO platform had a service disruption at 2am tonight, how would your team find out about it? For…
The IAM layer generates the earliest detectable signal of a credential attack. Before any account is compromised, before any privileged…
Defensible audit evidence for an access grant has a specific technical definition. It is not a confirmation that the access…
When did you last run a compliance evidence collection that did not surface something unexpected? Not a gap in your…
Your user authenticated this morning. They presented the right credentials. They completed the MFA challenge. Your access control system granted…
When you give someone SSH access to a Linux server, what exactly have you given them? Think about that carefully…