MSSP Policy Inheritance

Overview

Policy Inheritance enables MSSPs to define and centrally distribute standardized policies—such as Categories and Lists—across all client organizations. This approach ensures consistent enforcement of core security controls while significantly reducing the administrative burden on MSSP teams.

• Inherited Lists are locked for editing to maintain uniformity across organizations. However, client organizations can create and apply their own supplemental lists to meet unique requirements.

• Inherited Categories are also locked by default. However, MSSP admins can grant specific organizations permission to create their own policies, which can override the inherited categories—striking a balance between centralized governance and client-level flexibility.

• Rules are not inherited. They are always managed at the organization level, provided the MSSP has allowed the organization to create and manage its own policies.

This inheritance model delivers consistent protection where it matters most while still empowering organizations to tailor policies to their specific needs.

Enabling Policy Inheritance

To initiate configuration of Policy Inheritance, navigate to settings icon and select MSSP Settings. Then, click on ‘Policy Inheritance’.

Policy Inheritance is disabled by default.

Inheritance Toggle

Enabling the Inheritance toggle activates policy inheritance, causing all client organizations under the MSSP to automatically inherit the configured policies defined by the MSSP. This replaces the org specific Default Policy with that of the MSSP’s policy.

Permission to Create Policies

As an additional layer of control, MSSPs can determine whether their client organizations are allowed to create their own policies. This setting is critical, as client-created policies can override elements of the inherited MSSP policy—impacting how protections are applied within each organization.

• Only when Specifically Allowed: When selected, this option lets MSSPs control policy creation on a per-organization basis—enabling them to specify exactly which client orgs are permitted to create their own policies.

• To All Orgs by Default: This allows ALL orgs under MSSP control to create their own policies.

Granting Specific Orgs Policy Creation Abilities

When an MSSP has enabled Policy Inheritance and selected Only When Specifically Allowed under Permission to Create Policies, they can configure policy creation permissions on a per-organization basis.

To grant individual orgs the ability to create their own policies, follow these steps:

1. From the Organization selector at the top of the page, select the org that you would like to give policy creation permissions to.

   

2. Next select Protect Policy Management from the left-side menu.

3. Finally, at the top right of the main page, toggle, Permission to Create to enabled.

   

4. “Test Org” will now be able to create their own policies.

5. Repeat these steps for each org you wish to grant the permissions for.

MSSP Policy Configuration

With Policy Inheritance now enabled, let’s explore how to create and manage these policies effectively. Start by hovering over the MSSP shield on the left-side menu. You’ll be presented with two options, Categories & Lists

Categories

The Categories section in the MSSP Policy Management interface enables MSSPs to specify which content categories will be blocked by default for their child organizations. In HYAS Protect, threat-related categories are non-configurable and are always blocked to ensure maximum security. However, other content filtering categories can be customized for inheritance by child organizations. Simply select the categories you want to block, and these settings will automatically be applied to the child organizations.

When policy inheritance is enabled, the categories configured by the MSSP appear under each organization's Default Policy → Categories. These inherited categories are read-only at the org level and reflect the MSSP's enforced settings.

Lists

HYAS Protect allows MSSPs to create block and allow lists that are automatically inherited by their child organizations. These lists are visible to organizations as the Default list (look for Status as INHERITED) but cannot be modified. However, organizations can create their own lists to explicitly override the MSSP-defined settings if needed.

To create an MSSP-level list, select the action (e.g., Block or Allow), and type (e.g., FQDN, Domain etc). Navigate to the appropriate section and create a new list, which will appear under the Custom Lists section. Add the required indicators to the list, and these configurations will be applied to the child organizations.

Here’s how an organization’s List Management will appear with inherited lists, highlighting that MSSP-defined lists are locked and cannot be edited.