Everybody hates an audit. An audit of a company’s SAP systems can distract employees from their operational responsibilities, create an environment of conflict, and result in configuration changes, consuming precious time and resources. Worse, some audit findings may require costly rework — with issues becoming increasingly difficult to correct the longer they go undetected. While guidance exists for auditors who review SAP systems, little guidance exists for those being audited. Audit findings are common; unfortunately, many could be avoided if employees were better prepared for the audit itself. See an overview of how auditors approach an SAP audit, discuss typical audit techniques, describe the common elements required for a well-controlled SAP infrastructure, and set the foundation for ensuring success in any type of SAP audit. Given the complexity of SAP systems and the number of configuration and customization options available, however, it will not be possible to discuss every potential audit concern. I'll provide you with basic audit objectives and allow you to apply this understanding to specific issues within your organization.

Overview of the Audit Function

Regardless of the type of audit in which you are involved — SAP, financial statement, operational efficiency, or any other variation — the common thread to any audit is the auditor. Auditors are bound by a common set of rules, and those rules govern how they conduct an audit. To be effective at an SAP audit, therefore, you must first understand the characteristics specific to any audit. Contrary to popular belief, an auditor’s goal is not to cause problems. Conversely, an auditor aims to identify where potential problems might occur or have occurred and communicate sufficient information to interested parties so they can make informed decisions. Each of these interested parties may have different concerns relative to the process or system being audited. Thus, the nature and extent of the audit may take on different characteristics depending on the type of auditor involved. At a very high level, auditors generally fall into one of two categories: internal auditors and external auditors. There is also a wide variety of specialty auditors, who provide services in specific audit disciplines.

Internal Auditors

The goal of internal auditors is to protect management and the board of directors. Most internal audit functions report to the audit committee of the company’s board of directors, although many also have administrative responsibility to the chief financial officer (CFO). Internal auditors provide the board with valuable information about the company’s operations that the board may not receive directly from management due to biases, lack of objectivity, or merely a desire to look good in the eyes of the board. As a result, the internal audit function provides a system of checks and balances so the board of directors can better assure that its directives and objectives are being carried out appropriately. Companies employ internal auditors; however, they may not always be part of a company’s payroll. Smaller organizations in particular may choose to outsource the internal audit function to a third-party provider. Even larger organizations may choose to supplement an existing internal audit department’s knowledge and skills, particularly in specialty areas such as SAP, through the use of outside resources — often called co-sourcing. Regardless of who actually pays the specific auditor’s salary, your organization ultimately employs the internal auditor. Most importantly, internal audit reports are primarily for use inside the organization and are rarely distributed to external parties. This is an important distinction between internal auditors and the external auditors that we’ll discuss next.

External Auditors

When most people think of external auditors, they think of the financial statement auditor, typically employed by a large accounting firm, which opines on the integrity of a public company’s financial statements as part of the year-end financial reporting process. For purposes of this article, I refer to external auditors in a more inclusive sense, consisting of the various types of auditors an organization may encounter that are not ultimately employed by the organization. Although external auditors may review their reports with management and the board of directors, their true goal is to protect investors, customers, or other interested external parties. Just as an internal auditor provides the board with objective information that may not be received directly from management, external auditors provide external parties with information and insights that the respective organization may not make directly available. The most common type of external auditor is the financial statement auditor, which I mentioned previously. In the US, the accounting firm is paid by the organization being audited (creating a lack of pure independence, which arguably has resulted in some of the accounting scandals seen in recent years). However, in these cases the external auditor officially represents the interests of the investor (e.g., company stockholder). External auditors may also represent banks and report on issues such as compliance with loan covenants. They may represent governmental agencies — tax authorities, for example — and report on a company’s compliance with specific laws and regulations. Certain industries, such as financial services, pharmaceuticals/chemicals, and utilities (to name a few) may have industry-specific auditors charged with reporting on compliance to a governing entity. Depending on the nature of your business, you may also have external auditors who report to your customers. Customers may include a right-to-audit clause in their contracts, particularly related to services such as outsourced IT or HR/Payroll functions. In this case, depending on the specifics of your contract with the customer, they may periodically send a team of their own auditors into your organization to review a specified function. For organizations that perform services-related functions for a large number of companies, this desire on the part of customers to periodically audit these service-related processes can become particularly burdensome (imagine if every one of your customers decided to send in their own audit team to audit your SAP processing). As a result, some companies may choose to hire an independent audit firm to issue what is known as an SAS 70 report. Depending on the circumstances, customers may use this report to verify the effectiveness of operations in lieu of having to send their own audit teams to perform independent audits. Despite the wide variety of external auditors, one important fact remains constant: Reports from external auditors are issued outside the walls of the company. Although some external auditors may provide some additional value-added recommendations for your organization’s management (e.g., suggestions for improving your SAP systems that were observed during the course of the audit but that are not relevant to the audit), the ultimate audit report will be issued externally. In the case of certain types of audits, such as those conducted by your financial institution or by a customer, the distribution of these reports may be limited to specific organizations. In the case of a financial statement audit, the final reports may be issued to the public as a whole and are thus accessible to everyone, including your competitors. While it is always important to work with the auditor to ensure that the report of findings is relevant, factual, and fairly stated, the nature of the distribution of external audit reports makes this an even greater concern. We’ll discuss negotiation issues with your auditor later in this article.

