I have to agree that standards are and have fallen over the course of the last 15 to 20 years. I believe that this is as a direct consequence of the introduction of PC’s on peoples desktops. The flexibility offered by these boxes to the individual was never available from the monolithic mainframes or medium sized minis, however this flexibility is now the norm. I have sure seen that happening. When the PC was first being used as real business tools, the PC department were real mavericks compared to us mainframe programmers. They used tools that were totally innapropriate, because that is what they were familiar with. Those were the days when we usually had to wait a couple of hours or maybe overnight to get just one execution of a program in the mainframe. Having access to production data was nearly impossible and therefore rarely necessary.

Good points SS … The Change request system is indeed important in the SDLC process. Most companies have more pending requests than people to work on them. Senior management participation is needed to help prioritize the most critical business projects among competing requests. It’s beneficial to have an IT senior management steering group to help in this decision process.

Thank you all for your insights! Pardon me for being late, but I am doing research on SOX compliance, and this conversation raises some very challenging issues. On one hand, SOX compliance is there to protect the shareholders, and having controls in place benefits the bottom line. On the other hand, does non-compliance automatically mean there is wrongdoing, or do prohibitive costs create a necessity for essentially ethical people to find an alternative? Are smaller reporting companies, start-ups, etc., subject to the same sophisticated controls as a company as large as Apple? What are the ramifications of non-compliance? Are there penalties involved, or merely the hold up of audit sign-off until in compliance? Is “going private” a means of avoiding the scrutiny and oversight placed upon public companies, or just a means of avoiding the costs? Our audit fees are already exorbitant, and just the thought of increased cost makes my head pound. Your feedback is greatly appreciated!

I am stuck in the middle of a debate at my company and trying to come up with a balanced solution. One group of folks at my company think that the use of Excel for anything at all constitutes SOX violation. The other group thinks it is actually quite difficult for spreadsheets to trigger violation unless they are specifically for financial reporting. I think you’re right on track, as some education and negotiations are required. Certainly SOX standards don’t require you to rewrite everything into database applications and they specifically support the use of spreadsheets with best practices (as noted in prior posts). Going too far with SOX standards can drive up costs and create resistance when you truly need to address real issues With your recent work in version control, security controls, autonomy levels, and standardizing the process , place your company in a good position to meet SOX spreadsheet requirements. Any financial risk management aspects of this still might need to discussed and possibly resolved if it’s needed. Otherwise your current position looks good to me

Hello Friend, Please mail me the template at mohit.gupta_at_nucleussoftware.com.sg

