Frameworks and Controls

This page explains the Frameworks and Controls pages: what a clinic sees, what "Not applicable" means, and what each status means.

The idea in one minute

• A framework is a law or standard you have to meet. Today that is the HIPAA Security Rule.
• A framework is made of requirements: the specific things the law asks for, for example 164.312(d) Person or entity authentication. A requirement says what to achieve, not how.
• A control is the concrete thing your clinic does to meet requirements, for example Two-step verification is enforced for all users. Each control has an owner, a status, and, when it doesn't apply to you, a written reason.

One requirement usually needs several controls, and one control often covers several requirements.

When you turn on a framework, RiskFlow gives you a ready-made set of recommended controls, already linked to the requirements they help meet. They are your copies: you can rename them, give them owners, and mark the ones that don't apply. You can also add your own.

Who can do what

Role	Frameworks and Controls
ORG Admin	See everything, turn on frameworks, set owners, mark Not applicable, add and edit controls
ORG Auditor	See everything. Read-only
Other ORG roles	No access to these pages

These pages exist inside a clinic (ORG) workspace. MSP users reach them by switching into one of their clinics.

Each clinic sees only its own controls. Another clinic, even one managed by the same MSP, can never see your frameworks, controls or readiness.

Turning on HIPAA

1. Open Frameworks.
2. On the HIPAA Security Rule card, select Turn on.

RiskFlow copies the recommended controls into your workspace. You will see 0 of 48 requirements met. That is expected: nothing is checking your controls yet.

Turning a framework on a second time does nothing, and it never overwrites changes you've made.

Readiness

The readiness score is how close you are to meeting a framework:

requirements met ÷ requirements that apply to you, rounded down to a whole percent

For example, 12 of 48 requirements met, 25%. Only the 48 specific requirements are counted. The broader standards that group them are shown in the tree but don't add to the score. Requirements marked Not applicable leave the bottom of the fraction, so the score reflects only what applies to you.

Open a framework to see its requirement tree: each standard, the requirements under it, their status, and the controls that cover each one.

HIPAA distinguishes two kinds of requirement:

• Required: must be done.
• Addressable: do it, or write down why it isn't reasonable for you and what you do instead. Addressable does not mean optional.

Controls

Open Controls for the list of everything your clinic does. The list is sorted worst first, so it reads like a to-do list. Filter it by status, owner or framework, or search by name.

Open a control to see its guidance, its owner, and the requirements it covers.

Owners

The owner is the person who keeps the control passing. Pick anyone who belongs to your workspace. You can change or clear the owner at any time.

Custom controls

If your clinic does something the recommended list doesn't cover, select New control. Give it a name, an optional category, and choose the requirements it helps meet. A custom control shows a Custom badge, and appears under each requirement you linked it to.

You can change which requirements a control covers at any time, including for recommended controls. Custom controls can be deleted. Recommended controls can't be deleted. If one doesn't apply to you, mark it Not applicable instead.

What "Not applicable" means

Some controls don't apply to every clinic. For example, a clinic that doesn't act as a health care clearinghouse has no clearinghouse to isolate.

Marking a control Not applicable:

• needs a written reason, between 20 and 2,000 characters;
• records who approved it and when;
• stops that control counting toward readiness. A requirement is Not applicable only when every control covering it is. In that case it leaves the readiness total, and the score's denominator drops.

It is not a way to hide a failing control. The reason and approver stay on the control and in the audit log, where an auditor can read them.

Changed your mind? Select Undo N/A. The control applies again, and its status returns to Not started.

What each status means

Control status

Status	Meaning
Not started	Nothing is checking this control yet. Every control starts here.
Passing	Checks and evidence say it's working.
Failing	A check found a problem.
Needs evidence	Proof is missing or out of date.
Not applicable	Doesn't apply to your clinic. Reason and approver are recorded.

You can't set a status by hand, except by marking a control Not applicable. Statuses are worked out from checks and evidence.

note

Right now every control reads Not started, and your readiness will stay at 0% until the integrations and evidence features that feed controls are connected. Controls turn green as you connect systems and add evidence.

Requirement status

A requirement's status comes from the controls that cover it:

Status	Meaning
No coverage	No control covers it. Link an existing control or add a custom one.
Not applicable	Every control covering it is Not applicable.
Not met	At least one covering control is Failing.
Met	Every covering control is Passing or Not applicable.
In progress	Anything else: some controls haven't started, or need evidence.

Audit trail

Every change is recorded in the audit log under the Compliance category: turning on a framework, creating, editing or deleting a control, changing an owner, changing which requirements a control covers, marking and clearing Not applicable, and every status change. Status changes made by the system are labelled as such.

Open Audit log and filter by Compliance to review them.