Specialty Auditors

Both internal and external auditors often specialize in different audit disciplines. A typical internal audit department may have multiple specialists, with some auditors focused on financials and reporting, others focused on operational efficiency, some examining technology, and others dealing with investigations and fraud. Depending on how audits are conducted, you may be subject to multiple audits, each with a different focus. Many audit departments are moving towards more integrated audits, where multiple disciplines are combined into the same audit. This helps to save time and may reduce the auditee’s “pain factor” as well. Some auditors, typically called IT auditors, specialize in auditing technology. IT auditors may specialize in a subset of technology, such as networks or firewalls, although many IT auditors are technology generalists. Of course, there are also auditors who specialize in auditing SAP systems. In general, the more specialized the auditor, the higher the internal/external cost, and thus the more likely your organization won’t be able to afford their services full-time. In some cases, auditors know very little about SAP systems specifically; see the sidebar "My Auditor Doesn't Know Anything About SAP!" for more.

Differing Audit Objectives

Not only are there many different types of auditors and audits, but there are also many different types of audit objectives. A commonly used internal control framework known as COSO, based on a 1992 report from the Committee of Sponsoring Organizations (COSO) of the Treadway Committee (which you can find at www.coso.org), classifies an organization’s objectives as falling into one of four categories:

• Strategic: High-level goals, aligned with and supporting the company’s mission
• Operational: Effective and efficient use of resources, including safeguarding of assets
• Reporting: Reliability of public reporting
• Compliance: Compliance with applicable laws and regulations

Table 1 provides examples of audit objectives that can result in an SAP audit and the typical audience who would be the consumer of the related audit report.   Considering the number of different types of auditors and the wide variety of potential audit objectives, is it any wonder that some audits of SAP systems look very different from others? Depending on the context of the audit, something that’s important for one audit may be irrelevant to another. Using a specific example, consider an SAP security audit. If that audit is being conducted as part of a Sarbanes-Oxley review, then the assessment will likely focus on segregation of duties (SoD) over key functions related to financial reporting, as well as some basic SAP security administration and management controls. If the SAP security review is part of a HIPAA privacy audit, however, heavy emphasis will be placed on the ability of users to see sensitive information, the encryption of that data (both in the SAP system and in transit between SAP and other systems), and the processes for identifying protected information. The key takeaway here is that success (or failure) in a prior SAP system audit does not necessarily relate to success or failure in a future SAP system audit.

Auditing Principles

Before getting into the actual auditing of your SAP system, you should understand some key auditing principles. These principles often require auditors to behave in ways that seem foreign to those new to the audit process. Understanding these principles will allow you to better prepare for and react to the audit.

Professional Skepticism

