What we handle automatically. What stays yours.

The rule asks for 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 entity.

Patient Protect provides a guided security risk assessment, scores the answers, and retains the resulting documentation.

What that does not establish That the assessment has been conducted, or that it covered the ePHI the practice actually holds. The obligation is on the entity, and an unanswered assessment discharges nothing.

Your practice complete the assessment, review it against how the practice really runs, and repeat it when something material changes.

The rule asks for Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

Patient Protect implements security measures within its own environment and tracks remediation items raised by the assessment.

What that does not establish That the practice's risks have been reduced to a reasonable level. Most of a practice's ePHI lives in systems Patient Protect does not run.

Your practice decide and implement measures across the practice's own systems, and record why each was chosen.

The rule asks for Apply appropriate sanctions against workforce members who fail to comply with the entity's security policies and procedures.

Patient Protect holds the policy document and records workforce acknowledgement of it.

What that does not establish That sanctions exist or have been applied. Disciplining a person is an employment act; no platform performs it.

Your practice adopt a sanction policy and apply it when someone breaches it.

Onboarding attestation: “I understand that HIPAA violations result in disciplinary action”

The rule asks for Implement procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports.

Patient Protect records activity in its own system and surfaces it for review.

What that does not establish That the review has happened, or that it covers the practice's other information systems. Producing a log is not reviewing it, and OCR has said the rule does not set the interval — that follows from the entity's own risk analysis.

Your practice decide a review cadence from the risk analysis, carry it out, and cover the systems Patient Protect cannot see.

The rule asks for Identify the security official responsible for developing and implementing the entity's security policies and procedures.

Patient Protect provides a Security Officer role to assign, and records who holds it.

What that does not establish That a security official has been designated. Creating an account does not appoint anyone; someone has to be named.

Your practice name the security official and record the designation.

Onboarding attestation: “I understand who our designated Security Officer is”

The rule asks for Implement procedures for the authorization and/or supervision of workforce members who work with ePHI or in locations where it might be accessed.

Patient Protect scopes what each user can reach inside Patient Protect by role.

What that does not establish Authorization or supervision across the practice's other systems, or in the physical locations where ePHI can be seen.

Your practice assign roles deliberately, and extend the same discipline to systems and rooms Patient Protect does not control.

Onboarding attestation: “I agree to maintain confidentiality of all PHI I access”

The rule asks for Implement procedures for terminating access to ePHI when a workforce member leaves or their access is no longer appropriate.

Patient Protect removes a user's access to Patient Protect when the practice deprovisions them.

What that does not establish That access has been terminated. The platform cannot know someone has left until the practice tells it, and it cannot revoke access to systems it does not run.

Your practice deprovision promptly on departure, here and everywhere else the person had access.

The rule asks for Implement policies and procedures for granting access to ePHI, for example through access to a workstation, transaction, program or process.

Patient Protect grants access by role within its own environment.

What that does not establish Access authorization for the practice's other systems.

Your practice define who should have access to what, and apply it everywhere ePHI lives.

The rule asks for Provide periodic security updates to the workforce.

Patient Protect publishes current breach and enforcement intelligence, refreshed daily, and training material the practice can circulate.

What that does not establish That the workforce has received periodic updates. Material existing is not the same as it reaching people.

Your practice circulate updates on a cadence and record that you did.

The rule asks for Implement procedures for monitoring log-in attempts and reporting discrepancies.

Patient Protect monitors log-in attempts to Patient Protect and alerts on unrecognized ones.

What that does not establish The specification, even inside our own environment. It has two limbs, and we carry one of them cleanly: attempts are monitored. Reporting discrepancies terminates in someone at the practice receiving the report and doing something about it, and the specification asks for a procedure — an organizational artifact — not only a mechanism that emits alerts. It also says nothing about log-ins to the practice's other systems.

Your practice decide who receives these alerts and what they do about one, and apply equivalent monitoring to the other systems that hold ePHI.

The rule asks for Implement procedures for creating, changing and safeguarding passwords.

Patient Protect enforces credential rules for Patient Protect accounts.

What that does not establish The specification, even inside our own environment. Creating and changing are things a system can enforce. Safeguarding is mostly what people do with a credential once they have it — writing it on a note, reusing it elsewhere, sharing it with a colleague at the front desk — and no server-side rule reaches any of that. Nor does it reach the rest of the practice's systems.

Your practice adopt a password procedure covering how credentials are handled, not only how they are formed, and apply it everywhere ePHI is reachable.

