Security Risk Assessment Checklist for a State Hospital Discharge Data Program

A state hospital discharge data program may receive, maintain, analyze, or release sensitive patient-level information. Use this checklist to identify and reduce risks to electronic protected health information (ePHI), while confirming which federal and state requirements apply to each organization and data flow. HIPAA obligations depend on the parties’ roles and circumstances; a state program should not assume that every dataset or participant has the same obligations. The HHS Office for Civil Rights’ Security Rule risk analysis guidance explains the risk-assessment framework for covered entities and business associates.

Who should lead the security risk assessment?

Assign a clearly accountable lead, such as the program’s security official or information security officer. If the program is a HIPAA covered entity or business associate, the Security Rule requires it to identify a security official responsible for developing and implementing security policies and procedures. See 45 CFR § 164.308.

Build a cross-functional team so the assessment reflects both the data’s technical environment and its legal uses. Include, as appropriate:

• The discharge-data program director and data governance lead.
• Information security, IT, privacy, and records-management staff.
• Legal counsel familiar with state health-data and confidentiality laws.
• Hospital, data-submitter, research, and vendor representatives who understand the data they handle.

• ☐ Confirm who owns the assessment, approves risk decisions, and tracks follow-up work.
• ☐ Identify which organizations are covered entities, business associates, public health authorities, or other recipients, as applicable.
• ☐ Define the assessment scope, including systems, people, vendors, facilities, and data exchanges.

How should the program inventory and analyze discharge data risks?

Start by mapping the full data lifecycle: collection from hospitals, transfer, validation, storage, analysis, access by staff or contractors, release, archival, and deletion. Inventory the systems and services involved, including databases, file-transfer tools, cloud environments, workstations, backups, test environments, and vendor platforms. HHS guidance describes risk analysis as evaluating threats and vulnerabilities that could affect the confidentiality, integrity, and availability (CIA) of ePHI, along with the likelihood and potential impact of harm. See the HHS explanation of risk analysis and risk management.

• ☐ Record data elements, identifiers, sensitivity, source, owner, format, location, and retention period.
• ☐ Document how data moves between hospitals, the program, vendors, analysts, and approved recipients.
• ☐ Assess risks such as misdirected files, stolen credentials, ransomware, excessive staff access, re-identification, data corruption, outages, and vendor incidents.
• ☐ Estimate likelihood and impact, considering privacy harms as well as loss of data integrity or availability.
• ☐ Record existing safeguards, remaining risk, and the person responsible for each follow-up action.

Revisit the assessment when material changes affect the data or its environment, such as a new vendor, system migration, new disclosure purpose, or significant incident. HIPAA requires periodic evaluation and evaluation in response to environmental or operational changes for covered entities and business associates; it does not set one universal annual risk-assessment interval. Consult 45 CFR § 164.308 and the HHS Security Rule summary.

How can access to confidential data be controlled?

Limit access to the data and functions each person needs for an approved job. Use role-based permissions, unique user accounts, prompt access changes when responsibilities change, and prompt account removal when access is no longer authorized. For systems subject to HIPAA, unique user identification and emergency access procedures are required; access controls must restrict ePHI to authorized users. See 45 CFR § 164.312.

• ☐ Approve access through a documented process and review permissions on a defined schedule.
• ☐ Separate duties for data intake, identity management, analysis, release approval, and system administration where practical.
• ☐ Use strong authentication, monitor access logs, and investigate unusual or high-risk activity.
• ☐ Encrypt sensitive data at rest and in transit, and protect encryption keys. Under HIPAA, encryption specifications are addressable, so regulated organizations must assess whether and how to implement them and document their decisions; addressable does not mean ignore the risk.
• ☐ Provide secure emergency access procedures and test them without granting routine users unnecessarily broad access.

Review access to production data in test, training, and analytics environments, too. Where possible, use de-identified or synthetic data for tasks that do not need identifiable records.

What procedures should govern data requests and disclosures?

Use a consistent request-review process before releasing confidential data. Require the requester to identify the purpose, legal authority, requested variables, population, time period, intended users, security arrangements, and planned retention or destruction. Review the request against applicable state law, program authority, privacy rules, and any restrictions attached to the source data. HIPAA’s public-health disclosure permission applies in specified circumstances, including disclosures to a public health authority legally authorized to receive the information for public-health purposes; it is not a blanket authorization for any request. See HHS guidance on public health disclosures.

• ☐ Determine whether the request can be met with aggregate, de-identified, or less detailed data.
• ☐ Where HIPAA’s minimum necessary standard applies, limit the request or disclosure to what is reasonably needed for its purpose, subject to the rule’s exceptions. See HHS minimum necessary guidance.
• ☐ Require documented approval and record what was released, to whom, for what purpose, and when.
• ☐ Use a data-release agreement to define permitted uses, safeguards, redisclosure limits, incident reporting, retention, and destruction when appropriate under program policy or applicable law.

