SOX implication for UserID changes... 2349



  • Greetings all, new to the forum, been doing compliance for the last few years… Banking and high tech hardware and software.
    Recently I came across a situation where the IS group (myself) is debating with the admins and audit folks about the implication to SOX of a user ID change due to marriage.
    The arguement lies in the disagreement whether there is a SOX requirement dealing with userID changes. The admins say that they will not do the work, or make the changes, since its a SOX violation, and the IS group (myself) contests that SOX is addressed by way of audit trails for changing a users credentials.
    Can someone give me input on this matter? Im feeling short of words in explaining how SOX req’s are not being violated when a user requests a name change due to marriage. Without this, we’re having problems with the admin folks not wanting to do the work required to change user ID’s.
    Hopefully Im being clear enough.
    thanks in advance
    Lucas



  • Internal controls over financial reporting, is what sox requires the management to attest on.
    Name change, in my view( and practically), will not affect the privileges( need not even affect the user ID…) that an individual has.
    Change to user privilege, that too unauthorized changes or changes not in line with the user’s job responsibilities, or that which would result in an SOD conflict are typical cases which may be considered significant for SOX.
    I would encourage u to challenge the admin’s team to prove how this would be significant from a SOX perspective… either they convince you or accept your request…
    Hope this helps
    Cheers



  • Hi and welcome to the forums 🙂
    I agree with NC’s comments above, as SOX 404 controls are a senior management responsibility. Comprehensive controls for automated IT systems must be established, based on significant material risks. These guidelines are written at a high-level and on a generic basis, as company technologies will vary widely.
    SOX 404 itself would not address ID renaming at a granular level . The organization itself must assess whether the risk of renaming accounts is a material IT risk.
    Having worked in IT security for over a decade, I’ve seen both approaches used for name changes, as noted below:

    1. Some IT security departments have refused to change an initally assigned ID when name changes occur, as it creates extra work to transfer privileges to the new ID. I have seen some upset customers as a result 😉
    2. Some IT security departments will rename accounts to keep them in sync with name changes, esp. if the account might be structured as first initial and last name. The first initial and last name format for the ID is a less secure naming convention, as it could give hackers a better starting point (than a less personalized ID format that is more difficult to guess).
    3. Some IT security areas will rename only EMAIL accounts but keep existing mainframe or server IDs intact, as a compromise.
      As long as good procedural processes are present, any of the 3 approaches shared above could meet SOX requirements. When renaming requires rebuilding accounts from the existing one as a model – it’s important to ensure the old one is devactivated and eventually deleted.


  • I can tell you what we did in a Fortune 100 company I recently worked with, but I can’t speak to any ‘formal’ legalities / regulations regarding this issue. When dealing with accounting-related systems and the Windows/network account, we did not allow a user’s ID to be modified after marriage. However, if requested, we would disable the former User ID and assign a new one from scratch. Yes, it created a headache in other ways, but this particular company was very strict about this policy. They wanted to make sure that nothing affecting a user’s identity was ever deleted or modified, to ensure appropriate tracking for auditing. Since this company works VERY closely with their auditors year-round, my guess is that it was a recommendation from the auditing firm, but I don’t know the legal reasons why.



  • However, if requested, we would disable the former User ID and assign a new one from scratch. Yes, it created a headache in other ways, but this particular company was very strict about this policy. They wanted to make sure that nothing affecting a user’s identity was ever deleted or modified, to ensure appropriate tracking for auditing. Since this company works VERY closely with their auditors year-round, my guess is that it was a recommendation from the auditing firm, but I don’t know the legal reasons why.
    Hi and welcome to the forums 🙂
    Yes, what is shared above is the best approach. It’s similar to what I’ve seen in the past (e.g., setup a new account, model all access rights after the old one, and then expire the old existing account). It is a better practice to leave the old ID in place so that any prior audit trails are not lost .
    P.S. In a former company, the ‘refusal to change’ process worked for only a short period of time. Then a ‘VIP’ either got married or divorced and the ground shook and then the rules changed 😉 😄


Log in to reply