Ad-Hoc File Transfer Procedure¶


Distribution	Employees and Contractors; Clients upon request
Version	1.0
Approved	2026-03-15
Approved by	Ben Smith

Overview¶

This standard operating procedure (SOP) defines the approved methods for ad-hoc file transfer to and from FooEngine Limited, covering the exchange of content assets and other files with clients, vendors, and third parties on a case-by-case basis.

This SOP governs ad-hoc, request-driven transfers only. It does not apply to transfers that form part of an established, automated, or repeating workflow, which are governed separately. All staff must use one of the approved methods listed in this SOP, selected in the order of preference set out below.

Scope¶

This SOP applies to all FooEngine Limited employees, contractors, and any individual acting on behalf of the company when sending or receiving files on an ad-hoc basis. It covers all transfers involving content assets, client deliverables, or confidential data.

The use of any method not listed in this SOP is prohibited without prior written approval from the CTO.

Approved Transfer Methods¶

The following methods are approved for ad-hoc file transfer. The highest-priority option that is technically and operationally feasible must be used. Deviations from this order require documented approval.

Method 1 (Preferred): Aspera on Cloud¶

Aspera on Cloud (AoC) is one of two jointly preferred methods for all ad-hoc file transfers. It provides enterprise-grade security, high-speed transfer over the FASP protocol, and end-to-end encryption, making it particularly well suited for large media files and sensitive content assets.

Why it is preferred¶

Uses IBM Aspera's FASP transport protocol, which encrypts data in transit using AES-256 and delivers significantly faster transfer speeds than standard TCP/IP connections, particularly over high-latency or long-distance links.
Full audit trail: all transfer activity is logged within the AoC platform, recording who transferred what, when, and to or from which endpoint.
Access is controlled via named user accounts or authenticated shared inboxes, ensuring files are only accessible to authorised parties.
Supports transfer of very large files and folder structures without compression or splitting, preserving content integrity.
Aligns with MPA Content Security Best Practice Guidelines and is the recognised standard for secure media exchange in broadcast and post-production.

Operational requirements¶

All staff involved in ad-hoc sends or receives should hold an active, appropriately permissioned AoC account.
Transfers to or from external parties must use designated shared workspaces or client-specific folders, not personal home directories.
Shared inboxes and workspace directories must be configured with appropriate access controls and reviewed periodically.

Method 1 (Preferred): AWS S3 Cross-Account Access¶

Direct S3-to-S3 transfer via AWS cross-account IAM access is equally preferred to Aspera on Cloud. This method should be used where both FooEngine and the counterparty operate within AWS and have the technical capability to configure cross-account bucket access. It provides a cloud-native, fully auditable, and highly secure transfer mechanism without reliance on third-party platforms.

Why it is preferred¶

All data remains within the AWS network, encrypted in transit via TLS and at rest via SSE-S3 or SSE-KMS, with no exposure to the public internet when VPC endpoints or AWS PrivateLink are in use.
Access is governed by IAM policies and S3 bucket policies rather than shared credentials or download links, providing fine-grained and auditable access control.
All S3 API calls are logged via AWS CloudTrail, producing a complete and tamper-evident audit trail of who accessed or transferred what, and when.
No file size limits, no expiry concerns, and no dependency on a third-party service's availability or pricing.
Well suited to large-volume or programmatic transfers between FooEngine and AWS-based clients or partners.

How cross-account access works¶

Cross-account S3 access is established by granting a client's AWS account, or a specific IAM role within it, permission to read from or write to a designated FooEngine S3 bucket, or vice versa. No credentials, passwords, or download links are exchanged; access is tied to the counterparty's own authenticated AWS identity.

Operational requirements¶

Cross-account access configurations must be set up by, or under the direct oversight of, the CTO. Ad-hoc or informally configured cross-account policies are not permitted.
Bucket policies and IAM roles must follow the principle of least privilege: access should be limited to the specific bucket or prefix required, for the minimum duration necessary.
Dedicated transfer buckets or prefixes must be used for external access rather than granting access to production storage directly.
Access grants must be reviewed and revoked promptly once the transfer or project is complete. The Head of Media Operations is responsible for tracking active external access grants.
CloudTrail logging must be enabled on all buckets used for external transfers, with logs retained in accordance with the company's data retention policy.

Method 2: WeTransfer¶

WeTransfer may be used for ad-hoc transfers where neither Aspera on Cloud nor S3 cross-account access is available to the counterparty. All use must be via the FooEngine organisational WeTransfer account.