A data-release agreement is not automatically required for every data exchange under HIPAA; the applicable agreement depends on the parties, data, purpose, and legal basis. For example, a HIPAA limited data set generally requires a data use agreement, which specifies permitted uses and safeguards. HHS explains that in a particular limited-data-set/business-associate scenario, the data use agreement may satisfy the required assurances without a separate business associate agreement. Check 45 CFR § 164.514 and the HHS FAQ on limited data sets and agreements.

How should the program respond to suspected security incidents?

Give staff and vendors a clear way to report suspected incidents immediately, including lost devices, misdirected files, unusual account activity, ransomware, or an unauthorized disclosure. Assign incident roles in advance so responders can contain the event, preserve relevant evidence, assess affected systems and data, and coordinate communications.

• ☐ Contain the incident while preserving logs, messages, affected files, and other evidence.
• ☐ Determine what data and individuals may be affected, who accessed or received the data, and whether the information was acquired or viewed.
• ☐ Maintain a breach incident log recording the report, timeline, investigation, decisions, mitigation, and notifications or reasons notification was not required.
• ☐ Escalate suspected exposure of identifiable health information to privacy and legal leads promptly to assess applicable federal, state, contractual, and program notification duties.
• ☐ Review whether access should be suspended, credentials reset, or data recipients asked to secure or destroy exposed files.

Not every security incident is a reportable HIPAA breach. For an impermissible use or disclosure of unsecured protected health information, HIPAA’s Breach Notification Rule includes a presumption of breach unless an applicable exception applies or the responsible covered entity or business associate demonstrates a low probability that the information was compromised through a risk assessment. Required notices generally must be made without unreasonable delay and no later than 60 days after discovery, subject to the rule’s specific requirements. See the HHS Breach Notification Rule guidance. Check state law and agreements as well, since they may impose separate duties.

How can risks be mitigated and remediation verified?

Convert each material finding into a remediation plan with a named owner, target date, priority, and evidence needed to close the issue. Choose safeguards based on the risk and the program’s environment; HHS distinguishes risk analysis, which identifies and evaluates risk, from risk management, which implements measures to reduce it. See the HHS risk analysis and risk management guidance.

• ☐ Prioritize fixes according to the sensitivity of the data, likelihood of exposure, potential impact, and existing safeguards.
• ☐ Address gaps through measures such as narrower permissions, encryption at rest and in transit, secure file transfer, improved monitoring, tested backups, vendor changes, or staff procedures.
• ☐ Verify completion with evidence: test results, updated access records, configuration reviews, restore tests, or signed agreement updates.
• ☐ Reassess residual risk after mitigation and document any accepted risk, its approver, and the reason for acceptance.
• ☐ Retain required security policies, procedures, and compliance documentation according to applicable retention rules; HIPAA documentation requirements generally include a six-year retention period for covered entities and business associates. See the HHS Security Rule summary.

A reliable checklist connects clear ownership, a complete data inventory, controlled access, careful disclosure review, incident documentation, and verified remediation. Keep the assessment current as the program’s data, systems, partners, and legal obligations change.

FAQs.

Who should be responsible for a state hospital discharge data security risk assessment?

A designated security official or information security lead should coordinate the assessment with program leadership, privacy, IT, legal counsel, data governance, and relevant hospital or vendor contacts. If the program is a HIPAA covered entity or business associate, HIPAA requires a designated security official; the program should also identify any additional state-law or agency responsibilities.

How often should the program review its security risks and safeguards?

Review risks periodically and whenever a meaningful change or incident could affect the data or safeguards. HIPAA requires periodic evaluation and reassessment in response to relevant environmental or operational changes, but does not prescribe one universal annual frequency. Set a schedule appropriate to the program’s risk, and document the reason for any review cadence.

What should be documented after a suspected data breach?

Document the report and timeline, affected systems and information, people or organizations involved, investigative steps, evidence preserved, risk assessment, mitigation, decisions about notification, and any notices sent. A breach incident log is a useful way to maintain this record. HIPAA-regulated organizations must be able to show that required notices were provided or that notification was not required under the applicable rule.

When is a data-release agreement needed?

Use an agreement when required by applicable law, program policy, or the relationship and purpose of the disclosure, and to establish limits and safeguards for recipients. Under HIPAA, a limited data set generally requires a data use agreement; a business associate relationship may require a business associate agreement, though HHS identifies a limited-data-set scenario in which the data use agreement can provide the required assurances. Confirm the specific agreement with privacy and legal reviewers before release.