IRDAI ICS Annexure III Item 5 requires that user behaviour monitoring be implemented to detect anomalies in login time, login location, session duration, and access patterns, with alerts generated when behaviour deviates from established baselines. This is not a log storage requirement. It is an active detection requirement: the monitoring infrastructure must evaluate behaviour continuously against baselines and surface deviations for investigation without waiting for an administrator to manually review log files.
Most insurance IT environments have authentication logging in place. Every login attempt is recorded. Failed authentication events are captured. The gap Item 5 addresses is the layer between logging and detection: the analysis that converts a stream of login events into an alert when a specific event deviates from the established pattern for that user.
An authentication log containing a login from a new country at 3 AM is indistinguishable from a normal login without the baseline context. The event has the same format as every other successful login. Without anomaly detection that compares the event against the user’s historical access pattern, the anomaly exists in the log but is invisible to the monitoring team until they are specifically looking for it. By then, the attacker who used compromised credentials may have had hours of undetected access.
Item 5’s detection requirement is what turns passive logging into active security monitoring. This blog covers what Item 5 specifically requires, what baselines must cover, how detection thresholds must be configured, and how Akku’s Adaptive MFA implements the requirement.
Item 5 is within the audit trail and monitoring section of the IRDAI ICS Annexure III checklist. It requires user behaviour monitoring with anomaly detection and alert generation.
Anomaly detection requires a baseline against which current behaviour is compared. Item 5’s requirement for detecting anomalies in login time, location, and access patterns implies that baselines must cover at least these dimensions.
Login time baseline: the typical hours during which a user authenticates, derived from historical authentication events. A user who routinely logs in between 9 AM and 6 PM has a login time baseline. A login at 2 AM is a deviation from this baseline.
Login location baseline: the geographic locations from which a user typically authenticates, derived from IP geolocation of historical authentication events. A user who routinely authenticates from Mumbai and occasionally from Delhi has a location baseline. A login from a European IP address is a deviation.
Access pattern baseline: the applications and systems a user typically accesses during sessions, derived from session event logs. A user who routinely accesses the claims processing system and the policy administration system but not the financial reporting system has an access pattern baseline. Accessing the financial reporting system for the first time is a deviation worth examining.
Session duration baseline: the typical length of a user’s sessions for each application, derived from session start and end timestamps. A session significantly longer than the user’s historical average may indicate an automated process using the user’s credentials rather than interactive use.
Item 5 requires that alerts be generated when behaviour deviates from baselines. The alert generation requirement distinguishes anomaly detection from anomaly logging. A system that logs every authentication event with its contextual details but requires an administrator to review logs to identify anomalies is not generating alerts. An alert is a proactive notification that a specific event warrants investigation, generated automatically when the deviation threshold is crossed.
Alerts must be actionable. They must contain sufficient context for an administrator to assess the severity and initiate investigation: the user identity, the anomalous event, the baseline against which it was compared, the deviation magnitude, and a risk assessment.
Item 5’s detection and alert requirement implies a response process. Generated alerts that are not investigated fail to satisfy the monitoring objective. The monitoring infrastructure must support an investigation workflow: alerts are reviewed, assessed as genuine anomalies or false positives, and actioned accordingly. The investigation and response must be documented.
Implementing Item 5 requires monitoring across multiple behavioural dimensions. Each dimension requires its own baseline model and deviation detection logic.
Geographic anomaly detection identifies authentication events from locations inconsistent with the user’s established pattern. The most straightforward geographic anomaly is an authentication from a country where the organisation has no operations and the user has no travel history.
Impossible travel is a specific geographic anomaly that requires no baseline comparison: two authentication events for the same user from geographically distant locations within a timeframe that makes physical travel impossible indicate either credential sharing or account compromise. A login from Chennai at 10 AM and a login from London at 11 AM for the same user is an impossible travel event regardless of the user’s baseline.
For insurance environments where field agents and branch staff may access systems from multiple locations, the baseline must accommodate legitimate geographic variation. An agent who regularly accesses systems from Mumbai, Pune, and Nashik has a multi-location baseline. An authentication from London is still anomalous for this agent. Geographic anomaly detection must distinguish between the variability within an established pattern and genuine deviations from it.
Time-of-day anomaly detection identifies authentication events at hours inconsistent with the user’s established access pattern. For most insurance staff, legitimate access occurs during business hours with occasional after-hours access during peak periods. Authentication at 3 AM for a standard business user is an anomaly worth investigating.
For systems with defined permitted access hours, time-of-day anomaly detection is complemented by policy enforcement: access outside permitted hours is blocked, not merely flagged. The combination of policy enforcement for high-sensitivity systems and anomaly detection for standard systems provides layered coverage.
Device anomaly detection identifies authentication events from devices not previously associated with the user account. For organisations with MDM-enrolled corporate device fleets, authentication from an unrecognised device is a significant signal: it may indicate credential compromise or an employee using personal device access that violates the device policy.
For organisations with BYOD policies, the device baseline must accommodate multiple registered devices per user. Authentication from a device outside the registered set is the anomaly, not authentication from any unrecognised device if BYOD is permitted.
Access pattern anomaly detection identifies when a user accesses systems or performs actions inconsistent with their established pattern. A claims processor who accesses the underwriting system for the first time, a customer service agent who accesses bulk data export functions, or a standard user who begins accessing administrative functions they have never previously used are all access pattern anomalies.
For insurance environments processing sensitive policyholder data, access pattern anomalies at the system and function level are particularly significant. An insider threat scenario where a departing employee accesses and exports customer data before their departure date produces access pattern anomalies, not geographic or time anomalies, because the access occurs from a normal location at a normal time using the employee’s legitimate credentials.
Akku’s Adaptive MFA implements Item 5’s user behaviour anomaly detection requirement through AI-powered analysis at the authentication layer.
Every authentication event is evaluated against the user’s behavioural baseline covering geographic location, device identity, time of day, and access patterns. The baseline is built from historical authentication events and updated continuously as the user’s legitimate access patterns evolve.
The AI-powered analysis compares each new authentication event against the baseline across all dimensions simultaneously. A single deviation may warrant a step-up challenge. Multiple concurrent deviations warrant a higher-risk assessment and may trigger blocking or immediate administrator alert.
When an authentication event deviates from the baseline, Akku’s Adaptive MFA applies a risk-proportionate response. Low-severity deviations, such as authentication from a previously unseen IP within the same city, trigger a step-up MFA challenge: the user must complete an additional factor before access is granted. High-severity deviations, such as impossible travel or authentication from a high-risk IP reputation, may trigger session blocking pending administrator review.
The step-up authentication response is both a security control and an Item 5 compliance mechanism. It generates an alert in the form of the step-up event, documents the deviation that triggered it, and records the outcome. Every step-up event is logged in the audit trail with the triggering signals, the risk assessment, the factor required, and the resolution.
Risk and audit dashboards in the Akku admin console surface anomaly events as actionable alerts. Geographic anomaly alerts, impossible travel detections, new device access events, MFA failure spikes, and access outside permitted hours are presented as prioritised items requiring investigation.
Each alert contains the user identity, the anomalous event details, the baseline comparison, and the risk assessment. Administrators can access the full authentication event context from the alert, initiate investigation, and record the resolution in the audit trail.
The alert generation and investigation interface satisfies Item 5’s requirement that monitoring produces actionable alerts, not passive log storage.
Every anomaly detection event, step-up challenge, block action, and alert resolution is recorded in Akku’s append-only audit log with timestamps. The continuous stream of anomaly detection events throughout the compliance period constitutes the operating evidence that Item 5 requires.
For IS audit examination, the anomaly detection event log demonstrates that the monitoring was active throughout the examination period, that deviations were detected and alerted, and that alerts were investigated and resolved. The absence of any anomaly detection events during a 12-month period would indicate that the detection is either not deployed or not sensitive enough to detect the deviations that occur in any active user population.
Item 5 is frequently confused with standard authentication logging because both involve authentication events. The distinction is what happens to the events after they are recorded.
Authentication logging records events in a structured format for future retrieval and review. The logged events are available for manual inspection and forensic investigation but are not evaluated against baselines in real time. An authentication from an unusual location is logged identically to a normal authentication.
Anomaly detection evaluates events against baselines as they occur and generates alerts when deviations exceed configured thresholds. The anomalous authentication from an unusual location generates an alert immediately, before any investigation is required. The detection is automated and continuous, not dependent on manual log review.
Item 5 requires the latter. Standard authentication logging is a prerequisite for anomaly detection but does not satisfy the detection and alert generation requirement by itself.
Does your authentication infrastructure evaluate each login event against a user-specific behavioural baseline covering location, device, time, and access patterns, or does it log events without baseline comparison?
When a user authenticates from a new country or at an unusual hour, is an alert generated automatically and presented for investigation, or is the deviation only discoverable through manual log review?
Does your monitoring infrastructure detect impossible travel events, where the same user account has authentication events from geographically distant locations within an impossible timeframe, and generate immediate alerts?
For anomaly alerts generated in the last 12 months, is there a documented investigation record for each alert showing that it was reviewed, assessed, and either investigated or cleared with a rationale?
Does your anomaly detection cover access pattern deviations, where a user accesses systems or functions they have not previously accessed, or only geographic and time-of-day deviations?
See how Akku’s Adaptive MFA addresses IRDAI Item 5 user behaviour anomaly detection requirements through continuous baseline evaluation, risk-based step-up authentication, and alert generation.
Book a conversation with the Akku team to assess your current monitoring infrastructure against IRDAI ICS Item 5’s detection and alert requirements.
What is the difference between user behaviour analytics and the anomaly detection Item 5 requires?
User behaviour analytics is a broad category covering statistical analysis of user activity patterns to detect insider threats, data exfiltration, and account compromise. It typically operates on large datasets across multiple data sources including network traffic, file access logs, and application event logs. Item 5’s anomaly detection requirement is more focused: it requires detection of anomalies in login time, login location, session duration, and access patterns with alert generation. This is achievable through authentication-layer anomaly detection without the full data lake infrastructure that enterprise UBA platforms require. Akku’s Adaptive MFA implements the authentication-layer anomaly detection that Item 5 requires without requiring a separate UBA deployment.
How should organisations set anomaly detection thresholds to balance sensitivity and false positive rates?
Threshold calibration is iterative. Initial thresholds should be conservative, generating alerts only for the most unambiguous anomalies such as impossible travel and authentication from countries where the organisation has no operations. As the monitoring programme matures and administrators build experience distinguishing genuine anomalies from false positives, thresholds can be refined. Thresholds that generate too many false positives create alert fatigue, leading to genuine anomalies being dismissed alongside false positives. Thresholds that are too permissive miss genuine anomalies. The threshold review process should be documented and conducted at least quarterly, with adjustments recorded alongside the rationale.
Does Item 5 require user behaviour monitoring for all users or only for privileged users?
Item 5 applies to user behaviour monitoring broadly, not only for privileged users. The login time, location, and access pattern monitoring requirements cover the full user population. For insurance organisations, this includes field agents, branch staff, and business users, not only IT administrators. In practice, the detection sensitivity and alert prioritisation should be tiered by user risk profile: privileged users with access to critical systems warrant more sensitive detection and faster alert response than standard business users. But the monitoring infrastructure must cover all users to satisfy Item 5’s requirements.
How does Akku handle impossible travel detection for users who legitimately travel frequently?
Frequent travellers present a calibration challenge for impossible travel detection. An executive who travels internationally multiple times per month may have authentication events from different countries within short timeframes that are legitimate. The impossible travel detection must distinguish between physically possible travel, even if unusual, and physically impossible authentication sequences. The threshold for impossible travel should be calibrated to the minimum travel time between the two locations. Authentication events separated by more than the minimum travel time are physically possible and should not trigger impossible travel alerts, even if the route is unusual. Events separated by less than the minimum travel time are impossible regardless of the user’s travel history.
What investigation record is required for anomaly alerts under Item 5, and how should it be structured?
An anomaly alert investigation record must document: the alert details including user identity, anomalous event, and detection timestamp. The investigation action taken: whether the administrator contacted the user, reviewed session logs, or escalated to the security team. The resolution determination: whether the event was confirmed as legitimate, confirmed as malicious, or inconclusive. The response action: whether the session was terminated, the account was suspended, or the alert was cleared as a false positive. The resolution timestamp. This structured investigation record demonstrates that alerts are not only generated but acted upon, satisfying Item 5’s monitoring and response objective. IS auditors examining Item 5 will request investigation records for a sample of alerts from the examination period.
Can the same anomaly detection infrastructure satisfy both IRDAI Item 5 and SOC 2 CC7.2 requirements simultaneously?
Yes. IRDAI Item 5 and SOC 2 CC7.2 both require automated anomaly detection with alert generation. IRDAI Item 5 specifically requires detection of anomalies in login time, location, session duration, and access patterns. SOC 2 CC7.2 requires monitoring for anomalies indicative of malicious acts or errors. Both are satisfied by Akku’s Adaptive MFA continuous baseline evaluation, step-up authentication response, and alert generation infrastructure. The evidence required differs in audit context: IRDAI IS auditors examine the detection capability against the specific dimensions Item 5 names, while SOC 2 auditors sample anomaly alert records and investigation documentation across the Type II audit period. The same underlying detection infrastructure and alert records satisfy both.
Introduction IRDAI ICS Annexure III Item 10 requires that user accounts inactive beyond a defined…
Introduction ISO 27001:2022 Annex A.5.18 requires that access rights be reviewed at regular intervals and…
Introduction SOC 2 Trust Services Criteria CC5.1 requires that the entity selects and develops control…
Introduction SEBI CSCRF applies to all regulated entities but differentiates requirements by entity tier. Market…
Introduction SEBI CSCRF PR.AA.S1(G1g) and PR.AA.S1(G1h) require that user accounts inactive beyond a defined threshold…
Introduction ISO 27001:2022 Annex A.8.2 requires that the allocation and use of privileged access rights…