164.310(b) Workstation use: requirements and evidence

What 164.310(b) workstation use requires for ePHI

If you are the compliance lead or engineer who has to show that workstation policies exist and are followed, the short answer is this: 45 CFR 164.310(b) requires written policies that define what each workstation or class of workstation accessing ePHI is used for, how it is used, and what the physical surroundings of that workstation must be like. The standard does not ask for a particular product or setting, but it does expect you to have written rules for every type of device that can reach ePHI, and to be able to show that those rules fit the way people actually work. Under 45 CFR 164.304, a workstation is a laptop, desktop or other device that performs similar functions, together with electronic media stored in its immediate environment, such as the USB drives, external disks or printers that sit beside it. The standard has no separate implementation specifications, and Appendix A to Subpart C marks it as required (R), so there is no addressable option to document away.

The hard part is scope. Workstation policy has to cover home offices, personal laptops used for email, shared clinic terminals, and contractor devices, not only the desktops in your headquarters. Each of these has different functions, different physical surroundings and different levels of control. A useful first step is to inventory workstation types and classes, then write down for each class what work is done on it, which systems it reaches, and where it is physically used. NIST SP 800-66 Rev. 2 (section 5.2.2) describes the same sequence: identify device types and their uses, identify expected performance, and analyze the physical surroundings. Confirm with your own asset records whether a laptop left in a car or a shared terminal in a patient area is covered by a class you have already defined.

Written policy is only half of the evidence. An assessor will look for records showing that the device classes in your policy match the devices actually in service, and that remote and mobile use follows the stated rules. Asset inventory tools can supply that record. GLPI's Assets module can hold computers and other equipment entered by hand or pushed by its agent, and Zabbix host inventory can store device type, location and responsible person. Endpoint policy tools such as Fleet (osquery-based yes or no policies) and Wazuh Security Configuration Assessment can show whether a device meets a configuration rule. Confirm with each vendor that the check you need, such as screen lock or disk encryption, is available in the version you run, because the Security Rule does not name the setting. HHS publishes remote use and mobile device guidance in its Security Rule guidance materials, which is a sound next read before you finalize class definitions.

Which workstations and settings fall under 164.310(b)

Under 164.310(b), the policy and inventory only work if you know which devices count as workstations and where they are used. The cards below cover the scoping decisions that most often change the scope, from device classes to remote setups and third parties with access.

Device classes that count as workstations

The rule defines a workstation by function, not by form factor: a laptop, desktop or other device performing similar functions, plus electronic media in its immediate environment. Clinic desktops, laptops, thin clients, kiosks and clinician tablets all fall in scope if they access ePHI. Group them into classes, such as exam room terminals or mobile clinician devices, and record the functions and expected performance of each class. Ask whether any shared kiosk or thin client is excluded from your inventory by mistake.

Clinician tablets and handheld devices

A tablet or phone used to view, enter or send ePHI performs functions similar to a desktop, so it belongs in the workstation analysis even if your team calls it a mobile device. Decide which apps and data paths are permitted, whether the device is organization-owned, and what physical surroundings it may be used in, such as a public hallway or a shared vehicle. Record these decisions in the same class definitions used for desktops.

Remote and home workstations

Staff working from home change the physical surroundings the policy must address. The policy should state who may work remotely, which devices may be used, whether screens may be viewed by household members, and how printing and paper records are handled. HHS lists remote use guidance among its Security Rule materials, so start there when drafting these rules. Confirm that remote setups appear in your inventory and not only in HR records.

Personal devices used for ePHI

Personal laptops, phones and home computers that touch ePHI are workstations for purposes of this standard, even when the organization does not own them. The organization must still define acceptable functions, use and surroundings for them, or prohibit them. Decide whether personal devices are allowed at all, and if so, which ones, and how you will verify their configuration. Confirm that any personal device used for email or EHR access is covered by the same written rules.

Third parties that administer or touch workstations

Managed IT providers, remote support vendors, billing staff at outside companies and imaging technicians may log in to or repair workstations that access ePHI. Their use of those devices falls under your workstation policy. Define in the contract and the policy which functions they may perform, from where, and under what physical conditions. Ask each vendor how their own staff's devices are scoped before granting remote access.

Workstation inventory that feeds the policy

