A valid security policy consists of one or more security templates that define the security for a document based on the document's version state. Depending on your site and security settings, you can assign a security policy to a document in several places:
Document version states are related to document versioning. As a document progresses through cycles of minor version to major version, the document is always in one of four possible states. The state names are Released, In Process, Reservation, and Superseded. The security policy defines the automatic security applied to the document as it changes from one state to another as the document is checked in, checked out, promoted, or demoted. The security policy is a set of security templates that define the security for a specific version state. For more information about document versioning, see Manage document versioning.
As an example, you might have a group of users who have access rights to document minor versions (that is, documents that are in the In Process state). When the document is approved for release to a larger audience (set to the Released state), you would like to make it automatically available to a different group of users. You can create a security policy that defines which users have access to the document at each state. You can then apply this security policy to specific documents.
NOTE If each versioning state does not have its own security template, then the existing security from the last state is propagated to the next state. For example, if a security template has been created for only the Released version state, and you later demote a document from a major version (Released) to a minor version, the security permissions from the Released version template are preserved in the minor version. For best results, each versioning state should have an appropriate security template.
To open and use the wizard
You must have access to the Advanced Tools to create or modify a security policy.