How OpenSearch helps meet HIPAA audit controls
A covered entity or business associate that must show it records and examines activity in systems holding ePHI can use OpenSearch as the recording and examination mechanism under 45 CFR 164.312(b). The standard also depends on activity-review procedures and policy, so OpenSearch covers only part of what an auditor will ask to see. The rule accepts hardware, software or procedural mechanisms, so the record-keeping can come from OpenSearch while the review process is written and carried out by people. Start by listing every information system that contains or uses ePHI, including systems your team may not think of as clinical, and decide which of them feed the cluster. Treat the cluster as one component of the audit control.
The wording of 45 CFR 164.312(b) is short. It requires mechanisms that record and examine activity in information systems that contain or use ePHI, and it has no separate implementation specifications. Appendix A to Subpart C marks the standard as required, so an entity cannot treat it as addressable and decide to skip it. NIST SP 800-66 Rev. 2, the NIST resource guide for implementing the Security Rule, breaks the work into four key activities: determine the activities to audit, select tools, develop the activity review and audit policy and procedures, and implement the review process. OpenSearch answers the tooling step. The other three are decisions your team has to document, and they determine what the cluster must capture. HHS lists the NIST guide as informational, so it guides your design without setting the legal requirement.
No HIPAA certification exists for this standard. HHS states in its 2003 FAQ that no Security Rule standard requires an entity to certify compliance, and that private certifications do not stop HHS from later finding a violation. DeployOpen does not issue audit reports, attestations or certifications. What we prepare is the system and the evidence: configured audit logging, role-based access to the logs, documented review procedures and a record of how each control was tested. The HHS Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits, and your evidence is what those reviews will examine.
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898). The proposal would redesignate this standard as audit trail and system log controls with more specific requirements. As of October 2026, that change was still a proposal, and no final rule had been published, so the current text of 45 CFR 164.312(b) governs your design. Build the logging scope wide enough that more specific requirements would mean adjusting settings and retention rules, not rebuilding the architecture.
Before the design review, confirm three things with your team and the OpenSearch documentation: which audit events the Security plugin's audit log can capture in the version you deploy, where those logs are stored and who can read them, and how long your retention decision requires them to persist. The Security plugin provides role-based access control, field-level security and audit logs, but the available event set and its settings depend on version and configuration, so check them against the exact release you plan to run.
Mapping the audit controls requirement to OpenSearch capabilities
This table maps the audit controls standard and two related technical safeguards to OpenSearch Security features and the configuration decisions behind them. Read each row as a question an assessor may ask: what is recorded, who is identified, how traffic and access are protected, and who reviews the record. The main takeaway is that OpenSearch covers the recording and access parts, while the review step remains a procedure your organization must own.
| Requirement | Platform capability | Configuration |
|---|---|---|
| 164.312(b) audit controls: record and examine activity in systems that contain or use ePHI | OpenSearch Security audit logs record security-relevant events, such as authentication and access activity, and the cluster can ingest those logs and other log sources for storage and search. Ingestion tooling, including OpenTelemetry pipelines, is a separate component to plan. | Enable audit logging in the Security plugin and choose which event categories to capture. Send audit events to a dedicated index or cluster that ordinary application users cannot modify. Confirm the setting names, categories and default behavior for your exact version before you write the configuration into your baseline. |
| 164.312(a)(2)(i) unique user identification: assign and track a unique name or number for each user | The Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. Role-based access control maps authenticated identities to roles that limit what each user can do. | Connect OpenSearch to your identity provider so each person signs in with an individual account. Remove or restrict shared accounts, map directory groups to roles, and keep administrative roles to a named, small set of people. Confirm backend-specific settings, such as token validation for JWT, with the documentation for your version. |
| Transmission and access protection: technical safeguards in 164.312 for ePHI in transit and in the index | TLS protects node-to-node and client traffic. Document-level security and field-level security restrict which documents and fields a role can read, and field masking can hide values from roles that need only partial data. | Enable TLS for transport between nodes and for client connections, and manage certificates under your own PKI. Define roles that restrict documents by query and fields by name for patient-identifying data. Test these roles with representative users, since restrictive filters can change search results and dashboards. |
| 164.312(b) review: examine audit records on a defined basis (gap) | OpenSearch stores and searches the records, and it can run queries or alerting against them. It does not decide who reviews the logs, how often, what counts as an anomaly or how a review is evidenced. These are procedural decisions. | Gap to close in your program: name a review owner, set a review cadence, write alert conditions for failed logins, privilege changes and unusual access to ePHI indices, and keep dated records of each review and its follow-up. Align the procedure with the activity review steps in NIST SP 800-66 Rev. 2, which is informational guidance rather than a binding requirement. |
Evidence OpenSearch produces and how to keep it for auditors
A HIPAA audit controls review asks for proof that activity was recorded and examined, not only that logging was switched on. The cards below list the OpenSearch records that usually form that proof, how to protect them from alteration, and how to tie them to a review procedure your organization can demonstrate.
Security plugin audit logs
The OpenSearch Security plugin can write audit logs covering authentication events and requests to the cluster. Decide which categories you enable, where the logs are written, and which requests must be captured for ePHI indices. Confirm with your own configuration export that the audit settings you documented are the ones actually active on every node.
Index and snapshot records
Index creation, deletion, and snapshot and restore events show when ePHI data was stored, moved, or removed. Retain snapshot repository listings and restore logs so you can show what existed at a given date. Confirm how long your snapshot repository keeps these records, since snapshot retention settings are often shorter than the evidence period an auditor will ask about.
Configuration exports
Export cluster settings, security configuration, and index templates on a schedule and store each export with a date and the change ticket it relates to. These exports let you show what the audit controls looked like at any point in time, which matters when a question concerns a past event rather than the current state. Confirm whether your exports include secrets, and handle them accordingly.
Role and mapping definitions
Roles, role mappings, users, and identity backend settings determine who could read audit records and ePHI in the first place. Keep dated copies of these definitions so you can show who had access to the audit trail itself, not only to clinical data. Confirm that the people who administer OpenSearch cannot silently change the definitions that govern their own access.
Tamper-resistant storage for evidence
Audit records lose value if an administrator can edit or delete them without trace. Ship audit output to a separate store that the cluster administrators cannot write to, and restrict deletion to a documented process. Use write-once or immutable storage where your platform offers it, and check the hash or signature of exported files before they are filed. Confirm the controls with your infrastructure team and record how they were tested.
Review tickets and signed reports
HIPAA asks that activity is examined, so the evidence should include the review itself. Keep the ticket or report that records what was reviewed, the period covered, the findings, who reviewed them, and what was done about each finding. Link each ticket to the review procedure it follows and to the log extracts it examined. Confirm the review frequency and sign-off roles with your compliance lead before the first review is recorded.
Configuring OpenSearch as the audit record for ePHI systems
This sequence takes OpenSearch from scoping to a tested audit record for systems that create, receive, maintain or transmit ePHI. Each step leaves evidence that an assessor or covered entity can review, including the scope decision, the access model, the audit configuration and the detection test record. The order matters because scope and access controls must be settled before logs are routed into the cluster.
Define the systems and activities in scope
The security or compliance lead works with system owners to list every information system that creates, receives, maintains or transmits ePHI, then decides which user activities, administrative actions and system events must be recorded. NIST SP 800-66 Rev. 2 treats determining the activities to audit as the first key activity for the audit controls standard, and its sample questions help structure this review. The step is complete when a scope document names each system, its log sources and the owner who accepted the decision.
Deploy OpenSearch with dedicated cluster manager nodes
The platform team deploys OpenSearch using the installation method it already operates, such as Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages or Ansible. Cluster manager nodes run separately from data nodes, and replicas are placed on separate nodes with shard allocation awareness, as the cluster documentation recommends for availability. Before choosing a release, confirm its maintenance status on the OpenSearch releases page. The step is done when cluster health is reported as healthy and replica shards are allocated across the intended nodes.
Enable TLS and the Security plugin
The platform team enables TLS for node-to-node and client traffic and keeps the Security plugin active before any ePHI-related log data is indexed. Certificate authority, issuance and rotation should be agreed with the team that already runs your PKI, and the plan should state who holds the certificate private keys. Confirm the exact certificate configuration steps against the current Security plugin documentation for your version. The step is complete when plain HTTP connections are refused and a client presenting a trusted certificate can connect.
Configure authentication backends and least-privilege roles
The identity team connects the cluster to your directory through one of the supported backends, such as SAML, OpenID Connect, LDAP or Active Directory, Kerberos or JSON Web Tokens. The security team then defines roles that separate log shippers (write only), reviewers (read only, with document-level or field-level security and field masking where needed) and administrators, and it restricts who may delete indices. User impersonation is limited to named, approved cases. The step is complete when a role mapping export has been reviewed and test accounts are denied the actions their roles do not allow.
Route application and system logs into the cluster
The platform team connects log sources for each in-scope system, including the ePHI application, its database, operating systems, the identity provider, VPN concentrators and the cloud control plane, using the shipper your team already runs. OpenSearch's own ingestion tooling includes OpenTelemetry, which can be used where it fits. Each source should record the user identity, timestamp and originating host so that events can be attributed. The step is complete when one sample event per source is searchable with those fields populated and parsed correctly.
Configure audit logging for the cluster
The security engineer enables the Security plugin audit logging so that OpenSearch records its own authentication events, failed logins, data reads and writes, and changes to roles and users, then sets which categories are captured for this deployment. Audit records should be stored in an index that the ordinary log-writing and reviewing roles cannot modify or delete. Retention periods come from the organization's records policy, not from this guide. The step is complete when a test login, a failed login and a denied read each appear in the audit index with the expected user and outcome.
Write the activity review procedure
The compliance lead writes the review procedure, which NIST SP 800-66 Rev. 2 lists as a key activity alongside the audit policy. It should name the reviewer roles, the review frequency set by the organization's policy, the saved searches and dashboards used, which conditions trigger escalation, and the evidence kept for each review, such as signed review records. The procedure should also say who reviews the reviewers' access. The step is complete when the procedure is approved by the risk owner and a review evidence template exists.
Test detection and review before relying on it
The security team generates controlled test events, such as a failed login, an administrative role change and an unauthorized read of a test record, and confirms that each is recorded, surfaces in the agreed saved search and is handled by the review procedure. Gaps are logged with an owner and a fix date set by the risk owner. The test should be repeated after each OpenSearch upgrade or change to log sources. The step is complete when a signed test record shows every test event was detected and reviewed, which supports the audit controls standard without serving as a certification.
Why deployment choices affect audit reliability
An audit trail is only as reliable as the cluster that holds it. The audit controls standard in 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use ePHI, and a cluster that loses events when one machine fails cannot support that purpose, however well the policies are written. OpenSearch clusters use cluster manager, data, ingest and coordinating node roles, and the cluster documentation recommends dedicated cluster manager nodes, replicas on separate nodes and shard allocation awareness for availability. Those three settings decide whether audit records survive a host, rack or zone failure, so they belong in the design review before the first log is shipped.
Start with the node roles. Dedicated cluster manager nodes keep cluster state and membership work apart from indexing and search load, so a heavy query on a data node is less likely to disturb the component that tracks where audit indices live. Confirm how many cluster manager eligible nodes the quorum requires, then test the loss of one of them in a non-production cluster before go-live. For replicas, a primary and its replica on the same physical host protect nothing when that host fails. Shard allocation awareness, configured with node attributes such as rack or availability zone, tells the cluster to place copies in different failure domains. Ask the team to label every node with its attributes, then use the cluster's allocation explanation output to confirm that each audit index has copies in separate domains.
The regulatory bar may rise. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898). The proposal would redesignate the audit controls standard as audit trail and system log controls with more specific requirements. As of October 2026 that rule is still a proposal, and the latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. The wording could change before finalization, so the proposal should not be treated as settled. It should still shape the design now: keep a record of which events are logged, who can read them, how long they are kept and how completeness is checked, so that a more specific requirement becomes a documentation update.
Enforcement attention has also moved toward availability and intrusion risk. The HHS Office for Civil Rights 2024 to 2025 HIPAA audits reviewed 50 covered entities' and business associates' compliance with Security Rule provisions most relevant to hacking and ransomware. For an audit trail, that focus means an incident is the scenario most likely to be examined, because a reviewer may ask whether logs from the affected period are complete and still available. Plan a test for that case. Illustratively, stop one data node during steady ingestion, confirm that no audit index turns red or loses documents, and confirm that alerts still fire from the remaining nodes. Record the result, the cluster version and the settings used, since that record is the evidence an assessor will ask to see.
No deployment choice produces a HIPAA certificate. HHS states that no Security Rule standard requires certifying compliance and that it does not endorse or recognize private certifications, so reviewers evaluate the documented configuration, the test records and the review procedures behind them. Ask the implementation team to confirm in writing the cluster manager and replica layout, the allocation attributes, the outcome of each failure test and the owner of each review step. DeployOpen can plan, build and document that evidence in your infrastructure, but the assessment itself belongs to your independent auditors.
Questions buyers ask before hiring help with HIPAA audit controls
Does OpenSearch alone satisfy 164.312(b) audit controls?
No. 45 CFR 164.312(b) requires hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI, so compliance depends on a mechanism plus the procedures that run it. OpenSearch can serve as the mechanism. Its Security plugin provides audit logs, and the cluster can store and search the events you collect. What it cannot do is decide which activities to audit, set a review cadence, assign reviewers, or record who examined the logs and what they did about findings. NIST SP 800-66 Rev. 2 lists four key activities for this standard: determine the activities to audit, select tools, develop the activity review and audit policy and procedures, and implement the review process. The audit controls standard has no separate implementation specifications and is marked required in Appendix A to Subpart C. Plan the policy and review steps alongside the cluster build.
Is there a HIPAA certification that covers audit controls?
There is no HIPAA certification for audit controls, so no vendor or consultant can issue one that establishes Security Rule compliance. HHS states in its 2003 FAQ that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation. Enforcement comes from the HHS Office for Civil Rights through complaint investigations, compliance reviews and audits. If someone offers a HIPAA certificate for your OpenSearch deployment, ask what the document covers, who issued it, which framework and scope it assessed, and whether HHS recognizes the issuer. Some organizations commission a third-party assessment against a private framework for their own assurance. That is a business decision. Read the assessor's written scope before you rely on any such report.
What drives the cost of HIPAA audit controls work with OpenSearch?
Labor and infrastructure make up most of the cost, and no figure applies until the written scope is set. OpenSearch is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition, so software licensing is usually not the main cost. Labor covers inventorying systems that hold or use ePHI, choosing log sources, configuring audit logging and access control, writing review procedures and training reviewers. Scope drives effort up: more systems, more log sources and longer retention all add storage, indexing and review work. If a vendor hosts or handles ePHI for you, a business associate contract under 45 CFR 164.314(a)(2)(i) must be in place, and legal review adds effort. One-time costs include design, build and the first policy approval. Recurring costs include storage growth, patching, upgrades and ongoing review time. Ask any quote to separate these items and to state the systems, retention period and reviewer roles it assumes.
How long does a HIPAA audit controls project take with OpenSearch?
Duration depends on the written scope, so no single timeline applies to every organization. The biggest variables are how many systems hold or use ePHI, how many log sources feed the cluster, and whether policy and retention decisions are already made. Legal and privacy approval of the audit policy often sets the pace because it runs on its own review cycle. Infrastructure readiness matters as well: cluster sizing, network paths, identity integration and TLS should be in place before logs flow. DeployOpen plans most engagements as fixed scope, with deliverables and timelines agreed in writing before work starts, so the timeline appears in that document. Ask for milestones that separate design, build, the first review cycle and handover. Also ask which dependencies sit with your team, because those are the ones most likely to move the schedule.
What does our team need to provide for an audit controls project?
Your team supplies knowledge of your systems and the decisions only your organization can make. System owners for each application or platform that holds or uses ePHI confirm which activities matter and where their logs live. Security staff select tools, own the review procedure, and decide who reviews what and how often. Legal and privacy input shapes the audit policy, the retention period and any business associate terms that cover a hosting or support provider. Platform engineers provide environment access, the identity source for administrators, and the storage that will hold the cluster data. Someone with authority must approve the policy and accept the evidence. Name these people and their decision rights in the written scope so the project does not stall waiting for answers. Expect the first review cycle to need the same people again.
Can our internal team build HIPAA audit controls on OpenSearch alone?
Yes, if the team already has Security Rule knowledge and OpenSearch administration skills. Before deciding, confirm these points. The team can map systems that hold or use ePHI and the data flows between them. It knows the audit controls standard, the related administrative safeguards in 164.308 and the documentation requirements in 164.316. It can configure TLS, role-based access control and audit logging for your OpenSearch version. It can design index lifecycle and snapshot-based retention, and it can test restoring log data. It can write the activity review policy and run it on schedule, and it can keep the cluster patched within the maintenance window. Finally, it has a named owner who signs off on evidence. If one item is missing, the gap is often in the review procedure, so plan training or a scoped partner engagement for that part.
Which activities should OpenSearch audit logs capture for systems holding ePHI?
Start with the activities your risk analysis and NIST SP 800-66 Rev. 2 point to, typically authentication events, access to indices holding ePHI, administrative changes and security configuration changes. The OpenSearch Security plugin provides audit logs and documents role-based access control, document-level and field-level security and field masking, so you can record who reached which data. Confirm which audit categories, fields and output formats your OpenSearch version records, because log content needs testing before you rely on it. Decide the retention period and where audit records are stored. Separate reader roles from writer roles, and restrict who can change or delete audit records. Document the list of logged activities and the reason for each entry, then review that list whenever systems or applications change.
Will the proposed HIPAA Security Rule change the audit controls standard?
The proposal would change it, but no final rule exists yet. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), and it would redesignate the audit controls standard as audit trail and system log controls with more specific requirements. As of October 2026, HHS has not published a final rule. The latest Unified Agenda lists the rulemaking under Long-Term Actions, with final action projected for July 2027. The current standard still applies. Design your audit logging so it can be extended, using a documented list of logged activities, defined retention settings and review records that can be reported on. Track the rulemaking through the Federal Register and reginfo.gov, and check with counsel before you commit to fixed log content.
When to involve counsel, your auditor and your business associates
Legal and privacy counsel should decide first whether your organization is a covered entity, a business associate, or both, because that status determines whether the Security Rule applies directly to your OpenSearch cluster and which contracts must exist. Under 45 CFR 164.302, covered entities are health plans, health care clearinghouses and covered health care providers, and business associates are bound by the rule for the ePHI they create, receive, maintain or transmit. Counsel should also confirm whether the cluster will hold ePHI at all. Patient identifiers, record numbers or free-text search queries that reach the index can make audit logs ePHI, so ask counsel to approve the field list before any log source is connected.
Engage an independent auditor early, and define the scope in writing. HIPAA has no certification. HHS states in its 2003 FAQ that no Security Rule standard requires certifying compliance and that HHS does not endorse or recognize private certifications. Any report your auditor issues is an opinion on the controls you chose, not a HIPAA certificate. Agree in advance which OpenSearch components, log sources, time period and evidence are in scope, and ask the auditor to test the audit review procedure and the protection of stored logs, not only whether the cluster exists. HHS OCR's 2024 to 2025 audits review 50 covered entities and business associates, so the evidence should be ready before anyone asks for it. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports.
Business associates and subcontractors need the same attention. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. Inventory every party with administrative access to the cluster, its snapshot repositories and its backups, including managed hosting providers, consultants and vendor support engineers. Confirm that each contract covers where logs and snapshots are stored, who can read them, how long they are kept and how incidents are reported. A gap in one of these agreements can leave the audit trail itself unprotected.
Several adjacent frameworks may apply in parallel, and each needs its own assessment that this topic does not cover. HITRUST CSF is a separate certification scheme, NIS2 Annex I lists healthcare providers and certain medical device manufacturers among high-criticality entities, and GDPR governs personal data of people in the EU. Ask counsel which of these apply to your organization. Also track the HHS proposed Security Rule revision published at 90 FR 898 on January 6, 2025. It would redesignate the audit controls standard as audit trail and system log controls with more specific requirements. It was not final as of October 2026, and the Unified Agenda projects final action for July 2027. Penalties are a planning input: for penalties assessed on or after January 28, 2026, the inflation-adjusted civil money penalty ranges from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3, 91 FR 3666). Record who signed off on scope, contracts and assumptions, with dates, before the build begins.
How DeployOpen scopes and delivers HIPAA audit logging on OpenSearch
DeployOpen plans, builds and documents OpenSearch as the system that records and examines activity in systems holding ePHI, inside infrastructure you control. Engagements are fixed-scope, and the written scope sets out which systems feed the cluster, who reviews the logs and what evidence the review produces.
How we scope
- Inventory the systems that create, receive, maintain or transmit ePHI and decide which of their activity the cluster must record.
- Define the activity review procedures and who performs them, following the key activities described in NIST SP 800-66 Rev. 2.
- Confirm with your compliance lead which requirements the written scope covers, since HIPAA states no certification exists.
How we build
- Deploy OpenSearch with Security plugin audit logs, TLS for node and client traffic, and role-based access to the audit indices.
- Configure log shipping from each in-scope source, with field mappings, ingest handling and alerting on review-relevant events.
- Test that events from each source arrive, that read access is restricted to reviewers and that retention settings behave as documented.
How we hand over
- Document the scoped source list, log content, access model, retention settings and the review procedure your staff will follow.
- Provide runbooks for cluster operations, backups and recovery of the audit data, written for your own engineers to operate.
- Walk your review staff through the dashboards and searches, and record which items each review step is expected to examine.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that follows the same written scope.
- Plan OpenSearch version upgrades with your team, since maintenance releases cover security patches and bug fixes only.
- Revisit the scoped source list when systems change, and confirm with counsel whether the proposed Security Rule revision affects your plan.
