Skip to main content
Patient Protect circular logo mark in purple and white used for site navigationPatient Protect

Defense · Security Alerts

The problem is rarely the incident. It is that nobody noticed it stopped being true.

The BAA that lapsed while the vendor kept working. The policy nobody adopted. The training assignment that never got made. Conditions do not announce themselves, and the practice that finds out during an investigation found out too late.

Included in Basic·Starting at $39/mo

HIPAA mapping

Where this fits in the HIPAA rules.

4 provisions this capability contributes to, each with the specific Security Alerts behavior behind it. The obligation stays with your practice — the mapping shows which part of the work the platform carries.

§164.308(a)(6)(i)

Security incident procedures

A required standard: implement policies and procedures to address security incidents. Note what it asks for — procedures. The platform gives those procedures somewhere to happen and something to act on, but writing them is your practice's obligation and no product discharges it.

§164.308(a)(6)(ii)

Response and reporting

Requires identifying and responding to suspected or known incidents, mitigating harmful effects to the extent practicable, and documenting incidents and their outcomes. Documenting is the part that gets skipped, and it is the part an event record exists to make ordinary rather than heroic.

§164.414(b)

Burden of proof

Places the burden on the covered entity to demonstrate that required notifications were made, or that an impermissible use or disclosure did not constitute a breach. Burden of proof means contemporaneous records, and a decision reconstructed months later carries very little of it.

§164.404(b)

Timeliness of notification

Individual notice without unreasonable delay and no later than sixty days after discovery. Discovery is a date somebody has to be able to name, which is why recording when an event was logged is not administrative detail — it is where the clock starts.

What it does

The incident you have to report started as something nobody wrote down.

Compliance does not usually fail loudly. A BAA reaches its expiry and the vendor keeps working. A policy is added to the set and nobody adopts it. A new hire is entered and no training assignment is ever made. Every one of those is a gap that opened on an ordinary Tuesday, and none of them will tell you. The practice finds out during an investigation, which is the most expensive possible way to find out.

Patient Protect keeps evaluating those conditions and surfaces the ones that should not persist. Alongside them sit the issues a person generated — a login that hit the lockout threshold, an attempt to reach something outside a role, a record opened outside the usual pattern, an acknowledgment skipped. Two sources, kept apart, because they need different responses: the first is usually a configuration, the second is usually a conversation.

What makes this more than a list is what closing one costs and what it produces. A condition closes itself when you fix it. An activity issue does not close until a named officer writes down what they concluded — which is §164.308(a)(6)(ii) performed on a Tuesday instead of reconstructed under subpoena. And either way the score moves, because an open issue is a documented gap. Resolution and evidence are the same act here, which is the part practices usually pay a consultant to do twice.

How it works

6 mechanisms keep Security Alerts working.

01

The platform watches conditions, not just events.

System-level issues are conditions that should not persist and that nobody would otherwise notice: a BAA that lapsed while the vendor is still active, a required policy past its adoption deadline, an information system with no encryption status recorded, a workforce member with no current training assignment. These are not notifications about something that happened. They are the platform noticing that something has quietly stopped being true.

02

Human issues need a named person to close them.

An issue arising from workforce activity does not auto-close. A designated role — usually the Security Officer or Privacy Officer — reviews it, documents the disposition, and marks it resolved. That is the §164.308(a)(6)(ii) response-and-documentation obligation performed as a routine rather than reconstructed later, and the disposition someone wrote at the time is the artifact that matters.

03

Conditions close themselves; judgements do not.

System-level issues close automatically when the underlying condition is fixed — renew the BAA and the issue goes. Activity issues stay open until a person decides what they were. The asymmetry is deliberate and it is the right one: housekeeping should not need a meeting, and a judgement about someone's behavior should never be closed by a background job.

04

The ratio is the signal, not the count.

