HIPAA Security Risk Assessment: Step-by-Step Guide

If the HHS Office for Civil Rights (OCR) ever contacts your practice — because a patient complained, a laptop was stolen, or ransomware hit — one of the first documents they'll ask for is your security risk analysis. Not your privacy notice, not your antivirus invoice. The risk analysis. It's the foundation every other HIPAA security decision rests on, and it's the requirement small practices most often get wrong or skip.

The good news: a risk assessment for a 5–50 person dental or medical office is not a six-month consulting project. It's a structured way of answering four questions about your patient data: Where is it? What could go wrong? How likely and how bad would that be? What are we going to do about it? Done properly, it takes a few days of focused work the first time and much less each year after.

This guide walks you through the process step by step, the way OCR and HHS describe it: scoping, inventory, threats and vulnerabilities, current safeguards, likelihood, impact, risk ratings, documentation and the risk management plan. It covers the free HHS Security Risk Assessment (SRA) Tool, includes a sample risk register you can copy, and finishes with worked examples for a small dental office and a small medical office.

What is a HIPAA security risk assessment?

A HIPAA security risk assessment is a documented evaluation of the potential risks and vulnerabilities to the confidentiality, integrity and availability of all the electronic protected health information your practice holds. The Security Rule calls it a "risk analysis"; HHS and most vendors call it a "security risk assessment" or SRA. They're the same thing.

The legal requirement is in 45 CFR 164.308(a)(1)(ii)(A), which tells covered entities and business associates to:

"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."

A few terms used throughout this guide:

• ePHI (electronic protected health information) — any individually identifiable health information in electronic form: charts, X-rays, appointment books, insurance details, billing records, scanned forms, voicemails and emails about patients.
• Threat — something that could cause harm: a ransomware gang, a phishing email, a burst pipe, a hurricane, a careless employee, a dishonest one.
• Vulnerability — a weakness a threat could exploit: no MFA, an unpatched server, an unlocked closet, no backups off-site.
• Likelihood — how probable it is that a particular threat exploits a particular vulnerability.
• Impact — how bad the outcome would be for patients and the practice if it did.
• Risk — the combination of likelihood and impact. High likelihood plus high impact means high risk.

Notice the three words in the regulation: confidentiality (only the right people see it), integrity (it isn't improperly altered or destroyed) and availability (it's there when you need it). A good risk assessment covers all three. Many practices only think about confidentiality — "could someone steal our data?" — and miss availability, which is exactly what ransomware and long internet outages attack.

Why does OCR care so much about the risk analysis?