The policy describes classes of workstations, so the inventory must map each device to a class, a location and an owner. Open-source asset tools can hold this data. GLPI's Assets module records computers, monitors, peripherals and racks, and can receive data pushed by its agent. Zabbix host inventory stores device type, serial number, location and responsible person. Confirm which tool will be the system of record before you write the class definitions.

How an assessor tests workstation use policies

This table walks through how an assessor or OCR reviewer typically tests the 164.310(b) workstation use standard, from the written policy to physical surroundings. Read each row as a test step, the evidence to have ready, and the gaps reviewers commonly raise. Only the auditor or the OCR reviewer concludes whether the standard is met.

Test step	Evidence requested	Common findings
Review the written workstation policy for the three elements in the rule: proper functions, how each function is performed, and physical attributes of the surroundings	Workstation use policy and procedures, with version history and approval date	Policy covers functions but not how they are performed, or omits physical surroundings entirely
Confirm the policy names each workstation or class of workstation that can access ePHI	Inventory extract grouped by workstation class (for example, clinic desktops, clinician laptops, kiosks)	Policy names no workstation classes, or the classes do not match what the inventory shows
Sample workstations from each class and compare configuration and use against the policy	Sample selection record, configuration baseline reports and screenshots or scan output for sampled devices	Sampled devices run settings or software the policy does not describe, or no baseline exists for a class
Interview staff on remote and home use of workstations that access ePHI	Remote access rules, acceptable use acknowledgments and records of staff training on them	No remote use rules exist, or staff describe home practices the written policy does not allow or address
Inspect the physical surroundings of sampled workstations, including screen position, privacy and public visibility	Physical walkthrough notes, photographs where permitted, and documented workstation layout decisions	Physical attributes are asserted in policy but never verified on site, or unverified settings are left undocumented
Check that policy statements on workstation placement and use match the facility security plan and device controls	Cross-references between the workstation policy, facility security plan and device and media procedures	Policies written in isolation, with contradictory rules on who may use a workstation and where
Review how changes to workstation classes or locations are approved and recorded	Change records, updated inventory entries and policy revision history	Relocated or newly added workstations appear in no record, so the policy no longer reflects the environment

Implementing workstation use policies step by step

This sequence turns the 164.310(b) requirement into a working set of workstation classes, each with defined functions, approved uses and physical conditions, and a policy the workforce has acknowledged and that is reviewed on a schedule. Each step produces a record an assessor can inspect.

Inventory workstations and device types
Start by listing every workstation that can reach ePHI, including desktops, laptops, tablets, and personal or contractor devices used for remote work. Use the definition in 45 CFR 164.304, which covers laptops, desktops and similar devices plus electronic media kept in their immediate environment, so removable drives and printers that hold ePHI are not overlooked. Asset data from your device management tools or a configuration management database can seed the list, but someone must confirm it against how people actually work. The output is an inventory list with owner, device type, operating system and location category for each entry, signed off by the security official or delegate.
Define functions and performance for each type
For each device type, document the functions it performs, such as clinical charting, billing, imaging review or administrative email, and the expected performance and access it needs to do that work. NIST SP 800-66 Rev. 2, section 5.2.2, lists identifying device types, their functions or uses and their expected performance as key activities for this standard. Involve clinical and operational managers, because they know which tasks happen at which device. The output is a class matrix that maps each workstation class to its permitted functions, required applications, ePHI access scope and performance expectations.
Analyze physical surroundings for each class
Walk through the locations where each class is used and record the physical attributes that affect ePHI exposure. Typical items include screen placement relative to public areas, whether the room is shared with other staff, patients or visitors, privacy barriers, lockable storage, cable and docking arrangements, and the setup of home offices or other remote sites. The NIST guidance treats analyzing physical surroundings for physical attributes as a key activity. The output is a surroundings checklist per location type, with gaps noted and assigned to an owner for remediation.
Write the policy for each workstation class
Draft the workstation use policy so that each class has its own section stating the proper functions, the manner of use, and the physical attributes required of its surroundings. Cover remote and mobile use explicitly, since HHS publishes remote use and mobile device guidance in its Security Rule materials. Keep the language specific enough that a workforce member could apply it to their own desk or laptop. Legal, privacy and clinical leadership should review the draft. The output is a draft policy with one section per class, cross-referenced to the matrix and checklist from earlier steps.
Approve and communicate the policy
Route the final policy through the people who own the risk, typically the security official and the executive responsible for the affected services, and record their approval with a date and version number. Then distribute it to every affected group, including contractors and remote staff, and collect a signed acknowledgment or an electronic attestation from each person. Where workforce members use personal devices, make sure the policy says which of those devices are covered. The outputs are the approved policy version, distribution records, and a training or acknowledgment log that shows who received it and when.
Verify conformance on the devices
Check whether the devices in each class meet the surroundings and configuration expectations in the policy. Configuration assessment tools can show drift from a baseline, and endpoint query tools can report yes or no answers on whether devices meet a stated condition, such as screen lock enabled or disk encryption on. Wazuh Security Configuration Assessment and Fleet policies both support checks of this kind, although the exact checks depend on the policy and your environment, so confirm coverage before you rely on a tool. Physical attributes still need manual walk-throughs. The output is a conformance report by class, with exceptions logged and assigned for correction.
Review the policy on a set cadence
Set a review schedule in the policy itself and keep a log of each review. Reviews should also be triggered by changes such as new device types, new clinical sites, remote work arrangements or incidents involving a workstation. During review, refresh the inventory, reconfirm the class matrix, repeat the surroundings checks for new locations and retrain staff where the policy changed. Ask your organization or auditor what review interval they expect, because the rule itself does not set one. The output is a dated review log showing what changed, who approved it and which records were updated.