A healthy office runs mostly system-level issues — housekeeping, expected. A rising share of workforce-activity issues is the thing worth looking at, because it usually means a training gap, a permission that is wrong, or behavior that deserves a conversation. Most products give you a number going up. This distinguishes the kind of up.

05

Closing an issue moves the score.

Open issues weigh on the Compliance Score as documented gaps, and security-sensitive ones weigh harder on the Security Score, which in turn pushes Office Threat. So resolution is not tidying a list — it is the same act that moves the number your practice is judged on. The two things a practice usually treats as separate chores are one chore here.

06

Every issue has a record behind it.

The count on the Scoreboard is the surface; the Event Log is the record, with the timestamps, the people involved and the documentation attached. For a breach-related matter that is also where the four-factor assessment, the notifications sent and any HHS submission live — one place, assembled as you go, rather than a folder built in a panic. An event can additionally be shared anonymously into the Patient Protect network; that toggle is off unless you turn it on.

Who this is for

Built for the practices that need it most.

Practices with nobody whose job this is.

There is no security operations team. There is an office manager who also does payroll. The realistic bar is not detection sophistication — it is whether the odd thing gets written down by the person who noticed it.

Practices that have had an incident and no record of it.

The uncomfortable version of this is a practice that handled something well and cannot prove it. Handled-and-undocumented and ignored look identical to an investigator eighteen months later.

Practices that need the sixty-day clock to be a real date.

If your answer to when you discovered it is a range, the notification analysis is already on the back foot. A logged date is worth more than a good memory.

What you get

5 outcomes you’ll feel in week one.

Two sources, not one list.

Person-generated and platform-detected need different responses.

Resolved and Reported kept separate.

So closing an item cannot be mistaken for discharging the duty.

Discovery has its own date.

Which is the date the sixty-day clock actually runs from.

Visible beside your standing.

Open issues sit on the Scoreboard, not in a console nobody opens.

Network sharing is opt-in.

Anonymous sharing is a toggle, and it is off by default.

FAQ

What people ask first.

6 questions cover most first-time evaluations. See all FAQs →

Does this monitor our network or our servers?
No. It observes activity inside Patient Protect. It does not watch your workstations, your network, your backups or your EHR, and it cannot — nothing hosted elsewhere can see software running on your premises without an agent you would have installed. Any product describing server health or intrusion detection for your estate is describing something with a component in your building.
What causes an issue to appear?
Two things. Conditions the platform evaluates about your account — a lapsed BAA against an active vendor, an overdue policy adoption, a system missing its encryption status, a workforce member without a current training assignment, a scheduled platform backup that did not complete. And activity that crossed a threshold — a login hitting the lockout limit, an attempt to reach something outside a role's scope, a record opened outside the usual pattern, an acknowledgment skipped. Exact thresholds are configuration we have not verified and are not going to guess at.
Where do alerts appear?
In the platform: as the Open Issues panel on the Compliance Scoreboard, as the Open Incidents metric card beside it, and in full in the Event Log. That is the delivery, stated exactly — in-app and surfaced on the dashboard. This page makes no claim about email, SMS or push notifications, and you should not assume any.
Does an open issue mean somebody did something wrong?
Usually not. Most events are legitimate activity that crossed a threshold — the clinician who mistyped a password three times, the manager who opened a record at an unusual hour for an ordinary reason. The value is not accusation, it is that somebody looked and wrote down what they concluded.
Is an event the same as a breach?
No, and the distinction is the most consequential one here. §164.402 defines a breach, and an impermissible use or disclosure is presumed to be one unless a four-factor risk assessment shows a low probability that PHI was compromised. That assessment is your practice's to perform and document. An event record is where the documentation lives; it is not the assessment.
Which plan includes it?
Basic.

What it does not do.

  • Alerts on activity inside Patient Protect, not on the practice's network or endpoints
  • No channel, cadence or trigger claims until the mechanics are verified

The odd thing on a Tuesday, written down while someone remembers.

Burden of proof is discharged with contemporaneous records. There is no way to make those later, which is the entire argument.