← All documentation

Risk analyses

A risk analysis is a formal, documented, point-in-time analysis of the threats to your systems and the data they use, following the NIST SP 800-30 Rev 1 method: a standalone document you can hand an auditor. Each analysis serves one program:

  • an AI governance risk analysis, of your AI systems and the data they use;
  • the HIPAA security risk analysis (offered while a HIPAA assessment is): the Security Rule requires of a covered entity or business associate: "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate" (45 CFR § 164.308(a)(1)(ii)(A)). Its scope starts from your systems that handle ePHI, which you then edit to cover every place ePHI is created, received, maintained or transmitted, and each scenario can cite the Security Rule standard it concerns. Home's first steps tick "Complete your security risk analysis" once one holding at least one threat scenario is approved. Approving it records your own review: whether it is the analysis the rule requires is for your organization to decide.

The analysis is not the whole standard. The same standard also requires risk management (45 CFR § 164.308(a)(1)(ii)(B), Required): "Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a)." The decisions and recommended controls recorded here plan that work; carry it out and track it in the risk register and remediation tasks. Add to register on a scenario's row adds it to the risk register as a risk: its likelihood and impact, its residual ratings where both are given, its decision as the treatment and its recommended controls as the treatment notes. A scenario from a HIPAA analysis starts in the safeguard area its citation names (the administrative area when it names none of § 164.308 to § 164.316, and the Privacy Rule safeguards for a Privacy Rule section), and one from an AI governance analysis starts as Secure and resilient; change the category on the risk. Add to register asks for an optional owner (an active member who is not an auditor) and due date, and for a scenario you mitigate or avoid it offers a remediation task to track the work (ticked for Mitigate, unticked for Avoid; an accepted or transferred scenario takes none). The task is one per risk, with its priority set from the risk score, and it is assigned to the owner chosen when it is made, so the owner finds it under their own tasks; with no owner it is unassigned until the risk is given one, when it takes that owner (a task already assigned to someone is never moved). The same option is on the risk's own page. To add several at once, tick their rows and choose Add selected to the register, or choose Add every scenario not yet in the register; each becomes its own risk once, and a remediation task is made for each Mitigate scenario while Also create a remediation task for each Mitigate scenario is ticked (bulk sets no owner or due date: set them on each risk). Above the scenarios, the analysis says how many are in the register and how many high or very high scenarios are not; that count is for you to act on and does not change the compliance score. A scenario is added once, and its row then links to the risk, and the risk names the analysis and the level the analysis gave the scenario (the register bands its own score differently). That holds across revisions: a revision's copy of a scenario already in the register links to the same risk and is not added again, and a revision does not change the risk's ratings, which are managed on the risk. Deleting the scenario keeps the risk; while a revision still holds its copy, the risk links to that copy instead. The risk's description and treatment notes carry the scenario's asset, threat and recommended controls, so everyone who can read the risk register can read them; the vulnerability and the existing controls stay in the analysis, which members, and auditors whose grant includes the risk register, read but only admins change.

The Risk Register is the ongoing ledger of individual risks (AI risks, and HIPAA risks to ePHI), each linked to the system it is about where there is one; a risk analysis is a formal document built from threat scenarios, and Add to register carries a scenario from one to the other.

An analysis of one system (HIPAA)

A HIPAA security risk analysis can also be scoped to a single system that handles ePHI: choose the system under Analysis of on the New analysis form, or Start a risk analysis of this system on the system's record (an administrator's). Use it when that system changes in a way that affects the ePHI it holds. The Documentation standard's Updates implementation specification asks you to "Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information" (45 CFR § 164.316(b)(2)(iii), Required), and the Security Rule's general rules ask you to review and modify your security measures as needed and update their documentation accordingly (45 CFR § 164.306(e)). Carry what the analysis finds into your organization-wide analysis (Open a revision of it). The guided analysis proposes that system's scenarios alone.

Backsplice does not treat an analysis of one system as your organization's security risk analysis: it covers one system, and the rule's analysis covers all the ePHI you hold. It does not complete Home's step, count in the Risk Analysis part of the HIPAA score, or set Your year's next review; carry what it finds into your organization-wide analysis, which should still cover the system. The scope is set when the analysis is created, a revision keeps it, and the system's record lists its analyses.

