What is the HIPAA Security Rule?

The HIPAA Security Rule establishes national standards to protect the confidentiality, integrity, and availability of electronic protected health information (ePHI) through administrative, physical, and technical safeguards.

What is considered a HIPAA violation in cybersecurity?

A HIPAA violation occurs when PHI or ePHI is impermissibly used or disclosed or insufficiently safeguarded. Common causes include weak access controls, missing risk analyses, unencrypted devices, improper workforce training, and delayed breach reporting.

What are administrative, physical, and technical safeguards?

Administrative safeguards are policies, procedures, and training. Physical safeguards protect facilities and devices. Technical safeguards include access controls, audit logging, transmission security, and encryption.

Is a HIPAA risk assessment required annually?

HIPAA requires a regular and thorough risk analysis but does not mandate a specific frequency. Many organizations perform it annually and whenever significant changes occur, such as new systems, vendors, or workflows.

What should a HIPAA risk assessment include?

It should identify where ePHI resides, evaluate threats and vulnerabilities, assess likelihood and impact, review current controls, document risk levels, and define prioritized remediation steps and timelines.

What is the role of encryption in HIPAA compliance?

Encryption is an addressable implementation specification. If reasonable and appropriate, it should be implemented for data at rest and in transit. If not implemented, the decision must be documented and an equivalent alternative safeguard applied.

What is a Business Associate under HIPAA?

A Business Associate is any person or organization, other than a workforce member of a covered entity, that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Examples include cloud providers, IT support, billing services, and certain consultants. A Business Associate Agreement (BAA) is required before PHI access.

Do business associates need to be HIPAA compliant?

Yes. Business associates must implement appropriate safeguards for PHI, comply with applicable HIPAA requirements, enter into a BAA, report incidents and breaches, and ensure their subcontractors that handle PHI also comply.

What happens if a business associate causes a breach?

Both the covered entity and the business associate have obligations. The business associate must investigate, mitigate, and notify the covered entity. Breach notifications to individuals, HHS, and in some cases the media may be required based on the incident size and circumstances.

How do I secure remote access to ePHI?

Use VPN or zero-trust access, require multi-factor authentication, enforce least-privilege access, encrypt devices, manage endpoints and patches, disable local data storage when possible, and monitor logs for suspicious activity.

Can employees use personal devices under HIPAA?

Yes, if governed by a BYOD policy that enforces device encryption, screen locks, remote wipe, mobile device management, separation of work data, and prohibits storing ePHI in unsecured apps or locations.

What is considered a HIPAA data breach?

A breach is an impermissible use or disclosure of unsecured PHI that compromises its security or privacy, such as ransomware, lost or stolen devices, misdirected emails, or unauthorized access, unless a documented risk assessment shows a low probability of compromise.

How soon must a HIPAA breach be reported?

Affected individuals must be notified without unreasonable delay and no later than 60 days after discovery. Reporting to HHS depends on the number of affected individuals; large breaches (500 or more) require more immediate reporting and, in some cases, media notice.

What are the penalties for HIPAA violations?

HIPAA penalties vary by tier based on level of culpability, with per-violation amounts and annual caps per violation type. Enforcement may include corrective action plans, settlement amounts, and monitoring. Actual amounts depend on the facts and current HHS guidance.

Can my practice be audited for HIPAA compliance?

Yes. HHS’s Office for Civil Rights conducts audits and investigations, particularly after breaches or complaints. Maintaining documentation, training records, and current risk analyses helps demonstrate compliance readiness.

What documentation is required to prove HIPAA compliance?

Keep current risk analyses, remediation plans, security and privacy policies, workforce training logs, incident response procedures, business associate agreements, access audit logs, and evidence of ongoing monitoring and evaluations.

Why Health Systems Treat Health Tech Security as a Patient Safety Issue

Sep 17

Written By L Trotter II

Your sales team just finished a great demo.

The health system likes the product.

The clinical team sees the value.

The opportunity looks real.

Then the security questionnaire arrives.

Suddenly your CTO is being asked about:

Multifactor authentication
Incident response
Vulnerability management
Disaster recovery
Encryption
Audit logging
Third-party vendors
Business continuity
Access controls
Backup recovery

And if AI is involved, another section appears.

Where does PHI go?

How do your models process it?

Is it used for training?

Which AI vendors touch the data?

For a 2-40 person health tech company, this can feel excessive.

It isn't.

