HIPAA Security Risk Assessment for Small Practices: What’s Required, What’s Optional, and What Evidence to Keep

This article is informational and educational. It is not legal advice. Regulatory text and federal guidance are periodically revised — confirm the current version of any citation with your counsel or compliance advisor before relying on it.

The short answer. If your practice is a covered entity, or a business associate handling electronic protected health information (ePHI), the HIPAA Security Rule requires you to conduct a risk analysis and to manage the risks it finds. Those are two separate required implementation specifications at 45 CFR § 164.308(a)(1)(ii)(A) and (B). There is no small-practice exemption based on size, patient volume, or specialty. The Security Rule does not set a calendar date such as "every January"; it requires periodic technical and nontechnical evaluation at 45 CFR § 164.308(a)(8), and HHS Office for Civil Rights (OCR) guidance describes risk analysis as an ongoing process rather than a one-time project. Required Security Rule documentation must be retained for six years under 45 CFR § 164.316(b)(2)(i).

Most other guidance on this topic is either a restatement of the regulation or a template download. Neither tells a practice administrator what to do on Monday morning, what evidence belongs in the file, or where a vendor relationship changes the work. This piece is organized around those decisions.

One governing principle, stated once so the rest of the article can refer back to it: the obligation is yours. A questionnaire, a template, a vendor's compliance marketing, a SOC 2 report, a private certification, or a consultant's PDF can each be an input to your risk analysis and risk management. None of them is a substitute for it, because the Security Rule places the duty on the covered entity or business associate itself (45 CFR §§ 164.306, 164.308).

What the HIPAA Security Rule Actually Asks For

The HIPAA Security Rule is codified at 45 CFR Part 164, Subpart C (§§ 164.302–164.318) and applies to ePHI. The Privacy Rule (45 CFR Part 164, Subpart E) governs uses and disclosures of protected health information (PHI) more broadly; the Breach Notification Rule (45 CFR Part 164, Subpart D) governs what you do after an incident. They are related but distinct obligations, and risk analysis is a Security Rule concept.

Risk analysis as a required implementation specification

The Security Rule's administrative safeguards include a Security Management Process standard at 45 CFR § 164.308(a)(1)(i). Two of its implementation specifications are designated required, not addressable:

• Risk analysis, 45 CFR § 164.308(a)(1)(ii)(A): "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate."
• Risk management, 45 CFR § 164.308(a)(1)(ii)(B): "Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level as required by § 164.306(a)."

The general requirements at 45 CFR § 164.306(a) and the flexibility-of-approach provision at 45 CFR § 164.306(b) frame both.

So: is a risk assessment legally required, or just a best practice? For covered entities and business associates, risk analysis is a required implementation specification under 45 CFR § 164.308(a)(1)(ii)(A). It is not optional, and a general IT security review that never identifies ePHI is unlikely to satisfy it.

OCR has published guidance specifically on this specification — Guidance on Risk Analysis Requirements under the HIPAA Security Rule, issued by the U.S. Department of Health and Human Services, Office for Civil Rights, and available on the HHS HIPAA guidance pages. It remains the most directly applicable federal description of what an acceptable analysis involves. Because HHS periodically revises and reissues guidance, check the current version on hhs.gov when you begin an assessment; the citation in this article is to the document as titled by HHS, not to a particular archived copy.

Risk analysis vs. risk management: two obligations, not one

This distinction matters more than any other point in this article, and small practices collapse it constantly.

• Risk analysis — § 164.308(a)(1)(ii)(A) — is the assessment: identify where ePHI lives, what could go wrong, how likely it is, and how bad it would be.
• Risk management — § 164.308(a)(1)(ii)(B) — is the response: implement security measures sufficient to reduce those risks to a reasonable and appropriate level.

They are separate required specifications, and completing one does not satisfy the other. An analysis that is genuinely accurate and thorough may satisfy § 164.308(a)(1)(ii)(A) even if the practice then fails to act on it — but the failure to act is a separate deficiency under § 164.308(a)(1)(ii)(B). Conversely, a remediation project list with no underlying analysis leaves the analysis specification unmet and gives the remediation priorities no documented basis. In our experience reviewing small-practice files, the missing half is almost always the second one: a report exists, and nothing in the file shows what was decided about its findings.

Where the Security Rule stops and organizational judgment begins

