164.308(a)(4)(ii)(A) Isolating clearinghouse functions: evidence

What 164.308(a)(4)(ii)(A) requires when a clearinghouse sits inside a larger organization

If your organization is a parent company that also runs a health care clearinghouse, the clearinghouse must have policies and procedures that keep its electronic protected health information away from unauthorized access by the rest of the organization. This is a required implementation specification under the information access management standard, but it applies only in that structural situation. A stand-alone clearinghouse, or a clearinghouse with no larger parent, has no obligation under this provision.

The risk it addresses is ordinary in shared corporate environments. A clearinghouse function may share file servers, databases, network segments, identity directories, backup repositories, help desk queues and staff with unrelated business units such as a payer, a billing service or a corporate analytics team. Each shared element is a path by which someone without a legitimate need could reach transaction data. Your risk analysis should map every such path, and your procedures should state which roles may cross the boundary and under what approval. Confirm with counsel and your privacy officer how these procedures align with the minimum necessary expectations in the access management standard, since the two are read together in practice.

NIST SP 800-66 Rev. 2 (February 2024) lists isolating health care clearinghouse functions as the first key activity under information access management, which makes it a sensible starting point for the access design work that follows. Technically, isolation can be enforced with separate network segments and firewall rules (for example, an OPNsense policy that denies clearinghouse subnets to other business unit aliases and logs each match), separate directory groups or realms, and application-level delegation through a provider such as authentik. Treat these as options to evaluate against your environment rather than a checklist, and document the chosen design, the people who maintain it and the review cadence. The regulation text and the NIST guide are available through the NIST SP 800-66 Rev. 2 publication.

Which clearinghouse systems, staff and shared services are in scope

The isolation specification in 164.308(a)(4)(ii)(A) applies only when a health care clearinghouse sits inside a larger organization, so scoping starts with a classification question. Once that is settled, each shared system, person and service either widens or narrows the boundary the organization must defend and evidence.

Confirm the clearinghouse classification

Start by checking whether the unit actually meets the regulatory definition of a health care clearinghouse, which covers entities that convert health information between standard and nonstandard formats for transactions. A billing or claims unit that only forwards data to a clearinghouse may not qualify. If the unit is not a clearinghouse, or it is not part of a larger organization, this specification does not apply and the work shifts to other safeguards. Record the decision and its reasoning in writing.

Map every system holding clearinghouse ePHI

Inventory each application, database, file share and interface that receives, stores or transforms clearinghouse ePHI, including format conversion and transaction queues. Each one sits inside the boundary. Systems that only pass encrypted traffic through may stay outside, but only if the risk analysis supports that conclusion. Ask engineering to confirm data flows rather than relying on the architecture diagram alone.

Review shared identity providers

A single directory or single sign-on service that serves both the clearinghouse and the parent organization is a major boundary decision. If the parent can authenticate into clearinghouse applications through shared groups, the isolation policy must govern who can be granted those groups. Separate identity realms or tightly controlled group membership reduce this exposure. Document which accounts can reach clearinghouse resources and why.

Assess shared networks and segmentation

Flat networks, shared VLANs and common firewall zones let parent-organization traffic reach clearinghouse hosts without passing a policy check. Define the segments that contain clearinghouse ePHI and the rules that control traffic into and out of them. Confirm that firewall logging covers those rules, so that unauthorized access attempts can be reviewed later. The boundary is only as strong as the rules that enforce it.

Limit shared administrators and backups

Administrators who manage servers, databases or backup platforms for both groups hold a path to clearinghouse ePHI, whatever the application permissions say. List every privileged role with access to clearinghouse infrastructure, and decide which must be separated. Shared backup repositories and restore tools carry the same exposure, because a backup copy can be read without touching the live system. Confirm that backup encryption keys and restore rights are controlled separately.

Check shared vendors and hosting

Managed service providers, hosting platforms and software vendors that support both the clearinghouse and the parent may have standing access to both environments. Ask each vendor which personnel and tools reach clearinghouse data, and whether their support model crosses the boundary. Contracts and access records should reflect the same answer. Vendor access is a common gap because it sits outside the internal access review cycle.