The health system is trying to determine whether your company is HIPAA compliant.

More importantly they're trying to answer:

Could this vendor become a patient safety risk?

The Security Questionnaire Is Measuring More Than Security

For years, health tech vendors could think about cybersecurity primarily as a technology problem.

Protect the database.

Encrypt the traffic.

Restrict access.

Sign the BAA.

Move on.

Healthcare buyers think the opposite.

Modern healthcare depends on interconnected technology.

EHR platforms.

Cloud infrastructure.

APIs.

Patient portals.

Remote monitoring.

Scheduling systems.

Revenue cycle platforms.

Clinical applications.

AI.

Every new connection creates another dependency.

And when one of those dependencies fails, the impact usually extends far beyond compromised data.

Systems become unavailable.

Clinical workflows slow down.

Pharmacies can't process transactions.

Providers lose access to information.

Care delivery gets disrupted.

That's why your buyer's security team is asking harder questions.

They're not simply protecting a network.

They're protecting the organization's ability to operate.

Change Healthcare Changed How Buyers Think About Vendor Risk

The Change Healthcare cyberattack made third-party technology risk impossible for healthcare leaders to ignore.

HHS reported that approximately 192.7 million individuals were impacted by the incident.

But the lesson for health tech vendors goes beyond the size of the breach.

Change Healthcare demonstrated what happens when a critical vendor dependency becomes unavailable.

The impact moves through the healthcare ecosystem.

That's the risk enterprise buyers are thinking about when they evaluate your company.

A healthcare buyer now has to evaluate two kinds of exposure: the data you handle and the operational dependency your product creates.

That changes the questions they ask.

What happens if your environment is compromised?

How quickly would you know?

Can you contain the incident before it affects their environment?

Can you recover without disrupting critical workflows?

Can you show evidence that those controls actually work?

That is a much higher bar than saying:

"We're HIPAA compliant."

This Is Where Growth-Stage Health Tech Companies Get Stuck

I've seen the same operational problem repeatedly.

Early on, security works because the company is small.

The CTO knows the architecture.

The engineers know where everything runs.

Someone remembers why a particular control was implemented.

And when a customer has a security question, somebody can usually find the answer.

Then the company grows.

Sales starts targeting larger healthcare organizations.

Engineering is shipping faster.

More employees join.

More integrations connect to the product.

More vendors touch data.

AI gets added.

Enterprise opportunities increase.

And then the questionnaires start arriving more frequently.

But security still operates like the company has ten employees.

The CTO is still the person everyone calls.

That's the breaking point.

The company has reached the stage where your security program can no longer depend on your CTO personally operating it.

Your CTO Becomes the Security Bottleneck

This usually doesn't show up as a cybersecurity incident.

At first, it looks like an operational problem.

Sales sends a questionnaire to engineering.

Engineering answers what they can.

The CTO fills in the difficult sections.

Someone looks for the latest risk assessment.

Someone else searches Google Drive for the incident response plan.

A question about vendor management gets forwarded around.

Three days later, sales asks:

"Are we done yet?"

Then another questionnaire arrives.

And another.

Eventually one of your most expensive technical leaders is spending hours proving that the company is safe instead of building the product.

That's not scalable security.

And it isn't scalable sales.

The security questionnaire has exposed something important:

Your company's compliance maturity hasn't caught up with its commercial maturity.

This Is Why Buyers Keep Asking for Evidence

Enterprise healthcare buyers don't want security promises.

They want evidence.

HHS' current HIPAA Security Rule already requires regulated organizations to implement administrative, physical, and technical safeguards around electronic protected health information and maintain required documentation.

And the direction of travel is toward even greater cybersecurity rigor.

HHS has proposed the first major update to the HIPAA Security Rule since 2013. The proposed changes include stronger requirements around areas such as multifactor authentication, vulnerability scanning, penetration testing, network segmentation, risk analysis, documentation, and recovery planning. The proposal is not yet the rule currently in effect, but it sends a clear message about where healthcare cybersecurity expectations are moving.

Healthcare buyers are responding accordingly.

Having the control documented is only the first step.

They want to know whether your incident response plan has been tested.

They want to know whether identified vulnerabilities are actually remediated and how quickly.

They want to understand how access is granted, reviewed, and removed over time.

And they want confidence that your policies reflect how you actually operate.

The common thread is evidence.

Buyers are evaluating whether your security program functions in practice, not whether the right documents exist.

That's why vague questionnaire answers create more questions.