45 CFR § 164.306(b) expressly allows a covered entity or business associate to use any security measures that reasonably and appropriately implement the standards, taking into account its size, complexity, and capabilities, its technical infrastructure, the cost of measures, and the probability and criticality of potential risks. The Rule is technology-neutral: it does not name products, prescribe a scoring formula, or set a numeric risk threshold.

That flexibility is real, and it is not permission to do less. Practically — and this is our operational reading, not a quotation from the regulation — flexibility shifts the burden of showing your reasoning onto you. If the Rule does not define "reasonable and appropriate" for your practice, your documentation has to.

Why "required" vs. "addressable" does not mean "mandatory" vs. "optional"

Security Rule implementation specifications are designated either required or addressable (45 CFR § 164.306(d)). An addressable specification is not optional. Under § 164.306(d)(3), for an addressable specification you must assess whether the specification is a reasonable and appropriate safeguard in your environment, and then either implement it, or — if implementing it is not reasonable and appropriate — document why not and implement an equivalent alternative measure if reasonable and appropriate.

Can we decide not to encrypt something? Possibly, but only through that documented process. The technical safeguards standard for access control includes an addressable implementation specification for encryption and decryption at 45 CFR § 164.312(a)(2)(iv), and transmission security includes an addressable encryption specification at 45 CFR § 164.312(e)(2)(ii). Because these are addressable rather than required, a reasoned, documented decision not to implement them in a specific circumstance is contemplated by § 164.306(d)(3).

What the regulation does not do is bless any particular alternative in advance. Physical restriction of a device, or a compensating control, may form part of an analysis — but it is not presumptively sufficient. The decision has to rest on your own environment-specific assessment of risk under § 164.306(a)–(b), and the reasoning and any alternative measure have to be documented. An undocumented absence of encryption is indistinguishable from an oversight.