Which open-source tools produce workstation evidence

Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints against YAML policies and reports which checks pass or fail. Its shipped policies are mostly based on CIS benchmarks, and you can add custom policies. For 164.310(b), this is useful evidence that the configuration of a workstation class matches the rules your policy sets, such as screen lock settings, disk encryption or unneeded services, where those settings can be checked on the host. The checks read files, directories, registry keys and running processes, so they can confirm technical settings but cannot confirm where a laptop is used or who is sitting near the screen.

Per-endpoint results: Each monitored endpoint gets a scored list of checks with remediation advice, which you can export as proof for a workstation class.
Custom policies: Write YAML policies that reflect your own workstation standard, then map them to the functions and uses you documented.
Benchmark coverage: Shipped policies are mostly CIS-based, so confirm which benchmark version each policy follows before citing it.
Licence obligation: Wazuh is GPL-2.0-only, so distributing modified Wazuh code triggers GPL-2.0 source obligations; internal use alone does not.
Limit: A passing check shows a setting, not the physical attributes of the workstation surroundings.

Confirm the policy file names, check coverage and export options against the current Wazuh release before relying on them.

Evidence that shows workstation use is governed

An assessor testing 164.310(b) looks for a written policy, a current picture of the devices it covers, and proof that the rules are applied to each class of workstation. The cards below cover the artifacts that connect those three things, and how to keep each one current between audits. The organization produces this evidence itself; DeployOpen prepares the systems and records, and only an independent assessor forms a view on them.

Approved workstation policy by class

The written policy must define each class of workstation that can reach ePHI, such as clinic desktops, clinician laptops, kiosks and personal devices used under a bring-your-own-device arrangement. For each class, it states the proper functions, how the device is used, and the physical conditions around it, including screen position and privacy. Check that the policy names an owner, carries a version and approval date, and that every class in the inventory maps to a section of it. An assessor will ask which policy version was in force on a given date.

Workstation and device inventory

The inventory lists each device that accesses ePHI, its type, its assigned user or location, and the class it belongs to. GLPI's Assets module can hold computers, monitors, network equipment, printers and phones, and its native inventory can be populated automatically by the GLPI Agent. Zabbix host inventory records device type, serial number, location and responsible person. Confirm the inventory covers remote and home devices, not only devices on site, and that unknown devices are flagged.

Class-by-class configuration baseline results

A configuration baseline states the settings each workstation class must meet, such as screen lock, disk encryption and local administrator rights. Wazuh Security Configuration Assessment scans endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom checks for files, registry keys and processes. Fleet policies ask yes or no questions of devices and show which devices pass or fail each one. Keep dated results per class, and record the reason for any failure that is accepted for a period.

Remote and home use acknowledgments

Staff who work from home or travel with laptops should sign an acknowledgment of the remote use rules that apply to their device class. The acknowledgment should cover where screens may be viewed, whether printing at home is allowed, and how devices are returned. Store signed copies with the user's name, the date, and the policy version acknowledged. Check that the signing process runs again when the policy changes and when a person changes role.

