Collect sensitive documents through a secure upload portal.

A secure upload portal is designed to make external submission straightforward. Clients, suppliers or partners can be given a controlled portal route without being added to the organization's internal systems or asked to adopt a general collaboration platform. The precise sender journey can be configured around the intended use case.

This is different from public file sharing. The portal link is an intake route, not a link that exposes a stored document for anyone to download. The receiving side remains controlled by the organization, and submissions are routed to authorized business users or teams.

• Simple sender experience: open the portal, select the files and provide the requested context.
• Clear recipient ownership: the organization decides where the submission should go.
• Branded presentation: logos, colors and a suitable domain help reassure external users.

Where stronger sender verification is required, the organization should define that requirement during implementation and consider the sensitivity of the material being collected. The portal should form part of a wider process covering sender communications, staff responsibilities and exception handling. For ongoing two-way exchanges with named external users, review MX's approach to controlled B2B file exchange.

When a file enters MX, it receives AES-256 protection and is processed through the platform's patented quantum secure methodology, known as Anonymise, Shard, Restore. The methodology separates identifying context, divides the data into encrypted shards and restores the file through the authorized receiving workflow.

The upload is also associated with relevant activity information so the organization can evidence the submission and subsequent handling. Depending on the configured process, this can include the sender, upload time, intended destination and access events.

• Anonymise: separate the file payload from identifying context.
• Shard: divide the protected data so an individual shard is not a complete usable file.
• Restore: make the file available through the authorized business workflow.

MX is designed for controlled exchange rather than permanent cloud archiving. Expiry and removal settings should be agreed according to the organization's purpose, legal obligations and records policy. The receiving team remains responsible for how the restored file is stored or processed after the transfer. Read more about the encrypted file-sharing process and the controls that sit beyond conventional transfer encryption.

Technology can support compliance, but it cannot decide whether an organization should collect a document or make the wider processing lawful. Those decisions still depend on purpose, applicable legal requirements, transparency, data minimization, retention and appropriate organizational controls.

MX helps facilitate compliance efforts by giving organizations a more controlled and evidence-led transfer process. Named business access, activity records, expiry settings and data-location options can support HIPAA, CCPA, GLBA, SOX and NIST 800-171-related workflows when they are configured and operated appropriately.

• Accountability: record relevant submission and access activity.
• Access limitation: route documents to authorized users or teams.
• Data minimization: apply expiry and removal according to business purpose.
• Governance: use one approved process that staff can explain consistently.

The NIST Cybersecurity Framework explains why governance, protection and detection need to work together. MX provides transfer controls and evidence, while the organization remains responsible for its policies, configuration and lawful use. See the dedicated HIPAA file-sharing guidance for a regulated US example.

Yes. MX is designed to support large file transfers without forcing external users to divide a submission into several email messages or move to an unapproved consumer service. This is useful when the organization needs to collect design files, media, imaging, datasets, technical packages or other operational content that exceeds ordinary attachment limits.

The same secure upload process applies whether the sender is providing a small signed form or a multi-gigabyte project file. The portal keeps the submission, sender context and receiving workflow together, helping the team avoid manual reconstruction afterwards.

• One route: smaller documents and large data packages can use the same approved portal.
• No manual splitting: senders do not need to create several partial archives.
• Clear receipt: the receiving team can see when the upload reaches the workflow.

Actual performance will still depend on the sender's connection, browser, network controls and the organization's own environment. For very large or time-sensitive exchanges, the rollout should be tested with representative files and external users. The secure large file transfer page explains how MX supports these heavier workloads.

Custom white labeling allows the portal to reflect the organization's identity through its logo, colors and suitable domain experience. This is more than a visual detail. External users are more likely to trust and follow a document request when the submission route clearly belongs to the organization they already recognize.

A good rollout begins with one defined workflow rather than opening a general-purpose upload page for every possible use. Choose a team, document type or client process where email attachments create repeated risk or administration, then agree the ownership and policy around it.

1. Define the purpose: specify what should and should not be submitted.
2. Set the controls: agree routing, access, expiry and sender instructions.
3. Test the journey: use representative external users and file sizes.
4. Review the evidence: confirm the activity record meets operational and governance needs.

Once the pilot is working, the same pattern can be extended to other teams or external groups. Compare available MX plans or discuss a portal rollout with the team.