Before you write a HIPAA policy, decide whether you are a covered entity or a business associate, find every place electronic protected health information (ePHI) is created, stored or sent, and draw the boundary around those systems. Everything else in the Security Rule hangs on that map.
Who does HIPAA apply to?
HIPAA's Security Rule applies to covered entities (health plans, healthcare clearinghouses and certain healthcare providers) and to their business associates, which are vendors that handle PHI for them. Software and service companies often become business associates without noticing, because a customer sends data that includes patient information.
The HHS Security Rule pages blocked our automated fetch, so the structure below comes from the rule's published framework as summarized by secondary sources. Check the HHS text and get legal advice on your own status.
What is the Security Rule's shape?
It is organized as administrative, physical and technical safeguards. Each standard has implementation specifications that are either required or addressable. Addressable does not mean optional. Secondary summaries describe it as: implement it, implement an equivalent, or document why neither is reasonable, while still meeting the standard's goal. A risk analysis is a required part of the security management process.
How do you scope it?
1. Decide your role. Do you create or hold PHI for a healthcare customer? If so, you are likely a business associate and a signed Business Associate Agreement is needed before you handle that data. If you only scan source code, ask whether any customer repository, log or test data can contain PHI.
2. Map the data flows. Draw where ePHI enters, where it is stored, who or what touches it, where it leaves, and where copies end up: backups, logs, analytics, support tickets, email, test databases, AI tools.
3. List the systems. From the map, list each application, database, storage bucket, endpoint and vendor in the flow. That is your boundary.
4. Shrink it on purpose. Every system in scope needs safeguards. Cut scope by keeping PHI out of logs, masking data in test environments, and not sending it to tools that do not need it.
5. List your own subcontractors. If a vendor of yours touches ePHI, you need an agreement with them too.
6. Write the scope statement. One page: role, data types, systems, vendors, owners, date, approver.
What evidence should you keep?
- The scope statement and data flow diagram
- System and vendor inventory with owners
- Signed agreements with customers and subcontractors
- The risk analysis tied to the in-scope systems
- A log of scope changes
Mistakes to avoid
- Writing policies first and discovering PHI in logs later.
- Assuming "we never see patient data" without checking support tickets, error logs and test data.
- Treating the cloud provider as the whole answer. Shared responsibility means your configuration still matters.
- Leaving subcontractors out of the inventory.
What to do
- Decide covered entity or business associate with counsel.
- Draw the ePHI data flow diagram.
- List every system and vendor in the flow.
- Reduce scope by masking, filtering and moving data.
- Confirm agreements are signed before data moves.
- Run a risk analysis on the final boundary.
- Re-check scope whenever you add a product feature or vendor.
Quick check
Can a software vendor be a business associate?
Yes, if it creates, receives, maintains or transmits PHI on behalf of a covered entity. Ask counsel to confirm your status and whether any customer data could include PHI.
Does addressable mean optional?
No. It means you assess the specification and either implement it, implement an equivalent, or document why it is not reasonable, while still meeting the standard.
How Safeguard helps automate this
Scoping is easier when you can see what is actually in your systems. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between assessments. That frees your team to work on the boundary itself.
Technical evidence comes from your real code and dependencies, through scans, SBOMs and reachability, which helps you show what software sits inside the boundary and whether it carries known risk. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. It does not decide your HIPAA status and does not replace legal advice or an assessor.
Want to see it on your own stack? Book a call.
Sources
- HHS, HIPAA Security Rule overview (blocked to our fetch, check directly)
- HHS, guidance on risk analysis
Last reviewed: 18 October 2026.
