Introduction
IRDAI ICS Annexure III Item 10 requires that user accounts inactive beyond a defined threshold be automatically disabled. The operative word is automatically. A manual process where an IT administrator periodically reviews account activity reports and disables dormant accounts does not satisfy this requirement at the scale most insurance organisations operate. Automation is the technical requirement, not merely a recommended approach.
Dormant accounts represent a persistent access risk that is disproportionate to their apparent inactivity. An account that has not been used in 90 days belongs to a user who is either no longer employed, on extended leave, or has moved to a different role with different system access requirements. In each case, the account may hold entitlements that are no longer appropriate. If the account’s credentials are compromised through a phishing attack or credential stuffing, the attacker has access to systems the account is entitled to reach without any authentication anomaly triggering an alert, because the account has simply never been used recently.
Most insurance IT teams run dormant account reviews periodically, typically quarterly or semi-annually. The review identifies inactive accounts, produces a list, and administrators work through the list to disable or remove accounts. Between review cycles, dormant accounts accumulate. Accounts created during the gap between the last review and the current one are not caught until the next cycle. Item 10 requires a technical control that closes this gap continuously, not periodically.
This blog covers what Item 10 requires technically, why periodic manual reviews do not satisfy the automation requirement, what other IRDAI ICS items relate to account lifecycle management, and how automated dormant account management operates.
What Item 10 Requires Technically
Item 10 requires automatic disabling of user accounts that have been inactive beyond a defined threshold. The requirement has three components: activity monitoring, threshold enforcement, and automatic action.
Activity monitoring
Automatic disabling requires continuous monitoring of account activity. The system must track the last authentication event for every user account across all connected systems. For a centralised identity management platform, this means the last successful authentication event in the audit log for each user identity.
The activity monitoring scope matters. An account that has not authenticated to the organisation’s SSO platform in 90 days may still have authenticated directly to a legacy application that does not route through the centralised identity layer. If the dormant account definition is based on SSO activity alone, accounts with residual direct application access may not be detected as dormant.
Comprehensive activity monitoring requires the centralised authentication layer to serve as the single authentication path for all systems. When all systems authenticate through the centralised IdP, the last authentication event in the centralised log accurately reflects the account’s activity state across all systems.
Threshold enforcement
The inactivity threshold must be defined in the IT security policy and technically configured in the identity management platform. Industry practice at IRDAI-regulated entities typically sets the dormant account threshold at 90 days of inactivity, though some organisations use 60 days for accounts with access to sensitive systems.
The threshold must be applied consistently across all user account categories: employees, contractors, third-party administrators, and service accounts. Service accounts present a specific challenge because they may have legitimate periods of inactivity that do not indicate dormancy. Separate threshold policies for service accounts versus human user accounts address this distinction.
Automatic action
When an account crosses the inactivity threshold, the automatic action must be account disabling, not flagging for administrator review. Item 10’s automation requirement means the disabling must occur without human intervention. The disabling event must generate a timestamped audit record capturing the account identity, the triggering threshold, and the disabling timestamp.
The distinction between automatic disabling and automatic flagging is significant. A system that identifies dormant accounts and queues them for administrator review is a manual process with automated discovery. Item 10 requires automated enforcement: the account is disabled when the threshold is crossed, regardless of whether an administrator reviews the flag.
Related IRDAI ICS Items on Account Lifecycle Management
Item 10 does not exist in isolation. Several other IRDAI ICS items address related aspects of account lifecycle management that interact with dormant account controls.
Item 6: Temporary and contractor account lifecycle
Item 6 requires that temporary and contractor accounts be provisioned with a defined expiry date and removed or disabled promptly when the engagement ends. For organisations where contractor access is common, Item 6’s requirement is closely related to Item 10: both require that accounts do not persist beyond the point where they are needed.
Technically, Item 6 requires time-bound access for temporary accounts. The access grant must include an expiry date. When the expiry date arrives, access is automatically removed. This is the JIT access model applied to temporary engagements rather than individual sessions.
Item 26 and Item 33: Joiner-mover-leaver processes
Items 26 and 33 address the broader user lifecycle management requirement: accounts must be provisioned promptly on joining, updated when roles change, and removed promptly on departure. These items frame the ongoing lifecycle management context within which Item 10’s dormant account control operates.
An organisation with a strong joiner-mover-leaver process will have fewer dormant accounts because departures are deprovisioned promptly. Dormant accounts accumulate when the leaver process is incomplete: employees who left informally, contractors whose engagements ended without a formal deprovisioning trigger, or accounts created for specific projects that were never removed when the project concluded.
Item 189: Access reviews
Item 189 requires access reviews to be conducted periodically. Access reviews complement dormant account controls by identifying accounts that are active but hold entitlements that are no longer appropriate. An account that authenticates monthly but holds access to systems unrelated to the user’s current role is not dormant but may be over-provisioned. Item 189’s access reviews address this category of access risk that dormant account controls alone do not cover.
Akku’s IRDAI compliance mapping shows IGA and User Lifecycle Manager together address Items 6, 10, 26, 33, 150, 152, 155, 157, 189, and 341 across 10 total mappings.
Why Periodic Manual Reviews Do Not Satisfy Item 10
Item 10’s automation requirement is specific and cannot be satisfied by a periodic manual process, regardless of how frequently the reviews are conducted.
The gap between review cycles
Any periodic review process has a gap between cycles during which dormant accounts accumulate unchecked. If reviews are conducted quarterly, accounts that cross the inactivity threshold in month two of the quarter remain active for up to two months before being disabled. An attacker who compromises credentials for a dormant account during this window has undetected access for the duration of the gap.
Item 10’s requirement for automatic disabling eliminates this gap. When the threshold is crossed, the account is disabled immediately, not at the next review cycle. The gap is reduced from weeks or months to hours or less, depending on how frequently the activity monitoring system checks account states.
Scalability at insurance organisation scale
An insurance organisation with thousands of employees, hundreds of contractors, and dozens of third-party integrations cannot reliably manage dormant account identification and disabling through manual processes. At scale, manual review processes produce inconsistent results: some dormant accounts are caught promptly, others persist through multiple review cycles due to oversight or workload constraints.
Automated dormant account management applies the threshold consistently to every account simultaneously. No account is overlooked because an administrator was occupied with other work during the review cycle.
Audit evidence quality
A manual dormant account review produces evidence that reflects what was reviewed during a specific cycle. An automated dormant account control produces evidence that reflects what occurred for every account continuously. The quality of the audit evidence from an automated control is materially higher than from a manual process, and IRDAI IS auditors examining Item 10 compliance assess the evidence quality alongside the process description.
How Automated Dormant Account Management Works in Akku
Akku’s User Lifecycle Manager implements automated dormant account management through continuous activity monitoring and threshold-based enforcement.
Activity monitoring
The centralised audit log captures every authentication event across all connected applications. The User Lifecycle Manager monitors the last authentication timestamp for every user identity in the Akku directory. When an account’s last authentication event exceeds the configured inactivity threshold, the account is flagged for automatic action.
For accounts with access to systems that route authentication through Akku’s centralised identity layer, activity monitoring is comprehensive. For legacy systems with direct authentication not yet migrated to SSO, activity monitoring covers the centralised authentication layer but not direct application authentication. Full coverage requires all systems to authenticate through the centralised IdP.
Threshold configuration
Inactivity thresholds are configurable per user group or organisational unit. A 90-day threshold can be applied to standard employee accounts while a 30-day threshold applies to accounts with privileged access to critical systems. Service account thresholds can be set separately to accommodate legitimate inactivity patterns.
Automatic disabling and audit record
When an account crosses the threshold, the User Lifecycle Manager automatically disables the account across the Akku directory and triggers deprovisioning notifications to connected applications via SCIM. The disabling event generates a timestamped audit record capturing account identity, triggering threshold, last activity timestamp, and disabling timestamp. This record is the compliance evidence that Item 10 requires.
Re-activation workflow
When a disabled account needs to be re-activated, a structured re-activation workflow requires manager approval and justification before the account is re-enabled. The re-activation record is stored in the audit trail alongside the disabling record, providing a complete lifecycle history for the account.
Diagnostic Questions
Does your organisation have a technically-enforced inactivity threshold that automatically disables accounts when crossed, or does dormant account management rely on periodic manual review cycles?
For accounts disabled through dormant account controls in the last 12 months, is there a timestamped audit record for each disabling event showing the account identity, the triggering threshold, and the disabling timestamp?
Does your activity monitoring cover all systems that user accounts can authenticate to, or only systems that route through the centralised identity layer, leaving direct application authentication outside the monitoring scope?
Are temporary and contractor accounts provisioned with defined expiry dates that trigger automatic removal when reached, or does contractor account removal depend on a manual deprovisioning request from the business unit?
When dormant accounts are re-activated, is there a structured approval workflow requiring manager authorisation and documented justification, with the re-activation event recorded in the audit trail?
CTAs
See how Akku’s User Lifecycle Manager addresses IRDAI Item 10 dormant account requirements through automated activity monitoring and threshold-based enforcement.
Book a conversation with the Akku team to assess your current dormant account management against IRDAI ICS Item 10’s automation requirement.
FAQs
What is the specific inactivity threshold IRDAI Item 10 requires for dormant account disabling?
IRDAI ICS Item 10 requires automatic disabling of accounts inactive beyond a defined threshold but does not specify a precise number of days in the checklist item itself. Industry practice at IRDAI-regulated insurers typically applies a 90-day threshold for standard employee accounts and a shorter threshold, often 30 to 60 days, for accounts with privileged access to critical systems. The threshold must be defined in the organisation’s IT security policy and consistently applied through technical enforcement. IS auditors examining Item 10 compliance assess both the defined threshold and the evidence that it is technically enforced, not merely policy-stated.
What is the difference between account disabling and account deletion for Item 10 purposes?
Account disabling suspends the account, preventing authentication while preserving the account record and its audit history. Account deletion permanently removes the account. Item 10 requires automatic disabling as the immediate action when the inactivity threshold is crossed. Permanent deletion typically follows a further review process to confirm the account is no longer needed and to preserve audit trail integrity. For departed employees, deletion may be deferred to align with data retention obligations. For contractor accounts with confirmed engagement end, deletion may be appropriate immediately following disabling.
How does dormant account management interact with accounts that have legitimate periods of inactivity, such as employees on extended leave?
Employees on extended leave, maternity leave, long-term medical leave, or sabbatical may have accounts that cross the inactivity threshold without representing a security risk. The recommended approach is to configure a separate inactivity policy for accounts in defined leave status, with a longer threshold or a hold that prevents automatic disabling during the leave period. The leave status must be sourced from an authoritative HR system and applied to the account automatically when leave begins. Accounts on leave hold are still monitored and can be reviewed periodically. When leave ends, the standard inactivity threshold applies from the return-to-work date.
Does Item 10 apply to service accounts as well as human user accounts?
Yes, Item 10 applies to all user accounts including service accounts. Service accounts present a specific challenge because they may have legitimate periods of inactivity that do not indicate dormancy. A service account used for a batch job that runs monthly will appear inactive for 29 days out of every 30. Applying a standard 90-day inactivity threshold to service accounts requires careful threshold configuration to avoid false positives. The recommended approach is a separate inactivity policy for service accounts with a longer threshold, combined with a service account inventory that documents the expected activity pattern for each account. Service accounts with no documented expected activity pattern should be reviewed and either given an activity expectation or removed.
What audit evidence does IRDAI Item 10 compliance require, and how should it be structured for IS audit examination?
IRDAI IS auditors examining Item 10 compliance typically request evidence of the automated disabling mechanism configuration, showing the threshold is technically enforced rather than policy-stated. They request a sample of disabling events from the audit log showing timestamped records for accounts disabled through the automated control during the examination period. They verify that the disabling events are generated automatically at the time of threshold crossing, not manually triggered following a review. They also verify that disabled accounts have had their access to connected systems revoked, requiring SCIM deprovisioning confirmation records alongside the identity platform disabling records.
Can Akku’s dormant account management satisfy both IRDAI Item 10 and SEBI CSCRF PR.AA.S1’s dormant account requirements simultaneously?
Yes. IRDAI Item 10 and SEBI CSCRF PR.AA.S1(G1g) and G1h both require automatic disabling of accounts inactive beyond a defined threshold. The same automated dormant account management capability in Akku’s User Lifecycle Manager satisfies both requirements from the same technical control. The threshold configuration, activity monitoring, automatic disabling, and audit record generation are identical for both frameworks. The compliance mapping differs in clause references, but the underlying control is the same implementation producing the same continuous evidence.
