mis$5121:business$processes,$erp$systems$&$controls …

MIS 5121:Business Processes, ERP Systems & Controls Week 12: System Development Controls

Edward Beaver [email protected]

ff

Exam 2 Test Results

•  Results will be ‘curved’ to Max high score vs. perfect score of 38.25

•  Final Exam will have long Rme limit

0

1

2

3

4

41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25

Exam 2 Results

MarkeRng / Sales Customers

Supplier s

Supply Chain

Finance / HR Accounts Receivable

Billing

Accounts Payable

Procurement Conversion Warehouse DistribuRon

Customer Service

Reqmts

Invoice Verify

Goods Receipt

Purchase Order

Procurement at GBI Purchase to Pay Process

Vendor / Sourcing

Payment

The Many Flavors of Procurement •  Materials / Raw Materials •  Labor Services •  Other Services •  Leases / Rentals •  Supplies (Office, Maintenance, ProducRon, …) •  LogisRcs •  InformaRon Technology •  No PO •  Inter-‐company vs. 3rd Party •  AcquisiRons

MarkeRng / Sales Customers

Supplier s

Supply Chain

Finance / HR Accounts Receivable

Billing

Accounts Payable

Procurement Conversion Warehouse DistribuRon

Customer Service

Inquiry

Payment

Invoice

Delivery / Shipment

Order

Order to Cash at GBI

The Many Flavors of Sales Order •  Standard Orders •  Free of Charge (samples, compensaRon) •  Services / Not delivery related •  Consignment •  Miscellaneous Sales (Assets, RM’s, Leases, etc.) •  Returns •  Debit memo •  Credit Memo •  Rebate Seelement •  Special country / tax scenarios

Environment Favorable to Fraud Framework for spofng high-‐risk situaRons

Fraud!

Ra5onaliza5on

Fraud Triangle

•  Perceived opportunity (I can do it / conceal it and not get caught) Ø  Poor internal controls Ø  Lack of oversight

•  Incen5ve or Pressure (Financial or

emo5onal force pushing to commit fraud) Ø  Meet expectaRons Ø  Avoid criRcism Ø  Cover a mistake Ø  Personal failures, needs

•  Ra5onaliza5on (Personal jus5fica5on for

dishonest ac5ons) Ø  Low compensaRon Ø  Company is profitable

MIS 5121: Business Process, ERP Systems & Controls Real World Control Failures: Adelphia Fraud

By: James Levan

Control Failure: Adelphia •  Background:

v  Adelphia was the 6th largest cable company in the U.S v  The family that founded the company was using company funds for personal assets

•  Control Failures: v  Lack of segregaRon of duRes-‐ Rigas family controlled voRng rights and made all company decisions v  No system of checks and balances for company spending-‐ used funds for pleasure purchases v  The spending verificaRon process was completed by members of the family v  No accounRng standards used-‐ manipulated books for desired results

•  Results: v  The CEO, John Rigas is currently in jail facing criminal charges v  Adelphia filed for bankruptcy and no longer provides cable to customers v  Company is no longer listed on the New York Stock Exchange

•  What Could / Should those in Authority Have Done Different?: v  There should have been other people involved on the board of directors and in company decision

making v  Deloiee who audited Adelphia-‐ should have been more thorough in its financial statement audit

•  Reference: v  hep://www.wsj.com/arRcles/SB1027516262583067680

Ceo-‐ John Rigas

MIS 5121: Business Process, ERP Systems & Controls Real World Control Failures:

By: Vinh Nguyen

Control Failure: Peregrine Systems

•  Background: v  CA based enterprise sonware company (founded in 1981)that specialized in

change mgmt., IT service mgmt., and asset mgmt. sonware v  Grew to a global company and at its peak in 2000, was valued at $3 billion and

had 4500 employees v  CEO – Stephen Gardner v  CFO – Maehew Glass

•  Control Failures: v  Did not follow Generally Accepted AccounRng Principles (GAAP)

v  Improper recording of revenue v  Improper treatment of A/R

v  Failure to inform investors/stakeholders of Peregrine’s true financial situaRon v  Lead to an arRficially inflated stock price

