Identity Analytics and Risk Scoring

HICP Practice 6.5 requires you to deploy identity analytics that detect anomalous access patterns and assign risk scores to identity-related events so your team can triage, investigate, and respond consistently. Operationally, that means instrumenting identity signals (logins, MFA, privilege changes), defining risk scoring logic, and routing high-risk events into a documented investigation workflow. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Key takeaways:

• You need detection logic for anomalous identity behavior (including impossible travel) and a repeatable risk scoring model. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Scores must drive action: thresholds, alert routing, investigation steps, and response outcomes need to be defined and evidenced. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Audits will focus on coverage (systems/users), scoring rationale, and proof that high-risk identity events were investigated and remediated. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Identity analytics and risk scoring is a requirement-level control that closes a common operational gap: teams collect identity logs but fail to convert them into decisions. HICP Practice 6.5 is explicit: implement identity analytics to detect anomalous access patterns and assign risk scores to identity-related events. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a measurable detection-and-response capability with three deliverables: (1) defined identity signals and coverage, (2) a documented scoring model tied to specific anomalous behaviors, and (3) an investigation workflow with retained evidence.

This requirement is not asking for a specific product category by name. It is asking for outcomes you can prove: your organization can identify unusual identity activity (for example, impossible travel, abnormal access patterns, suspicious privilege changes) and you can consistently prioritize those events based on risk. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) If you can’t show how risk scores are produced, what triggers an investigation, and what happens next, you will struggle to defend compliance even if tools are deployed.

Regulatory text

Requirement (HICP Practice 6.5): “Implement identity analytics to detect anomalous access patterns and assign risk scores to identity-related events.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

What the operator must do:
You must implement analytics over identity telemetry (authentication, authorization, session, and privilege activity) that can detect anomalies (including unusual access patterns and impossible travel) and produce a risk score per identity-related event to drive investigation and response. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Plain-English interpretation

You need an identity “early warning system” that does more than alert. It must:

1. Detect suspicious identity behavior (not just known-bad indicators).
2. Score the event so analysts and incident handlers can prioritize.
3. Trigger a documented workflow: investigate, contain if needed, and record outcomes. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

If your current setup produces a flat stream of identity alerts with no prioritization or consistent handling, you are not meeting the intent of risk scoring.

Who it applies to

Entity types: Healthcare organizations and health IT vendors. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operational context (where exams and incidents focus):

• Workforce identities: employees, clinicians, administrators, help desk.
• Privileged identities: domain admins, EHR admins, cloud admins, break-glass accounts.
• Service and non-human identities: API keys, service accounts, automation runners.
• Third-party access paths: managed service providers, billing partners, EHR integrations, remote support. Treat these as identity events even if the “user” is external; the risk still lands on you.

What you actually need to do (step-by-step)

1) Define scope and “crown jewel” identity surfaces

Create a short scope statement that names:

• Identity providers (IdP), directories, SSO, VPN/remote access, EHR/clinical apps, cloud consoles, PAM, help desk tooling.
• High-impact data/applications (EHR, patient portals, claims platforms, file shares with ePHI).
• Administrative planes (cloud tenant admin, endpoint management, backups).

Output: “Identity Analytics Scope” document listing in-scope systems, log sources, and high-risk roles.

2) Instrument the right identity signals (log coverage first)

Collect logs that let you detect anomalies and reconstruct sequences:

• Authentication: success/failure, MFA prompt/deny, password resets, step-up auth.
• Session and access: token issuance, session duration, abnormal access times.
• Authorization: group membership changes, role assignments, app consent grants.
• Privileged operations: elevation events, new admin creation, break-glass use.
• Context: source IP, device identifier/posture if available, geolocation, user agent.

Evidence tip: auditors will ask “show me” by selecting a few identity events and tracing them back to raw logs.

3) Define anomaly use cases you will detect

Start with a small set you can defend and operate, such as:

• Impossible travel / suspicious geovelocity. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Abnormal access patterns: unusual hour, unusual device, unusual application for that user. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Excessive authentication failures followed by success.
• MFA fatigue patterns (repeated prompts, repeated denies).
• Privilege escalation anomalies: sudden admin rights, group changes outside change window.
• Service account anomalies: interactive login, new source network, unusual call volume.

Control design note: document each use case with: data required, detection logic (high-level), and expected response.

4) Build a risk scoring model you can explain

HICP requires risk scores; treat the score as a function of impact and likelihood, based on identity context. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

A practical scoring model uses weighted factors such as:

• Identity sensitivity: privileged account, clinical admin, service account.
• Asset sensitivity: EHR admin console vs low-risk app.
• Behavioral severity: impossible travel, new device + new geo, multiple failed MFA.
• Control posture: MFA disabled, legacy auth used, unmanaged device.
• Threat context (if you have it): known suspicious IP ranges from your own detections.

Make it operational:

• Define score bands (example: Low/Medium/High/Critical) rather than debating exact numbers.
• Set routing rules: which band creates a SOC ticket, which requires escalation, which triggers containment actions.

What auditors want: a written rationale for why certain identity events score higher, plus examples of scored events.

5) Attach score thresholds to an investigation and response workflow

Risk scoring without action fails in practice. Your workflow should include:

• Triage steps: validate identity, confirm geo/device, check recent password reset, check recent access to high-risk apps.
• Containment actions (pre-approved): force password reset, revoke sessions/tokens, require re-auth, disable account, remove privileged roles.
• Escalation rules: privileged identities, repeated anomalies, suspected compromise.
• Close-out criteria: false positive reason codes, confirmed incident steps, lessons learned updates to scoring logic.

