Hi Stuart.
Yes, modifying a dictionary is an issue. Sarbanes-Oxley is primarily concerned with financial fraud. There are other regulations that are more focused on other things. In the case of SOX if you could modify report output by manipulating a dictionary there is the potential for financial fraud. In theory the auditors would spot check only reports or dictionaries that directly impact financial reporting. But you may as well implement a universal strategy. Changing the permissions on all the dictionaries might not be my choice because - you are on SB+, I think? There are things that get updated into the dictionary at runtime. My approach usually includes a combination of file permissions and triggers but primarily I lean toward controlling the tools. With remote vocs you can very tightly control the tools. Susan p.s. or, you could just buy PRC and voila! ;) Date: Thu, 24 May 2007 11:23:20 +1000 From: "Boydell, Stuart" <[EMAIL PROTECTED]> Subject: [U2] A question of dictionaries. We are implementing source control here and I was wondering, in light of data protection and source control best practice and the US list members experience of Sarbanes-Oxely, if anyone is currently running their production systems using OS level (D_filename) read-only dictionaries. I know that EVAL and SQL NEXT.ACCUMULATOR statements which write back to the dictionary will fail but have you encountered any other gotcha's? Or if you have contemplated the idea of locking dictionaries, but abandoned it, why? I'm also curious to find out (as Australia legislation has been influenced by it) what the implications as far as SOX is concerned where a user can potentially [if they gain access to a writable dictionary] change a reporting column, or doesn't it go that far? Cheers, Stuart Boydell ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