The time it takes to crack a password depends on many factors: is a human manually typing in the passwords or is a program automatically doing it are the passwords typed into the application input window that the password protects or do you have access to the encrypted file that stores the users’ passwords and know the encryption or hash algorythm the automatically enforced password rules for minimum length and required diversity of passwords (lower case, upper case, numbers, special characters the fact that users tend to use passwords that they can easily remember so that cracking programs can use dictionaries and reduce the number of combinations that are actually used in practice. after how many unsuccessful password attempts in a given time period a user account is blocked for further attempts If a cracking program needs to simulate keystrokes being typed in an application and if the system limits the speed of processing such keystrokes (which can be much slower than the raw processing power of the CPU) then your cracking time will increase. Point number five is actually the most important one if the cracker does not have access to the enrypted password file. If the number of login attempts until blocking is three and if the investigative process to unblock user accounts involves contacting the user and verifying that it was him that made the unsuccessful attempts, then cracking has almost no chance unless passwords are extremely weak.

I agree with Calvin … Business Continuity and DR Plans are absolutely essential and they might even need to be shared with SOX external auditors. However, SOX audits aren’t supposed to test every IT control out there, as BC/DR plans should be more thoroughly assessed in general IT control type audits. SOX 404 focuses on management’s controls of automated financial systems and as Milan notes BC/DR plans would be outside the scope of controls testing, (even though they might still need to be covered with the SOX auditors verbally and/or documentation shared)

We were advised on Thursday or Friday that we should use Track Changes on our major Excel financial spreadsheets. I’d recommend instead looking at ‘Change Management’ or ‘Change Control’ versioning products that you could use on your server. For example, you’d checkout Workbook v1.0 of the spreadsheet, modify it, and check it back in as Workbook v2.0 (perhaps with an approver). I’m personally using this versioning controls for serval non-SOX compliant spreadsheets I publish. It provides backups, an audit trail and history of changes, and a great way of ensuring everyone is using the correct version of the document. In my own case, I’m not using Change Management software as it’s not required. Versioning using Change Management software is probably a more preferrable way of handling spreadsheet changes – just like you would program source code.

So, you are testing 30 JE’s per year. THat is reasonable. I would suggest that you focus in on testing of those JEs that could ahve a material impact on your FS if in error. We are only including in our poplulation to sample from those JEs greater than USD500M. We are still testing 30-35 JE’s, but from a smaller population, more focused on where the true risk exists. Actually, only 10 JEs per year (excluding rollforward testing which is a small sample size anyway): 2 months x 5JEs. I am glad to see how the SOX approach has changed to care about materiality, like in a F/S audit. I remember when SOX first rolled out (that was my last year in public and then I did not touch SOX until now), we selected samples regardless of materiality of the transaction because we wanted to focus on the fact that a control is done.

Just a few comments in response.%0AI agree there is a degree of inconsistency between partners and firms. I even noted it within a firm on the same account that had locations around the world.%0AAs I said before, taking our auditors perspective, given what they are testing I think most of their demands are reasonable. In fact our working relationship is very constructive. %0AGoing back to the start of this dialogue I was complaining about the unecessary level of work needed to comply with SOX. If I look at income I have millions of low value receipts. Looking at our various life products we find that many schemes are FRAG’d, audited or similar on a regular basis. We also report regularly to external monitoring bodies who also access our data and audit us. Together these would give me very strong comfort that we are not mistating our income (particularly with out bank reconciliations in tow). %0ABut income is a line entry on our P-and-L, we cannot rely on 3rd parties for evidence, therefore we must show that at least 70% of our line item cannot be wrong which means going into the business and transalting the controls into financial reporting ones and then undertake testing. This has to be done through a combination of self certification, internal testing and external audit, and because we have so many products and systems this becomes a significant pice of work.%0AI appreciate that this is unusual and most businesses are not in the same position as us. But this is why I contend that 1) SOX has had a significant negative impact both in cost and time and 2) the risk that SOX should be addressing is how management manipulate the data rather than the accuracy of the data itself.%0AWe do have a permanent SOX team of around 6 staff at present. This has reduced the risk that operations have bought into SOX and over time we should see a positive move, it has lead to a better use of resources by minimising audit fees and als because of the major restructuring that is impacting the Financial Services business in Europe with highly publicised redundancies and relocation of work to India etc we need to make sure we stay on top of that.%0AInterestingly our Internal Audit have refused to get involved with SOX claiming it impacts their ‘independence’. This is a senior management decision so I have had to improvise.%0AChaava - Basel will impact because we do have a banking business but it is only one aspect of our company. I think I will put it on hold until 2007 - I can only hold so many hoses at any given time.

I agree with you. CISA is not enough. Experience is of paramount importance. A young man, hired by a supermarket, reported for his first day of work. The manager greeted him with a warm handshake and a smile, gave him a broom and said, ’ your first job will be to sweep out the store .’ ’ But I’m a college graduate ,’ the young man replied indignantly. ’ Oh, I’m sorry. I didn’t know that ,’ said the manager. ’ Here, give me the broom, I’ll show you how .’

If I have tested and certified 404 (have the tested controls in place) then why do I have to keep testing them Because management has to make an assertion annually and you have to ensure you that your controls HAVE worked during the year - you can’t just assume that they SHOULD work based on monitoring. Broadly speaking what is required for quarterly monitoring for 302 purposes will not be sufficent to support your 404 assertion - but this partly depends on how you set up your steady state.

Another project I would recommend is a matrix of administrative authority (basically who does what and what is the limit of their limit of control (e.g. spending limits)).

Brilliant. I’m writing a thesis on whistleblowers protection in holland and as I am looking for information on the subject of SOx and the european data-protection directive I find this forum. Thanks for the information. Am I right to have understood that the problem is, kind of, solved? The American Court of Appeals has ruled tha SOx rules do not apply to foreign whistleblowers working outside the US. across the ocean the ‘group article 29 (EU 95/46)’ has advised in the matter and concluded that (national) legal obligations may breach the data-protection directive. If the obligation for a whistleblowers procedure comes from overseas, it may still be allowed, as long as it is proportionally right. Is this the end of it? Diederik Diercks Amsterdam

Can anyone recommend a sarbanes expert or company to conduct an on-site training for 10-15 individuals at at my company? It should be a 2-day training in our boardroom built around the different aspects of Sarbanes-Oxley Act of 2002. Thank you. Hi, Please feel free to contact me at 9198403 38133 for arranging an in-house training on SOx. We have done a couple of in-house and have had participants from more than 140 corporates for our public workshops. Rgards, Parthiban

As Mr. Guest Said: Information Processing Objectives area related to controls (COSO, chapter 4 not a PwC creation), and Financial Statement Assertions are related to financial statement lines (accounts). A well done COSO implementation should use CAVR. When you map your process and identify a control, it is easer to link to CAVR, and then link to FS assertions. I use to document both on my RCM. The correct relation between CAVR and FS Assertions are: Completeness - Completeness, Cut-off, Existence/Occurrence, Rights and Obligations Accuracy - Accuracy, Classification, Valuation and Allocation Validity - Existence/Occurrence, Cut-off, Rights and Obligations Restricted Access - Most, except for Rights and Obligations