How an assessor tests clearinghouse isolation

This table walks through each test an assessor typically runs against 164.308(a)(4)(ii)(A), the evidence requested for each, and the findings that most often appear. Read it as a pre-assessment checklist: if you cannot produce the evidence in the right-hand column, expect that test to produce a finding. The main takeaway is that a written policy alone will not pass; assessors look for the boundary to exist in systems and access records.

Test area	What the assessor does	Evidence requested	Common finding
Written isolation policies	Reads the policies and procedures that separate clearinghouse ePHI from the rest of the parent organization and checks they name the protected data and systems	Current written policy, version history, approval record and the systems in scope	Policy exists but names no systems, or describes a separation no one has implemented
Boundary tracing	Follows ePHI from intake through storage, processing and output to see where clearinghouse data stops and parent-organization systems begin	Data flow diagrams, system inventory, database and file share lists, network segment maps	Clearinghouse data copied into shared reporting or analytics stores with no documented boundary
Access grant sampling	Selects a sample of user accounts on each side and checks whether each account's access to clearinghouse ePHI is justified by a documented need	Access request tickets, approval records, role definitions and directory group memberships for the sampled accounts	Parent-organization users hold access that no approval record supports
Shared administrator review	Identifies accounts with administrative rights that span both the clearinghouse and the parent organization, then checks their documented purpose and controls	Privileged account register, justification for each shared administrator, logging of their activity on clearinghouse systems	Shared administrators exist but are absent from any register or review
Directory and group design	Reviews shared directories, domain groups and file shares to see whether a broad group grants access to clearinghouse data	Directory group export, file share permissions, group nesting and ownership records	Shared directories or broad groups such as all-staff grant read access to clearinghouse folders
Reachability testing	Attempts, under a documented test plan, to reach clearinghouse ePHI from accounts and network segments belonging to the parent organization	Test plan, test accounts, network access results, firewall or access rule exports and log extracts from the attempts	Parent-organization staff can reach clearinghouse databases or applications through an unrestricted network path
Exception handling	Looks for any temporary or standing exception to the isolation rules and checks it is approved, time-limited and reviewed	Exception register with approvals, expiry dates, compensating measures and review records	Exceptions granted verbally or in email with no register entry and no end date
Evidence of ongoing review	Checks whether access to clearinghouse ePHI is reviewed on a schedule and whether reviews lead to removals	Periodic access review reports, removal tickets and sign-off by the clearinghouse owner	Reviews are performed but removals are not recorded, or no review has occurred since setup

How to implement isolation step by step

This sequence turns the isolation requirement into a documented boundary: it identifies which clearinghouse data and systems must be separated, enforces that separation through identity, network and application controls, and records each decision so an assessor can trace it.

