Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

FERC Code of Conduct - Restricting access for employees

Former Member
0 Kudos

hello - I am project lead for an effort to separate market and transmission data from certain employees in our company. I'm finding this to be a monumental task, since we have a large SAP implementation. FI/CO, MM, HR (postion-based security), Customer (IS-U-CCS), PM, PS, xRPM. We have implemented SOD for SOx compliance, but this is an entirely different effort. Unlike SOx, we need to totally restrict transactions that could contain non-public market and transmission data, so we need to separate the data behind the transactions. Does anyone have experience with this? Would love to hear what approach you took and swap ideas.

Annette M Alboreo, FirstEnergy Corp.

2 REPLIES 2

Former Member
0 Kudos

Hi Annette,

First of all, good luck! Data segregation is always a tricky one to manage and needs to be carefully thought out. This sort of activity has a large security and functional overhead and you need to make sure you have access to them.

When I've worked on this sort of thing in the past, there are a few things that you need to identify

- What data is sensitive? The business should ID <b>all</b> sensitive data and the functional team translate that into fields etc. What data needs to be legally segregated, what data is nice to have segregated. A set of rules should be drawn up to say who get's what in which circumstances.

- How are people accessing data? What transactions give access to sensitive data? Standard SAP tx, custom tx (which may need auth checks changing), access to SE38/SA38, SQ01, SQVI etc. All of the routes to the data need to be identified.

Once it is known what data needs to be restricted then it is possible to address how to restrict access to it. A reasonable amount of it should be able to be catered for in the standard auth concept. It's also likely that there will be the requirement for additional config & customising (e.g hide fields, change screens, user exits) to meet these new control needs. I think it goes without saying that the more that you can fix with the standard auth concept, the easier it tends to be. If this means removing some transactions from users then in some cases it may be less costly than knocking up a whole load of custom code to solve the problem - of course this is dependent on the situation.

Hope that is of some use

Cheers

Alex

0 Kudos

Hi Alex,

thanks for your comments. It was good to hear our approach is on track. We started our analysis by determining which txns are sensitive, and then went to the business to see what they must have to do business. We are position-based, so we are looking at ways to secure the data via heirarchy. We think a high percentage can be handled via authorizations, but some will require coding changes. The tricky part is determining how to implement this in our already complex role structure.

How about BI? We are on BI 7.0, and will have to restrict data there as well. We are debating the approach - should we go at the InfoProvider level or InfoObject?

your comments were helpful - thanks again for the input.

- Annette