Onboarding attestation: “I understand our password requirements and why they matter”

The rule asks for Identify and respond to suspected or known security incidents; mitigate their harmful effects to the extent practicable; and document incidents and their outcomes.

Patient Protect provides the incident documentation workflow, and records security events in its own system.

What that does not establish Identification or response for incidents elsewhere in the practice. Our defensive tooling protects Patient Protect, not the practice's network or endpoints.

Your practice run an incident procedure covering the whole practice, and document what happened and what was done.

The rule asks for Establish policies and procedures for responding to an emergency or other occurrence that damages systems containing ePHI.

What that does not establish A contingency plan for the practice. The plan has to cover the practice's own systems and its ability to operate without them.

Your practice write, test and maintain a contingency plan for the practice's environment.

Onboarding attestation: “I know our emergency and contingency procedures for ePHI systems”

The rule asks for Perform periodic technical and nontechnical evaluation of how well the entity's security policies and procedures meet the Security Rule.

Patient Protect keeps compliance state current as risks are opened and closed, and retains the evidence an evaluation would draw on.

What that does not establish That an evaluation has been performed. This is a periodic organizational exercise, not a state a platform holds.

Your practice evaluate the program periodically and record the result.

The rule asks for Obtain satisfactory assurances, documented through a written contract, that a business associate will appropriately safeguard ePHI.

Patient Protect tracks agreements, their status and renewal, and gates messaging on whether a BAA is in place.

What that does not establish That the practice holds satisfactory assurances from every business associate it uses. We can only track relationships the practice tells us about.

Your practice identify every business associate, obtain the agreement, and keep it current.

Onboarding attestation: “I agree to the terms of this Business Associate Agreement”

The rule asks for Implement a security awareness and training program for all members of the workforce, including management.

Patient Protect provides the training curriculum, assigns it, and records completion per workforce member.

What that does not establish That the workforce has been trained. Assignment is not completion, and an attestation that training was completed is a statement by the person making it.

Your practice run the program, including for management, and keep the completion record current as people join.

Onboarding attestation: “I have completed security awareness training”

The rule asks for Implement procedures for guarding against, detecting and reporting malicious software.

Patient Protect covers phishing and malicious software in the training curriculum.

What that does not establish Protection of the practice's endpoints and network, which is where malicious software actually arrives.

Your practice put endpoint protection and a reporting path in place across the practice's own devices.

Onboarding attestation: “I understand how to identify and report suspicious emails or software”

The rule asks for Implement policies and procedures to address security incidents.

Patient Protect provides the procedure template and the place to record incidents, and captures workforce acknowledgement of the reporting path.

What that does not establish That the practice has adopted procedures, or that anyone would follow them. An acknowledgement records what a person said they knew on a date.

Your practice adopt incident procedures and make sure the workforce can actually execute them.

Onboarding attestation: “I know how to report a security incident in our office”

The rule asks for Implement policies and procedures to limit physical access to electronic information systems and the facilities housing them, while ensuring properly authorized access is allowed.

What that does not establish Anything. Locks, keys and who can walk into the server closet are outside any software's reach — and this standard was absent from all three surfaces, which described themselves as covering the safeguards.

Your practice control physical access to the facility and to the systems inside it, and write the procedure down.

The rule asks for Implement policies and procedures specifying the proper functions to be performed, the manner of performing them, and the physical attributes of the surroundings of workstations that can access ePHI.

Patient Protect captures a dated attestation from each workforce member about their own workstation surroundings.

What that does not establish That workstations are sited safely. Someone attesting that their screen cannot be overlooked is evidence of what they believe, not of the policy this standard asks the practice to write.

Your practice write the workstation-use policy, and confirm the physical reality against it.

Onboarding attestation: “I confirm my workstation is positioned to prevent unauthorized viewing of PHI, and I do not leave PHI visible when I am away from it”

The rule asks for Implement physical safeguards for all workstations that access ePHI, to restrict access to authorized users.

Patient Protect captures a dated attestation that the workforce member locks their workstation when stepping away.

What that does not establish That physical safeguards exist. The standard asks for safeguards on the workstation, which is a physical act in a physical room.

Your practice put physical safeguards on every workstation that can reach ePHI.

Onboarding attestation: “I confirm I lock my workstation when stepping away”

The rule asks for Implement policies and procedures governing the receipt and removal of hardware and electronic media containing ePHI into, out of and within a facility.

Patient Protect holds the device policy and records that workforce members have read it.

What that does not establish That hardware and media movement is controlled. No software tracks a laptop leaving the building.

