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
-‐ Master Data -‐ TransacRon
Data -‐ User
Management / Data
Dev 180 Data Conversion
-‐ Master Data -‐ TransacRon
Data -‐ User
Management / Data
Dev 900 Sandbox
-‐ Master Data -‐ TransacRon
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
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’
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
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
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
Risk / Control Matrix: Final Exercise
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
Risk / Control Matrix: Final Exercise
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
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)
COSO Framework (2013)
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
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
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.
Risk / Control Matrix: Final Exercise
Top Related