Have you ever felt that no matter how many years you’ve worked with an auditor and how forthcoming you’ve been in previous audits, you just can’t seem to get the auditor to trust what you’re saying? The reality is that per audit standards, they cannot. Auditors are required to operate in a mode of professional skepticism. This means that an auditor cannot merely trust what someone says and must gather additional evidence to support (or potentially refute) what they have been told. Specifically, auditors must operate in a neutral position on a scale where trust is at one end and distrust is at another. As such, an auditor’s beliefs (or the beliefs of the individuals with whom the auditor is working) should not influence the outcome. Audit evidence must stand on its own and support the conclusions of the audit. Initially, this standard may seem harsh, but I’ve seen first-hand how a lack of professional skepticism can have a serious impact on an organization. I worked with a company a number of years ago that highly regarded one particular employee for their ability to reconcile SAP general ledger accounts during period end. This individual typically had the fewest number of outstanding reconciling items and comparatively very few dollars outstanding at any given point in time. In fact, management began relying on this person to coach others in how to effectively reconcile SAP accounts. It wasn’t until after an audit, however, that this person’s true success mechanism was revealed. After working many of the larger reconciling items, once this person got close enough (relative to the overall account balance, which was a very sizeable number), they merely created a journal entry to clear out the remaining items. In essence, this “SAP reconciling superstar” only seemed like a model employee on the surface. You may wonder from this example how professional skepticism fits in with this example since the problem was caught during an audit. In this case, professional skepticism was used during the audit, which is why the individual’s actions were detected. Management had failed to be professionally skeptical during their review processes. Surprisingly, this person’s work had been approved by management for years prior to the problem being identified. The organization had a process whereby managers were supposed to review each employee’s reconciliations to ensure adequacy. Unfortunately, this individual’s manager was not operating in a neutral position on the professional skepticism scale — trusting the integrity of the person’s ongoing work based on results that appeared reasonable in the past. As a result of this lapse in judgment, the organization lost a sizeable amount of money, a large effort was required to go back through history and clean up the mess, and management was left looking foolish. I encourage every manager (not just those within internal audit) to apply professional skepticism in their work as well. Review the work of your SAP developers, periodically assess the accuracy of your SAP security setup and maintenance processes, and determine whether those reviewing SAP exception reports are following through on identified items appropriately — whatever your role, spend some time validating your own assumptions about performance.

Evidence

Another audit principal that can cause problems during an SAP audit involves the concept of evidence. For audit purposes, evidence must stand on its own — meaning that an independent auditor looking at the same information would come to similar conclusions regarding the test results. To some extent, maintaining evidence supports the concept of professional skepticism. For example, some companies having to comply with the US Sarbanes-Oxley Act may be shocked when a significant deficiency is issued by their external auditors simply because someone didn’t sign a document — even though they performed a related review. Some auditors go a step further by declaring, “If you can’t prove it, it didn’t happen.” This may seem a little extreme, but the reality is this: If you don’t have sufficient evidence to prove something, then an auditor cannot independently attest that it happened. Therefore, a “lack of sufficient evidence” during an SAP audit becomes an audit issue itself. Beyond resulting in the auditor being unable to attest to the adequacy of audit results, a lack of evidence also begs the question of how management can be assured that things are happening as intended. As in the example from the previous section, if management is merely trusting employees to perform as expected, this can raise broader audit concerns around the effectiveness of the control environment management has established. In short, evidence should exist that processes are indeed operating as management intends — both for audit purposes as well as for management. See the sidebar, "Electronic Evidence," for information on electronic forms of evidence.

Understanding the Audit

Before examining the parts of a typical SAP system audit, I'll discuss several common audit techniques and processes.

Risk-Based Auditing

The scope of many audits these days is often determined by applying a risk-based approach. There are many different approaches comprising the details of risk-based auditing, but fundamentally this technique focuses more attention on those risks specific to your organization that have a higher likelihood of occurring or affecting your organization than those that do not. Using an SAP example, an insurance company using both SAP’s Treasury module as well as SAP’s Projects module may find that significantly more attention is placed on SAP Treasury with potentially little-to-no attention on SAP Projects. This makes sense because the risks in an insurance company typically center more on cash and the tracing and flow of money than around projects. Conversely, a company whose primary business is construction may find their SAP audit having the exact opposite focus.

