From Outdated IT to HIPAA Readiness: HIPAA Compliance for Small Business

Updated August 2026: I originally published this article in April 2025 after working with a healthcare service business that needed to address HIPAA requirements and technology related requirements associated with its CARF accreditation. A lot has happened since then, both with this client and across healthcare cybersecurity in general. I have updated the article to better explain why I started with an IT Baseline Assessment, what we found, the technology and security work that followed, and what happened when this same client later experienced a real disaster that put the environment we had built to the test.

When this client first came to me, they already knew where they needed to get. They had HIPAA requirements to address and were working through requirements associated with CARF accreditation. What they did not have was a clear understanding of where their technology environment currently stood or what needed to change.

For healthcare organizations, HIPAA compliance for small business starts with understanding the technology already in place, how information is accessed and protected, and where security or operational gaps need to be addressed.

I could have immediately started recommending a new firewall, computers, Microsoft 365, endpoint protection, or other security products. But that would have skipped an important step. Before I could responsibly build a plan for where they needed to go, I needed to establish where they were starting.

That is why I began with an IT Baseline Assessment.

“Before I could build a plan for where they needed to go, I had to establish where their technology stood.”SNL-Tech Services

Where Do You Start When Your Business Needs to Address HIPAA?

This is one of the first questions I think a small healthcare business should ask. If you know you have HIPAA requirements but do not have a clear understanding of your computers, network, accounts, security, backups, cloud services, or where sensitive information is stored, how do you know what actually needs to change?

For this client, the first step was understanding the existing technology environment. I needed to know what computers and network equipment they were using, how employees signed in, what security protections existed, where files were stored, how email was configured, what was supported, what was outdated, and what employees depended on to do their jobs.

My IT Baseline Assessment is not a declaration that an organization is or is not HIPAA compliant, and I do not present it as a substitute for the organization's formal HIPAA Security Rule risk analysis or broader compliance responsibilities. My role is on the technical side. I need to understand and document the technology environment, identify technical gaps within my scope, and implement and manage the IT and security controls appropriate for that environment.

That distinction matters, but so does the reason for establishing the baseline. Current HHS guidance describes risk analysis as foundational to HIPAA Security Rule compliance because an organization needs to understand the electronic protected health information it creates, receives, maintains, or transmits, along with the risks, vulnerabilities, and existing safeguards surrounding that information. For me as the IT provider, the baseline gave me the technical picture I needed to start making informed recommendations instead of assumptions.

What Is CARF Accreditation?

HIPAA was not the only consideration for this particular client. CARF accreditation was also important to the organization.

CARF International is an independent nonprofit accreditor of health and human services. It was originally founded as the Commission on Accreditation of Rehabilitation Facilities, which is where the acronym CARF comes from. Unlike HIPAA, CARF is not a federal regulation. CARF accredits health and human service programs against applicable organizational and program standards and uses a peer review accreditation process focused on quality and continuous improvement. Its accreditation programs cover areas that include behavioral health, substance use treatment, medical rehabilitation, aging services, child and youth services, and other health and human services.

I think that distinction is important because I do not use HIPAA compliance and CARF accreditation interchangeably. This client had HIPAA responsibilities while also working to meet requirements associated with CARF accreditation. My job was to understand what that meant for their technology environment and perform the technical implementation and documentation that fell within my role.

What HIPAA Compliance for Small Business Looks Like in Practice

Once I went through the environment, we had something much more useful than assumptions. We had an actual technical starting point and could begin prioritizing what needed attention.

Among the issues I identified were:

• An outdated firewall that could no longer be updated

• A network switch that was no longer supported

• No antivirus or endpoint protection

• Local user accounts with no centralized management

• Aging computers that needed to be addressed

• Email that lacked the security and compliance configuration the environment needed

• File sharing that needed better structure and access controls

These were not theoretical future problems created by a proposed regulation. They were existing weaknesses in an environment already being used by a healthcare organization.

That is an important distinction in 2026 because there has been a lot of discussion about the proposed changes to the HIPAA Security Rule. Regardless of what eventually happens with those proposed changes, an unsupported firewall does not become safer because a regulatory timeline changes. Missing endpoint protection does not become less important. Weak access controls do not protect patient information better while everyone waits for a new rule.

Modernizing the Network and Computers

