Data Protection
Data Protection supports client regulatory compliance with existing Data Protection regulations such as GDPR & CCPA. It provides Fenergo SaaS clients with the ability to define Data Retention periods by geography or jurisdiction. It includes the operational process for users to offboard jurisdictions from an entity and scope specific jurisdictions for targeted data deletion.
Data Protection Domain
Data Protection sits underneath the Policy domain within the Management menu.
There are four Permissions for Data Protection:
- Data Protection Access: This Permission allows a User to interact with and navigate into the Data Protection domain / screen.
- Data Protection Create: This Permission allows a User to create new Data Protection Regimes via the "+ ADD" button.
- Data Protection Edit: This Permission allows a User to edit existing Data Protection Regimes via the pencil icon.
- Data Protection Delete: This Permission allows a User to delete existing Data Protection Regimes via the trash-can icon.
From the Data Protection Regime page, the User can observe any existing Data Protection Regimes that have been configured. A Data Protection Regime will define the duration in months until the data deletion process can occur for a given Policy. These retention dates will be stored against a customer during an offboarding event and represent the date when their data is no longer required to be retained.
The User can also create additional Data Protection Regimes by selecting the "+ ADD" button. When viewing a Data Protection Regime from the grid view, the User will see the below:
- Name: the name of the given Data Protection Regime.
- Related Jurisdiction: The Related Jurisdiction (i.e. the Policy) that the Data Protection Regime is mapped to.
- Data Retention Period: the length of time defined until the scoped data is deleted, displayed in years & months.
The User can search for an existing Data Protection Regime from the Grid. The search bar here uses the "Name" and "Related Jurisdiction" fields to filter the configured Data Protection Regimes.
Intended use of the Client Offboarding Journey
Client Offboarding journeys are used to partially or fully 'Offboard' policies from clients in reflection of changes to their business relationship (for example products are offboarded, they have exited a given region/business unit etc). The offboarding journey will set the policies in-scope for offboarding to 'Offboarded' status, meaning that they will no longer be 'in-scope' for any future journeys and it will schedule the deletion of data for the calculated retention date (per associated Data Protection Regime) of each offboarded jurisdiction.
It may be useful to capture Reason for offboarding, in which case, this would be recommended to capture as 'Journey level' data outside of the Global policy (i.e. to review reason for partial offboarding, refer to the offboarding journey) or as Entity-level Data for Global Policy (i.e. the reason for full offboarding is captured on the Entity and visible on EPP).
Offboarding Journeys are not intended to capture broad updates to Entity data or to capture net-new policy requirements. Because Entity Verification results in policies becoming 'Offboarded', net-new requirements captured from a new version of a policy during an offboarding journey may not display on the EPP.
Following Full Offboarding, any subsequently launched 'Client' Journeys will fail unless 'Client Reonboarding' is completed first to bring Global policy back into scope. Without Global Policy, tasks with Target Entity 'Client' will appear empty with requirements in-scope. It is possible to maintain an Offboarded entity using journeys with Target Entity 'Related Party' - i.e. you can maintain them as an RP but not as a client.
If any journeys are in-progress when the client is FULLY offboarded, they will be automatically cancenlled. It's recommended to configure a Journey Launch Control rule to prevent Client Offboarding journeys from being launched while any journeys are in-progress. You can use a condition like "Current Journeys > In Progress Journey Types > Is defined" to prevent offboarding journeys from being launched when any journey types are in-progress.
"Client Offboarding" Journey Type Logic
Journey Types available from the "Launch New Journey" modal on the Entity Profile Page are filtered so that "Client Offboarding" will only be available when an Entity has Client Status (represented in the UI with the "Client" chip on the Entity Profile Page). The "Journey Type" dropdown within the "Launch New Journey" modal is now supported with filtering logic to only display the "Client Offboarding" Journey Type when the entity is a Client.
Configurators cannot change the name of the default "Client Offboarding" Journey Type within the "Journey Types" Reference Data list. Doing so will break the filtering logic for Journey Types.
In order for an entity to be recognized as a client, a "Client Onboarding" Journey must be completed for the entity OR the entity must be migrated with a "Client" Status. The "Client Onboarding" Journey must contain a "Verify Entity" Task. When this has been done, the User will be able to see the "Client Offboarding" Journey Type.
When the User selects the "Client Offboarding" Journey Type, a new dropdown will appear beneath the "Journey Types" field called "Jurisdictions". This dropdown will display the Jurisdictions to offboard based on the Jurisdiction meeting both of the below criteria:
- The Jurisdiction (i.e. Policy) has a configured Data Protection Regime.
- The Jurisdiction has been scoped in a Journey for that Entity.
The User can choose to offboard a single or multiple non-Global Policies by multi-selecting the relevant Jurisdictions. If the User selects the "Global" Jurisdiction, it will initiate a full offboarding for the entity and all scoped Jurisdictions for the entity will be offboarded in the subsequent Client Offboarding Journey.
Partial Offboarding
When the User selects the "Client Offboarding" Journey Type, they can select a single or multiple non-Global Jurisdictions to be offboarded. The Partial Offboarding capability allows a Client to offboard specific Jurisdiction[s]. When a Jurisdiction or Jurisdictions has been selected in the "Jurisdictions" dropdown - and the User completes the subsequent "Client Offboarding" Journey - that Jurisdiction will no longer be picked up in the logic engine for future Journeys for that Entity.
Once the User has selected the relevant non-Global Jurisdictions to be offboarded, the Client Offboarding Journey for the selected Jurisdiction[s] will commence. After completion of the "Complete Client Offboarding" Task, any in-flight Journeys that contain the scoped Policies will be cancelled. These cancelled Journeys will be re-launched after the Client Offboarding Journey is completed with the offboarded Jurisdiction[s] no longer being scoped.
Once a Jurisdiction has been partially offboarded, it will no longer appear in the "Jurisdictions" dropdown when launching future Client Offboarding Journeys within the "Launch New Journey" modal.
When a Partial Offboarding has been completed and the selected Jurisdictions offboarded, the "Client" chip will remain on the Entity Profile Page. This is because the Client has only decided to offboard specific Jurisdictions.
Full Offboarding
A Client can select the "Global" Policy within the "Jurisdictions" dropdown when launching a Client Offboarding Journey to initiate a Full Offboarding. A Full Offboarding will allow for the Data Deletion process to begin when the Data Retention Date is reached, which will initiate the deletion of all Data, Documents, Related Parties and Data Group information across all Policies for the Entity in question. It effectively allows the User to fully exit a Client from Fenergo SaaS. As called out previously, the Offboarding of "Global" will Offboard all other Policies in tandem.
The process to initiate a Full Offboarding is the same as to initiate a Partial Offboarding. A User selects "Global (Full Offboarding)" from the Jurisdictions dropdown and a Client Offboarding Journey is kicked off. Once the "Complete Client Offboarding" Task type has executed, the Data Retention Date is set, and on this date the Data Deletion process will kick off.
Additionally, with Full Offboarding the "Client" chip will be removed from the Entity Profile Page and be replaced with a new chip of "Offboarded Client". This will allow system Users to identify an Offboarded Entity within the Fenergo SaaS UI that is scheduled for Data Deletion.
Offboarded Client - Related Party Maintenance
When a 'Client' entity has been fully offboarded, they can also be a Related Party that's associated to other client or non-client entities (for example as a Beneficial Owner or CEO). The Related Party association may pre-exist Offboarding or may come later.
As a Related Party, their Related Party data can be maintained via the Related Parties task. In the event that a journey needs to be launched to manage their 'Related Party' data in isolation from other entities, there are some limitations because a fully offboarded 'Client' has all policies (including Global) set out of scope. A journey can be used specifically for Related Party maintenance using the following tasks configured with 'Target Entity' Related Party:
- Data and Document Tasks (Data, Documents, Data & Documents)
- Data Review Task
- Proposed Changes Task
The journey would need to use 'Verify Entity' to verify changes to the Related Party Entity - this is because it verifies the data of the journeys root entity.
Conflict Resolution is not currently supported for journeys on Offboarded Client Related Parties.
If an offboarded client is scheduled for deletion, when the retention date is reached the deletion process will currently include their Related Party data i.e. full deletion of the entire record.
We are working on an enhancement to explicitly protect the RP data by only deleting their client data. The user guide will be updated when this enhancement is available
Automatic Offboarding
While the Global policy is in-scope by default, other jurisdictions are typically brought into scope when their configured conditions are met. Given the potential complexity of Policy Scoping conditions, a Policy could have been become in-scope for an entity during the initial Onboarding, but conditions may no longer be applicable after the latest Periodic Review (e.g. from a change in Products or entity data). Users will benefit from system automation to ensure that conditionally triggered Policies are offboarded correctly when no longer applicable for the entity so that the Data Retention information can be recorded for the Policy.
The system has the ability to automatically initiate a Partial Offboarding Journey for a policy jurisdiction that was brought into in-scope but where the scoping conditions are no longer met. As the default Policy, 'Global' will always remain in-scope until a 'Full Offboarding' journey has been completed.
Within the Data Protection configuration page, there is a new toggle, Enable Automatic Offboarding When Policy Conditions No Longer Met. During the Verify Entity task, when this toggle is enabled, the system will automatically initiate an Offboarding Journey applicable for all Policies that are 'in-scope' for the entity, but where the scoping conditions are no longer being met.
Configuration Exchange
Configuration Exchange has been enhanced to allow clients to promote the "Enable Automatic Offboarding When Policy Conditions No Longer Met" toggle setting across environments. From Configuration Exchange, the specific toggle can be located under the domain Feature Settings and the user can select the specific toggle they want to import.
Offboarding journeys cannot be triggered via launchpad tasks. This is due to the fact that offboarding journeys have specific jurisdictional context which is not passed via lauchpad tasks.
Re-Onboarding
Clients with offboarded policies are eligible to launch a Re-Onboarding journey to specifically transition selected policies from 'Offboarded' status to 'In-Scope' status. When an Entity has been fully offboarded, each policy for needs to be explicitly selected for re-onboarding - global must be re-onboarded (mandatory and pre-selected) and other policies can be optionally selected. For partially offboarded entities, users can select one or more policies to re-onboard.
The Re-onboarding journey is configured using the Journey builder. The journey name can be configured to a client's preferences (e.g. "Client Re-Onboarding" or "Client Reonboarding"), however the journey type must be set to "Client ReOnboarding".
"Complete Client ReOnboarding" is the only mandatory task to required to successfully re-onboard a client or selected policy jurisdictions. This is a system task that will execute the transition of selected policies from 'Offboarded' to 'In-Scope' and verifies this change to Entity Data (Verify Entity task is not required). It may be appropriate to configure an approval task prior to this step.
No policy driven input tasks should be configured within a 'Client ReOnboarding' journey (i.e. while in-scope policies are in flux). The Journey Launchpad task can be configured to follow "Complete Client ReOnboarding" if any further maintenance activities are required. With this sequence jurisdictions are successfully re-onboarded before any data task is triggereed, ensuring the in-scope policies are correct.
Configuring Data Protection
Configuration of Data Protection Regimes
When the User selects the "+ ADD" button, they will be brought to the Data Protection Editor screen. Here, the User will be presented with three fields: Data Protection Regime Name, Related Jurisdiction and Duration in Months. All three fields are mandatory for the creation of a Data Protection Regime. Although the Duration in Months is inputted as a total number of months (e.g. 78), it renders in the Data Protection Regime page as Years and Months (6 years, 6 months).
The "Related Jurisdiction" dropdown will display all configured Policies within the tenant. A Policy does not need to be in a published state for a User to be able to create a Data Protection Regime. This allows for a User to create a Data Protection Regime for a Policy that is still in a "Draft" status.
The "Duration in Months" field enables the User to set the amount of months until the Data Deletion process will kick-off. It is set to support a maximum of 50 years (600 months).
Data Protection Regimes are versionless, meaning that once the User hits the "Save" button during the configuration of their Data Protection Regime, that Regime becomes the default Regime for the combination of values the User has inputted for Name, Related Jurisdiction and Duration of Months. Additionally, there is no "Submit for Approval" process. Once the User hits "Save", the Data Protection Regime can be utilised within the tenant.
Finally, there is currently no validation logic on Data Protection Regimes. A User can create additional Data Protection Regimes for a given Policy without any validation errors. If this scenario occurs whereby a User has configured multiple Data Protection Regimes against a single Policy, the "Complete Client Offboarding" Task type will fail. A User must therefore ensure that there is only one Data Protection Regime configured per Policy. We will be looking to introduce validation logic in MVP+ on the Data Protection Regime Editor screen to prevent this scenario from occurring.
Note: A Data Protection Regime must be configured for a Policy in order for Offboarding and Re-Onboarding functionality to operate correctly for that Policy.
Client Offboarding Journey Configuration
A Client Offboarding Journey must have the new "Complete Client Offboarding" Task type as the final activity in order for the Partial or Global offboarding to successfully capture the Data Retention information for the date (note: this task also contains the Verify Entity process and the Verify Entity task is not required and should not be added).