Thinking Like an Auditor

Learning to think like an auditor is actually one of the best things you can do to prepare for, and ultimately survive, an SAP system audit. You may think your auditor is cynical or pessimistic, but in reality, there is simple logic behind most audit concerns. The key lies in continuously asking, “What could go wrong?”, evaluating that answer, and asking, “Then what else could go wrong?” Considering risk-based auditing, you should then gauge the impact and likelihood of the event or issue to determine whether it warrants attention and investigation (not every audit is risk based, however, so at times your SAP auditor may be concerned with issues that do not seem likely to occur or greatly affect your business). For the items deemed important enough to warrant further consideration, you should then think, “Given that this could go wrong, what do we do to prevent it from happening or to detect it in a timely fashion if it does?” The issues that can cause problems in an organization tend to fall into several buckets, so you may see audit objectives centered on themes such as: validity, accuracy, completeness, timeliness, relevance, and recording. Asking your “What could go wrong?” questions in the context of these categories can be particularly helpful in ensuring that you’ve appropriately addressed all the risks in your SAP system. Here are some examples:

• What could cause a payroll adjustment in your SAP system to be invalid?
• What could make checks cut from the SAP system having inaccurate amounts?
• What could result in the information we use to calculate liabilities incomplete?
• What could cause goods receipts not to be entered into the SAP system and processed in a timely fashion?
• What could result in the information used to determine write-offs being irrelevant?
• What could lead to sales being recorded in the wrong period?

As mentioned above, for each of these questions, you would then list possible causes along with the impact and likelihood of occurrence for your organization. Regarding the question, “What could cause goods receipts to not be entered into the SAP system and processed in a timely fashion?” a partial list of potential causes and their impact might include:

• Goods were received in the warehouse but not entered into the SAP system within the 24-hour corporate policy standard (high likelihood, low impact for parts; moderate likelihood, high impact for equipment)
• The receipts file transmitted nightly from warehouses running non-SAP systems was not received (low likelihood, moderate impact)
• The receipts file transmitted nightly from warehouses running non-SAP systems was not processed in the SAP system (low likelihood, moderate impact)
• Third parties who receive and store goods on behalf of the company did not submit a file for processing within corporate guidelines (high likelihood, low impact)

Lastly, you should have sufficient processes to ensure these potential causes are either prevented or detected in a timely fashion if they occur. These processes may differ by type or category. Considering the first potential cause, you might have:

• For goods of type X: RFID tags automatically update SAP inventory records upon receipt into the warehouse (preventive)
• For all goods (both type X and not-X): All employees whose job responsibilities include entering or transmitting goods receipt information are required to periodically (at least once per year) sign off on compliance with receiving policies, which dictate that all receipts must be entered into the SAP system within 24 hours (preventive)
• For all goods (both type X and not-X): Every week, managers review reports of invoiced items that have not been received and investigate items that have been outstanding for more than Z days (detective)
• For all goods (both type X and not-X): Physical inventories are performed quarterly, and inventory adjustments are made in the SAP system based on actual physical count (detective)

Of course, just being able to list preventative or detective processes is not enough. You need to show that these processes would prevent errors above a cumulative magnitude that would cause key stakeholder (e.g., management, supplier, investor) concern, or detect such problems in sufficient time to correct them before uncorrected errors would cause stakeholder concern. You can see from the example that this organization relies primarily upon detective controls for goods receipt, which are not of type X. Although they do have a preventive control listed, it is fairly weak — this organization, like others, has periodic employee performance problems. You need to determine whether these controls are sufficient to reduce overall risk to an acceptable level. Upon evaluation, you may determine that you need to increase the frequency of certain controls or add additional controls.

Applying Audit Investigative Techniques