The remediation work started with the underlying environment. I replaced the outdated firewall and unsupported network switch with current equipment that gave us a better foundation to work from. I also deployed endpoint protection across the organization's computers.

I would describe that differently today than I did in the original version of this article. Installing endpoint protection does not make a business HIPAA compliant. A firewall does not make a business HIPAA compliant either. They are technical safeguards that can be part of a much larger security program. What mattered here was that important protections were either missing or outdated, and we now had the baseline information necessary to address them intentionally.

The computers also needed a lifecycle plan. When I originally wrote this article in April 2025, Windows 10 end of support was still approaching. Windows 10 reached end of support on October 14, 2025, so this conversation has changed. Unsupported operating systems and aging hardware need to be evaluated based on the actual environment, the support available, what the computer is being used for, and what information it can access.

Instead of waiting for computers to fail one by one, I developed a replacement strategy so the organization could address aging equipment proactively.

Moving Away From Local Accounts

Another major issue was how employees and computers were being managed. Employees were using local Windows accounts, which made centralized identity, device management, and consistent security controls much more difficult.

I transitioned the environment to Microsoft Entra ID so identities and devices could be managed more centrally. That created a much stronger foundation for managing access and the computers themselves than the collection of independent local accounts that had existed previously.

This is where I think healthcare business owners need to understand the difference between owning Microsoft 365 and actually managing Microsoft 365. Having licenses does not tell me whether MFA is configured appropriately, administrative access is controlled, devices are managed, employees have appropriate access, security alerts are being reviewed, or the tenant is configured around the way the business actually operates.

I go much deeper into those questions in What I Check When I Do a Microsoft 365 Tenant Security Review. That review is what I also refer to as my Microsoft 365 Audit. It is specifically focused on what is happening inside the Microsoft environment, while the IT Baseline Assessment looks at the broader technology environment.

Email, Microsoft 365, and File Access Needed Attention Too

I migrated the client's email to Microsoft 365 and implemented additional email security controls, including encryption capabilities, anti phishing protections, spam filtering, and logging and auditing capabilities appropriate to the environment.

File sharing also needed to change. I implemented SharePoint so the organization could move away from its previous approach to file sharing and use an environment where access and permissions could be managed more intentionally.

There is something I would emphasize much more strongly today than I did when I originally wrote this article. Moving files into SharePoint does not make them secure simply because they are now in Microsoft's cloud.

Before sensitive business or patient information is moved into SharePoint, I want to understand who should have access to it, which security groups should control that access, how sharing should work, what devices should be allowed to reach the information, and what additional protections are appropriate for that particular business. Depending on the environment and licensing, Conditional Access and other Microsoft security controls can be used to place conditions around access based on factors such as identity, device state, location, and risk.

For a regulated business, that becomes particularly important. An employee having valid Microsoft credentials does not automatically mean I want that employee downloading sensitive information onto any unmanaged computer they happen to be using.

Does Microsoft 365 Make a Healthcare Business HIPAA Compliant?

No, and I think this is one of the most important misconceptions for a small healthcare business to understand.

Microsoft 365 can provide services and security capabilities that can be used as part of an environment handling protected health information, but purchasing Microsoft 365 does not make the organization HIPAA compliant. The organization still needs to understand where ePHI is stored and transmitted, who can access it, how devices are managed, what security controls are configured, which vendors or services are involved, what agreements are required, and how its broader HIPAA responsibilities are being addressed.

The same principle applies to other technology. A HIPAA capable EHR does not make every computer, email account, cloud service, backup, firewall, wireless network, and employee workflow compliant. Technology can support an organization's HIPAA responsibilities. It cannot replace them.

This is also why I do not automatically tell every business to move everything to the cloud. The right environment depends on the business, its applications, employees, workflows, security requirements, and regulatory obligations. I go deeper into those decisions in Should Small Businesses Move Everything to the Cloud?.

The Incident Response Plan Was Part of the Work

The project was not limited to replacing equipment and configuring Microsoft 365. Documentation and response planning were also part of what this client needed, and I created an Incident Response Plan for the organization.

An Incident Response Plan answers a different question from endpoint protection or a firewall. Security products can help prevent, detect, or contain certain threats. The Incident Response Plan establishes what the organization is going to do when something actually happens.

Who needs to be involved? How does a suspected incident get escalated? Who is responsible for which actions? How will communication be handled? What needs to be documented? What systems or information may be affected? Who needs to be contacted?

