Updating Compliance Calibrator Rule Set

The business has decided to change a few rules by removing a couple of custom tcodes from the rule set. In DEV I go into the Function and remove the objects associated with the tcode and disable the tcode. After running the rule set update there is still some sort of tie. I have created a test ID in DEV with a known issue around each of the changes. I'm not getting a different result when running compliance calibrator.
Any ideas?
We are running R/3 4.6C and compliance calibrator 4.0

Can you please check the following demo?
[Virsa Compliance Calibrator Application for SAP v5.1 Demo|http://www.sdn.sap.com/irj/scn/elearn?rid=/library/uuid/d2f1cf9c-0d01-0010-2dac-aedd3c4f7f5b&overridelayout=true]
Please give more details on the step where you got stuck.
Regards,
Dipanjan

Similar Messages

SAP GRC 5.2 Compliance Calibrator rule sets for HR module

HI All,
The company i am working for has done installation of GRC 5.2. I would like to download the SAP out of box Compliance Calibrator rule sets for HR function module in a spreadsheet format.
I would like to download the rule set for risks at Function level, Tcode level and also at authorization object level in ABAP and Roles, actions and permissions in JAVA.
I will discuss with the BPAs, internal auditors and come up with a new rule set exclusively for my company needs with the help of the above spreadhseet.
Please tell me what steps i need to do to get this thing done.

Please go through the process but save these as txt files for UNIX. I am not sure about 5.2 but CC4 was not uploading rule files correctly if file was not saved for TXT for UNIX.
Regards,
Harry Sidhu

Access to update the GRC rule set is limited

Hello - What is the process (tcode) to see who has access to update the GRC rule set?
Thanks!

Hi Sam,
What is the version of your RAR (CC)? If it is CC 4.0 then you enter the product via tcode and go to rule architect to make changes. If you have CC 5.X then you go through the web browser and go to Rule architect to make changes to the rule set.
The process to change a rule set is as below:
1) Creats Function
2) Create risk
3) Create Rule
Regards,
Alpesh

Compliance Calibrator 5.1 Risk Categories

Hello.
Is there a difference in the way the systems reacts to a risk category i.e. if the risk is classified as High, does it stop a user from doing something? Is there any difference between medium and low or are the categories merely used in the risk analysis reports as a statistic?
Thanks.

It is still preventative in that you can perform a risk analysis simulation. That is, you can test for risks <i>before</i> you grant the user access. It is also preventative in that it is testing segregation of duties controls, which are a type of preventative control.
Risk Terminator leverages from the Compliance Calibrator rule-sets and basically modifies the user maintenance and role maintenance tcodes to add a risk-analysis step in there. So, for example, if you are maintaining a role, when you go to generate, it will perform a risk analysis and you will have to document the reasons for creating/changing a risky role. Same when you assign roles to a user that combine to cause a risk. So, yes, Risk Terminator is also preventative. As is Access Enforcer.

Do you trust the SAP standard rule set ?

