Can you store sensitive documents in HighLevel?

This guide covers what HighLevel says about its own security, the three places a file can sit in an account, how to set up a file field for documents you're cleared to keep, and why deleting a file and unsharing it are two different jobs. It isn't legal advice, and it can't clear any document type for you.

What HighLevel says about its security

HighLevel reports achieving SOC 2 Type II, with a stated scope of security, confidentiality and availability. Its help center also documents encryption in transit and at rest.

Those are statements about how HighLevel runs its platform. They don't say which kinds of documents belong in a contact record. The same security overview restricts storing sensitive information except where it is otherwise permitted, and that is the line to read first.

Payments show why scope matters. The June 2026 version of that overview said HighLevel was not PCI-DSS compliant. In October 2026 HighLevel announced a PCI DSS validation scoped to its SaaS payments. That newer announcement covers payments; it doesn't approve storing other documents. HighLevel has changed this before, so check the current pages.

A security report describes the platform. It doesn't approve what you put in it.

Three places a file can sit

HighLevel has more than one home for documents, and they are separate features. Knowing which one you're using tells you where to look when a file has to come out again.

• A File Upload custom field on the contact. The file sits on the contact record, where it can be opened, replaced or removed from the field.
• Contact Documents and Documents & Contracts, which HighLevel treats as two separate features. Don't assume a setting in one carries over to the other.
• The Client Portal, where a contact can upload files to you. Those files appear under Documents > Received > Client Portal, and an upload there can start a workflow through the Client Portal File Uploaded trigger.

Questions to settle before the first upload

Before you build anything, write down what the documents are and who decided they may be kept in HighLevel. If nobody can answer the second part, stop there.

• What is actually in the file? A signed agreement, a photo of finished work, a tax return, a health record and an ID document are very different questions.
• Does HighLevel's own description of permitted data cover it? Its security overview is the place to check.
• Which rules apply to your business and to this kind of document? That's a question for your lawyer or compliance adviser, not for a CRM setting.
• Who on your team needs to open these files, and who else has a login that can see contacts?
• When does each file get deleted, and whose job is that?

Setting up a file field for documents you may keep

Once a document type is cleared for HighLevel, a File Upload custom field on the contact is the simplest home for it.

1. Review the data categories HighLevel permits, and your answers to the questions above, before you create anything.
2. Go to Settings > Custom Fields > Create Custom Field and choose File Upload as a contact field.
3. Set the file formats the field accepts. Turn on Allow Multiple Files only if one contact really needs more than one file in that field.
4. Name the field for exactly what it holds, so nobody drops a different kind of document into it later.
5. On a test contact, use Upload File, then open, replace and remove the file to see each step work before real files go in.
6. If clients will send files through the Client Portal instead, check the contact's portal access and the sharing controls before you invite anyone.

Deleting a file is not the same as unsharing it

HighLevel treats deleting a document and revoking its portal sharing as separate actions. Doing one doesn't mean the other happened. When a client relationship ends, or a file was shared by mistake, check both: is the file gone from the record, and has the sharing been switched off?

If your documents need tight control over who can download them, test that control in your own account with a dummy file before real ones go in. If HighLevel can't do what your rules require, keep those files in a system built for them and store only a note in the contact record.