I like to think of auditing as being similar to the scientific process. In science, you have a theory that you work to prove. In the audit investigative process, the controls (each of the processes you identified that would prevent or detect the potential problem from occurring) can be considered management’s theories. The auditor is now attempting to gather evidence to prove — or in many cases, disprove — management’s view of the effectiveness and reliability of these controls. Related to these controls, the auditor looks at the design, determining whether it is operating as intended and if it would sufficiently mitigate risk to the desired level. Once they are comfortable with the design of the control, the auditor reviews the operation of the control to determine whether it is performing as intended. Throughout the process, the auditor is gathering evidence to support the conclusion. There are generally four different types of evidence that auditors gather during the course of their SAP review, as follows in order of reliability (Table 2). The first is corroborative inquiry, which seeks to ensure that the people interviewed (formally or in casual conversation) during the audit share the same beliefs. The second is observation, where the auditor observes whether the intended process is occurring consistently based on how they see people or systems performing their required actions. During the examination of documentary evidence, the auditor looks for other indications (such as paper trails or details within electronic transaction records) to further validate the consistency and integrity of the process. The final type of evidence is re-performance, in which the auditor independently performs all or part of the action (e.g., review, calculation, data extraction) and compares their results to what actually occurred. Auditors often perform a combination of these techniques to increase the level of assurance.   Knowing these evidence-gathering techniques can be useful as you prepare for your own SAP audit. We discussed how auditors are really attempting to prove or disprove management’s theories. There is certainly no reason why you can’t (or shouldn’t) do the same in advance of your own audit. Let’s talk about how each of these techniques could be applied to investigate one of the controls identified in the example earlier — that “Every week, managers review reports of invoiced items that have not been received and investigate items that have been outstanding for more than Z days.” Remember the concept of professional skepticism when performing these and similar tests in your own SAP environment. If you can get in the habit of thinking like an auditor and applying audit techniques to your everyday processes, you can significantly reduce the pain and duration of your SAP audits.

Overview of the Typical SAP Audit

Now let’s talk about the typical SAP audit. Of course, you may remember from the introduction that, given the different types of auditors and different types of audits, a “typical SAP audit” is a bit of a misnomer. That being said, after years of SAP system auditing I tend to classify components of a review into five major buckets: project management and system administration, general computer controls (GCC), SAP Basis settings and security, SAP module-specific technical settings, and the business processes enabled by SAP. I’ll look at each of these briefly here and then discuss them in more detail later in the article.

Project Management and System Administration

The project management and system administration category looks at how you select, install, and make upgrades to SAP components and in general, ensures that the SAP system is meeting the needs of your business. When auditing in this category, I would look at issues like how you determine the appropriate tolerance settings for SAP configured controls and ensure that they are reflected in your SAP system. This category is specific to the things you do to make sure the SAP system works well for your business, both today and in the future. In my mind, this category is more about strategy, management, and execution than about SAP or IT specifically. I generally refer to this layer as the foundation layer for the SAP audit.

General Computer Controls (GCC)

General computer controls is a term used in the information systems auditing profession and reflects a standard set of higher-level IT management, infrastructure, and process controls that should be in place to support the effective operation of any system (SAP included). This category of controls would generally look at broad issues that are not SAP specific (but that are in the context of SAP for an SAP system audit) like interface management, troubleshooting and support, network infrastructure, business continuity, and security administration at the network and infrastructure layers. While some of these areas may not be under the influence of employees who work directly at SAP systems at these levels, the effect that these processes have on the reliability of the SAP system is significant and therefore, it can be a large part of a comprehensive SAP audit.

Basis Settings and Security

This category generally addresses SAP settings that are not module specific. It is concerned with powerful administrative functions like backups, archiving, and mass maintenance. Significant emphasis is also on global security settings, such as minimum password lengths, passwords for default SAP accounts, logout and locking parameters, and other settings that provide the foundation of the SAP system’s very powerful security model.

SAP Module-Specific Technical Settings

This category is similar to the Basis category, but this one addresses those settings that are specific to an SAP module, such as Production Planning (PP), Financial Accounting (FI), or Sales and Distribution (SD). Audit steps in this category typically look at specific configuration settings and defined tolerance levels to determine whether they are appropriate (e.g., examining the configured release strategy and related authorization limits for purchasing). Security in this category is primarily concerned with sensitive transactions and authorizations for that process (e.g., the ability to change vendor bank account information), as well as segregation of duties (e.g., separation of the ability to enter an invoice from the ability to approve the disbursement of funds). Depending on the extent of the SAP audit, this could be a very detailed audit or a very high-level audit.

