Child Site Management Policies let Parent Site Administrators enforce specific site settings across Child Sites. When a setting is included in a policy, the value set by the Parent Site applies to every Child Site included in the policy, and Child Site Administrators cannot change it. Settings not explicitly included in the policy remain under each Child Site's control.

Settings values are saved inside the policy itself. Changing a setting on the Parent Site does not change the policy value. Edit the policy directly to change what is enforced on Child Sites.

A settings policy never restricts or changes the Parent Site's own settings.

When to Use a Policy

Use a settings policy when your organization has requirements that Child Site Administrators must not be able to override. The driver is typically security, compliance, or data governance. Common examples:

If your compliance program prohibits unencrypted FTP, add the Plain/unencrypted FTP Support setting to the policy and disable it. Child Site Administrators cannot re-enable it.
If users across your organization must use 2FA, enforce that setting from the Parent Site so no Child Site can relax it.
If your data governance program requires a specific retention period, set it in the policy to prevent Child Sites from diverging.
If your organization pursues government work, enable FedRAMP Security Mode in the policy. The policy gains the six settings that the mode enforces, and Child Site Administrators cannot relax any of them.

Creating a Policy

To create a settings policy, provide a Name. You can also provide a Description as a note for reference.

Define the scope of affected Child Sites. Each policy applies only to the child sites assigned to it, and each child site belongs to only one policy at a time, so policies never overlap on the same site.

One policy can be designated the default. If a default policy exists, new Child Sites automatically inherit the default policy.

Add any settings you want to enforce to the policy. Each setting requires a value, and the value must be valid for that setting. Settings you do not add remain editable within each Child Site. The full list of policy-managed settings is in the developer documentation.

When you save the policy, the settings take effect immediately for every Child Site included in the policy.

Custom SMTP

A Parent Site Administrator can enforce SSL Mode through Custom SMTP on the policy's Networking tab. The Custom SMTP encryption modes determine whether encryption is required before authentication or message delivery. A mode included in the policy is preserved rather than changing automatically after a verified STARTTLS connection.

Managing any Custom SMTP field in a policy, including only SSL Mode, locks the entire Custom SMTP form in the Child Site's web interface. Child Site Administrators cannot edit the other SMTP fields through that form, even when those fields are not included in the policy.

Switching a policy to Use standard outbound SMTP server removes SSL Mode from the policy instead of resetting it to Use If Available. The policy stops controlling the mode. A Child Site using Custom SMTP with Use If Available can again change automatically to Require SSL (Explicit) after a verified STARTTLS connection.

Managing Desktop and Mobile App Access

To enforce which apps users can connect with across Child Sites, open the policy's Clients & Protocols tab and select General. Use Add to Policy for Desktop App Enabled, Mobile App Enabled, or both, and set each included switch to the value you want to enforce. On an affected Child Site, the setting shows Managed by Parent Site Administrator and cannot be changed locally.

Turning either setting off signs out all users of that app on the affected Child Sites and blocks new sign-ins to it, including for administrators. This also applies to Parent Site users connecting to a Child Site: the Child Site's app setting governs that connection. The Parent Site's own app access is unchanged, and users can still sign in to the affected Child Sites through the web app, including SSO.

Turning the setting back on permits fresh sign-ins; sessions that were signed out are not restored. App availability is separate from app session lifetimes, which affect only newly issued sessions.

Managing Root Folder Settings on Child Sites

You can add File Expiration, Limit Uploaded Files to Certain File Extensions, Limit Uploaded Files to Regular Expression, and Malware Scanning to a policy. Files.com then creates each one on the root folder of every Child Site the policy covers, and each setting applies to all subfolders.

A folder setting added through a policy replaces any folder setting of the same type that a Child Site already has. If the setting was turned off for certain folders on the Child Site, the policy turns it back on there. While a folder setting is part of a policy, nobody on the Child Site can change it, including the Child Site's own Site Administrators.

Removing a folder setting from a policy, or deleting the policy, does not delete the setting from a Child Site. This way, a deleted policy can never quietly take away a protection the Child Sites rely on. Each Child Site's own Site Administrators can change or delete the setting again. To remove it everywhere, delete it on each Child Site.

A policy can also turn on either or both Root Folder Settings for its Child Sites. Turning on Restrict Root Folder Settings to Site Administrators means only each Child Site's own Site Administrators can change folder settings on its root folder. Turning on Root Folder Settings Apply to All Workspaces as well makes the supported settings apply in every Workspace on each Child Site. The first works on its own. The second requires the first.