What the HIPAA Security Rule requires you to do for ePHI
If a customer, contract or regulator now asks you to show HIPAA Security Rule compliance, the answer starts with what the rule asks of you. The Security Rule (45 CFR Part 164 Subpart C) requires covered entities and business associates to protect the confidentiality, integrity and availability of electronic protected health information through 18 standards and 36 implementation specifications. There is no HIPAA certification to obtain. Your organization owns its controls and the evidence for them, and no single certificate proves that you meet the rule.
The rule is flexible and technology neutral. It does not prescribe specific products or settings. Instead, you choose measures based on your size, complexity and capabilities, your technical infrastructure, your costs, and the probability and criticality of the risks to your ePHI. A small practice running a hosted scheduling tool and a large health plan operating its own data center will therefore implement different measures, and both can be compliant if each decision is justified in writing. The practical first step is to confirm which ePHI systems you create, receive, maintain or transmit, because every choice that follows depends on that inventory.
Your job is to decide, implement and document. Start by confirming with your privacy and security leads which standards apply to each system, then record how each implementation specification is met. Where a specification is addressable, record your assessment and any equivalent alternative measure. An independent assessor or auditor can test your position, but they will not issue a HIPAA certificate, and a vendor's certificate does not transfer your obligations to them. Ask any implementation partner to show exactly which controls they prepare and which evidence stays with your team.
Which standards cover which part of the program
The Security Rule groups its requirements into general rules, three safeguard categories, and two sections that govern contracts and documentation. Each card below covers one part, so you can see which section a given control belongs to before you map it to your own evidence.
General rules and flexibility
Sections 164.302 to 164.306 set the scope: ePHI must stay confidential, intact and available, and entities must guard against reasonably anticipated threats. These sections also explain how an entity chooses measures based on its size, complexity, infrastructure, cost and risk. They also define the addressable specification decision. Check that your program records the reasoning behind each choice, because the flexibility the rule allows only holds up when that reasoning is written down.
Administrative safeguards
Section 164.308 covers how the organization manages people and processes: the risk analysis and risk management cycle, the named security official, workforce clearance and access termination, security training, incident procedures, contingency planning, periodic evaluation, and business associate assurances. Most documentation requests from investigators start here. Confirm that each standard has an owner and a dated record of review.
Physical safeguards
Section 164.310 covers the physical environment around ePHI: controls on facility access, rules for workstation use and location, and device and media controls that govern hardware movement, disposal and reuse. These apply to on-premises servers, laptops and backup media alike. Check how your cloud or colocation provider's physical controls are documented and inherited into your own risk analysis.
Technical safeguards
Section 164.312 covers the controls inside systems: unique user identification and access control, audit controls that record activity, integrity protections against improper alteration, person or entity authentication, and transmission security for data in transit. Encryption appears here as an addressable specification. Confirm that audit logs are retained, reviewed and tied to the access decisions they record.
Organizational requirements
Section 164.314 sets what must be in agreements with business associates, including the assurances a business associate gives about protecting ePHI, and the plan document requirements for group health plans and their sponsors. Before a vendor touches ePHI, check that the contract includes these elements and that subcontractor obligations flow down to each downstream party.
Policies, procedures and documentation
Section 164.316 requires written policies and procedures for each Security Rule requirement, and documentation of actions, activities and assessments. It also requires retention for six years from creation or last effective date, whichever is later, with documents available to the people who run the controls and updated as conditions change. Keep a single register that links each policy to its evidence and its retention date.
Why addressable does not mean optional
Addressable does not mean optional. Of the 36 implementation specifications in Appendix A to Subpart C, 14 are required and 22 are addressable. A required specification must be implemented. For an addressable one, the entity must first assess whether the specification is reasonable and appropriate in its environment. If it is not, the entity documents why it is not and implements an equivalent alternative measure, provided that measure is reasonable and appropriate (45 CFR 164.306(d)). The only way to skip a specification is to make and record that decision, and to back it with an alternative control.
The risk analysis under 45 CFR 164.308(a)(1)(ii)(A) drives that decision. Ask the risk analysis to answer three questions for each addressable specification: where ePHI for the relevant system lives, what threat or vulnerability the specification would address, and what the cost and operational impact of implementing it would be. Encryption of ePHI at rest is the best-known example. A small practice may decide a different measure is equivalent for a specific device, but it still has to explain the reasoning. Your security official should own this worksheet, and each decision should trace back to a named risk in the register.
An assessor or OCR investigator will look for the decision record, not just the outcome. Expect requests for the risk analysis, the risk management plan, the written assessment for each addressable specification, the documented rationale for any alternative, and evidence that the alternative is operating, such as configuration exports or review logs. Under 45 CFR 164.316(b)(2)(i), these documents must be kept for six years. The 2025 proposed revision would remove the addressable category and make these specifications required, but as of October 2026 no final rule has been published, so the current rule still governs. Confirm the current status in the Federal Register proposed rule and plan your decision records to meet the existing rule today.
How a small practice and a large health plan can meet the same standards differently
A small practice, such as a three-clinician office with one electronic health record and a single network, is a covered entity with the same standards as any other. What changes is the scale of the measures. HHS says entities may weigh their size, complexity, technical infrastructure, costs and the probability and criticality of risks. In an illustrative case, a practice might rely on a managed EHR vendor's hosting, use the vendor's built-in audit logs and multi-factor sign-in, and review access quarterly through a short checklist.
- Risk analysis at practice scale: The practice still needs an accurate and thorough risk analysis. It can use the free HHS SRA Tool to inventory where ePHI lives, including laptops, email and backups.
- Named security official: One staff member, or an outside person engaged for the role, must be assigned responsibility for security policies and their enforcement.
- Written policies and training: Short, specific policies for access, passwords, devices and incidents, with documented workforce training.
- Vendor assurances: Business associate agreements must be in place before any vendor handles ePHI.
- Proportionate technical measures: Encryption and access controls sized to the practice's systems, with the reason for each addressable choice documented.
Before relying on this model, check that your risk analysis covers every device and vendor, and that your documentation is retained for six years.
A hospital or health system runs many clinical systems, medical devices, interfaces and cloud services, often with a large workforce and several sites. In an illustrative case, a system might segment clinical networks, run a formal access review process for thousands of accounts, and operate a security operations function that reviews audit logs. Its complexity raises the cost and effort of each measure, and HHS's factors point toward measures that match that exposure.
- Complex infrastructure: Risk analysis must cover medical devices, interfaces, third-party connections and shadow applications, not only the core EHR.
- Layered controls: Network segmentation, centralized logging and privileged access management address threats a small practice would handle more simply.
- Dedicated roles: A full-time security official, an incident response team and separate ownership of contingency planning are common at this scale.
- Higher probability and criticality: Ransomware and phishing against large systems carry higher probability and patient-care consequences, which supports stronger backup and restoration planning.
- Vendor oversight at volume: Many business associates and subcontractors require a tracked inventory of agreements and periodic reassessment.
Ask whether the risk analysis documents why each addressable measure was chosen, and whether the organization can show OCR its activity reviews.
A health plan is a covered entity that often processes large volumes of claims through many business associates, administrators and data exchanges. In an illustrative case, a plan might outsource claims processing to an administrator while keeping its own policies, oversight and plan-sponsor controls. The Security Rule's organizational requirements add duties that smaller providers rarely face, such as plan document conditions for group health plans and their sponsors under 45 CFR 164.314.
- Data flows across parties: The plan must map ePHI moving between members, employers, administrators, clearinghouses and cloud hosts, then obtain satisfactory assurances from each business associate.
- Plan sponsor controls: Where an employer sponsors the plan, the plan document must restrict the sponsor's access to ePHI and require safeguards.
- Scale of monitoring: Activity review, audit controls and incident detection must cover large member populations and integrated systems.
- Cost drivers: Vendor oversight, monitoring tooling and staff time usually dominate spend, and these recur each year.
- Documentation volume: Records need six-year retention and must be updated when systems change.
Confirm which functions the plan outsources, and whether each business associate contract matches the plan's own safeguards.
Building the Security Rule program in a sensible order
This sequence moves from knowing where ePHI lives to proving that safeguards still fit the risk over time. Each phase produces a document or record that the next phase depends on, so an assessor can trace a control back to the risk that justified it.
Scope where ePHI lives
Start by listing every system, service, device and location where electronic protected health information is created, received, maintained or transmitted. Include EHR and billing platforms, email, file shares, backups, mobile devices, medical devices and any cloud or hosted services. The privacy and IT leads should own this inventory, with input from clinical and operations staff who know the real data flows. The output is a current data flow map and asset list that names an owner for each system. You know this step is done when someone outside the project can follow ePHI from entry to deletion using only that map.
Complete the accurate and thorough risk analysis
Run the risk analysis required by the risk analysis implementation specification, identifying threats and vulnerabilities to the confidentiality, integrity and availability of each system in the inventory. Rate likelihood and impact, and record the current controls that reduce each risk. The HHS risk analysis guidance and NIST SP 800-66 Rev. 2 can structure the work, and the free HHS SRA Tool is one option. The output is a written risk analysis that is dated, signed off by the security official and specific enough to show which systems were reviewed and how.
Decide risk management measures and document choices
Turn the risk analysis into a risk management plan that states which measures reduce each identified risk to a reasonable and appropriate level, who owns each measure and when it will be reviewed. For every addressable implementation specification, record whether the entity implements it, documents why it is not reasonable and appropriate and adopts an equivalent alternative, or does both. Leadership should approve the plan. The output is a signed risk management plan with an addressable decision log, so each safeguard can be traced to a specific risk.
Write policies and procedures for each requirement
Draft written policies and procedures that cover every Security Rule requirement the plan relies on, including the designated security official role, workforce access, training, sanctions, incident response, contingency planning and device handling. Keep each procedure specific enough that staff can follow it and an assessor can test it against the practice. Review and approval should be recorded with dates. The output is a controlled policy set with version history, where each document names the requirement it satisfies and the person accountable for keeping it current.
Implement administrative, physical and technical safeguards
Put the planned measures into operation across the three safeguard groups: administrative controls such as workforce access and training, physical controls such as facility access and workstation and media handling, and technical controls such as access control, audit logging, integrity protection, authentication and transmission security. Track each measure against its risk and its owner. Ask any outside implementer to deliver configuration records, test results and training attendance, not only a finished system. The output is a control register that shows each safeguard as implemented, with the evidence that proves it.
Put business associate assurances in place
Identify every vendor, cloud host, subcontractor or service provider that creates, receives, maintains or transmits ePHI for you. Before any of them handle ePHI, obtain satisfactory assurances in a written contract or other arrangement that meets the organizational requirements. Review each vendor's own security evidence against the risks recorded in your analysis. The output is a vendor register that lists each business associate, the agreement in force, the date it was signed and the review that supports it.
Run evaluation, activity review and risk reevaluation
Once the program is running, review logs that track access to ePHI and detect security incidents, periodically evaluate whether the measures still work, and reassess risk when systems, staff, vendors or threats change. Record each review and the action it triggered. Keep all Security Rule documentation for six years from creation or from the date it was last in effect, whichever is later. The output is a recurring review calendar with completed review records, a current risk analysis and an archive that can answer an OCR request.
What six-year documentation has to hold
The Security Rule requires you to keep documentation of your Security Rule measures for six years from the date it was created or the date it last was in effect, whichever is later (45 CFR 164.316(b)(2)(i)). The retention clock therefore restarts each time a policy, procedure or assessment is superseded, so an outdated version does not expire on its own schedule. The same section requires that documentation be available to the people responsible for implementing the measures and be reviewed periodically and updated as needed in response to environmental or operational changes. Retention is a required specification, not an addressable one, so the question is how to keep the records, not whether to keep them.
A reviewer will usually start with the risk analysis and then ask for the records that show the analysis was acted on. Expect to produce the current and prior versions of your written policies and procedures, training materials and attendance logs, sanction records, access reviews and the evidence that terminated users lost access, security incident logs and their follow-up, business associate agreements and their subcontractor flow-down, and the results of your periodic technical and nontechnical evaluations. Each record should show a date, an owner and the version it applies to, because an undated document is hard to defend as the one in effect at a given time.
Confirm the retention rules with your legal counsel and your records management team before you set deletion schedules, since backup rotation, email archives and ticketing tools often purge data on their own timers. Ask your system owners whether logs and access reports can be exported in a readable form for the full six years, and whether your business associates retain their own copies under their contracts. Your records plan should also name who can retrieve documentation during an OCR request, so that the answer to "where is the 2021 policy" does not depend on one person.
Where each standard group sits and what evidence shows it
This table maps each part of the Security Rule to the plain-language duty it places on the organization and the records an assessor usually asks to see. Read it as a checklist of what to keep on file, not as a list of certificates, because the Security Rule does not provide for any third-party certification. Evidence in each row is what your own organization produces and retains.
| Regulation section | Safeguard group | What the group asks the entity to do | Typical evidence an assessor requests |
|---|---|---|---|
| General rules (164.306) | General requirements | Protect the confidentiality, integrity and availability of all ePHI you create, receive, maintain or transmit, and choose measures suited to your size and risks. | Documented scope of ePHI systems, the reasoning behind chosen measures, and the record of decisions on addressable specifications |
| 164.308 (administrative) | Administrative safeguards | Run a risk analysis and risk management, assign a security official, manage workforce access, train staff, respond to incidents, plan for contingencies and evaluate periodically. | Current risk analysis and risk management plan, named security official, access review logs, training records, incident logs, contingency test results and business associate agreements |
| 164.310 (physical) | Physical safeguards | Limit physical access to systems holding ePHI, control workstation use and secure devices and media through their lifecycle, including disposal and re-use. | Facility access procedures and visitor logs, workstation use policy, device and media inventory, and certificates or logs of media destruction or re-use wiping kept by your organization |
| 164.312 (technical) | Technical safeguards | Control access to ePHI, record and examine activity, protect ePHI from improper alteration, verify identity and guard transmissions, including encryption where you have assessed it. | Access control lists, unique user ID configuration, audit log settings and review records, integrity controls, authentication settings, and encryption configuration for data at rest and in transit |
| 164.314 (organizational) | Business associate and plan requirements | Make sure business associate contracts or other arrangements include the required security terms, and for group health plans, make sure plan documents address ePHI safeguards. | Signed business associate agreements, subcontractor flow-down terms, vendor assurance records and, for group health plans, the amended plan document language |
| 164.316 (policies and documentation) | Policies, procedures and documentation | Write policies and procedures for each Security Rule requirement, keep them available, update them, and retain the documentation for six years. | Versioned policy set with approval dates, revision history, a retention schedule showing six-year records, and proof that current staff can access the documents |
Who owns the controls, who prepares evidence and who reviews it
The covered entity or business associate is the party the Security Rule binds, so it owns every safeguard, every decision about whether an addressable specification is reasonable and appropriate, and the accountability for what happens to electronic protected health information (ePHI). Outside help does not move that responsibility. The organization must name a security official, perform and maintain the risk analysis, and keep the written policies and six-year documentation that show its decisions. When it says a measure is reasonable and appropriate, it must be able to explain why.
- Risk analysis and risk management: The organization decides the scope of ePHI, the threats it faces and the measures it adopts in response.
- Security official role: A named individual, who may be internal or outsourced, answers to leadership for the program.
- Addressable decisions: The organization records whether each addressable specification is implemented, what alternative it uses, or why it is not needed.
- Business associate contracts: The organization obtains satisfactory assurances in writing before a vendor handles ePHI.
- Workforce and sanctions: Staff training, access decisions and sanction policies remain the organization's own obligations.
Before engaging anyone, confirm internally who signs off on each control and who holds the documentation file.
An implementation partner, such as DeployOpen, prepares the systems, configurations, documentation and evidence that the covered entity or business associate uses to run its Security Rule program. DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. The work is performed under a written, fixed scope that sets out deliverables and timelines before work starts. The partner does not issue audit reports, attestations or certifications, and it does not decide whether the client complies.
- Systems and configuration: Hardening, access control settings, logging and backup set-up on infrastructure the client owns.
- Documentation drafts: Procedures, system descriptions and configuration records that the client reviews, approves and maintains.
- Evidence preparation: Log exports, access reviews and test results organized so the client's own staff can present them.
- Testing support: Security testing that feeds the risk analysis, performed under agreed rules of engagement.
- Handover: Written records of what was built, who operates it and what the client must run after the engagement ends.
Ask for the written scope, name the client's owner of each deliverable, and confirm which items remain the client's responsibility after handover.
An independent auditor or assessor tests the controls against the Security Rule and any report it issues belongs to that assessor. HHS does not endorse or recognize private certifications, and no Security Rule standard requires an entity to certify compliance. Even a favorable third-party assessment does not prevent the HHS Office for Civil Rights (OCR) from later finding a violation. OCR, through complaint investigations, compliance reviews and audits, decides whether the entity complies with the rule.
- Independent testing: The assessor samples configurations, records and interviews to check whether controls operate as described.
- Scope limits: A report covers only the systems, dates and requirements named in its scope.
- No ownership of controls: The assessor cannot design the controls it tests without losing independence.
- OCR authority: Only OCR determines compliance for enforcement purposes, using its own review of the record.
- Report terms: Read what the assessor says it did, what it did not test and how the entity may describe the result to customers.
Before relying on any assessment, confirm the assessor's qualifications, the exact scope and whether the report claims compliance, which HHS does not treat as a certification.
Which gaps usually show up first in a Security Rule review
Most Security Rule findings trace back to a small set of gaps: incomplete scope, undocumented decisions, policies that drift from reality, missing vendor assurances, unperformed reviews and lost records. Each card below names one gap, a check you can run this week, and what to confirm in your own environment.
Risk analysis misses ePHI locations
The risk analysis must be an accurate and thorough assessment of risks to all ePHI the entity creates, receives, maintains or transmits. Gaps appear when the inventory covers the EHR and ignores backups, email archives, laptops, medical devices, shared drives and vendor-hosted systems. Check: pick three systems that touch patient data and confirm each appears in the analysis with its threats and controls. Confirm with system owners, not only the IT asset list.
Addressable decisions lack reasoning
For each addressable implementation specification, the entity must decide whether it is reasonable and appropriate, document why when it is not, and adopt an equivalent alternative where reasonable. Reviewers often find the decision was never written down, or that a choice to skip encryption rests on no analysis. Check: for every addressable specification, confirm a dated record exists that links the decision to the risk analysis.
Policies that do not match systems
Written policies must describe how the organization actually protects ePHI. A common gap is a policy requiring quarterly access recertification, automatic logoff or a specific backup schedule while the systems run differently. Check: take three policy statements on access, logging and backup and trace each to a configuration setting or a recent ticket. Confirm the owner signed off on the current version.
Missing business associate assurances
A covered entity may let a business associate handle ePHI only after obtaining satisfactory assurances in a written contract or other arrangement. Gaps appear when a hosting provider, billing company or managed IT firm processes ePHI under a standard service agreement with no safeguard terms. Check: list every vendor with ePHI access and confirm each has a signed agreement that covers Security Rule obligations and subcontractor flow-down. Ask legal counsel to review the terms.
Reviews that never happen
The Security Rule expects entities to regularly review records of access to ePHI and detect security incidents, periodically evaluate security measures, and reevaluate risks. Reviewers often find log review and evaluation plans written but never carried out, with no dated results. Check: pull the last three access reviews and the most recent periodic evaluation. Confirm each has a date, a reviewer, findings and a follow-up action.
Six-year records overwritten
Security Rule documentation must be retained for six years from creation or from the date it last was in effect, whichever is later. Gaps appear when policies are edited in place, old risk analyses are deleted during cleanup, or a document management tool purges by default. Check: confirm superseded versions of policies, risk analyses and assessments still exist with effective dates, and confirm your retention settings meet the six-year period.
Questions buyers ask about Security Rule requirements
Is there a HIPAA certificate I can buy instead of doing the work?
No. There is no official HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation. Third-party HIPAA certificates and seals can show that an assessor reviewed something on a given date, but they do not replace your own risk analysis and evidence. Ask a vendor for its risk analysis summary, policies, training records and the scope of any independent assessment instead. The HHS FAQ on certification explains the position in HHS's own words. For the wider picture, see the HIPAA certification explained page.
What does addressable mean in practice?
Addressable does not mean optional. For each addressable implementation specification, you must assess whether it is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why and implement an equivalent alternative measure if that is reasonable and appropriate. Under 45 CFR 164.306(d), your risk analysis drives that decision. Of the 36 implementation specifications in Appendix A, 22 are addressable and 14 are required. Encryption is the best-known example: many organizations find it reasonable to encrypt ePHI at rest and in transit, but the decision still has to be recorded. The required versus addressable page covers the three choices in detail.
Can a small practice do this without outside help?
Often yes, if the practice has a named security official, a manageable number of systems and enough time to learn the rule. HHS describes the Security Rule as flexible and scalable, so measures can match the size, complexity and capabilities of the organization. The most demanding task is the risk analysis, and HHS publishes a free Security Risk Assessment Tool and guidance on risk analysis that small practices can use. Outside help is most useful for reviewing the risk analysis, configuring systems and writing policies that match actual practice. Be clear about roles: an outside consultant or implementation partner can prepare systems and documents, but the organization owns its safeguards and decisions. The small practice guidance on the HIPAA organization type pages and the consultants and services page cover the trade-offs.
What does the work need from our staff?
Expect the work to need named owners, not just IT time. The rule requires a security official, workforce training and sanctions, access decisions by role, and regular review of records that track access to ePHI and detect security incidents. Staff from operations, clinical or billing teams will need to describe where ePHI actually lives and how it moves, which is the input the risk analysis depends on. Leadership must approve policies and accept residual risk. IT staff handle configuration, logging, backup and access controls. The effort depends on how many systems hold ePHI, how many people have access and how much documentation already exists. Ask any advisor which of these tasks they will do, which they expect your team to do, and how they will hand over the evidence. The HIPAA Security Rule compliance checklist lists the artifacts OCR expects.
How long must we keep Security Rule documentation?
Keep Security Rule documentation for six years. Under 45 CFR 164.316(b)(2)(i), retention runs from the date the document was created or the date it last was in effect, whichever is later. Retention is a required implementation specification, so it applies to every entity. In practice, this means keeping superseded policies, risk analyses, risk management plans, training records and sanctions records, and business associate arrangements for at least six years after each version stopped being in effect. Your backup and archive design should preserve these records and make them retrievable, because OCR investigations often request them after a long delay. The policies, procedures and documentation pages explain the three documentation specifications.
Does the Security Rule require encryption or multi-factor authentication today?
Not as a flat mandate. The current rule does not require multi-factor authentication. Encryption is an addressable specification for ePHI, so you must assess it, decide whether to implement it, and document any alternative if you do not. In practice, regulators expect strong, justified decisions for systems that hold ePHI, and an unencrypted device lost or stolen without a documented rationale is hard to defend. The January 2025 proposal would make encryption and multi-factor authentication mandatory, and that status is not final. Confirm the current text of the rule on the eCFR and check the proposal's status on the Federal Register and reginfo.gov before you rely on any timeline. The HIPAA security requirements and proposed changes pages cover both states of the rule.
What is the 2025 proposal changing, and when will it take effect?
HHS proposed a major revision to the Security Rule on January 6, 2025 (90 FR 898, RIN 0945-AA22). The proposal would remove the addressable category, make encryption and multi-factor authentication mandatory, require an asset inventory and network map, set a 72-hour restoration target for critical systems, and add annual compliance audits and penetration testing. Comments closed March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists the rule under Long-Term Actions with final action projected for July 2027. Those dates can move, so check the Federal Register proposal and the reginfo.gov entry for RIN 0945-AA22 before making plans. The proposed changes page tracks the details.
How DeployOpen prepares systems and evidence for a Security Rule review
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems that hold ePHI can be shown against the Security Rule's safeguards. We prepare systems and evidence for your review; the covered entity or business associate owns its controls, and only an independent auditor or assessor issues reports.
How we scope
- Scope is agreed in writing before work starts, listing the ePHI systems, safeguards and standards covered.
- We map which implementation specifications are required and which are addressable, so your decisions are recorded.
- Scope names what stays with your security official, workforce and assessor, and what DeployOpen prepares.
How we build
- We configure access control, audit logging, encryption and backup settings on platforms running in your cloud or data center.
- Each safeguard is tied to a documented control owner, configuration baseline and the evidence that shows it operates.
- Testing covers applications, APIs and infrastructure, with findings tracked against your risk analysis and risk management plan.
How we hand over
- Deliverables include configuration records, policies drafts, test results and an evidence index keyed to each standard.
- Documentation is written so your team can retain it for six years and keep it current as systems change.
- Your organization reviews and approves every control and document before it is presented to any independent assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement ends.
- Retainers can keep evidence current when platforms are patched, upgraded or when new ePHI systems are added.
- Confirm with DeployOpen the exact support terms, response expectations and fees in the written quote before you commit.