Confirm the clearinghouse function applies
Start by establishing whether your organization contains a health care clearinghouse function at all. The specification applies only when a clearinghouse sits inside a larger organization, so legal and compliance leads should document the entity analysis, the functions performed (such as converting nonstandard transactions into standard formats or the reverse) and the business units involved. Where no clearinghouse function sits inside a larger organization, record that conclusion and its basis, since the specification then does not apply. The output is a signed entity determination that the security official and counsel can point to.
Map clearinghouse ePHI and connected systems
Inventory every data store, application, interface, integration, backup and administrative account that holds or touches the clearinghouse's ePHI. Include shared services the rest of the organization also uses, such as file transfer servers, identity directories, logging platforms, data warehouses and support tooling, because these are the most common paths across a boundary. Data flow diagrams and the asset inventory from your risk analysis are the usual sources. The check that closes this step is a reviewed inventory where every system is tagged as clearinghouse, shared or non-clearinghouse, with an owner named for each.
Define the boundary and assign each side
Using the inventory, draw the boundary between the clearinghouse and the larger organization. Decide which systems sit inside, which are shared and how each shared system is either split or limited to non-ePHI functions. Name the workforce roles and the accountable manager for each side, and state which people may cross the boundary and for what purpose. The output is a boundary register and an updated data flow diagram that show every approved crossing point, with the reason it exists and the control that governs it.
Write the isolation policy and procedures
Document the policy that the clearinghouse's ePHI is protected from unauthorized access by the larger organization, and the procedures that implement it. Cover who may request an exception, how exceptions are approved, how staff are trained to recognize boundary violations, and how the policy is reviewed when systems change. Policy owners should be the security official and the clearinghouse leadership, and the document should be approved and dated. The output is a versioned policy that links to the boundary register and to the access management procedures for the information access management standard.
Separate identities and access groups
Create distinct directories, groups or tenants for clearinghouse users, and make sure no large-organization group is granted access to clearinghouse resources by default. Shared administrators with broad rights should be reviewed and either removed from clearinghouse scope or placed under documented, logged exceptions. Open-source identity tools can support this, for example an identity provider such as authentik that brokers sign-in to applications over OAuth2, OpenID Connect or SAML, or FreeIPA for single sign-on in Linux and UNIX environments. Confirm each product's capabilities against your environment before relying on them. The output is an access matrix showing which identities can reach which clearinghouse systems.
Enforce the boundary at network and application layers
Place clearinghouse systems in segmented network zones and write firewall rules that permit only the approved flows listed in the boundary register, denying everything else by default. A stateful packet filter such as OPNsense can pass, block or reject traffic by source, destination, port and protocol, and can log rule matches for review. At the application layer, a web application firewall such as Coraza, which works with OWASP Core Rule Set rulesets, can protect clearinghouse web interfaces. Test each rule with a deliberate cross-boundary attempt and keep the results. The output is exported rule sets, change records and test evidence showing blocked and permitted flows.
Document exceptions through the risk analysis
Any shared system, cross-boundary service account or temporary access path that cannot be removed should be recorded as an exception. Each exception needs a business reason, the controls that limit it, an approver and a review date. Feed these items into the HIPAA risk analysis and the risk management plan so the residual risk is assessed and accepted by an accountable person, not left in an operational note. The output is an exception register linked to risk analysis entries and signed approvals.
Record and retain each step's output
Keep the outputs of every step together as the evidence set: the entity determination, the inventory and diagrams, the boundary register, the policy, the access matrix, exported firewall and application rules, test results, the exception register and review records. Store them under the documentation requirements that apply to Security Rule policies, and schedule periodic reviews to confirm the boundary still matches the systems in use. Ask any implementation partner to deliver these artifacts in a form your assessor can trace from requirement to evidence. The output is a maintained evidence package that an independent assessor can test, while the organization remains responsible for the controls themselves.

How network, identity and application controls make the boundary hold

A written policy alone does not isolate clearinghouse data. The specification asks for policies and procedures that protect the clearinghouse's ePHI from unauthorized access by the larger organization, and an assessor will look for technical enforcement behind those documents. The boundary has to be enforced where traffic, identities and application requests actually pass. Start by mapping every system that holds or processes clearinghouse ePHI, every account that can reach it, and every network path that leads to it. That map is the basis for the controls below and for the risk analysis that should justify them. Segmentation is the first layer. Place clearinghouse systems in their own network zone and control traffic in and out with a stateful packet filter, so that only the flows the clearinghouse needs are permitted. Rules should be written by source, destination, port and protocol, and each rule that matters for isolation should log its matches so that someone can review attempted access from the parent organization. Confirm with your own network team how rule changes are approved and recorded, because an undocumented exception can quietly undo the boundary.

Identity separation is the second layer, and it is where many boundaries fail in practice. If parent-organization directories grant administrators, help desk staff or shared service accounts access to clearinghouse applications by default, the parent can inherit clearinghouse roles without anyone deciding that it should. Decide which identity sources are allowed to authenticate into clearinghouse systems, keep clearinghouse roles in a separate directory or group structure, and review membership of those groups on a defined schedule. Ask whether any parent-level domain administrator can reach clearinghouse hosts, and document the answer. Application-layer filtering is the third layer. Clearinghouse services exposed over HTTP or similar protocols should sit behind a web application firewall that inspects requests before they reach the application. This does not replace access control, but it limits the request types that shared infrastructure will accept. Test each layer independently, for example by attempting access from a parent-organization account and from a parent-organization network segment, and keep the results as evidence that the isolation was checked rather than assumed.