A small addition to the extensive discussion above is that of internal quality assurance review. Simply put, once the soxer has done there part through documeting risks, control activities, relationship to f/s and COSO assertions, doing a walkthrough and assessing adequacy of design; a knowledge/preferably senior person needs to review the resultant work. In a sense, this is testing the work done on design. Likewise, a more senior person would (I assume) review the work done while testing effectiveness. To extend the thought, the QA review is the monitoring control and the external auditor testing is the independent assurance. It might be semantics, but quality control is crucial to establishing and maintaining credibility both internally within a client; and externally with the auditor. It also helps keep everyone on the same page, methodology wise, including production of clean consisent output that’s easily reviewed.

The Proposal for a Directive on Statutory Audit and Annual Accounts is in many aspects a reply to the Sarbanex Oxley Act, as for example, the requirement of registration, which was probably introduced due to the effects of the extraterritoriality of Sarbanes Oxley. It was quite obvious that, after Sarbanex Oxley, the Commission was going to issue a (more or less) similar piece of legislation, although there are some significant differences (as for example, the principles approach - I have already read the discussion in the other Forum about Rules vs. Principles and I still think that the approach is quite different in both regulations.). However, the draft is not the last one, it is still subject to amendments by the European Parliament and to the rest of the codecision procedure. Thus, the text may still change a lot… Regards, Tulipe

Sample sizes guidelines from IIA and external Audit have been: Nature of Control Frequency of Occurrence Min # of Items to Test Manual Many times per day (> 5,000 transactions/mo) 60 Manual Many times per day 40 Manual Daily (365 per year) 20 Manual Weekly (52 per year) 10 Manual Monthly (12 per year) 3 Manual Quarterly (4 per year) 2 Manual Annually (Once per year) 1 Programmed Test one application of each programmed control activity if supported by effective IT general controls Otherwise test similarly to a manual control (e.g., 60) IT General Controls Follow the guidance above for manual and programmed aspects of IT general controls

Found a couple of things that tie this together better than I did: Excerpts from the SEC Final Rule ‘We believe that each company should be afforded the flexibility to design its system of internal control over financial reporting to fit its particular circumstances.’ In this same final rule, the SEC says: ‘The methods of conducting evaluations of internal control over financial reporting will, and should, vary from company to company. Therefore, the final rules do not specify the method or procedures to be performed in an evaluation.’ They go on to discuss the COSO framework: ‘…we have modified the final requirements to specify that management must base its evaluation of the effectiveness of the company’s internal control over financial reporting on a suitable, recognized control framework that is established by a body or group that has followed due-process procedures, including the broad distribution of the framework for public comment. The COSO Framework satisfies our criteria and may be used as an evaluation framework for purposes of management’s annual internal control evaluation and disclosure requirements. However, the final rules do not mandate use of a particular framework, such as the COSO Framework, in recognition of the fact that other evaluation standards exist outside of the United States, and that frameworks other than COSO may be developed within the United States in the future, that satisfy the intent of the statute without diminishing the benefits to investors.’ http://www.sox-online.com/coso_cobit_sec_on_frameworks.html In most companies of any size, data moves between multiple business groups and IT systems on its way from initial transactions to the reports that the CEO and CFO must attest to. Attesting to the accuracy of the data requires confidence in accounting procedures and controls. These are addressed within the COSO framework. The SOX 404 attestation also requires confidence in the IT systems that house, move, and transfom data. This requires confidence in the processes and controls for those IT systems and databases. The COBiT framework was designed to address IT concerns. Finally, an excerpt from IT Control Objectives for Sarbanes Oxley this is the document that maps Cobit objectives to COSO ‘The PCAOB standard includes specific requirements for auditors to understand the flow of transactions, including how transactions are initiated, authorized, recorded, processed and reported. Such transactions’ flows commonly involve the use of application systems for automating processes and supporting high volume and complex transaction processing. The reliability of these application systems is in turn reliant upon various IT support systems, including networks, databases, operating systems and more. Collectively, they define the IT systems that are involved in the financial reporting process and, as a result, should be considered in the design and evaluation of internal control. The PCAOB suggests that these IT controls have a pervasive effect on the achievement of many control objectives. They also provide guidance on the controls that should be considered in evaluating an organization’s internal control, including program development, program changes, computer operations, and access to programs and data. While general in nature, these PCAOB principles provide direction on where SEC registrants likely should focus their efforts to determine whether specific IT controls over transactions are properly designed and operating effectively. This document discusses the IT control objectives that might be considered for assessing internal controls, as required by the Act. The appendices of this document provide control examples that link PCAOB principles, including their relationship to internal control over financial reporting. To support implementation and assessment activities, illustrative control activities and tests of controls are provided in the appendices.’