v  Internal/External Audit failures

Control Failure: Peregrine Systems

•  Results: v  KPMG replaced Arthur Andersen and quesRons revenue sources (2002) v  Filed for Chapter 11 Bankruptcy, 1400 employees laid off, and $4 billion in shareholder

equity lost v  Acquired by HP in 2005 v  CEO – sentenced to 8 years and CFO – sentenced to 5 ¼ years v  Contributed to the need for Sarbanes-‐Oxley Act of 2002

•  What Could / Should those in Authority Have Done Different?: v  Governance – “Tone from the Top” – CEO and CFO gave go ahead for improper revenue

recogniRon v  Follow strict adherence to compliance laws (at the very least)

v  Increased involvement of Board of Directors v  CommunicaRon between board of directors and CFO/Finance Lead should be open

v  Board only sessions/Audit Commieee v  Due diligence from internal and external auditors

•  Reference: v  heps://www.sec.gov/liRgaRon/complaints/comp18205.htm v  heps://www.wi.gov/news/pressrel/press-‐releases/execuRves-‐and-‐auditor-‐of-‐peregrine-‐systems-‐inc.-‐indicted-‐on-‐

securiRes-‐fraud-‐charges

MIS 5121: Business Process, ERP Systems & Controls Real World Control Failures: Kingfisher Airlines | Vijay Mallya

By: DEVANG MEHTA

Control Failure: Inflated ValuaRons •  Background: KINGFISHER AIRLINES | Vijay Mallya

v  Started OperaRons in 2005. Awarded 5 stars by Skytrax. Only 1 profitable quarter. v  Defaulted on payments, salaries, taxes. v  MulRple failure of Controls: Top Down / Banking / Government / who else?

•  Control Failures: v  Over ValuaRon of Assets when the company was making losses – Grant Thornton is the Auditor. v  Single handed control of the enRre enterprise. v  No whistle blowing by the senior management,

•  Results: v  Vijay Mallya is currently in UK negoRaRng a seelement for restructuring. v  Grant Thornton’s audit report under scruRny. v  Accumulated dues to the bank of $2 billion dollars, Accumulated loss

•  What Could / Should those in Authority Have Done Different?: v  A more transparent audit report by Grant Thornton v  ProacRve acRon by the banks, courts and the tax departments v  Senior Management should have more control.

•  Reference: v  hep://www.businesstoday.in/topics/kingfisher-‐crisis v  hep://www.livemint.com/Companies/LFg1OtbDqCjTdK980JrRhP/The-‐airline-‐that-‐grounded-‐an-‐empire-‐Kingfisher-‐

Airlines-‐and.html

Control Failure: Inflated ValuaRon •  Other Facts: KINGFISHER AIRLINES | Dr. Vijay Mallya

v  Announced KFA was not in transportaRon business but in hospitality business v  Personally chose the Air hostesses. InstrucRons were that passengers were to be treated as his own

guests. v  Launch was closer to his son Sid Mallya’s 18th birthday. Was a gin to him v  Personally involved in Kingfisher Calendar Girls shooRng. v  Kingfisher Calendar Charts : Link

v  video

MIS 5121: Business Process, ERP Systems & Controls Real World Control Failures:

By: Jiehong Huang

Control Failure: Crazy Eddie •  Background:

v  Was an American retail business that sold electronic goods v  Founded in 1971, Went public in 1984 v  Ceased operaRons in 1989 v  Family business, turned into the largest electronic chain in the New York metropolitan area

•  Control Failures: v  Crazy Eddie had been skimming cash for years v  Inflated its stock price by adding imaginary stock and falsifying accounts v  False financial statements propelled its stock to $79 a share form $8

•  Results: v  The Stock fraud caused company bankruptcy v  A federal invesRgaRon showed that the company stole investors more than $145 million v  Eddie Antar was arrested in Israel and two brothers were accused of a scheme

•  What Could / Should those in Authority Have Done Different?: v  SeparaRon of operaRon and ownership v  Hiring professional managers to run the business v  Investors should request a third party to run an external audit when the company went public

Control Failure: Crazy Eddie

