Accountability should sit with business owners, finance process leads, and SAP administrators working under a formal change control model. General ledger, AP, AR, and integration settings affect financial reporting and compliance, so no single technical team should change them alone. Clear ownership, approval workflows, and segregation of duties are essential to prevent silent control drift.
Why This Matters for Security Teams
Financial configuration in SAP is not a routine system setting. Changes to general ledger, accounts payable, and integration postings can alter how transactions are classified, approved, reconciled, and reported. That means a small configuration edit can create audit gaps, misstated balances, or unauthorized payment paths without any obvious application failure. Current guidance suggests treating these settings as control-bearing changes, not administrator convenience tasks.
This is also an identity and governance problem because the people or service accounts making changes often have broad access by default. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why hidden access paths persist in finance platforms. The same pattern shows up in incidents like the SAP Breach, where access and configuration risk become inseparable once trust is overextended. In practice, many security teams discover these issues only after a posting exception, control failure, or audit finding has already exposed the drift.
How It Works in Practice
Accountability should be split across business ownership and technical execution, with one clear approval path for each change. Finance process owners define the business impact, SAP administrators implement the approved change, and internal control or audit functions verify that segregation of duties is preserved. This aligns with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where configuration management, least privilege, and change oversight intersect.
A practical model usually includes:
- a named finance owner for the affected process, such as general ledger or AP;
- a SAP functional lead to validate the design and downstream posting impact;
- a technical administrator to carry out the change under ticketed approval;
- independent review before transport into production;
- logging that ties the change to a specific request, approver, and rollback plan.
For identity proofing and accountability, the question is not only who has access, but how that access is issued and tracked. The NIST SP 800-63 Digital Identity Guidelines reinforce the need for strong identity assurance around privileged actions, while NHIMG research on SAP SQL Anywhere Monitor Hardcoded Credentials shows how unmanaged credentials can undermine the very controls meant to protect financial systems. One relevant NHI stat: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. These controls tend to break down when SAP transports, emergency access, and integration accounts are managed outside the same approval workflow because the change trail fragments across teams.
Common Variations and Edge Cases
Tighter change control often increases cycle time, so organisations have to balance control strength against the need for timely finance changes at month end, quarter end, or during system cutovers. There is no universal standard for this yet, but current guidance suggests that emergency fixes should still retain retrospective approval, evidence capture, and post-change review.
Edge cases usually involve integration postings, shared service centres, and vendor-managed SAP support. In those scenarios, accountability should not move to the vendor simply because the technical work is outsourced. Business ownership stays with the organisation, even if implementation is delegated. The same is true when changes affect both configuration and interface mappings, because one change can alter ledger postings, tax treatment, and reconciliation logic at once. NHIMG research on the Klue OAuth Supply Chain Breach is a useful reminder that third-party access can widen impact when control boundaries are unclear.
Where the answer becomes least stable is in global SAP environments with multiple finance owners and inconsistent transport governance. In those cases, accountability should be documented by system, by process, and by change type rather than assumed from team structure alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers privileged NHI control and rotation risks in SAP change paths. |
| OWASP Agentic AI Top 10 | Useful where automated SAP changes are driven by agents or scripts. | |
| CSA MAESTRO | Aligns with governance for autonomous or semi-automated finance workflows. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to safe SAP financial configuration changes. |
| NIST AI RMF | GOVERN | Governance ensures accountability for high-impact configuration decisions. |
Map SAP technical and integration accounts to NHI-03 and require approvals, review, and rotation.
Related resources from NHI Mgmt Group
- Who is accountable for keeping authorization approvals current when policy changes after a request is submitted?
- Who is accountable when privileged ERP access allows an inappropriate change to financial or supplier data?
- Who is accountable when a financial institution fails to meet cybersecurity requirements for access control and third-party oversight?
- Why do non-human identities create more audit risk than human accounts?