Who Needs One (and Who Thinks They Don't)

Covered entities are defined at 45 CFR § 160.103 and include health care providers who transmit health information in electronic form in connection with a transaction covered by the HIPAA transaction standards — medical practices, dental offices, clinics, behavioral health providers, and specialty practices among them.

Business associates — persons or entities that, on behalf of a covered entity, create, receive, maintain, or transmit PHI for a covered function or activity, as defined at 45 CFR § 160.103 — have direct Security Rule obligations. The Security Rule's applicability provision at 45 CFR § 164.302 and the general requirements at § 164.306(a) apply to business associates as well as covered entities; that direct applicability traces to the HITECH Act and the 2013 HIPAA Omnibus Rule, which extended Security Rule requirements to business associates and their subcontractors that create, receive, maintain, or transmit ePHI. If you are a billing service or a managed service provider (MSP) that meets the definition, the risk analysis obligation applies to your own environment too.

There is no small-practice exemption. Nothing in 45 CFR Part 164, Subpart C conditions applicability on head count, patient volume, or specialty. Keeping most records on paper does not remove the obligation either: the Security Rule applies to ePHI a covered entity or business associate creates, receives, maintains, or transmits (45 CFR § 164.306(a)), so a single cloud EHR, one billing portal, or one laptop brings that ePHI in scope. The flexibility language at § 164.306(b) affects how you implement safeguards, not whether you analyze risk.

How often, and what triggers a fresh look

Does the Security Rule require an annual risk assessment? Not in those words. Two separate authorities are relevant, and they should not be merged into one imaginary rule:

1. The regulation. 45 CFR § 164.308(a)(8) contains a required Evaluation standard: perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under the Rule and subsequently in response to environmental or operational changes affecting the security of ePHI. That is an evaluation requirement; the Rule does not attach a fixed interval to it.
2. OCR guidance. In Guidance on Risk Analysis Requirements under the HIPAA Security Rule, HHS describes risk analysis as an ongoing process rather than a single event, and indicates that entities should update it as circumstances warrant. Confirm the current wording on hhs.gov, since the guidance has been reissued over time.

Neither authority prescribes a specific annual calendar deadline for risk analysis. The following is our operational recommendation, not a regulatory quotation: review annually, and update whenever one of these events occurs.

• New or replaced EHR or practice management system
• Migration of any system to cloud hosting
• Merger, acquisition, or opening a second location
• A security incident or breach
• A new vendor with ePHI access, or an existing vendor changing its architecture
• Significant staffing or workflow change (new remote work, a new BYOD practice)
• A payer, insurer, or partner request that puts your documentation under review

An annual cadence plus change-driven updates is a defensible operational default and maps cleanly onto the § 164.308(a)(8) evaluation standard. It is not the only defensible cadence.

Scoping the Assessment: Find the ePHI First

A risk analysis that misses a system is hard to describe as "accurate and thorough" in the sense § 164.308(a)(1)(ii)(A) requires, and scoping is where small practices most often fail before they start.

Building an ePHI inventory

For each item, record: what it is, what ePHI it holds or transmits, who administers it, where the data physically or logically resides, who has access, and which vendor is involved.

Systems small practices routinely miss

1. PACS and medical/dental imaging systems, including intraoral and radiography workstations
2. Local backup appliances and cloud backup buckets
3. Patient texting and appointment-reminder platforms
4. Email, including mailboxes holding referrals, statements, or attachments
5. Cloud fax and e-fax services
6. Personal phones, tablets, and home computers used for portal access or on-call work
7. Copiers, scanners, and multifunction printers with internal storage
8. Voicemail, call recording, and answering services
9. Intraoffice chat tools and shared network drives holding scanned documents
10. Legacy workstations kept alive for a single discontinued application
11. Removable media — USB drives, imaging discs, external hard drives
12. Remote access paths — VPN, remote desktop, and vendor support tunnels

Mapping data flows to vendors

Draw the paths, not just the boxes. ePHI moving from your EHR to a clearinghouse to a payer crosses several parties. Each hop is a place where your analysis needs to say who holds the data and under what agreement.

If you produce a data flow diagram for the assessment file — recommended — give the image descriptive alt text such as "Data flow diagram showing ePHI moving from front desk workstations to the cloud EHR, to the billing service, and to the clearinghouse, with backup and imaging paths marked," and keep the same information available as text or an HTML table in the document body so the content is accessible and reviewable without the image.

Defining boundaries you can defend

State explicitly what is in scope and what is out, and why. "Out of scope" is a decision that needs a reason on paper: "guest Wi-Fi VLAN, no ePHI systems reachable, verified by segmentation test on [date of your test]" is defensible. An unexplained gap is not.

Running the Assessment: A Workable Method for a Small Team

Three named resources are worth knowing about before you start.

• NIST Special Publication 800-30, Guide for Conducting Risk Assessments (National Institute of Standards and Technology) is the most commonly referenced methodological anchor for likelihood/impact risk assessment. Check nist.gov for the current revision.
• NIST Special Publication 800-66, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide maps security practices to Security Rule standards. Check nist.gov for the current revision.
• The Security Risk Assessment (SRA) Tool, published by HHS's Office of the National Coordinator for Health Information Technology (ONC) — now part of the Assistant Secretary for Technology Policy — with OCR, is a free downloadable application aimed at small and medium providers. Confirm the current version and its documented scope on the HHS site before relying on it.

Two qualifications matter. NIST publications are guidance, not binding regulation for covered entities; using them helps you show a structured method, but conformance to NIST is not itself the legal standard. And the SRA Tool is a structured worksheet that helps you organize and record an analysis — per the governing principle above, it does not by itself produce compliance, a certification, or your risk management plan.

What is the difference between a risk analysis and a risk assessment questionnaire? A questionnaire records answers about your practice. A risk analysis produces environment-specific findings — this system, this weakness, this likelihood, this impact, this decision. A completed questionnaire with no findings tied to named systems is a record of answers, not an analysis of risk to your ePHI.

The sequence we recommend:

1. Identify threats and vulnerabilities relevant to your actual environment: ransomware reaching unsegmented imaging systems, credential phishing against clinical email, lost unencrypted laptops, a departing employee's retained access, vendor support tunnels left open, backup failure discovered only during a recovery attempt.
2. Assess likelihood and impact on a simple scale — low/medium/high is sufficient. Do not manufacture false precision with decimal scores you cannot justify.
3. Document existing safeguards and their actual state. The difference between "we require MFA" and "MFA is enforced on 14 of 17 accounts; three service accounts are excepted" is the difference between an assertion and a finding. Verify; do not assume.
4. Assign risk levels and rank remediation so the highest-severity, most-likely items get attention first.
5. Turn findings into a risk management plan, including a documented decision for anything you are not fixing. Naming an owner and a target date for each item is our recommendation because it is how remediation actually happens and how you later evidence § 164.308(a)(1)(ii)(B); the Rule itself specifies the security-measures obligation and the documentation obligation (§ 164.316) rather than a particular register format.

Administrative, physical, and technical safeguards should each be represented (45 CFR §§ 164.308, 164.310, 164.312): workforce security and training, facility and device controls, access control, audit controls, encryption, and the contingency plan including data backup and disaster recovery (§ 164.308(a)(7)).

How long does this take, and what does it cost?

We are not publishing figures we cannot source, and you should be skeptical of anyone who quotes a price before seeing your environment. What we can do is name the variables that drive effort, because they are the same variables a credible quote will be built from:

• Number of ePHI systems and the number of vendors touching them
• Whether anything is self-hosted — on-premises servers, imaging systems, or PACS storage add verification work that a single cloud EHR does not
• Number of physical locations, and whether each has its own network
• Whether an inventory already exists, or has to be built from scratch
• Whether controls will be verified or attested — verifying MFA enforcement, encryption status, and backup restores account-by-account and device-by-device takes materially longer than accepting staff answers, and produces materially stronger evidence
• State of prior documentation — an assessment that updates a maintained register is faster than a first cycle
• Whether remediation is in scope or only the analysis and plan
• Internal availability — the assessment usually stalls on staff time for interviews and evidence collection, not on the assessor

Practices with a single cloud EHR, a handful of vendors, and no self-hosted systems are at the light end of that range; multi-location practices with imaging, on-premises servers, and broad MSP administrative access are at the heavy end. Ask any prospective assessor to price against those variables explicitly.

Required vs. Optional Work: A Decision Table

The middle column separates express regulatory requirements from documentation you would need in order to demonstrate a requirement, and from our operational recommendations.

On the certification row

There is no federal HIPAA certification program. HHS materials on HIPAA compliance describe obligations that entities must implement and be able to demonstrate, and OCR's enforcement and audit activity assesses compliance against the regulations themselves; HHS does not issue, endorse, or accredit "HIPAA certified" status for organizations, products, or training. Readers can verify this on the HHS HIPAA pages at hhs.gov, and we recommend doing so rather than taking our word for it.

That is a separate matter from private programs. HITRUST CSF certification, SOC 2 attestation reports issued by CPA firms, and vendor self-attestations are private-sector artifacts. They may be useful evidence — HITRUST in particular maps controls to HIPAA Security Rule requirements — but they are not government certification, they do not bind OCR, and they do not establish that your practice has met its own obligations under §§ 164.308–164.316. Per the governing principle: input, not substitute.

If you are unsure whether your current documentation would hold up, SecureTrust can help you scope or validate a security risk assessment — including reviewing an assessment you already have. Content gap: this contextual CTA needs a link to the SecureTrust security risk assessment service page; no service or consultation URL was available in the approved link set, so no link has been inserted rather than a guessed one.

Evidence: What to Keep and How Long

The practical difference between a compliant practice and an unprovable claim is the file. 45 CFR § 164.316(b)(1) requires that the policies and procedures implemented to comply with the Security Rule be maintained in writing, and that any action, activity, or assessment required by the Rule be documented.

The documentation set

The Rule requires documentation of required actions, activities, and assessments (§ 164.316(b)(1)) but does not enumerate a file structure. The following set is our recommended way to satisfy that requirement legibly:

• ePHI inventory and data flow map, dated
• The risk analysis itself: method used, systems assessed, findings
• A risk register with per-finding detail
• A risk management plan or corrective action plan with owners and dates
• Written approval by the practice owner or the designated security official (§ 164.308(a)(2) requires the designation; the sign-off is our recommendation)
• Vendor list with BAA status and the security information you reviewed

Evidence of implementation, not intent

Policies show intent. What demonstrates implementation is operational residue: training completion records with names and dates, access review sign-offs, ticket history for remediation items, backup restore test results, audit log samples showing that logging is enabled and reviewed (see the audit controls standard at 45 CFR § 164.312(b)), and offboarding checklists for departed staff (see termination procedures at § 164.308(a)(3)(ii)(C)). The specific formats are ours to recommend; the underlying standards are the Rule's.

What OCR guidance emphasizes

What does OCR look for in a risk analysis? We can point to what HHS has published rather than characterize investigator behavior generally.

• Guidance on Risk Analysis Requirements under the HIPAA Security Rule (HHS/OCR) sets out the elements HHS associates with an acceptable analysis, including identifying where ePHI is created, received, maintained, or transmitted, identifying threats and vulnerabilities, assessing current security measures, determining likelihood and impact, determining risk level, and documenting the results — and describes the analysis as an ongoing process.
• The HIPAA Audit Program protocol published by OCR sets out, for each standard and implementation specification, the kinds of documentation an audited entity may be asked to produce. Reading the protocol entries for § 164.308(a)(1) and § 164.316 is a direct way to see what a document request looks like, expressed by OCR itself.
• OCR publishes resolution agreements and corrective action plans on hhs.gov. Where risk analysis appears in those documents, it is characterized as an allegation or finding in that specific matter.

Two cautions, stated as our editorial position: describe published enforcement documents only as published, and do not extrapolate a general legal standard from a single settlement. If you cite an enforcement action internally, name the specific action and link to the HHS page for it so a reviewer can read the actual language.

Retention: six years, from when

How long do we keep it? 45 CFR § 164.316(b)(2)(i) requires that the documentation required by § 164.316(b)(1) be retained for six years from the date of its creation or the date when it last was in effect, whichever is later.

Two consequences follow directly from that wording. First, the clock is not simply "six years from the assessment date" for a document that stayed in force: a policy in effect for four years is retained for six years after it ceased to be in effect. Second, superseded versions matter — which is why our recommendation is to retain prior versions rather than overwrite them. Note also that state law and payer contracts may impose longer retention periods; those are outside the Security Rule and worth checking with counsel.

§ 164.316(b)(2)(ii) additionally requires documentation to be made available to the persons responsible for implementing the procedures it concerns, and § 164.316(b)(2)(iii) requires periodic review and updating as needed in response to environmental or operational changes affecting the security of ePHI.

Version control

Date and version every document, and keep the prior cycle's analysis. Being able to show that a finding was opened in one cycle, remediated, and verified in the next is, in our experience, among the more persuasive artifacts a small practice can produce — and it aligns with the review-and-update requirement at § 164.316(b)(2)(iii).

Where Vendors and BAAs Change the Assessment

What a BAA does and does not transfer

Does signing a business associate agreement transfer risk or responsibility? No. A business associate agreement is a contract; the required content is specified at 45 CFR § 164.504(e), and § 164.308(b) requires a covered entity to obtain satisfactory assurances, documented through such a contract, that a business associate will appropriately safeguard ePHI. Since the HITECH Act and the 2013 Omnibus Rule, business associates also carry direct Security Rule obligations of their own (45 CFR § 164.302; § 164.306(a)).

None of that displaces your own duty under § 164.308(a)(1)(ii)(A) to analyze risk to the ePHI you create, receive, maintain, or transmit, including the paths it takes. A BAA changes who else is accountable, not whether you are.

Do we still need our own analysis if our EHR vendor is HIPAA compliant?

Yes. A cloud EHR vendor's controls cover the vendor's environment. Your risk analysis has to cover your side of the line: workstation and device security, user provisioning and termination, password and MFA configuration, printed output, remote access, staff behavior, and the local systems the EHR touches. "HIPAA compliant" used as a vendor marketing phrase describes the vendor's claim about its own service; it says nothing about your configuration of it, and — see the certification discussion above — no federal body certifies that claim.

Reviewing vendor security posture

Reasonable things to request: an executed BAA; a current SOC 2 Type II report, HITRUST CSF certification, or equivalent; a description of encryption in transit and at rest; breach notification commitments and timelines; subcontractor disclosure; and the support access model. Accept documents you can actually read and evaluate; a compliance logo on a web page is not a document.

Cloud EHR, managed IT, billing, transcription

Business associate status is function- and data-dependent, not category-dependent. Under the definition at 45 CFR § 160.103, the question is whether the person or entity creates, receives, maintains, or transmits PHI on behalf of a covered entity in performing a covered function or activity, or provides specified services involving disclosure of PHI. Cloud EHR hosts, medical billing services, transcription services, and MSPs with administrative access to systems holding ePHI commonly meet that definition — but the determination has to be made vendor by vendor, based on what the vendor actually does with your data. A contractor whose work never involves PHI, and who has no access to it, is a different case; HHS guidance on business associates and on cloud service providers is the place to start on close calls.

MSPs and billing services deserve particular attention because they often hold broad administrative access. Ask specifically how their access to your systems is authenticated, logged, and reviewed. That is a control in your environment under § 164.312(a) and § 164.312(b), and it belongs in your register.

SOC 2 and HITRUST are inputs, not substitutes

Can we rely on a vendor's SOC 2 or HITRUST report instead of assessing them ourselves? No — the governing principle applies here as everywhere. Read the report's scope section and its exceptions, then record what it tells you and what it does not. A report scoped to one product line says nothing about another. A report is evidence that you considered vendor risk; it is not your risk analysis.

Documenting vendor risk in your own register

Give each significant vendor at least one register entry: what ePHI it touches, what you reviewed, the residual risk, and your decision.

Common Failure Modes in Small-Practice Assessments

Use these as self-checks against the assessment you already have. These are patterns we see in small-practice files, offered as diagnostics rather than as legal conclusions.

• The one-and-done from three years ago, unchanged through an EHR migration and two new vendors. Consider it against the evaluation standard at § 164.308(a)(8) and the update requirement at § 164.316(b)(2)(iii).
• A completed template with no environment-specific findings — every answer generic, no system named, no weakness identified.
• Findings with no owner and no date. This is a risk-management weakness in practice: without an owner, remediation tends not to happen and the file cannot show what was done about the finding.
• Unverified assumptions about encryption and access control. "The laptops are encrypted" — checked how, on which machines, on what date?
• No record of owner or security official review. Sign-off is our recommendation rather than a stated requirement, but an unapproved assessment reads as a consultant's artifact rather than a management decision.
• An analysis that stops at the network edge, ignoring cloud systems, personal devices, and vendor-hosted services.

What a defensible risk register entry looks like

The following is an illustrative entry, presented as an accessible table. Register fields are our recommended format, not a schema named in the regulation.

Fill in real dates and names in your own register. Bracketed placeholders left in a working register mean the item has no deadline, which is worth fixing before your next review.

When to Do It Yourself and When to Bring in Help

Who inside the practice should own and approve the assessment? 45 CFR § 164.308(a)(2) requires the designation of a security official responsible for developing and implementing the Rule's policies and procedures. Beyond that designation, the following is our recommendation: one named person — often the practice administrator — owns the assessment, and the owner or governing body reviews and signs off on the results. Delegating execution is fine. Delegating accountability is not, because the obligation under § 164.306(a) sits with the entity.

Signals you can run it internally: a simple environment, a single cloud EHR, few vendors, no self-hosted servers, and someone on staff with the time and discipline to inventory systems and verify controls rather than assume them. The HHS/ONC SRA Tool is a reasonable structure for this case.

Signals you need outside help: self-hosted servers or imaging systems; multiple locations; a recent incident, breach, or payer inquiry; an existing assessment that has never produced a specific finding; broad MSP administrative access nobody has reviewed; a merger; or no one internally who can verify a technical control independently of the person who configured it.

What to ask a prospective assessor: What method do you use, and how does it map to the required implementation specifications at § 164.308(a)(1)? Will you produce a risk register with likelihood, impact, owners, and dates, or only a scored report? Will you verify controls or rely on our answers? Will you name systems and configurations, or issue generic findings? What do we own and retain afterward — and in what format? How does your quote change with the scope variables above? And be direct about certification: anyone promising federal HIPAA certification or guaranteed compliance is describing something that does not exist.

A good deliverable includes the ePHI inventory and data flow map, the analysis method, environment-specific findings, a risk register you can maintain yourself, a prioritized remediation plan with owners and dates, and a place for owner approval — in editable form, not a locked PDF you cannot update next quarter.

Talk with SecureTrust about a security risk assessment

If you are not sure whether your current risk analysis would hold up under review — or you have never had one done — SecureTrust can help you scope an assessment for your environment, or validate and strengthen an assessment you already have. We will tell you what your documentation supports and what it does not. No certification claims, no compliance guarantees: those are not things any vendor can honestly sell.

Content gap for the editor: this block needs a booking or contact link (service page and/or consultation page). No SecureTrust service, contact, or booking URL was included in the approved link set, so none has been inserted.

Related reading

• How to conduct a HIPAA risk assessment: the complete, actionable guide — general assessment methodology
• Why every clinic needs a comprehensive HIPAA risk assessment
• HIPAA risk assessment for dental practices: how to do it right
• HIPAA Security Rule enforcement in 2026: moving from risk analysis to active risk management
• Ransomware in dental clinics — threat context for the contingency plan and backup findings
• Supply chain cybersecurity for MSPs — vendor and subcontractor risk
• IT outages vs. cyber attacks: differentiating, mitigating, and building resilience — availability and contingency planning
• When crisis hits: building an incident playbook during the incident — incident response context

Informational only; not legal advice. Consult qualified counsel regarding your specific obligations.