Hello all,
I have the impression that, too often, the SAP standard ruleset has been taken for granted : upload, generate and use. Here is a post as to why not to do so. Hopefuly, this will generate a interesting discussion.
As I have previously stated in other threads, you should be very careful accepting the SAP standard rule set without reviewing it first. Before accepting it, you should ensure that your specific SAP environment has been reflected in the functions. The 2 following questions deal with this topic :
1. what is your SAP release ? ---> 46C is different than ECC 6.0 in terms of permissions to be included in the function permission tab. With every SAP release, new authorization objects are linked to SAP standard tcodes. Subsequently some AUTHORITY-CHECK statements have been adapted in the ABAP behind the transaction code. So, other authorizations need to provided from an implementation point of view (PFCG). And thus, from an audit perspective (GRC-CC), other settings are due when filtering users' access rights in search for who can do what in SAP.
2. what are your customizing settings and master data settings ? --> depending on these answers you will have to (de)activate certain permissions in your functions. Eg. are authorization groups for posting periods, business areas, material types, ... being used ? If this is not required in the SAP system and if activated in SAP GRC function, then you filter down your results too hard, thereby leaving certain users out of the audit report while in reality they can actually execute the corresponding SAP functionality --> risk for false negatives !
Do not forget that the SAP standard ruleset is only an import of SU24 settings of - probably - a Walldorf system. That's the reason SAP states that the delivered rule set is a starting point.
So, the best practice is :
a. collect SAP specific settings per connector in a separate 'questionnaire' document, preferably structured in a database
b. reflect these answers per function per connector per action per permission by correctly (de)activating the corresponding permissions for all affected functions
You can imagine that this is a time-consuming process due to the amount of work and the slow interaction with the Java web-based GRC GUI. Therefore, it is a quite cumbersome and at times error-prone activity ...... That is, in case you would decide to implement your questionnaire answers manually. There are of course software providers on the market that can develop and maintain your functions in an off-line application and generate your rule set so that you can upload it directly in SAP GRC. In this example such software providers are particularly interesting, because your questionnaire answers are structurally stored and reflected in the functions. Any change now or in the future can be mass-reflected in all (hundreds / thousands of) corresponding permissions in the functions. Time-saving and consistent !
Is this questionnaire really necessary ? Can't I just activate all permissions in every function ? Certainly not, because that would - and here is the main problem - filter too much users out of your audit results because the filter is too stringent. This practice would lead too false negatives, something that auditors do not like.
Can't I just update all my functions based on my particular SU24 settings ? (by the way, if you don't know what SU24 settings are, than ask your role administrator. He/she should know. ) Yes, if you think they are on target, yes you can by deleting all VIRSA_CC_FUNCPRM entries from the Rules.txt export of the SAP standard rule set, re-upload, go for every function into change mode so that the new permissions are imported based on your SU24 settings. Also, very cumbersome and with the absolute condition that you SU24 are maintained excellent.
Why is that so important ? Imagine F_BKPF_GSB the auth object to check on auth groups on business areas within accounting documents. Most role administrator will leave this object on Check/Maintain in the SU24 settings. This means that the object will be imported in the role when - for example - FB01 has been added in the menu. But the role administrator inactivates the object in the role. Still no problem, because user doesn't need it, since auth groups on business areas are not being used. However, having this SU24 will result in an activated F_BKPF_GSB permission in your GRC function. So, SAP GRC will filter down on those users who have F_BKPF_GSB, which will lead to false negatives.
Haven't you noticed that SAP has deactivated quite a lot of permissions, including F_BKPF_GSB ? Now, you see why. But they go too far at times and even incorrect. Example : go ahead and look deeper into function AP02. There, you will see for FB01 that two permissions have been activated. F_BKPF_BEK and F_BKPF_KOA. The very basic authorizations needed to be able to post FI document are F_BKPF_BUK and F_BKPF_KOA. That's F_BKPF_BUK .... not F_BKPF_BEK. They have made a mistake here. F_BKPF_BEK is an optional auth object (as with F_BKPF_GSB) to check on vendor account auth groups.
Again, the message is : be very critical when looking at the SAP standard rule set. So, test thoroughly. And if your not sure, leave the job to a specialized firm.
Success !
Sam