Physical surroundings checklists

The physical attributes of each workstation location are the part of 164.310(b) that a configuration scan cannot see. Use a checklist per location covering screen orientation toward public areas, privacy filters, locking of unattended rooms, cable and device security, and whether ePHI can be printed or left on whiteboards. Date each checklist, record who completed it, and repeat it on a schedule set by the organization. Photographs or floor plans can support the record where they are permitted.

Exception records and review logs

Any device or class that does not meet the policy needs a written exception with the reason, the compensating measure, an approver and an expiry date. Review logs show that someone reexamined the policy, the inventory and the exceptions on a set schedule and recorded changes. Confirm that closed exceptions remain on file and that the review log links to the change records that resulted. An assessor who finds an open exception with no owner or end date will treat the process as unmanaged.

What meeting 164.310(b) costs in money and effort

This table breaks the cost of meeting the workstation use standard into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for scoping a quote: no prices or durations are given because none are supplied, so ask for each line to be priced in your written scope. The main takeaway is that open-source tooling removes license spend but not the staff time to configure, maintain and evidence the policy.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Policy drafting and legal review	Internal compliance lead, outside counsel or consultant	One-time, then recurring at each annual review	Up with the number of workstation classes; down with a short, reusable template
Inventory of workstation types and uses	IT asset owner, security engineer, optional consultant	One-time, then recurring as devices change	Up with remote share of staff and device churn; down with standard images and fewer classes
Tooling and hosting for inventory and checks	Platform team; no license fee for the GPL, MIT or AGPL tools named	Recurring operating effort, plus one-time setup	Up with the number of endpoints and agents; open-source removes license spend, not operating effort
Engineering time for configuration checks	Platform or endpoint engineers building YAML or osquery policies	One-time build, recurring maintenance as OS and policy baselines change	Up with custom policies per workstation class; down with a small set of standard baselines
Staff time for surroundings reviews	Facilities, security staff and workstation owners walking through sites or remote setups	Recurring, usually at onboarding and on a set cycle	Up with multiple offices, shared spaces and home offices; down when remote rules are standardized
Training on workstation rules	Security or HR staff, plus employee time	Recurring, often annual and at onboarding	Up with workforce size and turnover; down with one shared module across workforce roles
External review or testing	Independent assessor or consultant, if engaged	Often one-time per assessment cycle, plus follow-up	Up with scope breadth and remote sites; down with a clearly written scope agreed in advance
Auditor or assessor time	Independent assessor, selected by your organization	Recurring at each assessment cycle	Up with missing or inconsistent evidence; down with a ready evidence pack. Confirm fees in writing

Who owns workstation use policies, who helps and who assesses

The covered entity or business associate owns the workstation use policy under 45 CFR 164.310(b). The security official usually holds accountability for the policy and its approval, while IT or platform engineering supplies the facts the policy depends on, such as which device types exist and where they are used. Leadership and the workforce own the day-to-day behavior the policy describes, and that is the part an assessor will ask about first.

Policy ownership: The security official approves the written policy, names the workstation classes it covers, and keeps it current when remote work or device types change.
Classes and functions: IT defines each workstation class, the ePHI functions it performs and the settings it must keep, including laptops, desktops and remote setups.
Inventory: IT or platform engineering maintains the list of devices that can reach ePHI and the people responsible for each one.
Physical surroundings: Facilities and department managers describe where each class may be used, such as clinic rooms, home offices or public areas.
Staff acknowledgment: HR or the compliance lead collects signed acknowledgments and ties them to training records.

Before engaging anyone, confirm internally who signs the policy and who can produce the inventory on request.

Questions buyers ask about workstation use compliance

How much effort does workstation use compliance take for a small practice compared with a multi-site organization?

The effort scales with the number and variety of workstations, the number of sites and how staff reach ePHI, not with the size of the organization alone. A small practice with a handful of desktops, one location and a single electronic health record usually has a short list of workstation types and a simple set of rules to write and enforce. A multi-site organization must document each class of workstation, its functions and the physical surroundings at every location, then check that each site follows the same rules. The main drivers are the count of device types, the number of locations with different physical conditions, the amount of remote access and how many systems hold ePHI. Ask any provider to break its estimate down by device class and site so you can see where the time goes.

Can we meet the workstation use standard in-house without outside help?

