Вы находитесь на странице: 1из 58

“Hypercare”: How to Handle Security and

Control Requirements Immediately After a


Major System Implementation or Upgrade-
Related Go-Live

Holly Marrs
PwC
Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.
In This Session

Cutover Stability
Hypercare
Planning Metrics

Controls Leveraging Key Audit


Approach GRC 10.1 Focus
1
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

2
Hypercare Definition

When companies undertake a major implementation or upgrade, the most visible goal is a
timely and successful go-live with minimal disruption for the business. Oftentimes, this
leads to an intense (and often stressful) period immediately after go-live called “hypercare”.

• Definition: The period after go-live is often referred to as hypercare and it can be
extremely risky to the success of an implementation. This is a period of time where the
project team provides extended support for the business to work through issues
encountered when cutting over to the new system. Hypercare typically extends 30-90
days after go-live.

Risk: When project teams are so focused on helping the company maintain business-as-
usual activities, control deficiencies go unnoticed until it is too late!

3
Hypercare Definition (cont.)

• During the first few months after go-live, clients will make dozens of choices that could
have immense impacts on:
• Securing the system properly
• Relying on transactions posted in the system
• Their ability to pass audits
• With so many moving parts such as mass data loads, user training, increased volume of
system changes, and elevated access …
• How do companies maintain compliance to IT general controls during such a critical
time?
• How do companies work with both internal and external audit to demonstrate modified
controls unique to this go-live scenario?
 Answer: Plan ahead and utilize SAP Access Control and Process Control

4
Hypercare Definition (cont.)

• Areas to focus on during hypercare:


 Confirm business-as-usual is working
 Manage defects
 “Trained” project team members should train employees
 Roll off vendor support (knowledge base)
 Some team members should focus on next phase rollouts by addressing “lessons
learned” while designing and supporting
 Execute and manage new internal control framework

5
Hypercare Definition (cont.)

• Example risks and issues often faced during hypercare:


• Resource constraints (internal vs. vendor)

• Lack of knowledgeable subject matter experts

• Lack of training (e.g., materials, reference guides, in-person)

• Issue prioritization

• Emergency access needs can result in excessive privileged access

• Response times for support can be delayed

• Phase rollouts introduce additional security and training risks

• Control integration and SOX compliance may not be a top priority

• Emergency support can lead to control gaps

6
Hypercare Definition (cont.)
Risk Factors: People
• Lack of executive level support/awareness to post go-live criticality
• Lack of dedicated business process and technical professionals
• Lack of sufficient involvement from the business process owners in the hypercare
phase
• Lack of necessary ERP expertise on the implementation team (including management
and readiness partner)
• Insufficient training for end users
• Importance of change management is underestimated or done ineffectively
• Lack of effective knowledge management
• Insufficient governance strategy around segregation of duties, master data, and
reporting
7
Hypercare Definition (cont.)

Risk Factors: Process

 Lack of a formalized project office responsible and accountable for inventorying,


prioritizing, and monitoring the various competing problems that arise
Risk Factors: Technology (SAP)
• SAP security is not addressed proactively to design a strategy that balances costs
associated with controls and maintenance
• Risk associated with SAP default functionality is not addressed (SAP*, SAP_ALL,
SAP_NEW, RSPARAM vulnerabilities)
• Lack of negative security testing to identify unintended combinations of access
granted
• Interfaces are not tested thoroughly
• Reports are not readily available to support the various processes
8
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

9
Cutover Planning

• During the cutover window, several circumstances will be presented that are outside of
the normal expectations for the systems and business process environment. Examples of
this may include:
• Data Management/Conversion:

• Mass data loads will be occurring through either automated conversion programs or

manual process steps


• Change Management:

• There is a high likelihood that the volume of changes introduced to the live

environment will be higher than normal and the speed with which those changes are
migrated to production may be significantly faster than in a stable environment
• The production environment may be open more often or for more extended periods

of time, which may allow for change management to be circumvented

10
Cutover Planning (cont.)

• During the cutover window, several circumstances will be presented that are outside of
the normal expectations for the systems and business process environment. Examples of
this may include: (cont.)
 Sensitive Access Management :

 Access issues may be encountered through introduction of new end-user security

roles. This may increase the likelihood of granting excessive access to business
users so that transaction processing can occur or significantly increase usage of
Firefighter.
 For organizations in a phased implementation approach, there will likely be live

business units/locations in addition to those that are being cutover into the system.
Access granted to project team members for cutover purposes can create exposure
to all locations or units that are live.

