Vendor master data change and payment run release
The role that can change a supplier's bank details and release the payment run can send a payment anywhere with no second person involved. It is read across two lines of the matrix; one role on both sides of one line is read as self-approval instead.
The question for the matrix owner
Which role other than the one releasing the run approves a change to supplier bank details, and who calls the supplier back on a number already held?
The two halves
- Approving vendor master data change
- Approving payment run release, by the same role
Clauses
7 clauses| Regime | Clause |
|---|---|
| COSO | COSO P10 Principle 10: Selects and develops control activities · COSO P8 Principle 8: Assesses fraud risk |
| SOX | SOX FRAUD-1 Fraud Risk Assessment |
| ISO/IEC 27001 | ISO/IEC 27001 5.3 Segregation of duties |
| NIST SP 800-53 | NIST SP 800-53 AC-5 Separation of duties |
| COBIT | COBIT DSS06.03 Manage roles, responsibilities, access privileges and levels of authority · COBIT DSS06.02 Control the processing of information |
COSO P10 Principle 10: Selects and develops control activitiesThe organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. Points of focus: Integrates with risk assessment; Considers entity-specific factors; Determines relevant business processes; Evaluates a mix of control activity types; Considers at what level activities are applied; Addresses segregation of duties. Control activities are selected and developed integrated with the risk assessment, considering entity-specific factors (environment, complexity, nature, scope), the relevant business processes, a mix of control activity types (preventive and detective, manual and automated), the level at which activities are applied, and segregation of duties where practical, with alternative controls where not.
Where matrices usually fall short: Controls not traceable to assessed risks; Segregation conflicts unmitigated
Source: COSO Internal Control, Integrated Framework
COSO P8 Principle 8: Assesses fraud riskThe organization considers the potential for fraud in assessing risks to the achievement of objectives. Points of focus: Considers various types of fraud (applicable to ICFR); Assesses incentives and pressures; Assesses opportunities; Assesses attitudes and rationalizations. The assessment of risks to objectives considers the potential for fraud in its various types (fraudulent reporting, misappropriation of assets, corruption, management override), assesses the incentives and pressures, the opportunities from control weaknesses, and the attitudes and rationalizations that could lead individuals to commit fraud.
Where matrices usually fall short: Fraud risk considered only for misappropriation; Management override never assessed
Source: COSO Internal Control, Integrated Framework
SOX FRAUD-1 Fraud Risk AssessmentAnnual fraud risk assessment identifies schemes, considers incentives/pressures, opportunities, and rationalizations.
Where matrices usually fall short: Fraud risk assessment treated as a checkbox rather than a tailored exercise; Schemes not mapped to specific accounts, assertions, and processes; Anti-fraud programs not linked to identified scheme risks; Assessment not refreshed when business model or incentives change; Output not communicated to process owners or the Audit Committee
Source: SOX 404 and ICFR
ISO/IEC 27001 5.3 Segregation of dutiesSplit conflicting duties so no single person can run a sensitive process end to end unchecked.
Where matrices usually fall short: Combining conflicting roles in small teams; Lack of documented exceptions; Infrequent access rights reviews; Reliance on informal approvals
Source: ISO/IEC 27001:2022
NIST SP 800-53 AC-5 Separation of dutiesRequires the organization to identify and document the individual duties that must be kept apart to limit malevolent activity without collusion, and to define system access authorizations so that those duties cannot be exercised by one person.
Where matrices usually fall short: Conflicting duties named for finance processes only and never for system administration; Small teams create unavoidable conflicts that are tolerated rather than documented and compensated; Separation enforced at role definition but broken by direct entitlement grants
Source: NIST SP 800-53 Rev 5
COBIT DSS06.03 Manage roles, responsibilities, access privileges and levels of authorityBusiness roles, responsibilities, levels of authority and segregation of duties supporting the process objectives are managed, and access to all information assets related to business processes is authorised: roles and responsibilities follow approved job descriptions and process activities; levels of authority for approving transactions, transaction limits and other decisions follow approved job roles; sensitive activities are allocated so that duties are clearly segregated; access rights and privileges are the minimum needed for predefined job roles, removed or revised immediately on role change or termination; regular awareness and training cover roles, responsibilities, the importance of controls and the security, integrity, confidentiality and privacy of information; administrative privileges are secured, tracked and controlled to prevent misuse; and access control definitions, logs and exception reports are periodically reviewed so that privileges remain valid and aligned with current staff and roles.
Where matrices usually fall short: Transaction limits not enforced in the system; Access accumulated across role changes
Source: COBIT 2019
COBIT DSS06.02 Control the processing of informationThe execution of business process activities and related controls is operated on enterprise risk so that information processing is valid, complete, accurate, timely and secure, reflecting legitimate and authorised business use: the originator of transactions is authenticated and their authority verified; duties are segregated between origination and approval; transactions are verified as accurate, complete and valid through controls such as sequence, limit, range, validity, reasonableness, table look-ups, existence, key verification, check digit, completeness, duplicate and logical relationship checks and time edits, with validation rules and criteria reviewed periodically; erroneously input data are corrected and resubmitted without compromising original authorisation levels, retaining original source documents for reconstruction; data integrity and validity are maintained through the processing cycle with erroneous transactions not disrupting valid ones; output is handled in an authorised manner, delivered to the right recipient, protected in transmission and verified for accuracy and completeness; data integrity is maintained through unexpected interruptions and confirmed after failures; and transaction data passed between applications and functions inside or outside the enterprise are checked for proper addressing, authenticity of origin and integrity of content, with authentication and integrity protection in transit.
Where matrices usually fall short: One person able to originate and approve a payment; Interface files accepted without checking origin or integrity
Source: COBIT 2019