Because every other safeguard decision in the Security Rule is supposed to flow from it — and because its absence shows up in case after case. If you don't know your risks, you can't defend why you did (or didn't) implement any given safeguard.

The Security Rule is deliberately flexible. Under 45 CFR 164.306(b), a practice chooses its security measures based on its size, complexity, technical capabilities, the cost of the measures, and the probability and criticality of risks. And for every "addressable" specification — encryption, automatic logoff, security reminders and more — 164.306(d)(3) requires you to assess whether it's reasonable and appropriate in your environment. The risk analysis is where that assessment happens. Without it, your choices are guesses.

OCR has made this a priority in enforcement. In October 2024 it announced its first enforcement action under a new Risk Analysis Initiative, created to focus investigations on compliance with the risk analysis requirement. By June 2026, a settlement with a health plan marked the initiative's 14th enforcement action, according to a July 2026 analysis by the law firm Nixon Peabody. The pattern across these cases is consistent: an incident (often ransomware or hacking) triggers an investigation, OCR finds no accurate and thorough risk analysis, and the outcome is a payment plus a multi-year corrective action plan that requires — you guessed it — a risk analysis and a risk management plan, monitored by HHS. You can read the resolution agreements on HHS's enforcement page.

There's a business reason too. IBM's 2026 Cost of a Data Breach report found healthcare was again the most expensive industry for data breaches, at an average of $6.64 million per breach. Most small practices will never face numbers like that, but even a "small" incident means forensic costs, legal fees, notification letters, downtime and lost patient trust. The risk analysis is how you decide where a limited budget does the most good.

What does OCR expect a risk analysis to include?

HHS guidance lists the elements every risk analysis should cover: scope, data collection, threats and vulnerabilities, current security measures, likelihood, impact, level of risk, documentation and periodic review. It does not require a particular method or tool.

HHS's Guidance on Risk Analysis Requirements under the HIPAA Security Rule is short and worth reading in full. In summary, it expects:

The guidance also stresses that the risk analysis is not a one-time event. It describes an ongoing process of reviewing records, tracking access to ePHI, detecting incidents, evaluating whether safeguards work, and reevaluating risks.

What a risk analysis is not

These are the most common things practices hand OCR that don't meet the requirement on their own:

• A gap checklist. A list of HIPAA standards with "yes/no" next to each is useful (our HIPAA Security Rule checklist is one), but it doesn't rate likelihood and impact or cover every system.
• A vulnerability scan or penetration test. Great input, but technical only.
• A vendor's compliance certificate. There is no HHS-approved HIPAA certification. Microsoft says so plainly in its own HIPAA documentation.
• Last year's report with the date changed.
• A risk analysis that only covers the EHR. OCR expects all ePHI: email, scanned documents, imaging, backups, phones, fax, spreadsheets on the billing manager's desktop.

Before you start: who, what and which tools

You need three things before step one: a small team, a clear scope, and a method for recording results. Getting these right saves hours later.

Who should be involved

1. The security official — usually the practice manager or office manager. They own the result and make the risk decisions.
2. Your IT provider or technical person — they know (or can find out) what devices, settings, backups and network equipment you have.
3. A clinician or the owner — they know which systems patient care can't do without and what downtime really costs.
4. Someone from the front desk and billing — they know the workarounds: the shared password on a sticky note, the spreadsheet of unpaid claims, the personal phone used to text the doctor.

Two to four people for a small office is plenty. The front-desk perspective is the one most often skipped and the one that most often reveals real risks.

Choosing a method

• The HHS SRA Tool — free, designed for small and medium practices, guided questions. Good default for most 5–25 person offices.
• A spreadsheet based on NIST SP 800-66 Revision 2 — NIST's February 2024 resource guide for implementing the Security Rule includes a risk assessment approach and maps each standard to practical activities. Good if you want flexibility or have more complexity.
• An outside assessor — useful for larger or more complex practices, or if you want an independent view. You still own and approve the result.

Whatever you use, the content is the same. Pick one and finish it.

How to do a HIPAA security risk assessment, step by step

The process has nine steps: define scope, inventory ePHI, map data flows, identify threats, identify vulnerabilities, assess current safeguards, rate likelihood and impact, assign risk levels, and document a risk management plan. It mirrors both the HHS guidance and the approach in NIST SP 800-66r2.

Step 1: Define the scope

Write one paragraph stating what the assessment covers: all locations, all workforce members, all systems and vendors that create, receive, maintain or transmit ePHI, and the date range. If you have a satellite office or providers who work from home, name them. If something is out of scope, say why.

Example scope statement: "This risk analysis covers all ePHI created, received, maintained or transmitted by Seaside Family Dental at its single office location, including on-site systems, cloud services, mobile devices, remote access by the owner from home, and services provided by business associates. It reflects conditions as of September 2026."

(Seaside Family Dental is a made-up example name.)

Step 2: Build an inventory of where ePHI lives

List every place ePHI is stored, processed or sent. Go room by room and system by system. Typical categories for a small practice:

1. Core clinical systems — EHR or practice management software (cloud or on-site server), imaging software and its database, lab interfaces.
2. Workstations — front desk, operatories or exam rooms, offices, billing.
3. Mobile devices — laptops, tablets, phones (practice-owned and personal phones that get work email or texts).
4. Servers and storage — on-site server, network storage, external drives, USB sticks.
5. Email and file sharing — Microsoft 365 mailboxes, OneDrive, SharePoint, Teams.
6. Communications — VoIP phones and voicemail, e-fax, patient texting or reminder services, answering service.
7. Backups — local backup appliances, cloud backup, Microsoft 365 backup.
8. Medical and dental devices — digital X-ray sensors and their PCs, intraoral cameras, CBCT units, ECG machines, lab analyzers that store patient data.
9. Office equipment — multifunction copiers and scanners with internal drives.
10. Business associates — every vendor that holds or accesses ePHI. (See our business associate agreement guide.)

For each item record: name, type, location, owner/user, what ePHI it holds, whether it's encrypted, and who supports it. If you work with a managed IT provider, ask for their RMM (remote monitoring and management) device report as a starting point — then walk the office to find what it missed.

Step 3: Map how ePHI flows

Sketch how patient data moves: patient fills in a tablet form → EHR → claim sent to clearinghouse → payment posted → statement mailed by print vendor. Referral letters emailed to specialists. X-rays exported to a USB stick for an oral surgeon. Lab results faxed in.

You're looking for flows that leave your controlled systems: personal email, unencrypted USB drives, consumer file-sharing apps, text messages. Those are frequently where the real risk sits.

Step 4: Identify reasonably anticipated threats

List the threats that realistically apply to your practice. You don't need to consider meteor strikes; you do need to consider hurricanes if you're in Florida. A solid starting list:

Human — deliberate: ransomware, phishing and business email compromise, credential theft, theft of devices, employee snooping in records, a disgruntled ex-employee.

Human — accidental: misdirected email or fax, lost phone or laptop, accidental deletion, misconfiguration, clicking a malicious link.

Environmental: hurricane, flood, fire, power outage, extended internet outage, HVAC failure in the server closet.

Technical: hardware failure, software bugs, vendor outage, an unsupported operating system that no longer gets security fixes.

Third party: a breach or outage at your EHR vendor, billing company, IT provider or other business associate.

Step 5: Identify vulnerabilities

For each system in your inventory, list weaknesses a threat could exploit. Pair them up: "Ransomware + no immutable backups," "Device theft + unencrypted laptop," "Phishing + no MFA on email." Typical vulnerabilities in small practices:

• No multi-factor authentication on email, EHR or remote access
• Shared logins
• Unencrypted laptops, desktops or USB drives
• Missing security updates; old Windows versions
• Backups that are on-site only, not immutable, or untested
• Remote Desktop exposed to the internet
• Flat network where guest Wi-Fi, phones, imaging and workstations all share one network
• Departed staff with active accounts
• No security awareness training
• Missing BAAs
• No documented downtime procedures
• Single internet connection with no failover

A vulnerability scan of your network and a Microsoft 365 configuration review (Microsoft Secure Score is a useful starting point) will surface technical vulnerabilities you can't see by walking around.

Step 6: Assess your current security measures

For each threat–vulnerability pair, write down what you already have in place and whether it actually works. Be honest. "We have antivirus" isn't enough; "Microsoft Defender for Business is installed on all 14 PCs and reporting healthy as of 9/15" is.

Check three things for each control:

1. Is it in place?
2. Is it configured correctly? (MFA on, but with an exception for the owner's account, is a common gap.)
3. Is it being used and monitored? (Audit logs that nobody reads don't reduce much risk.)

Step 7: Rate likelihood and impact

Use a simple three-level scale. Since version 3.6, the HHS SRA Tool uses Low / Moderate / High to align with NIST scoring, so that's a sensible choice.

Likelihood:

• Low — unlikely; strong controls in place or the threat rarely targets practices like yours.
• Moderate — could happen; some controls but gaps exist.
• High — likely or already happening (for example, phishing emails arrive weekly and there's no MFA).

Impact:

• Low — minor inconvenience; small amount of ePHI; no patient harm; quick recovery.
• Moderate — disruption for a day or more, ePHI of some patients exposed, notification likely.
• High — practice can't operate for days, large volume of ePHI exposed or lost, patient safety affected, major financial or legal consequences.

Write one sentence explaining each rating. The reasoning is what makes the analysis defensible.

Step 8: Determine the level of risk

Combine likelihood and impact using a matrix:

Then sort your risks from highest to lowest. High risks get addressed first. You don't have to eliminate every risk — the rule asks you to reduce risks to a "reasonable and appropriate" level — but you do have to decide, on purpose, what to do about each one.

Step 9: Document results and build the risk management plan

For each risk, choose a response:

• Mitigate — add or improve a safeguard (most common).
• Transfer — shift some of the financial impact, for example through cyber insurance. Note that insurance doesn't transfer your HIPAA obligations.
• Accept — for low risks where the cost of mitigation outweighs the benefit. Document who accepted it and why.
• Avoid — stop the activity, for example stop exporting X-rays to unencrypted USB drives.

The risk management plan is a separate required specification (164.308(a)(1)(ii)(B)). It lists the action, owner, target date, budget if any, and status. This is the part that turns a document into actual protection — and the part OCR most often finds missing.

Sample risk register for a small practice

A risk register is a table that tracks each risk from identification to resolution. Below is a realistic example for a small practice. Copy the structure; replace the content with your own findings.

Keep the register in a place you'll actually update — a SharePoint list or a shared spreadsheet works. Review it monthly in the first few months, then quarterly. When an action is complete, record the date and keep the evidence (a screenshot, a report, an invoice).

How do you use the HHS SRA Tool?

The HHS Security Risk Assessment Tool is a free Windows application from the HHS Office for Civil Rights and the Assistant Secretary for Technology Policy (ASTP/ONC) that walks small and medium practices through a risk assessment with guided questions. It's a reasonable choice for most practices under about 25 people.

Key facts about the SRA Tool (as of October 2026)

• Current version: HHS released version 3.6 in September 2025. A 3.6.1 installer followed in May 2026 that, according to HealthIT.gov, updated only the software certificate, with no changes to the tool itself.
• Platform: a desktop application for 64-bit Windows. There's no Mac or web version.
• Privacy: information you enter is stored locally on your computer; HHS states it doesn't collect, view, store or transmit it. That also means you are responsible for backing up the file and keeping it secure.
• What's new in 3.6: a confirmation step with a "reviewed-by" date for each section, recording who approved it and when (useful audit evidence), and a risk scale updated to match NIST, with "medium" renamed "moderate."
• Cost: free. Download it from HealthIT.gov.

How to work through it

1. Install it on a secure practice computer — encrypted, with MFA on the user account — since the file will describe your vulnerabilities.
2. Enter practice information and assemble your team.
3. Enter your assets (devices, systems, media) and vendors (business associates). Use the inventory from Step 2.
4. Answer the multiple-choice questions section by section. Each question explains what it's asking and why. Answer what is true today, not what you intend to do.
5. Use the education panels. Where you're unsure, the tool's guidance text explains the safeguard.
6. Review threats and vulnerabilities the tool identifies from your answers and adjust likelihood and impact if they don't fit your situation.
7. Confirm each section with the reviewed-by step.
8. Generate the reports — the summary and detailed reports become part of your documentation.
9. Build your risk management plan from the findings. The tool identifies risks; acting on them is up to you.
10. Save and back up the file. Next year, open it, update it, and save a new version — don't overwrite the old one. You need to keep prior versions for six years.

SRA Tool limitations to know about

• It only knows what you tell it. It doesn't inspect your network, Microsoft 365 or devices. Pair it with a technical review by your IT provider.
• It's question-driven. If an important system isn't in your asset list, it won't be assessed.
• It doesn't produce your risk management plan automatically. You still need owners and dates.
• It's not proof of compliance on its own. HHS describes it as an aid; the content and follow-through are what count.

Other frameworks you can use

You can use any reasonable method; the most useful free references for small practices are NIST SP 800-66 Revision 2 and the HHS 405(d) Health Industry Cybersecurity Practices.

• NIST SP 800-66 Rev. 2 (February 2024) — "Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide." It explains the risk assessment process, lists key activities and sample questions for each Security Rule standard, and maps them to the NIST Cybersecurity Framework and NIST SP 800-53 controls. It's long, but the sections for each standard are practical checklists.
• HHS 405(d) HICP — "Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients," produced by an HHS–industry task group. It's written for organizations of different sizes and includes a technical volume for small organizations. Following it can also count as a "recognized security practice," which, under a 2021 amendment to the HITECH Act (Public Law 116-321), HHS must consider when it decides penalties and audit outcomes if you can show the practices were in place for the previous 12 months.

Using a recognized framework as the backbone of your risk analysis and risk management plan is a practical way to make your program both effective and defensible.

What documentation do you need to keep?

Keep the risk analysis, the risk management plan, the evidence that actions were completed, and prior versions — for at least six years. Under 45 CFR 164.316(b)(2), documentation must be retained six years from the date it was created or last in effect, whichever is later.

Your risk assessment file should include:

1. Scope statement and date of assessment
2. Team — who participated and their roles
3. Asset and vendor inventory
4. Data-flow description or diagram
5. Threats and vulnerabilities identified
6. Current safeguards and their status
7. Likelihood, impact and risk ratings with brief reasoning
8. Risk register / risk management plan with owners, dates, status
9. Evidence of completed actions — screenshots of MFA policies, Intune encryption reports, backup test results, signed BAAs, training logs
10. Sign-off by the security official (and owner, ideally), with date
11. Prior versions of the assessment

Store it in a secure, backed-up location — a restricted SharePoint site with a retention policy works well — and limit access, because the document is a roadmap of your weaknesses.

How often should you do a HIPAA risk assessment?

At least once a year in practice, plus whenever something significant changes. The current rule doesn't name an interval; it requires an ongoing process and updates in response to environmental or operational changes.

Trigger events that should prompt an update:

• New EHR, practice management or imaging system
• Moving to the cloud, or moving offices
• Adding a location or remote/telehealth workers
• A security incident or breach
• A new business associate that handles significant ePHI
• Major staff turnover or a merger/acquisition
• New regulatory requirements

The proposed Security Rule update published January 6, 2025 would require a risk analysis review at least every 12 months, along with a written technology asset inventory and network map. As of October 2026 that proposal hasn't been finalized, but an annual cycle is already the norm and a good habit.

A practical calendar:

Common risk assessment failures

Most failed risk analyses fail for the same few reasons: incomplete scope, no follow-through, and outdated content. Here's what we see and how to avoid it.

1. Only the EHR is assessed. Email, scanned documents, imaging PCs, phones, fax and backups get left out. Fix: start from a complete inventory.
2. No risk management plan. Findings without owners and dates. Fix: every moderate or high risk gets an action, owner and due date.
3. Copy-paste templates. The document mentions a server you don't have and misses the cloud EHR you do. Fix: describe your environment.
4. "Assessment" equals a vendor certificate. No HHS-endorsed HIPAA certification exists. Fix: write your own analysis.
5. Never updated. The analysis is from 2019; the practice moved to a cloud EHR in 2023. Fix: annual review plus change triggers.
6. Availability ignored. Focus on hackers stealing data, nothing about outages, hurricanes or ransomware locking files. Fix: assess downtime and recovery explicitly — see our EHR downtime and internet failover plan.
7. Business associates ignored. Fix: list every vendor and assess the risk they represent.
8. Ratings without reasons. "High" with no explanation. Fix: one sentence each.
9. No evidence of completed actions. The plan says MFA was enabled; there's no screenshot or report. Fix: save evidence as you go.
10. The analysis lives only in the IT provider's system. If you switch providers, you lose it. Fix: the practice keeps its own copy.

Scenario: risk assessment for a six-person dental office

For a small dental office, a full first-time risk assessment is typically two to three working days spread over a few weeks, with most effort spent on the inventory and the follow-up actions.

The office: one dentist, one hygienist, two assistants, one front-desk person, one office manager. Practice management and imaging on an on-site server. Three operatories, each with a PC connected to an intraoral sensor. A CBCT unit with its own workstation. Microsoft 365 email. A patient reminder text service. VoIP phones.

Day 1 — inventory and data flows (office manager + IT provider, ~4 hours). Walk the office. The inventory turns up 11 devices, not the eight everyone assumed: the CBCT workstation, an old reception PC kept "just in case," and the copier with an internal hard drive. Data flows reveal that X-rays are emailed to an oral surgeon as unencrypted attachments, and the dentist checks the schedule on a personal phone through a consumer app.

Day 2 — SRA Tool session (office manager + dentist + IT, ~4 hours). Answer the questions honestly. Key vulnerabilities: no MFA on email, the "just in case" PC still has an active login and old patient files, the CBCT workstation runs an older Windows version required by the vendor, backups go to one USB drive, no BAA with the text reminder service.

Day 3 — ratings and plan (office manager + IT, ~3 hours). Rate each risk with the matrix. High risks: email takeover, ransomware with no recoverable backup, unencrypted laptop. The plan: MFA within two weeks; new backup with immutable cloud copy and a test restore within 30 days; wipe and dispose of the spare PC with a disposal log entry; isolate the CBCT workstation on its own network segment with no internet browsing; get a BAA from the reminder vendor or switch; use encrypted email for referrals.

After: the office manager reviews the register monthly. Six months later, all high risks are closed with evidence in the folder. The annual update next September takes about half a day. Imaging-specific risks like the CBCT workstation are common — see our dental imaging network and computer guide and the dental office IT guide.

Scenario: risk assessment for a 30-person medical practice

A larger medical practice needs the same nine steps, but scope, vendors and remote access make the inventory bigger and the risk register longer — plan for a few weeks of elapsed time.

The practice: four physicians, two physician assistants, nursing staff, a lab, billing, and front desk across two locations. Cloud EHR, an on-site lab interface server, a patient portal, telehealth, an answering service, outsourced transcription, and providers who chart from home.

What's different:

• Two locations mean two physical assessments and a site-to-site connection to assess.
• More business associates — the vendor list may run to a dozen or more. Each needs a BAA and an assessment of the risk it represents. Ask your bigger vendors for their security documentation (a SOC 2 report or HITRUST certification, if they have one).
• Remote access is a major risk area. Assess whether providers use practice-managed devices, whether MFA is enforced, and whether the EHR can restrict sign-ins to compliant devices.
• Insider risk grows with headcount. Include "inappropriate chart access by workforce" and check whether EHR access reports are reviewed.
• Telehealth platforms need a BAA and should be in the inventory.

How to run it: a kickoff meeting with the administrator, a lead physician, the billing manager and IT; a two-week data-gathering period (inventory, vendor list, configuration reviews, a vulnerability scan); a working session to rate risks; and a final review where leadership accepts or funds each action. Many practices this size use the SRA Tool for structure plus a spreadsheet risk register, or hire an outside assessor for the first round and maintain it internally after. Our medical office IT guide covers the systems you'll be assessing.

Should you do it yourself or hire someone?

A small practice can do its own risk assessment with the SRA Tool and help from its IT provider; bigger or more complex practices often benefit from an outside assessor for the first round. Either way, the practice must own the result.

Do it yourself if: you have fewer than about 20 staff, a simple environment, a cooperative IT provider, and a security official who can set aside a few days.

Get help if: you have multiple locations, on-site servers plus cloud systems, many vendors, providers working remotely, a recent incident, or you've never done one and don't know where to start.

Questions to ask a risk assessment provider

1. Will the result be a written analysis of our risks, with likelihood and impact ratings — not just a checklist or certificate?
2. Does the scope cover all ePHI, including email, imaging, phones, fax, backups and vendors?
3. Do you include a technical review (Microsoft 365 configuration, vulnerability scan) or only interviews?
4. Will you deliver a risk management plan with prioritized actions?
5. Who keeps the documents, and in what format?
6. Will you sign a business associate agreement?
7. How do you handle updates next year?

How the risk assessment connects to everything else

The risk analysis is the hub; nearly every other HIPAA security activity either feeds it or flows from it.

• It decides which addressable safeguards you implement — see the HIPAA Security Rule checklist and our interactive HIPAA Security Self-Assessment.
• It identifies which vendors are highest risk and need closest attention.
• It shapes your contingency plan — what to restore first, how long you can be down. Our backup and disaster recovery guide and downtime cost calculator help put numbers on that.
• It informs your incident response — the risks you rated high are the incidents you should rehearse. See our HIPAA breach response plan.
• It supports your cyber insurance application — insurers ask many of the same questions. See the cyber insurance requirements checklist.
• It's what you'll hand OCR first if anything goes wrong.

The bottom line

A HIPAA security risk assessment is required, it's the first thing OCR asks for, and it's the single best way to decide where your security budget should go. For a small practice it's very doable: define the scope, inventory every place patient data lives, list realistic threats and vulnerabilities, check what's really in place, rate likelihood and impact, rank the risks, and — most importantly — build and follow a risk management plan with owners and dates. Write it down, keep it six years, and update it at least yearly.

The free HHS SRA Tool is a perfectly good way to start. Where most practices need help is the technical half: knowing what's actually configured in Microsoft 365, on each device and on the network, and fixing the high-risk findings quickly.

We help medical and dental practices in Ormond Beach, Daytona Beach, Palm Coast and remotely across the US with risk assessments and the fixes that follow, as part of our managed IT services. If you'd like a hand, book a free 20-minute call — we'll tell you honestly whether you can do it yourself.