Using GRC PC to monitor transported changes

[brian_martenson]

I am trying to understand if GRC PC can monitor for transported changes. If I transport a change from one system to another (e.g. Dev to Quality), the change in Q is not logged in SCU3 which GRC PC uses to identify changes that do not meet the deficiency criteria. Should GRC PC be able to monitor transported changes and/or is this even possible?

[madhusap]

Hi Brian,

Parameter “rec/client” is for enabling table logging and yes if any changes are made in production directly you can use GRC PC to monitor based on change logs. But if you are making changes in development for a program or a function module then changes are based on versions and not exactly change logs. For example if a role is modified in development then change logs will be only in DEV and not in PRD, so i was wondering what exactly you are trying to monitor and how it can be addressed through table logging.

But if your requirement is to monitor any table data changes or config changes directly in production, you can monitor using PC by enabling table logging and using change logs as deficiency criteria.

Regards,

Madhu

[brian_martenson]

Hi Madhu-

Yes, the rec/client is for enabling table logging for changes made directly in Production to the table data (e.g. changing a field from marked to unmarked). However, the RECCLIENT parameter in STMS is used to log changes to table data transported through the landscape. For example, if I make a change to a field of data, say an account number used when posting an entry, and make this in Production. If table logging for the table and the rec/client parameter are enabled, GRC PC will find the change in the SCU3 logs. However, if I make the same change in Dev and transport the change through the landscape, if the RECCLIENT parameter is not assigned to the environments in STMS, then the change is not logged in SCU3 and GRC PC cannot find the change. If the RECCLIENT parameter is enabled in STMS, then the change will be logged in SCU3 and GRC PC will find the change that was transported. Again, the table must also have table logging enabled, otherwise no changes are logged from the transport.

So my ultimate goal is to find changes made to the table data, not the table structure itself, and the RECCLIENT parameter in STMS will allow that to be found.

By having both monitoring schemes in place, I am able to see if any changes are made in Production directly or a change is transported through the landscape.

Brian

[madhusap]

Hi Brian,

Generally for changes being transported from DEV to QAS to PRD you should have a change management process in place and all the changes should have been approved by relevant stakeholders and tested thoroughly before they are moved to production. GRC PC change logs monitoring is not for this purpose as the transport changes can be in different forms as versions or change logs (which will be in development only) etc.

I suggest you to make use of your change management process to validate the changes moving from DEV to PRD. You can have authorization restrictions on who can make changes (generally developers and consultants) and who can import the changes (generally basis team) as a good practice.

Regards,

Madhu

[brian_martenson]

Thank you, Madhu for your response. I understand a process should be in place to monitor the transports prior to moving between systems and we have one. However, I want to be able to monitor the settings in the system across many areas and I am not able to be made aware of each and every change that happens to all of the business areas. Monitoring the changes also allows our auditors to gain comfort that the current settings in the system are correct, since the business will review the change log and may not have been aware of a change processed by a different team that impacted them. Additionally, some changes made in the system will impact other GRC PC rules and will need to be accounted for in the filter or deficiency criteria.

As such, I dug deeper into this situation and found that enabling the RECCLIENT parameter in the Transportation Management System will allow changes transported to be logged (if the table has logging enabled) so that GRC PC can identify these changes as well as any that are made directly to Production (which should not happen, but there is always the risk, so it needs to be monitored).

Thank you again for your response and assistance with my question.