HIPAA and Clinical Photography: What Practices Actually Need
Patient photos are PHI under HIPAA. What the rules require of your photo software, what stays your responsibility, and why no software is HIPAA certified.
Last reviewed 12 September 2026. This page is general information about US federal regulations, not legal advice. CureCast is a software company, not a law firm. Nothing here is advice about your practice’s particular circumstances, and you should not act on it without your own counsel.
The short version
Patient photographs are protected health information. Full-face photographic images are named explicitly in the Privacy Rule as one of the eighteen identifiers that must be removed before health information counts as de-identified.
No software is HIPAA certified. The Department of Health and Human Services does not certify, approve or accredit any product, server or vendor. No such certificate exists.
What does exist is a signed Business Associate Agreement plus safeguards. HIPAA requires a covered entity to have a written contract in place with any vendor handling protected health information on its behalf, and that contract must contain specific elements set out in the regulations.
Compliance belongs to your practice. Software supports a compliance programme. It cannot be one.
Are patient photographs protected health information?
The list does not stop at faces. Identifier (R) is a catch-all:
A distinctive tattoo, a surgical scar, a birthmark or an unusual anatomical feature can identify a person. Cropping out a face does not automatically de-identify a body photograph and treating it as though it does is a common and understandable mistake.
There is also a second test. Even after removing all eighteen identifiers, the covered entity must not have actual knowledge that the remaining information could identify someone (45 CFR 164.514(b)(2)(ii)). A surgeon who knows exactly whose torso is in a photograph has that knowledge.
What about photographs that do not show a face?
Yes, and the regulation says so by name.
The Privacy Rule’s de-identification standard lists eighteen identifiers that must be removed before health information stops being individually identifiable. Identifier (Q) is:
The same phrase appears again at 45 CFR 164.514(e)(2)(xvi), in the list of direct identifiers excluded from a limited data set.
This means a clinical photograph showing a patient’s face is identifying on its own. It does not become PHI because a name is attached to the file. It is PHI because of what is in the frame.
Why this matters in an aesthetic practice
Before and after photographs are the working currency of plastic surgery, dermatology and medical aesthetics. They are taken constantly, compared across visits, shown in consultations and used in marketing. Every one of them is a clinical record and most of them are identifying.
Is there such a thing as HIPAA certified software?
No. There is no HIPAA certification, from any government body.
HHS does not certify, approve, endorse or accredit software, servers, cloud providers or vendors. There is no official list of approved products, and no certificate that a vendor can hold.
Some vendors advertise HIPAA certification regardless. What they usually mean is that they have paid for a third-party audit or attestation. That can be a perfectly reasonable thing to do, and it may tell you something useful about their internal controls. It is not a government certification, it does not bind HHS, and it does not make your practice compliant.
What to ask instead
45 CFR 164.508(c)(1) sets six core elements:
- Will you sign a Business Associate Agreement? If a vendor hesitates, stop there.
- How is data encrypted at rest and in transit? Expect a named standard, not “bank-level security.”
- How is staff access controlled? Per person, or a shared login?
- What does the audit trail record, and can I export it?
- Where is the data physically stored? Ask for it in writing.
- Do you have a BAA with your own hosting provider? The chain matters, not just the first link.
- What happens to my data if I leave?
- A vendor who answers all seven clearly is more useful to you than one holding a certificate that does not exist.
What HIPAA requires of a software vendor
The Business Associate Agreement
A software company that stores or processes PHI on a practice’s behalf is a business associate. Before any PHI changes hands, HIPAA requires a written agreement.
The general rule is at 45 CFR 164.502(e). The specific elements that agreement must contain are at 45 CFR 164.504(e), and they include establishing the permitted uses and disclosures, requiring the business associate not to use or disclose the information otherwise, and requiring appropriate safeguards.
Since 2009, business associates have also been directly liable. Section 13401 of the HITECH Act, signed 17 February 2009 as part of the American Recovery and Reinvestment Act, applied the Security Rule’s administrative, physical and technical safeguards to business associates in the same way they apply to covered entities, and made them civilly and criminally liable. The 2013 Omnibus Rule implemented this.
This is why a BAA is not a formality. Your vendor carries real exposure of their own, and a vendor unwilling to sign one is telling you they do not intend to carry it.
The Security Rule safeguards
The Security Rule sets standards across three categories for electronic PHI:
| Category | Citation | Covers |
|---|---|---|
|
Administrative safeguards |
45 CFR 164.308 |
Risk analysis, workforce access management, training, incident procedures |
| Physical safeguards |
45 CFR 164.310 |
Facility access, workstation use, device and media controls |
| Technical safeguards |
45 CFR 164.312 |
Access control, audit controls, integrity, authentication, transmission security |
Encryption: required, or not?
This is widely misreported, so here is the precise position.
Encryption appears twice in the Security Rule, at 45 CFR 164.312(a)(2)(iv) for stored data and 45 CFR 164.312(e)(2)(ii) for transmitted data. In both places it is an addressable implementation specification rather than a required one.
Addressable does not mean optional. It means the covered entity must assess whether encryption is reasonable and appropriate for its environment and then either implement it, implement an equivalent alternative, or document why neither is reasonable. In practice, for a practice storing thousands of identifiable clinical photographs in the cloud, it is very difficult to document that encryption is unreasonable.
There is also a strong practical incentive. Under the Breach Notification Rule, notification obligations attach to unsecured PHI, defined at 45 CFR 164.402 as information not rendered unusable, unreadable or indecipherable through a technology or methodology specified by the Secretary in guidance. Encryption meeting that guidance places an incident within what is commonly called the breach safe harbour. Encrypted data that is lost or stolen, where the key was not also compromised, generally does not trigger notification.
Encryption is technically addressable and practically essential.
Encryption: required, or not?
45 CFR 164.502(b) and 45 CFR 164.514(d) require a covered entity to limit use and disclosure of PHI to the minimum necessary for the purpose.
164.514(d)(2) is specific: the practice must identify which people in its workforce need access to PHI to do their jobs, and for each of them which categories of information they need, then make reasonable efforts to limit access accordingly.
For a clinic, that is a direct instruction to configure staff permissions deliberately rather than giving everyone the same access. A receptionist scheduling appointments does not need to open surgical photographs.
What remains your practice’s responsibility
No vendor can take these on, and any vendor suggesting otherwise is misleading you.
- Risk analysis. 45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to electronic PHI. It is about your whole environment, not one application.
- Policies, procedures and documentation. 45 CFR 164.316 requires written policies, retained for six years.
- Workforce training. 45 CFR 164.308(a)(5) requires a security awareness and training programme.
- Patient authorisation for marketing. Covered in detail in the next section. Storing a photograph compliantly and publishing it are entirely separate questions, and the second is not something software decides for you.
- Device and physical security. Who can pick up the iPad, what happens when it is lost, who has keys to the room.
- Breach response. The Breach Notification Rule at 45 CFR 164.400 to 164.414 sets out what must happen if PHI is compromised.
Using patient photographs in marketing
This is where aesthetic practices are most exposed, because before and after photographs are both clinical records and the most persuasive marketing a practice owns.
Publishing a patient’s photograph is a use for marketing and requires a written authorisation. 45 CFR 164.508(a)(3) is explicit. The only exceptions are a face-to-face communication with the individual, or a promotional gift of nominal value. A website gallery, an Instagram post, a brochure and a consultation album shown to a different patient are none of those things.
Treatment consent is not marketing authorisation. A patient consenting to a procedure has not agreed to appear in your advertising. They are separate permissions, and one does not imply the other.
What a valid authorisation must contain
45 CFR 164.508(c)(1) sets six core elements:
- A description of the information to be used or disclosed, identified in a specific and meaningful fashion
- The name or specific identification of the person or class of persons authorised to make the use or disclosure
- The name or specific identification of the person or class of persons to whom the disclosure may be made
- A description of each purpose of the use or disclosure
- An expiration date or expiration event
- Signature of the individual and date. If a personal representative signs, a description of that person’s authority to act for the individual
45 CFR 164.508(c)(2) adds three required statements: the right to revoke in writing and how to do it, whether treatment can be conditioned on signing, and the fact that information disclosed may be redisclosed by the recipient and lose its protection.
The authorization must also be in plain language (164.508(c)(3)), and the practice must give the patient a copy of the signed authorization (164.508(c)(4)).
Two traps specific to aesthetic practice
Do not bundle marketing permission into the surgical consent form.
45 CFR 164.508(b)(3) restricts compound authorizations. An authorization may generally be combined with another authorization under the same section, except where one of them conditions the provision of treatment. A surgical consent conditions treatment. A marketing authorization cannot.
Combining them into a single signature creates exactly the conflict the rule prohibits, and it is a very common arrangement in aesthetic clinics.
Keep them as separate documents with separate signatures.
You cannot make treatment conditional on photo permission.
45 CFR 164.508(b)(4) prohibits a covered entity from conditioning treatment, payment, enrolment or benefits on an individual providing an authorization, outside narrow exceptions that do not apply to aesthetic surgery. A patient who declines to be photographed for your portfolio must still be treated on the same terms.
Revocation
A patient may revoke at any time, and the revocation must be in writing (45 CFR 164.508(b)(5)). The exception is to the extent the practice has already acted in reliance on it, which is why a photograph already printed in a brochure does not have to be recalled from every waiting room.
What must stop is future use. That requires knowing, at the moment someone is about to build a gallery, whether this patient’s permission still stands.
Authorisations that are no longer valid
45 CFR 164.508(b)(2) lists when an authorisation is defective and cannot be relied on: the expiration date has passed or the expiration event has occurred, it was not filled out completely, the practice knows it has been revoked, it breaches the compound or conditioning rules, or the practice knows material information in it is false.
An expired authorisation is not a weaker authorisation. It is no authorisation at all. Since element five above requires an expiry date or event, every marketing authorisation a practice holds has an end, and somebody has to be tracking it.
Retention
45 CFR 164.508(b)(6) requires the practice to document and retain every signed authorisation, in line with the six-year documentation requirement at 45 CFR 164.530(j).
The Security Rule is being rewritten
This is the most significant pending change in HIPAA in more than a decade, and it directly affects vendors.
On 27 December 2024, HHS issued a Notice of Proposed Rulemaking to update the Security Rule, published in the Federal Register on 6 January 2025. HHS described it as seeking to update the Security Rule “for the first time since 2013.”
The proposals would, among other things, remove the addressable/required distinction and make encryption at rest and in transit mandatory, require multi-factor authentication, and require annual verification from business associates.
HHS set out why, and the figures are theirs:
Between 2018 and 2023, reports of large breaches rose 102%, and the number of individuals affected rose 1002%
In 2023, over 167 million individuals were affected by large breaches, a record
Since 2019, large breaches caused by hacking rose 89% and those caused by ransomware rose 102%
Where it stands now
The comment period closed on 7 March 2025 with close to 5,000 comments. In the Fall 2026 Unified Agenda, HHS moved the rulemaking (RIN 0945-AA22) to its Long-Term Actions list, identifying July 2027 as the anticipated timeframe for final action. Unified Agenda dates are planning estimates, not binding deadlines.
Some vendors are already describing mandatory encryption as current law. It is not. HHS states the position plainly on its own NPRM page:
The sensible reading: encryption is addressable today, very likely to become mandatory, and there is no good reason to wait.
Penalties
Civil monetary penalties are tiered by culpability, from a violation the covered entity did not know about and could not reasonably have known about, through reasonable cause, to wilful neglect corrected and wilful neglect uncorrected.
The amounts are adjusted annually for inflation. Effective 28 January 2026, HHS applied a multiplier of 1.02598, producing penalties from a minimum of $145 per violation to an annual cap of $2,190,294 for all violations of an identical provision in a calendar year.
OCR also continues to apply a 2019 enforcement discretion policy that sets lower annual caps for the first three tiers.
Because these figures change every year, treat any specific number you read as dated, including this one. Check the current Federal Register notice.
Where clinical photography actually goes wrong
Across enforcement actions and everyday practice, the recurring failures are rarely exotic.
- Photographs taken on personal phones.
A photograph taken with a phone’s own camera app is written to that device’s camera roll and, on most phones, synced automatically to the staff member’s personal cloud account. The practice then has clinical images in a location it does not control and cannot retrieve. When that person leaves, the photographs leave with them. - Shared logins.
If four people use one account, the audit trail cannot attribute anything, and the minimum necessary standard cannot be applied at all. - Messaging apps.
Consumer messaging platforms do not sign business associate agreements. HIPAA does permit a covered entity to send information to the patient themselves through a channel the patient has requested, provided the practice has warned them about the risks and documented that. That is a patient-directed disclosure with conditions attached, not a compliant messaging system for internal use. - Staff offboarding.
Access that is never revoked, and images already sitting on a former employee’s device. - Marketing without authorization.
Publishing a before and after photograph without a written authorization under 164.508(a)(3), often because the patient verbally agreed and nobody wrote it down. - Curiosity.
A colleague looking up a patient they recognize. Access controls and an audit trail are the only things that address this.
How CureCast supports these workflows
CureCast is photo management software for plastic surgery, dermatology and medical aesthetics practices. It supports HIPAA-compliant workflows. It is not, and cannot be, a compliance programme.
We sign a Business Associate Agreement with every US practice, and we hold one with Amazon Web Services, who host the storage. Ask to see it before you start your trial, not after.
- Photographs never reach the camera roll. Images captured through CureCast go directly into the practice's account. They are not written to the device gallery and do not sync to a staff member's personal cloud, which removes the most common failure above.
- Encryption. AES-256 at rest, TLS 1.3 in transit with TLS 1.2 as fallback.
- Per-person access control. Every staff member has their own login, with permissions set at module and action level, so access can be matched to role as the minimum necessary standard contemplates.
- Audit trail. Views, downloads, shares, exports and consent activity, recorded with staff, device, IP and timestamp, filterable and exportable as CSV or PDF.
- Consent forms, with marketing permission recorded against the patient. Practices can build their own consent and authorisation forms in CureCast, capture signatures from up to four signers on a single form, and store the signed document in the patient's record rather than in a filing cabinet.
Four signature slots exist because one is often not enough. A personal representative signing for a minor or a patient lacking capacity, whose authority has to be described under 164.508(c)(1)(vi). A witness. The treating practitioner. A translator.
Because forms are separate per procedure and per purpose, marketing authorisation can be kept as its own document rather than bundled into a treatment consent, which is what 164.508(b)(3) requires.
Marketing permission is then recorded against the patient, so when a before and after is being built the answer to "is this patient cleared for marketing?" is visible at that moment rather than reconstructed later from paperwork.
What this does not do. CureCast supplies the mechanism to capture, sign, store and surface authorisations. Whether any particular form is a valid HIPAA authorisation depends on what your practice puts in it, the six core elements, the three required statements, plain language, and a copy given to the patient. Draft your forms with your own counsel. Software cannot tell you whether your wording satisfies 164.508.
- Confidential patient access. Individual patients can be made invisible in search, lists and galleries to all but named staff.
- Device management and session timeout. Administrators can see connected devices and end a session when one is lost. Inactive sessions end automatically.
What we do not do: write your policies, perform your risk analysis, train your staff, obtain patient authorisations, or secure your premises. Those are yours, and they are what compliance actually consists of.
Sources
All verified 12 September 2026.
Regulations
- 45 CFR 164.514, de-identification, the eighteen identifiers, minimum necessary. eCFR
- 45 CFR 164.508, authorisations, marketing, core elements, compound authorisations,revocation. eCFR
- 45 CFR 164.502, uses and disclosures, general rules. eCFR
- 45 CFR 164.504, business associate contract requirements. eCFR
- Part 164 source and authority: 65 FR 82802 (28 December 2000), amended 67 FR 53270 (14 August 2002), 78 FR 5700 (25 January 2013), 78 FR 34266 (7 June 2013)
HHS
- Summary of the HIPAA Privacy Rule
- Summary of the HIPAA Security Rule
- Business Associate Contracts
- Breach Notification Rule
- Breach Safe Harbor guidance
- HIPAA Security Rule NPRM, source of the “current Security Rule remains in effect” statement and the breach statistics
- NPRM fact sheet
Federal Register
- HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, 6 January 2025
- 2013 Omnibus Final Rule, 25 January 2013
Statute
- HIPAA: Public Law 104-191, 21 August 1996
- HITECH: Public Law 111-5, 17 February 2009, sections 13400 to 13424

See How CureCast Fits Your Practice
Discuss how CureCast fits into your clinical photo workflow, from capturing and organizing patient photos to securely managing them across your practice.
Prefer email? [email protected]