Compliance decisions
HIPAA AI audit evidence and retention
Define the evidence you need before deciding how long to keep it. HIPAA requires audit controls and activity review, while its six-year Security Rule documentation requirement does not automatically set the retention period for every AI prompt or event. Different records need different decisions.
For Healthcare security engineers, privacy teams and internal audit
Keep the audit purpose clear without copying PHI into every evidence system.
Synthetic records and evaluation plan. No production event, six-year prompt policy or completed deletion is asserted.01
Start with the question the evidence must answer
An auditor may need to know which policy applied, whether a control was operating or how an incident was reviewed. Those are different questions from reconstructing a complete clinical conversation. State the question, the source system and the person who will review the evidence before selecting fields.
HHS describes audit controls for systems using ePHI and procedures to review information-system activity. A screenshot of a dashboard or a count of AI visits is not automatically sufficient evidence of access, a policy decision or a completed investigation. Verify what each event actually records.
Source context: HHS: Summary of the HIPAA Security Rule
02
Separate event data from policy documentation
A security event may contain a time, application, relevant account reference, policy identifier and action. The policy document explains the intended rule; the review record explains what the responsible person did with the event. A medical record or source document can have its own separate retention requirements.
Keep links or controlled references between these records where useful. Avoid duplicating full prompts or attachments merely to make the evidence look complete. An event may itself include sensitive information, so access, retention and onward export need review even when the raw source file is not retained.
Source context: HHS: Summary of the HIPAA Security Rule · HHS: Guidance on risk analysis
03
Apply the six-year rule to the right material
HHS states that required Security Rule policies, procedures and documentation must be retained for six years from creation or the date last in effect, whichever is later. That statement concerns the specified documentation. It is not a universal instruction to preserve every employee AI conversation for six years.
For other record types, document the applicable legal, contractual and operational reasons for retention. Consider investigation needs, clinical-record rules, privacy obligations and preservation requirements. A vendor’s default retention setting is an available configuration, not your organisation’s legal analysis.
Source context: HHS: Summary of the HIPAA Security Rule
04
Test the meaning of the fields
Use a synthetic input and record what appears in the source event, the dashboard and any exported copy. Check time zones, identifiers, action meanings and whether a missing event represents an unsupported path, a configuration issue or another gap. A displayed “blocked” label should be understood in the context of the actual tested action.
The sample below records an intended action without inventing an observed result. Compare required fields with supported fields and make missing evidence explicit. If data is exported to another system, identify that system’s owner, access permissions and retention policy as a separate part of the record.
Source context: HHS: Guidance on risk analysis
05
Make review and disposal accountable
Assign an owner to routine activity review, exception investigation and retention changes. Record when a review happened, what scope was examined and what follow-up was required. A reporting schedule without a reviewer or a defined question provides weak assurance.
When a record reaches its retention limit, check for applicable preservation requirements before disposal. Keep evidence of the decision at an appropriate level without reproducing the sensitive content being deleted. Review this design when the AI service, event schema, export destination or legal requirement changes.
Source context: HHS: Summary of the HIPAA Security Rule
Put it into practice
AI evidence and retention matrix
Use the record type to choose a retention owner and rationale. The example deliberately avoids assigning an invented organisation-wide retention period.
Synthetic records and evaluation plan. No production event, six-year prompt policy or completed deletion is asserted.
TEST-AI-001
Synthetic sensitive-input check
Observed outcome: not run
Policy reference
Identify the version that should apply
Review reference
Record who examined the actual evidence
| Record | Evidence purpose | Retention decision |
|---|---|---|
| Security event: synthetic upload | Which application, policy and action were involved? | Security and privacy owners define the period and supported fields. |
| Policy version and required procedure | What rule and procedure were in effect? | Apply the Security Rule documentation requirement where applicable. |
| Activity-review record | Who reviewed the defined event scope and what followed? | Determine whether it is required Security Rule documentation and apply the relevant rule. |
| Underlying patient record | Clinical or administrative source of the input. | Use the medical-record and other applicable requirements, not the event-log default. |
| Exported event copy | Investigation or reporting in another system. | Assign the receiving owner and its access, retention and preservation rules. |
| Record subject to preservation | Evidence relevant to a specific dispute or investigation. | Resolve the preservation obligation before routine deletion. |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
hipaa-ai-evidence-retention.mdInspect
# AI evidence and retention matrix
Synthetic records and evaluation plan. No production event, six-year prompt policy or completed deletion is asserted.
Use the record type to choose a retention owner and rationale. The example deliberately avoids assigning an invented organisation-wide retention period.
| Record | Evidence purpose | Retention decision |
| --- | --- | --- |
| Security event: synthetic upload | Which application, policy and action were involved? | Security and privacy owners define the period and supported fields. |
| Policy version and required procedure | What rule and procedure were in effect? | Apply the Security Rule documentation requirement where applicable. |
| Activity-review record | Who reviewed the defined event scope and what followed? | Determine whether it is required Security Rule documentation and apply the relevant rule. |
| Underlying patient record | Clinical or administrative source of the input. | Use the medical-record and other applicable requirements, not the event-log default. |
| Exported event copy | Investigation or reporting in another system. | Assign the receiving owner and its access, retention and preservation rules. |
| Record subject to preservation | Evidence relevant to a specific dispute or investigation. | Resolve the preservation obligation before routine deletion. |
## Review steps
- Define event semantics: Identify what an action value proves and which unsupported or unobserved paths it does not cover.
- Record the retention rationale: Distinguish required policy documentation from prompt content, operational events and exported copies.
- Compare source and export: Run an authorised synthetic test and record actual fields, timestamp behaviour and access boundaries.
## Synthetic event specification
Event reference: TEST-AI-001
Input: an invented administrative note
Application: named by the evaluator before the test
Policy: sensitive-input test policy
Intended outcome: the agreed policy action
Observed outcome: not run
Raw patient content required in the event: no real patient data in this fixture
This is an evidence specification, not a representation of an Aona export schema. Map it to fields actually supported by the selected configuration.
## Source and scope
Guide: https://aona.ai/resources/guides/hipaa-ai-audit-evidence-retention/
Source check: 21 September 2026. General information; no professional approval or installed-product result is represented.
- HHS: Summary of the HIPAA Security Rule: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
- HHS: Guidance on risk analysis: https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html
hipaa-ai-evidence-retention.csvInspect
Record,Evidence purpose,Retention decision
Security event: synthetic upload,"Which application, policy and action were involved?",Security and privacy owners define the period and supported fields.
Policy version and required procedure,What rule and procedure were in effect?,Apply the Security Rule documentation requirement where applicable.
Activity-review record,Who reviewed the defined event scope and what followed?,Determine whether it is required Security Rule documentation and apply the relevant rule.
Underlying patient record,Clinical or administrative source of the input.,"Use the medical-record and other applicable requirements, not the event-log default."
Exported event copy,Investigation or reporting in another system.,"Assign the receiving owner and its access, retention and preservation rules."
Record subject to preservation,Evidence relevant to a specific dispute or investigation.,Resolve the preservation obligation before routine deletion.
Before you proceed
Keep these distinctions clear
- Six years is not a prompt default
- Apply the documentation rule to its actual scope rather than every data category.
- Exports create another copy
- The destination system needs its own owner, permissions and retention decision.
Apply it to employee AI use
Bring your actual data path.
Aona’s supported activity and policy evidence can contribute to an employee-AI security review.
Confirm the available fields and configured retention. Aona is not a complete medical-record system or a guaranteed HIPAA archive.
Use a synthetic input to compare the selected path’s event with the required evidence and any exported copy.
Review your use caseFAQ
Questions for this decision
Does HIPAA require every AI prompt to be kept for six years?
Should we keep raw PHI to prove a policy worked?
Does an exported report prove every AI input was inspected?
Who owns a log after it reaches the SIEM?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- HHS: Summary of the HIPAA Security Rule
Audit controls, information-system activity review and retention of required Security Rule documentation.
regulator · checked 2026-09-21 - HHS: Guidance on risk analysis
Identifying and documenting risks to ePHI across the regulated entity’s systems.
regulator · checked 2026-09-21