Who Can See Your OSHA 300 Log and Injury Records? Fewer People Than Your Software Thinks

A worker has a right to his own Form 301 — not to his coworkers'. That single sentence from 29 CFR 1904.35(b)(2)(v) is the access rule most safety software gets backwards. The market sells "role-based access" as a feature checkbox, and then hands every account in the company a synchronized copy of the injury log — names, dates of birth, what happened and to which body part. Nobody on the crew asked the compliance question that actually matters on payday Friday: if my foreman opens the app, what does he see about my accident?

Get this wrong and the damage is doubled. The employer loses the crew's trust the day a worker discovers his diagnosis is one tap away for fourteen colleagues — and loses the demonstration, in the same moment, that records required by Part 1904 and 1910.1020 were handled the way those rules require.

At a glance: an employee gets the establishment's 300 Log (1904.35(b)(2)(iii)) and his own 301 ((b)(2)(v)(A)) by the end of the next business day; a union representative gets 301s stripped to the "Tell us about the case" section within 7 calendar days. Six case types are privacy concern cases that must not carry a name on the Log (1904.29(b)(7)): "privacy case" goes in the name space, the names live on a separate confidential list. And the respirator medical questionnaire is closed to the employer entirely: "your employer or supervisor must not look at or review your answers" (1910.134 App. C). Under OSHA rules, an employee may see his own 301 incident report and the establishment's 300 Log, six privacy-concern case types must not carry the employee's name on the Log, and the respirator medical questionnaire may not be looked at or reviewed by the employer or supervisor.

The access map, straight from the text

Notice what the table does not contain: any right for the workforce at large to browse the injury records. The 300 Log is available on request to the people the rule names — it is not a feed.

Privacy concern cases: when even the Log must not name the worker

1904.29(b)(7) lists six case types where the name never goes on the Log — you enter "privacy case" in the name space and keep a separate, confidential list matching case numbers to names:

1. an injury or illness to an intimate body part or the reproductive system;
2. an injury or illness resulting from a sexual assault;
3. mental illnesses;
4. HIV infection, hepatitis, or tuberculosis;
5. contaminated needlesticks and sharps cuts;
6. any other illness, if the employee asks that his or her name be left off.

And (b)(9) goes a step further than most programs realize: when removing the name isn't enough (a 40-person company where everyone knows who broke what), you may use discretion in the description itself, keeping the cause and general severity while dropping details of an intimate nature.

The trap for digital systems is masking the name on screen while the database still serves the employee_name column to anyone who queries the API. Screen masking is a costume. The confidential list of 1904.29(b)(6) is only confidential if the stored record is partitioned — not just the pixels.

The respirator questionnaire: a door OSHA closed on the employer itself

Appendix C to 1910.134, the mandatory medical evaluation questionnaire, speaks to the employee directly, and the sentence is remarkable:

"To maintain your confidentiality, your employer or supervisor must not look at or review your answers, and your employer must tell you how to deliver or send this questionnaire to the health care professional who will review it."

Read that as a software requirement and it becomes uncomfortable for most of the market: digitize the questionnaire naively — one table, organization-wide admin read — and the software manufactures a violation that paper never committed. The employer's lawful output from the medical evaluation is the determination (cleared, cleared with restrictions, not cleared), not the answers behind it. The same logic runs through 1910.1020(e)(2)(ii): access to employee medical records rides on the employee's specific written consent, not on job title.

Where the wall stands in HazComFast

Measured on the live product, by querying the API directly rather than the screen:

• a worker account querying the incident API directly gets HTTP 200 with zero rows: no coworker's case file, no date of birth, no injury description, whatever the query;
• the same worker account attempting to create an incident record is refused;
• an administrator reading the respirator medical questionnaire table is refused by the database — the partition binds the top of the org chart too, which is what App. C demands;
• SDS metadata stays inside the organization that owns it: zero rows cross-organization, every row for the owner;
• and the witnesses that prove the wall is in the right place: admins and site managers see every case and product they are entitled to, and the worker account can still file a near-miss report — closing the records does not close the reporting channel.

The distinction that matters when you evaluate any system, ours included: ask where the wall is built. A wall in the user interface stands until someone queries the backend directly. A wall in the database stands regardless of which client asks. "We don't display it" and "it is not readable" are different sentences, and only one of them is a compliance statement.

The hub & related: OSHA recordkeeping — 300, 300A & 301 · Crews without email & shared logins · OSHA Recordkeeping Requirements: the 300 Log Guide · Is a Near Miss OSHA Recordable? · 30-Year Record Retention under 1910.1020 · Respirator Fit Test Log (free tool)

Sources & verification: employee and representative access rights, deadlines, and the "Tell us about the case" limitation per 29 CFR 1904.35(b)(2), verified against the CFR text 2026-08-27; privacy concern cases, the confidential list, and the description-discretion provision per 29 CFR 1904.29(b)(6)-(b)(9), verified 2026-08-27; the questionnaire confidentiality sentence quoted verbatim from Appendix C to 29 CFR 1910.134, verified 2026-08-27; medical-records consent per 29 CFR 1910.1020(e)(2)(ii), verified by our regulatory review against osha.gov 2026-07-28. Product behavior verified on the live product on August 21, 2026, by direct API call. HIPAA is not the framework for employer-held exposure and medical records under 1910.1020 and is deliberately not invoked here. General guidance, not legal advice.