Access Reviews and Recertification

HICP Practice 3.5 requires you to run periodic access reviews where accountable managers recertify that each user’s access still matches their job responsibilities, and you promptly remove or downgrade access that is no longer needed (HICP 2023 - 405(d) Health Industry Cybersecurity Practices). To operationalize it fast, define review scope and cadence, generate authoritative access lists, route attestations to owners, track remediation to completion, and retain evidence.

Key takeaways:

• Make managers explicitly certify access, not just “review a list,” and document decisions and removals (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).
• Your control is only as strong as your identity and access inventory; fix source-of-truth gaps before scaling reviews.
• Audit readiness comes from traceability: who reviewed, what they decided, what changed, and when.

Access reviews and recertification fail in practice for two reasons: the access inventory is incomplete, and the review turns into a check-the-box email with no accountable decision or follow-through. HICP Practice 3.5 is short, but it expects a real governance loop: periodic reviews, manager recertification, and removal of unnecessary privileges so access stays aligned to job responsibilities (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

For a Compliance Officer, CCO, or GRC lead, the goal is simple: be able to prove that access is reviewed by the right owners, at a defined interval, with documented outcomes, and with timely remediation when access is inappropriate. This page translates the requirement into an operating process you can stand up quickly across core systems (EHR, identity provider, email/collaboration, cloud consoles, finance/HR apps, and security tooling) and then expand.

You’ll see what to scope first, who must participate, what evidence auditors ask for, and the mistakes that cause findings (like reviewing the wrong population, excluding admins, or failing to close tickets). Where helpful, examples show how to write decision options and how to package evidence so it survives scrutiny.

Regulatory text

HICP Practice 3.5: “Conduct periodic access reviews and recertification to ensure user access remains appropriate and aligned with current job responsibilities.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operator interpretation (what you must do):

• Run access reviews on a defined schedule.
• Have accountable leaders (typically managers and system/data owners) recertify access as appropriate for each user’s current role.
• Revoke or reduce access that is unnecessary, inappropriate, or outdated, and document that remediation. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Plain-English interpretation of the requirement

You need a repeatable process that answers four questions for each in-scope system:

1. Who has access? (complete list of users, including service accounts and privileged/admin roles)
2. What do they have? (roles, groups, entitlements, and any elevated permissions)
3. Who approved it and who re-approved it? (manager/system owner recertification)
4. What changed after the review? (removals, downgrades, exceptions with justification)

A “review” without a recorded decision and a closed remediation loop does not meet the intent of recertification.

Who it applies to

Entity types

• Healthcare organizations (providers, payers, integrated delivery networks) (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Health IT vendors and other organizations that build or operate systems handling healthcare workflows or data (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operational contexts where auditors focus

• Systems with sensitive data or operational impact: EHR/EMR, patient portals, billing, IAM/SSO, cloud management planes, security admin consoles, and workforce identity stores.
• Privileged access: domain admins, cloud admins, database admins, security tooling admins, break-glass accounts.
• Role changes and offboarding: merges, restructures, contractors rolling off, temporary access that never expires.
• Third-party access: external support, outsourced billing, managed service providers, and implementation partners. The same recertification logic applies: access must be reviewed and either affirmed or removed.

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

1) Define the review policy (scope, owners, cadence)

Create a short “Access Review & Recertification Standard” that names:

• Systems in scope (start with your highest-risk apps and your identity provider)
• Populations (employees, contractors, third parties, service accounts)
• Access types (roles/groups, direct entitlements, local accounts, API keys where applicable)
• Reviewers:
  • Line managers recertify user access based on job responsibilities
  • System owners validate role design and least-privilege alignment
  • Security/IAM runs the process and validates completion
• Decision outcomes: Approve/Recertify, Remove, Reduce, Correct role, Exception (with reason and expiry)

Write the cadence as an operational choice that fits your environment. The key is that it is defined, followed, and evidenced (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

2) Build an authoritative access inventory per system

For each in-scope application, document:

• System name, owner, and data sensitivity (internal classification is fine)
• How to extract access: report, API export, directory group membership, app admin export
• Required fields: user identifier, display name, manager, role/group, last login (if available), account type (human/service), and whether privileged

If the access report lacks manager attribution, fix it by mapping identities from your HR system and identity provider. Most recertification failures trace back to poor identity linkage.

3) Normalize access into “reviewable units”

Managers cannot responsibly certify a spreadsheet of cryptic permission strings. Convert entitlements into clear items:

• “EHR – Clinical Documentation – Edit”
• “Billing – Refunds – Approver”
• “Cloud – Subscription Owner”
• “Security Platform – Admin”

Where role design is messy, start by reviewing high-risk roles first (admins, financial approval, patient record export).

4) Run the recertification workflow

Use a controlled workflow (ticketing, GRC tool, or an access governance tool). Minimum workflow requirements:

• Reviewer receives a list of direct reports (and any delegated accounts) with current access
• Reviewer must record a decision per user (or per entitlement) with date/time stamp
• Non-responses escalate to the reviewer’s management chain
• The system tracks completion status and retains an immutable record of attestations

Practical decision prompts that drive action:

• “Recertify: Access matches current duties”
• “Remove: User no longer needs access”
• “Change: Move user to standard role X”
• “Exception: Keep access for reason Y until date Z”

5) Remediate and close the loop

A review is not complete until remediation is complete.

• Convert “remove/reduce/change” decisions into access change tickets with assignees and due dates.
• Validate completion by re-running the access report or capturing before/after evidence.
• Record exceptions with an owner, business justification, compensating controls (if any), and a re-review trigger.

6) Add quality checks (what separates “performed” from “defensible”)

Build a small QA sampling step:

