What HIPAA and SOC 2 auditors actually check in a shared mailbox
Compliance and risk officers rarely get surprised by a new regulatory requirement during an audit. What actually catches people off guard is realizing, mid-conversation with an auditor, that a shared mailbox can't answer a question everyone assumed was already covered: who handled this, when did they handle it, and can you show me.
This article isn't a substitute for legal or compliance advice specific to your organization. It's a practical look at what HIPAA and SOC 2 auditors commonly ask for when a shared mailbox is in scope, and what it actually takes to have that answer ready before the question comes up.
What HIPAA auditors typically ask for
Who has access, and why. Not just a list of names with Full Access or Send As permissions, but a documented justification tied to minimum necessary access. Auditors generally want to see that access reflects an actual business need, reviewed periodically, not a list that's grown by habit.
Can you show me who handled this message. For a mailbox that touches protected health information, an auditor may point to a specific message and ask who was responsible for it and when it was addressed. A plain shared mailbox has no native way to answer that with certainty. Anyone with access could have opened, read, or replied to it.
What's your retention and disposal policy. HIPAA compliance generally requires a defined retention period for records containing PHI, along with secure disposal once that period ends. This needs to be documented and demonstrably followed, not just assumed.
Could you reconstruct a disclosure if something went wrong. In the event of a suspected breach, the organization needs to be able to identify what information was involved and who it was disclosed to. Without a clear ownership and activity trail, reconstructing this after the fact becomes a manual, time-consuming exercise, right when speed matters most.
What SOC 2 auditors typically ask for
Evidence of access control, not just an access control policy. SOC 2 audits generally look for documentation showing access reviews actually happen on a regular cadence, not a policy stating that they should.
Logging of user activity. Who did what within the mailbox, and when, maps directly to the monitoring and logging expectations under SOC 2's security criteria. A shared mailbox with no ownership model and no activity log has nothing to produce here.
Change management records. If permissions changed, when did that happen and who approved it. This is a common gap in mailboxes that have existed for years and accumulated access changes informally.
A demonstrable incident response process. Not just a documented plan, but evidence that the organization could actually execute it, including identifying who was responsible for a given piece of correspondence during the incident window.
The common thread: a record, not a policy
Across both frameworks, the pattern is the same. Auditors are generally satisfied by policies on paper up to a point, but what they're actually testing is whether the organization can produce a record that proves the policy is being followed. Shared mailbox security in regulated industries covers why this distinction matters conceptually; this is what it looks like when someone's actually asking.
A native Microsoft 365 shared mailbox supports access control well, but it has no built-in mechanism for showing who handled a specific message, tracking response times against a regulatory window, or producing a reviewable ownership history. That gap is usually not a sign of poor practices. It's a sign the mailbox was never built to produce this kind of evidence in the first place. Governance structure in Microsoft 365 and how IT teams should structure shared mailboxes both cover the structural side of closing that gap.
What to have ready before an audit
A documented, reviewed access list with justification for each person's access. The ability to pull up a specific message and show who owned it and when it was actioned. A written, enforced retention and disposal policy. And evidence, not just a claim, that response-time commitments tied to regulatory windows are being met.
If you're evaluating a shared mailbox tool partly on its ability to produce this evidence, it's worth knowing that vendor compliance and your own compliance are two different things worth checking separately. Emailgistics holds SOC 2 Type 2 and HIPAA compliance itself, which matters for vendor due diligence, but it's a separate question from whether the tool helps you produce the records your own auditors ask for.
Conclusion
HIPAA and SOC 2 audits rarely ask for anything an organization hasn't already heard of in principle. What they ask for is proof: a specific message's handling history, an access list with justification behind it, a retention policy that's actually enforced. A shared mailbox that was never built to produce that proof isn't a compliance failure by itself, but it does mean the gap is worth closing before an auditor is the one who finds it.
In practice, auditors want to see a record, not just a policy: who has access to the mailbox and why, who handled a specific message and when, and how long messages are retained before disposal. A written access policy is a starting point, but HIPAA and SOC 2 auditors typically ask for evidence that the policy is actually being followed, which a plain shared mailbox has no built-in way to produce.
Common questions include who has access to the mailbox and whether that access reflects minimum necessary need, whether the organization can identify who handled a specific message containing protected health information and when, what the retention and disposal policy is for that information, and whether the organization could reconstruct what was disclosed and to whom in the event of an incident.
SOC 2 audits generally focus on evidence of ongoing control, not just controls existing on paper: documented and periodically reviewed access lists, logging of user activity within the mailbox, records of when permissions changed and why, and an incident response process that could actually be exercised if needed.
Not natively, in most cases. Native shared mailboxes support access control, but they don't log who handled a specific message, don't track response times against regulatory windows, and don't provide a reviewable record of ownership over time. Producing that evidence typically requires adding structure, ownership, and logging, on top of the mailbox, either through a dedicated tool or a disciplined manual process.