Data Protection and Lifecycle

When a Files.com Mount exposes a cloud bucket, people and workflows act on the files in that bucket. The provider's recovery, retention, lifecycle, and encryption policies govern those files. The storage operator controls those policies under the Remote Server ownership model. Your team can also configure Files.com expiration rules to remove files through the mount.

Files.com folder permissions control access through Files.com. Provider policies apply at the storage boundary, including to other applications that use the bucket directly. Both need to fit the job: a Files.com user allowed to delete a file can still receive a provider error when a retention policy prevents that deletion.

Recovery and Retention

Versioning keeps earlier contents when an object changes. Soft delete preserves deleted data for a recovery period. These features can make an accidental replacement or removal recoverable, but they also retain additional billable data. The storage operator sets the recovery window. Restoration uses the provider's recovery tools and requires suitable access there; Files.com's regular mounted listing shows current files rather than every retained copy. For a counterparty's bucket, recovery may therefore depend on that operator rather than your Files.com administrator.

Recovery and write-once retention answer different questions. Recovery helps you retrieve an earlier file after a change. A retention policy prevents specified changes for a required period, and a legal hold keeps protected data until an authorized person releases the hold. Write once, read many (WORM) describes preserving protected contents while continuing to allow reads.

Providers apply these controls at different scopes:

A retained version is not necessarily the file that a user sees at its usual path. In particular, S3 Object Lock alone does not promise that a file remains visible in the current listing. Conversely, a GCS retention policy can reject a recurring upload that replaces yesterday's report at the same name.

The storage administrator chooses the scope, mode, duration, and administrative permissions according to the owner's retention obligations. Some locked settings cannot be reversed or shortened. Confirm which protections apply before a workflow begins creating or replacing files.

With the operator's agreement, test the required create, replace, move, and delete operations in a separate location with the applicable policy. A successful upload under a new name does not test replacement, and a copy-and-delete move needs deletion of its source. If the policy prevents an operation, the workflow needs an agreed alternative or a change by the responsible administrator.

Lifecycle Rules

A lifecycle policy directs the provider to act on stored objects when conditions are met, such as their age, name prefix, class, or version state. Typical actions move older data to a cheaper class, expire current files, remove noncurrent versions, or abort incomplete multipart uploads. The provider performs this work independently of Files.com.

For a partner feed, one policy might keep incoming files immediately readable while another governs records already moved to an archive prefix. Expiring the incoming prefix too soon can remove files before the receiving application processes them. Transitioning working files to an offline tier can instead leave their names visible while preventing downloads until restoration.

Current files, noncurrent versions, soft-deleted data, and incomplete upload parts have different cleanup rules. Expiring the visible file does not necessarily remove all prior versions, and cleaning up incomplete multipart parts does not expire completed files. The storage owner configures the categories needed for its retention and cost goals. S3 Lifecycle, Azure lifecycle management, and GCS Object Lifecycle Management describe the provider's supported actions and conditions.

Expiration Through Files.com or the Provider

You can remove expired files using Files.com File Expiration or the remote provider's lifecycle rules. Either approach can meet a cleanup requirement; the useful choice depends on the access your team has, the rule's conditions, and the amount of data to process.

Files.com expiration sweeps run daily and delete files after a configured period without modification. Set the rule directly on the mount or a folder within it; a mount does not inherit expiration from its parent folder. This lets your team manage cleanup even when a customer or vendor owns the storage and you cannot configure its lifecycle policies. The Remote Server's credentials must allow listing and deletion of the affected files, and your team needs the Files.com administrative access required to configure expiration.

When you can configure the provider's lifecycle rules and they meet the retention requirement, provider-side expiration is often faster, especially for large collections. The provider performs cleanup within its storage service, while a Files.com sweep lists remote files and sends deletion requests through the connection.

Files.com expiration, provider lifecycle rules, and workflows that delete a source after delivery operate independently. Compare which timestamp starts each rule's retention period and which paths it covers. For a vendor feed, the owner's expiration schedule sets a collection deadline even if your team would prefer to keep the files longer. Provider retention protections still apply to deletion requests through Files.com, and recovery depends on the remote storage's versioning, soft delete, or other protection settings.

Encryption and Key Ownership

Server-side encryption protects stored contents using the storage service's encryption system. The service encrypts writes and decrypts authorized reads. Amazon S3, Azure Storage, and Google Cloud Storage provide default encryption at rest. This is separate from HTTPS encryption during transfer and from the permissions that decide who may read a file.

With provider-managed keys, the cloud provider manages the encryption keys. With customer-managed keys, the organization using the cloud storage controls a key in a key-management service and grants the storage service the access it needs. That organization may be the counterparty supplying the bucket for your connection.

Organizations choose customer-managed keys to control key policy, audit key use, and manage rotation or revocation independently of ordinary file access. That control also creates an operational dependency: unavailable keys or removed key permissions can prevent the storage service from reading retained contents.

The key and storage administrators manage encryption at the provider. Your Files.com connection needs the settings and access required to work with that configuration:

Changing a default key is not a general-purpose instruction to re-encrypt every existing object. The key owner needs to account for the provider's rotation behavior and retain key versions required for current and recoverable data. Deleting an encryption key can make otherwise retained files unreadable, so key retention belongs in the recovery plan as well as the access policy. When another party manages the key, that party must resolve unavailable-key failures; replacing the Files.com login credential does not restore the key's availability.

Client-side encryption instead encrypts contents before they reach the storage service. The stored object contains encrypted bytes; authorized storage access by itself does not reveal the original file. Decryption then needs the appropriate application and key. Files.com GPG processing can encrypt or decrypt files as part of supported workflows. If an application supplies files already encrypted, arrange decryption before steps that need to inspect or transform their contents. Plan that step's processing location and access requirements alongside the transfer path.