11
Cutover Planning (cont.)

• During the cutover window, several circumstances will be presented that are outside of
the normal expectations for the systems and business process environment. Examples of
this may include: (cont.)
 Segregation of Duties (SoD):

 Project team members may be granted update access to business transactions in

the production environment and this is not advised. This access may create
Segregation of Duties (SoD) violations, grant access to sensitive information, or
grant access to transaction codes/authorizations that may not be in production
roles.

Plans may have been well articulated for controls and security after go live; however, a
number of unexpected factors may lead to the controls failing and the security controls not
operating as management intended.

12
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

13
Stability Metrics and Reporting
Prepare and track Hypercare Readiness Scorecard for go-live
Phase 3,
Criteria Phase 1 Phase 2 Notes and Actions needed for 100%
etc.
Processes • Control integration, training
Tools • SAP AC/PC monitoring
Reports • Defect Report, EAM Report
Roles &
• Training team, support team, audit, etc.
responsibilities
Staffing Plans • Global 24 hour “war room” support for week 1
Coverage Plans • Continue weekly update
Infrastructure • Preparation of technical equipment for locations, mobile devices
Training • Dry run complete?
Soft spots • Mitigation plans developed and conveyed to user and hypercare teams?
Critical • Conversion of SIT/UAT critical tickets to hypercare tickets
Workarounds • Workaround plans conveyed to user and hypercare teams

Be sure to include this item in final go-live approval decision!


14
Stability Metrics and Reporting (cont.)

• When does the hypercare period end?


 DO NOT just pick an arbitrary period of time (e.g., 3 months)

 DO monitor the following:

 Number of critical defects and/or workarounds

 Number of changes to security roles

 Count of Firefighter usages

 Frequency of IT performing business transactions

 DO communicate with both internal and external auditors regarding the plan and timing
for short-term hypercare controls and the longer term new control framework

15
Stability Metrics and Reporting (cont.)

• Example Reports: Number of Critical Defects


Seven Days Trend
Hypercare Status Overview

Backlog
Opened

Closed

SEV1

SEV2

SEV3

SEV4

CR
Date
Rejected/Dup.
03/27/13 30 30 2149 595 955 528 48 23
Completed 03/26/13 185 172 2164 601 957 533 49 24
03/25/13 189 203 2151 605 948 526 48 24
Open 03/24/13 46 44 2165 616 963 514 48 24
03/23/13 48 41 2163 612 968 511 48 24
03/22/13 126 115 2156 602 970 512 48 24
0
0

00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
50
10
15
20
25
30
35
40
45
50
55
60
65
70
75
80
85
03/21/13 187 172 2145 597 967 509 48 24
1)
Open Completed Rejected/Dup. Data of previous days may change according to changed severity
Report generated: 3/27/13 11:10 AM 12-24 24-48 48-72 3-7 7-10 10-30 > 30 %
0-12
Total 2149 8484 2826 Severity Total % Met
hrs hrs hrs hrs days days days days
1- Severe 595 3704 1336 SLA
955 3523 1119 TOP 207 196 258 169 354 100 105 25 1414 17% 29%
2- Major
1- Severe 506 431 590 372 821 298 533 153 3704 44% 25%
3- Minor 528 1035 304
2- Major 210 171 266 237 699 349 1032 559 3523 42% 25%
4- Minimal 48 94 29
3- Minor 92 56 88 52 176 78 292 201 1035 12% 45%
CR 23 128 38 4- Minimal 21 17 5 3 10 5 17 16 94 1% 83%
Totals 829 675 949 664 1706 730 1874 929
% 10% 8% 11% 8% 20% 9% 22% 11%
SLA: Sev 1 = 24 hours; Sev 2 = 72 hours ( 3 days ); Sev 3 = 7 days; Sev 4 = 30 days

Weekly defect monitoring for first few months after go-live: Look for impacts to the security and control
environment. Is a temporary control needed to mitigate an open defect or workaround?
16
Stability Metrics and Reporting (cont.)

• Example: Firefighter Usage


• Interview excessive
users
• Is IT performing
business transactions?
• Identify the root cause of
usage
• Is proper training in
place?

17
Stability Metrics and Reporting (cont.)

• In addition to reviews to support your control environment, there may be data within your
SAP environment that is indicating operational or compliance concerns. Review the data
for trends that could indicate manual work arounds have been introduced into the
environment.

Example of Stability Metrics