Evidence that shows isolation works and stays current

Isolation is only as credible as the records behind it. The six artifacts below let an assessor trace a rule from the written policy to the systems that enforce it, and each one needs a refresh cycle so it still matches the environment on the day it is examined.

Written isolation policy and procedures

The policy names the clearinghouse functions, the larger-organization units that must be kept out, and the approval path for any exception. It should state which roles may cross the boundary and why. Review it after every reorganization, acquisition or new clearinghouse service, and confirm that the version on file is the one staff actually follow. Ask whether the policy ties back to the risk analysis, since an assessor will check that link.

Current boundary diagram

A diagram shows where clearinghouse systems, shared networks, identity stores and administrative paths meet. It should match the live configuration, not the design from the original project. Refresh it whenever a network segment, VPN, data feed or shared service changes, and have an engineer sign off that it reflects production. Mark every crossing point so an assessor can see which ones are controlled.

Access grant and review records

Keep records of each grant to clearinghouse ePHI for both sides of the boundary, showing who approved it, the business reason and the date. Periodic reviews should confirm that larger-organization staff still lack access they do not need. Record every removal as well as every addition. Pull a sample of grants and check each one against the approval trail, because gaps in this trail are a common finding.

Firewall rule sets and match logs

Export the current rule set for each boundary firewall, with aliases for the address groups it protects. Keep change history that links each rule to a ticket and an approver. Enable logging on rules that block or pass traffic across the boundary, and retain the logs long enough to review them on a schedule. OPNsense, for example, can log each rule match in its live log view, but the export and retention process still needs to be documented by your team.

Identity group membership exports

Directory group membership is the second layer that controls whether a user reaches clearinghouse data. Export group membership for every group mapped to clearinghouse applications, and compare it against the access grant records. Run the export on a fixed cycle and keep dated copies. Where an identity provider such as authentik or FreeIPA brokers sign-in, confirm that application providers reference the right groups and that no shared service account bypasses them.

Exception records tied to risk analysis

Where a larger-organization function needs limited access to clearinghouse data, record the exception, its justification, the compensating measures and an expiry or review date. Link each exception to the risk analysis entry that accepted or treated the risk. Review open exceptions at each risk review, and close any that no longer have a business need. Undocumented exceptions are the artifact most likely to undermine the others.

What isolating a clearinghouse costs in money and effort

This table lists the cost components of isolating a clearinghouse's ePHI from the rest of a larger organization, who is paid for each, and whether it is one-time or recurring. No price figures are supplied for this specification, so use the drivers and quote questions to compare proposals. The main takeaway is that the largest recurring costs follow the number of shared systems, staff and vendors that touch clearinghouse data.

Cost component	Who is paid or who bears the cost	One-time or recurring	What drives it up or down
Scoping and data mapping	Internal privacy and security staff, or an outside consultant if engaged	One-time, then revisited when systems change	Number of systems, databases and interfaces that carry clearinghouse ePHI
Engineering time to separate directories, accounts and networks	Internal platform engineers or an implementation partner under a written scope	One-time, with later changes as systems are added	Count of shared directories, identity stores, network segments and admin accounts
Open-source tooling and infrastructure	Your cloud or data center costs; no license fee for self-hosted open-source components	Hardware or hosting recurring, software license spend can be removed	Platform choice, redundancy needs and the size of the environment
Access policy and procedure drafting	Internal compliance or legal staff, or a consultant	One-time drafting, recurring review	Number of roles, business units and shared vendors needing access rules
Evidence collection and upkeep	Internal security or operations staff	Recurring, usually tied to access reviews and log retention	How often access changes, how many people manage access, and whether evidence is automated
Vendor and shared-service review	Internal vendor management, plus any vendor fees for their assurances	Recurring at each contract renewal or new integration	Number of vendors and shared services that touch clearinghouse functions
Testing of the separation	Internal staff or an outside security tester under a fixed scope	Recurring, at least as part of the evaluation standard	Complexity of the boundary and how often it changes
External review and assessor time	Independent auditor or assessor, if you commission one	Recurring when an outside review is requested	Scope of what is reviewed and how well evidence is prepared in advance