The middle of a security incident is a terrible time to start deciding those things.

The plan also needs to reflect the actual business and technology environment. A generic template may provide a useful starting point, but a plan becomes much more useful when it accounts for the systems, people, responsibilities, vendors, and communication paths that actually exist. Because I had already established the client's technical baseline and worked through the environment, I was not creating an Incident Response Plan for technology I did not understand.

The current HIPAA Security Rule already requires regulated entities to implement policies and procedures for addressing security incidents, including identifying and responding to suspected or known incidents, mitigating harmful effects where practicable, and documenting security incidents and their outcomes. This is an existing responsibility, not something that begins only if the proposed Security Rule changes are finalized.

Incident Response and Disaster Recovery Are Not the Same Thing

Incident Response and Disaster Recovery are closely connected, but I look at them as two different problems. Incident Response deals with how the organization responds to a security event. Disaster Recovery deals with how the organization restores the technology and data the business depends on after something goes wrong.

HIPAA already addresses this through its contingency planning requirements. Those requirements include a data backup plan, Disaster Recovery Plan, and Emergency Mode Operation Plan for responding to emergencies and other occurrences that damage systems containing ePHI. The current requirements contemplate events such as fire, vandalism, system failure, and natural disasters.

For this client, that stopped being theoretical.

Then a Storm Ripped Part of the Roof Off

Fortunately, the disaster happened after I had completed the client's transition to the newer environment.

A severe storm came through Frederick, Maryland, and ripped part of the roof off their building. The damage affected the area where employees worked and also damaged technology, including the firewall, network switch, wireless access points, computers, and network infrastructure.

The client called me late that night after he had been at the building and seen the damage. I drove up early the next morning to assess the IT environment and figure out what we could recover, what needed to be replaced, and how we could get employees working again while the damaged portion of the building was being repaired.

This was where Disaster Recovery became very physical, very quickly.

We moved usable computers and equipment out of the damaged area and relocated employees to the other side of the building. Conference rooms became temporary offices. I set the computers back up in those temporary spaces, tested the equipment, and made sure the systems we could recover were functioning properly.

The network infrastructure also needed immediate attention. I replaced the network switch that had been damaged by the storm, swapped out the damaged firewall and handled the RMA process for it, and ordered replacement wireless access points for the units that had been damaged.

While another company worked on repairing the damaged part of the building, the client was able to stay up and running from the temporary offices we had created on the other side of the building.

That is an important part of this story. Disaster Recovery is not always a ransomware event or a server failure. Sometimes a storm removes part of your roof and suddenly the office your employees normally work from is not usable.

The Damaged Computer Did Not Become a Data Loss Event

One computer was damaged badly enough that it ultimately had to be replaced. Fortunately, because this happened after I had already transitioned the client's environment, the loss of that physical computer did not mean the loss of the business data stored on it.

Their files were no longer dependent on that individual computer. The information had already been moved into the cloud as part of the earlier modernization work.

That meant I could focus on replacing the damaged device and getting the employee working again rather than adding a data recovery problem to everything else we were already dealing with.

This is one of the practical benefits I look for when designing an environment around the business rather than around individual computers. Hardware is going to fail eventually. Computers get damaged, lost, stolen, or replaced. The loss of one physical device should not automatically become the loss of the business information an employee needs to do their job.

At the same time, this experience does not mean every business should move everything to the cloud. The cloud solved one important part of this particular recovery problem. It did not replace the damaged firewall. It did not replace the switch, wireless access points, cabling, computers, phones, or physical office space. The cloud was one part of the resilience we had built into the environment, not the entire Disaster Recovery strategy.

“Disaster Recovery is not only about getting your data back. It is about understanding what your business needs to operate when the environment you planned for is no longer available.”SNL-Tech Services

Getting the Business Back Into Its Original Offices

The temporary environment was not the end of the recovery.

About a week and a half later, once repairs to the damaged part of the building were complete and employees could return to their original offices, I went back. We moved the computers and phones out of the temporary spaces and returned them to their regular offices. I reconnected and tested the equipment and found that some cabling in the affected area also needed to be replaced so the phones and network connections would function properly again.