•  Reference: v  hep://www.nj.com/news/index.ssf/2012/03/the_long_and_wild_crazy_eddie.html v  hep://www.nyRmes.com/1993/07/21/business/crazy-‐eddie-‐founder-‐guilty-‐of-‐fraud.html v  hep://whitecollarfraud.com/crazy-‐eddie/crazy-‐eddie-‐fraud/

MIS 5121: Upcoming Events

•  Reading Assignment 7 – Due: Yesterday •  Reading Assignment 8 – Due: April 17 •  Reading Assignment 9 – Due: April 24

•  Guest Lecture: Auditor’s PerspecRve -‐ April 18

•  Guest Lecture: SAP What’s New (HANA) -‐ April 25

MIS 5121: Auditor’s Visit Topics •  _____

•  _____

•  _____

•  _____

•  _____

•  _____

MIS 5121 : Auditor’s Topics 2015 •  What are the general methodologies used for audiRng? •  How do you classify risks? •  How do you review SegregaRon of DuRes (modules vs. employees)? •  Have you personally detected a fraud scenario in your audit? If so,

please explain •  How do you maintain your independence? Is that easy? •  What is your opinion on cyber-‐security laws being considered by

the US government (CIA, CISA legislaRon)? •  How easy it it for an auditor to commit fraud? •  Does SAP provide good control environment vs. other systems

(ERP, other)? •  Since SAP can be customized in so many ways, how does an auditor

know what to audit when everything is different with each client?

System and IntegraRon Controls

22

Key InformaRon Technology Risks

•  System Security •  Data Migra5on •  Data Interface •  Change Management •  Transport Security •  Instance Profile Security •  Table Security •  Data Dic5onary, Program and Development Security •  Informa5on Security Administra5on •  Logs and Traces •  Firefighter access •  Powerful User ID’s and Profiles •  Background Processing (Batch vs. foreground: real-‐Rme)

Table Security

Ø  Tables are Integral part of SAP ApplicaRon ²  Different Types of Data

§  System Tables (T000 – Clients, TDDAT – Table AuthorizaRon groups, USOBT_C – PFCG TransacRons and Auth Objects)

§  ConfiguraRon / Control (T001 – Company codes, T001W – Plant Codes, TVAK – Sales Document Types)

§  Master Data (MARA – Material Codes, KNA1 – Customer Master: General)

§  TransacRon Data (VBAK – Sales Doc Header, VBAP – Sales Doc Line Item, EKKO – Purchasing Doc Header)

²  Client-‐dependent and Client-‐independent 28,610+ Tables in SAP

Client Dependent vs. Independent

Dev 100 Master (Gold)

-‐  Master Data -‐  TransacRon

Data -‐  User

Management / Data

Dev 110 Dev Test


Data -‐  User

Management / Data

Dev 180 Data Conversion


Data -‐  User

Management / Data

Dev 900 Sandbox


Data -‐  User

Management / Data