Sam and everyone,
Sam brings up some good points on the delivered ruleset. Please keep in mind; however, that SAP has always stated that the delivered ruleset is a starting point. This is brought up in sap note 986996     Best Practice for SAP CC Rules and Risks. I completely agree with him that no company should just use the supplied rules without doing a full evaluation of their risk and control environment.
I'll try to address each area that Sam brings up:
1. Regarding the issue with differences of auth objects between versions, the SAP delivered rulset is not meant to be version specific. We therefore provide rules with the lowest common denominator when it comes to auth object settings.
The rules were created on a 4.6c system, with the exception of transactions that only exist in higher versions.
The underlying assumption is that we want to ensure the rules do not have any false negatives. This means that we purposely activate the fewest auth objects required in order to execute the transaction.
If new or different auth object settings come into play in the higher releases and you feel this results in false positives (conflicts that show that don't really exist), then you can adjust the rules to add these auth objects to the rules.
Again, our assumption is that the delivered ruleset should err on the side of showing too many conflicts which can be further filtered by the customer, versus excluding users that should be reported.
2. For the customizing settings, as per above, we strive to deliver rules that are base level rules that are applicable for everyone. This is why we deliver only the core auth objects in our rules and not all. A example is ME21N.
If you look at SU24 in an ECC6 system, ME21N has 4 auth objects set as check/maintain. However, in the rules we only enable one of the object, M_BEST_BSA. This is to prevent false negatives.
3. Sam is absolutely right that the delivered auth object settings for FB01 have a mistake. The correct auth object should be F_BKPF_BUK and not F_BKPF_BEK. This was a manual error on my part. I've added this to a listing to correct in future versions of the rules.
4. Since late 2006, 4 updates have been made to the rules to correct known issues as well as expand the ruleset as needed. See the sap notes below as well as posting Compliance Calibrator - Q2 2008 Rule Update from July 22.
1083611 Compliance Calibrator Rule Update Q3 2007
1061380 Compliance Calibrator Rule Update Q2 2006
1035070 Compliance Calibrator Rule Update Q1 2007
1173980 Risk Analysis and Remediation Rule Update Q2 2008
5. SAP is constantly working to improve our rulesets as we know there are areas where the rules can be improved. See my earlier post called Request for participants for an Access Control Rule mini-council from January 28, 2008. A rule mini-council is in place and I welcome anyone who is interested in joining to contact me at the information provided in that post.
6. Finally, the document on the BPX location below has a good overview of how companies should review the rules and customize them to their control and risk environment:
https://www.sdn.sap.com/irj/sdn/bpx-grc
Under Key Topics - Access Control; choose document below:
    o GRC Access Control - Access Risk Management Guide   (PDF 268 KB)
The access risk management guide helps you set up and implement risk
identification and remediation with GRC Access Control.

Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA

Issue Summary
In Java 1.7 Update 71, Java 1.7 Update 72 and Java 1.8 Update 25 Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA. We've noticed this with Oracle Forms and Reports 11g where we have forms that specify Java 1.6 Update 20. We used to be able to specify Java 1.6 Update 26 in our Ruleset, but now the only version a that works in our ruleset is Java 1.6 Update 20 which is the same version requested by the JPI-Version attribute of the jar. The long term solution would be to upgrade Oracle Forms and Reports, however this isn't currently in the cards.
RuleSet.xml Test
Ruleset.xml
1
2
3
4
5
6
7
8
9
10
11
<ruleset version="1.0+">
<rule>
   <id location="*.javatester.org" />
   <action permission="run" version="1.6*" />
</rule>
<ruleset version="1.0+">
<rule>
   <id location="*.internaldomain.name" />
   <action permission="run" version="1.6*" />
</rule>
</ruleset>
Test 1 (Control)
Installed Java Versions:
– 1.7 Update 51 b13 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
Deployment Ruleset works as expected for both URLs
Test 2
Installed Java Versions:
– 1.7 Update 72 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
The RuleSet works for JavaTester.org however on internaldomain.name we get the following error:
With the trace logging turned on, I suspected the version attribute supplied by the RIA. I was able to trick Java by adding the following to my system deployment.properties file:
deployment.javaws.jre.0.product=1.6.0_20
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.enabled=true
Because the RIA requests 1.6.0_20 it matches 1.6* from the deployment ruleset sooner than 1.6.0_26. However, if 1.6.0_20 is not available 1.6.0_26 should match according to the Deployment Rule Set documentation:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
The version of the JRE that is used is determined by the following order of precedence:
1. The current version of the JRE is used if it is available and matches both the version attribute and the version requested by the RIA.
2. The latest available version of the JRE is used if it matches both the version attribute and the version requested by the RIA.
3. The current version of the JRE is used if it is available and matches the version attribute.
4. The latest available version of the JRE is used if it matches the version attribute.
If no version is available that meets the criteria, then the RIA is blocked, and a message is shown to the user. To provide a custom message, include the message element.
As a result:
If Java 1.6.0_20 is listed in the version requested by the RIA and 1.6.0_20 is listed in the deployment.properties file, #1 matches.
If Java 1.6.0_20 is listed in the version requested by the RIA, but 1.6.0_20 is NOT listed in the deployment.properties file the #1 SHOULD match, but doesn’t. It used to match up-to and including JRE 1.7 Update 51 however the ruleset appears to no longer match in subsequent versions.
#2 should never match with our current Deployment Ruleset. It would match if we specified 1.7* as a version in the Ruleset.xml.
#3 used to be broken as well after JRE 1.7 Update 51 however this bug has been marked as fixed. See: http://bugs.java.com/view_bug.do?bug_id=8032781
I have reproduced this issue with Java 1.7 Update 71, Java 1.7 Update 72, and Java 1.8 Update 25 when one of these versions are installed with Java 1.6 Update 26.

I can't seem to edit this post anymore, for some odd reason.
So here goes;
I found this post in NVIDIA's knowledge base;
When installing an after-market graphics card into a certified Windows 8 PC with UEFI enabled, the s...
The interesting parts in this post are as follows;
When an after-market graphics card is installed into a motherboard with UEFI enabled in the system BIOS, or if the system is a certified Windows 8 PC with Secure Boot enabled, the system may not boot.
UEFI is a new system BIOS feature that is provided on most new motherboards. A UEFI system BIOS is required in order for the Windows 8 Secure Boot feature to work. Secure boot is enabled by default on certified Windows 8 PCs.
In order to get the PC to boot with a graphics card that does not contain UEFI firmware, the end-user must first disable the secure boot feature in the system's SBIOS before installing the graphics card.
Note: Some system SBIOS's incorporate a feature called compatibility boot. These systems will detect a non-UEFI-enabled firmware VBIOS and allow the user to disable secure boot and then proceed with a compatibility boot. If the system contains a system SBIOS the supports compatibility boot, the user will need to disable secure boot when asked during boot process
This leads me to believe that the BIOS update that wrecked my setup was 9SKT58A/9SJT58A, which only contains one change;
"Adds support for updating BIOS from a WIN7 BIOS to a WIN8 BIOS".
I've just ordered a cheap UEFI-compatible GT640 from Gainward, so I hope I'll be able to try that out this weekend.

Re: Virsa Compliance Calibrator & Pre-defined SOD Rule Set

Hi All,
We have installed the Virsa Compliance calibrator 5.1 in our sandbox environment. When we goto the "Rule Architect" tab under Compliance calibrator using tcode /virsa/zvrat it brings up the page with Rules information.
Per the Virsa documents that i read they have mentioned that there are pre-defined SOD Rules (Transaction codes and Tcode objects) that we can use in the Rule Architect.
My question is how do i enable and use those pre-set SOD Rules that Virsa provides by default. I do not see them under the Rule architect tab though. Can someone give some pointers to use these pre-set SOD rules.
Thanks & Regards
-Murali

Hi Laziz,
Thanks for your patience in replying to my CC 5.1 queries. I did follow your steps for the Generate Rule & Background Job-> Schedule Analysis and scheduled the job immediate.
However, when i looked up the status of the scheduled analysis Background Job-> Search pulls up the job i scheduled at the top it reads "Job scheduler Status: unknown error" . I clicked on "View Log" button and it shows some messages as shown below (Note: I am just posting some parts of the error msgs below. but it still goes for 1 page...)
May 16, 2007 1:09:07 PM com.virsa.cc.xsys.bg.BgJobDaemon init
INFO: *** BgJobDaemon loaded
May 16, 2007 1:11:09 PM com.virsa.cc.common.util.ConfigUtil setDefaultJ2EEParam
WARNING: Cannot get Application URL: null. PLEASE SET 'Background Daemon URL' IN CONFIGURATION TAB
java.lang.NullPointerException
     at com.virsa.cc.common.util.ConfigUtil.setDefaultJ2EEParam(ConfigUtil.java:203)
     at com.virsa.cc.common.util.ConfigUtil.getBgJobStartURL(ConfigUtil.java:192)
     at com.virsa.cc.xsys.bg.AnalysisDaemonThread.run(AnalysisDaemonThread.java:45)
     at java.lang.Thread.run(Thread.java:534)
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: class name: com.virsa.cc.extreport.ReportPack50SP1_01.ReportPack50SP1_01 class: com/virsa/cc/extreport/ReportPack50SP1_01/ReportPack50SP1_01.class
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: Jar Entry length=1568 compressed size=1568 actual read=1568
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: class name: com.virsa.cc.extreport.ReportPack50SP1_01.CrtActbyRsk_Act_RskLvl class: com/virsa/cc/extreport/ReportPack50SP1_01/CrtActbyRsk_Act_RskLvl.class
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: Jar Entry length=13210 compressed size=13210 actual read=13210
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: class name: com.virsa.cc.extreport.ReportPack50SP1_01.CrtRolbyRsk class: com/virsa/cc/extreport/ReportPack50SP1_01/CrtRolbyRsk.class
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: Jar Entry length=19287 compressed size=19287 actual read=19287
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: class name: com.virsa.cc.extreport.ReportPack50SP1_01.CrtProfbyRsk class: com/virsa/cc/extreport/ReportPack50SP1_01/CrtProfbyRsk.class
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: Jar Entry length=12807 compressed size=12807 actual read=12807
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: class name: com.virsa.cc.extreport.ReportPack50SP1_01.UsersbyOrgLevels class: com/virsa/cc/extreport/ReportPack50SP1_01/UsersbyOrgLevels.class
May 16, 2007 1:24:37 PM com.virsa.cc.extreport.JarClassLoader loadClassData
FINEST: Jar Entry length=18557 compressed size=18557 actual read=18557
May 16, 2007 1:24:59 PM com.virsa.cc.common.util.ConfigUtil setDefaultJ2EEParam
WARNING: Cannot get Application URL: null. PLEASE SET 'Background Daemon URL' IN CONFIGURATION TAB
java.lang.NullPointerException
I am not sure whats causing this and it's been 2hrs since i scheduled the user analysis but i don't see any data still appearing in the fron-end..Any pointers again???
Thanks
-Murali

Compliance Calibrator Default Rules Upload Files

I'm implementing Compliance Calibrator 5.1, and I'm at the point where I need to upload the default rule-set. However, I cannot locate the flat files required for the initial rule-set upload (i.e. business process, function, and risk definitions). I've read through the user guides, but they don't seem to reference exact file names or specify where the files would be located after install. Thanks in advance for your help.

Varun,
you may get a quicker answer to your question in the GRC forum
Governance, Risk and Compliance (SAP GRC)

Updating rule set in CC from SAP

Hi - if anyone can help with this issue - I'd greatly appreciate it.
We loaded CC 5.2 last year and loaded all of our custom transactions to the appropriate functions. However, since then, there have been changes to standard and custom transactions (in the authorization objects) and those changes are not showing up in the rule set. (we added new authorization objects) Is there a way to have the rule set update automatically with these?
We are running the two SAP jobs that export the texts and objects and then we have two jobs running daily in CC to bring in from those files. We then have a full system sync running daily. Updates are still not coming in.
Any help is appreciated!
Thanks,
Elizabeth

HI Elizabeth,
When you say you have added new Authorization objects, do you mean to say that you have added to the roles?
I strongly recommend to go to SU24 tcode and check whether the new Authorization objects are properly Check/Maintained to the respective Tcodes.
Also merge all the new authorization data in all the roles and regenerate them.
Also you need to update the rules once the above steps are done.
Regards,
Kiran Kandepalli.

Create rules in Compliance Calibrator for HR PD profiles

Hello
In Compliance Calibrator can we create a rule to check PD profile combinations?
Example:
We have 3 PD profiles say 1, 2, 3
We dont want 1, 3 together
Any help on this, is greatly appreciated.

Alexander,
Thanks for your prompt response. But the note available from SAP is not included SCM?
<b>Note 1033326 - Compliance Calibrator 5.2 Rule Upload</b>
SOD Action and Permission level rules are provided for R/3, APO, ECCS, CRM
and SRM. HR and Basis rules are included in the R/3 but also broken out
separately.
Could you tell me what all other modules are included in the standard ruleset?
Thanks in advance
Eric

Updation of Rule-set in GRC10

Hi,
There is a requirement for us to update few risks(objects within the risk) for our non-business ruleset. What is the best suggested method to do this?
->Directly update from NWBC
->Download Rule-set and upload from SPRO
->Transport
If any body can share their suggestions and steps, it would be great.
Thanks,
Sabitha

Hello Sabitha,
This is because you haven't created the connectors in DEV. do you have that connectors in SM59?? I recoomend to create the connectors and associate the to the logical system just to keep all the systems with the same info. you can create the connectors but it's not neccesary to fill all the data in SM59. Just create the connector with the name would be fine.
If i modify the ruleset based on the connector group in development and transport the ruleset would all the physical systems still be listed in the drop down in Quality and Prod
Yes, this will be deleted only if you transport the logical system configuration from DEV and it's not related to SoD rules transport.
If we modify the ruleset based on connector group in development and transport , would it cause any inconsistency as it looks like the Quality and Prod the physical connectors are linked to the ruleset
No. if you are working with the logical system and you haven't uploaded rules to the physical ones it has no effect.
From your comment I understand that it does not matter about the physical systems as rule generation would take care of generating/linking the ruleset based on the systems assigned to the Connector Group/Logical Systems- If this is the case I am wondering why in development system even after the generation of rule-sets the physical systems are not available
This is because you haven't created the connector or you haven't linked the connectors to te connector groups or you haven't enabled the connectors for the auth scenario.
When generating rules the system generates the rules for the necessary logical systems. since you have none in DEV it wont generate rules for your scenario. So in the escenario you are describing in DEV with logical connectors but no physical ones you shouldn't be able to execute a risk analysis there.
Cheers,
Diego.

Rule set Updates

We started with Virsa CC 5.1 in 2006 now we are using CC 5.2
If I go to the SAP Note 1173980 u2013 Q2 2008. Do I find all the Rule
Updates from 2006 to 2008 or we need to implement all the below Virsa
Rule updates.
1061380 u2013 Q2 2006
1035070 u2013 Q1 2007
1083611 u2013 Q3 2007
1173980 u2013 Q2 2008

HI:
You need to review each set of updates, and determine if they are applicable for your system. Each subsequent rule set update issued does NOT include previous entries.
It is up to each client to customize entries in the updates per their own requirements, but just taking the last one, means that you may miss some of the important updates in previous updates.
Margaret

Compliance Calibrator standard rule files needed

Hello, we need the standard rule files (.txt) for the Compliance Calibrator 5.2. We don't have the installation software accessible atm and couldn't find anything on the SAP marketplace.
If someone could give us information on where to get these files explicitly would be great.
Thanks and best regards,
Jan

The rules are delivered together with the software which you will be able to download if you hold a valid software license for SAP GRC Access Control. Your organization holds valid licenses of the software in several countries, e.g. in Germany, France, India, Italy, the Netherlands, and the US.

GRC Rule Set Updates

Where can I fund updates made to the default rule set?

http://service.sap.com/support
Click on the Help & Support tab --> Search for SAP Notes.
You will need a valid S-number to log in.
Thanks!
Ankur
SAP GRC RIG

Update on Management View in VIRSA Compliance Calibrator 5.2

Hello,
is there a way to delete the Data for the Management View in VIRSA Compliance Calibrator 5.2 and then make a full new data load.
When I select Full Synchronisation and Management Reports in the Schedule Analysis, the system does not update the Management View correctly, the Management Report shows still roles which are already deleted in the SAP-System.
Thanks

Hi,
You can do a Full sync of Users and Roles first which will be ovewrite and then run the Batch Risk Analysis Management Reports.
You can try this exercise first if it does not work then go ahead with Alpesh's advice.
Thanks
Darshan

Updating Compliance Calibrator Rule Set

Similar Messages

Maybe you are looking for