Who owns isolation, who can help and where the auditor stops

Your organization owns the requirement. The specification applies only if a health care clearinghouse sits inside a larger organization, so the first decision is whether that is true for your structure. If it is, your leadership must define which functions are clearinghouse functions, set the policies that keep that ePHI away from the rest of the business, and accept the residual risk in writing. The security official and the privacy function typically own the policy, while the business owners of the clearinghouse and the rest of the organization approve who may cross the boundary.

Boundary decision: Document which systems, data stores and staff belong to the clearinghouse and which do not.
Policy ownership: Write and approve the isolation policy and the procedures that enforce it.
Access approvals: Decide who in the larger organization may request access, on what basis, and who signs off.
Risk acceptance: Record how the risk analysis treated any shared services, such as shared networks or identity directories.
Evidence custody: Keep access reviews, approval records and change logs under your own control.

Before you engage anyone, confirm internally whether your organization meets the clearinghouse definition at all, because a wrong answer here changes the whole scope.

Where clearinghouse isolation usually fails

Isolation rarely fails in the policy text. It fails in the places where a parent organization's shared identities, networks, billing data and access exceptions quietly reach the clearinghouse. The cards below cover the gaps assessors and implementation teams most often find, and each ends with the check that closes it.

Shared domain administrators

When the parent organization and the clearinghouse share directory domain administrators, any parent administrator can read or change clearinghouse records without going through clearinghouse approval. Under 164.308(a)(4)(ii)(A), the policies must keep clearinghouse ePHI out of reach of the larger organization. Check that clearinghouse systems sit in their own administrative scope, with separate privileged accounts, and that every privileged grant is listed and approved.

Flat network segments

A clearinghouse that shares a broadcast domain or VLAN with general corporate hosts depends on every host staying clean. Segmentation is the technical form of the isolation the rule asks for. Confirm that clearinghouse subnets are reachable only through defined firewall rules, and review whether those rules allow broad management protocols from corporate networks.

Undocumented parent access to billing data

Billing and claims data often flows to finance, sales or analytics teams in the parent organization through reports, data warehouses or shared spreadsheets. These copies are easy to forget during the risk analysis. List every data feed and copy that leaves the clearinghouse, record which parent role receives it, and confirm the flow matches an approved access decision.

Stale access reviews

Access that was right when granted can outlive the job it supported, especially after reorganizations, mergers or staff moves between the clearinghouse and the parent. Periodic review under the access establishment and modification specification is where these leftovers get caught. Ask for the last review record, who signed it, and whether removed users were checked against the clearinghouse access list.

Exceptions without a risk basis

Temporary exceptions, such as a parent executive who needs a clearinghouse report or an engineer who needs production access during an outage, often stay open with no written reason. An exception needs a documented business need, an approver outside the requesting team, and an end date. Require each exception to name its risk and expiry, and review open exceptions at the same cadence as access reviews.

Common questions about isolating clearinghouse functions

Does the isolation requirement apply to a standalone health care clearinghouse?

No. The specification in 45 CFR 164.308(a)(4)(ii)(A) applies only when a health care clearinghouse is part of a larger organization, such as a health system, insurer or company that houses a clearinghouse unit. A standalone clearinghouse still must meet the rest of the Security Rule, including information access management, but this required isolation step is not triggered. Whether your unit counts as part of a larger organization depends on your corporate structure, data flows and how the clearinghouse shares systems, people and identity stores with other units. Confirm that answer with counsel and your privacy officer before scoping any work, because the test turns on the facts of your structure.