Client Independent Ø  Programs (ABAP) > Repository Objects (Client Independent Config Ø  Data Dic5onary -‐ Currency, UOM’s Ø  Parameters -‐ Pricing Tables Ø  Authoriza5on Objects > Transac5ons

Client Dependent System/Instance

SAP: Table Driven System ExecuRon Ø  SAP Processing is customized using thousands of

Configura5on tables §  Access via the ‘ImplementaRon Guide’ (TransacRon SPRO) §  Entries determine how transacRons are processed §  Entries also support implementaRon of controls (e.g. processing

parameters and limits)

Ø  ERP Systems are Dynamic §  ConfiguraRon table values and therefore system processing, are

conRnually changed (process changes, business structure, etc. §  EffecRve processing and control Requires:

o  Managed Design o  DocumentaRon

Table Security

Ø  Control Concerns ²  Access to maintain / modify table entries ²  AuthorizaRon group assignment (esp. custom tables) ²  Logging of changes (certain criRcal tables only) – next

secRon

Risk and Recommenda5on Table Security

Risks: Ø  Many tables (e.g. config) control how programs funcRon. Changing them

equivalent to changing a program Ø  Direct table changes bypass security, coded edit checks. High potenRal for

corrupt data and compromise ‘un-‐alterability’. Changes to client-‐independent tables could have unexpected side affects (affects all clients).

Ø  Users with update access to table entries can modify customized tables not assigned to specific authorizaRon group

Recommenda4ons: Ø  Changes to configuraRon tables, table structures and certain system table

entries should be made in DEV, tested in QA and migrated to PRD per change management process

Ø  Direct access to maintain tables restricted to very few individuals Ø  Assure &SAP_EDIT backdoor change access in SE16N is DeacRvated Ø  All criRcal tables assigned to an AuthorizaRon Group to prevent users not part

of that group from accessing them (even for ‘display’ only)

Risk / Control Matrix: Design Approach

Risks

Control ObjecRves

Control, system and Security Design + ImplementaRon §  Automated Controls §  Manual Controls §  ApplicaRon Security §  SegregaRon of DuRes §  Approvals §  Reports §  Procedures

CONTROL DESIGN

Define

Drive

Influence

Control AcRviRes / Controls

Controls: IntegraRon Points

IT / Security

Security ConfiguraRon

Automated (Access) Control

SOX SecRon 404 IntegraRon

Subset

Risk/Control Matrix can serve as the primary vehicle for integraRng control design into project acRviRes and deliverables

Program Development

FuncRonal Spec

Technical SpecificaRon

Automated (Custom) & Manual Controls

Business Process Teams

Bus Process Reqmts

Training & Procedures

Manual Controls

Security Analysis Tool

SegregaRon of DuRes

SOD Controls & SensiRve Access

GRC

Automated: Standard & ConfiguraRon

Risk / Control Matrix

Program & Development Security Ø  Types of Development Objects (FRICE)

²  Forms – outputs (invoices, Purchase orders, ...) ²  Reports – custom reports ²  Interfaces – SAP to other systems ²  Conversions – Data migraRon ²  Enhancements – Change system logic, use addiRonal fields, etc.

§  User-‐Exits: defined SAP branches to custom code (lower risk) §  Change SAP code (high risk, long term extra maintenance)

²  Workflow – non-‐config components, logic Ø  Development: custom programs

²  Typically ABAP (SAP SQL extension programming language)

Program & Development Ø  ABAP can be a ‘black box’ – Control Concerns

–  Unauthorized execuRon of Business Logic – bypassing security and SOD design. –  Unauthorized read access to business and configuraRon data – Could allow

then of criRcal data (e.g. credit card info) and be illegal –  Unauthorized modificaRon of business and configuraRon data

•  Violate principal of change documents (Unalterable -‐ not able to be changed or deleted) •  DeleRon of data can be illegal

–  RepudiaRon of Business Process (denial of the truth or validity of something) – Legal requirements require non-‐repudiaRon regarding creaRon of and change to business transacRon and master data.

–  IdenRty Then – Unauthorized access to customer master data could lead to idenRty then and impact the data privacy and even criminal laws.

–  Denial of Service – Auditors must communicate quesRonable findings to protect the investors and stakeholders and where violaRon is intenRonal criminal law is invoked.

Ø  Is program code ‘good’ ²  Does what it’s supposed to do ²  Limited to requirements only (not branch off to perform other

nefarious acRons) ²  Well-‐behaved: doesn’t mess up other programs, logic, operaRon of

ERP system

Ø  Good Development PracRces ²  Clear, documented, approved requirements defined before coding ²  Define Requirements, Design Logic before major coding (e.g. use of

funcRon modules for common logic) ²  Peer Code Reviews ²  Experienced development leadership ²  Test, Test, retest BEFORE moving to PRD (strong change management

governance)

Program & Development Security

Program & Development Ø  Other Control Concerns

²  Access to run ALL programs granted rarely and appropriately

²  Secure Programs §  ‘Authority Check’ inside the Code §  AuthorizaRon Group assigned to program

²  Development access (developers ‘key’) granted only in DEV ²  Programs unit tested in DEV, integraRon tested in QA and migrated to PRD per

change management process

²  Limit Development and Debug access in PRD §  Debug access can provide unsecured view of tables §  Debug access also can compromise ‘un-‐alterability’ via allowing deleRng

of table entries.

Risk and Recommenda5on Program Security

Risks: Ø  Unintended, nefarious uses of program code Ø  Users capable of execuRng programs directly can compromise standard

controls (access security, audit trails) Ø  Users with access to run ALL programs are allowed to run all executable

programs (note not all programs are executed directly) Ø  Display access to ABAP code gives backdoor access to program execuRon Ø  Debug authority provides unsecured table viewing and table change

Recommenda4ons: Ø  AcRve review, manage program code deails Ø  Access to run programs restricted via SAP Security / AuthorizaRons Ø  Further secure programs via assignment to authorizaRon groups Ø  Basis Admin no Display access to ABAP code (prevent backdoor access) Ø  Debug authority restricted to effecRvely monitored ‘emergency users’


IT / Security




Subset


Program Development

FuncRonal Spec




Bus Process Reqmts


Manual Controls


SegregaRon of DuRes


GRC



Data DicRonary Security

Ø  Central Catalogue of: ²  Data definiRons and descripRons ²  RelaRonships between data

elements / structures ²  RelaRonships between data and use in programs and screens

Ø  Control Concerns: ²  Data DicRonary changes could affect the data integrity in system ²  Access to make changes needs to be restricted to appropriate

individuals ²  S_DEVELOP AuthorizaRon object controls acccess to create /

maintain / delete APAP dicRonary & repository objects

Ø  Also called ABAP/4 DicRonary in SAP

Risk and Recommenda5on Data DicRonary

Risks: Ø  PRD Access to S_DEVELOP Allows direct changes to Data DicRonary

which could compromise integrity of the data Ø  Any Data DicRonary change could compromise integrity of the data

Recommenda4ons: Ø  No one (including Basis Administrators) should have update access to

Data DicRonary in ProducRon (PRD) Ø  Changes to data dicRonary performed in DEV, tested in QA and

migrated to PRD per change management process Ø  Developer access restricted appropriately using SAP Security /

authorizaRon concept

InformaRon Security AdministraRon Ø  Security AdministraRon can be:

²  Centralized ²  Decentralized ²  Hybrid of both

Ø  Control Concerns: ²  Segregate:

§  Role Development §  User AdministraRon (Assign Roles, change).

²  Do not Develop / Change Roles directly in PRD §  Develop and unit tested in DEV, integraRon tested in QA and migrated to PRD per

change management process

Risk and Recommenda5on InformaRon Security AdministraRon

Risks: Ø  If User AdministraRon access is not limited, higher risk of unauthorized

and excessive access in SAP Ø  No SegregaRon of User AdministraRon tasks, higher risk of inaccurate

or unauthorized access assigned to users and profiles in SAP

Recommenda4ons: Ø  Define Owners of all SAP systems, clients and data or Processes Ø  System and Client Owners responsible for:

§  Approving all changes to their systems / clients §  Authorizing overall access to the system

Ø  Data / Process Owners responsible for: §  Control of overall data / process components in the systems / clients §  Authorizing specific access to data / processes within the PRD system

Ø  Same people do not have access to create, maintain and assign roles Ø  Role CreaRon or maintenance not performed in PRD environment

System Logs and Traces Ø  Need to be acRvated to exist Ø  System Audit Log can be set up (SM19) to record:

²  Successful / unsuccessful Dialog logon aeempts ²  Successful / unsuccessful RFC logon aeempts ²  RFC calls to funcRon modules ²  Changes to user master records ²  Successful / unsuccessful TransacRon starts ²  Changes to the audit configuraRon

Ø  System traces (ST01 / ST05) for: ²  Database access ²  ABAP/4 programs ²  Internal system acRvity ²  Developer traces ²  RFC Calls

SAP Integrated Change Log

Ø  Built into most system documents (e.g. Sales Order, PO, Delivery, …)

Ø  ConfiguraRon to turn on/off some changes

Ø  Data Stored in tables – available for subsequent reporRng

Ø  ‘Big Brother’ is watching?

Ø  Excellent for problem diagnosis

Risk and Recommenda5on System Logs and Trace Files

Risks: Ø  If audit files (Logs and traces) are not secured at the operaRng system

level for each applicaRon server, they could be maliciously deleted

Recommenda4ons: Ø  Secure folders where log and traces files are stored at the operaRng

system level Ø  Develop and use procedures for how to review and run traces at part

of rouRne system security monitoring

Table Logging Ø  In addiRon to system change logs

supports traceability Ø  Needs to be acRvated in system to

exist Ø  Can be acRvated individually by

table via SE13 ²  Concern: for high change rate tables

logs fill up fast

Key IT Controls Overview

•  Table, Security AdministraRon –  2-‐3 risks that exist –  Common control recommendaRons for each

•  Program, Development, Data DicRonary –  2-‐3 risks that exist –  Common control recommendaRons for each

Assignment QuesRons •  How common are missing or faulty authorizaRon checks? •  Explain the difference between the IT general applica5on controls and the IT

general controls. •  Is it possible for a fraudulent user to make a copy of the logs and reinstall them into

the system in order to delete the originals to hide a fraudulent act, or would there be a “protected” log system that would sRll record this acRvity?

•  What is the importance of the principle of inalterability? •  According to the principle of unalterability, some certain fields won’t allow to be

changed. What should the staff do if an emergency is happening and he needs to make the change to the document?

•  Since we can change documents in SAP, so how we change the pos5ng date in SAP if we forget to select date and SAP set it as a default date?

•  What tools allow a company to easily monitor, capture and review logs? •  When the cost of implemenRng a compliance control is higher then the benefit

obtained, what must an organizaRon do to ensure efficiency and profitability?

SAP Environment Security Components

Network Security

SAP ApplicaRon Security

OperaRng System Security

WorkstaRon Security

DataBase Security

Assignment QuesRons •  How much automated controls should be desired? Is it beneficial to consider

controls at design phase or are controls introduced as and when needs arise? •  Who in a company is primarily responsible for the idenRficaRon and monitoring of

SAP related control? •  What kind of vulnerabiliRes are associated with RFC communicaRon? •  Could you please explain how to segregate the duRes related to applicaRon control? •  Who generally has the access to debug acRviRes and how does it work? •  Debugging is risk area but is criRcal for applicaRon support and maintenance. What

controls are most relevant in real life scenario? •  What should be done in the case logs are deleted and they cannot be retrieved? •  For my understanding, applicaRon only works on system generated/ recurring

transacRon data. For manually post data, is only control to perform an audit ? •  How does the abuse of the principle of least privilege for the individual Basis

authorizaRons represent as a high risk for the availability of SAP system and for the integrity and consistency of the data and the processing logic?

Assignment QuesRons •  If a business catastrophe like Cantor Fitzgerald on 9/11 happened today, how would

the company protect its data, and who would access it in an emergency assuming that corporate leadership, or those normally authorized were incapacitated or deceased?

•  What are in common between external document number assignment and internal document number assignment?

•  What applicaRon control do you think is the best? To me, I believe it is the logging features, although they most likely aren’t used as much as they should be

Break Time

Risk / Control Matrix Final Exercise

52

Risk / Control Matrix: Design Approach

Risks

Control ObjecRves

Control, system and Security Design + ImplementaRon §  Automated Controls §  Manual Controls §  ApplicaRon Security §  SegregaRon of DuRes §  Approvals §  Reports §  Procedures

CONTROL DESIGN

Define

Drive

Influence

Control AcRviRes / Controls

•  Agenda – Last Class (April 4): Part 1 -‐ IdenRfy Risks – This Class (April 11): Part 2, 3

•  Risk Priority (Severity & Likelihood) •  IdenRfy Controls •  Link Controls to Risks

– April 18: Part 4 -‐ Complete Control DefiniRons – April 25: Part 5, 6 -‐ Control Process / Audit Details; Personal QuesRons

– Due April 28 11:59 PM: Assignment Submission

Risk / Control Matrix: Final Exercise


Part 1: a)  Analyze the key risks that exist for the Order to Cash

(OTC) process at GBI b)  Define and document the key risks that exist for the