Cycle Area Metric Description
PTP Master Data Vendor Analysis Number of One-Time Vendors

PTP Disbursements Spend to one-time Identify if users are using one-time vendors to perform payments and not
vendors leveraging actual vendors, this could be an inefficiency in the process and
present a potential risk of fraud as one-time vendors present a unique fraud
risk.

18
Stability Metrics and Reporting (cont.)
Example of Stability Metrics
Cycle Area Metric Description
PTP PTP Outstanding Review of the number of documents and dollar value of all unmatched documents in
GR/IR the GR/IR account that have not been resolved after 60 or 90 days
balances
OTC OTC Sales Orders Identify instances where manual price overrides were used at the time of sales order
with manually processing
updated prices
OTC OTC Customer Identify if there are inefficiencies in the order-to-cash process to see if there are a lot of
Credit Notes credit notes compared to the number of invoices issued
vs. Invoice
Ratio
OTC Accounts # of Cancelled Identify the number of cancelled sales invoices
Receivable Sales Invoices
RTR Financial Manual Journal Identify the number of manual journal entries and late entries (where a prior posting
Close Entries period was opened and entries recorded)

19
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

20
Controls Approach

• Summary of Controls Integration (CI)


 Organizations can successfully design, implement, and sustain their ERP controls environment
 CI fully integrates members of the project team with responsibility for proactively influencing
process and system design based on risk and controls considerations. The CI scope typically
includes:
 Risk Assessment

 Controls Design and Build


Specifically
important for
 Pre-Go-Live Controls Validation
hypercare period
 Controls Deployment and Support

 SOX Documentation Build

 Controls Testing Approach for Sustainment

 End-User Controls Training

21
Controls Approach (cont.)

• The controls team, those tasked with assessing the effectiveness of controls in the new
environment, will need to develop a risk-based response to go-live at each location.
There will be a series of tasks that they will want to consider performing.
• Examples of this may include:
 Testing key automated controls are operating effectively, including report validation

 Reviewing for direct changes to the production environment

 Reviewing for user with unmitigated SoD conflicts

 Reviewing for users who were granted access outside of the automated provisioning
system
 Reviewing for uses of standard SAP accounts, roles, and profiles

 Reviewing cutover users/access and ensuring it is removed in a timely manner

 Reviewing FF usage and that an approved incident was logged for each FF check out

22
Controls Approach (cont.)

• Training
 Creation and/or delivery of training sessions

 Creation of training materials

• Business Process Controls


 Control monitoring and mitigation plan development

 Evaluation of go-live or “hypercare” controls

 Thoroughly document scenarios that qualify for temporary and modified controls

 E.g., Emergency changes still require testing and approvals but may be captured in a

more manual fashion (i.e., email)

23
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

24
Case Study
A global tire manufacturer was going through a large scale SAP implementation.
The work began with a small project to introduce Controls Integration (CI) to their
SAP implementation and this ultimately led to a thoroughly controlled SAP
environment.

• Issue – What were the issues this company was facing?


 Large scale SAP implementation with delayed go-live due to functionality challenges in
a number of business areas
 Security role design and Segregation of Duties (SoD) conflicts surfaced within a month
of go-live
 Target support model for compliance program was not appropriately designed to
support new control landscape

25
Case Study (cont.)
Cost of Controls: Which curve will you end on?
Integrator Selected with No
Controls Focus
High
Controls
Checkpoints
Internal Audits
Cost of Controls

Controls
Implementation
Without Controls
COE

Controls Sustainment
with Controls
COE/GRC/Controls IQ
Low
Blueprint Realization Go-Live/Hypercare Sustainment
26
Case Study (cont.)

• Action – How did this company address their issues?


 Designed and executed a “hypercare” support audit that addressed potential financial reporting
risks within the financial reporting, data integrity, security, change management, and IT
process areas
 Security war room to remediate SoD and access issues, cover help desk ticket back log

 Post-go-live automated control validation to create a baseline completed during go-live


weekend with additional post-go-live manual control execution support for Internal Control
Owners
 Implementation of additional “interim” ITGC monitoring controls for key risk areas (open/close
production, table monitoring, developer access)
 Substantive “lookback” activities to re-create financially significant transactional activity for
elevated access accounts within cutover, FF accounts, and critical SoD rules
 Firefighter role redesign, policy design, and reviewer training

27
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

28
Leveraging GRC 10.1 Functionality