Your practice govern device and media movement, and keep the record this standard's implementation specifications require.

Onboarding attestation: “I understand the policies for PHI on mobile devices”

The rule asks for Implement policies and procedures addressing the final disposition of ePHI and of the hardware or electronic media on which it is stored.

Patient Protect holds the disposal procedure and records workforce acknowledgement of it.

What that does not establish That devices have been disposed of properly. This specification is required, and it is discharged by what happens to the hardware.

Your practice dispose of devices and media under a written procedure, and record what was destroyed and when.

Onboarding attestation: “I understand the procedures for disposing of devices containing PHI”

The rule asks for Implement technical policies and procedures for electronic information systems that maintain ePHI, to allow access only to those persons or software programs granted rights.

Patient Protect controls access to ePHI held in Patient Protect by role.

What that does not establish Access control over the practice's other electronic information systems, which the standard also covers.

Your practice apply access control to every system maintaining ePHI, not only this one.

The rule asks for Assign a unique name and/or number for identifying and tracking user identity.

What that does not establish Unique identification in the practice's other systems, which is where shared logins usually survive. Note too what our own evidence reaches: we can show seats are sold and managed one per workforce member, which is a commercial fact rather than proof that the authorization layer refuses a shared credential or attributes each action to the person who took it. Attribution is the point of this specification, so the claim waits until someone can read the authentication model or run a controlled account test.

Your practice eliminate shared accounts everywhere ePHI is reachable, which is where they usually survive.

The rule asks for Establish and implement procedures for obtaining necessary ePHI during an emergency.

What that does not establish Anything. This specification is required and was absent from all three surfaces that claimed to enumerate the technical safeguards — which is the clearest evidence that the list was assembled from our features rather than from the rule.

Your practice decide how clinicians reach necessary ePHI in an emergency, and write it down.

The rule asks for Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

Inside Patient Protect terminates idle Patient Protect sessions automatically.

What that does not establish Session termination in the practice's other systems. This specification is addressable, so the practice must still assess it and either implement it elsewhere or document why an alternative is reasonable.

Your practice assess idle-session risk across the practice's systems and act on the assessment.

Onboarding attestation: “I confirm automatic logoff or screen lock is enabled on my devices”

The rule asks for Implement a mechanism to encrypt and decrypt ePHI.

Inside Patient Protect encrypts ePHI at rest in Patient Protect.

What that does not establish Encryption of ePHI held elsewhere. And the rule does not name a cipher — it is addressable, so the entity assesses whether encryption is reasonable and appropriate and documents the decision either way.

Your practice assess encryption for the practice's own stores and record the conclusion.

The rule asks for Implement hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

Patient Protect records activity against ePHI held in Patient Protect.

What that does not establish Audit coverage of every information system in the practice that contains or uses ePHI. We receive no activity data from other vendors.

Your practice ensure the practice's other systems record and examine activity too.

The rule asks for Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

What that does not establish Integrity corroboration for ePHI held elsewhere.

Your practice assess integrity mechanisms for the practice's other stores.

The rule asks for Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.

Inside Patient Protect verifies identity before granting access to Patient Protect. Multi-factor authentication is our implementation of that verification.

What that does not establish Authentication in the practice's other systems. And the standard does not name a mechanism: it requires verifying identity, so MFA is our choice rather than a HIPAA requirement. All three surfaces labeled this specification 'Authentication (MFA)', which reads the implementation back into the rule.

Your practice verify identity wherever ePHI is reachable, by whatever mechanism the risk analysis supports.

The rule asks for Implement a mechanism to encrypt ePHI whenever deemed appropriate.

Inside Patient Protect encrypts ePHI in transit to and from Patient Protect.

What that does not establish Encryption of the practice's other transmissions. Addressable again — the rule says 'whenever deemed appropriate', which puts the judgement on the entity.

Your practice assess transmission encryption across the practice's own channels.

The rule asks for Make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of a use, disclosure or request.

Patient Protect limits what each role can reach inside Patient Protect, which constrains one class of internal use.

What that does not establish Minimum-necessary judgement across the practice's uses, disclosures and requests. Deciding how much to disclose to a given recipient for a given purpose is a human decision made case by case.

Your practice apply minimum-necessary reasoning to disclosures and requests, and train the workforce to make it.

Onboarding attestation: “I understand I should only access or disclose the minimum PHI necessary”

The rule asks for Have appropriate administrative, technical and physical safeguards to protect the privacy of PHI, and reasonably safeguard it from any intentional or unintentional impermissible use or disclosure.