Workflow artifact: a one-page “Identity Risk Event Runbook” with decision points and evidence to capture.

6) Operationalize tuning and governance

Set governance so the scoring model does not rot:

• Assign owners: security operations for tuning, IAM for configuration, GRC for control evidence.
• Track metrics qualitatively (trend-based): alert volume, false positives, time-to-triage, repeat offenders.
• Review recurring false positives and document tuning decisions with change control.

If you need a system of record to manage evidence and map it back to HICP Practice 6.5, Daydream can act as the control workspace where you store the scoring methodology, log source coverage, runbooks, and investigation samples in one audit-ready place.

Required evidence and artifacts to retain

Keep evidence that proves both capability and operation:

1. Identity Analytics Scope and Data Sources

• Inventory of identity systems and log sources
• Data flow diagram or simple architecture sketch
• Confirmation that logs are retained and searchable

2. Detection Use Case Catalog

• List of anomalies covered (including impossible travel and unusual access patterns) (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Data prerequisites per use case
• Mapping to responsible team/runbook

3. Risk Scoring Methodology

• Scoring factors and weight rationale (high-level is fine)
• Score bands and routing thresholds
• Change log for tuning decisions

4. Runbooks and Ticket Evidence

• Runbook for identity risk events
• Samples of alerts/tickets showing: event details, risk score, triage notes, actions taken, closure reason

5. Access Governance Linkage

• Evidence that privilege changes and break-glass usage are monitored and scored
• Exception records if some systems cannot provide needed telemetry

Common exam/audit questions and hangups

• “Which identity systems are covered, and which are out of scope? Why?”
• “Show me an example of an anomalous identity event and its assigned risk score.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• “What triggers an investigation versus informational logging?”
• “How do you detect impossible travel, and what do you do when it happens?” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• “How do you prevent alert fatigue from breaking the process?”
• “How do you handle third-party identities or shared accounts?”

Hangup to expect: teams can demonstrate detections but cannot explain scoring logic or show consistent investigation outcomes.

Frequent implementation mistakes and how to avoid them

1. Scoring is opaque (“the tool does it”).
   Fix: write down scoring factors you rely on and keep example events with explanations.

2. No coverage of privileged identity events.
   Fix: explicitly add privilege changes, admin role grants, and break-glass usage into the use case catalog.

3. Identity events don’t route into incident workflows.
   Fix: define thresholds that open tickets and create an escalation path for high-risk scores.

4. False positives overwhelm analysts.
   Fix: tune by narrowing to high-signal anomalies first (impossible travel, privilege changes), then expand.

5. Service accounts are ignored.
   Fix: build separate baselines and anomaly rules for non-human identities; interactive login on a service account is often high-risk.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, identity compromise is a common entry path for healthcare incidents; inability to detect anomalous access and prioritize response increases the chance that account takeover becomes ePHI access and reportable events. HICP’s framing ties identity analytics directly to investigation and response through risk scoring. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Practical 30/60/90-day execution plan

First 30 days (establish capability)

• Confirm in-scope identity systems and top applications.
• Turn on and centralize identity logs for IdP/SSO, VPN, EHR admin access, and privileged role changes.
• Publish an initial anomaly use case list (include impossible travel and unusual access patterns). (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Draft the risk scoring methodology and score bands.
• Create the runbook and ticket fields required (risk score, user, app, geo/device, action taken).

Days 31–60 (make it operational)

• Implement detections for the initial use cases.
• Route High/Critical scored events into a tracked queue (SIEM/SOAR/ticketing).
• Run tabletop reviews of a few scored events to validate decision points.
• Start tuning with documented change control and false-positive reason codes.
• Train help desk and IAM on containment steps (session revocation, forced reset, role removal).

Days 61–90 (prove repeatability and audit readiness)

• Expand coverage to remaining critical apps and service accounts.
• Add privileged identity-specific scenarios (new admin, group changes, break-glass).
• Produce an evidence pack: scope, scoring model, use cases, runbook, and investigation samples.
• Establish governance cadence for scoring updates and exceptions.
• Validate that third-party access paths generate identity events and enter the same scoring and triage process.

Frequently Asked Questions

Do we need a dedicated “identity analytics” tool to meet HICP Practice 6.5?

HICP requires the capability: detect anomalous identity access patterns and assign risk scores that trigger investigation and response. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) You can meet the intent with an IdP risk engine, SIEM analytics, or a combination, as long as you can prove scoring and follow-through.

What counts as an “identity-related event” for scoring?

Treat authentication events, MFA activity, session/token actions, privilege changes, and role/group membership changes as identity-related events. The key is that the event is tied to an identity and can indicate anomalous access patterns. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

How do we document risk scoring without exposing sensitive detection logic?

Document scoring factors and banding at a level that explains prioritization (privileged role, impossible travel, unusual device) without disclosing every rule condition. Keep a restricted appendix for deeper logic if needed, and retain scored event examples. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

We have impossible travel alerts, but analysts ignore them. Are we compliant?

Probably not. HICP calls for assigning risk scores to trigger investigation and response, so you need thresholds, routing, and evidence that high-risk events were handled. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

How should we handle third-party access (MSPs, support vendors) in identity scoring?

Bring third-party identities into the same telemetry and scoring pipeline, then add context (approved source networks, expected hours, privileged scope). If you allow shared accounts, document the exception and add compensating monitoring. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

What evidence is most persuasive in an audit?

A clear scope of identity systems, a written scoring methodology, and a small set of investigation samples that show: anomaly detected, risk score assigned, triage performed, actions taken, and closure rationale. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)