• GRC Overview
• Leveraging Access Control – Emergency Access Management Example
• Leveraging Process Control – Continuous Control Monitoring for Critical ITGC
Configurable Controls Examples

29
Leveraging GRC 10.1 Functionality — Overview

Enterprise Risk
Management Risk Management

Compliance Global
and Controls
Access Control Process Control Environment
Trade

SOA Platform SAP NetWeaver®

Business Applications
and IT Infrastructure SAP Oracle PPSFT Other …

30
Leveraging GRC 10.1 Functionality — Overview (cont.)
SAP GRC Suite Hypercare Examples to be Discussed

Access Control
Access (AC)
Control (AC) Process Control
Process (PC)
Control (PC) RiskRisk
Management
Management (RM)(RM)

Risk and Compliance Compliance


Repository Enforcement Risk Identification Risk
User Provisioning Transparency
Critical Access
and SoD Risks

Policy and Procedure


Continuous Control Management Risk Assessment
Monitoring Risk Mitigating

Emergency Business Role


Access Management
Issue and Remediation Customized Risk
Reporting Management Definitions Risk Indicators

31
Leveraging GRC 10.1 Functionality — Access Control
• SAP Access Control
Access Risk Analysis Emergency Access Management
• Real-time SoD and SA • Also known as Firefighter
reporting at user and role levels • Allows controlled and monitored
• Ability to document mitigating access to users for sensitive or
controls and assign to identified critical actions
SoD and SA conflicts GRC Access Control
10.1

Access Request Management


• Automated workflow engine Business Role Management
• Allows for automated provisioning • Standardizes and governs the
of user access and FF ID role development lifecycle
requests, plus recertification
32
Leveraging GRC 10.1 Functionality — Access Control (cont.)
History of AC Terminology

Virsa SAP Access Control SAP Access Control Today


(until 2011)
Compliance Calibrator Risk Analysis and Remediation Access Risk Analysis
CC RAR ARA
Firefighter Superuser Privilege Mgmt. Emergency Access Mgmt.
FF SPM EAM
Access Enforcer Compliant User Provisioning User Access Mgmt.
AE CUP UAM
Role Expert Enterprise Role Mgmt. Business Role Mgmt.
RE ERM BRM

33
Leveraging GRC 10.1 Functionality — Access Control (cont.)

• Emergency Access Management (Firefighter) is a solution used for:


 Emergency situations

 Short-term extensive and/or special access such as hypercare

• EAM General Process


 Selected personnel log in as Firefighters who can perform tasks outside of their normal
role or profile in an emergency situation
 Each Firefighter ID must be requested in a ticket and receive approvals before being
assigned
 Only certain designated individuals can assign Firefighter IDs

 Extended access is granted to users while creating an auditing layer that monitors and
records usage

34
Leveraging GRC 10.1 Functionality — Access Control (cont.)

• EAM Features
 Provides EAM IDs to perform actions that require special/elevated access

 Provides centralized access and administration of Firefighter IDs. Log review workflow
drives accountability and audit ability in the Firefighter log review process.
 Integrates with ARM to support workflow-based Firefighter ID/role approval process

 Ability to categorize criticality of emergency access

 Enhanced logging functionality of actions performed by Firefighter

 Captures reason code usage and activity for enhanced metrics reporting

35
Leveraging GRC 10.1 Functionality — Access Control (cont.)

• EAM Benefits
 Mitigates the most common open audit issue faced by companies: SAP_ALL

 Eliminates 3am emergency phone calls to approve access

 Track transaction code usage and changes

 Defined authorizations and validity dates

 Email notification of super user logon

 Auditable reporting logs

36
Leveraging GRC 10.1 Functionality — Access Control (cont.)

• EAM User Login


 In EAM, a user can be assigned one or more Firefighter IDs and is required to provide a
Reason Code and description of planned actions to be taken

Usage: EAM for hypercare should only be used for a


temporary period of time. Daily or frequent access for the
long term makes the logs too large for a reasonable/
valuable review.
37
Leveraging GRC 10.1 Functionality — Access Control (cont.)

• EAM – Reason Codes


• Reason codes are required to be selected when Firefighter access is checked out
(e.g., hypercare)
• GRC 10.1 tracks usage of reason codes to assist in metrics reporting of Firefighter
usage
• Line item reason code usage can be viewed using the Reason Code and Activity report
and total counts can be viewed in the reason code table

38
Leveraging GRC 10.1 Functionality — Access Control (cont.)

