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.

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.

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.

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.