Skip to Content
Product Information
Author's profile photo Ruchi Tandon

All you need to know about SAP’s Russia Data Residency Solution!!!

SAP is committed to ensuring our HR Solution supports compliance and allows companies to meet all of their local and international statutory obligations. One such law that we responded to with rapid pace was the Russia Data Privacy Legislation (RPDL), which came into effect in September 2015.

Here is all you need to know about the Legislation and our solution

What is the Russia Data Residency Law?
Russia Data Privacy Legislation requires companies with employees in Russia to manage master personal information related to their employees in a Russian Data Center.
The Legislation creates a new obligation to manage master personal data of Russian citizens in Russia. This means that companies located outside of Russia, processing data of Russian citizens “will be forced to place their servers within Russia if they plan to continue making business in the market.” The exact purview of the localization law is somewhat ambiguous, but RPDL data operators to ensure that the recording, systemization, accumulation, storage, revision (updating and amending), and extraction of personal data of Russian employees is stored on servers located in Russia.
What is the SAP SuccessFactors Solution?
SAP has established a data center in Russia to enable customers to be compliant with this law. Customers who wants to use our Russia Data Privacy solution will each have their own private database schema created in the Russian Data Center (RDC). This instance will house the personally identifiable information (PII) of their Russian employees. This can be reported on using an MDF record called ‘Person Data Residency Log’ that resides in the same Global Data Center (GDC) as the customer’s production Employee Central instance. This log stores a date and time stamp showing when the information was written to the Russia Data Center and to the Global Data Center. It also includes other information like employee ID, type of action performed, and object modified so organizations can report on type and time of action performed on PII of Russian employee.
When an entry/update is made to PII for employees whose legal entity country = ‘RUS’, all of their PII is first written to the Russian Data Center (DC) and then it is written to the global data center and an entry is made in the Person Data Residency Log Record. This solution has been available to customers since Q4 2015.

The following Employee Central entities are supported as of Q1 2017:
• Person (Date of Birth, Country of Birth)
• Personal (Marital Status, Gender, Nationality)
• Global Information
• Email Information
• Phone Information
• Social Account Information
• National ID Card Information
• Address Information
• Work Permit Information
• Emergency Contact Information
• Dependents Information
• EC Workflow Entity
• Payment Information
• Background Information (Employee Profile on Metadata Framework)
• Person Data Workflow
• Attachment Support
The date and time of updates made in the Russia Data Center and global data center are recorded in the Metadata Framework (MDF) object Person Data Residency Log Record and can be reported on using our advanced reporting tool. This solution provides transparency to the administrator and end user and enables organizations to be compliant with the Russian Privacy Data Law (RPDL).

Implementing the Solution

Our solution not only provides you with the framework that allow you to be compliant with the law, but implementing it is also a breeze and can be achieved in 4 easy steps. Here are the steps to implement the solution:

Step 1: Enable Provisioning Settings

Have your implementation partner or SAP SuccessFactors Support activate the “Reside PII in Russia” flag in Provisioning and select “Enable API Based Solution” flag.

Following are the URLs for preview and production environments:

Preview Instances: https://drspreviewdc18int.dc18.saas.sap.corp
Production Instances: https://drsproddc18-int.dc18.saas.sap.corp

The API Secret key should be provided during the Provisioning setup. It is used for validating the API call specific to the company instance.

Enable the attachment sync, if your customer plans on capturing attachments for personal Information.

Starting with the Q2 2017 release, a schema will automatically be created in Russian DC when you enable the switch in provisioning. If you encounter an error, please raise an SRSD ticket to create a schema in the Russian Data Center.

Step 2: Granting Security Permissions

Once you have enabled the Provisioning settings you can secure the Person Data Residency Log using the Configure Object Definition, and grant permission for the object to the required roles using the Miscellaneous Permissions section of the security role.
Step 3: Schedule the sync job in Provisioning to run daily in the customer’s environment.

The job will create or update the PII data in the Russia Data Center by reading PII data from the Global Data Center for the scenarios mentioned below:

