What 164.308(a)(1)(ii)(D) information system activity review requires
The required specification asks covered entities and business associates to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports. It sits under the security management process standard in 164.308(a)(1) and is a required implementation specification, not an addressable one, so you cannot decide it is inapplicable. Picture the compliance lead whose audit is coming: the logs exist and are retained, but nobody can show a dated record of someone reading them, deciding what mattered and acting on it. That gap is the thing an assessor will test. This specification is the administrative counterpart to the audit controls standard in 164.312(b), which requires the mechanisms that record and examine system activity. The technical standard asks whether the logging exists; this specification asks whether a person or process regularly looks at what was recorded. The risk it targets is inappropriate access that goes unnoticed. In the January 2025 proposed rule, HHS cited an OCR investigation of a large provider where employees inappropriately accessed patient account information for six months, and the ePHI of more than 12,000 patients was sold to an identity theft ring (90 FR 898). Logs were likely recording that access. Nobody was reviewing them.
That is why logging alone does not satisfy the specification. Enabling audit logging on an EHR, a file share or a self-hosted application produces data, but the rule requires procedures to review that data regularly. Your procedures should name the log sources in scope, the reviewer role, the review cadence you chose from your risk analysis, what a reviewer looks for, and how findings move into incident response. The rule does not set a review frequency or name tools, so those choices are yours to justify. Confirm with your security official which logs are reviewed, how often, and who signs off, and keep the dated review records as evidence. Open-source platforms can collect and flag events, but they produce alerts for a person to triage, not a completed review by themselves.
Which systems, logs and teams fall under activity review
Activity review only works when the scope matches where ePHI actually lives and moves. The decisions below determine which systems, log sources and people the review must cover, and each one changes the work an assessor will expect to see documented.
Systems that hold or touch ePHI
Start from the risk analysis inventory, not from the list of servers you happen to monitor. Any application that creates, receives, stores, transmits or processes ePHI belongs in scope, including systems that only pass ePHI through, such as integration engines and file transfer services. Record each system in the review procedure with its owner, so the reviewer knows what must be examined. Confirm the inventory is updated when new applications or data flows appear.
Application and database audit logs
Application logs show what users did with patient records, such as views, exports and edits, while database logs show privileged queries and schema changes. Both are needed because an employee can read records through a legitimate application or bypass it with direct database access. Confirm that each log captures the user identity, the object accessed and the time. Where the platform writes audit events to a file, the procedure should name the path and the retention period.
Identity provider and authentication events
Sign-in records, failed log-ins, password resets and multi-factor enrollment changes show who got into the environment and how. Reviewing them supports the log-in monitoring addressable specification as well as activity review. Check whether the identity provider logs are forwarded to the same place as application logs, so one reviewer can connect a suspicious log-in with the records accessed afterward.
Endpoints and workstations
Workstations and laptops that open ePHI generate records of logins, process execution, removable media use and security tool alerts. Scope decisions here depend on whether staff can save ePHI locally or only access it through managed systems. The review should cover endpoint detections that relate to ePHI access, and the procedure should say which endpoint classes are included and which are excluded with a documented reason.
Cloud control planes and admin tools
Administrative actions in cloud consoles, hypervisors, container platforms and backup tools can change or expose ePHI without touching the application itself. Control plane logs, privileged role assignments and changes to storage permissions should be reviewed. Confirm that administrator activity in these tools is logged and that the logs are protected from the administrators whose actions they record.
Third-party and hosted systems
A vendor that hosts ePHI does not remove the covered entity's or business associate's duty to review activity, but the review may depend on what the vendor provides. Decide which logs the contract makes available, how often they are delivered and who reviews them. Where the vendor keeps the logs, document the access you have and the request process. Business associate terms should be checked against the scope of activity review before the work begins.
How the review process fits with audit controls and incident response
The split is simple to state and easy to get wrong. The audit controls standard in 164.312(b) requires the mechanisms that record and examine system activity, so it is about generating the records. This specification, 164.308(a)(1)(ii)(D), requires procedures that regularly review those records. A system can log everything and still fail this specification if nobody reads the logs on a defined schedule, keeps no evidence that the review happened, or cannot say who reviewed what. Assessors test both halves separately: they ask for the log configuration under 164.312(b), then ask for proof that a named role reviewed audit logs, access reports and security incident tracking reports at the frequency the organization's own procedure sets. In a self-hosted stack, the logging layer might be Nextcloud's admin_audit app writing to audit.log, OpenBao audit devices writing JSON request logs, or a Wazuh deployment writing alerts.json. The reviewer needs to know which of these sources feeds which system holding ePHI.
A reviewer looks for patterns and gaps, not only for alerts. Useful questions include whether access to a patient record spiked outside normal work patterns, whether an account accessed records it has no treatment or operational reason to touch, whether log-in failures cluster, whether audit logging stopped on a host, and whether privileged changes appear in the log without a matching change ticket. Tools such as OpenSearch Security Analytics or Wazuh can flag matches against detection rules, but the review must still record what was examined, what was dismissed and why. A finding becomes a security incident under 164.308(a)(6) when it is a suspected or known security incident, meaning an attempted or successful unauthorized access, use, disclosure, modification or destruction of information or interference with system operations. Confirm your own incident definition and escalation path with counsel and your security official, because the threshold for a breach assessment is set separately by the breach notification rules.
How to implement activity review step by step
This sequence turns the activity review requirement into a working cycle: a defined scope, a current inventory of log sources, a written procedure, named reviewers, and a record of every review and the exceptions it raised.
Define the review scope and objectives
Start by deciding which systems that create, receive, maintain or transmit ePHI fall inside the review, and what the review must answer, such as unauthorized access, failed log-ins and changes to access rights. The security official or the risk analysis owner drafts the scope list, and leadership approves it. The step is complete when the scope list names each in-scope application, database, endpoint group and cloud tenant, and ties each one back to the risk analysis.
Build the log source inventory
Identify every place activity is recorded for the in-scope systems, including application audit logs, operating system logs, directory and identity logs, database audit trails, VPN and remote access logs, and security tool alerts. For each source, record the owner, where the log is stored, its retention location and whether it reaches a central point. The platform engineering lead and system owners complete the inventory, and the security official signs off once every in-scope system has at least one named source.
Write the activity review standard operating procedure
Document how reviews happen: which records are examined, how often, which events trigger immediate follow-up, how a reviewer records findings, how a suspected incident is passed to the incident response procedure, and how the review itself is logged. The procedure should reflect the risk analysis rather than generic settings. The security official approves the SOP, and the step closes when the document is versioned, distributed to reviewers and cross-referenced to the audit controls and security incident procedures.
Configure logging and alert rules to support review
Enable the audit settings the inventory calls for, confirm that logs carry user, time, action and outcome, and set alert or correlation rules for the events the SOP names. Test each source by generating a known event and confirming it appears where reviewers will look. Open-source platforms such as Wazuh, OpenSearch Security Analytics and the audit logging features of applications like Nextcloud can support this work, but teams should confirm each capability in their own version. The step is complete when test events are visible and alert routing has been verified.
Name reviewers and train them on the procedure
Assign a named reviewer roster with a backup for each log source, and confirm that reviewers have access to the records without holding the administrative rights they audit. Reviewers should be trained on the SOP, the escalation path and how to recognize access patterns that matter for ePHI. The security official signs off on the roster, and the step produces a training record for each reviewer and a documented separation between reviewers and the administrators whose activity they check.
Run the first review and record the results
Carry out the first review cycle exactly as the SOP describes, covering the agreed scope and time period. The reviewer documents what was examined, what was found, which events were judged benign and why, and what was escalated. Each finding that needs action is opened in the exception log with an owner and a closure record. The first review record, signed by the reviewer and countersigned by the security official, is the evidence that the process works in practice.
Maintain the exception log and repeat the cycle
Keep a running exception log that tracks every anomaly, its investigation, its disposition and any change made to systems, access or procedures as a result. Repeat the review at the frequency the SOP sets, and review the SOP itself when the risk analysis, systems or threats change. The security official reviews the exception log periodically, and the evaluation process under 164.308(a)(8) can use these records as input. The cycle is working when records are consistent across periods and open exceptions have documented owners.
Open-source tools that produce and surface activity records
Nextcloud's admin_audit app records administrative and security-relevant events, such as configuration changes and file operations, and writes them to a dedicated audit log. Its output is the raw material for the review specification: if nobody reads the file, or the file does not capture the events the risk analysis identified, the review cannot meet the requirement. Logging is configured in the server's logging settings, where the log destination can be left at the default data directory location or pointed to a separate path through the logfile_audit setting.
- What it records: Additional event information written to audit.log in the data directory, or to the path set with logfile_audit.
- What it does not do: It does not review or alert on the entries. Someone or something must read them on a defined schedule.
- Storage location: Moving the log to a separate path can help with access restriction and retention, but the new location must be included in backup and access control design.
- Coverage check: Confirm which events the app logs in your release and whether they include access to ePHI files, sharing changes and admin actions.
- Integrity: Confirm who can edit or delete the file and whether copies leave the server.
Confirm the exact event list, log rotation behavior and file permissions in your deployed version against the Nextcloud admin manual before writing the review procedure.
OpenBao audit devices record every API request and response that passes through the server, including errors. That makes them a strong source for showing who requested secrets, encryption keys or configuration and when. The records are structured JSON, which suits automated parsing, but the log also contains request detail that must be protected. OpenBao hashes most sensitive values with HMAC-SHA256 so the log can show that a value was used without revealing it.
- What it records: A JSON entry for each API request and response, including errors, with most sensitive values hashed using HMAC-SHA256.
- What it does not do: Hashing does not make the log free of sensitive information. Some fields may remain visible, so confirm the field-level behavior for each audit device you enable.
- Availability: An audit device that cannot write its log can block requests, so plan for the log destination's capacity and failure behavior.
- Review input: Pair the log with a regular review of secret access patterns, such as reads from unexpected identities or unusual volumes.
- Retention: Set how long entries are kept according to the risk analysis and your six-year documentation practice.
Confirm the enabled audit devices, their failure behavior and the fields each one hashes in your configuration by checking the OpenBao audit documentation and testing with a sample request.
OpenSearch Security Analytics and Wazuh turn raw logs into findings and alerts that people can review. Security Analytics runs detectors that match ingested logs against Sigma rules, records matches as findings with a rule, log type and severity, and uses a correlation engine to link findings across log types. Wazuh decodes collected logs, compares each event against more than 3,000 built-in rules and decoders plus custom rules, and writes matching alerts to local files for review in its dashboard. Together they give the review specification a reviewable queue rather than a pile of files.
- OpenSearch Security Analytics: Detectors match ingested host, network and cloud logs against prepackaged or custom Sigma rules, record findings, and can send alerts to channels such as Slack or email.
- Wazuh ruleset: Each event is compared against over 3,000 built-in rules and decoders plus custom rules, with alerts mapped to MITRE ATT&CK.
- Wazuh output: Matching alerts are written to alerts.log and alerts.json and forwarded to the Wazuh indexer for dashboard review.
- What they do not do: Neither tool decides whether a finding is a violation or an incident. Triage, disposition and sign-off remain human tasks that must be recorded.
- Rule tuning: Default rules may not match your environment, so document which rules are enabled, suppressed or customized and why.
Confirm which rulesets, Sigma rules and alert channels are active, who triages findings, and how those decisions are recorded before presenting these tools as meeting the review requirement.
How an assessor tests activity review
This table compares what an assessor checks for 164.308(a)(1)(ii)(D), the test step, the evidence requested and the findings that most often appear. Read each row as a question the assessor will ask, then confirm your own records can answer it before the review starts. The main takeaway is that a log existing is not enough: the assessor wants proof that someone reviewed it, on a set schedule, and acted on what they found.
| Assessor test | Evidence requested | Common finding |
|---|---|---|
| Confirm the logging mechanism is enabled and covers in-scope systems | System inventory of ePHI systems, audit configuration exports and a list of sources forwarding logs to the review tool | Logging is off on a database, file share or SaaS tenant that holds ePHI but was left out of the scope list |
| Request the written review procedure | Dated information system activity review procedure naming the logs, the reviewer role, the frequency and the escalation path | A procedure exists in draft or was never approved, or it does not name which logs are reviewed |
| Sample review records across the review period | Dated review records, such as signed checklists, ticket entries or dashboard review logs, for several sample dates across the period | Reviews appear only for the weeks before the assessment, leaving gaps across the rest of the period |
| Test whether reviews cover access reports and incident tracking | Access reports for ePHI systems and the security incident tracking log, with proof the reviewer examined both | Review records mention only system health or uptime and never show access reports or incident records |
| Check that identified anomalies were followed up | Tickets or case notes linking each flagged event to an investigation, a closure decision and any sanction or corrective action | Anomalies are noted in the review but no investigation, outcome or closure is recorded |
| Check reviewer independence and frequency | Documented reviewer assignment, evidence the reviewer does not administer the reviewed systems, and the frequency set in the risk analysis | The system administrator reviews their own privileged activity, or the frequency in the procedure does not match the risk analysis |
| Compare review scope with the risk analysis | Risk analysis entries for ePHI systems and the matching log sources and review frequency | Systems rated high risk in the risk analysis receive the same or less review than low-risk systems |
Which evidence shows that activity review happens
An assessor testing 164.308(a)(1)(ii)(D) wants proof of three things: that a documented process exists, that the logs feeding it are complete, and that people actually reviewed the records and acted on what they found. The cards below cover the artifacts that show each part, and each one needs to stay current between audits, not just be assembled before one.
Written review procedure
The standard operating procedure states what is reviewed, how often, by whom, which tools are used, what counts as a finding, and how escalation works. NIST SP 800-66 Rev. 2 treats developing this procedure as a key activity for the standard. Review it at least annually and after any change to logging tools, log sources or staffing, and record the approval date and version so an assessor can see the procedure was current when the reviews happened.
Log source inventory
A current list of every system that produces activity records for ePHI, including applications, databases, identity providers, file shares, endpoints and cloud accounts, with the log type, retention location and owner for each. The inventory is what proves the review covers the whole environment. Check it against the asset list whenever a system is added, retired or moved, because a source missing from the inventory is a gap no review will catch.
Dated review records
Each review leaves a record with the date, the reviewer's name, the log sources and period covered, the outcome, and any findings. A blank checkbox or a shared log-in does not satisfy this. Store the records in a system that prevents silent edits, and confirm that reviewers are not reviewing their own administrative activity without a second person checking it.
Access report extracts
Periodic exports of who accessed which ePHI systems, including privileged accounts, failed log-ins and access changes, are the most direct evidence a reviewer examined access activity. Keep the query or filter used to produce each extract alongside it, so the same report can be regenerated during an audit. Compare extracts against current workforce status to flag accounts that should have been removed.
Alert triage tickets
When a detection rule fires, the triage ticket shows who looked at it, what they concluded, and what they did. Tickets should link to the alert and the underlying log entries. Tuning changes that suppress or adjust rules need their own approval record, since an assessor will ask whether a noisy rule was silenced to make the review easier.
Exception and follow-up logs
Findings that need more than a ticket, such as unexplained access or a missing log source, belong in a follow-up log with an owner, a due date and a closure note. This log shows that review leads to correction. Open items that age without closure are the pattern OCR investigators look for, so review the log at each review cycle and record any overdue items with a documented decision.
Log retention settings
Configuration evidence showing how long activity records are kept and where they are stored proves that records exist to review. Export the actual settings from each platform rather than relying on policy text. For example, a Nextcloud admin_audit configuration or a Wazuh alert output path can be captured in a dated screenshot or configuration file. Retention and the six-year documentation rule in 164.316 are different requirements, so confirm which period your policy applies to each record type.
What meeting activity review costs in money and effort
This table breaks the cost of running information system activity review into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the questions in the final column when requesting a quote. The main takeaway is that open-source tooling removes license spend but not the recurring reviewer time, detector tuning and evidence upkeep that the specification actually requires.
| Cost component | One-time or recurring, and who is paid | What drives it up or down, and what to ask for in a quote |
|---|---|---|
| Tooling or licenses | Recurring if commercial, paid to vendors. Self-hosted open-source platforms such as Wazuh, OpenSearch and Nextcloud carry no license fee, but hosting still costs money. | Log volume, number of sources and whether support subscriptions are bought. Ask whether any component is commercially licensed and what support tier is assumed. |
| Engineering time to configure logging | One-time for initial setup, then recurring for changes. Paid to internal staff or an implementation partner. | Number of systems holding ePHI, mix of platforms and how much logging is already enabled. Ask which audit sources are configured, which are left to the client, and how each is verified. |
| Detector and rule tuning | Initial one-time work, then recurring as systems change. Paid to security engineers or the partner. | Volume of false positives and the rules chosen for the risk analysis. Ask how many rules are delivered, who tunes them and how tuning changes are recorded. |
| Recurring reviewer time | Recurring. Paid to the staff member or team who reviews logs, access reports and incident tracking reports on the schedule the entity sets. | Review frequency, number of alerts and the staffing model. Ask who performs each review, how long the review is expected to take and who signs off. |
| Evidence upkeep | Recurring. Paid to the organization, with possible support from a partner. | How often review records are produced, and how many reviews are documented. Ask which review logs, sign-offs and follow-up tickets the partner will hand over. |
| Storage and retention | Recurring, paid to whoever hosts the infrastructure, such as the client's cloud account or data center. | Retention period set by the entity's policy and documentation rules, and volume of records. Ask how long audit records are kept and where they are stored. |
| External testing or review | Optional, one-time or periodic. Paid to an outside assessor or security testing firm. | Scope of the review and whether independent validation is wanted. An outside review can test the process but cannot issue a HIPAA certification. Ask what the review covers and what it cannot show. |
| Auditor or OCR sampling response | Occasional, paid to staff time to produce records on request. Auditors and OCR are not paid by the entity. | How well records are organized and how many systems are in scope. Ask whether the evidence can be retrieved quickly for a sample of review records. |
Which parts of activity review are worth outsourcing
A partner can take on much of the mechanical work behind 164.308(a)(1)(ii)(D), but the decisions that make the review meaningful must stay with the covered entity or business associate. The work that outsources well is the setup: confirming that audit logging is enabled on each ePHI system, forwarding those logs to a central store, writing the standard operating procedure that describes what is reviewed and how often, and packaging the resulting records as evidence. For example, a partner might configure the admin_audit app in Nextcloud to write to a dedicated audit.log path, or set up OpenBao audit devices so that every API request and response is recorded, then document where each log lives and who can read it. Detector tuning in OpenSearch Security Analytics or custom rules in Wazuh also fits here, since the partner can draft rule sets and suppression logic for the organization to approve.
What stays with the organization is the judgment. Someone on the workforce must decide which alerts are investigated, which access reports are reasonable, and whether a pattern in the logs points to a security incident under 164.308(a)(6). The security official remains accountable for the review under 164.308(a)(2), and that accountability cannot be delegated to a vendor. Sign-off on exceptions, such as a rule that is muted because it produces known noise, should be recorded by an internal owner with a reason and a review date. Before engaging a partner, ask for a written split of responsibilities, confirm who receives alerts out of hours, and check that the partner's staff will not hold standing access to ePHI beyond what the scope requires. Confirm also whether the review cadence is set by your own risk analysis, since the rule requires the review to be regular without fixing an interval.
Scope and cost follow from the same split. Setup work is usually a one-time project, while the review itself recurs and draws on internal time whether or not a partner is involved. Costs rise with the number of systems, log sources and custom detectors, and with how much tuning the environment needs. Ask any partner to state in writing which deliverables are configuration, which are documentation, and which are ongoing support, and to name who performs each. A partner can prepare the records an assessor will ask for, but it cannot issue an audit opinion or attest that the organization complies with the Security Rule.
Where activity review usually fails in practice
Most activity review failures are not missing logs. They are logs nobody owns, reviews nobody can prove happened, and sources that never reached the review at all. The cards below cover the gaps assessors most often find and the fix for each.
Logs enabled but never read
Auditing is switched on across the environment, yet no one has a scheduled task to look at the output. Under 164.308(a)(1)(ii)(D) the rule asks for a regular review of the records, so the logs alone do not satisfy the specification. Fix it by listing each log source, the review frequency for each one, and the person who reads it. Check that the review produces findings or a documented clean result, not just a filled log store.
No defined reviewer
Reviews often rely on a general statement that 'IT monitors logs,' which leaves no one accountable when a review is skipped. Assessors look for a named role, a backup for absences, and the authority to escalate findings to the security official. Write the reviewer assignment into the procedure and confirm the reviewer has read access to every log source in scope. Reviewers who also administer the systems they audit should be flagged as a conflict in the risk analysis.
Review without a record
A review that happened but left no trace is hard to defend. Auditors ask for evidence that a specific review took place, what was examined, what was found and what was done about it. A short signed or ticketed record for each cycle, listing the sources reviewed, the time window and any alerts closed, provides that proof. Keep these records with the policies required under the documentation standard so they can be produced on request.
Scope missing cloud or SaaS sources
On-premises servers are reviewed while identity provider sign-ins, cloud control plane events, email platforms and collaboration tools are not. ePHI often lives in those systems, so the review is incomplete even when it runs on schedule. Build an inventory of every system that stores, processes or grants access to ePHI, including hosted and SaaS services, and map each one to a log source. Confirm with the cloud or SaaS provider which audit events are available and how long they are kept.
Alerts not linked to incident tracking
Reviewers may notice suspicious activity and resolve it informally, so it never reaches the incident record required under the security incident procedures standard. Define a rule that any confirmed concern from a review opens a tracked incident, with the ticket number recorded against the review entry. Test this by picking a sample of review findings and tracing each one to its incident outcome or documented closure reason.
Log retention shorter than the review cycle
If logs roll off before the next review runs, the review cannot examine the period it was meant to cover. This is common when a default retention setting was never changed for a quarterly or monthly review. Set retention so that every log remains available for at least one full review cycle plus time for any follow-up investigation. Document the retention period alongside the review frequency so the two are checked together during the periodic evaluation.
Who does what for activity review
The covered entity or business associate owns this specification. The Security Rule places the duty on the organization, and the security official named under 164.308(a)(2) is accountable for whether reviews actually happen and whether findings are acted on. Staff who perform reviews are part of the workforce and must be trained and authorized for that role.
- Accountability: The security official approves the scope of what is reviewed, how often, and who performs the review.
- Review decisions: Someone with authority decides whether a flagged event is benign, needs investigation, or becomes a security incident under 164.308(a)(6).
- Reviewer independence: Where practical, the person reviewing privileged administrator activity should not be the same person whose activity is being reviewed.
- Records of review: Keep dated evidence of each review, the findings, and the follow-up actions.
- Operating the process: Reviews must run on a schedule the organization sets and keeps, not only after an incident.
Check that your named security official can show a sample of recent review records, including who signed off and what happened to each finding.
An implementation partner such as DeployOpen can configure and document the systems that produce activity records, but it does not own the review decisions or the compliance outcome. Its work is preparing the environment so the organization can run the review and show that it does so.
- System configuration: Enable audit logging in the applications and platforms that hold ePHI, and set log retention and storage so records are not overwritten before review.
- Procedure drafting: Draft the standard operating procedures for the review process, which the organization must approve and adopt.
- Detection and reporting: Set up log collection, alert rules and dashboards that surface access reports and security incident tracking data for reviewers.
- Evidence preparation: Assemble configuration exports, sample review outputs and runbooks so the organization can hand them to an assessor.
- Scope limits: The partner does not decide what counts as an incident and does not sign off on the organization's compliance.
Confirm in the written scope exactly which systems are covered, who receives alerts, and which artifacts the partner will hand over at the end.
An independent auditor, assessor or qualified third party tests the review process and reports on what it found. Only that independent party issues a report or opinion. HHS does not recognize private certifications, and no Security Rule standard requires one, so an assessor's report describes what was tested rather than granting HIPAA compliance.
- Testing approach: The assessor typically samples review records, checks that reviews occurred on schedule, and traces findings to documented follow-up.
- Evidence requested: Expect requests for procedures, audit log configurations, review logs, sample alerts and incident tickets.
- Independence line: An assessor that helped design or configure the controls it later tests should disclose that relationship and may need to limit its conclusions.
- Reporting: The report is issued by the assessor, not the organization or its implementation partner.
- Scope of conclusions: A third-party assessment shows what was examined in a defined period, not that the organization will always comply.
Before engaging an assessor, ask how it handles conflicts when a firm has also implemented the controls under review.
Questions buyers ask about activity review cost and effort
Can we run information system activity review in-house?
Yes, the Security Rule does not require outside help, and the organization owns the obligation either way. The specification asks for procedures to regularly review records such as audit logs, access reports and security incident tracking reports, so the work is mainly a staffing and process question. Your team needs to know which systems produce logs, who reviews them, how often, what counts as a finding and how reviews are recorded. Teams with an existing security operations function often absorb this quickly. Teams without one should ask whether a reviewer can be assigned and sustained, because a review that happens only when someone remembers will not produce useful evidence.
How much effort does a implementation partner remove from activity review?
A partner typically removes the setup work: identifying log sources, configuring collection, writing review procedures, building dashboards and alert rules, and documenting how reviews are evidenced. The organization still performs and signs off on the reviews. Effort drops most when log sources are few, standardized and already centralized, and rises when ePHI sits in many applications, legacy systems or cloud accounts with inconsistent logging. Ask the partner to list each system in scope, the log types it will collect, and which parts of the review it will hand over to your staff, so the division of work is written down before the engagement starts.
What does the review work require from our staff?
Staff need time, defined roles and enough context to judge what they see. In practice this means a named reviewer or rotation, a documented frequency, access to the log platform, and a clear escalation path into incident response when a review turns up something suspicious. Reviewers also need to understand normal activity for each system so they can spot unusual access patterns, such as a workforce member opening records outside their assigned patients. Ask whether the reviewer role is covered during leave and whether the organization has the skills to tune alerts, since noisy alerts consume reviewer time without improving security.
How long does setup take for activity review?
The duration depends on written scope, and no fixed timeline applies to every organization. The main variables are the number of systems that handle ePHI, whether logging is already enabled and centralized, how many log sources must be integrated, and how much tuning the alert rules need. Engagements are usually fixed-scope, so the scope document should state the systems, log types, review procedures and deliverables, and the timeline should follow from that. Ask for a schedule with milestones tied to each system, and for an explicit statement of what the organization must provide, such as credentials, network access and reviewer time.
Do open-source tools satisfy the activity review specification on their own?
No. Tools collect and organize evidence, but the specification requires a regular review process, and that process must be defined, performed and documented by the covered entity or business associate. Platforms such as Wazuh, which compares events against a ruleset and writes alerts for review, or OpenSearch Security Analytics, which records findings from ingested logs, can support the work well. Nextcloud's admin_audit app and OpenBao's audit devices produce records that feed the review. Confirm each tool's capabilities against its current documentation, and then write the procedure that says who reviews what, how often and how exceptions are handled.
Does a third-party assessment prove we comply with activity review?
No. HHS states that no Security Rule standard requires certification, and it does not endorse or recognize private certifications, so a third-party report is not a HIPAA certificate. An outside assessment can test whether your procedures, configurations and review records are consistent and can show gaps before OCR does. OCR decides compliance through its own complaint investigations, compliance reviews and audits. Treat any assessment as a readiness input, and ask the assessor to state exactly what it tested, which periods it covered and what it did not examine.
What drives the recurring cost of activity review?
Recurring cost comes mainly from reviewer time, log storage and retention, platform hosting or licensing, and periodic procedure updates. Storage grows with the number of log sources and the retention period your risk analysis supports. Reviewer time grows with alert volume, so tuning reduces it over time. Platform costs depend on whether you run open-source software on your own infrastructure or buy a commercial service, and your cloud or data center charges apply in either case. Ask any quote to separate one-time setup from recurring operations, and to show how each recurring item scales with the systems in scope.
How DeployOpen prepares activity review for an assessment
DeployOpen plans, implements and documents the activity review process for 164.308(a)(1)(ii)(D) inside your own infrastructure, so the records, review procedures and evidence are in place before an assessor asks for them. We prepare systems and evidence; your organization owns the control, and only an independent auditor or assessor issues any report.
How we scope
- The written scope lists which systems, applications and log sources fall under the activity review process.
- We confirm with you which records count as ePHI system activity, such as audit logs, access reports and incident tracking.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The scope names who in your organization reviews records and how that review is reported to the security official.
How we build
- We configure the audit logging on each in-scope platform so activity records are written and retained for review.
- We deploy log collection and rule-based alerting, such as Wazuh or OpenSearch Security Analytics, where the scope calls for it.
- We tune detection rules to your environment and test that known events generate the expected records and alerts.
- We document the review procedure as standard operating procedures covering cadence, reviewer, escalation and sign-off.
How we hand over
- You receive configuration records, rule inventories and the written review procedure for your own staff to operate.
- Review logs and sign-off records are delivered in a format your assessor can sample, with clear ownership for each review.
- We walk your reviewers through the dashboards, alert queues and escalation steps used in the process.
- Gaps found during setup are listed in the handover with the owner responsible for closing each one.
How we support
- Ongoing support, upgrades and continuous testing of the review tooling are available as a retainer.
- Retainers can cover rule updates after platform upgrades and periodic checks that logs still capture required events.
- Before any assessment, we can help you prepare the evidence package, and you confirm with your assessor what they will request.
- Questions about what an independent assessment can show should go to the assessor, who alone decides what they accept.