Order to Cash (OTC) process at GBI §  Tab: Part 1 – GBI Risks §  IdenRfy at minimum 25 risks in the process §  IdenRfy a minimum 4 risks in each of the OTC sub-‐processes:

ü  OR&H: Order Receipt and Handling ü  MF: Material Flow (shipping) ü  CI: Customer Invoicing ü  PR&H: Payment Receipt and Handling


Part 2: IdenRfy key controls for the Order to Cash (OTC) process at GBI

§  Tab: Part 2 – GBI Controls §  IdenRfy at minimum 15 controls for the process §  IdenRfy a minimum 3 controls in each of the OTC sub-‐

processes: ü  OR&H: Order Receipt and Handling ü  MF: Material Flow (shipping) ü  CI: Customer Invoicing ü  PR&H: Payment Receipt and Handling

§  At least two (2) controls must be Automated / Config controls


Part 3: Link Risks (Part 1) to the Controls (Part 2) §  Tab: Part 1 – GBI Risks §  At least one (1) control must be idenRfied for each risk

idenRfied as High Severity or High Likelihood / Frequency §  A given control may address mulRple risks (listed once in Part 2

tab and mulRple Rmes in Part 1 tab) §  A given risk may be addressed by mulRple controls (listed once

in Part 1 tab and mulRple Rmes in Part 2 tab) §  Risks without out a control:

