Introduction 

This section describes how ShareDo:

• Authenticates users,
• Authorises users to perform specific functions,
• Audits case activities,
• and deals with specific details related to GDPR compliance.

At an application level, ShareDo’s security is based on standard protocols such as OAuth, OpenID, and HTTPS.

ShareDo then tracks, audits and correlates user access tokens across all layers of its architecture.

Introduction to compliance and security in ShareDo

View the playlist on YouTube: Platform Deep Dive - ShareDoShow.

Identity Providers

Authentication can be supported by:

• ShareDo's in-built forms-based authentication with configurable security policies.
• Active directory via our WINFS bridge.
• OpenID providers such as:
  • Azure Active Directory
  • Social logins (X (formallyTwitter), Facebook, LinkedIn)

Any or all of these can be enabled on the same ShareDo instance, facilitating, for example:

• Internal users logging on using their O365 account.
• External users logging on using a forms-based login.

OAuth Access Delegation

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

ShareDo uses OAuth extensively to grant secure access to both user-centric and application-to-application clients. All of ShareDo’s APIs require tokens in order to access them.

Examples of common client applications include:

• ShareDo Word Add-ins.
• External workflow engines.
• External client applications that require access to ShareDo APIs.

Where ShareDo relies on external services, these can be added as linked services.

Authorisation

ShareDo provides a comprehensive role-based permission model for authorisation that allocates permission sets to teams or users.

Typically, you define Access Control teams (which are similar to Windows) and then assign permission sets to those teams.

Whilst this defines the global permissions, in addition, through the case roles, you can define fine-grained permissions for every case with access to cases and their functionality being controlled through a team or user's role on that case.

Security Barriers

Security barriers can be created within the work type structure (e.g., contract, policy/statement of work) or at the individual case or role levels.

Security barriers facilitate the creation/management of specific ‘allow’ or ‘deny’ barriers that are enforced and honoured for the case, including case artefacts. These security barriers can be applied to a ‘role’, ‘team’ or ‘user’ level.

An example set of security barriers include:

• Ensure access is restricted to members of a specific team.
• Ensure the role assignment is restricted to users with valid attributes (e.g., qualified lawyers).
• Ensure access is explicitly denied to members of a specific team (e.g., client contacts UK).

Security barriers can also be enforced automatically as part of the matter intake process or initial review phases. This is enforced via security SmartPlans that fire in response to requests from the intake process.

ODS Walls

Within the ODS Area of ShareDo, we maintain a master list of users, people, organisations and teams.

These master lists can be subdivided in a number of ways, including the following:

• Configuration of different searches.
• ODS Types.

However, there are various circumstances where we wish to create specific sets of ODS Entities to restrict the available entities that are available for different users. We describe these restrictions as ODS Information Walls.

Examples of the use of walls include

• Restricting the list of users so that a client user can only see the users who are working on their account.
• Restricting the list of organisations so that a client user can only see the organisations that they have as counterparties.
• Restricting the list of users available for task allocation to only those that are in your business unit. For example, the real estate team would only see real estate users.

Like most ShareDo feature enhancements, ODS Walls are optional and are controlled by the feature framework via the "ODS Information Walls" feature.

Within this feature, you specify two elements:

• The default wall applied to all ODS Entities that are created. Access to this wall will typically be given to system administrators.
• The work types that should be used to default "walls" for specific processing scenarios; this is typically statements of work.

Once enabled with the Admin area, you will then be able to maintain walls.

A wall contains various ODS entities with permissions to read or update these entities being granted to security teams. Walls can be assigned in several ways:

• Users can ODS Entities manually, either singularly or as a bulk action.
• When a new ODS Entity is created, it can be assigned a Wall by virtue of the default system walls – these are defined in the global feature.
• By any default, walls that are defined in the work item hierarchy.

Information Walls restrict user's actions in the following ways:

• When a user searches ODS Entities, the list of results returned is restricted by the user's membership of Walls and the Read permission.
• When a user attempts to update an ODS Entity their ability is restricted by the user's membership of Walls and the Update permission.

Encryption

ShareDo supports the encryption of sensitive data at rest. An example of this is when we are required to store credentials to access external resources. Encryption of data in transit is through HTTPS. When operating in the ShareDo SaaS environment, the virtual machines in Azure are deployed with disk encryption, and all backups taken and stored are encrypted.

Within our SaaS environment, we also support BYOK if required.

Auditing

ShareDo maintains two ‘audit’ streams. The first is a forensic one—e.g. each and every touch-point, whether this be data changes, task updates, etc. This record contains the date & time, user, and change made.

The second is a case chronology. This is a user-friendly graphically rich history of key case steps and is designed for an end-user (internal or external) to understand the ‘case-related events’ that have occurred on the case.

Additionally, the user context is captured in each log message, providing an even finer-grained audit. Actions taken by users are recorded in these audit logs, which are also available in reporting.

Personal Identifiable Information Management

ShareDo provides a number of features to facilitate the secure management of PII.

• Access to PII is only granted based on application permission; users cannot see this information without this permission.
• People can be placed into ODS Security Groups, and users are then only granted access to specific sets of contact records.
• Access to PII information is audited; these audit logs can then be monitored for unusual activity.
• Access to a subset of information, such as bank details, can be controlled explicitly.

Subject Access Requests

ShareDo provides a 360-degree view of every participant's interaction with the system, ensuring you have a comprehensive picture of subject access requests.

These views, together with the ability to search across all work, let you facilitate subject access requests either:

• Manually
• Via a report
• Or a document template

Data Retention & Anonymisation

During the lifecycle of your case management system, there will be times when you want to have data either permanently deleted or anonymised. Example use cases include:

• When you are in a configuration environment, you may want to delete all work type instance data.
• As part of data retention policies or following a “Right to be forgotten” request, you wish to remove personally identifiable data.

To facilitate these requests, shared provides two different features.

Data Anonymiser

This administration tool is used when:

• Moving production data between environments.
• As part of data retention policies.

The advantage of the data anonymiser tool is that it does not remove data from the system but instead obfuscates it; hence, historical reporting is not affected in any way.

The data anonymiser tool affects both Work Item (e.g. Matters) and ODS (e.g. People) related data.

“Destructive” Tool

This administration tool permanently deletes data associated with a work type; as the name suggests, this tool should not be used lightly, as all data is removed in its entirety.

Data Retention Policies

Since ShareDo does not store documents, it is typically the case that data retention policies are defined in the document management system, and these policies are integrated with the anonymiser or destructive tools.

Likewise, you can also configure ShareDo workflows to perform these policies on your behalf if required. As discussed, we recommend using the anonymiser tool in your retention policies wherever possible.