That meant the technology response happened in stages. First I needed to assess the damage and protect what could still be used. Then we needed a temporary environment that would allow employees to continue working. Damaged equipment had to be replaced. Finally, once the building itself was repaired, everything had to be moved back, reconnected, repaired where necessary, and tested again.

For me, that experience is a much better explanation of Disaster Recovery than simply asking whether a company has backups.

“Having a backup and knowing you can recover your business within the time you actually have are two very different things.”SNL-Tech Services

A backup matters tremendously when data needs to be restored. But a backup cannot replace a damaged network switch, a damaged firewall, unusable WiFi, broken cabling, or an office employees cannot safely work in.

Why Availability Matters in Healthcare

When business owners hear HIPAA security, the first thing they often think about is preventing someone from stealing patient information. Confidentiality is certainly important, but the HIPAA Security Rule addresses the confidentiality, integrity, and availability of electronic protected health information.

Availability is the piece that becomes very tangible when a healthcare organization cannot reach the systems or information its employees need.

That can happen because of ransomware, hardware failure, a network outage, a cloud service disruption, or, as this client experienced, physical damage to the building itself. The specific recovery requirements will depend on the organization, its systems, applicable requirements, and operational needs. I do not assume every healthcare organization has the same recovery window.

What I do want to understand is which systems are critical, what is being backed up, how much data loss the organization could tolerate, what needs to come back first, and how long the business can reasonably function without a particular system. Saying “we have backups” does not answer those questions.

Healthcare Breaches Are Not Just a Hospital Problem

Physical disasters are only one side of the risk healthcare organizations face. Cybersecurity incidents continue to affect healthcare organizations on an enormous scale.

According to HHS's Annual Report to Congress for calendar year 2024, the Office for Civil Rights received 663 reports of breaches affecting 500 or more individuals, and those breaches affected approximately 242.9 million people. Hacking and IT incidents represented 81 percent of those large reported breaches and affected more than 241 million individuals. HHS also identified areas such as risk analysis, risk management, information system activity review, audit controls, and authentication as areas needing continued attention.

Those numbers are enormous, but I do not think a small medical practice, behavioral health provider, treatment facility, or other healthcare business should look at them and conclude that cybersecurity is only a problem for hospital systems and national insurance companies. The technology may look very different in a ten person organization than it does in a hospital system, but the need to understand and protect ePHI does not disappear because the business is small.

I also do not use those statistics to scare clients into buying technology. I use them as context for why understanding the environment and addressing known weaknesses matters.

Should Healthcare Businesses Wait for the Proposed HIPAA Security Rule Changes?

No.

HHS proposed significant changes to the HIPAA Security Rule in December 2024. The proposal includes more prescriptive requirements around areas such as technology asset inventories, network maps, written documentation, MFA, encryption, vulnerability scanning, network segmentation, Incident Response, backup and recovery, and testing of security controls. The proposal also includes written procedures to restore certain relevant electronic information systems and data within 72 hours.

Those provisions are proposed, and I would not tell a client that they are already requirements under the current Security Rule. HHS states that the current Security Rule remains in effect while the rulemaking process continues.

But a changing regulatory timeline is not a reason to stop technical implementation.

The current Security Rule already contains requirements involving risk analysis and risk management, security incident procedures, contingency planning, access controls, audit controls, authentication, and other safeguards. Current HHS guidance also continues to emphasize understanding risks to the confidentiality, integrity, and availability of ePHI.

I do not need to wait for a future regulation to tell me that unsupported systems, missing endpoint protection, weak access controls, or an untested recovery process deserve attention. At the same time, I am not going to represent proposed requirements as though they are already law.

The practical approach is to understand what applies today, address the technical risks that exist today, and continue watching the regulatory environment as it evolves.

Where Does Cyber Insurance Fit Into This?

Cyber insurance creates another reason for a business owner to understand what is actually happening in the technology environment.

HIPAA, CARF accreditation, and cyber insurance underwriting are different things, and I do not treat their requirements as interchangeable. But they can cause businesses to encounter questions about some of the same underlying technical controls, including MFA, endpoint protection, backups, recovery, administrative access, encryption, remote access, and Incident Response Planning.

If an insurance application asks whether MFA is enforced, whether backups exist, or whether the business has a documented Incident Response Plan, I do not want the owner guessing. I want the answer to reflect what is actually implemented and documented.

