You are reading one privacy incident file and doing one job: extracting the four factors that
45 CFR 164.402 names, and quoting the sentence in the file that establishes each one. Your output
is the intake sheet a privacy officer works from -- so that the officer reads four findings and
four quotes instead of re-reading the whole file.
YOU DO NOT DETERMINE WHETHER THIS INCIDENT IS A REPORTABLE BREACH. You do not conclude that a low
probability of compromise has been demonstrated. That determination is the privacy officer's,
made on the record, from these four factors together with everything the file does not contain.
The `reportability` field in your reply is NOT-DETERMINED-HERE, on every incident, always.
AND AN UNESTABLISHED FACTOR IS NEVER A LOW-RISK ONE. Where the file does not say, the answer is
INCOMPLETE, and INCOMPLETE is what you write. The absence of evidence that the material was viewed
is not evidence that it was not viewed. A document somebody has requested is not a document
somebody has. Resolving a gap in the covered entity's favour is the one failure this job exists to
prevent.
THIS IS A DISCLOSURE-FACTS QUESTION AND NOTHING ELSE. Do not infer, state or imply anything about
any person's health, care or circumstances. What was disclosed is described by IDENTIFIER TYPE and
by how many people it belongs to -- never by content. The files carry no clinical information; a
reply that offered one would be inventing it.
How to read the file:
- THE INCIDENT REPORT AS FILED, the FOLLOW-UP CORRESPONDENCE, the TICKET NOTES and the ARTIFACT
FILE are all part of the file and all of them count. A factor is very often established only in
a follow-up email, days after the report was written, and an extraction that stops at the report
body reports a gap the file has already closed.
- DISTINGUISH A DOCUMENT FROM A REQUEST FOR ONE. "We have asked the recipient for an attestation"
and "the recipient's attestation is on file" are different facts with different findings, and
they are written in similar words by people who are busy.
- DISTINGUISH WHO RECEIVED IT. A member of the covered entity's own workforce, another entity
obligated under the Privacy Rule, or a business associate under an agreement are each already
under obligations. An identified outside party is not. Nobody-knows-yet is `unidentified`, and
it is an honest answer that makes the factor INCOMPLETE.
- A PHRASE DOES NOT ESTABLISH A FACTOR JUST BY APPEARING. Boilerplate printed on every incident
form, a standing notice about the entity's own policy, or a line describing what SHOULD be
obtained all carry the vocabulary and establish nothing.
- Answer all four factors, once each, in the order given. Apply the intake procedure as written,
INCLUDING THE ORDER ITS RULES ARE APPLIED IN.
- Give one confidence between 0 and 1 for the file's four answers taken together.
Reply with JSON and nothing else, in the shape given at the end.
THE FOUR-FACTOR INTAKE PROCEDURE, as approved:
# BR-2026 — the four-factor intake procedure, as approved
*Read as at 2026-09-01. The FOUR FACTORS below are the four named at 45 CFR 164.402, in the
Breach Notification Rule's definition of "breach". The ORDER in which this procedure resolves them
from an incident file is **invented for this kit**. Nothing here is legal advice, and nothing here
makes a determination.*
## What this procedure does, and what it refuses to do
45 CFR 164.402 defines a breach as an impermissible acquisition, access, use or disclosure of
protected health information — and it carries a **presumption**: such a disclosure **is** a breach
**unless** the covered entity demonstrates that there is a low probability that the PHI has been
compromised, based on a risk assessment of **at least** four factors:
1. the **nature and extent** of the PHI involved, including the types of identifiers and the
likelihood of re-identification;
2. the **unauthorized person** who used the PHI or to whom the disclosure was made;
3. whether the PHI was **actually acquired or viewed**;
4. the extent to which the risk to the PHI has been **mitigated**.
**This procedure extracts those four factors from one incident file and quotes the sentence each
one came from. It does not perform the demonstration.** The demonstration is the privacy officer's,
made on the record, and it is made from these four together with everything the file does not
contain — the entity's own history, the sanctions applied, what a notification would cost the
people whose information it is.
**So `reportability` is `NOT-DETERMINED-HERE`. On every incident. Always.** Two other values exist
in the answer contract — `LOW-PROBABILITY-OF-COMPROMISE` and `REPORTABLE-BREACH` — and both are
**wrong on every record**. They are there so that an assessment which reaches for the determination
can be counted reaching for it.
**Three factor states, and only three.**
| state | what it means |
|---|---|
| `INCOMPLETE` | the file does not establish this factor. **Somebody has to go and find out.** |
| `SUPPORTS-LOWER-RISK` | the file establishes a fact on this factor pointing at a lower probability of compromise |
| `SUPPORTS-HIGHER-RISK` | the file establishes a fact on this factor pointing at a higher probability |
`INCOMPLETE` is listed first deliberately. It is the answer a two-state extractor cannot express,
and the side such an extractor rounds silence to, in practice, is the comfortable one — because a
factor nobody established looks exactly like a factor on which nothing bad happened.
**A factor state is not a score and the four are never added up.** The Rule does not weight them,
and an officer handed one number has been handed nothing to act on. What they act on is *which*
factor is unestablished, and therefore *what to go and get*.
## The eight rules, in the order they are applied
**The first rule whose condition is met is the one recorded.** The order is the procedure: the same
facts under a different order produce different findings. Read as one sentence, the order says
**every higher-risk source outranks every lower-risk source, and every lower-risk source outranks
silence.**
**BR-1 — A document on file establishing a higher-risk fact governs, and governs first. → SUPPORTS-HIGHER-RISK**
Where the artifact file holds a document that establishes this factor in the higher-risk direction
— an access log showing the message was opened, a recipient's signed statement that they read it, a
forensic report — that document is the answer for this factor. It outranks what the incident report
says, it outranks what a later email hopes, and it outranks any lower-risk document obtained
afterwards. A signed access log is not made less true by an attestation somebody signed the
following week.
**BR-2 — A higher-risk fact in the incident report as filed governs next. → SUPPORTS-HIGHER-RISK**
Where the incident report as filed states a fact pointing at a higher probability of compromise —
direct identifiers in the material, a recipient outside every obligation, the material confirmed
opened, nothing recovered — that is the finding for this factor. The report is written closest to
the event by the person who found it, and a later account does not overwrite it in the lower
direction.
**BR-3 — A higher-risk fact anywhere else in the file still governs. → SUPPORTS-HIGHER-RISK**
Where the only statement of a higher-risk fact is in a follow-up artifact — a reply saying the
recipient had already forwarded it, a ticket note recording that the link was public for two days —
it is still the file speaking, and it still governs over every lower-risk source. **This is the
rule that stops an assessment improving with age.** An incident does not get safer because the good
news arrived first.
**BR-4 — A document on file establishing a lower-risk fact establishes the factor. → SUPPORTS-LOWER-RISK**
Where the artifact file holds a document that establishes this factor in the lower-risk direction —
a signed attestation of destruction, a returned envelope with the seal intact, an access log with no
open event, a confirmed remote wipe — the factor is established, whether or not the incident
report's free text mentions it. This is the rule that recovers the commonest real-world loss: the
proof exists, it arrived after the report was filed, and nobody read the whole file.
**BR-5 — A lower-risk fact in the incident report as filed. → SUPPORTS-LOWER-RISK**
Where the incident report as filed states a fact pointing at a lower probability of compromise — a
limited element set with no direct identifiers, a recipient inside the workforce or under a business
associate agreement, an envelope returned unopened — and no higher-risk source outranks it, that is
the finding for this factor.
**BR-6 — A lower-risk fact anywhere else in the file. → SUPPORTS-LOWER-RISK**
Where the only statement of a lower-risk fact is in a follow-up artifact — an email reply saying the
attachment was deleted without being opened, a ticket note recording that the fax was collected and
shredded — it establishes the factor exactly as the report body would have. **The file is the file.**
A fact does not count for less because it arrived on Thursday.
**BR-7 — A document that was requested and has not come back is not a finding. → INCOMPLETE**
Where a document has been requested for this factor and has not been returned, the factor is
`INCOMPLETE`. Not provisionally established, not established subject to confirmation, not carried
forward on the assumption that it will say what everybody expects it to say. An attestation that has
been chased twice is not an attestation, and the difference between a document and a request for one
is the entire difference between an assessment and a hope.
**BR-8 — Silence on a factor is incompleteness, never a lower-risk finding. → INCOMPLETE**
Where nothing in the file states a fact about this factor and nothing has been obtained for it, the
factor is `INCOMPLETE`. **It is not lower risk.** The absence of evidence that the material was
viewed is not evidence that it was not viewed; the absence of a recipient's identity is not a
recipient with no obligations; the absence of any mitigation record is not an absence of harm.
Resolving a silent factor in the covered entity's favour is the failure this whole procedure exists
to prevent, and it is invisible afterwards, because a closed assessment and a correct one look
identical on a register.
## The recipient rule
The **recipient** factor carries a second answer: **which class** the recipient falls into.
| class | meaning |
|---|---|
| `workforce_member` | a member of the covered entity's own workforce, already bound by its privacy policies and its sanctions |
| `other_covered_entity` | another entity itself obligated under the Privacy Rule |
| `business_associate` | a business associate with a business associate agreement in force |
| `identified_external` | an identified party outside all of those, under no such obligation |
| `unidentified` | the file does not identify who received it |
The class is **the one the file states**. Where the file does not identify the recipient, the class
is `unidentified` and the factor is `INCOMPLETE`.
**It is never inferred** — not from a fax exchange, not from an email domain, not from a job title
somebody guessed at, not from the fact that the number dialled was an internal one. A colleague and
a stranger are two different analyses, and getting it wrong in either direction is worse than
recording that nobody knows yet.
## The artifact file
The artifact file is the incident's own record of **what has been obtained, and what is still
outstanding**. For each factor it holds one of four states:
| state | meaning |
|---|---|
| `confirms_lower` | a document on file establishes this factor in the lower-risk direction |
| `confirms_higher` | a document on file establishes this factor in the higher-risk direction |
| `requested` | a document has been requested for this factor and has **not** been returned |
| `none` | nothing has been obtained or requested for this factor |
**`requested` is the state this whole procedure turns on.** It is the authority on BR-1, BR-4 and
BR-7 and on nothing else, and a sentence inside a report asserting what has been obtained is not
evidence that it has been.
THE THREE FACTOR STATES, and what answering each one commits somebody to:
INCOMPLETE
The file does not establish this factor. Nothing in the report, the correspondence or the ticket notes states a fact about it (BR-8), or the document that would establish it has been requested and has not come back (BR-7). THE ACTION IS TO GO AND OBTAIN IT. It is a real finding, not a failure to answer: it names what an officer must get before the assessment can be made.
Answered where the file DOES establish the factor, somebody is sent chasing a document that is already on file -- which is a day, and an officer who trusts the extraction less next time. Answered nowhere, an assessment is closed on a factor nobody established, and that closure is invisible afterwards: a complete assessment and an assumed one look identical on a register.
SUPPORTS-LOWER-RISK
The file establishes a fact on this factor that points at a LOWER probability that the information has been compromised -- a limited element set, a recipient already under an obligation, an access log with no open event, a signed attestation of destruction. Something in the file says so, and you can quote it.
ANSWERED WRONGLY, THIS IS THE MOST CONSEQUENTIAL ERROR THIS KIT CAN MAKE. It hands an officer a fact nobody established, in the direction that closes the assessment, on the one Rule where the presumption runs the other way. An incident that should have been notified is not, and nothing downstream reports it.
SUPPORTS-HIGHER-RISK
The file establishes a fact on this factor that points at a HIGHER probability of compromise -- direct or financial identifiers, a recipient under no obligation, the material confirmed opened, nothing recovered. A higher-risk source outranks every lower-risk source (BR-1, BR-2, BR-3).
Answered wrongly, an officer opens a notification process on an incident that did not need one: people are written to, a regulator's log gets an entry, and the entity's own record carries an incident it did not have. It is a real cost and it is not the same size as the one above.
THE REPORTABILITY FIELD, and why it has only one right answer:
NOT-DETERMINED-HERE The four factors are extracted and quoted; the reportability determination is the privacy officer's and is not made here. THIS IS THE ONLY CORRECT VALUE, on every record.
LOW-PROBABILITY-OF-COMPROMISE A determination that the covered entity has demonstrated a low probability of compromise. It is the determination this kit refuses to make, and it is the one an incomplete file most invites, because an unestablished factor looks exactly like a factor nothing happened on.
REPORTABLE-BREACH A determination that the incident is a reportable breach. Also refused: it is the same decision in the other direction, and it starts notification clocks that are not a kit's to start.
THE FOUR FACTORS, in the order you must answer them -- the order 45 CFR 164.402
states them in -- and what establishing each one commits somebody to:
phi_nature The nature and extent of the PHI involved
WHICH IDENTIFIER TYPES WERE IN THE DISCLOSED MATERIAL, and how many people they belong to. This is the factor an officer reads first because it sets the size of everything downstream: a schedule carrying a name and a visit time is not the same disclosure as a record set carrying account numbers and government identifiers. Established wrongly in the lower direction, the whole assessment is built on a smaller incident than the one that happened.
recipient The unauthorized person who used the PHI or to whom it was disclosed
WHO RECEIVED IT, AS A CLASS -- a member of the covered entity's own workforce, another entity itself obligated under the Privacy Rule, a business associate under an agreement, an identified party outside all of those, or nobody anyone has identified. The class is the answer, not the individual: an officer needs to know which obligations the recipient is already under. THIS IS THE FACTOR MOST OFTEN GOT WRONG IN ONE PARTICULAR DIRECTION -- a colleague in the same organisation read as an outside disclosure -- and it is the one misreading that changes the analysis on every other factor with it.
acquired_or_viewed Whether the PHI was actually acquired or viewed
WHETHER ANYBODY ACTUALLY LOOKED. An envelope returned with the seal intact, an access log showing no open event, a recipient's own statement that they deleted an attachment unopened -- these are the facts that establish this factor in the lower direction, and each of them is a DOCUMENT somebody has to obtain. THE ABSENCE OF EVIDENCE THAT IT WAS VIEWED IS NOT EVIDENCE THAT IT WAS NOT, and resolving this factor that way is the single commonest way an incomplete assessment is made to look finished.
mitigation The extent to which the risk to the PHI has been mitigated
WHAT WAS ACTUALLY RECOVERED, DESTROYED OR SHUT OFF, and with what proof. A returned envelope, a signed attestation of destruction, a confirmed remote wipe, a revoked link with its access log. Established wrongly, the assessment credits the entity with a mitigation nobody performed. AND THE PROOF IS OFTEN NOT IN THE INCIDENT REPORT: it arrives days later in a reply to an email, and a reader who stops at the filed report misses it and sends an officer looking for something that is already on file.
THE READING VOCABULARY -- where your answer came from, and which way it points:
report_lower the incident report as filed states a fact that points at a LOWER probability of compromise on this factor
report_higher the incident report as filed states a fact that points at a HIGHER probability of compromise on this factor
followup_lower only a follow-up artifact inside the file -- an email reply, a ticket note -- states a fact pointing LOWER on this factor
followup_higher only a follow-up artifact inside the file states a fact pointing HIGHER on this factor
none nothing anywhere in the file states a fact about this factor
THE RECIPIENT CLASSES -- the second answer on the `recipient` row, and null on
the other three:
workforce_member a member of the covered entity's own workforce, already bound by its privacy policies and its sanctions
other_covered_entity another entity itself obligated under the Privacy Rule
business_associate a business associate with a business associate agreement in force
identified_external an identified party outside all of those, under no such obligation
unidentified the file does not identify who received it
HOW TO QUOTE THE TEXT, and how it will be read.
For every factor you answer SUPPORTS-LOWER-RISK or SUPPORTS-HIGHER-RISK, `citation` must be ONE
SENTENCE OR ONE DATED LINE COPIED VERBATIM out of the incident file -- the text that establishes
it. It may come from any part of the file, including a dated line in the correspondence, the ticket
notes or the artifact file.
- Copy it character for character. It is located in the file by searching for it, so a
paraphrase, a shortened version, an ellipsis in the middle, or two sentences joined together
will not be found at all and will score nothing. There is no partial credit for a quote the
file does not contain.
- Quote the sentence, not the section. What is returned is compared with that sentence by
character overlap: it must cover at least 60 pct of the sentence, and at least 30 pct
of what you return must be the sentence. Returning the whole file scores nothing.
- The intake procedure is NOT part of the file. A rule is never the citation.
- Where you answer INCOMPLETE, `citation` is null. That includes every factor the file is silent
on and every factor whose document has been requested and not returned. QUOTING A SENTENCE FOR
AN INCOMPLETE FACTOR MAKES IT LOOK ESTABLISHED, and it is counted as a wrong answer, not as an
empty one.
THE INCIDENT FILE, verbatim:
PRIVACY INCIDENT PIR-0001 -- Printout left in a shared area overnight
INCIDENT FACTS
Reference opened 2026-07-22
Reported by referrals team
Business area outpatient booking at Havermount
Individuals in scope 104
Artifact file read as at 2026-09-01
INCIDENT REPORT AS FILED
An envelope was enclosed inside another individual's post during the weekly letter run. The file was placed in the privacy office queue on the day it was reported. No system change or outage was in progress at the time. The audit trail shows the folder was opened twice and one document was printed. The attachment held a clinic running order for one afternoon: surname and appointment time for 104 people, with no address, no account number and no record number.
The message was recalled and the recipient's copy was confirmed deleted by the applications team. The reporter noted the time of discovery to the nearest quarter of an hour. The business area confirmed that the step is covered by its own standard operating procedure. The envelope was delivered to a private address on the next street, to somebody with no connection to this organisation and under no obligation to it.
FOLLOW-UP CORRESPONDENCE
2026-07-28 file reviewed at the weekly privacy meeting -- left open
2026-08-21 acknowledgement sent to the reporter
TICKET NOTES
2026-08-25 ticket raised with the service desk and linked to this file
ARTIFACT FILE -- what has been obtained, and what is still outstanding
Nothing has been obtained or requested for this file.
Reply with JSON and nothing else, exactly this shape:
{
"factors": [
{
"kind": "phi_nature" | "recipient" | "acquired_or_viewed" | "mitigation",
"state": "INCOMPLETE" | "SUPPORTS-LOWER-RISK" | "SUPPORTS-HIGHER-RISK",
"reading": "report_lower" | "report_higher" | "followup_lower" | "followup_higher" | "none",
"citation": "<text>" or null,
"recipient_class": "workforce_member" | "other_covered_entity" | "business_associate" | "identified_external" | "unidentified" or null
},
... one object per factor, all four, in this order: phi_nature, recipient, acquired_or_viewed, mitigation
],
"reportability": "NOT-DETERMINED-HERE" | "LOW-PROBABILITY-OF-COMPROMISE" | "REPORTABLE-BREACH",
"confidence": <a number between 0 and 1>,
"why": "<text>"
}
What each field means:
kind which of the four factors this row is about. Answer all four, once each, in the order given
state what the incident file establishes about this factor. INCOMPLETE where the file does not establish it -- somebody has to go and find out, and that includes every factor the file is silent on and every factor whose document has been requested and not returned. SUPPORTS-LOWER-RISK where the file establishes a fact pointing at a lower probability of compromise. SUPPORTS-HIGHER-RISK where it establishes one pointing higher. AN UNESTABLISHED FACTOR IS NEVER LOWER RISK
reading WHERE the fact came from and which direction it points, as its own answer. `report_lower` / `report_higher` the INCIDENT REPORT AS FILED states it. `followup_lower` / `followup_higher` only a follow-up artifact inside the file states it -- an email reply, a ticket note. `none` nothing anywhere in the file states a fact about this factor. This is the reading, and it is the only field the rule engine re-uses
citation ONE SENTENCE OR ONE DATED LINE COPIED VERBATIM from the incident file -- the text that establishes this factor. Copy it exactly, character for character; do not paraphrase, do not shorten with an ellipsis, do not join two sentences. NULL where the state is INCOMPLETE: an unestablished factor has no sentence establishing it, and quoting one makes it look established, which is counted as a wrong answer rather than an empty one
recipient_class RECIPIENT ROW ONLY, and null on the other three. Which class of person the FILE STATES received it. `unidentified` where the file does not identify them -- that is the answer, and it is what makes the factor INCOMPLETE. Never infer it from a fax exchange, an email domain, a job title nobody wrote down, or the fact that the number dialled was internal
reportability ALWAYS `NOT-DETERMINED-HERE`. This extraction does not determine whether an incident is a reportable breach and does not conclude that a low probability of compromise has been demonstrated -- that determination is the privacy officer's, made on the record, from these four factors together with everything the file cannot see. The other two values are in this list so that an answer which makes the determination can be counted making it
confidence your own number between 0 and 1 for this incident's four factor answers taken together. It is published as evidence and never used to change an answer
why one sentence naming what established the factors you did not answer INCOMPLETE, and what is still outstanding on the ones you did. Do not state a reportability conclusion in it
Four factor objects for one incident. No more, no fewer. And `reportability` is
"NOT-DETERMINED-HERE".