1. Transfer of an Employee to Russia.
2. Concurrent/Global Assignment to Russia.
3. Future dated transaction where the legal entity is set to Russian Legal entity in future.
Step 4: Create a custom report using Advanced Reporting Tool

The data can be reported on by configuring and generating a custom ODS report using the Person Data Residency Log record.

The log captures following information.
• Person ID
• Date of Change
• Legal Entity of the Employee
• Timestamp of change in Russian data center
• Timestamp of change in global data center
• Information whether it was an insert or update or delete
• Changed entity (EC object level)
• Entity Identifiers to uniquely identify record that was changed
The report can be generated by applying one or more selection criteria:
• Date range of change date
• Legal entity of the employee.
• One or multiple employee IDs
• Object type changed, etc.

Scenarios Covered
New Hire via the User Interface:
If the Russian Legal Entity (country=RUS) is chosen from job info during a new hire, then all of the person-related entities will be synced to the Russian Data Center.

New Hire via Imports and API:
Customers have to follow a specific import sequence to retrieve the company country to ensure the PII data of Russian employees is written to the Russia Data Center. The legal entity is determined with Job Info imports, which must be completed prior to importing any PII data. Here is the new order of imports that should be followed:

• Basic User Import (no personal data is synced to the Russian Data Center).
• Employment Import
• Job Info Imports (this provides the country of company).
• Any of the person-related entities imports will be synced to the Russian Data Center.

If a customer fails to follow this sequence, they will have to perform a full purge for all person-related entities. The same process has to be followed for API upserts via Boomi or any other interface. Zip Upload is not applicable here as the order of imports is hard coded in the system.

Workflow:
If the legal entity from Job info is Russia, then all person-related entities will be synced to Russian Data Center upon approval of the new hire workflow.

ESS/MSS on Person-Related Entities:
If an ESS/MSS action is taken for any of the person-related entities after a hire, and if the job info Legal Entity is Russia, then data will be synced to the Russian Data Center (Insert/Update/Delete).

Legal Entity Change/ Global Assignment/ Concurrent Job:
If a global assignment/concurrent job or an international transfer is added for an employee in Russia then the PII record for the employee will be synced using the PII Job Sync that can be run on a daily basis.

Future Dated Records:
Future-dated changes are also synced to the Russian Data Center

Terminate/Rehire:

No insert/update/delete happens on person-related entities for an employee when that employee is terminated. This means no special handling is required for terminations. If any personal information is changed for a rehire where the job info country is Russia, then then it will be synced to the Russian Data Center.

Conclusion:

This makes our solution very robust to provide a framework to secure all personal information that we capture for employees in Russia in our SAP SuccessFactors solutions.

Please Note:

Data Residency feature is not required to be enabled for the customers who have their global instance in Russia(DC18). Because the personal data of the Russian employees will be directly stored in the global instance which is located in Russia that makes compliant with Russian data privacy law”.

Please refer to the following guides for implementing the solution

 

About Russian Data Residency Solution Guide

EC Implementation guide for Russian Data Center

Russian Data Residency Test Cases

 

Update: April 2021 – Recruiting Released 1H 2020

Implementation Guide for Russia Data Residency Solution for Recruiting

 

 

