SAP Migration Segregation of Duties: A Controller Review

What should a controller review before approving SAP access?

A controller should approve SAP migration access only after finance has reviewed conflicting duties, temporary privileges, emergency access, compensating controls, and post-go-live recertification. The review should name each role, affected finance process, business owner, duration, approval path, monitoring evidence, and condition for removal before cutover authority is released.

Key takeaways

• Finance should assess what each user can complete end to end, not only the names of assigned roles.
• Temporary migration privileges need an expiry date, approver, business reason, and retained activity record.
• A compensating control needs an owner, frequency, evidence source, and defined conflict that it addresses.
• Post-go-live recertification should remove project access rather than inherit the cutover roster.

SAP's current Access Control product page describes access-risk analysis, periodic user-access reviews, role-based access control, and controlled emergency access. Those are relevant capabilities, but the page does not make a tool the controller. Finance must decide which combinations are unacceptable, which exceptions it will tolerate, and what evidence is sufficient.

Philippine law does not prescribe SAP role names. The Data Privacy Act of 2012 does supply three dated numerical data points that matter when migration roles can reach personal information. Section 25 sets imprisonment of one to three years and fines of ₱500,000 to ₱2 million for unauthorized processing of personal information; its sensitive-information range is three to six years and ₱500,000 to ₱4 million. Section 35 applies the maximum penalty in the relevant scale when at least 100 persons are affected. These penalties are legal context, not a formula for ranking access conflicts.

Which SAP access conflicts should finance challenge?

Finance should challenge any access combination that lets one person create or change a financially significant record and complete the transaction or approval that relies on it. The controller can use the following original review card as a starting point, then map each row to the company's processes, SAP roles, approval limits, and local authority matrix.

SAP says its application can “identify and remediate violations of segregation of duties and critical access” through embedded risk analysis. The quotation supports automated analysis; it does not establish that a default rule set matches the company's chart of accounts, payment design, materiality, or delegated authority. The controller should require finance owners to sign the mapped conflict set before testing.

For a private-cloud program, Appcentric's RISE with SAP service is a relevant deployment route; for public cloud, see the GROW with SAP service. Deployment choice does not settle role ownership. The finance review should follow the actual target process and configured permissions in either case.

How should temporary and emergency access be controlled?

Temporary and emergency access should be time-bound, independently approved, tied to a named task, logged, reviewed after use, and removed when the task ends. The controller should reject “needed for cutover” as a complete business reason because it does not identify the transaction, duration, approver, or evidence.

SAP's product page describes temporary super-user status using firefighter login IDs in a controlled, auditable environment. A controller's migration rule can therefore require five records for each exception:

1. The request names the user, role, finance task, system, start time, and end time.
2. An authorized finance owner approves the business need before activation, except under a documented emergency route.
3. The system records activities performed during the access window.
4. An independent reviewer compares activity with the approved task and resolves differences.
5. The access owner removes the privilege and retains removal evidence.

The privacy review stays tied to finance data. Section 20 of the Data Privacy Act says a personal information controller must implement “reasonable and appropriate organizational, physical and technical measures” against unlawful processing. Section 21 keeps that controller accountable for personal information transferred to a third party for processing. Neither section mandates a particular SAP product or segregation matrix. They support asking who can use migrated employee, vendor-contact, customer, or expense data, for what approved purpose, and under whose accountability.

The corporate-governance anchor is Section 22 of the 2019 Revised Corporation Code, which places corporate powers, business conduct, and control of corporate property with the board unless the Code provides otherwise. Section 30 addresses director or trustee liability for willful assent to patently unlawful acts, gross negligence, or bad faith. These provisions do not turn the controller into the board. The finance review should escalate unresolved exceptions to the authority named in the company's bylaws, board resolutions, and approval matrix.

Appcentric's existing CFO migration approval guide covers the wider funding decision. This review is narrower: it asks whether finance access is acceptable before cutover and again after project privileges should end.

What should controllers ask at the final access review?

Controllers should require direct answers backed by the target-system role listing, workflow configuration, exception register, test results, and removal evidence. The final review is a finance acceptance decision, not a general cybersecurity assessment.

Is a clean role name enough to prove separation?

Is a clean role name enough to prove separation?

No. Review the transactions and approvals a user can complete across all assigned roles, including inherited, composite, temporary, and emergency access. A harmless-looking role can contribute one half of a conflict. The controller should assess the combined effective access against the approved finance-process map and authority limits.

Can a compensating control accept any conflict?

Can a compensating control accept any conflict?

No. The exception record should identify the exact conflict, why removal is impracticable, the control owner, review frequency, evidence, escalation threshold, and expiry. The controller should test the control with a realistic transaction before acceptance. A manager's awareness or an undocumented report is not evidence that the conflict is controlled.

Who should approve emergency finance access?

Who should approve emergency finance access?

Use the authority named in the company's approved access and finance policies. The requester should not approve the request or review personal activity. The record should state the task, time window, affected system, reviewer, and removal point. A break-glass route can be fast while still producing independent evidence.

When should project access be removed?

When should project access be removed?

Remove access when the approved migration task ends, not when the entire program closes. Set expiry at grant time and review extensions as new decisions. After go-live, recertify the production roster against operational job duties. Project membership, test-system access, or cutover participation should not become standing production authority.

What should block the controller's sign-off?

What should block the controller's sign-off?

Block sign-off when a material conflict lacks an approved treatment, temporary access has no expiry, emergency activity cannot be independently reviewed, migrated totals cannot be reconciled by someone other than the loader, or the post-go-live removal owner is unnamed. Record the blocker, decision owner, evidence needed, and next review date.