²  Acceptable Risk: Business agrees no controls will be developed ²  TBD (To Be Determined)

Extra Slides

Change Documents

Ø  Change ‘log’ stores informaRon on changes made to master data and transacRon data via standard transacRons (Miss direct table maintenance changes)

Ø  Permanent record and audit trail for transacRons executed in SAP

Risk and Recommenda5on Change Documents

Risks: If users are not restricted from maintaining change documents, the system audit trail from changes documents could be deleted accidentally or via malicious intent

Recommenda4ons: Users in producRon have acRvity level of security object S_SCD0 set to ‘08’ (Display Change Documents). InvesRgate ways access to maintenance of change documents could be further restricted (locking transacRon)

SAP System CharacterisRcs

63

Integrated Database

Ø  All transacRons stored in one common database in thousands of tables

Ø  Module automaRcally create entries in other modules (e.g. OTC creates financial posRngs)

Ø  Auditors need to understand the flow of informaRon Ø  Databases can be accessed by any module Ø  Users view the system as TransacRons, documents

and reports Ø  SAP modules are transparent to users

Technical Environment

Technical Complexity Ø  System usually resides on mulRple computers

²  Using different servers and databases ²  CoordinaRon is a challenge

Ø  Legacy systems may be interfaces Ø  Distributed systems and bolt-‐ons contribute to

