Planning security policies

Before you begin to add and configure security policies, determine the security needs of your organization and then plan your security strategy.

First, determine how many security policy roles and project roles you need. Then, determine whether you need to create a security policy with different roles, or whether you can simply modify the roles that are supplied by the Global security policy to meet your needs.

  • If all of the business units in your organization follow the same rules, or if you can implement the appropriate differences in access through a combination of project and security policy roles, it makes sense to implement one security policy: a modified Global security policy. You can add as many roles as necessary to the Global security policy.
  • If there are numerous functional groups in your organization that require different types of access, leave the Global security policy in its default state and add a security policy with one or more roles for each functional group.
  • At any time, a user can have an object role, a project role, and a security policy role. It is best practice to assign a user one security policy role only, from a single security policy. Therefore, if you have users who multi-task in such a way that they need more than one security policy role in addition to their project and object roles, it is recommended that you create more security policies and assign that user one role from each of the appropriate security policies.

As a best practice, try to implement the smallest number of security policies possible. Within a single security policy, you can configure different permissions for each marketing object type. You can also configure different permissions for each of your project and request templates. Additionally, for each project template you can configure different security role and project role permissions for each tab (custom as well as standard) separately for projects and project requests.

When you set up permissions for the roles, the individual permission settings are granular. For example, if you want users in a particular role to be able to edit the Summary tab of a project, you must grant that role both Edit and View permissions. If you forget to grant the View permission, users in that role do not see the Summary tab, so their permission to edit it is useless. In another example, it would not make sense to grant permission to post messages without also granting permission to read them.
Note: When a project or a request is added as a child to a Program, it possesses the same security policy as the parent object, i.e., the Program.