In the municipal ERP, the same accounts-payable clerk can create a new vendor record and approve that vendor’s payment. Which design change best applies separation of duties?
Select an answer to reveal the explanation.
Short Explanation
One person who can invent a vendor and cut the check is writing checks to an imaginary cousin. Separation of duties splits those keys across two people so fraud needs collusion, not just one busy afternoon.
Full Explanation
In municipal ERP accounts payable, allowing the same clerk to create a vendor and approve that vendor’s payment concentrates incompatible duties: a single actor can invent a payee and authorize funds, enabling fraud without collusion. Separation of duties splits vendor master-data creation from payment approval into distinct roles held by different people, enforced by workflow so the system rejects self-approval paths and records dual control. Keeping both rights while only lengthening the password strengthens authentication, not authorization structure; stronger secrets do not replace incompatible-function splits. Combining create-vendor and approve-payment into a “super clerk” role maximizes efficiency at the direct expense of SoD and increases fraud risk. Moving both functions to an unpaid intern relocates the concentration of duties to a lower-oversight person rather than eliminating it. Exam caveat: CISSP tests SoD as preventing one person from completing a critical transaction end-to-end; password policy and staffing swaps are common distractors. Collusion risk remains, so monitoring and reconciliations still matter. Operational check: review ERP role matrices for create-vendor versus approve-payment, remove dual entitlement from individuals, enforce workflow separation, sample recent vendor creations against payment approvers for the same IDs, and alert on SoD conflicts in access reviews.