Yes, the standard does not require an outside firm, and a covered entity or business associate can write and maintain its own workstation policies. The work is mostly documentation and verification: listing workstation types, stating the permitted functions and manner of use, describing the physical surroundings, and checking that staff follow the rules. Outside help is most useful when the team lacks staff with time for the inventory, needs an independent view of gaps, or must map many endpoints quickly. Whatever you choose, the organization remains responsible for its own policies. An implementation partner can prepare systems and evidence, but only an independent assessor issues reports on compliance, and HHS does not certify compliance.

How long does workstation use compliance take, and what sets the timeline?

The timeline depends on how quickly you can inventory workstations and agree on the rules that apply to each class. No supplied fact gives a standard duration, so confirm estimates with your provider against your own environment. The steps that most often extend the schedule are an incomplete device list, unclear ownership of remote or shared machines, policy approval cycles, and the time needed to change physical arrangements such as screen placement or shared-area controls. Any engagement should begin with a written scope that names the sites, device classes and deliverables, so the timeline reflects agreed work rather than assumptions.

What does the organization need to provide for workstation use compliance?

The organization must supply the decisions and the access that no outside party can make for it. Expect to provide:

A named owner for the workstation policies and for the security official role under the rule
A complete list of workstation types, their users and their locations, including laptops and any electronic media kept near them
Read access to endpoint management or inventory data, and administrative access where configuration checks must run
Sign-off from clinical and operational leaders on the permitted functions for each workstation class

Without these inputs, any policy written by a consultant or partner will describe systems the organization does not actually run.

Do remote workstations and personal devices that access ePHI fall under the standard?

Yes, if a device can access ePHI, it belongs in the workstation analysis. The rule defines a workstation as a laptop, desktop or other device performing similar functions, plus electronic media in its immediate environment, so home computers and laptops used for clinical work are covered. Bring-your-own-device arrangements do not remove the obligation, although the policy may treat personal and organization-owned devices differently. Your policy should state where remote work is allowed, what physical protections apply at home, and how lost or shared devices are handled. HHS publishes remote use guidance and mobile device tips in its Security Rule materials, which are a useful starting point for this part of the policy.

Is there a HIPAA certificate for workstation compliance?

No, there is no HIPAA certificate for workstations or for any other part of the Security Rule. HHS states that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not stop HHS from later finding a violation. A vendor offering a HIPAA workstation certificate is offering a private document that OCR does not recognize as proof of compliance. What regulators can review is your written policy, your workstation records and evidence that staff follow the rules. An independent assessment can test that evidence, but it is not a HIPAA certification.

What could the pending Security Rule revision change for workstation use?

HHS proposed a major revision to the Security Rule on January 6, 2025, and the proposal has not been finalized. As of October 2026, no final rule has been published, and the latest Unified Agenda lists final action as projected for July 2027. The proposal would strengthen many technical and documentation expectations, so organizations should watch for changes to how workstation and device requirements are written. Until a final rule is published, the current standard in 45 CFR 164.310(b) applies. Plan your workstation documentation so it can be updated, and confirm the status with the Federal Register and the Unified Agenda before making commitments based on the proposal.

How DeployOpen prepares workstation use evidence

DeployOpen helps organizations write workstation use policies for 164.310(b) and build the inventory, configuration checks and records that show those policies are followed. Our role is to prepare systems and evidence inside your own infrastructure, while your organization owns the policies and an independent assessor reviews them.

How we scope

The written scope lists which workstation types, laptops, desktops and remote setups are covered by the policy.
Scope names the systems that hold the inventory and configuration data used as evidence for each workstation class.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure asset inventory and endpoint configuration checks so each workstation class is recorded with its function and location.
We set up policy checks for settings such as screen locking and disk encryption, mapped to the rules your policy states.
We test that inventory and check results match the policy on sample devices before handover.

How we hand over

You receive the workstation use policy drafts, configuration baselines and a description of how each check was built.
Handover includes runbooks showing how to export inventory and compliance results for an assessor's review.
Your staff own the policies and the evidence, and we document which steps still require your own review or sign-off.

How we support

Ongoing support, upgrades and continuous testing of the workstation checks are available as a retainer.
Retainer work can cover updating policies when new device types or remote work arrangements are added.
Ask any provider to confirm in writing who signs off on policy content and who reviews evidence at the audit stage.

164.310(b) Workstation use