• EAM – Enhanced Logging


 Select and review the Log Report message from Work Inbox

 Click “Submit” to approve the Firefighter activity

39
Leveraging GRC 10.1 Functionality — Access Control (cont.)

• Example hypercare process with EAM


1. Provide implementation team support access only through Firefighter accounts

2. Ensure this team is trained on appropriate EAM usage and processes

3. Monitor EAM account usage on a weekly basis after go-live

 Look for trends in reason codes/frequency/users

 Ensure all log activity has appropriate approvals

4. After go-live support usage has stabilized, be sure to remove access from the support
team. Risk: Access remains for an unnecessary period of time which could result in
unauthorized use.

40
Leveraging GRC 10.1 Functionality — Process Control

• Process Control Automated Monitoring can help with the following:


 Testing of:

 SAP ECC Configuration

 Master Data

 Transactions

 Exception reports with configuration change details

 Workflow-based remediation and issue reporting

Screenshot from an automated exception report targeted at preventing the use of one-time vendor accounts

41
Leveraging GRC 10.1 Functionality — Process Control (cont.)
Example Continuous Transaction monitoring Example Continuous
controls Configuration monitoring controls

1. Detect unusual number of journal 1. Detect changes to tolerance


postings made to one-time vendors. limits for invoice verification.

2. Identify all purchase orders made to one- Configuration 2. Detect change to Duplicate
Monitoring Invoice settings.
time vendors and calculate their percentage
with respect to the total amount of purchase
orders created at the company code level. 3. Detect changes to Production
being locked down.

Transaction Continuous Master Data


Monitoring Monitoring Monitoring
Example Continuous Access Example Continuous Master Data
monitoring controls monitoring controls

1. Detect users with the ability 1. Detect vendor master data with
to maintain vendor master data identical bank account details.
and initiate payment to vendors
(Segregation of Duties Access
Monitoring 2. Detect incomplete master data for
violations). materials, customers, vendors.

42
Leveraging GRC 10.1 Functionality — Process Control (cont.)
Create Data
Configure ERP for Analyze &
Analyze the Data Source & Business Map to Controls Schedule Report & Refine
Monitoring Remediate
Rule

Example Hypercare CCM: PC Monitoring Configuration


1. Create data source to monitor table that shows Production status
2. Create business rule to monitor table changes
3. Map to key SOX control: SAP PRD environment is locked
4. Schedule planner to run daily and report exceptions if production is opened
5. Train control owners on how to remediate issues and/or document business
justification and approvals for items that are sent to work inbox

43
Leveraging GRC 10.1 Functionality — Process Control (cont.)
Create Data
Configure ERP for Analyze &
Analyze the Data Source & Business Map to Controls Schedule Report & Refine
Monitoring Remediate
Rule

Example Hypercare CCM: PC Monitoring Inappropriate EAM Usage


 Did any Firefighters post journal entries in the past 90 days?

Have Firefighters Have Firefighters Have Firefighters Have Firefighters processed


created users? changed materials? processed sales orders? purchase orders?
44
Leveraging GRC 10.1 Functionality — Process Control (cont.)
Create Data
Configure ERP for Analyze &
Analyze the Data Source & Business Map to Controls Schedule Report & Refine
Monitoring Remediate
Rule

Example Hypercare CCM: PC Monitoring Inappropriate EAM Provisioning


 Are Firefighters following validity policy?
Yes, PC can monitor
Access Control tables!

45
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

46
Key Audit Focus Areas
• IT General Controls (ITGC) Overview
 ITGCs help provide a foundation for data processing environments that is secure, reliable, and provides
for data completeness, accuracy, and integrity

Significant Parts of the Financial Statements


Balance Income
General Controls SCFP Notes Others
Sheet Statement
• Change
Management Business Process/Classes of Transactions
App. Controls
• Security Process A Process B Process C
Administration • Configurable
• IT Operations Financial Applications Options
• Systems • Programmed
Application A Application B Application C
Development Controls
Lifecycle IT Infrastructure • Access Controls,
Database Operating System Network etc.

47
Key Audit Focus Areas (cont.)
ITGC Overview – Foundation
• ITGCs represent the foundation of the IT control structure. They help establish the reliability
of data generated by IT systems and that systems operate as intended and that output is
reliable.

• ITGCs are organized into four domains/processes:


• Security Administration (e.g., password settings and user administration)
• Change Management (e.g., change approvals and testing) Relates to
• SDLC/Program Development (e.g., SDLC Policy and large-scale system implementations) Hypercare
• IT Operations (e.g., backup and recovery)