complexity

§  A §  B

Processing Ø  TransacRons processed by the system iniRate new

transacRons and posRngs automaRcally (event driven) Ø  If iniRaRng transacRon is invalid, inaccurate or incomplete

that can have significant impact on the organizaRon ²  Suggests needs for preventaRve controls rather than detecRve

controls

Ø  Data entry accuracy improved through use of default values, cross-‐field checking and alternate views into the data

Ø  SAP uses online real-‐Rme processing §  TradiRonal ‘batch’ controls / processing and audit trails are no longer

available §  Period closing will be different in SAP

COSO Framework (2013)


IT / Security




Subset


Program Development

FuncRonal Spec




Bus Process Reqmts


Manual Controls


SegregaRon of DuRes


GRC



Parts 1.  Analyze and define the key risks that exist for the Order to Cash (OTC)

process at GBI 2.  Guided by the risks you idenRfied (esp. the High Severity and High

Likelihood / Frequency risks) idenRfy the key controls that will be used in the OTC process.

3.  Link the Risks from Part 1 to the controls in Part 2. 4.  Complete definiRon of the controls (classificaRons, links to asserRons,

etc.) 5.  Write auditable control process documentaRon for 1 manual and 1

automated (configuraRon) control idenRfied. 6.  (Individual vs. Team submission): Couple quesRons about your work as a

team to complete this and other exercises. (OpRonal) Details will be announced via a blog post in last couple weeks of class.
