The following topics are available:

iManage Work Object Security

The iManage Work security model offers a versatile and flexible means of managing security across all workspaces, containers, and documents. Each item has a series of security settings. Precise refinements can be made on each security settings, providing an increasing amount of security and specifying exact access for any user or group.

For example, an editor's group may be added to an item that allows those group members to edit documents. All other users can be excluded entirely, perhaps for conflict of interest reasons, from viewing documents. Additional versatility is provided by even being able to exclude specific members of that editor's group from editing or viewing a specific document.

Every item has the following security characteristics:

Security Policy Manager (SPM) access limitations
default security
access permission
library and global role restrictions
security model and groups membership conflict resolution

The bottom line result of the combinations from all the sources is called the effective security.

iManage Security Policy Manager

iManage Security Policy Manager (SPM) is an optional add-on application for iManage Work that manages security. This application allows for more detailed control, audit, and reporting of security. It is a security layer before iManage Work's access permissions, and provide additional control including new security features. It is designed to work with iManage Work but is a separate application. iManage Work cannot change or set SPM values. SPM can also be applied to other applications including iManage Records Manager and the Microsoft Windows file system. Contact iManage for additional information about the application.

SPM introduces two conditions that apply first when determining access permissions for items, which includes containers (such as workspaces, folders, matters, clients, and cases) and documents: Open access, and restricted access.

Open access. This permission allows the selected users and groups access to those items. However, normal iManage Work access permissions still apply. For example, SPM may grant a user open access to a matter, but iManage Work does not allow access for that user on that matter. The combined result is that the user has no access.
Restricted access. This permission denies the selected users or group access to the items. Restricted access permission is a convenient method to limit access without having to modify iManage Work access permissions, and includes avoiding refile events. For example, SPM assigns a user restricted access to a matter. Regardless of the iManage Work access permission, even if the user is granted explicit iManage Work access permission, the user will have no access to the matter.

The remaining discussion assumes a user or group has open access to an item.

Default security

The default security value is the basic security level and is inherent at all times. A value must to be assigned when a container is created, or a document is created or initially uploaded. This may be changed later by someone with proper permissions. See Changing Security.

The following are the four default security values:

Security value	For Containers	For Documents and emails
Private	Only the the user who created the container (also called the owner) can access it. Other users or groups can be explicitly granted access permission (see Access permission) and will have access only to the limit allowed by those permissions. An item that is private to a user or group will only be accessible to them.	Only the the user who created the document (called the owner) or a user that the owner allows to edit it (called the operator) can access the document. Other users or groups can be explicitly granted access permission (see Access permission) and will have access only to the limit allowed by those permissions.
View	All users and groups can access the container's contents but cannot add or remove items from the container, or modify, delete, or move documents.	All users and groups can view the document, but cannot modify, delete, or move documents. The user who created the document (called the owner) or a user that the owner allows to edit it (called the operator) can modify the document.
Public	All users and groups can access the container's contents. They can add, delete, and move items into or from the container.	All users and groups can view or modify the document. However, they cannot delete or move the document. The user who created the document (called the owner) or a user that the owner allows to edit it (called the operator) can delete or move the document.
Inherited	Indicates that the container or tab does not have an explicit default security of its own, and instead assumes the default security and access permission of its parent container. iManage Work calculates this permission level automatically. A best practice is that only the highest-level container, typically the matter, is explicitly assigned an access level, and that all other containers be assigned Inherited security.	Indicates that the document does not have an explicit default security of its own, and instead assumes the default security and access permission of its parent container. iManage Work calculates this permission level automatically. A best practice is that only the highest-level container, typically the matter, is explicitly assigned an access level, and that all other containers, documents, and emails be assigned Inherited security.

Access permission

Access permission is an optional security value a user can have for a container, document, and email. Access permission refers specifically to user's granted access to an object. These include the following values. A user or group is not required to have an access permission. The access permission may be more or less restrictive than the object's default security. If specified, it overrides the default security. If not specified, the item's default security value is used.

Access permission	For containers	For documents and emails
No Access	A user or group cannot view the contents of a container, or search for documents inside of it.	A user or group cannot view the contents of a document or email, search for the item, or see the item in the iManage Work browser.
Read	A user or group can view the contents of a container or view the document, but cannot add, edit, or remove items.	A user or group can view the contents of a document or email, but cannot add, edit, or remove content.
Read/Write	A user or group can view, add, or remove the contents of a container or view the document, but cannot delete or move the container itself or change the container’s security.	A user or group can view, add, and edit the contents of a document or email. They cannot delete and move the item, or change the security or metadata properties of the item.
Full Access	A user or group can view, add, or remove the contents of a container or view the document, but can also remove or move the container itself and change the container’s security. This is the same as having Owner permissions with the container.	A user or group can view, add, or edit the contents of a document or email. They can delete and move the item, and change the security or metadata properties of the item.