Patient Protect provides safeguarded channels for the communication conducted inside Patient Protect.

What that does not establish Safeguards across the practice's privacy practices generally, including the physical ones — a screen facing a waiting room is inside this standard and outside any software.

Your practice put administrative, technical and physical safeguards in place across the practice.

The rule asks for A covered health care provider with a direct treatment relationship must make a good faith effort to obtain the individual's written acknowledgment of receipt of the Notice of Privacy Practices.

What that does not establish That the notice itself is compliant, or that it was provided. §164.520(b) governs what the notice must contain, and this specification only concerns the acknowledgement of having received it.

Your practice maintain a compliant notice, provide it at first service delivery, and document the attempt where acknowledgement is not obtained.

Onboarding attestation: “Patient acknowledges receipt of the Notice of Privacy Practices”

The rule asks for Designate a privacy official responsible for developing and implementing the entity's privacy policies and procedures.

Patient Protect provides a Privacy Officer role to assign, and prompts for it during setup.

What that does not establish That a privacy official has been designated. A workforce member attesting they know who holds the role does not appoint anyone.

Your practice designate the privacy official.

Onboarding attestation: “I understand who our designated Privacy Officer is”

The rule asks for Document the personnel designations required by §164.530(a)(1) and retain that documentation.

Patient Protect records and retains the designation once the role is assigned here.

What that does not establish The designation itself, which is §164.530(a)(1)(i) — this provision is the narrower documentation duty, and the onboarding matrix cited it for the designation. Nor does it document a designation the practice made elsewhere and never entered.

Your practice record the designation, and keep it current when the role changes hands.

The rule asks for Train all members of the workforce on the entity's PHI policies and procedures, as necessary and appropriate for them to carry out their functions.

Patient Protect delivers privacy training, distributes the policies, and records both completion and receipt.

What that does not establish That training was appropriate to each person's function, which is the judgement this standard actually asks for.

Your practice train the workforce on the practice's own policies, and retrain when those policies change materially.

Onboarding attestation: “I have been trained on our office's privacy policies, and I acknowledge receipt of our HIPAA privacy and security policies”

The rule asks for Provide a process for individuals to complain about the entity's privacy policies and procedures, or its compliance with them.

What that does not establish That a complaint process exists or that patients can reach it. The duty runs to individuals, not to the workforce.

Your practice establish the process, tell patients about it in the notice, and document complaints received.

Onboarding attestation: “I know how patients can file a privacy complaint”

The rule asks for Following discovery of a breach of unsecured PHI, notify each affected individual without unreasonable delay and no later than 60 days after discovery.

Patient Protect provides incident documentation workflow and the reference material behind the assessment.

What that does not establish That any required notification has been made.

Your practice assess whether a breach occurred and notify affected individuals within the deadline.

Onboarding attestation: “I know how to report a suspected breach of PHI”

The rule asks for Following discovery of a breach of unsecured PHI, notify the Secretary — contemporaneously for breaches affecting 500 or more individuals, and annually for smaller ones.

Patient Protect provides incident documentation workflow, and publishes the breach and enforcement record so a practice can see what has been reported.

What that does not establish That notification has been made. All three surfaces labeled this provision 'Breach Awareness' — a requirement that does not exist. §164.408 is a notification duty owed to the Secretary, not an awareness state a dashboard can put a practice into.

Your practice notify the Secretary on the timeline the breach size requires.

The rule asks for Apply the §164.530 administrative requirements to breach notification, and carry the burden of demonstrating that all required notifications were made, or that an impermissible use or disclosure was not a breach.

Patient Protect retains dated incident documentation, which forms part of the evidentiary record the burden is discharged with.

What that does not establish That the burden is met. And this is not the breach-reporting provision: the onboarding matrix labeled §164.414 'Breach Reporting', where notification duties live in §164.404, §164.406 and §164.408.

Your practice keep documentation sufficient to demonstrate either that notification was made or that no breach occurred.

The rule asks for Nothing. This provision states who the HIPAA rules apply to: health plans, health care clearinghouses, and health care providers who transmit health information electronically in connection with a covered transaction.

What that does not establish Anything, because there is no obligation here to establish. §160.102 defines scope, not duty, so it cannot be a covered requirement — and the onboarding matrix was counting it as one.

Your practice determine the practice's status under HIPAA, which decides which of the rules below apply at all.

Onboarding attestation: “I understand our office is a covered entity or business associate under HIPAA”