• Confirm privileged accounts were included
• Confirm terminated users are not present
• Confirm a subset of removals actually took effect in the system
• Confirm exceptions are time-bound and re-reviewed

7) Operationalize for third-party access

Treat third-party identities as first-class citizens in the review:

• Tag accounts as third party and map to a sponsor (internal owner)
• Require sponsor recertification
• Require expiry dates for access where feasible
• Ensure offboarding triggers remove third-party access promptly when engagement ends

Where Daydream fits (earned, practical)

If your bottleneck is compiling clean access lists across systems and routing them to the correct reviewers with follow-ups and evidence packaging, Daydream can streamline the workflow: ingestion of access exports, reviewer assignments, escalation tracking, and a single evidence bundle per cycle that maps decisions to completed remediation. The control still needs defined ownership and scope, but the operational drag drops once the review pipeline is centralized.

Required evidence and artifacts to retain

Keep artifacts in a single “Access Reviews” evidence folder by review cycle and system:

Governance

• Access Review & Recertification policy/standard referencing HICP Practice 3.5 (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• System inventory and scope statement (systems, populations, privileged access definition)
• RACI or responsibility mapping (IAM, managers, system owners, security)

Execution evidence ¹

• Access population report export (dated)
• Review assignment list (who reviewed what)
• Attestation records (reviewer identity, timestamp, decision outcomes)
• Exception register entries (justification, owner, expiry/review date)
• Remediation tickets and closure proof (screenshots, change logs, before/after exports)
• Completion report (coverage, non-responders, escalations)

Quality assurance

• QA sampling checklist and results
• Evidence of follow-up for overdue reviewers and overdue remediation

Common exam/audit questions and hangups

Expect questions like:

• “Show me the last completed access recertification for your EHR and your identity provider.”
• “Who is accountable for certifying access: IT, security, or business managers?”
• “How do you ensure access aligns to current job responsibilities after transfers?”
• “Are privileged accounts reviewed separately or with additional scrutiny?”
• “How do you handle service accounts and shared accounts?”
• “Show evidence that removals identified in the review were actually executed.”

Hangups that trigger findings:

• Incomplete population (admins or third parties excluded)
• “Reviewed” but no per-user decisions recorded
• No remediation tracking, or remediation not completed
• Exceptions without justification or without re-review

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating recertification as an email sign-off	No traceability; no per-user decision	Use a workflow that records decisions per user/entitlement with timestamps
Reviewing only HR roster, not actual system access	Misses local accounts, stale entitlements	Always start from system-of-record access exports, then map to HR/IdP
Excluding privileged roles because “security already monitors them”	Leaves the highest-risk access uncertified	Put admins and break-glass accounts in scope with explicit owner recertification
No exception discipline	Exceptions become permanent	Require a written reason and a re-review trigger for each exception
Failing to tie remediation back to review outcomes	You can’t prove the control worked	Link each removal decision to a closed ticket and post-change validation

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. Operationally, weak access recertification raises the likelihood of unauthorized access through role drift, stale accounts, and excessive privileges. Those failures typically show up during incident response and post-incident investigations as preventable contributors, and they also create audit findings because the organization cannot prove access remained aligned to job responsibilities (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum defensible process)

• Name an executive owner (IAM/security) and confirm manager accountability for recertification.
• Pick a small initial scope: identity provider + one high-impact clinical or financial system.
• Document review procedure, decision outcomes, and evidence checklist.
• Generate first access exports and run a pilot recertification with a small management group.
• Open remediation tickets for removals and track them to closure.

Days 31–60 (expand scope and harden evidence)

• Add privileged access (cloud console, security admin tools) and third-party accounts to scope.
• Introduce escalation for non-responses and overdue remediation.
• Create an exception register with required fields and owner sign-off.
• Add QA sampling and document results.

Days 61–90 (operate at scale)

• Expand to remaining tier-one systems and standardize role naming for reviewability.
• Integrate joiner/mover/leaver signals so transfers and terminations feed access changes.
• Produce a repeatable evidence pack per cycle with: access list, attestations, remediation closure, and exceptions.
• If tooling is the bottleneck, implement a centralized workflow (for example, Daydream) to automate assignments, reminders, and evidence packaging.

Frequently Asked Questions

What counts as “periodic” for access reviews under HICP Practice 3.5?

HICP Practice 3.5 requires that you define and follow a recurring schedule, but it does not prescribe a fixed interval in the provided text (HICP 2023 - 405(d) Health Industry Cybersecurity Practices). Pick a cadence that matches system risk and prove you executed it consistently.

Do managers have to recertify, or can IT do the review?

The intent is recertification against job responsibilities, which typically requires manager or business owner accountability (HICP 2023 - 405(d) Health Industry Cybersecurity Practices). IT/security can run the process and provide reports, but someone who understands duties must attest.

How do we handle service accounts and shared accounts?

Put them in scope and assign an accountable owner (system owner or application team). Recertify purpose, permissions, and whether the account is still required, then document compensating controls where interactive use is unavoidable.

What evidence is most persuasive to auditors?

Auditors want traceability: dated access exports, named reviewers, timestamped decisions, and proof that removals/downgrades were implemented. A completion report plus linked remediation tickets closes the loop.

We have too many entitlements to review individually. What’s an acceptable approach?

Start with role-based reviews and focus on high-risk roles, then iterate toward cleaner role design. If you group entitlements, document the grouping logic and make sure reviewers understand what each role grants.

How should we cover third-party access in recertification?

Treat third parties like any other identity population: include them in access exports, assign an internal sponsor, and require sponsor recertification. Where possible, require time-bounded access and re-review when the engagement changes.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices