SAP Source List Controls

In SAP, if at any point of time a buyer wants to know which vendors or internal suppliers can supply a material over a given period of time then source list is the answer from where they can find out the possible source of supply.  A source list specifies the possible sources of supply for a material over a given period of time.  It shows the time period in which a material may be ordered from a given vendor or under a certain long-term purchase agreement.  Here a possible source of supply can be a vendor (external supplier) or an outline agreement or both.

Within a source list, each source of supply is defined by means of a source list record for a certain plant (organizational level) over a given period of time. Once you have maintained the source list in the system you can use it in the administration of sources of supply.

Given that source lists drive purchase orders for critical materials, it is necessary to review changes to source list to validate that all changes are based upon approved business decisions.  If changes are made and not approved, vendors may be given priority over other vendors, materials may not be ordered, or approved contracts may not be enforced.

Therefore, it is a requirement to review all changes to the source list for critical materials.  Critical materials are defined as materials that are required by a company to maintain production levels and customer expectations.

A review of all changes to source lists can be performed via transaction ME04 

 Control Activity:

Insert the following search criteria in ME04

• Material:
  • If a list of critical materials has been designated, insert them in this field
  • Otherwise, leave this field blank to see all changes to materials
  • Plant:
    • If a list of critical plants has been designated, insert them in this field
    • Otherwise, leave this field blank to see all changes to materials at all plants
    • Changed by:
      • Leave blank so changes from all users are captured
      • From Change Date:
        • Use the date of the last review in order to catch the entire list of changes

 Execute the report and review the list of changes.  Take any follow up actions necessary based on the list of changes.

SAP One time Vendor Accounts

Management performs a review of one-time vendor master records activity to validate that postings adhere to policies and standards.  Issues identified are investigated and resolved in a timely manner.

One time vendor accounts (OTV) are used to procure from suppliers who do not have a vendor master record.  The OTV account can be considered as a shell, with all the vendor details specified during purchase order and invoice processing.

The one time vendor ability is determined from the account group level.  Account groups can be created with one time vendor functionality assigned to them. When vendors are assigned to an account group that is marked as one time vendor, it will become a one-time vendor (OTV). For each OTV master record, multiple vendors can be processed through it. During the initial steps of vendor creation, the vendor is assigned to an account group. When the vendor is assigned to an account group, it will inherit the one time characteristics.

One-time vendors require less information within vendor master and traceability is limited of key fields such as bank details. One-time vendor (OTV) accounts are used to process procurement transactions for vendors that do not have a vendor master record and therefore may not subject to the vendor master review and approval process.

Control Implementation:

Using transaction code FBL1N or FBL2N, one can analyze specific vendor account line items, corresponding balances, transaction history, etc. to validate the processed payments are reasonable when one time vendors are used:

• One-time Vendor is set to “Yes”.  This report will provide a history of payments made to one-time vendors.   This is important to review and understand as one-time vendors require less information within the vendor master and traceability is limited of key fields such as bank details and are only available during processing.

SAP Purchasing Info Record Controls

The system is configured to validate that sensitive fields have been completed or restricted from use during the creation / change of purchasing info records. The system will automatically assign a sequential internal number to each purchasing info record, which will be created after vendors are created in SAP.

Purchasing info records (PIR’s) are used by a company to hold specific information when certain materials are procured from certain vendors.  The info record contains data such as prices and conditions that you can store for the relevant purchasing organization or plant, the number of the last purchase order, tolerance limits for over-deliveries and under-deliveries.  In addition, the PIR can contain:

• The planned delivery time (lead time required by the vendor to deliver the material).
• Vendor evaluation data.
• An indicator showing whether the vendor counts as the regular vendor for the material.
• The vendor sub-range to which the material belongs.
• The availability period during which the vendor can supply the material.
• The info record contains quotation and ordering data. The data in the info record (prices for example) is also used as default data for purchase orders.

For instance, a company can store the current and future quotation conditions (discounts, fixed costs etc.) in the info record, in order to be able to copy them into Purchase Orders more accurately and efficiently.  Information in a PIR is defaulted into Purchase Orders making imperative that sensitive fields such as price, discount, etc have been properly captured and maintained.

PIRs can be applied at both the Purchasing Organization level and the Plant level in the system providing flexibility to the procurement group.

The correct category should be identified before creating a purchasing information record.  There are 4 categories of purchasing information records can be created in SAP:

• Standard – Information record for standard purchase order.
• Pipeline – Information on vendor and material that is supplied through a pipeline, cables, or pipes such as electricity or water.
• Consignment – Information on material that a vendor owns and stored at the purchaser’s plant.
• Subcontracting – Information for subcontract orders.

Creation and maintenance of PIRs can be performed via transaction ME11, ME12, ME13 or ME15.

Access to PIR creation and maintenance should be restricted to only authorized users and should be segregated from users with the ability to create purchase orders.  In addition, the access to change PIR configuration should be segregated from all functional access in order to maintain the consistent use of PIRs.

 

 

SAP Contract Changes

Management reviews and approves creation/modification of contracts in the SAP environment to validate that supporting documentation has been appropriately completed and approved.

The objective of this control is to ensure that the correct information is included on each type of contract.

Different types of contracts will have different information required to ensure that the legal document is adequately captured. Contacts can generally be considered as:

• Quantity – Where an agreed quantity will be purchased over the period.
• Value – Where an agreed value will be purchased over the period.

Some contacts types will have specific pricing at the material level, where as other will just specific the target Quantity or Value.

The newly created contract should be reconciled to the original hardcopy contract to ensure the contract in ECC matches the agreed-upon terms.

Control Activity:

To identify the changes to the contracts, table CDHDR should be run using transaction SE16 / SE16N with the following criteria:

• Change doc. object = EINKBELEG
• Object Value = Enter the appropriate document range for Contacts
• Date = Month under review

The contracts that are identified through table CDHDR as changed during the month under review should then be input into table CDPOS using transaction SE16 / SE16N to identify the specific changes that were made.  CDPOS should be run with the following search criteria:

• Change doc. object = EINKBELEG
• Document Number = Change documents identified trough table CDHDR
• Field = Key Fields identified for review

The changes should be reconciled to the original hardcopy contract to ensure the contract in ECC match legal documents.

SAP Vendor Master Data flagged for deletion Risk

On a monthly basis, vendors flagged for deletion but not assigned a purchasing block are reviewed to validate they have not been transacted against.

Vendor Master Records are created at the general Master Data level and then extended to relevant company codes and purchasing organizations. Once the vendor is extended, it can be flagged for deletion at any of the three levels of Vendor Master Data:

1. General
   1. This is data that applies equally to all company codes and purchasing organizations within the enterprise. The general data includes the vendor’s name, address and communication information, the tax identifiers and controls, and the bank account information used for payments.
2. Company code
   1. Accounting information is kept at company code level, which governs financial transactions. This data includes payment transaction data (default payment terms and payment method), the number of the relevant control account (called the reconciliation account which will be used when posting the accounts payable balance sheet account), and withholding tax information by country.
3. Purchasing organization.
   1. Purchasing data is kept at purchasing organization level.  This information is used for the purchase, receipt, and invoicing for goods and services.  This data includes default purchasing information (currency, payment terms, and terms of delivery), the methods of goods receipting and invoicing, and the business relationship with other vendors.

When a vendor is flagged for deletion, the only system response produced is a warning message, which will not block the transaction. The vendor can still be transacted against if a purchasing block and/or posting block are not also assigned to it. Therefore, the risk of transacting with a vendor that is marked for deletion exists if the proper blocks are not applied.

To address this risk, monitoring of vendors marked for deletion needs to be performed. Vendors marked for deletion at the general, company code, or purchasing organization level that do not have the purchasing block applied should be monitored at each level to ensure purchase orders have not been transacted against them

By monitoring the purchasing block to ensure no transactions are created against the vendor, assurance is gained that no postings will occur for that vendor

The steps outlined below will be used to confirm whether or not a vendor with a deletion flagged has been transacted against during the period of review:

1. General Data Level
   1. Flagged for Deletion not blocked for Purchasing
   2. Verify Date Vendor was Flagged for Deletion
2. Company Code Level
   1. Flagged for Deletion not blocked for Purchasing
   2. Verify Date Vendor was Flagged for Deletion
3. Purchasing Organization Level
   1. Flagged for Deletion not blocked for Purchasing
   2. Verify Date Vendor was Flagged for Deletion
4. Follow-Up and Report Distribution

Control Activity

Management should obtain the list of vendors flagged for deletion by executing transaction SE16N and querying table LFA1 for “LOEVM = X.” Using this list, management should query FBL1N to determine if the vendor was transacted against during the period of review.

 

Changed and Manual SAP Authorizations

Changing authorizations for a Role is often a headache following the best practice of updating the USOBT_C tables versus pushing authorizations manually in PFCG. We want to avoid changed and manual authorization statuses in the authorization tab.  Changed and manual authorizations lose their connection to the transaction code (which is the entire purpose of the USOBT tables) and will result in role degradation over time as transaction codes are moved in and out of roles without moving their associated objects and field values.

Standard means the table (USOBT_C) filled in all of the authorizations necessary.  This is the best, but not always possible, since some Tcodes are used differently by users and may require different activity values.

Retransporting, Unlocking and creating Transport Requests

 

 

Scenario: there was an issue with QB1 where one of the info providers was missing a value in the bex tab settings see below for the settings selection.

 

 

 

 

 

Double click on select objects

 

Select the info object

And click on transfer selections

 

Click on the truck button and it will ask you to create a TR. Fill the info. If the TR is locked  go to SE03

 

CLCIK ON UNLOCK OBJECTS ON THE LEFT

 

 

Enter the TR and unlock

To delete a certain object in the TR go to the TR

 

DOUBLE CLICk on the TR

 

 

Hit the change button at the top and select the row and delete it.

 

SAP GRC and Secrets of an External Auditor

Have you ever imagined learning what an external auditor does in his daily life?  I decided to share my knowledge about controls for SOX -Sarbanes Oxley evaluation. Before we get into the controls here are some of the terminologies used in the secret world of Auditing. TOD- Test of design, TOE- Test of Operative effectiveness, PCAOB- Public Company Accounting Oversight Board.

Here goes the story…SEC (Securities exchange Commission) set up a board called PCAOB sometime in 2004 to oversee the auditors of public companies in order to protect their interests of investors. The external auditors follow the rules or auditing standards set by this board. Here are the auditing standards defined by PCAOB. http://pcaobus.org/Standards/Auditing/Pages/default.aspx The general documentation every external auditor on this planet uses something called ITGC – IT general controls. The ITGC has four sections where the controls are defined and evaluated. This is a template used by these auditors to evaluate the company’s processes after mapping them from the ICOFR-Internal Control over Financial Reporting. The four sections are as follows:

I. Access to Programs and Data

II. Program Changes

III. Program Development

IV. Computer Operations

TOD or test of design is used to document the control objectives, Control numbers and their description.  Ever since SAP bought VIRSA the world has changed in terms of auditors having to spend less time with their clients. SAP Solutions for Governance, Risk, and Compliance: GRC Access Control (comprising applications formerly known as Virsa Compliance Calibrator, Virsa Firefighter, Virsa Access Enforcer and Virsa Risk Terminator) Virsa Compliance Callibrator is a fantastic tool to solve the SOD conflicts and streamline a steady definition of the roles and authorization. This tool will satisfy the section I.E section of the ITGC and there is no chance they can mark you down with any kind of deficiencies. The Virsa Access Enforcer is another tool which will satisfy the I.C controls. The I.B controls can be satisfied by using another tool called Virsa Firefighter which handles exceptional access requests. The Virsa Role Expert is another web based tool.  Auditors love to snap your monitors with their tool called (Alt+Prt Sc).  So get ready to snap your own monitors and make your printer auditor friendly.  The I.A controls involve the following solutions: maintain a policy document that provides security related guidance for your SAP system landscape. Make sure every user has his own unique ID and no system accounts exist. Make sure the user access to the SAP system is done with the use of profiles defined.  Auditors use a system generated report (No excel sheets involved) to assess the periodic review of user access which will satisfy the I.D controls. So generating reports to satisfy their strict controls can only help you from seeing a deficiency in their Test of Operative Effectiveness.

• I. Access to programs and Data

I.A

• The Company has established an information security function that is appropriately aligned within the organization.
• The company has adopted a formalized security policy that provides guidance for information security within the organization and includes within its scope all aspects of the IT environment relevant to financial reporting applications and data (e.g. networks, perimeter security, operation system security, application security, acceptable systems use).

I.B

• The organization has established an authentication mechanism for in-scope information systems that provides individual accountability.
• o If passwords are used for authentication, the organization should have established rules for password management and syntax.
• The organization has established a rule based authorization mechanism that provides access to system and application resources based on job function.

I.C

• An effective mechanism is in place to ensure that access is appropriately modified or revoked when changes in job function through transfer or termination occur.
• Changes to access rights are performed immediately after the user is terminated to minimize the likelihood of system abuse or sabotage.
• Security administration personnel effectively communicate changes to access rights to appropriate management.
• The organization has controls in place to ensure proper management of data access settings (i.e., data file permission)

I.D

• The organization performs a periodic review of active users and user access rights to identify and remove inappropriate system access.

• Inappropriate system access is removed.
• Access changes due to the review process are appropriately documented and the documentation is retained.

• Access groups and roles are periodically reviewed to identify inappropriate or incompatible access rights that conflict with segregation of duties (as established in Audit Objective E below).

I.E

• Controls are in place to allow for effective translation of business rules into system access rules
• Example Control Considerations:
• The organization may group compatible system access privileges into roles or profiles to facilitate security administration.
• Controls should ensure that segregation of duties conflicts do not exist for users having access to multiple system profiles or transactions.

Based on my previous blog  SAP GRC- Governance, Risk and Compliance and Secrets of an External Auditor. I had mentioned a couple of terms without a detailed explanation.  Below are some of the Key terms and definitions.

COSO:  The Committee of Sponsoring Organizations of the tread way Commission provides detailed internal control criteria and defines the components of internal controls. This framework sets a standard for management to follow with regards to internal controls. Read more

PCAOB:  Established by Sarbanes-Oxley, the Public Company Accounting Oversight Board has broad powers to oversee audits and auditors of public companies. Through its oversight of public company auditors, the PCAOB influences how companies should prepare for their audits. In March 2004, the PCAOB issued auditing standard #2 which provides the requirement for the audit of internal controls over financial reporting. Read more

Internal Control over financial Reporting:  A process designed by or under the supervision of the company’s principal executive and financial officers or persons performing similar functions and affected by the company’s board of directors, management and other personnel to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with the GAAP (Generally accepted accounting principles)

Test of Design:

Design effectiveness refers to when the controls compiled with would be expected to prevent or detect errors or fraud that could result in material misstatements in the financial institutions. It involves consideration of the financial reporting objectives that the control is meant to achieve and whether it will achieve them.

Test of Operative Effectiveness:

Operating effectiveness refers to whether the control is operating as designed and whether the person performing the control has the necessary authority and qualifications to perform the control effectively. During the testing of operating effectiveness, management gathers evidence regarding how the control was applied, the consistency with which it was applied and by whom it was applied.

SAP GRC Process Controls

SAP GRC Process Controls offer an application for end-to-end control management by managing automated and manual controls by prioritizing remediation activities and providing the management a complete overview of the Control Environment.

To understand the concepts of SAP GRC Process Controls, it is necessary to learn the different controls or control categories for SAP. The Controls mentioned below are considered as the base for testing SAP systems by External Auditors.

Preventative Controls:

Preventative Controls helps to prevent errors or fraud from occurring in the first place that could result in a misstatement of financial statements.

Examples of preventive controls are segregation of duties which is well handled by GRC Access Controls Application, adequate documentation, and physical control over assets.

By performing simulation in GRC Compliance Calibrator, we are implementing a preventive control that avoids introduction of SOD violations before a risk is introduced into the production environment.

Detective Controls:

Detective Controls helps in detecting errors or frauds that have already occurred that could result in a misstatement of financial statements.

Examples of detective controls are Periodic Review of Users and Segregation of duties, analyses, variance analyses and reconciliations. SAP GRC provides management reports at 5 different levels which can be achieved using the transaction code SUIM as well. The 5 levels are SOD at Transaction Code Level reports, SOD at Authorization Object Level reports, Critical Transactions Risk Analysis reports, Critical Role/Profile reports and Mitigation Control reports.

Authorizations: Approval of transactions executed in accordance with management’s generally accepted accounting principles and procedures.

Example of authorizations include a supervisor’s approval using SAP GRC Access Enforcer (Compliant User Provisioning)  that he or she has verified and validated that the activity or transaction conforms to established policies and procedures.

Interface/ Conversion Controls: Interface – Data interfaces transfer specifically defined portions of data between two computer systems and should ensure completeness and integrity of data being transferred.

Conversion:  The process of converting data from one system to a new system.

Key Performance Indicators: Financial and non Financial quantitative measurements that are collected by the company, either continuously or periodically and used by the management to evaluate the extent and progress towards meeting the managements defined objectives.

Reconciliation: A control designed to determine that two items such as computer systems are consistent.

Segregation of duties: SAP has covered this well enough to be known as SAP GRC Access Controls which describes SOD as segregation of duties and responsibilities of authorizing transactions, recording transactions and maintaining the custody to prevent individuals from being in a position to both perpetrate and conceal an error or irregularity.

Management Review: A person, other than the preparer analyzing and performing oversight of activities performed (does not apply solely to management doing the review)

System Access: The ability that an individual or group has within a computer information system processing environment, as defined by access rights configured in the system. The access rights in the system agree to access in practice.

System Configuration/Account Mapping: Configuration – ‘switches’ that can be set by turning them on or off to secure data against inappropriate processing, based on the organization’s business rules.

Account mapping – ‘switches’ that can be set related to how a transaction is posted to the GL and then to the financial statements.

Exception/ Edit Report:

Exception – A Report generated which shows violations of company standards.

Edit – A report generated that shows changes made to a master file.

A very important concept used by auditors is the Financial Statement Assertions.  Auditors use this as a framework to assess the financial statements and present them in a right manner.  Based on the Control Activity and the business value an assertion is used to make sure the business process runs fairly.

Below is a brief definition of each of these Assertions:

 

Consider the below example

The control is about monitoring the changes in the developer keys to detect unauthorized application changes. This control belongs to the Presentation and Disclosure assertion as mentioned in the above table.

Similarly let’s take another example

This control is monitoring changes to the configuration setting that allows or denies General Ledger postings by document types. This control belongs to the Rights and Obligations and Valuation or Allocation assertion as defined in the above table.

For completeness, consider this example

As external auditors continue to conduct tests to verify existence, occurrence or completeness, SAP GRC Process Controls can help you take a complete control over any misstatement in your financial statements.

 

Gary Prewettt wrote this excellent article on SDN. I’d like to share his article here

http://scn.sap.com/community/grc/blog/2014/12/03/starting-fiscal-year-2015-on-the-right-grc-foot

The Public Company Accounting Oversight Board, established by Congress as part of the Sarbanes-Oxley Act, has responsibility to oversee audits by public companies. Since 2012, the PCAOB has been particularly active, and in September of 2014 the PCAOB announced significant changes to auditing standards have been released and take effect for companies with a fiscal year starting December 15th, 2014 or afterwards – less than two weeks from the time of this writing.

 

In addition to changes and proposed changes to accounting standards, the PCAOB has been actively releasing staff guidance in the form of practice alerts, directing additional validation of source reporting assumptions, ensuring that system-generated reports are complete and accurate, and verifying top-down risk assessments are conducted (one auditor acquaintance of mine recently termed the current PCAOB validation process “brutal”).

So What Does this Mean for Me?

Practically speaking, SAP customers publicly traded in the U.S. have been seeing and will continue to see increased scrutiny from their external auditors. So what does this mean for SAP customers with U.S. Sarbanes-Oxley obligations? And in particular, what does this mean for SAP customers with SAP Access Control/GRC in place to monitor separation of duties and automate security design and role assignment?

 

Canned Access Control/GRC reports and rule sets are relatively easy to verify assumptions around completeness and accuracy. That said, the SAP-delivered  rule set is not one size fits all – some high risks for certain industries will be medium risks for others, and vice-versa. For those of you who like to spend this time of year planning strategy for the coming year, I recommend considering the following questions when planning your FY 2015 audit report improvements to stay ahead of trends in SOX reporting requirements:

 

• Have we conducted a top-down risk assessment with high, medium and low SOD risks in our AC/GRC rule set(s) in scope, and have the results been verified and signed off on by senior management? And are we able to trace rule set changes to findings in this risk assessment?
• Mitigating controls are, by design, limited to being effective for one year. Still, many SAP customers will re-apply them for another year without giving a whole lot of thought to the underlying assumptions. Did your risk assessment ensure that the residual risk after mitigating controls is in effect is acceptable? And is there traceability of these management signoffs to your mitigating controls?
• Are my technical controls for my GRC landscape adequately defined and documented? Have we spent time adequately negative testing GRC roles (for example, can mitigating controls owners approve firefighter requests?)
• Have my risk owners been adequately defined by senior management and adequately documented?
• Have my BPOs been adequately defined by senior management?

 

Final Thoughts

The PCAOB practice and standards changes have had and will continue to have an impact; the full extent of that impact has yet to be determined. That said, early compliance will have significantly less organizational impact than mid-year remediation.  It never hurts to plan ahead!

 

Related Reading

http://www.natlawreview.com/article/public-company-accounting-oversight-board-pcaob-selected-auditing-developments

http://pcaobus.org/Standards/QandA/10-24-2013_SAPA_11.pdf

http://pcaobus.org/Rules/Rulemaking/Docket038/Release_2014_002_Related_Parties.pdf

SAP GRC Password Self Service

Password Self Service Configuration in SAP GRC is a secure, web-based, end-user password reset management facility provided to users. This helps domain users to perform self service password reset  and employee self update of personal details. The user need not have a GRC user account and instead log in via the Active Directory User ID and change passwords for any target system connected to the GRC system. For example, If I need to allow my end users to change ECC Production System password on their own and not call or email helpdesk they can use the self service password functionality in SAP GRC to easily change passwords. Now, the questions lie in how to configure this in GRC system. Let’s take a look at this…

Check the PSS tick mark for the system you want to be able to PSS in this path IMG > Governance, risk compliance > maintain connector settings > choose the connector you like to turn on the PSS funcitonality

Maintain these services in tcode : SICF

1.)GRAC_OIF_MY_PROFILE_EU

2.)GRAC_GAF_NAME_CHANGE_SERV_EU

3.)GRAC_POWL_REQUEST_STATUS_EU

4.)GRAC_GAF_PWD_SELFSERVICE_EU

5.)GRAC_OIF_USER_REGISTER_EU

6.)GRAC_GAF_ACCREQ_WITH_REQREF_EU

7.)GRAC_OIF_REQUEST_SUBMISSION_EU

8.)GRAC_GAF_ACCREQ_WITH_TEMPL_EU

9.)GRAC_GAF_ACCREQ_WITH_USEREF_EU

10.)GRAC_UIBB_END_USER_LOGIN

 

Enter the number of questions and number of attempts as shown below. IMG > Governance, risk, compliance > access control, user provisioning > maintain password self service

 

Register the question as shown above.

 

Leave this empty if HR is not being used.

click on Activate End User Logon as shown above

Right click on the service > test service > obtain the link

Update the Logon tab with the service user ID and password so the end users need not have a GRC account. They can directly go to the link as shown in the above screen shot.

Enter the credentials (LDAP) – (above) and let the user register the answer for the questions in the link “Register SELF service Questions” and then click on password self-service.

 

Answer the question as shown below.

 

This question was configured in SPRO as shown below

 

Click on password self-service in the below End User Logon page.

 

Choose the system as shown above

 

Change your password in the respective system

How to Restrict PSS questions to admin only in GRC 10.1

there is an option to disable “Register Self Service Questions” from End User Screen read : 1600374 – CUP: Admin and user questions option not configurable in PSS

 

 

SAP GRC Access Controls – Helping You Visualize the Big Picture

GRC is a discipline that aims to synchronize information and activity across governance, risk management and compliance in order to create efficiency, enable more effective information sharing and reporting and avoid wasteful overlaps. However, there are two very common challenges that every organization faces when using the very technical GRC system.  For one, GRC reports are typically difficult to customize and require additional resources to identify the right information and then get in into the right hands.  Secondly, most organizations experience a disconnect between the business and technical aspects of the solution, meaning business teams and IT don’t communicate and collaborate as effectively as needed to connect the dots and optimize the solution’s powerful capabilities.

 

 

Ruleset

Rule sets define categories or groupings of rules. A rule set is used for determining the group of access risks that are to be used when running an access risk analysis. Several Rules are combined together in a Ruleset. The Rules are available as Rule ID in a separate table called GRACACTRULE. The Ruleset Information is available in table GRACRULESET.

 

 

A newly installed GRC system comes with a starter package of Rules bundled in a Ruleset called “GLOBAL”. Note: It is important to activate a BC set to fill the GRACRULESET tables with standard SAP Data.

 

Rules

 

The purpose of Risk Recognition is to determine and classify risks, and to construct rules that determine the existence of these risks in analyzed objects, such as users, roles, profiles, and so on. Actions and permissions combine to form functions. Functions in certain combinations result in a risk. Risks are associated with business processes and all the components come together to form rules.

 

 

 

Rules in GRC can be uploaded using transaction code GRAC_UPLOAD_RULES, generated for the specific Risks using tcode GRAC_GENERATE_RULES, delete rules using tcode GRAC_RULE_DELETE. GRC 10.1 can now allow you to transport rules using tcode: GRAC_RULE_TRANSPORT.

Functions

Functions are the building blocks of access risks. They define a collection of one or more tasks that an employee needs to complete to perform a specific goal. These tasks are called Actions. When you define a function, you associate one or more actions to the function. Each of these actions has an associated permission (security object) that defines the scope of access for the action.

Functions – Actions

Functions and Actions are related to each other using the table GRACFUNCACT. This table shows the relationship between the Function ID and the associated Actions (Transaction Codes) including the connectors or the target systems as shown in Picture 4 where the Actions are associated. GRACFUNC is the parent table which holds the Function Information.

 

Functions, Actions and Permissions are related using the table GRACFUNCPRM. This table shows the relationship between Functions, the associated Transaction codes or Actions and the Authorization Objects for the tcodes as shown in Picture 5. The connector information is available as well which helps to determine the source of the Transaction codes and Authorization Objects

Business Process

Business Process is a key component in the Access Controls Architecture. Risks and Functions are associated with a Business Process for example, Risk ID’s related to Finance are assigned the business process Finance. Functions that are associated to a specific Risk is associated to a specific business Process. This relationship between the Functions and Business Process is stored in a table called GRACBPROC. The other tables where the risks and functions have the Business Process information are GRACFUNC and GRACSODRISK.

 

 

Owners

Risk Owners are stored in table GRACOWNER. Every Risk ID is associated with an owner which indicates the responsibility or the ownership of the Risk’s in the system.

 

 

 

 

what did you think about this article ? let me know…