I go much deeper into this in Cyber Insurance Requirements for Small Businesses: Can You Answer the IT Questions on Your Application?, including why I think technical questions on an insurance application should be verified before a business answers them.

How Do I Know Whether Our HIPAA Security Controls Are Actually in Place?

This may be one of the most important questions a healthcare business owner can ask.

If someone tells you that your business is secure or that everything is “HIPAA compliant,” you should be able to ask what that means technically and get understandable answers. You do not need to become an IT professional, but someone should know how your environment is actually configured.

Depending on the organization, useful questions can include:

• Do employees have individual accounts?

• Where is ePHI created, received, maintained, or transmitted?

• Is MFA configured appropriately?

• Are company computers encrypted?

• Are computers centrally managed and kept current?

• Is endpoint protection installed, active, and being monitored?

• Who has administrative access?

• How is access to sensitive information controlled?

• Can unmanaged or personal devices access sensitive files?

• What security and audit logging is available?

• What is being backed up?

• Has recovery actually been tested?

• What happens if a critical system becomes unavailable?

• Is there a documented Incident Response Plan?

• Which technology vendors may handle ePHI, and have the appropriate agreements and responsibilities been addressed?

• When was the technology environment last reviewed?

The answers will not look identical for every healthcare business. The important part is that somebody actually knows the answers and can explain them.

Compliance and Security Do Not Stop When the Project Ends

One of the biggest changes I would make to the original version of this article is how I describe the end of the project.

Technology does not remain frozen after remediation work is completed. Employees come and go. Computers age. Applications change. Microsoft changes features. Vendors are added and removed. Files move. Permissions accumulate. New vulnerabilities are discovered. Business processes change. The environment needs ongoing management.

For this client, the initial project created a much stronger technical foundation. But the storm later demonstrated why understanding and managing the environment continues to matter after the original implementation is finished. Technology had to adapt again because the business itself suddenly had to adapt.

That is true whether the driver is HIPAA, CARF accreditation, cyber insurance, or simply the responsibility of keeping a business operational.

What If I Do Not Know Where My Healthcare IT Environment Stands?

I would not start by buying another security product. I would start by establishing the baseline.

What technology do you have? What is supported? What is outdated? Where does sensitive information live? Who has access? How are identities managed? What protects the computers? What happens when an employee leaves? How is Microsoft 365 configured? What gets backed up? How quickly could you recover? What documentation exists? What happens if there is a security incident? What happens if employees cannot use the office tomorrow?

Those answers give us something concrete to work from.

For this client, the IT Baseline Assessment gave me the technical picture I needed before I started making changes. If the broader IT environment is already understood but Microsoft 365 itself is the concern, my Microsoft 365 Tenant Security Review provides a more focused look at the Microsoft environment.

The assessment itself does not make an organization compliant. What it can do is replace assumptions with an understanding of what is actually there. From that point, the business can make much better decisions about what needs to happen next.

From Outdated IT to a Better Managed Healthcare Environment

When I originally called this article From Outdated to Compliant, I was trying to capture the transformation this client was going through. Looking back at the project now, I think there is a more useful lesson.

The value was not that I installed a collection of products and declared the business compliant. We established where the technology stood, identified the technical gaps, replaced outdated and unsupported equipment, improved identity and device management, strengthened email and file access, moved business information away from dependence on individual computers, created an Incident Response Plan, and developed a stronger foundation to support the client's HIPAA responsibilities and CARF accreditation efforts.

Then that environment faced something we had not planned on happening in exactly that way.

A storm damaged part of the building and took out physical technology. We moved the business into temporary offices, replaced damaged network equipment, kept employees working while repairs were underway, and then moved everything back and tested it when the original offices were ready again. A computer was destroyed, but losing that computer did not mean losing the business data it once would have contained.

That experience reinforced something I think applies well beyond healthcare.

Good IT planning is not about trying to predict every possible thing that can go wrong. It is about understanding what your business depends on, reducing the points of failure you can control, documenting the environment, protecting the information that matters, and being prepared to adapt when the problem that actually happens is not the one you expected.

If your healthcare business knows it needs to improve its technology, security, HIPAA readiness, or recovery planning but does not have a clear picture of where things stand today, SNL-Tech Services Business IT Solutions can help establish that starting point and build the technical plan from there.

Frequently Asked Questions

Where should a small healthcare business start with HIPAA and IT?