• In addition to ITGCs, IT Entity Level Controls (ELCs) exist to address the overall control
environment. IT ELCs are designed to shape the corporate culture or "tone at the top."
Examples of IT ELCs include IT policies and procedures, annual training requirements, and
IT governance.
48
Key Audit Focus Areas (cont.)
Public Company Accounting Oversight Board

SOX Act requires accounting firms auditing public PCAOB inspections are causing
companies to register with, and be subject to periodic external auditors to ask more
inspection by the PCAOB questions and evidence on controls

• Increased IT considerations, including data and reports


• Increased concern of the accuracy and completeness of reports
• Increased controls over access automation and SoD analysis
• Increased controls over access changes and logs
• Less reliance on management representation and more evidence on control testing

49
Key Audit Focus Areas (cont.)
• Completeness and Accuracy over Reporting
 There are many viewpoints on how companies validate completeness and accuracy
over reporting. Management’s goal is to have comfort in all key reports, which can be
gained by the following methods:
 Tying reports to independent source information

 Testing reports as part of system implementation or “one-off” and relying on Change

Controls
 Relying on other ITGC controls for “canned” reports

50
Key Audit Focus Areas (cont.)
Most Common Areas for Testing during hypercare: Be ready!
 Review for proper System Development Lifecycle (SDLC) controls

 Testing key automated controls are operating effectively

 Review for direct changes to the production environment

 Perform report and program validation for key SOX controls

 Review for users with unmitigated SoD conflicts

 Review for users who were granted access outside of the automated provisioning system

 Review for uses of standard SAP accounts, roles, and profiles

 Review cutover users/access is removed in a timely manner — if access is not removed


in a timely manner perform additional procedures to monitor the access granted
 Review EAM usage and that an approved incident was logged for each check out

 Avoid Q4 go-live (if possible) because there is no time to remediate issues


 Be in close communication with the internal and external auditors
51
What We’ll Cover

• Definition of Hypercare
• Cutover Planning
• Stability Metrics and Reporting
• Controls Approach: Execution of tight control over business processes and security
• Case Study
• Leveraging GRC 10.1 Functionality
• Key Audit Focus Areas
• Wrap-up

52
Where to Find More Information
• Brian Shannon, “7 Strategies for Preparing Your SAP System for Audits (SAPinsider, October 2015).
 http://sapinsider.wispubs.com/Assets/Articles/2015/October/SPI-7-strategies-for-preparing-your-SAP-
systems-for-audits
• Process Control – Continuous Monitoring on the SAP Help Portal
 http://help.sap.com/saphelp_grcpc101/helpdata/en/5d/038910ddca4b9d847934a662b98b4c/content.htm?f
rameset=/en/9a/35bde07054476ead120eb81251f10a/frameset.htm&current_toc=/en/60/d658f576b6452eb0f
943c04b354018/plain.htm&node_id=140&show_children=false
• Access Control – Configuring ID-based Firefighting on the SAP Help Portal
 http://help.sap.com/saphelp_grcac101/helpdata/en/4f/5faf2e95052892e10000000a42189b/content.htm

• Access Control – Configuring EAM Log Notifications on the SAP Help Portal
 http://help.sap.com/saphelp_grcac101/helpdata/en/c6/a13aab8efc454eadeab21a46381885/content.htm

53
7 Key Points to Take Home

• Proper planning for the period of hypercare is key!


• Use hypercare stability metrics to help monitor and quantify both progress and issues
during this period
• Controls Integration (CI) is a critical component to any implementation and should be a
top priority
• Train hypercare support teams on controls and appropriate processes
• GRC 10.1 functionality in Access Control and Process Control can help make the
hypercare period more automated, efficient, and successful
• Understand the audit requirements for compliance during hypercare
• Maintain close communication with internal and external audit teams

54
Your Turn!

How to contact me:


Holly Marrs
Email: holly.marrs@pwc.com

Please remember to complete your session evaluation


55
Disclaimer
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP SE.

© 2016 PricewaterhouseCoopers LLP, a Delaware limited liability partnership. All rights reserved. PwC refers to the US member firm, and may sometimes refer to the PwC network. Each
member firm is a separate legal entity. Please see www.pwc.com/structure for further details.
This content is for general information purposes only, and should not be used as a substitute for consultation with professional advisors.

56
Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026
Copyright © 2016 Wellesley Information Services. All rights reserved.

Вам также может понравиться