Assigned Tags

      36 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Andy Wei
      Andy Wei

      great blog with detailed implementation steps!!

      Author's profile photo Jarret Pazahanick
      Jarret Pazahanick

      Nice job with this Ruchi and great to see SAP/SuccessFactors be so responsive to changing country dynamics.  Don't think SuccessFactors gets enough credit for how global their solution really is compared to some of their HR Technology cloud competitors.

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Thanks so much Jarret and I agree we don't get enough credit as a lot of customers aren't even aware that a solution even exists for this.

       

      Author's profile photo Harshal Soni
      Harshal Soni

      Hello Ruchi,

      Very detailed Blog. Thank you!

      I believe the onus still falls on SAP SuccessFactors and SI's to market these offerings & solutions.

      This is not an excuse but the fact is that Customers do not have enough time and resources to research each and every solution.

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Thank you Harshal. Yes agreed.

       

      Author's profile photo Former Member
      Former Member

      We certainly know about it now 🙂

      Thank you very much for the very informative write-up.

       

      Author's profile photo Bruce Hillier
      Bruce Hillier

      Great blog Ruchi - I'll be forwarding to my colleagues as I think its a nice hidden gem.

      Bruce

       

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Thank you Bruce!!!

       

      Author's profile photo Francois Maass
      Francois Maass

      Hello Ruchi

      Great blog, really valuable information!

      I'm wondering if you've managed to create the ODS report for the Residency Log information? We have this feature enabled with the permissions assigned and updated, however I cannot seem to find the residency log for reporting in the reporting side.

      Any tips would be highly appreciated!

      Thanks
      Francois

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      To see the table on reporting side, did you grant security permissions for it on Configure Object Definition and Manage Permission roles for the role. The other pre-req is data should be created for the record under Manage Data for it show in advanced reporting.

       

      Author's profile photo Former Member
      Former Member

      Hi Ruchi,

      could you please let me know if this also supports EC Recruiment module?
      So the Russian candidate data are also stored in the Russian Data Center first?

      Thanks
      michal

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi Michal

      Right now we do not have RDC for Recruiting. Current ETA for RCM is mid of 2018.

       

      Author's profile photo Former Member
      Former Member

      Hi Ruchi,

      do you have any more detailed information about ETA for RDC for Recruitment?

       

      Thanks,

      michal

       

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi Michal

      The ETA has moved for RDC for Recruitment has been moved to 1811 due to other pressing product priorities like GDPR.

      Thank you.

      -Ruchi

       

      Author's profile photo Former Member
      Former Member

       

      Hi Michal,

       

      did you make any progress in this regard? How are you dealing with the recruiting data not being stored in the Russian Data Center?

      It would be great if you could give us some advice here ?

      Regards,

      Sören

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi Soren

       

      At this time product does not meet this requirement. It would be great question to put in Recruitment enablement group or on the community. One option is to generate daily reports form recruiting and storing it locally on a Russian system.

       

      Author's profile photo Toby Tam
      Toby Tam

       

      Hi Ruchi,

      Thanks for the detail information.

      The law is to manage master personal data of Russian citizens in Russia.  Will the process copy non-Russian citizens who work in Russia too?  How does the process distinguish Russian or non-Russian citizens?

      Thanks

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      The process is driven out of country of legal entity in which the employee is hired into and not their nationality. Hope this helps

       

       

      Author's profile photo Raul Camacho Martín
      Raul Camacho Martín

       

      Hello Ruchi,

      What about EC Payroll solution, on a global scenario, HQ based in Europe with a legal entity in Russia running payroll for them.

      Do we need  the EC Payroll (ERP PY instance) also duplicated and synchronized for the fields above?

      Or the target compliant scenario is that only the EC instance is based in RU and synched and all payroll can be in one single EC Payroll instance in EU datacenter?

      Thanks in advance

      Raul

       

      Author's profile photo Stefanie Monteyne
      Stefanie Monteyne

      Hello Ruchi

      Great blog post & easy implementation steps for this solution!

      I was wondering how to deal with information stored solely in Employee Profile, (for customers without EC but active in Russia). I assume the current solution does not support that (yet)?

      Thanks for your input!

      Best regards

      Stefanie

      Author's profile photo Geri Ann Frisone
      Geri Ann Frisone

      Hi Stephanie - did you ever get an answer to this question?

      Thanks,

      Geri Ann

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      That is correct Stephanie. It only works when we you hire someone with Russian legla entity using job info.

      Author's profile photo Shari Owen
      Shari Owen

       

      How does a customer who just learned they did not have 'Reside PII in Russia' turned on in Provisioning go about getting their Russian employees history moved into the Russian data center so they are compliant?

      Thanks - Shari

      Author's profile photo Geri Ann Frisone
      Geri Ann Frisone

      Hi Shari - did you ever get an answer to this question?

      Thanks, Geri Ann

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi Shari

       

      Yes the process supports that which migrates all data with employees in Russia after you turned on the feature.

      Author's profile photo Sandeep Gilotra
      Sandeep Gilotra

      Please refer to official SAP Successfactors roadmap for future functionality. The comments on this blog should not be viewed as a feature commitment and/or roadmap.

       

      Author's profile photo Esben Sjøntoft
      Esben Sjøntoft

      Hi Ruchi,

       

      Great article. Would you have any information regarding how this works with the Workforce Analytics module (WFA)? Reason I am asking is because this module actually extracts data from EC and loads into an OLAP Cube which resides in either of the EU DCs (or US for that matter) depending on which DC the client is using for their BizX Suite.

      So if the client has this feature turned on, then that is fine and it has no consequences for the end user. The UI is the same but some Russian data is in DC18 while the rest of the employee's data might be in DC12. But when the WFA ETL takes the EC data and loads it to the cube which is located in DC12 (for instance) then how are they still compliant with this law?

      Thanks in advance for any information you can share on this, or any direction in which you can point me.

      Best regards,

      Esben

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi

       

      I am not sure I got your concern. As the cube is not data sources, I wouldn’t think we need to do it for reporting analytics. Once you turn it on, it will write the applicable data from DC12 to RDC for employees with legal entity in Russia by running the process.

      Author's profile photo Praveen Thota Abraham
      Praveen Thota Abraham

      Hi Ruchi and other experts in the area.

      Can we try this out in Sales Demo?

      In Enable API Based Solution, What API URL do we have to use for sales demo?

      What schema so we have to update the Russian Data Center Company Schema with?

      Is It mandatory to have an API Secret KEY?  If it is are there any recommendations to create a key format?

       

      Best regards,

      Praveen

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi Praveen,

       

      I hope you found this section in the implementation guide:

      Setup the API based solution by entering the API URLAPI SecretRussian Data Center Company Schema.

      • API URL: The API URL pointing to the Russian Data Center is auto populated.

      • API Secret: Enter a secret key of your choice. This key will be used for authenticating each API call made to the Russian Data Center.

      • Russian Data Center Schema: Schema created in Russian Data Center dynamically when you enable this solution.

      Author's profile photo Zachary Tilley
      Zachary Tilley

      Hi Ruchi and Community,

       

      Does anyone know if Recruiting and Onboarding have been updated to be compliant with these regulations?

      Do these regulations apply to employee data? or does that include candidate data collected on the candidate profile and during Onboarding?

       

      Thanks,

      Zach

       

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi Zachary

       

      The regulation currently apply to employee data. You can post that in the respective product communities or check the roadmap. I know it was on roadmap of recruiting but I don’t know the timelines for sure.

      Author's profile photo Anastasia Gladenko
      Anastasia Gladenko

      Are there any plans to make SF compient with Russian law in terms of cross-border data transfer of external candidates' data? There is a number of countries which are not the parties to the Council of Europe Convention on the Protection of Individuals with Regard to Automatic Processing of Personal Data and ensure adequate protection of the data subjects’ rights. Accourding to the Russian law we cannot give access to users from these coutries without a written consent with wet signature, which makes it impossible for the candidate to register in our database. Currently SF does not provide any posibility to restrict view access to candidate database for particular contries. Visibility is given on the candidate choice - 1. can see all recruiters worldwide; 2. can see recruiters of the country of residence; 3. only recruiters of the job requisition.

      Thank you

      Anastasia

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi Anastasia,

      Please log an enhancement with the recruiting team. I am not aware of how we are ahndling RDC requirements for candidate information

      Thanks

      Ruchi

      Author's profile photo David Cook
      David Cook

      Are there plans to offer a similar solution to comply with the similar data residency requirements that are in the works for China?

      Author's profile photo Ruchi Tandon
      Ruchi Tandon
      Blog Post Author

      Hi David

      I have not heard anything for China. Please log an influence ticket for this under Employee Central

      Ruchi