- Home
- Compliance
- HIPAA Compliance
- The Security Rule
HIPAA rules
The Security Rule, mapped to a cloud software company.
The Security Rule (45 CFR Part 164, Subpart C) tells covered entities and business associates how to protect electronic PHI. It names outcomes, not products. That leaves you free to choose controls, and obliged to show why the ones you chose are reasonable for your size and risk.
Back to HIPAA services01 · Scope
Narrower than the Privacy Rule, and deeper
Electronic PHI only, but every system that holds or moves it.
The rule reaches electronic PHI (ePHI): PHI you create, receive, maintain or transmit in electronic form. Paper and speech are outside it. Inside it, the duty is broad: protect the confidentiality, integrity and availability of ePHI, guard against threats you can reasonably foresee, guard against uses the Privacy Rule forbids, and make sure your workforce complies.
- Production databases
- Object storage
- Backups
- Logs and traces
- Message queues
- Support tooling
- Laptops
- CI fixtures with real data
02 · Flexibility
Flexibility is a duty to reason, not a discount
Four factors shape what is reasonable for you.
- Size, complexity and capabilityA ten-person startup and a national insurer are not expected to build the same programme.
- Technical infrastructureThe hardware, software and platform security features you already have.
- CostA legitimate factor, but never a reason to leave a serious risk untreated.
- Probability and criticality of riskWhat your risk analysis says could happen to ePHI, and how bad it would be.
Every factor feeds back to the risk analysis. Without one, you cannot show your choices were reasonable, and OCR has repeatedly singled out missing analyses in its enforcement work.
03 · Required or addressable
What addressable really asks of you
Three outcomes, each documented.
Each standard carries implementation specifications marked required or addressable. A required one must be implemented. An addressable one triggers an assessment, and that assessment has only three acceptable endings.
- It is reasonable and appropriate here, so you implement it.
- It is not, so you document why and implement an equivalent alternative measure.
- It is not, and no alternative is reasonable either, so you document both conclusions.
The encryption test
Encryption at rest and in transit is addressable. For a cloud company, where every major provider offers it and the breach safe harbor rewards it, a written case for skipping it would be very hard to defend.
HHS has proposed changes to the Security Rule that would make most specifications required. Check the current status before planning against the existing text.
04 · Safeguards mapped
The three families, in cloud terms
Typical controls, and the evidence a reviewer will ask to see.
| Family | Typical controls in a cloud software company | Evidence a reviewer asks for |
|---|---|---|
| Administrative: security management | Risk analysis, risk register, risk treatment plan, sanctions policy, activity review | The dated analysis, the register with owners, a log review record |
| Administrative: people | Named security official, onboarding and offboarding, role-based access approval, security training | Appointment record, access tickets, training completions |
| Administrative: resilience | Incident response plan, backups, disaster recovery and emergency mode plans, periodic evaluation | Incident records, restore test results, the latest evaluation |
| Administrative: vendors | Business associate agreements with every vendor touching ePHI | The vendor list and signed agreements |
| Physical | Inherited data centre controls, laptop policy, full-disk encryption, device disposal | Provider's attestation, device inventory, disposal records |
| Technical: access | Unique accounts, single sign-on with multi-factor, break-glass procedure, session timeouts | Identity provider configuration, break-glass log, timeout settings |
| Technical: audit and integrity | Centralised logging of ePHI access, tamper-evident storage, checksums or database constraints | Log samples, retention settings, integrity controls |
| Technical: authentication and transmission | Strong authentication for users and services, TLS on every path, encryption of storage | Authentication policy, TLS configuration, key management settings |
A cloud provider covers the physical layer of its own facilities. Your offices, laptops and every configuration choice stay with you.
05 · Documentation
If it is not written down, it did not happen
Policies, decisions and actions, kept for six years.
- Policies and procedures. Written for every standard that applies to you.
- Records of actions. Assessments, reviews, approvals and incident handling, in writing or electronic form.
- Addressable decisions. Each one with its reasoning and any alternative chosen.
- Six-year retention. From the date created or the date last in effect, whichever is later.
- Available and current. Reachable by the people who carry them out, and revised when the environment changes.
Sources: 45 CFR 164.302 to 164.318 (Security Rule general rules, administrative, physical and technical safeguards, organisational requirements, documentation); 45 CFR 160.103 (definition of electronic PHI); HHS guidance on risk analysis under the Security Rule and on HIPAA and cloud computing.
Security Rule questions
Does the Security Rule require a penetration test?
Not by name. Your risk analysis may make one reasonable.
The rule asks for periodic technical and non-technical evaluation and for safeguards matched to risk. It does not list penetration testing. Many teams use one as evidence that technical safeguards work, and customers often ask for it.
Is our cloud provider's compliance enough?
No, it covers its layer, not yours.
A provider that signs a business associate agreement takes on duties for the infrastructure it runs. Access design, logging, encryption settings, backups and staff training on your side remain yours to implement and evidence.
How often must the risk analysis be updated?
The rule says periodically and on change; it sets no fixed interval.
The rule requires review as needed to keep protection reasonable and on environmental or operational change. Many organisations refresh it commonly once a year and after major changes such as a new data store or provider.
Can HHS certify that we meet the Security Rule?
No. HHS certifies no one.
There is no official HIPAA certificate. An independent assessment can show where you stand, and attestation reports such as SOC 2 can evidence overlapping controls, but compliance stays your ongoing duty.
Related guides
See which safeguards would survive a review.
Our HIPAA risk assessment maps your cloud controls to each standard and the evidence behind it. Counsel should confirm how the rule applies to your agreements.