Library and global roles restrictions

A library role is a named set of library-level privileges. Library roles are assigned to individual users, and each user must have a role, even if only the default role automatically to each new user. Some library-level privileges affect access to containers and documents. For example, if a container's default security is full access, a user is explicitly granted full access, which includes being able to delete items. However, if the user's library-level role privilege Delete is not granted, the user will not be able to delete items.

The following library-level privileges may affect user access.

Documents

Value	Description
Import/Create	Allows users to import/create documents.
Checkout Documents	Allows users to check in and check out of documents in the library to which the user has access.
Unlock Documents	Allows users to unlock documents that are checked out or currently in use.This is basically a forced check in. Any changes to the document will not be saved back to the library. The document remains on the checked out computer, along with any changes. Care must be taken in this case. The document does remain on the checked out computer and may represent a security issue.
Delete	Allows users to delete documents and containers from libraries to which the user has access. For some iManage Work environments, the document will be moved to the user's Trash and is recoverable. For other environments, if Trash is not enabled, the document will be deleted permanently.
View for NRTADMINs	Allows NRTADMINs to view the contents of private documents when they do not have explicit access permission to the documents. In general, this should remain disabled to ensure the security of sensitive information. NRTADMINs will still be able to search for private documents regardless of this setting.

Folders and tabs

Value

Description

Create Public Folder

Allows users to create a new public project folder.

The user can still create private folders or subfolders with security inherited from the parent folder. Allow users to create folders with public or view default security. When this is disabled, users can still create private folders. Folder creation is also subject to the user's security permissions in the individual workspace when trying to create a folder.

Create Public Searches

Allows users to save public searches and mark them as public.

Allows users to create search folders public or view default security. When this is disabled, users can still create private search folders. Search folder creation is also subjected to the user's security permissions in the individual workspace when trying to create a search folder.

Workspaces

Value	Description
Create private Workspaces	Allows users to create private workspaces.
Create public Workspaces	Allows users to create public workspaces.
Delete Workspaces	Allows users to delete workspaces. Workspaces and their containers will be permanently deleted and must be re-created in the event of accidental deletion. The workspace contents will be moved to Trash for cloud customers and for on-premises customers may be permanently deleted if Trash is not enabled.

Changing Security

Only a user or group with Full Access to that item can change security levels. This includes having access permission of Full Access, or being an item's operator (also called an owner), who by default has Full Access for that item.

Security can be changed in the following ways:

iManage Security Policy Manager: iManage Security Policy Manager (SPM) can set Open or Restricted access for users and groups. This access does not change the iManage Work system's settings but instead is a security layer that is checked before attempting to access iManage Work.

Direct assignment: The user can change the default security directly to an item. In the property panel, or at the time the document is created or initially uploaded, a properties panel displays. If the user has the proper level of permissions, they can change the default security.

Refile: Refile is an iManage Work Windows service that automatically updates container's and document's security. This includes the collective default security and access permission, and metadata for each item. If a parent container has its security and/or properties changed, this service automatically propagates those changes downward through all the children containers and their documents. For example, if a workspace changed its default security to View, that new default security is automatically changed for all children containers with a default security of Inherited.

Security Model

The iManage Work security model resolves access conflicts if a user belongs to two or more groups. The model is called hybrid security. The hybrid model grants:

Access using the most permissive access levels from among the available groups.
Except if a denial exists. The denial take precedence over any access grant.

For example, a user is a member of both Group 1 and Group 2, and is trying to access Container A.

Source	Access level
Container A	Default security is View.
Group 1	View
Group 2	Read/write

The hybrid model grants access from the most permissive access levels. Here, Group 2 offers Read/write, so the user is granted Read/write access to Container A.

For another example, a user is a member of both Group 1 and Group 2, and is trying to access Container A.

Source	Access level
Container A	Default security is View.
Group 1	No access
Group 2	Read/write

The hybrid model grants access from the most permissive access levels except if there is a denial among those. Here, Group 1 offers No access, so the user is not granted access to Container A.

Conflicts from different groups

The following matrix determines the net result of conflicts caused by a user being in two or more groups.

First, determine the group with the most restrictive access in the first column. This means the group either has No Access, or any other access.
Second, determine the group with the least restrictive access in the second column.
Third, using the single row that matches the first and second access levels, cross index with the user's access rights. The result is the user's access level from groups.

Hybrid security model
		The user's access permission
Most Restrictive Group Access Rights	Least Restrictive Group Access Rights	No Access	View	Unspecified	Read/Write	Full Access	Owner
No Access	(Any access)	None	None	None	None	None	Full
Any access other than No Access	View	None	View	View	Read/Write	Full	Full
Any access other than No Access	Unspecified	None	View	Default	Read/Write	Full	Full
Any access other than No Access	Read/Write	None	Read/Write	Read/Write	Read/Write	Full	Full
Any access other than No Access	Full	None	Full	Full	Full	Full	Full

