How to examine personnel data, payroll controls, and access rights across SAP HCM with confidence and precision.
Auditing an SAP Human Capital Management (HCM) environment is one of the most consequential engagements an internal auditor or external reviewer can undertake. Payroll errors, unauthorized access to employee records, and misconfigured benefit plans can expose an organization to financial loss, regulatory penalties, and reputational damage, all traceable to configuration decisions buried deep in a system that most auditors never fully explore.
This guide walks you through the major audit domains in SAP HCM in a logical, field-ready sequence. For each area, you will find the specific transaction codes (T-codes) to use, the tables and objects to examine, what to look for as a potential finding, and practical recommendations you can bring back to management. Whether you are new to SAP audits or refining an existing program, this guide gives you a structured, repeatable approach that covers configuration, authorization, and reporting controls.
A note on terminology: throughout this guide, references to the IMG mean the Implementation Guide, accessed via SPRO (System Customizing Implementation Guide). The IMG is where nearly all SAP configuration lives, and access to it is itself a significant control risk. Every section will remind you to check who can get in there, because the person who can change configuration often does not need to.
1. Enterprise Structure and Personnel Configuration
The enterprise structure is the foundation on which everything else in SAP HCM is built. Before a single employee record is created, the system must know how the organization is structured: which company codes exist, which personnel areas belong to those companies, and how employee groups and subgroups are defined. When this foundation is poorly configured or poorly controlled, every downstream process inherits the problem.
What you are reviewing here is whether the personnel areas (PA), personnel subareas (PSA), employee groups (EEG), and employee subgroups (ESG) have been defined in a way that reflects actual business requirements, and whether access to change that structure is appropriately restricted.
Start by accessing the IMG to view the enterprise structure definition.
T-code: SPRO → Enterprise Structure → Maintain Structure → Definition → Human Resources
Then look at the underlying tables directly using SM31 (Table Maintenance):
- T500P — Personnel areas
- T501 — Employee groups
- T503K — Employee subgroups
- V_001P_all — Extended table maintenance for personnel areas
From an auditor's perspective, the key questions are: Do the personnel areas map correctly to the company codes established in Financial Accounting? Are employee groups defined with enough granularity to support security, reporting, and processing rules? Are there any orphaned or test structures left over from implementation that were never cleaned up?
The authorization objects to examine are S_IMG_GENE (generate enterprise IMG), S_IMG_ACTV (perform functions in the IMG), and S_PRO_AUTH (new authorizations for projects). Run a user list from SU10 or using your security reporting tool to identify everyone who holds these objects. A common finding is that a broad group of IT or HR staff retained IMG access after go-live, far beyond the implementation team that legitimately needed it.
SAP S/4HANA note: In S/4HANA, organizational structures are increasingly managed through the Organizational Management Fiori apps and the Business Partner model. The underlying table logic is similar, but auditors should also check the Manage Workforce app permissions and the corresponding authorization roles in the Fiori launchpad, as these can grant effective configuration access outside the traditional IMG path.
2. Master Data Controls
Master data in SAP HCM is the heart of the employee record. It covers everything from hiring actions and personal information to bank details, recurring payments, and organizational assignments. If someone can manipulate master data without appropriate controls, the consequences range from ghost employees on the payroll to unauthorized pay changes to concealed conflicts of interest.
This domain covers several interconnected areas, each deserving its own attention.
Personnel Actions
Personnel actions are the formal business processes that move employees through the employment lifecycle: hiring, transferring, terminating, retiring. In SAP, each action triggers a series of infotypes — structured screens that capture the information needed to complete that action. The action is initiated through PA40 (Personnel Actions), and the infotypes are maintained through PA30 (Maintain HR Master Data) and displayed through PA20 (Display HR Master Data).
When auditing personnel actions, your first step is to review the action menu configuration in the IMG and verify that the list of available actions matches what the company has officially sanctioned. Then check whether user groups have been configured to restrict which actions each HR role can execute. An HR generalist responsible for onboarding should not be able to process terminations, and vice versa.
The most important authorization object here is P_ORGIN (HR Master Data), which controls access by infotype, personnel area, employee group, employee subgroup, subtype, and organizational key. This granularity is what makes SAP authorization both powerful and complex. A poorly designed role that grants access to all infotypes with all authorization levels is effectively giving a user full read and write access to every employee record in the system.
Key infotypes to flag during your review include:
- IT 0000 — Personnel Actions
- IT 0001 — Organizational Assignment
- IT 0002 — Personal Data
- IT 0008 — Basic Pay
- IT 0009 — Bank Details
- IT 0014 — Recurring Payments and Deductions
- IT 0015 — Additional Payments
A common and serious finding is that users who enter or approve pay data also have access to run PA40 for terminations or rehires. This represents a segregation of duties failure that could allow fraudulent manipulation of the employment record without a compensating review.
T-codes to use: PA40, PA30, PA20, PA10 (Personnel File), PA70 (Fast Data Entry), SARP (HR Report Tree)
Infogroups and Dynamic Actions
Infogroups define which infotypes appear — and in what sequence — when a personnel action is executed. Auditors often overlook this area, but it matters significantly. If the infogroup for a hire action omits the bank details infotype, an employee could be set up in the system without a payment method, creating a gap that payroll would have to work around manually.
Dynamic actions are SAP's automated triggers: when a condition in one infotype is met, the system automatically presents another infotype for data capture. For example, if an employee's marital status changes in IT 0002 (Personal Data), the system should trigger the benefits enrollment screen (PA90) to capture updated dependent information. If dynamic actions are not correctly configured, these downstream processes fail silently.
To review dynamic actions, navigate through SPRO → Personnel Management → Personnel Administration → Setting Up Procedures → Create Dynamic Actions. Then actually test them: execute a personnel action that should trigger a dynamic action and confirm it fires correctly. Configuration that looks right in the IMG does not always behave correctly at runtime.
Infotype Screen Control and Authorization
Screen control allows the system to show or hide specific fields within an infotype based on the user's role. This is an important privacy and compliance mechanism. For example, fields containing Social Insurance Numbers or date of birth should not be visible to users whose role does not require that information.
To review screen controls, use SPRO → Personnel Management → Personnel Administration → Customizing User Interface → Determine Screen Modifications. Then walk through key infotypes manually using PA20 and PA30 and confirm that sensitive fields are being suppressed for roles that should not see them. A finding here — sensitive fields visible to users without a business need — can trigger obligations under privacy legislation such as GDPR or applicable state and provincial privacy laws.
The authorization object P_PERNR is worth specific attention. This object controls whether a user can access their own personnel number, and in many implementations, it is not restricted, meaning an HR administrator or payroll clerk can view and potentially modify their own record. This is a self-service risk that should always be tested.
Organizational Key
The organizational key (field VDSKI in IT 0001) provides a powerful secondary layer of access control. It allows an administrator's access to be restricted to only the employees assigned to them, going beyond the coarser controls of personnel area and employee group. When properly implemented, an HR business partner supporting a specific department can only see and maintain records for employees in that department.
Review the organizational key setup through SPRO → Personnel Management → Personnel Administration → Organization Data → Organizational Assignment → Set Up Organizational Key. Check tables T527 (organizational key control), T527A (creation rules), and T5270 (descriptions). Then test it: use a test user account that has an organizational key restriction and attempt to access an employee outside that restriction. The system should deny the access.
In many SAP implementations, the organizational key is defined but never enforced — meaning the configuration exists but the key is not actually assigned in user master records. This is a common gap that provides a false sense of security.
Menu Options, Objects on Loan, and Cost Distribution
Three additional master data areas deserve attention, though they are often skipped in routine audits.
Menu options accessible through PA30's auxiliary functions — including the ability to delete a personnel number (PU00), change payroll status (PU03), and change the date of hire (PA41) — carry significant fraud risk. The ability to delete a personnel number or change a hire date can be used to manipulate service calculations, benefit entitlements, and payroll history. Access to these functions should be extremely limited.
Objects on loan are tracked in IT 0040 and should be cross-referenced against IT 0032 (Internal Control) for asset number linkage and against IT 0014 (Recurring Payments/Deductions) for any associated perquisite deductions. Use PE03 (Feature Maintenance) to check feature ANLAC, which controls the number of loan objects and asset number validation. A common finding is that objects on loan are tracked inconsistently, with no recurring deduction set up to reflect the taxable benefit value.
Cost distribution in IT 0027 is the mechanism that splits an employee's costs across multiple cost centers or controlling objects. View this infotype through PA30 and confirm that the cost centers referenced are valid and match the employee's actual organizational assignment. Mismatches between the cost center in IT 0001 and the distribution in IT 0027 can produce incorrect financial postings that financial auditors may catch only at period close.
Master Data Reports
Master data reporting is a critical control layer, and access to certain reports is itself a risk. Reports like RPAUD00 (Logged Changes for Infotype Data) provide an audit trail of who changed what in employee records and when — this is your primary evidence source for investigating unauthorized changes. Ensure this report is available to auditors and compliance staff, and check whether change logging has been activated for all sensitive infotypes.
Access to reporting is controlled through P_ABAP (HR: Reporting) along with P_ORGIN and P_ORGXX. Use SA38 (ABAP Reporting) and SE38 (ABAP Editor) to review which programs users can execute. A finding here is that broad access to SA38 effectively bypasses infotype-level authorization, because some reports read HR clusters directly rather than going through the standard authorization checks.
T-codes for reporting: PM00 (Personnel Administration Reporting), SA38, SE38, SARP
3. Organizational Management
Organizational Management (OM) in SAP defines the formal structure of the company: organizational units, jobs, positions, and the relationships between them. It is tightly integrated with Personnel Administration (PA), and when that integration is functioning correctly, a personnel action automatically updates the organizational assignment of an employee. When it is not, you end up with position data that contradicts what is in the employee's master record.
PA/PD Integration
The integration between Personnel Administration and Personnel Development (Organizational Management) is controlled by a switch in the IMG. Verify that this switch is active by navigating through SPRO → Personnel Management → Organizational Management → Integration → Set Up Integration with Personnel Administration → Basic Settings. Look for the entry PLOGI/ORGA, it should have an "X" value indicating integration is active.
T-code: OOPS can also be used to check integration settings directly. If integration is off, organizational assignment changes made through personnel actions will not flow through to the OM side, meaning position assignments will be out of date. This matters for access control, reporting, and succession planning.
Organizational Structure, Jobs, and Positions
The organizational structure should reflect the company's actual hierarchy. Use OOOE (Overview of Organizational Units) to browse the structure and PPOC (Create Organizational Units) or PO10 to examine individual units. For jobs, use PO03 (Create Job Object) and PSOC (Job Report Tree). For positions, use PO13 (Create Position Objects) and PSOS (Report on Positions).
When reviewing positions, confirm that each position has the required relationships established: position to job (object S to object C) and position to organizational unit (object S to object O). Positions without these relationships, known as unrelated objects, are a maintenance and reporting problem. Use the organizational structure drill-down in the OM detailed maintenance screen to identify unrelated objects, or run report RHSTRU00 (Organizational Structure) through SA38.
A common audit finding in this area is that positions are created for reporting or security purposes but never properly linked to jobs or organizational units, resulting in a fragmented org chart that does not accurately represent the company.
T-codes to use: OOOE, PPOC, PO10, PO03, PO13, PP70, PP01, PPOM, PSOG, PSOO
Work Locations
Work centers (locations) in SAP OM are maintained through PO01 (Maintain Work Centers) and reported through PSOA (Reports on Work Centers). The audit focus here is straightforward: do the work centers configured in the system reflect actual company locations, and are they properly linked to organizational units and cost centers? Misaligned work center data can affect time management configuration, particularly the assignment of personnel subarea groupings and public holiday calendars.
4. Payroll Controls
Payroll is the highest-risk area in any SAP HCM audit. Errors here are not theoretical — they result in employees being overpaid or underpaid, incorrect tax remittances, and erroneous general ledger postings. The audit approach in payroll requires both a configuration review and a rigorous access control review, because the two risks reinforce each other.
Payroll Accounting Areas
Payroll accounting areas define the pay cycle groupings: which employees are paid together, on what schedule, and under what processing rules. Review these using OH00 or through the IMG path: Payroll Accounting → Basic Settings → Payroll Organization → Check Payroll Accounting Area. Feature ABKRS defaults the payroll area assignment for each employee.
The audit concern here is over-complexity. Too many payroll accounting areas create unnecessary administrative burden and increase the risk of an employee being assigned to the wrong area — leading to incorrect pay frequency or missed payroll runs. The right number of payroll areas is the minimum required to handle genuinely different processing rules.
T-code: PA03 (Personnel Control Record) is essential in this area. It shows the current status of each payroll area — open, released, or exited — and prevents retroactive changes when a payroll area is in a released or exited state. Auditors should verify that the control record process is being followed properly and that no one is manually reversing the payroll area status to make retroactive changes outside the normal correction process.
Pay Infrastructure and Wage Types
Wage types are the building blocks of payroll calculation. They determine how employees are paid, what deductions are taken, what is taxable, and how everything posts to the general ledger. The authorization to create and maintain wage types should be restricted to individuals who have no responsibility for entering or approving pay — this is a fundamental segregation of duties control.
Review the wage type catalog through the IMG: Personnel Management → Personnel Administration → Payroll Data → Basic Pay → Wage Types → Check Wage Type Catalog. The relevant tables are V_512W_T (wage type texts), V_52D7_B (wage type groups), and T511 (wage type attributes).
Pay particular attention to permissibility settings. SAP allows you to restrict which wage types are available for which employee subgroups and personnel subareas. If permissibility is not properly configured, a user could manually enter a wage type that should not apply to a particular employee — for example, a bonus wage type applied to an hourly worker not eligible for bonuses.
Also review the payroll schemas and rules using PE01 (Personnel Calculation Schemas) and PE02 (Personnel Calculation Rules). These define the logic that drives the payroll calculation engine. Unauthorized changes to schemas or rules can silently alter payroll results for large groups of employees. Access to PE01 and PE02 should be treated with the same sensitivity as access to financial system configuration.
T-codes to use: PE01, PE02, PE03, PCIK (Payroll Accounting Activities), SM31
Basic Pay and Other Payroll Data
Infotype IT 0008 (Basic Pay) is the most sensitive infotype in the system. It stores salary rates, pay scale assignments, and the pay scale groups and levels that drive compensation. Review the authorization on this infotype carefully using P_ORGIN with the infotype value set to 0008. Confirm that access is limited to HR administrators whose job function requires it, and that payroll clerks can read but not modify it unless that is an explicit business requirement.
The self-access risk is particularly important here. Auditors should always test whether employees — especially HR staff — can access and modify their own IT 0008 record. Use a test user account to attempt this, and confirm the system blocks it. P_PERNR controls this check, but it must be actively configured.
Other payroll infotypes requiring access control review include:
- IT 0009 — Bank Details (a classic target for payroll fraud)
- IT 0014 — Recurring Payments and Deductions
- IT 0015 — Additional Payments
- IT 0066 through IT 0068 — Garnishment Order, Debt, and Adjustment
- IT 0224 — Tax Information
Bank details deserve special mention. A user who can change IT 0009 without compensating review controls can redirect another employee's pay to a personal account. This is one of the most frequently observed payroll fraud mechanisms in SAP environments, and it is preventable with proper authorization and a detective report that identifies changes to bank details within the pay cycle.
T-codes to use: PA30, PC00 (HR Payroll Menu), PCIK, PA03
Running Payroll and Off-Cycle Payroll
The payroll run itself is executed through the payroll driver and managed through the payroll menu. Key T-codes include PC00 (HR Payroll Menu), PC1K (Payroll Menu for Canada), and the simulation capability accessible through the payroll menu path. Always verify that simulation runs are available and that auditors or finance staff can run simulations without triggering an actual payroll.
Segregation of duties in the payroll run process means that the person who maintains employee master data (basic pay, bank details) should not be the same person who initiates and releases the payroll run. Review the Personnel Control Record (PA03) to understand the release workflow, and map the user access against the org chart to confirm this segregation exists.
Off-cycle payroll runs warrant particular scrutiny. These are by definition exceptions to the normal cycle, and they carry a higher risk of unauthorized payments — whether through adjustment checks, on-demand checks, or manual checks. Run a list of all off-cycle runs in the audit period and review the authorization and business justification for each. The access to initiate off-cycle runs should be limited and well-documented.
Key authorization objects for payroll: P_ABAP, P_TCODE, P_PCLX (payroll clusters PCL1 through PCL4), P_ORGIN, P_ORGXX, P_PERNR, S_TMS_ACT
Payroll Reports
Access to payroll reports is a proxy for access to payroll data. Reports like RPCALCKO (Payroll Simulation), RPCEDTKO (Remuneration Statements), and RPCLJNKO (Payroll Journal) contain sensitive compensation information for all employees in a payroll area. Restrict access through authorization groups assigned in SE38 and verify through the P_ABAP object.
A practical audit step: run SA38 and search for programs matching RPC* to see all payroll-related programs. Then cross-reference who has access to those programs via P_ABAP and determine whether that list is appropriate.
5. Time Management
Time management in SAP HCM encompasses holiday calendars, work schedules, time recording, absences, overtime, and attendance. It sits at the intersection of HR, payroll, and operations — and errors here ripple through into pay calculations, labor cost reporting, and compliance with collective agreements.
Holiday Calendars and Work Schedules
The public holiday calendar defines which days are recognized as holidays and how employees are compensated for working on those days. Review the calendar configuration through SPRO → Global Settings → Maintain Calendar, or use SCA1 (Display Public Holidays) and SCA2 (Display Public Holiday Calendar). Table THOL contains the holiday entries.
Auditors should verify that the calendar accurately reflects the company's recognized holidays by jurisdiction, particularly important in organizations operating across multiple provinces or states where statutory holidays differ. A single incorrect holiday class (full day versus half day, for example) can result in systematic payroll errors for every employee affected.
Work schedules are more complex. They are built in layers: break schedules feed into daily work schedules, which feed into period work schedules, which combine with employee subgroup groupings and public holiday calendar assignments to produce the work schedule rule recorded in IT 0007 (Planned Working Time). Use PT01 (Create Monthly Work Schedule), PT02 (Change), and PT03 (Display) to review schedules. Feature SCHKZ controls how work schedules default into IT 0007 based on employee subgroup.
The audit question is whether work schedules adequately — but not excessively — cover all the variations required by the workforce. Too few schedules force workarounds. Too many create maintenance complexity and inconsistency.
Tables to review: T550P (break schedules), T550 (daily work schedules), T551A (period work schedules), T508A (work schedule rules)
Time Recording
Time recording in SAP captures exceptions to the standard work schedule: absences, attendances, overtime, and substitutions. Data enters the system either through direct entry in PA61 (Maintain Time Data) or through time recording terminals feeding into the HR cluster. The time evaluation driver RPTIME00 then processes this raw data into compensated hours and feeds results to payroll.
Audit focus here centers on three risks. First, can a time administrator change their own time records? This self-service risk — controlled via P_PERNR — is a common finding. Second, are overlapping time entries detected and rejected? SAP has built-in collision handling for infotype time constraints, but these must be correctly configured. Third, is there a clear workflow for supervisory approval of time entries, particularly overtime, before data is passed to payroll?
Key infotypes in time recording include IT 2001 (Absences), IT 2002 (Attendances), IT 2003 (Substitutions), IT 2004 (Availability), IT 2005 (Overtime), IT 2006 (Absence Quotas), and IT 2007 (Attendance Quotas).
T-codes to use: PA61, PA63, PA30, PA51 (Display Time Data), PT40 (Time Management Pool), PT60 (Time Evaluation), PT63 (Personal Work Schedule)
Absences, Vacation Tracking, and Overtime
Absence management and vacation tracking are closely linked. Leave types are defined in table T533 and flow into IT 0005 (Leave Entitlement). Absence quota type 99 must be assigned to vacation to ensure that vacation taken in IT 2001 automatically decrements the quota in IT 0005. Run report RPTLEA30 to verify that leave entitlements are being generated correctly.
A frequent audit finding is that employees have taken more vacation than their quota allows, with no system-enforced control preventing it. SAP can be configured to warn or prevent over-quota absences, but this requires explicit configuration of quota deduction rules. Check whether these rules are active and whether someone is reviewing exception reports regularly.
Overtime is recorded in IT 2005 and can trigger either additional pay or compensatory time, depending on the wage type assigned. The audit concern is access: who can record overtime in IT 2005? If employees can enter their own overtime without supervisor approval in the system, the compensating control must be a robust manual review process. Use PT40 (Time Management Pool) to view time management exceptions and pending approvals.
T-codes to use: PA61, PT40, PA53, SA38, SE38
Key reports: RPTABS20 (Absence & Attendance Overview), RPTLEA00 (Leave Overview), RPTCMP00 (Time Leveling)
SAP S/4HANA note: In SAP SuccessFactors integrated environments, time and attendance data may be captured in SuccessFactors Time Tracking and pushed to S/4HANA via integration middleware. Auditors should verify that the integration mapping correctly handles absence types and that quota balances reconcile between the two systems. The Fiori app My Time Events and its underlying authorization objects in S/4HANA differ from the classic PA61 authorization model.
Time Evaluation
Time evaluation is the engine that converts raw time data into compensated results. Schemas and rules configured in PE01 and PE02 define how time is evaluated, which hours qualify for premiums, how overtime thresholds are calculated, and how time balances are maintained. Access to modify these schemas carries the same risk as access to payroll schemas: unauthorized changes can silently alter how every employee's time is calculated.
Year-end time processing adds another layer of risk. Quotas must be transferred to the new year, leave credits must be either carried forward or paid out per policy, and calendars and schedules must be generated for the coming year. Use PT60 (Time Evaluation), PE01, and PE02 to review these processes. Table T511K/LVACR controls the leave accrual constant (defaulting to 1.25 days per month in standard SAP), verify this matches the company's policy.
T-codes to use: PE01, PE02, PT60, PT61 (Time Statement), PU22 (Archiving Results)
6. Compensation Management
Compensation management controls how salary ranges are defined, how budget is allocated for merit increases, and how compensation awards are processed and activated. The key risk is that compensation changes bypass the defined approval workflow and are entered directly into the system without appropriate authorization.
Review the plan and budget setup using HRCMP0001, HRCMP0002, and HRCMP0003. Ensure that plan periods are defined and that budget structures are approved before increases are processed. The salary structure review focuses on whether pay grade ranges accurately reflect the company's compensation policy and whether any employees fall outside their assigned grade range.
For the compensation process itself, HRCMP000 is the primary transaction for processing merit and incentive increases. The workflow should include submission, approval, and activation steps — and each step should be performed by a different role. Auditors should verify that the person who submits an increase cannot also activate it into the employee's basic pay record.
The relevant infotypes for compensation management are IT 0008 (Basic Pay), IT 0014 (Recurring Payments), IT 0015 (Additional Payments), IT 0025 (Appraisals), IT 0380 (Compensation History), and IT 0381 (Employee Eligibility). Access to IT 0380 in particular provides a historical record of all compensation changes — this is a useful evidence source for auditors investigating unusual pay activity.
T-codes to use: PA30, PA97 (Compensation Matrix), PA98 (Administration — Salary Increase), PA99 (Release), HRCMP000
7. Benefits Administration
Benefits administration in SAP HCM manages the definition of benefit plans, enrollment of employees, vendor and cost configuration, and the integration of benefit deductions with payroll. The complexity of this area — especially when pre-tax and post-tax contributions, imputed income, and contribution limits are involved — makes it a fertile ground for both configuration errors and access control gaps.
The benefits configuration lives under SPRO → Personnel Management → Benefits. Note that to view the Benefits section of the IMG, users must have the parameter BEN added to their user parameters via SU52. This is itself a control — only those who need to configure benefits should have this parameter set.
Benefit Areas, Plans, and Eligibility
Benefit areas define the top-level grouping (for example, US benefits versus Canadian benefits) and control which payroll areas are associated with each benefits configuration. Review the benefit area setup through the IMG and feature BAREA. Then review the benefit programs, employee benefit groups, and plan year definitions under the Basic Settings section.
For each plan type , health, insurance, savings, confirm that eligibility rules have been configured correctly. The key control is that the enrollment screen presented to an employee shows only the plans for which they are eligible. If eligibility rules are misconfigured, an employee could be enrolled in a plan they are not entitled to, or more commonly, be excluded from a plan they should have access to. Use PA90 (Benefits Enrollment Screen) to test enrollment for sample employees and confirm that only eligible plans appear.
The ELIGR feature drives the assignment of eligibility rules to employees. Review this feature in PE03 and confirm its logic matches the company's benefit eligibility policy.
Vendors, Costs, and Default Plans
Benefit providers or vendors should be set up in the system only after going through the company's standard vendor selection process, including competitive bidding where applicable. Verify that each benefit provider in SAP corresponds to an approved vendor in the accounts payable system. The cost formulas associated with each plan should be reviewed for accuracy, particularly when plan costs change at the beginning of a new plan year.
Default benefit plans, plans that employees are automatically enrolled in without an active election, carry a specific audit risk. If defaults are misconfigured, employees may be enrolled in plans they did not choose, potentially triggering incorrect deductions and benefit costs. Review default plan configuration through the IMG under Flexible Administration and check tables T5UB6 (Health Plans) and T5UB7 (Insurance Plans).
T-codes to use: PA90, PA85 (Employee Demographics), PA86 (Benefit Change), PA87 (Eligibility Change), PA91 (Enrollment Forms), PA93 (Benefits Configuration), PA94 (Benefits Report Tree), SU52
Family Members and Enrollment Controls
Family and related persons data is maintained in IT 0021 and feeds directly into benefits enrollment for dependents and beneficiaries. The types of relationships allowed in the system are configured through the IMG, and they should reflect the company's defined benefit eligibility for dependents. Unauthorized additions of dependents, particularly in health plan and life insurance contexts, are a real fraud risk that auditors should test by reviewing IT 0021 changes during the audit period using RPAUD00.
8. Career, Succession Planning, and Recruitment
Career and succession planning in SAP HCM identifies critical positions and maps qualified candidates against them using qualification profiles. The qualifications catalog, maintained through OOQA (Setting Up Qualification Catalog), defines the skills and competencies against which positions and persons are evaluated. The decay meter feature — maintained through OOHW, reflects the diminishing relevance of qualifications over time.
Audit focus here is on data integrity and access. Who is responsible for maintaining qualification objects and profiles? Is the qualification catalog kept current, or are there qualifications that no longer exist in practice but remain active in the system? Are succession planning reports, particularly SAPMHTAQ (Succession Planning), restricted to authorized users?
T-codes to use: OOQA, OOHW, PP01, PSQ1 through PSQ8, PSR2 through PSR5
For recruitment, the audit concern is whether the applicant administration process supports segregation of duties: the person who creates a job requisition should not also approve it, and the person who processes an applicant hire should not have unrestricted access to manipulate the applicant status throughout the selection process. Review applicant status changes through the recruitment module and confirm that status transitions follow the defined workflow.
9. Extended Checks: Change Logs, User Tables, and Double Verification
No SAP HCM audit is complete without a set of extended checks that cut across all the domains reviewed above.
RPAUD00 (Logged Changes for Infotype Data) is the single most valuable report for a forensic or control review. It shows every change made to HR infotypes, including who made the change, when, what the old value was, and what the new value is. Run this report for all sensitive infotypes (IT 0008, IT 0009, IT 0014, IT 0015) over the audit period and look for changes made outside business hours, changes that were quickly reversed, and changes made by users to records in their own organizational area.
Employee number integrity should be checked to ensure there are no duplicate records, no gaps in the numbering sequence that suggest deleted records, and no personnel numbers that appear in multiple payroll areas simultaneously. Use SE16 (Data Browser) to query personnel number tables directly.
Double verification, sometimes called four-eyes control, should be configured for the most sensitive changes. In practice, this means that a change to bank details or basic pay entered by one user must be explicitly confirmed by a second user before it takes effect. Verify whether double verification has been activated in the system and, if so, whether it is working as intended by testing a sample change and observing whether the confirmation prompt appears.
User table access is the final frontier. Tables accessible through SM30 and SM31 contain configuration data that, if modified directly, can alter system behavior without leaving the same audit trail as a standard transaction. Run a list of users with access to table maintenance and confirm this list is limited to basis and authorized configuration staff.
T-codes for extended checks: SE16, SM30, SM31, SA38, RPAUD00, SU10
10. Performance Appraisals
Performance appraisals in SAP HCM are not just an HR formality — they are a direct input into payroll. When configured correctly, the results recorded in IT 0025 (Appraisals) automatically trigger changes to IT 0008 (Basic Pay), moving an employee up or down a pay scale group and level chain based on their appraisal outcome. This tight integration between performance management and compensation is powerful, but it also means that a misconfigured appraisal setup — or unauthorized access to appraisal records — can produce unintended salary changes at scale.
The configuration starts with defining the appraisal criteria themselves. These are the dimensions on which employees are evaluated: problem solving, quality of work, teamwork, and so on. Each criterion is defined in table T513F and assigned a weight in table T513H. Those weights default automatically into IT 0025 when an appraisal record is created, so auditors should verify that the weights in the table match the company's approved appraisal policy documentation. Discrepancies between what the policy says and what the system calculates are a frequent and underappreciated finding.
Appraisal criteria are further defined for specific main appraisal features using tables T510U_C and T5J59, and the grouping of personnel subareas and employee subgroups is controlled through tables T001P_L and T503_F. The principle here is that employees who are evaluated against the same criteria should be grouped together — so that pay scale group and level chains can be applied consistently across comparable roles.
From a security standpoint, the critical question is who can create or modify IT 0025 records. Because appraisal results feed directly into basic pay changes, unauthorized access to this infotype is effectively unauthorized access to payroll. Use your authorization review of P_ORGIN with infotype 0025 specified to generate the user list, and then cross-reference it against the list of users with access to IT 0008. Anyone appearing on both lists holds a significant segregation of duties conflict — they can set the appraisal result and benefit from the pay change it triggers.
Also confirm that the appraisal process is being followed procedurally. The system can be configured correctly and still be bypassed if managers are directly entering results without going through the defined review and approval steps. Ask for a sample of completed appraisal records and trace them back to the underlying approval documentation.
Related infotypes: IT 0001 (Organizational Assignment), IT 0002 (Personal Data), IT 0008 (Basic Pay), IT 0025 (Appraisals)
T-codes to use: PA30 (Maintain Master Data), PA20 (Display Master Data)
Tables: T513F, T513H, T5J12, T510U_C, T5J59, T001P_L, T503_F
11. Recruitment
The recruitment module in SAP HCM manages the full applicant lifecycle — from vacancy creation and advertising through applicant administration, selection, and ultimately conversion to an employee record. Because recruitment sits at the boundary between the outside world and the HR system, it carries specific risks around data integrity, unauthorized access to applicant information, and the integrity of the hire decision itself.
Integration Settings and Applicant Number Control
The first thing to verify in a recruitment audit is whether the module is properly integrated with Personnel Administration (PA) and Organizational Management (PD). This integration is controlled by the same PLOGI/ORGA switch reviewed in the Organizational Management section. When integration is active, internal applicants can have their existing employee data made available in the recruitment process — controlled by feature PRELI — and employee data from the administration side is available for recruitment processing via feature PRELR.
Feature NUMAP controls whether applicant numbers are assigned internally by the system or entered manually. Internal assignment is always preferable from a control standpoint: manual number assignment creates the risk of duplicate applicant records or deliberate manipulation of applicant IDs to obscure a candidate's history in the system.
To verify these settings, navigate through SPRO → Personnel Management → Recruitment → Basic Settings → Set Up Integration with Personnel Administration. Also check the number range configuration for applicant numbers, which defines the valid range and whether gaps are allowed.
Vacancy Management and Advertising
In SAP, a vacancy formally triggers the recruitment process. If integration with Organizational Management is active and IT 1007 (Vacancy) is enabled, every unfilled position flagged as vacant automatically enters the recruitment pipeline. Auditors should verify whether IT 1007 has been activated and whether the vacancy status on positions is being kept current — an organization with hundreds of positions marked as vacant when only a handful are actively being recruited creates noise that obscures legitimate openings and can complicate headcount reporting.
Each vacancy in the system is assigned a personnel officer, a line manager, and a staffing status. Confirm that these assignments are complete and accurate. A vacancy with no assigned personnel officer has no designated owner, meaning no one is formally accountable for the recruitment process for that position.
Recruitment instruments and media — the channels through which positions are advertised — are defined in the IMG under SPRO → Personnel Management → Recruitment → Workforce Requirements and Advertising. Review whether the media and instruments configured reflect the company's actual recruiting practices, and whether there are any active advertising channels that are no longer in use but have not been deactivated.
Menu path for vacancy maintenance: Human Resources → Personnel Management → Advertising → Vacancy → Maintain
Applicant Administration and Selection
Applicant data is maintained through PB30 (Maintain Applicant Master Data), the recruitment module's equivalent of PA30. Applicants are classified by applicant group (differentiating temporary versus permanent, external versus internal) and applicant range (further classification within the group). These groupings can be used to restrict access — an HR recruiter responsible for external hiring should not have access to the files of internal applicants who have applied for positions under a different business unit's purview.
The infotypes involved in applicant administration closely mirror the employee master data structure:
- IT 4001 — Applications
- IT 4000 — Applicant Events
- IT 4002 — Vacancy Assignment
- IT 4004 — Change Action Status
- IT 4005 — Applicant's Personnel Number
Additional data captured during the recruitment process includes IT 0022 (Education), IT 0023 (Previous Employment), and IT 0024 (Qualifications) — the last of which feeds directly into the qualifications catalog if the Career and Succession Planning module is integrated.
The selection process — comparing applicant qualifications against position requirements — uses the same qualifications catalog infrastructure reviewed in the Career and Succession Planning section. Auditors should confirm that selection decisions are documented in the system and that the applicant status trail in IT 4004 reflects the actual decision sequence. A candidate who moves from "In Process" to "Hired" without intermediate status records may indicate that the formal selection process was bypassed.
Key authorization objects: PLOG, P_APPL (Applicant), P_PCLX
T-codes to use: PB30, PA30, SPRO (IMG)
12. Training and Development
Qualifications and Course Administration
The Training and Development module in SAP HCM manages the formal connection between employee competencies and business requirements. Qualifications are the skills, certifications, and competencies attached to employees and positions. When a qualification expires or decays below a required proficiency level, the system should flag it for renewal. When an employee completes a training course, their qualification record should be automatically updated to reflect the new or refreshed competency.
The qualifications catalog is the foundation of this module. It must be defined and configured before qualifications can be assigned to positions or employees. Key tables include P1000 (object descriptions), P1001 (relationships between objects), and P1025 (the decay meter, which defines the lifespan of a qualification before it needs to be recertified). Report RHXQCATO provides an overview of the qualifications catalog and is a useful starting point for reviewing whether the catalog is current and well-maintained.
T-code: PO11 is used to maintain qualification objects. During the audit, review whether qualifications attached to high-risk or regulated roles — safety certifications, professional licenses, compliance training completions — are being tracked with appropriate decay meters and renewal workflows. A qualification catalog that is never updated becomes a compliance liability rather than a control.
Course administration is managed through a set of business event transactions. Training programs are defined as business event types (PO04), with resources (instructors, rooms, materials) and costs attached. Individual events are planned using PV10 and created using PV11. Attendance bookings, cancellations, and rebookings are managed through PV15, which also handles the transfer of learning objectives to the attendee as qualifications upon course completion.
Cost transfer to Controlling is handled through PVIC, which posts training costs to the relevant cost centers. Auditors reviewing training and development should confirm that costs are being transferred correctly and that the cost assignment matches the organizational unit of the attendee rather than a generic training cost center.
A common finding in this area is that the qualifications module is configured but not maintained — qualifications are assigned to positions at implementation and never updated as job requirements evolve, and course completion records are not consistently loaded into the system. The result is a qualification profile that looks complete on paper but does not reflect reality.
T-codes to use: PO04, PV10, PV11, PV15, PVIC, PO11, OOQA
Key authorization objects: PLOG, P_ORGIN, P_TCODE
13. PD Authorizations and Structural Security
Understanding Structural Authorizations
Standard SAP authorization — the profile and role-based access control reviewed throughout this guide — works by restricting what a user can do based on transaction codes, infotypes, and organizational fields. Structural authorization adds a second dimension: it restricts which objects in the organizational hierarchy a user can access based on their position in that hierarchy.
When structural authorizations are active, a user's access to positions, organizational units, and persons is determined by a structural profile that defines a root object and an evaluation path through the organizational structure. A regional HR manager, for example, might have a structural profile rooted at their regional organizational unit, giving them access only to positions and persons within that region — even if their standard authorization role would otherwise allow broader access.
This makes structural authorization a powerful and important control in large organizations with complex hierarchies. But it also requires careful maintenance: if organizational structures change and structural profiles are not updated, users may retain access to organizational units they no longer support, or lose access to ones they now do.
Structural authorizations are activated by running report MPPAUTSW, which sets the authorization switch in the system. Verify that this has been done by checking tables T77PS and T77UA through SM31 or the IMG path: Personnel Management → Organization Management → Basic Settings → Authorizations Management → Structural Authorizations.
Profiles are maintained through OOSP (Maintain PD Profiles) and assigned to users through OOSB (Assign PD Authorization). A profile can also be attached directly to a position through PO13, meaning it takes effect automatically for whoever holds that position — an elegant approach that reduces the maintenance burden when people change roles.
The link between an employee's HR record and their system user account is established through IT 0105 (Communications), specifically the system user name subtype. Report RHPROFLO maps authorization profiles to system user names and is a useful cross-reference tool for auditors verifying that structural profiles are correctly assigned.
T-codes to use: OOSP, OOSB, PO13, PP70, SA38, SM31
Key authorization objects: PLOG, P_ORGIN, S_PROGRAM
When auditing PD authorizations, the central questions are whether structural authorization is actually in use, whether profiles are correctly rooted in the organizational hierarchy, whether there is a documented process for updating profiles when the organization changes, and whether someone is formally responsible for creating and maintaining those profiles. In many implementations, structural authorization was activated at go-live and then effectively abandoned — profiles exist but are never reviewed, and organizational changes flow through without triggering corresponding profile updates.
SAP S/4HANA note: In S/4HANA environments using SAP SuccessFactors for talent management, structural authorization concepts carry over but are implemented differently in the Fiori-based role model. The Business Role Management app and IAM (Identity and Access Management) framework in S/4HANA replace some of the traditional T77PS/T77UA table-based controls. Auditors should verify whether structural authorization is enforced at the S/4HANA layer, the SuccessFactors layer, or both — and whether there are gaps at the integration boundary.
14. Extended Security Checks
The final audit domain pulls together a set of checks that cut across the entire SAP HCM system. These are the controls that catch what everything else misses — the edge cases, the residual access risks, and the evidence trail that allows you to reconstruct what happened when something goes wrong.
Extended Master Data Check and P_ORGXX
The authorization object P_ORGXX enables an extended check on HR master data based on administrator field assignments in IT 0001. This is not active in the standard SAP system and must be explicitly turned on by running program MPPAUTSW and setting the AUTH_SW switch — typically done by the ABAP development team. When active, it restricts access to employee records based on who is designated as the HR administrator, time recording administrator, or payroll administrator for that employee in IT 0001.
The administrator assignments are:
- SACHP — HR Master Data Administrator
- SACHZ — Time Recording Administrator
- SACHA — Payroll Administrator
- SBMOD — Administrator Group (defined through feature PINCH)
This mechanism provides a very granular, person-level access control that supplements the coarser personnel area and employee group controls of P_ORGIN. To test whether it is working, transfer a test employee to a different department and then attempt to access that employee's record using a user account linked to the previous department's administrator. The system should deny access.
The audit question here is whether this level of control is actually required and whether, if it has been activated, it is being maintained correctly. Administrator field assignments in IT 0001 are only as current as the last time someone updated them — and in practice, they often lag behind organizational changes.
Employee Number Security and P_PERNR
Authorization based on personnel number, controlled through P_PERNR, allows access to be restricted to specific employee records — most commonly an employee's own record. This is the mechanism that enforces the rule that employees cannot view or modify their own salary or time data.
The check is not active by default. To activate it, run program MPPAUTSW through SE38 and turn on the AUTH_SW switch. The relevant field values in the P_PERNR object are:
- AUTHC — Authorization level (read, write, etc.)
- INFTY — Infotype
- SUBTY — Subtype
- PSIGN — Interpretation of the user/personnel number assignment: "I" gives authorization for the assigned personnel number only; "E" gives authorization for all personnel numbers except the assigned one
The assignment of user names to personnel numbers is maintained in table V_T513A, viewable through SM31. Auditors should pull this table and verify that every HR, payroll, and time management user has a personnel number assignment that correctly restricts their self-access.
A practical test: identify a payroll administrator in the system, log in as that user (or use a test account with the same profile), and attempt to access that administrator's own IT 0008 Basic Pay record. The system should block it. If it does not, P_PERNR is either not active or not correctly configured.
T-codes to use: SE38, SM31, SA38
Key authorization objects: P_ORGIN, P_ORGXX, P_PERNR
Double Verification
The double verification concept in SAP HCM provides a formal two-person approval requirement for sensitive data changes. The first person enters data into a locked record at authorization level E (entry). A second person then reviews and approves the change by unlocking the record at authorization level S (supervisor) or D (display and approve). The record cannot proceed to payroll processing until it has been through both steps.
This control is most valuable for high-risk transactions: additional earnings entered in IT 0015, bank detail changes in IT 0009, and manual time entries that affect overtime calculations. Verify whether double verification has been configured for these infotypes and test it by entering a change as a level-E user and confirming that the record is locked pending approval.
To review the profiles of HR and payroll users and verify their authorization levels, navigate through Tools → Administration → User Maintenance → Users, enter the username, and display the associated profiles. Drill into each profile to confirm that authorization levels are correctly assigned — no single user should hold both level E and level S or D for the same infotype and organizational scope, as this would allow them to enter and approve their own changes.
Change Log Monitoring: List Changes
The history tables for user master, authorization, and profile changes are among the most important evidence sources available to an SAP auditor. They record who changed what in the security configuration and when — making them essential for both ongoing monitoring and incident investigation.
The key history tables are:
- USH02 — Change History for Logon Data
- USH04 — Change History for Users
- USH10 — Change History for Profiles
- USH12 — Change History for Authorizations
Access these tables through SE16 (Data Browser) by entering the table name directly, or use SE17 (General Table Display). The change document transactions provide a more structured view: SU01 for profile changes, and the change documents menu path under Tools → Administration → User Maintenance → Repository Infosys for user and authorization changes.
During the audit, review these tables for the period under examination and look for changes made outside business hours, changes made immediately before or after a payroll run, and changes to highly privileged profiles or roles. Also look for changes that were quickly reversed — this pattern can indicate someone temporarily elevated their own access to perform an unauthorized action and then removed the evidence from the current state.
T-codes to use: SE16, SE17, SU01
User Tables and Critical Access Reports
The final set of checks uses SAP's built-in user reporting capabilities to provide a comprehensive view of who has access to what across the system.
The most important user tables are:
- USR01 — User Master (current active users)
- USR04 — User Modification Data and Number of Profiles
- USR11 — Profiles assigned to users
- USR12 — Authorization values
To get a complete listing of all user tables, navigate to SE16, enter USR* in the table name field, and use the dropdown to display all tables in the USR namespace. Similarly, all user-related reports can be found by entering RSUSR* in SA38.
The two most critical user reports for an SAP HCM audit are:
RSUSR001 — Lists all currently active users in the system. Run this and compare it against the company's active employee list. Any system user without a corresponding active employee record is a potential ghost account and should be investigated immediately.
RSUSR005 — Lists users with critical authorizations. This report can be configured to flag specific authorization object and field value combinations that the company has defined as high-risk. If this report has not been configured with a meaningful critical authorization profile, recommend that as a remediation action.
One check that should never be skipped: search for any user in the production environment with the profile SAP_ALL. This profile grants unrestricted access to every transaction and every object in the system. It should exist only in development and sandbox environments for technical testing purposes. Finding it in production — on any account, including technical or basis accounts — is a critical finding requiring immediate remediation.
To view the full range of user access information, navigate through Tools → Administration → User Maintenance → Repository Infosys and explore the sub-menus for Users, Profiles, Authorization Objects, Activity Groups, Transactions, Comparisons, Where-Used Lists, and Change Documents. This menu structure gives you a complete picture of the authorization environment and is where experienced SAP auditors spend a significant portion of their fieldwork time.
T-codes to use: SE16, SE17, SA38, SU01, SU10
Key reports: RSUSR001, RSUSR005
Essential SAP Audit & HR Resources
SAP Trust Center: Compliance and Audit Reports
- Why you need it: This is the ultimate starting point for IT and compliance auditors. The SAP Trust Center provides official, downloadable SOC 1, SOC 2, and ISO audit reports for SAP’s cloud environments (including SuccessFactors). It is essential for verifying third-party assurances and understanding SAP's shared responsibility model.
SAP Help Portal: SAP ERP Human Capital Management (HCM)
- Why you need it: For organizations still running on-premise SAP HR, this is the official documentation hub. Auditors should bookmark this page to cross-reference standard Infotypes, backend tables, and traditional T-codes (like PA30 and PT60) when verifying system configurations against business policies.
SAP Help Portal: SAP SuccessFactors HCM Suite
- Why you need it: As noted in our audit guide, modern HR processes like Recruitment and Performance Appraisals have heavily migrated to the cloud. This portal provides the official technical documentation necessary to audit SuccessFactors' role-based permissions (RBP), APIs, and S/4HANA integration points.
SAP Community: Governance, Risk, and Compliance (GRC)
- Why you need it: The SAP Community is an invaluable resource for real-world audit scenarios. The GRC topic page is filled with expert discussions, blogs, and Q&As regarding Segregation of Duties (SoD) conflicts, structural authorizations, and mitigating insider threats using SAP Access Control.
SAP Security Baseline Template (SAP Support Portal)
- Why you need it: SAP publishes an official "Security Baseline Template" (often referenced via SAP Note 2253549) that details the absolute minimum security configurations every SAP system should have. Auditors can use these official baselines to measure a client's password policies, extended security checks, and authorization limits.
ISACA: IT Audit Frameworks and SAP Audit Programs
- Why you need it: ISACA is the global gold standard for IT auditing. While not an SAP-owned site, ISACA provides independently developed, peer-reviewed SAP ERP audit programs and frameworks (like COBIT). Auditors should leverage ISACA's whitepapers to align their SAP HR and financial audit procedures with globally recognized risk management standards.
Closing Thoughts
Auditing SAP HCM effectively requires a combination of technical literacy and process understanding. The T-codes and tables in this guide give you the access points, but the judgment calls, the pattern recognition, and the ability to connect a configuration gap to a business risk are what separate a meaningful audit from a checkbox exercise.
A few principles to carry through every section of this work:
The IMG is the master key to the SAP HCM kingdom. Anyone with broad IMG access can change virtually any configuration setting. Always start your audit by identifying who has S_IMG_GENE and S_IMG_ACTV in their profiles, and treat that list as a high-risk population requiring additional scrutiny.
Self-access to HR records, the ability of an employee, administrator, or manager to view or modify their own data — is a recurring control gap. Test it in every domain. P_PERNR is the authorization object that should be preventing it, but it is frequently misconfigured or omitted.
Change logging is your evidence. RPAUD00 should be running, and its output should be reviewed regularly by someone independent of the HR and payroll teams. If change logging is not activated for sensitive infotypes, recommend it as a priority remediation.
And finally, keep your findings in context. SAP HCM
is a complex, deeply configurable system, and most organizations
implement only a portion of its capabilities. What matters is not
whether every feature is used, but whether the features that are in use
are properly controlled, and whether the controls in place are actually
working.
This guide was developed by Hernan Huwyler as a practical reference for internal auditors, external reviewers, and compliance professionals working in SAP HCM environments. It is intended to support audit planning, fieldwork execution, and finding development across the full scope of the HR module.