Building an analysis

Create an analysis with a title, description, and scope (the system boundary it covers), plus a target review date. It starts in draft.

Then add threat scenarios, one per row. A scenario may name the system in your Systems register it is about (optional; the guided analysis names it for you on every scenario it proposes for a system), and a risk added from the scenario starts with the same system and shows on that system's record. Like its ratings, the risk's system is then managed on the risk: changing the scenario's system later does not move a risk already added. Each captures the asset, the threat source and threat event, the vulnerability, the existing controls, and a likelihood and impact (1–5) — the risk score is their product, mapped to a level from very low to very high, both computed from the ratings and never typed. Record the risk decision (mitigate / accept / transfer / avoid), the recommended controls, the residual likelihood and impact once those controls are in place (both or neither; their product is the residual score), and a citation: type any reference, or pick one from the list (a NIST AI 600-1 risk, or on a HIPAA analysis a Security Rule standard or implementation specification).

The guided analysis (HIPAA)

A HIPAA security risk analysis does not start blank. Creating one opens the guided analysis, and Suggest scenarios on the analysis page (a draft or one in review) opens it again at any time. It matches a library of threat scenarios, written from the NIST SP 800-30 threat events for a health care organization, to what you have recorded:

  • each system that handles ePHI (ransomware, stolen credentials, a workforce member viewing records without a work reason, an outage, a breach or failure at the vendor that hosts or supports it, and, unless the system is used as a service, an unpatched vulnerability),
  • each device in use that may hold ePHI (a lost or stolen laptop, an unlocked unattended screen, malware, disposal), and
  • your organization as a whole (phishing, an email account takeover, remote access, a misdirected message, an unreported incident, a business associate's breach, a fire or flood, a departed workforce member's access).

Each proposal carries a threat source and event, the vulnerability, recommended controls, the Security Rule provision those controls address, and a starting likelihood and impact. The ratings follow what you recorded: a laptop recorded as not encrypted starts with a higher impact than an encrypted one, and a device with no automatic screen lock a higher likelihood. They are a starting point. Nothing is selected for you: tick each scenario that applies, change any rating, and Add selected scenarios; each becomes an ordinary scenario of the analysis, which you edit, decide and approve on its page. A scenario already in the analysis (the same asset and threat event) is shown as added and is not added again. Systems and devices you have not recorded are not proposed, so record where your ePHI lives first, under Systems and Devices.

The citation names where to look in the Security Rule; it is not a finding that the provision is met or missed. Recommended controls are measures to consider, not Security Rule requirements, and an addressable implementation specification may be met by a documented equivalent. Using the library does not by itself make the analysis the one the rule requires. That remains your organization's judgment.

Lifecycle & export

An analysis moves Draft → In review → Approved → Archived. It records who prepared it, and approving it records who approved it and when; an analysis with no threat scenario cannot be approved, and reopening an archived one as a draft clears its approval. An approved or archived analysis's threat scenarios are locked: none can be added, edited or deleted, so the scenarios under an approval are the ones that were approved. Adding an approved analysis's scenarios to the risk register still works. To review an approved analysis, choose Open a revision on it: a new draft is opened with its title (marked "(revision)"), description, scope, methodology and every threat scenario copied, and the approved analysis stays in force, its threat scenarios as they were approved, until the revision is approved (then archive it). Its title, description and scope stay as approved too (an archived one's until it is moved back to draft); its review date can still be changed. Print / PDF produces an audit-ready version of the finished document. There's no automatic recurrence — set a review date and revisit it on your own cadence (annually is typical). For HIPAA, the Security Rule sets no fixed interval. The Documentation standard's Updates implementation specification requires: "Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information" (45 CFR § 164.316(b)(2)(iii), Required).

Who can do what

Creating and editing risk analyses is org-admin only. Every member can open an analysis and read it; an auditor can open one only when their grant includes the risk register scope. The document is meant to be authored deliberately, not generated — you enter the threat scenarios that reflect your environment.