Security compliance requirements for document sharing

Map each framework to the workflow

For a health organisation, HIPAA means asking whether ePHI is protected through administrative, physical and technical safeguards. A clinic sharing a patient report needs unique identities, restricted access and evidence of activity, not just a statement that files are encrypted.

For a business serving people in the EU, GDPR can apply to the document and to the information generated around it. You need a lawful reason to collect viewer details, clear transparency, sensible retention and control over processors and subprocessors. The regulation became enforceable on 25 May 2018, and it applies in two main ways. If you have an establishment in the EU, it covers processing in the context of that establishment (Article 3(1)). If you don't, it still applies when you offer goods or services to people in the EU or monitor their behaviour there (Article 3(2)). Where someone happens to be located isn't the test on its own.

SOC 2 gives a buyer an independent examination of controls against selected Trust Services Criteria. ISO 27001 shows that an organisation runs an information-security management system based on assessed risks and documented treatment decisions. Both help with procurement. Neither removes the need to inspect the specific document-sharing path.

The control that matters is the one operating on the document you're actually sending.

Use the six functions against a document link

Govern asks who owns the risk, which policies apply and how leadership reviews performance. If nobody owns viewer-data retention, the setting will eventually become accidental.

Identify means understanding the information flow. List the document, video, viewer email, activity records, location details and any API or support access connected to the send.

Protect covers permissions, authentication, encryption, session controls and safe handling of copies. A public link and a recipient-specific link carry different risks, even when the PDF is identical.

Detect requires meaningful monitoring. A download alert is more useful when it names the actor, document, time and authorisation result.

Respond covers what you do after suspicious access, a lost device, a compromised account or an unexpected export.

Recover means restoring service and confidence without losing evidence or repeating the same failure.

Govern is the function teams underweight. Technical staff can configure access controls, but someone senior has to decide what data the organisation needs, how long it keeps it and which risks it accepts.

This is closer to building regulation than to buying one approved house design. The rules set outcomes and safety expectations. They don't prescribe the same floor plan for a small consultancy and a hospital.

A framework gives you a language for risk. It doesn't give you permission to stop thinking.

Turn the safeguards into product behaviour

HIPAA groups safeguards into administrative, physical and technical categories, and the workflow needs all three. Administrative safeguards cover risk analysis, workforce procedures, incident handling and vendor agreements. Physical safeguards concern the facilities and systems behind the service. Technical safeguards govern access, identification, audit controls and protection in transit and at rest.

For the clinic's report, a defensible set-up looks like this:

• Unique identities: every administrator, employee, service account and integration has its own. Shared credentials make responsibility hard to establish.
• Role-based access: the check should consider team, document and recipient permissions, not just whether someone holds the link.
• Emergency access: a controlled route for urgent access, with the event recorded and reviewed.
• Audit logs: authentication attempts, document creation and deletion, permission changes, link generation, downloads, video access, exports and support access.
• Risk-based protection: HIPAA doesn't prescribe one encryption algorithm, so you choose protections that fit your risks. It does require you to keep Security Rule documentation for six years from the later of its creation or last effective date.

In practice that points towards TLS in transit, strong encryption at rest, session expiry, least-privilege service roles and protected logs. None of it counts unless you can show it's configured, monitored and reviewed.

If you're assessing LiveDocument's posture, read its HIPAA security information alongside the vendor agreement and your own risk assessment. A compliance statement supports the review. It doesn't replace it.

Analytics create another compliance surface

Email gating helps a sender identify a recipient, but it's also a collection event that needs a lawful basis and a clear explanation. Page-level activity can show a sales team which part of a proposal needs follow-up. You still have to decide whether that granularity is necessary and how long it should stay available.

Before you switch tracking on, ask:

• What is collected by default?
• Is the viewer told what happens before they open the document?
• What purpose justifies collecting the email and activity data?
• How long are analytics, videos and logs retained?
• Which subprocessors receive the information?
• How can a person exercise their data-subject rights?
• Can access be revoked and records deleted when the purpose ends?

Here's the part vendors rarely say out loud: more analytics can mean more compliance work. A feature that gives you richer insight also creates more personal data to secure, explain, restrict and delete. Tracking is personal data, so tell recipients, limit who inside your team can see it and don't keep viewer records longer than the deal needs them.

If you're evaluating LiveDocument, its GDPR security information is the place to start. Then test the real settings against your privacy notice, retention schedule and processor agreements.

SOC 2 and ISO 27001 at a glance

Scope is where buyers get careless. A SOC 2 report can exclude a service, subsidiary or subprocessor that matters to your workflow. An ISO 27001 certificate can cover a business unit that doesn't include the product you're buying.

Neither automatically wins. I'd weight whichever evidence reaches furthest into your workflow. For SOC 2, read the system description, the examination period, any exceptions and the complementary user controls. For ISO 27001, ask for the certificate scope, the relevant risk treatment and proof the service sits inside the certified system.

A certificate is a useful door opener. It isn't a safe-passage document.

Ask for evidence at the workflow level

Data captured: does the service store document content, video, viewer emails, location, page-level activity, downloads and administrative actions?

Storage and transfers: where is it stored, where does it move and which subprocessors receive it? Data residency isn't a universal security proxy. Weigh encryption, jurisdiction, transfer mechanisms and contractual rights together.

Retention: get separate answers for documents, videos, analytics, emails, notifications and audit logs. One "account deletion" statement may not explain what happens to every derived record.

Revocation: test who can revoke access, whether an existing session stays active and what happens to copied or downloaded files. Revocation should be a real control, not a button that only blocks future opens.

Identity: do administrators, support staff, service accounts and integrations have distinct identities? How is privileged access approved and reviewed?

Audit coverage: do logs cover viewing, downloading, link creation, permission changes, exports, support access and failed authentication?

NIST SP 800-53 is a handy technical baseline. Its AU-2 control says organisations should identify the events that must be logged. AU-3 then sets what each audit record contains: what happened, when and where, the event source, the outcome and the identity involved. The NIST SP 800-53 Rev. 5 control catalogue has the source material.

For a proposal download, a useful record includes the document ID, viewer or administrator identity, session, UTC timestamp, action and whether it succeeded. Without those fields an alert tells you something happened, not whether it was allowed.

Review the monitoring and evidence package

Ask how the platform alerts on repeated failed logins, sudden bulk downloads, privilege escalation, disabled logging or unusual administrator access. Then ask what evidence you can export during an investigation. A credible package should include:

• Control mappings: which framework requirement each control supports.
• Access reviews: who reviewed privileged and recipient access, and when.
• Remediation records: how vulnerabilities were found, prioritised and closed.
• Incident and recovery tests: whether the response and restore processes have actually been exercised.

Our guide to secure file sharing platforms can sit next to your procurement worksheet, but the real work is yours. Put a test document through the exact workflow your team will use, then inspect the permissions, notifications, logs and deletion behaviour.