Receiving files¶

The preferred way to receive files via WeTransfer is through a File Request. This generates a dedicated upload link for the sending party, allowing them to deposit files directly into the FooEngine account without requiring an account of their own.

File Requests must be created from the FooEngine WeTransfer account. Personal or free accounts must not be used.
Requests should be clearly named to identify the project or client, and closed or deactivated once the expected transfer has been received.
File Request links must only be shared directly with the intended sender via a trusted channel, such as email to a verified contact.

Sending files¶

When sending files to an external party via WeTransfer, the following controls are mandatory without exception:

Mandatory Controls for WeTransfer Outbound Transfers
1. Recipient tracking must be enabled. The recipient must enter their email address before downloading.
2. A password must be set on the transfer. The password must be sent to the recipient separately from the download link (e.g. via a separate email, phone call, or secure message).
3. The download link expiry must be set to no longer than 7 days. A shorter expiry is preferred where the recipient can reasonably be expected to download promptly.
4. Transfers must be sent from the FooEngine organisational WeTransfer account. Personal or free accounts must not be used.

Expiry extensions¶

If a recipient requires access beyond the 7-day default, an extension must be approved by the CTO or Head of Media Operations before a new link is generated. The reason and approved duration must be documented. Routine re-sending without approval is not permitted. Where extensions are repeatedly required for the same transfer, this is an indicator that a Method 1 option would be more appropriate.

Prohibited uses of WeTransfer¶

Sending files without recipient tracking or a password.
Sharing download links publicly or via channels where unintended parties may gain access.
Using personal or free WeTransfer accounts for business transfers.
Setting link expiry beyond 7 days without prior documented approval.

Method 3: Client Dropbox¶

Where a client uses Dropbox as their primary file sharing platform, FooEngine can receive files via a Dropbox shared folder. This method is approved for inbound receipt only and is subject to the conditions below.

How it works¶

The client shares a Dropbox folder with the FooEngine account registered at acs@fooengine.com. Once accepted, the shared folder appears within that account and files deposited by the client become accessible to authorised FooEngine staff.

Conditions of use¶

It must not be used to expose FooEngine data or internal files to the client via the same shared folder unless explicitly approved.
Shared folder invitations must be verified before acceptance. If an invitation is unexpected or from an unknown party, it must be confirmed with the relevant client contact before the share is accepted.
Access to the acs@fooengine.com Dropbox account is restricted to authorised personnel. Credentials must not be shared informally.
The Head of Media Operations is responsible for managing accepted shares, monitoring incoming content, and removing shares that are no longer active or relevant.
Files received via Dropbox must be moved to internal storage or the production environment promptly. Dropbox must not be used as long-term storage for client assets.

Limitations¶

FooEngine does not provision outbound Dropbox shares to clients. For sending, use a Method 1 option or WeTransfer with full controls applied.
If a client requests that FooEngine create and share a Dropbox folder outbound, this must be escalated to the CTO for approval before proceeding.

Non-Approved Methods¶

The following methods are explicitly not approved for ad-hoc business or client file transfer unless a written exception has been granted by the CTO:

Personal or consumer-grade cloud storage (e.g. personal Google Drive, iCloud, OneDrive).
FTP or SFTP connections to unvetted or unapproved servers.
Email attachments for content assets or confidential files larger than 10MB, or involving sensitive content.
USB drives or physical media without prior approval and appropriate encryption.
Free-tier or personal accounts on any file transfer platform.
Messaging apps (WhatsApp, Telegram, Signal, or similar) for business content or client assets.

Responsibilities¶

All Staff: must use only approved transfer methods, apply required controls, and report any use of non-approved methods to the Head of Media Operations.

Head of Media Operations: is the day-to-day operator for WeTransfer and Dropbox transfers, responsible for managing active shares, tracking S3 external access grants, applying required controls, and escalating approvals to the CTO where required.

CTO: is the SOP owner, approves and oversees S3 cross-account configurations, approves exceptions and extension requests, and reviews this SOP annually or following any significant incident.

Exceptions and Review¶

Any transfer arrangement not covered by this SOP requires written approval from the CTO prior to the transfer taking place. Exceptions must be logged with the business justification, parties involved, data transferred, and any mitigating controls applied.

This SOP will be reviewed annually, or sooner in response to changes in tooling, client requirements, or applicable security standards.