Business Processes Enabled by SAP

The final category in a comprehensive SAP audit deals with the business processes enabled by SAP. To a large extent, this set of audit procedures deals less with how the SAP system is set up and more with how employees use their SAP system in practice. In my opinion, while a lot of auditors tend to focus on the earlier categories we discussed, the most significant and critical findings can occur in this category. At this level, we are no longer predicting what could happen based on how the SAP system is configured or managed, but rather we are dealing with what is currently happening and how it is affecting the business. Findings may exist where the SAP system is technically configured correctly, but employees are misusing functionality either because they lack understanding (training and development), lack a defined process (policies and procedures), lack ongoing guidance and coaching (management monitoring), or they are consciously attempting to circumvent the system (fraud and abuse). Audits covering this category would find, for example, employees in Accounts Payable using sundry invoice processing (which needs to be enabled to pay certain invoices such as utilities and services) for payments that should go through SAP’s three-way match process. Although findings in this area may not be the fault of employees supporting the SAP system, the SAP support function can often assist in helping management proactively identify these issues and define additional monitoring routines.

How These Five Categories Fit Together

You’ll notice that the image in Figure 1 is shaped somewhat like a pyramid. I like to picture the components of an SAP audit in this way because a pyramid shape illustrates how the lower categories support those up above. For example, having authorization limits set in your SAP system is a good start, but if SAP security is not configured to enforce reasonable security measures at the Basis level, then it is difficult to assure that a user (and thus an approver) is who they say they are. Similarly, if appropriate processes do not exist within the GCC environment to monitor interface processing, the SAP system may be processing accurately against an incomplete set of transactions. Lastly, if the SAP system changes are not appropriately coordinated with the business areas, a change that seems minor may have unintended consequences at the business process level and result in management making inappropriate decisions based on a faulty interpretation of data. From an audit standpoint, the auditor must ensure that reasonable controls exist at the lowest levels of the pyramid before spending too much time on the upper levels — there is no point checking the deadbolt if the back door is wide open.   The pyramid also helps prioritize audit work when time and other resources are scarce. In a perfect world, the auditor could fully validate every control setting and process within the SAP system. Given the complexity of the SAP system and the number of possible settings, however, this is a practical impossibility. If evidence can show that the right people are involved in SAP-related decisions, sufficient testing occurs over all changes, an overall control mindset pervades the organization, and similar control foundation-related elements exist, auditors can be more confident that the specific details are taken care of without examining each of them exhaustively.

The GCC Audit

Now that you’ve had a fairly thorough overview of the audit process, it’s time to dig into the specific details of an SAP audit. We’ll be discussing other components of the SAP audit in detail in subsequent articles, so the remainder of this article will focus on the GCC component. You will likely encounter some type of GCC assessment during every SAP audit. We already discussed how the GCCs support the controls and effective processing in SAP. GCCs are also common to every system audit, regardless of application type — thus most technology auditors, even those relatively new to the field, become quickly comfortable with assessing GCCs. The most common IT control framework addressing GCCs from an audit perspective is called Cobit, and is published by the IT Governance Institute (a spinoff of ISACA, the leading organization for IT auditors). If you are really interested in understanding the GCC audit, I’d recommend you invest some time reading at least the Cobit summary documents at www.itgi.org. Cobit itself consists of multiple manuals, so it would be impossible to summarize effectively in this article. Instead, I’d like to focus on some of the areas that, based on my experience, seem to be the most problematic for organizations. While a GCC audit will cover more than policies and procedures, security, and change control, you can get through some of the more painful parts of a GCC audit with the following as tips.

Policies and Procedures