How long does it take to isolate clearinghouse functions?

No duration is set by the rule, so the timeline depends on the scope of your environment. The main drivers are how many systems hold clearinghouse ePHI, how many shared directories, networks and administrator accounts connect the clearinghouse to the rest of the organization, and whether the data flows through shared databases or reporting tools. Mapping those flows during your risk analysis usually comes first, followed by policy, technical separation, testing and documentation. A fixed-scope engagement agrees its schedule in writing before work starts, so ask any partner for milestones tied to named systems. Your own timing will also depend on change windows, approvals and staff availability.

How much staff effort does clearinghouse isolation require?

Effort falls on several roles, and the largest share usually sits with the teams that own the data flows. Clearinghouse leaders define which functions and records are in scope. Infrastructure and identity staff implement segmentation and access changes. The security official and compliance lead write or update the policies and procedures. Testers verify that users outside the clearinghouse cannot reach its ePHI. After the first pass, effort recurs as access reviews, log reviews and change approvals:

Clearinghouse owners: scope and data mapping
Infrastructure and identity staff: segmentation, access groups and logging
Security and compliance staff: policies, procedures and evidence
Testers and reviewers: validation and sign-off

Ask any quote to break effort down by these roles.

Can our team isolate clearinghouse functions in-house?

Yes, a capable internal team can do this, provided it has skills in network segmentation, identity management and written policy. Self-hosted open-source platforms can carry much of the technical work. OPNsense rules pass, block or reject traffic by source, destination, port and protocol, aliases group addresses so segments are easier to maintain, and each rule match can be logged for review. authentik can act as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so clearinghouse applications sign in against a controlled source. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Confirm each feature against the version you run, and keep ownership of the policy with your organization.

What does an outside implementation partner change?

An outside partner changes capacity and how quickly the technical work gets done, but it does not change who owns the controls. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it prepares systems and evidence for assessment. Your organization still owns its policies and risk decisions. An independent auditor or certification body is the party that issues any report or certificate, and DeployOpen does not issue either. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. No price list is published, so a quote follows from the written scope.

Does HHS certify HIPAA Security Rule compliance?

No. HHS states that no Security Rule standard requires an entity to certify its compliance. HHS does not endorse or recognize certifications from private organizations, and a private certification does not stop HHS from later finding a violation. Any vendor or consultant who sells a HIPAA certificate is offering something HHS does not recognize, so ask what evidence they can show instead: a documented risk analysis, written policies, test results and an independent assessment report with a stated scope. HHS's 2003 FAQ on certification explains the position in full. An independent assessment can show that a defined scope was tested at a point in time.

How DeployOpen works on this

DeployOpen plans and implements the technical separation that 164.308(a)(4)(ii)(A) calls for, inside the client's own infrastructure, and prepares the policies and evidence that show it works. The organization keeps ownership of its controls and its compliance determination, and an independent assessor is the party that tests and reports on them.

How we scope

Written scope names each clearinghouse function, the larger-organization systems it must be separated from, and the ePHI stores involved.
We map which networks, identity realms, applications and administrator groups can reach clearinghouse data today.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure segmentation with OPNsense rules, aliases and per-rule logging so cross-boundary traffic is blocked and recorded.
We design separate identity realms with authentik or FreeIPA so clearinghouse access is granted only to named staff.
We test the boundary with access attempts from the wider organization and document each result for review.

How we hand over

Handover includes the written isolation policies and procedures, the access authorization records and the rule configurations.
Evidence packs map each artifact to the NIST SP 800-66 Rev. 2 access management activity so your assessor can trace it.
You receive runbooks for adding or removing users, plus a list of open items that remain the organization's decisions.

How we support

Ongoing support, upgrades and continuous testing of the boundary are available as a retainer.
We can re-test isolation after reorganizations, mergers or new clearinghouse integrations, and update the evidence set.
Confirm with your legal and compliance team whether a clearinghouse is in fact part of a larger organization before scoping begins.