Unspecified access permission indicates that access permissions have not been defined for the item. The item may not have any default values, or all existing values have been removed.

Examples

If the user is part of a group that offers the most restrictive access of No Access, regardless of any other access permissions (except for the owner who always has full access) the user will have no access.

If the user is part of a group that offers the most restrictive access of View, another group offers the least restrictive of Read/Write, and the user has access permission of View, the effective security is Read/Write. The security model resolves the different access levels as the least restrictive, here as Read/Write.

Effective Security

Effective Security is the net result of a combination of an item's:

Security Policy Manager access level
default security
access permission
roles restrictions
conflicts among groups the user belongs to
the security model being used

If an item has only default security, all users will be limited to that security level. For example, if the default security is view, then all users have view access to it.

Users may have access permission different than the default security. Continuing the example, user Sandhya needs to be prohibited from viewing a container's contents, perhaps due to a conflict of interest. In this case, she would be assigned an access permission of no access. After that, Sandhya will not be able view contents inside the container. If the access permission of no access were applied to a document, she could not be able to read it, and is even being prohibited from seeing it in a container.

The effective security in these two cases is straightforward. The access permission always has priority. In the example above, no access has priority over the view default security.

However, access can also be provided through groups.

If the user is provided access from only one group (and with no explicit security otherwise), the group's access priority is over the default security. For example, the user Nicole is part of a group with read/write access to a container with view default security. Nicole has the effective security of read/write. This is granted from the group having priority over the default security.

If a user is a member of at least two groups, and some of the groups have different access levels, an access level conflict occurs. The resolution depends on the security model being used.

Owner/Author

The owner, also called the author, is a status that is automatically assigned to the user who creates a new document or initially uploads a document. That user has Full Access privileges to the document, regardless of other access restrictions. A document can have only one owner at time, and the current owner can assign ownership to another user.

Operator

The operator of a document is a user who has made changes to the document. It does not grant ownership to the document, but the operator has Full Access to the document.

“Author” is the field used to give the security over-riding ‘owner’ role of the document. The author will always have permission to view and edit the file, and will have full access. The author is automatically set to the person who uploaded the original file, unless they used ‘advanced upload’ to deliberately set another author.

“Operator” is determined by the last user to make edits, and is useful to track who has worked on a file. In cases where there is a team, or when the user is working on behalf of another user, it is a means to separate who is doing the work from the user responsible for the file.

ACLs

An ACL is an access control list used by iManage Work to mark access permission for documents and containers. It is an internal mechanism and not used directly by users or system administrators. However, users may refer to them to refer to the combination of default security, access levels, and metadata for an item. A child container can be said to "inherit its parent's ACL," meaning the default security and all users and groups in that container access permission from the parent.

Refile

iManage Refile Service is an optional service that propagates security and property field changes throughout a library in a background operation. This is not part of an item's effective security but can affect an item's security values.

The propagation begins with well defined events, such as changing the security on a container, or changing a property field value. For example, changing the default security of a container may trigger a refile event. Once an event is initiated, the propagation is automatic and does not require confirmation from the user. During the propagation, items are updated according to explicit rules. The refile processes downward, through each subfolder and is recursive through all subfolders. For example, a change at the matter level may affect all items within that matter. If the event occurs in a child folder within that matter, only that child folder and items contained by it, including other folders, may be affected. The propagation never transverses to a higher container. The operation occurs in the background and is not noticeable by users. They can continue to use the application. However, it may take a few minutes for the refile service to propagate these changes through the entire container hierarchy.

Encryption

Data encryption is a security measure that prevents visibility of documents in the case of unauthorized access or theft. This is not part of an item's effective security but can affect an item's security values.

Also called data at rest encryption, the documents are encrypted when they are not being used. In the event they are compromised, such as by theft, wrongful disclosure, or unauthorized access (including internal unauthorized access), the files are encrypted, and therefore, unreadable. When an authorized user accesses a document (such as through editing or viewing within a client application), the document is decrypted and will be able to be read or edited normally. When the user is done with it, it is returned to its encrypted state. This encryption is compliant to HIPAA and other American statutes protecting sensitive information.

A document or email will be encrypted if at least one the following conditions is applicable, even if other conditions specify not to enable encryption. More than one condition has no additional effect.

iManage Work automatically encrypts data-at-rest; enryption cannot be disabled.

Condition	For more information:
The document class or subclass sets HIPAA-compliant encryption to Yes.	Classes / Subclasses
A custom field (such as custom1 or custom3) specifies document encryption. Any document with that custom field in its profile will be encrypted.	Custom Fields
The file type specifies document encryption.	File Types