• Have a formal exception process: Policies and procedures can’t always be followed. Have a formal, defined process for approving exceptions to the policy, and document each approved exception. This shows the auditor that you are aware and have made a conscious decision around how to address the related business risks.
• Periodically communicate and revalidate exceptions: Having an exception process alone is not enough, particularly in an organization where people change. The risk tolerance of new management may not be the same as that of previous management. Additionally, advances in technology may allow you to address risks more effectively. Lastly, the costs of compliance may change over time, again resulting in the need to reevaluate exceptions to management’s defined processes.
• Periodically self-audit against your policies, and update your policies (or approve exceptions) if they don’t work for your business: One of the easiest findings for an auditor is where settings and processes don’t match corporate policy. For example, if your security standards say that all passwords must have a minimum length of 10 characters and be changed every 30 days and your SAP security settings in report RSPARAM show the SAP system set at 9 characters and 40 days, you have an audit exception. It doesn’t matter that 9 characters and 40 days may arguably still provide very strong security. The mere fact that the SAP system does not match your corporate policy (and no exception has been documented) is an issue.

Security

• Validate user access against a segregation of duties (SoD) matrix: Every organization should have an SAP SoD matrix, defining abilities that should not be granted in combination to a user (e.g., entering vendors and approving vendor disbursements). This matrix should be validated by management periodically, and each ability should be mapped to its respective transactions, authorizations, and authorization objects so that SAP security personnel can effectively identify which users have which abilities. Additionally, user abilities should be checked for SoD conflicts upon initial setup, as well as any change to profiles and profile assignments. SAP BusinessObjects Access Control can greatly enhance an organization’s ability to check SoD issues.
• Change SAP default passwords: Hopefully this is not a risk for your organization; however, verifying that default passwords have been changed is on every IT audit checklist. Pay particular attention to IDs such as SAP*, DDIC, SAPCPIC, EARLYWATCH, and (in some systems) TMSADM.
• Restrict privileged access requiring only periodic use: At times, you may need to give certain individuals access to transactions and other SAP abilities they may not typically need (or that they should not have, given typical SoD requirements). For example, a programmer may need emergency access into SAP production to fix a time-sensitive problem. Rather than grant privileged access as part of the user profile definition (risking that these privileges could be used when not intended by management), provide a means to grant access only when needed, and audit the access actually used. SAP BusinessObjects Access Control has some useful features to enable this better than historical means.

Change Control

• Use standard forms, which require consideration of security and control elements for all SAP changes: Good business practices suggest that security and control requirements be considered for every system change. For example, when creating a custom transaction in the SAP system, how will it affect SAP workflow? Does the transaction create the potential for any SoD concerns? What edit checks and tolerances should be addressed to validate user input? Requiring security and control elements to be considered on the change request form ensures that they are consistently considered. 
• Maintain a pre-transport checklist to ensure sufficient support is gathered prior to implementation: I talked earlier in this article about the importance of retaining evidence. The change control process includes many evidence-related items important to an auditor — from the initial change request and requirements through approvals, testing and QA results, and ultimately the go-ahead for transport into production. Since any of these could be required for audit support, it’s a good practice to make sure all of these are gathered and appropriate signatures and support have been retained prior to moving any change into SAP production.  
• For emergency changes, complete skipped steps post-implementation: Every organization experiences emergency changes, where code must be moved into production more expeditiously than through the standard change process. Emergency changes often involve less up-front diligence to streamline the process, and some may completely bypass controls. Following up after the change to ensure the emergency change meets production standards is critical to satisfy audit requirements. Additionally, be sure to inform affected business management of the emergency change so they can monitor operations for potential impact. 
• Develop test plan details commensurate with the complexity of the change and experience of those involved in testing: Some changes are less complex than others. For example, adding a field to a report has potentially less inherent risk than changing the essence of a calculation. Even simple changes, however, should be tested. But the complexity of the change isn’t the only factor that should affect the level of detail in the test plan. Some testers may be more familiar with SAP testing procedures than others. By ensuring that test plan detail considers both the complexity of the change and the experience of the testers, you have better assurance that testing will be performed effectively to catch the issues it is meant to catch. 
• Resolve unsuccessful tests prior to go-live: Although this may seem obvious, as an auditor I’ve seen all-too-frequent situations where organizations did not fix every problem identified during testing prior to approval and transport of the change. In the case that management has been appropriately informed and accepts the risk associated with the test failure, make sure this information is thoroughly documented — not just for audits, but also for troubleshooting and problem resolution if issues are identified down the road.