And more questions slow sales cycles.

A Security Review Is Really a Resilience Review

This is the mindset shift I believe growth-stage health tech companies need to make.

Stop looking at the enterprise security questionnaire as a compliance exercise.

Your buyer is evaluating whether your company can be trusted as part of their healthcare environment.

That means they are evaluating resilience.

Can you prevent common incidents?

Can you identify unusual activity?

Can you respond when something goes wrong?

Can you recover?

Can you determine what happened?

Can you communicate clearly during an incident?

Can you prove all of it?

Cyber incidents in healthcare are expensive and disruptive.

IBM's 2026 Cost of a Data Breach research puts the average healthcare breach at approximately $6.64 million, the highest average breach cost across industries for the fifteenth consecutive year.

Healthcare organizations understand that risk.

Your questionnaire is part of how they transfer less of it into their environment.

What Mature Health Tech Vendors Do Differently

The companies that handle enterprise security reviews well operate using these four disciplines.

1. Security Has Clear Ownership

Security doesn't live in everyone's job description and therefore nobody's job description.

Someone owns the program.

The CTO remains an important stakeholder.

Engineering remains responsible for implementing technical controls.

But someone is accountable for keeping the entire security and compliance program functioning.

2. Compliance Produces Evidence

A policy isn't enough.

Mature programs can demonstrate that controls operate.

Risk assessments are current.

Access reviews occur.

Training is tracked.

Vulnerabilities are remediated.

Incident response is tested.

Vendors are reviewed.

Logs are retained.

Backups are tested.

The evidence already exists before the questionnaire arrives.

3. Security Questionnaire Answers Are Repeatable

A mature company doesn't reinvent its security posture for every sales opportunity.

There is a source of truth.

Standard answers are documented.

Supporting evidence is organized.

Policies align with technical specifics.

When the buyer asks the same question three different ways, the answers remain consistent.

That creates confidence.

4. Security Supports Sales Instead of Interrupting Engineering

This is the outcome that matters.

Sales knows where security documentation lives.

Common questions have approved answers.

Escalations are clear.

Technical questions go to engineering when engineering expertise is actually required.

The CTO isn't the human API connecting sales, compliance, security, legal, and infrastructure.

That's what scalable security looks like.

Security Is Becoming Part of Your Product

I don't mean another security feature on the roadmap.

I mean the ability of your company to operate securely is becoming part of what enterprise healthcare organizations are buying.

A great clinical workflow isn't enough if the buyer believes introducing your product creates unacceptable risk.

A great AI capability isn't enough if nobody can explain where PHI travels.

The product and the company behind the product are evaluated together.

For growth-stage health tech vendors, that means security maturity eventually becomes commercial maturity.

The organizations that understand this and build for security reviews and patient safety.

The Signal Most Founders Miss

If your CTO and senior engineers are increasingly spending their time answering security questionnaires, preparing compliance evidence, reviewing customer security requirements, and explaining your controls to enterprise buyers, pay attention.

That's not merely an annoying side effect.

It's a good thing because your company has entered a different stage.

The controls that worked when everyone could sit around the same table won't necessarily work when multiple enterprise opportunities are moving through procurement simultaneously.

At this point, engineering capacity is no longer the real issue.

The company needs security leadership and an operating structure that can support the stage it has reached.

Healthcare buyers are evaluating whether they can trust your organization as part of their clinical environment.

That trust comes from consistent controls, clear ownership, and evidence that the program works.

The vendors that can demonstrate that maturity are the ones more likely to keep deals moving.

-Larry

L Trotter II

As Founder and CEO of Inherent Security, Larry Trotter II is responsible for defining the mission and vision of the company, ensuring execution aligns with the business purpose. Larry has transformed Inherent Security from a consultancy to a cybersecurity company through partnerships and expert acquisitions. Today the company leverages its healthcare and government expertise to accelerate compliance operation for clients.

Larry has provided services for 12 years across the private industry developing security strategies and managing security operations for Fortune 500 companies and healthcare organizations. He is influential business leader who can demonstrate the value proposition of security and its direct link to customers.

Larry graduated from Old Dominion University with a bachelor’s degree in Business Administration with a focus on IT and Networking. Larry has accumulated certifications such as the CISM, ISO27001 Lead Implementer, GCIA and others. He serves on the Board of Directors for the MIT Enterprise Forum DC and Baltimore.

https://www.inherentsecurity.com