Joiners and leavers get owned. Movers accumulate.

    By QuartzX Team••7 min read
    Relevant products
    QuartzIDIdentity & Access Governance and Privileged Access
    Segregation of DutiesAccess Governance
    Two segregation-of-duties conflicts flagged in a QuartzID access request: Capture Trades against Approve Trades, and Modify Trades against View Cashflows.

    Identity programmes are built around two events. Someone joins and gets what the role needs. Someone leaves and loses all of it. Both are visible, both have an owner, and both get audited.

    The third event has none of that. Someone moves — back office to middle office, middle office to a desk — and the organisation treats it as an addendum. New access is granted because the new job cannot be done without it. The old access is a question nobody is holding.

    Do that three times over a career and the result is not a role. It is a sediment.

    Three moves, nothing taken away Back officesettlement, reconciliationMiddle officerisk, P&L controlFront officetrading desk carried from a previous role granted for the new one a combination nobody approved
    Each move is approved on its own terms. Nobody ever approves the total, because nobody is looking at the total.

    Why a pair is worse than a permission

    Every entitlement in that stack passed a review at the moment it was granted. That is the part that makes this hard to argue about: there is no rogue approval to find, no policy that was breached, no control that failed. The risk is not in any one of them. It is in the fact that two of them now sit behind the same login.

    Each one is ordinary. Both together are not. Capture tradesenter a positionin the trading systemUnremarkable on its own Approve tradessign off a positionsomeone else enteredUnremarkable on its own Enter a position and approve it yourself.No second pair of eyes, and nothing to alert on.
    Segregation of duties is a property of the combination, which is why reviewing entitlements one at a time cannot find it.

    This is the shape of the Société Générale losses in 2008. Jérôme Kerviel had worked in the back office before moving to a trading desk, and what made the positions possible to conceal for as long as they were was not a single excessive permission — it was knowing, from the inside, how the controls he was now working around actually operated. The move was the event that mattered, and the move was the event nobody treated as one.

    Why it is hard to see

    The three facts you need to detect this live in three different places, owned by three different teams:

    • The entitlements live in each application, in that application's own vocabulary. "Capture Trades" in one system and the right to book a deal in another are the same capability under two names.
    • The move lives in HR, as a job change with an effective date. It reaches the applications as a request for something new, not as a notice that something old should end.
    • The rule — that these two capabilities should never be held by one person — usually lives in a policy document, a spreadsheet, or somebody's head.

    Nothing joins them. An access review shows a reviewer a list of entitlements for one person, and asks whether each is still needed. Each one, taken alone, still is. The reviewer approves the list, correctly, and the toxic pair inside it survives another cycle.

    What actually changes it

    Three things, and the order matters:

    • Treat a transfer as a departure and an arrival, not an amendment. The old role's access has to be explicitly re-justified or removed, in the same workflow that grants the new role's. An internal move is the only lifecycle event where "do nothing" is the default, and it is the one where doing nothing accumulates.
    • Write the conflict rules where they can be evaluated. Not as a policy PDF, but as rules over the actual entitlements, so the system can answer "does this grant create a conflict" at request time rather than at review time. In a trading environment that means rules that understand instruments, counterparties, portfolios and amount thresholds — "approve trades" is not one permission, it is a permission bounded by what and how much.
    • Detect the pair at the moment of request. A conflict caught while someone is asking for access costs a conversation. The same conflict caught in an annual review costs a remediation project, and caught by an incident costs considerably more.

    What this does not fix

    • Somebody still has to write the rules. A system can enforce a conflict matrix and can suggest pairs that look like conflicts. It cannot tell you that your firm considers these two functions incompatible — that is a judgement about your business, and it has to come from the people who run it.
    • A pair held by two people can still be a problem if they report to each other. Segregation of duties is about independence, not only about logins, and an org chart can defeat a clean entitlement model.
    • Clearing the backlog is a project. Detecting accumulated conflicts is fast. Deciding which side of each pair to remove, from people who are using both, is not.

    None of that is a reason to leave the sediment where it is. The question the board asks after an incident is never "was each grant approved". It is "could one person have done this", and that is a question about combinations.

    Security and compliance

    • SOC 2 Type IIAudited by Sensiba LLP.
    • ISO/IEC 27001Certified by Sensiba LLP, an ANAB-accredited certification body.
    • GDPRCompliant with the EU General Data Protection Regulation.
    • PIPEDAReady for Canada's Personal Information Protection and Electronic Documents Act.

    Reports available upon request