A healthcare business needs to understand the environment that creates, receives, maintains, or transmits ePHI. A formal HIPAA Security Rule risk analysis is part of the organization's compliance responsibilities. From the IT side, establishing a technical baseline can help identify the computers, network equipment, applications, accounts, cloud services, security controls, backups, and other technology that need to be understood and addressed.

Does an IT Baseline Assessment make my business HIPAA compliant?

No. An SNL-Tech Services IT Baseline Assessment establishes a technical picture of the environment and helps identify technical gaps within the scope of the assessment. HIPAA compliance includes administrative, physical, and technical responsibilities and cannot be reduced to an IT assessment or checklist.

Is CARF the same as HIPAA?

No. HIPAA is federal law. CARF International is an independent nonprofit accreditor of health and human services. An organization may have HIPAA responsibilities while separately pursuing or maintaining CARF accreditation.

Does Microsoft 365 make a healthcare business HIPAA compliant?

No. Microsoft 365 can provide services and security capabilities that can be used as part of a HIPAA regulated environment, but licensing alone does not make an organization compliant. Configuration, access, devices, data handling, applicable agreements, policies, risk analysis, and other responsibilities still need to be addressed.

Do healthcare businesses need an Incident Response Plan?

The current HIPAA Security Rule requires regulated entities to implement policies and procedures to address security incidents, including identifying and responding to suspected or known incidents, mitigating harmful effects where practicable, and documenting security incidents and their outcomes. The organization's response procedures should reflect its actual environment.

Does HIPAA address Disaster Recovery?

Yes. The current HIPAA Security Rule includes contingency planning provisions covering a data backup plan, Disaster Recovery Plan, and Emergency Mode Operation Plan. Contingency planning addresses emergencies or other occurrences that damage systems containing ePHI.

Does the current HIPAA Security Rule require every healthcare system to be restored within 72 hours?

No. The specific 72 hour restoration provision is part of the proposed HIPAA Security Rule modernization. It is not a current universal requirement under the existing Security Rule.

Should my healthcare business wait for the proposed HIPAA changes before improving security?

No. The current HIPAA Security Rule remains in effect. Existing requirements already address areas such as risk analysis, security incidents, contingency planning, access controls, audit controls, and authentication. Known technical risks do not need to remain unaddressed simply because additional regulatory changes are being considered.

Is putting our files in the cloud the same as having Disaster Recovery?

No. Cloud services can improve resilience in some scenarios, as they did when this client's damaged computer did not result in the loss of the files that had already been moved to the cloud. But cloud storage does not replace a complete recovery strategy. Computers, networking, internet access, phones, physical facilities, cloud services, backups, and other dependencies still need to be considered.

Are healthcare cyberattacks mostly a problem for hospitals and large health systems?

No. Healthcare cyber risk extends across regulated healthcare providers, health plans, and business associates. HHS reported 663 large breaches occurring in 2024 that affected approximately 242.9 million individuals, with hacking and IT incidents accounting for 81 percent of those large breaches.

ADDITIONAL RESOURCES

U.S. Department of Health and Human Services, Office for Civil Rights:Guidance on Risk Analysis

Current HHS guidance explaining the HIPAA Security Rule risk analysis requirement and the importance of understanding risks to the confidentiality, integrity, and availability of ePHI.

U.S. Department of Health and Human Services:Summary of the HIPAA Security Rule

An overview of the current Security Rule and its administrative, physical, and technical safeguards.

U.S. Department of Health and Human Services:HIPAA Security Rule Notice of Proposed Rulemaking Fact Sheet

HHS information about the proposed Security Rule modernization, including proposed requirements involving asset inventories, network maps, MFA, Incident Response, backup and recovery, testing, and restoration procedures.

U.S. Department of Health and Human Services, Office for Civil Rights:Annual Report to Congress on Breaches of Unsecured Protected Health Information for Calendar Year 2024

OCR's official report documenting 663 large breaches affecting approximately 242.9 million individuals in 2024.

U.S. Department of Health and Human Services:Security Rule Guidance Material

Additional HHS guidance addressing HIPAA Security Rule implementation, cybersecurity, risk management, and protection of ePHI.

CARF International:About CARF

Information about CARF International, its accreditation role, history, and work across health and human services.

CARF International:Behavioral Health Accreditation

Information about CARF accreditation for behavioral health and related health and human service programs.