Talk:Sarbanes-Oxley Act: Difference between revisions
imported>Pat Palmer (more possible details for the "Technical considerations" article) |
imported>Howard C. Berkowitz No edit summary |
||
| Line 3: | Line 3: | ||
==Technical considerations== | ==Technical considerations== | ||
First, I appreciate this article. Good job so far! Although I don't have specific references at hand, here's a little more detail (through the grapevine) that we might be able to use to flesh out the "Technical considerations" section. While working as a consultant in various corporations, I was occasionally told, by managers and co-workers, that the specific consequences of S-O for us programmers folks is (1) to make databases log all changes to anything financial (and who did them, and when) in such a way that people cannot deceive auditors (and keep the logs practically forever), and (2) retain email backups over time (which is generally done anyway for simple operational integrity in case of disk crash) so that, long after an email has been "deleted" by a user, it may still be located by auditors in the backups. And basically, retain an audit trail of all the digital actions that might be wanted in future by auditors. There are probably other consequences as well. It might be useful to recruit a database person, and maybe a system administrator who had kept emails in a governmental office or other non-profit, or in a financial company, to comment more specifically about what the requirements are and how they can be satisfied. In today's world, the rather new field of computer forensics makes it more and more difficult for people to disquise their digital tracks, so there might be a tie-in with S-O and computer forensics as well.[[User:Pat Palmer|Pat Palmer]] 23:02, 12 March 2011 (UTC) | First, I appreciate this article. Good job so far! Although I don't have specific references at hand, here's a little more detail (through the grapevine) that we might be able to use to flesh out the "Technical considerations" section. While working as a consultant in various corporations, I was occasionally told, by managers and co-workers, that the specific consequences of S-O for us programmers folks is (1) to make databases log all changes to anything financial (and who did them, and when) in such a way that people cannot deceive auditors (and keep the logs practically forever), and (2) retain email backups over time (which is generally done anyway for simple operational integrity in case of disk crash) so that, long after an email has been "deleted" by a user, it may still be located by auditors in the backups. And basically, retain an audit trail of all the digital actions that might be wanted in future by auditors. There are probably other consequences as well. It might be useful to recruit a database person, and maybe a system administrator who had kept emails in a governmental office or other non-profit, or in a financial company, to comment more specifically about what the requirements are and how they can be satisfied. In today's world, the rather new field of computer forensics makes it more and more difficult for people to disquise their digital tracks, so there might be a tie-in with S-O and computer forensics as well.[[User:Pat Palmer|Pat Palmer]] 23:02, 12 March 2011 (UTC) | ||
:Good points. We might well have a separate article on email retention and disclosure, especially in a transnational situation where there is no one set of rules unless, for example, both countries are in the EU. | |||
:Coincidentally, I've been wondering if we might want to consider both code sample subpages and, for quite a few topics, compliance checklist subpages. "Code" could include router and firewall configuration, all with thorough disclaimers. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 00:33, 13 March 2011 (UTC) | |||
Latest revision as of 18:33, 12 March 2011
Technical considerations
First, I appreciate this article. Good job so far! Although I don't have specific references at hand, here's a little more detail (through the grapevine) that we might be able to use to flesh out the "Technical considerations" section. While working as a consultant in various corporations, I was occasionally told, by managers and co-workers, that the specific consequences of S-O for us programmers folks is (1) to make databases log all changes to anything financial (and who did them, and when) in such a way that people cannot deceive auditors (and keep the logs practically forever), and (2) retain email backups over time (which is generally done anyway for simple operational integrity in case of disk crash) so that, long after an email has been "deleted" by a user, it may still be located by auditors in the backups. And basically, retain an audit trail of all the digital actions that might be wanted in future by auditors. There are probably other consequences as well. It might be useful to recruit a database person, and maybe a system administrator who had kept emails in a governmental office or other non-profit, or in a financial company, to comment more specifically about what the requirements are and how they can be satisfied. In today's world, the rather new field of computer forensics makes it more and more difficult for people to disquise their digital tracks, so there might be a tie-in with S-O and computer forensics as well.Pat Palmer 23:02, 12 March 2011 (UTC)
- Good points. We might well have a separate article on email retention and disclosure, especially in a transnational situation where there is no one set of rules unless, for example, both countries are in the EU.
- Coincidentally, I've been wondering if we might want to consider both code sample subpages and, for quite a few topics, compliance checklist subpages. "Code" could include router and firewall configuration, all with thorough disclaimers. Howard C. Berkowitz 00:33, 13 March 2011 (UTC)