This section explains standards, regulations, and frameworks that may
affect human services technology. Case Management Guide does not create
industry standards — we explain established ones and point to their
authoritative sources.
Case Management Guide provides educational information and is not legal,
compliance, or security advice. Whether and how any standard applies
depends on your organization's specific circumstances.
HIPAA
Federal privacy and security rules for protected health information — which apply to some, not all, human services organizations.
Who should care: Organizations handling health information; anyone evaluating vendors that may store PHI.
What you need to know
HIPAA applies to "covered entities" — health plans, clearinghouses, and providers billing electronically — and their vendors. Many human services organizations are not covered at all; a behavioral health agency billing Medicaid almost certainly is.
If you are covered, a software vendor holding your client health data is your "business associate" and must sign a business associate agreement (BAA). No BAA, no deal.
Compliance is mostly about your organization — policies, training, risk analysis, and access decisions — not just software features. "HIPAA compliant software" is not a thing you can buy.
Even if HIPAA does not apply to you, other rules (42 CFR Part 2, FERPA, state law, funder contracts) may — "HIPAA doesn't apply" is the start of a privacy analysis, not the end.
Federal confidentiality rules for substance use disorder treatment records, stricter than HIPAA in important ways.
Who should care: Behavioral health and SUD treatment programs and their technology vendors.
What you need to know
Protects records created by federally assisted substance use disorder (SUD) treatment programs — a narrower scope than HIPAA, with stronger protections.
Stricter than HIPAA mainly in two ways: disclosures generally require the patient's written consent even where HIPAA alone would allow sharing, and records generally cannot be used against the patient in legal proceedings without a court order.
A 2024 federal rule aligned Part 2 more closely with HIPAA — one consent can now cover future treatment, payment, and operations uses, and breach notification and penalties now mirror HIPAA. Compliance became mandatory in February 2026.
Recipients of Part 2 records face redisclosure restrictions, so software serving SUD programs must be able to identify and protect these records rather than treating everything as one pool of data.
Federal law protecting the privacy of student education records.
Who should care: Youth and family programs that work with schools or handle education records.
What you need to know
Protects education records held by schools and education agencies that receive federal education funds — it binds the school, not your program directly.
Parents (and students themselves at 18) control access: most disclosures of education records require written consent or a specific legal exception.
For youth and family programs, the practical effect is on data sharing: getting attendance, grades, or records from a school partner usually requires consent forms or a data-sharing agreement that carries FERPA conditions with it.
Records your program creates about a young person are not FERPA records — but data you receive from schools keeps its protections.
An auditing framework in which an independent auditor examines a service organization's controls for security, availability, and related criteria.
Who should care: Buyers assessing a vendor's security posture; a SOC 2 report is evidence, not a government certification.
What you need to know
A SOC 2 is an independent auditor's report on a vendor's controls — evidence of security practices, not a government certification or a pass/fail license.
Type I examines control design at a single point in time; Type II tests whether controls actually operated over a period of months. Ask for Type II.
Security is the only required criterion — availability, confidentiality, processing integrity, and privacy are optional add-ons, so ask which were covered.
Ask to read the actual report (vendors usually share it under NDA). The exceptions and auditor notes tell you more than the badge on the website.
The Web Content Accessibility Guidelines — the widely referenced standard for making web software usable by people with disabilities.
Who should care: Anyone whose staff or clients use web software; often required in public-sector procurement.
What you need to know
The global reference standard for accessible web software, with three conformance levels — Level AA is the common target in policy and procurement.
Covers the things that determine whether staff and clients with disabilities can actually use a system: keyboard operation, screen-reader compatibility, contrast, focus visibility, forms, and error handling.
Often legally relevant: U.S. federal procurement (Section 508) maps to WCAG, many state and local contracts require it, and ADA claims frequently reference it.
When evaluating vendors, ask for an accessibility conformance report (ACR/VPAT) — and remember your clients, not just your staff, may use portals the vendor provides.
A voluntary framework of cybersecurity practices organized around core functions such as identify, protect, detect, respond, and recover.
Who should care: Organizations building a security program; useful shared vocabulary with vendors.
What you need to know
A voluntary framework, not a regulation — nobody "certifies" you against it, and there is no penalty regime.
Organizes security into core functions (govern, identify, protect, detect, respond, recover) that give small organizations a complete map of what a security program covers.
Its best use for human services organizations is as shared vocabulary: it structures security conversations with vendors, funders, and IT support.
It scales down: you choose a target profile appropriate to your size and risk rather than implementing everything at once.
Protecting data in transit and at rest so intercepted or stolen data remains unreadable — a baseline expectation for systems holding client information.
Who should care: Everyone evaluating case management software.
What you need to know
Two states matter: encryption in transit (protecting data moving between browser and server) and at rest (protecting stored data). Both should be standard in any modern system — not premium add-ons.
Encryption protects against intercepted or stolen data; it does nothing about a legitimate account being misused. Access controls and audit trails cover that side.
Ask vendors what is encrypted, to what standard (current TLS in transit; strong standard algorithms like AES-256 at rest), and whether backups are encrypted too.
Under rules like HIPAA, properly encrypted data that is lost or stolen may not be a reportable breach — one reason encryption is worth confirming in writing.
Records of who accessed or changed data and when — foundational for accountability, investigations, and many compliance regimes.
Who should care: Programs subject to funder, privacy, or health-data requirements.
What you need to know
An audit trail records who viewed or changed what, and when — it is how you answer "what happened?" after an incident, a dispute, or a monitoring visit.
Several regimes expect it: HIPAA's Security Rule requires audit controls for electronic health information, and many funders expect change history on client records.
Logs that can be edited or silently deleted are not audit trails. Ask whether logs are tamper-resistant and how long they are retained.
Ask whether views (not just edits) are logged — in sensitive programs, who looked at a record matters as much as who changed it.
Documented interfaces that let systems exchange data — increasingly important as programs coordinate across organizations.
Who should care: Organizations connecting case management to HMIS, EHRs, or reporting systems.
What you need to know
An API lets systems exchange data automatically — the difference between integration and staff re-typing data between an HMIS, an EHR, and a funder portal.
"Has an API" varies enormously: ask what data can be read and written, whether documentation is public, and whether API access costs extra.
Interoperability is also your exit strategy — the same openness that connects systems is what lets you take your data with you if you leave a vendor.
Data flowing through an API carries the same privacy obligations as stored data; integrations should appear in your privacy and security analysis, not around it.
When HIPAA applies to human services organizations, what covered entities and business associates are, why there is no such thing as automatically 'HIPAA compliant software' — and the questions to ask a vendor.