Build a programme around the handling of patient information
HIPAA compliance is an ongoing responsibility to apply the requirements relevant to an organisation’s role, information and activities. For a regulated healthcare provider or service business, the practical objective is to control how protected health information is used, disclosed, secured and recovered, and to make defensible decisions when something goes wrong. A useful programme connects legal interpretation with everyday work: reception, clinical care, claims processing, technical support, system administration, procurement and patient requests.
Begin with three questions. Why does the organisation have the information? Which people and systems can act on it? What would happen if it were exposed, changed or unavailable? The answers determine the scope of assessment and the people who need to participate. Starting with a purchased policy pack often leaves these questions unresolved. Starting with a network diagram alone can miss paper intake forms, recorded calls, exported spreadsheets and the contractor who handles exceptions outside the main application.
The Privacy Rule addresses protected health information (PHI) across relevant forms and establishes rules for its use, disclosure and individual rights. The Security Rule focuses on electronic PHI, commonly called ePHI. Breach notification adds a separate decision and reporting framework. These are connected responsibilities, but a security tool does not decide whether a disclosure is legally permitted, and a signed contract does not demonstrate that access actually works as intended. Summary of the HIPAA Privacy Rule Summary of the HIPAA Security Rule Breach Notification Rule
This guide offers implementation methods for security leaders, operations managers and buyers of HIPAA support. Examples are hypothetical, not customer case studies. Suggested review frequencies, project phases and technical patterns are planning recommendations unless a specific legal requirement is identified. An organisation should obtain appropriate legal advice on its status, difficult disclosures, contracts, state-law obligations and incidents; the implementation team should bring organised facts to those decisions.
Use the rule in effect, and track proposals separately
This guide reflects the legal baseline reviewed on 12 October 2026. The eCFR Security Rule page displayed text current through 8 October 2026, and HHS’s Security Rule summary, last reviewed on 7 August 2026, explicitly describes the rule currently in effect. Both retain the distinction between required and addressable implementation specifications. Addressable does not mean that an organisation can ignore the safeguard without analysis. 45 CFR Part 164, Subpart C Summary of the HIPAA Security Rule
HHS issued a proposal in December 2024, published in the Federal Register in January 2025, to strengthen the Security Rule. Proposed changes include more prescriptive approaches to encryption, multifactor authentication, inventories and testing. HHS’s proposal fact sheet states that the current rule remains effective during rulemaking. This guide therefore does not present the proposal’s annual audit, particular testing intervals or proposed restoration deadline as existing universal legal duties. Recheck the rulemaking before approving a programme baseline or publishing a legal update. HIPAA Security Rule NPRM fact sheet
A practical change register should distinguish four things: current legal requirements, contractual commitments, organisational security standards and anticipated regulatory changes. A hospital might already require multifactor authentication because its risk analysis and security policy support that choice. A customer might impose a shorter incident-reporting period in a business associate agreement. Those are meaningful obligations or decisions without being mislabelled as a newly effective federal rule.
Privacy developments also require careful dating. HHS’s updated reproductive-health rule notice reports that a June 2025 court order vacated most of the 2024 rule while leaving some notice-of-privacy-practices changes in place, with a February 2026 compliance date. Do not copy a 2024 checklist and assume every provision remains enforceable. Specialist review is particularly useful for sensitive records, substance use disorder information and disclosures connected with litigation or law enforcement. Reproductive Health Care Privacy final rule fact sheet
Determine your role before selecting controls
HIPAA does not regulate every organisation that happens to possess health-related information in the same way. Covered entities include health plans, healthcare clearinghouses and healthcare providers that conduct specified electronic transactions. A business associate performs certain functions or services involving PHI for a covered entity; relevant subcontractors can also be business associates. Analyse the actual service relationship rather than using an industry label as the answer. Covered Entities and Business Associates Business Associates
Prepare a short role record for each material service. Identify the contracting legal entity, the customer, the business activity, the reason PHI is needed and the relationship to the customer. Distinguish direct patient services from services delivered for another regulated organisation. If one group runs a consumer wellbeing application and a separate clinical platform for hospitals, those activities may require different analyses. A single marketing statement that the whole company is covered can hide important differences in data handling and legal responsibilities.
Map boundaries at the point where work changes hands. Does a support team merely help install software without receiving PHI, or does it examine live records and retain screenshots? Does a hosting provider maintain encrypted ePHI even though it cannot decrypt it? HHS’s cloud guidance explains why a no-view arrangement can still create business associate responsibilities. Encryption changes risk; it does not automatically remove the provider’s legal role. Guidance on HIPAA and Cloud Computing
When status is uncertain, record the uncertainty and restrict the proposed data flow while the facts are reviewed. Useful questions are concrete: who supplies the records, who determines the purpose, who can query them, who keeps copies and who selects subcontractors? An applicability review should produce an agreed boundary and a change trigger, such as adding managed support, accepting a new customer type or introducing record storage. Keep that conclusion close to contracting and product approval so it is revisited when the service changes.
Follow information beyond the clinical application
A reliable information map begins with activities, not just an inventory of software. Follow an appointment from intake through the consultation, referral, billing, support, archiving and eventual disposal. For each handoff, record what information moves, why it moves, who receives it and where additional copies appear. An apparently simple scheduling process may create reminders, calendar entries, call recordings, analytics events, troubleshooting logs and vendor support attachments.
Use a manageable record structure: process owner, source, destination, record type, purpose, access roles, transfer method, retention rule and supplier. Add whether the data is part of a designated record set used to make decisions about individuals, because patient access work may depend on records held outside the main electronic health record. HHS confirms that the right of access can extend to information maintained by a business associate on the covered entity’s behalf. Access to PHI maintained by a business associate
Interview the people who handle exceptions. Ask a billing analyst to show how a rejected claim is investigated, using a safe demonstration record. Ask a technical support analyst where diagnostic attachments are saved. Ask a clinic manager what happens during a network outage. These conversations often reveal the gap between the approved workflow and the workaround staff use to keep services moving. Improve the workflow instead of merely telling people to stop doing something they still need to accomplish.
Validate the map with evidence such as system configuration, storage listings, contract scope and sampled transactions. Avoid copying patient records into the mapping workbook. A field description and representative synthetic example are usually enough to explain the flow. Give each data flow an owner who can approve changes. A diagram that cannot identify its author, evidence date or responsible service becomes a historical illustration rather than a dependable input to risk analysis.
Design permitted use and disclosure decisions
The first privacy question is whether a particular use or disclosure is permitted or required. The next questions concern the amount of information, recipient verification, channel and record of the decision. Reducing a dataset does not make an otherwise impermissible disclosure acceptable. Conversely, a disclosure that is legally permitted may still need stronger operational safeguards to prevent an error in execution. The Privacy Rule’s permission structure and its individual-rights provisions must be reflected in actual workflows. 45 CFR Part 164, Subpart E
Create separate routes for common categories rather than sending every request to a single generic inbox. A treatment communication, patient access request, insurer enquiry, legal demand, research request and marketing proposal are different events. A front-line worker should know which route to use and what details to capture. The privacy lead should be able to see deadlines, missing information and questions that need legal interpretation without reviewing every routine message personally.
For repeatable disclosures, design an approved dataset and recipient check. For unusual requests, require a documented assessment before release. A release-of-information team can keep a decision record containing the request, identity verification, authority, scope, approved output, delivery method and completion time. The purpose is to explain the decision later without turning the record itself into an unnecessarily large copy of the patient’s file.
Build individual rights into systems early. Can staff locate records held by suppliers, produce a readable copy, route an amendment request and identify who handles a complaint? A business associate’s response process should support the covered entity’s obligations and the contract’s allocation of work. A technically secure platform can still cause privacy failures if it cannot locate or return relevant records promptly. Test a representative request from receipt to completion, including the point where work leaves your organisation.
Limit information to the work that requires it
The minimum necessary principle generally requires reasonable efforts to limit relevant uses, disclosures and requests for PHI to what is needed for the purpose, subject to important exceptions. For example, it does not apply to disclosures to or requests by a healthcare provider for treatment, or to an individual’s access to their own information. Those exceptions should be taught accurately; a blanket slogan to share as little as possible can obstruct legitimate care or patient rights. Minimum Necessary Requirement
Translate the principle into job design. A payment follow-up team may need account status, dates and relevant claim information but not unrestricted access to every clinical narrative. A technical support engineer may need an error code and transaction identifier rather than a complete clinical note. Start with the task, identify the decisions the person must make, and then identify the fields required to make those decisions. Ask the process owner to validate whether the reduced view still supports accurate work.
Pay particular attention to exports. A well-designed screen can coexist with a report button that downloads the entire patient table. Review report permissions, spreadsheet templates, shared folders and attachments separately from application access. Where practical, use purpose-specific reports and remove unnecessary fields before information leaves the controlled system. Monitor whether staff recreate broader exports because the approved report is missing a field they legitimately need.
An exception route matters. If an analyst needs additional information for a particular claim, record the reason, authorisation and duration rather than broadening the entire team’s access indefinitely. The organisation should be able to distinguish occasional justified access from a permanent design flaw. Review exceptions for patterns: repeated requests for the same data may indicate that the base role needs redesign, while requests that never lead to useful work may indicate avoidable exposure.
Connect risk analysis to funded action
Risk analysis asks what could compromise the confidentiality, integrity or availability of ePHI in the organisation’s actual environment. Risk management determines what to do about those risks and whether the resulting protection is reasonable and appropriate. The Security Rule requires both. A control checklist can help organise a review, but it does not replace the analysis of threats, vulnerabilities, existing safeguards and consequences. HHS guidance describes key elements without prescribing one universal scoring method. Guidance on Risk Analysis
Write risks as plausible events. For example: a former outsourced worker retains a valid remote session and downloads claim attachments because account termination does not reach the customer platform. This is more useful than a line reading access control: medium. It identifies an actor or event, a weakness, an affected workflow and an outcome. Evidence might include an account sample, termination tickets and session settings; assumptions should be labelled when the facts are incomplete.
Consider integrity and availability as carefully as confidentiality. A laboratory interface that silently drops results can affect care even if nobody steals data. A ransomware event that blocks appointment information may disrupt treatment and create unsafe manual processes. A backup that cannot restore a required database is a material weakness despite an attractive dashboard showing successful jobs. Use service owners to assess consequences, because security teams may not know which delay or alteration matters most operationally.
For each material risk, choose an action, accountable owner, target date, temporary measure and verification method. Leadership should see unresolved risk and the consequences of delayed work. A decision to defer a costly replacement should state what compensating measures are possible and what event will force reconsideration. Calling a risk accepted does not cancel an applicable legal duty. Close the item when evidence demonstrates the intended protection, then retain enough history to explain what changed and why.
Make administrative safeguards operational
Administrative safeguards connect people, decisions and systems. They include the security management process, assigned security responsibility, workforce security, information access management, training, incident procedures, contingency planning, evaluation and business associate arrangements. The current regulation sets these responsibilities at 45 CFR 164.308. Implementing them means creating reliable work routines, not simply collecting documents bearing the same headings. 45 CFR Part 164, Subpart C
Assign a security official with authority to obtain information and escalate unresolved issues. Identify the operational owners beneath that role: human resources for workforce changes, application owners for permissions, facilities for physical access, procurement for suppliers and clinical operations for service continuity. A responsibility chart should clarify who decides, who performs the work and who checks completion. Giving every task to the security official creates a bottleneck and obscures the responsibilities of the people who run the service.
Build security steps into existing processes. A hiring workflow can trigger role-specific access and training. A supplier onboarding request can trigger classification, a contract review and a data-flow assessment. A system change can trigger review of logging, recovery and support access. An offboarding ticket can follow the worker through identity accounts, physical badges, customer systems and retained devices. Integration with real work is more durable than a separate compliance reminder that staff can forget.
Management reporting should surface decisions. Useful measures include overdue high-risk actions, unowned systems, access removals that missed the organisation’s target, suppliers with unresolved agreements, failed recovery exercises and incident lessons not yet implemented. Explain what each measure means and what decision it should trigger. A rising number of reported near misses may reflect better reporting rather than deteriorating behaviour, so discuss causes before assigning blame or celebrating a favourable percentage.
Protect the places and devices where work happens
Physical safeguards apply wherever ePHI can be accessed or stored, including offices, clinics, equipment rooms and remote work settings. The Security Rule addresses facility access, workstation use and security, and device and media controls. Cloud hosting does not eliminate local responsibilities: staff may still view records on home monitors, save attachments to laptops or print lists for a temporary clinic. 45 CFR Part 164, Subpart C
Walk through actual work areas with the process owner. Check screen visibility, visitor movement, shared workstations, unattended printers, storage cabinets and disposal arrangements. A reception desk needs a design that permits efficient patient interaction while avoiding unnecessary exposure to other visitors. A support floor may need separate visitor access and supervised maintenance. Evaluate how the design works during busy periods, when staff are most likely to bypass inconvenient steps.
For devices, maintain enough information to connect ownership, configuration, movement and disposal. An organisation should know who received a laptop, whether it is managed, what happens if it is lost and how the device is recovered or retired. When equipment changes hands, verify that the approved removal or sanitisation process actually occurred. A certificate from a disposal supplier is more useful when it identifies the devices and the service performed rather than making a broad untestable promise.
Remote work needs explicit boundaries. Define approved devices, private workspace expectations, printing restrictions, local storage rules and reporting routes for loss or accidental disclosure. Discuss difficult situations such as a shared household workspace or an unexpected office closure. Technical controls can reduce some risk, but staff still need a workable plan. Provide an approved alternative when an employee cannot meet the conditions, rather than assuming an acknowledgement form has resolved the exposure.
Use technical controls as a connected system
Technical safeguards should make approved behaviour possible and unauthorised behaviour difficult to perform or conceal. The current Security Rule includes access control, audit controls, integrity, authentication and transmission security. Some implementation specifications are required; others are addressable under the rule’s documented assessment process. Avoid equating a product feature list with compliance, because effectiveness depends on configuration, coverage, people and follow-up. 45 CFR Part 164, Subpart C
Start identity design with named users and clearly owned service accounts. Link access to a business role, use stronger authentication where the risk warrants it, and separate routine work from privileged administration. Ensure a worker leaving one organisation loses access to every relevant customer system, not just the employer’s email account. Test dormant sessions and integration tokens as well as passwords, because an apparently disabled account may not terminate every route to the information.
Encryption decisions should address stored information, network transmission, backups, portable devices and exported files. Key access, recovery and rotation require ownership. Encryption does not prevent a legitimate account from misusing data after decryption, so it must sit alongside authorisation and monitoring. Log useful events, protect the logs and establish who reviews them. A large log archive with no defined review process offers limited operational value when the team needs to reconstruct a disclosure.
For every major control, ask what a successful test would show. An access test might demonstrate that a claims worker cannot read another customer’s records. A transmission test might verify a secure integration and identify a failing legacy route. A logging test might show who exported records and when. These tests should use synthetic or appropriately protected data and avoid disrupting clinical services. Keep findings connected to remediation, with a retest after material changes.
For a closer look at safeguard ownership and evidence, use our HIPAA Security Rule guide alongside the programme decisions described here.
Turn supplier agreements into working relationships
A business associate agreement establishes important restrictions and obligations, but it must describe the real relationship. HHS publishes sample provisions addressing matters such as permitted uses, safeguards, reporting, support for individual rights, subcontractors and termination. Those samples are not a complete negotiated contract for every situation. Legal and operational reviewers should work together so the agreed terms can actually be performed. Business Associate Contracts
Before onboarding a supplier, identify the specific services and features that will handle PHI. A platform may offer an agreement for some services while excluding others. Confirm the relevant legal entity, account tier, subprocessors, support model and data locations. Ask how the supplier provides incident information, retrieves a customer’s records, removes a departing customer’s data and supports recovery. Vague assurances are less useful than a clear allocation of tasks and supporting evidence.
Use a shared responsibility record. For example, a cloud provider may secure underlying infrastructure while the customer configures permissions and applications; a managed service provider may administer access but rely on the client to send timely staff changes. Document the dependency on each side and test the handoff. When nobody is explicitly responsible for a task, it can be omitted even though both parties believe it is covered by the agreement.
Plan for exit before the relationship becomes critical. Identify export formats, retrieval time, transition assistance, remaining backups and continuing protections where immediate destruction is infeasible. Review suppliers when the service changes or new evidence raises concern. An annual questionnaire may be useful for some relationships, but a merger, new support location or material incident may justify earlier review. The review should result in decisions about continued use, additional safeguards, restricted data flows or a transition.
Where a supplier hosts or supports ePHI, our HIPAA cloud-services guide develops the responsibility matrix, customer configuration and exit questions.
Separate response, breach assessment and notification
A security incident requires prompt operational attention, but not every incident is automatically a reportable HIPAA breach. Conversely, an impermissible disclosure should not be dismissed merely because no malicious attacker is involved. HHS describes a presumption of breach for an impermissible use or disclosure unless an applicable exception or a documented assessment supports a low probability that PHI was compromised. The assessment considers the information, recipient, actual acquisition or viewing, and mitigation. Breach Notification Rule
Prepare an intake process that staff can use without first determining legal significance. Capture what happened, when it was noticed, affected services, immediate safety concerns and available evidence. Involve security, privacy, operations and legal advisers as appropriate. Preserve useful records while containing harm. Avoid destroying evidence through hasty reinstallation or asking staff to conduct their own uncontrolled investigation of patient information.
Maintain separate clocks for discovery, containment, assessment and notification. HIPAA notification rules commonly use an outer limit of 60 days for relevant notices, together with a requirement to act without unreasonable delay; that is not an invitation to wait. Business associate agreements may impose earlier reporting. HHS reporting treatment differs for breaches affecting fewer than 500 individuals, and media notification has its own threshold. The incident team should use the applicable rule and contract, not a single number copied onto every playbook. Breach Notification Rule
An incident record should explain decisions, uncertainties and changes in understanding. If early facts suggest ten people are affected and later evidence suggests more, preserve both the initial assessment and the reason for revision. After recovery, convert lessons into specific work: a missing log source, a broad export permission, an unclear supplier contact or a failed identity check. An incident is not fully addressed merely because the service is running again.
Treat recovery as a patient information workflow
The current Security Rule includes requirements for data backup, disaster recovery and emergency mode operation, with addressable specifications for testing and revision and for applications and data criticality analysis. A backup product is one component of the response. The programme must consider how authorised staff will obtain reliable information and protect it while normal systems are unavailable. 45 CFR Part 164, Subpart C
Map recovery priorities to services. A clinic may need current medication information and appointments before it needs a historical analytics warehouse. A claims processor may need the latest transaction state to avoid duplicate submissions. Ask service owners what data loss and interruption would mean in practice, then use those answers to set recovery objectives. Do not adopt a vendor’s default retention or recovery promise without comparing it with the workflow’s needs.
Test dependencies, not just files. Recovery may require identity services, encryption keys, network configuration, software licences, supplier support and staff who are not immediately available. A restored database that cannot be accessed by authorised users has not restored the service. A restored application that cannot reconcile transactions performed during downtime may introduce integrity problems. Include reconciliation and controlled return to normal operations in the exercise.
Protect the emergency process itself. Temporary paper records, shared emergency accounts and offline extracts can create new exposure. Decide how such information is secured, entered into the main system, checked for accuracy and disposed of when no longer needed. Record exercise findings in plain terms: what failed, how the failure affected the service, who will correct it and what evidence will show improvement. The next test should deliberately revisit the weak dependency.
Maintain records that explain what happened
Evidence should connect a requirement, an implemented process and an observed result. A policy shows the intended rule. An approval shows a decision. A system setting shows configuration at a point in time. A log or completed ticket shows an event. A review record shows that someone examined the result and acted on it. Treating all these items as interchangeable can produce a large library that still cannot answer a straightforward question.
The Security Rule’s documentation requirements include retention for six years from creation or the date last in effect, whichever is later, for the specified documentation. This is not a universal statement that every patient record, log or backup must be kept for six years. Those categories require their own retention analysis, including other laws, contracts, operational needs and litigation holds where relevant. Summary of the HIPAA Security Rule
Use a small evidence catalogue with an owner, source, period covered, sensitivity, retention rule and retrieval location. Avoid uploading unnecessary patient information into a compliance platform. For an access review, the meaningful evidence may be a controlled account report, the reviewer’s decisions and the completed removals. A screenshot of a dashboard without a date or scope may be much less useful. Restrict evidence access, because investigation reports and technical records can themselves be sensitive.
Test retrieval periodically. Ask someone outside the daily process to locate a prior agreement, policy version or recovery result. If they cannot determine which version applied at the time, improve version control. If a supplier is the only party holding an essential record, establish how it will be obtained. Good records help operations learn and respond; they should not exist only for an imagined future auditor.
Hypothetical example: a clinic group changes its appointment platform
Consider a fictional clinic group moving to a hosted scheduling and patient messaging service. The initial project plan treats the change as a software migration. A data-flow review reveals that appointment reasons enter reminder templates, the call centre downloads daily lists and the vendor’s support tool accepts screenshots. The risk is wider than the database transfer because information will also move through messages, support cases and staff workstations.
The project team first separates decisions. The privacy lead reviews what information is appropriate in each message and how patient preferences are handled. Procurement confirms the service scope and agreement with the relevant vendor entity. Security examines roles, authentication, logging and integration access. Clinical operations defines how staff will work during the cutover and how incomplete bookings will be reconciled. Each person has a distinct contribution instead of signing a single ambiguous approval sheet.
The team changes the design before migration. Reminder templates omit unnecessary clinical detail. Call-centre roles receive a limited view, with a route for authorised escalation. Support staff use synthetic demonstration records when possible and an approved secure process when real information is necessary. The migration plan includes an access removal step for the old supplier and a decision about retained data, rather than assuming cancellation of the subscription deletes everything.
Validation follows the patient journey. The team creates test appointments, sends messages to controlled addresses, exercises a failed interface, checks a record export and rehearses recovery of a booking after a short outage. It also tests what a departing staff member can still access. The outcome is a documented set of decisions, configuration evidence and unresolved issues for leadership. No certificate is needed to make those improvements concrete, and no certificate would substitute for them.
Hypothetical example: a healthcare BPO adds a night shift
A fictional billing services company supports several healthcare customers from an offshore operations centre. To cover an additional time zone, it proposes a night shift with some staff working from home. The customer applications remain hosted in the United States, but workers can view PHI abroad. The organisation should analyse the full processing arrangement, including remote access, local handling and contractual conditions. Server location alone does not describe where information is used.
The programme owner gathers facts before promising readiness. Which customers allow this operating model? Which workers need which accounts? Can the virtual desktop prevent local downloads and still support the required task? Are calls recorded, and where are recordings processed? Who can approve emergency access during the night shift? The legal and privacy teams review contractual and jurisdictional questions, while security and operations evaluate the practical safeguards. HHS guidance recognises that overseas services can introduce particular risks that need consideration. Guidance on HIPAA and Cloud Computing
The company pilots the shift with a small authorised team. Accounts are individual and customer-specific. Supervisors receive a process for unusual claims rather than a shared privileged login. Staff practise reporting a misdirected attachment and a lost device. Incident contacts include an available customer route, and the team tests escalation outside normal office hours. Technical restrictions are checked with representative work so staff are not forced into personal messaging or local spreadsheets to meet service targets.
The evidence package contains the agreed scope, customer conditions, role approvals, training outcomes, configuration checks and pilot findings. A remaining limitation in the recording system is recorded with an owner and interim restriction. Expansion waits for the affected customers’ requirements to be satisfied. The example illustrates an operational decision: a new shift changes access, supervision and response capability even when the underlying application is unchanged. Reusing last year’s assessment without examining those changes would miss the central risk.
Sequence the work by dependencies and exposure
A useful roadmap begins with scoping and immediate risk reduction. Confirm the organisational role, identify material PHI flows and assign decision owners. At the same time, address obvious urgent exposure such as uncontrolled public sharing, abandoned privileged accounts or an inability to report incidents. Do not defer a known serious issue merely because the full assessment is still being written. Preserve the decision and evidence so early action can be incorporated into the programme record.
The next phase should connect risk analysis, requirement mapping and implementation. Prioritise dependencies: an accurate workforce list improves access review; an information map improves backup coverage; clear supplier scope improves contract and incident planning. Group work into achievable changes with named owners and acceptance criteria. A task such as improve access is too vague; a task that identifies the systems, prohibited condition and verification method can be scheduled and reviewed.
Then exercise the programme. Run a patient request through the supplier chain, an access removal through every relevant platform, an incident through the escalation route and a restoration through the business workflow. Include people who will actually perform the work. A tabletop discussion can expose unclear decisions, while a controlled technical test can expose configuration failures. Use both where appropriate, and distinguish a discussion result from a demonstrated technical capability.
Ongoing compliance requires a rhythm matched to change and risk. Review material system changes, new services, supplier changes and incident lessons. Keep leadership informed of unresolved matters and choices requiring resources. There is no universal project duration that makes a complex healthcare environment compliant. A credible engagement explains its scope, evidence, limitations and ongoing responsibilities so the organisation can decide what to improve next.
Build the next review around testable findings and dependencies with our HIPAA gap-assessment guide.
Buy deliverables and capability, not a government certificate
When selecting external support, request a proposal that identifies the services, legal entities, locations, systems and rules in scope. Ask what information the assessor will examine, who will be interviewed and how findings will be prioritised. Distinguish an assessment from implementation assistance, contract advice, technical testing and ongoing operation. These services can complement one another, but a buyer should know which outputs are included and who owns the remaining work.
HHS does not endorse or recognise private Security Rule certifications, and obtaining one does not remove legal obligations or prevent a later finding of a violation. An independent evaluation can still be useful when its scope, method, evidence and limitations are clear. The meaningful question is what the evaluation establishes about the organisation’s actual practices, not whether the cover page resembles a certificate. Are we required to certify compliance with the Security Rule?
Evaluate sample deliverables using practical questions. Can a department owner understand and act on a finding? Does the risk analysis cover the environment rather than a generic checklist? Can the implementation team trace an action to the evidence needed for closure? Will the organisation retain editable records and enough knowledge to maintain the programme after the engagement? Ask how unresolved legal questions and technical limitations are reported rather than allowing them to disappear inside an overall score.
Software may help track tasks, versions, training and evidence if its capabilities fit the workflow and its handling of sensitive information is appropriate. Training can improve staff decisions if it uses relevant roles and scenarios. Neither should be purchased on the assumption that a tool or course automatically confers HIPAA compliance. Start with the problem to be solved, verify the offered capability and agree how success will be demonstrated in the healthcare service.
Reference basis
HHS: Summary of the HIPAA Privacy Rule; HHS: Summary of the HIPAA Security Rule; HHS: Breach Notification Rule; eCFR: 45 CFR Part 164, Subpart C; HHS: HIPAA Security Rule NPRM fact sheet; HHS: Reproductive Health Care Privacy final rule fact sheet; HHS: Covered Entities and Business Associates; HHS: Business associates; HHS: Guidance on HIPAA and Cloud Computing; HHS: Access to PHI maintained by a business associate; eCFR: 45 CFR Part 164, Subpart E; HHS: Minimum Necessary Requirement; HHS: Guidance on Risk Analysis; HHS: Business associate contracts; HHS: Security Rule certification FAQ.
Frequently asked questions
Does every company with health information have to comply with HIPAA?
No. Applicability depends on the organisation, its activities and its relationship to a covered entity, among other facts. A consumer service, employer, healthcare provider and outsourced processor can have different roles. Document the facts and obtain a role determination before assuming a particular set of HIPAA duties. Other privacy or security laws may still apply.
Does addressable mean optional?
No. Under the current Security Rule, an addressable specification requires assessment of whether the safeguard is reasonable and appropriate. If it is, implement it. If it is not, document the reason and implement an equivalent alternative where reasonable and appropriate. A silent omission is not a documented assessment.
Can a business associate rely entirely on its customer?
No. Business associates have direct responsibilities under applicable HIPAA provisions as well as contractual responsibilities. The parties should allocate practical tasks, but neither should assume the other operates every safeguard. Test the boundaries between customer notifications, supplier actions and the resulting evidence.
Is the 2024 Security Rule proposal already the current rule?
No. As of the official-source review on 12 October 2026, the existing Security Rule remained in effect and the 2024/2025 changes were still identified as proposed. Recheck official sources when updating the programme, because later rulemaking or court decisions can change the applicable requirements.
What should a first HIPAA assessment produce?
At minimum, a useful engagement should clarify scope and assumptions, show the evidence reviewed, explain material gaps and risks, and assign practical follow-up actions. The deliverables should distinguish verified findings from unresolved questions. The exact assessment scope must be agreed; a brief questionnaire is not equivalent to testing an entire environment.
Can we use an external assessment as proof that nothing can go wrong?
No. An assessment is bounded by its scope, timing and evidence. New systems, staff changes, suppliers and incidents can change the position. Use the report to improve decisions and demonstrate the work performed, while continuing the organisation’s own monitoring, review and corrective action.
Discuss the next practical step
To define an integrated HIPAA programme, bring your service boundary, main information flows and unresolved management decisions to a scoping discussion. The useful starting deliverable is an agreed assessment and implementation scope, with responsibilities and evidence requirements.
Explore CyberVantage360 HIPAA assessment and implementation services, or contact CyberVantage360 to discuss your priorities.