Technical Summary of the 404 2242
OHScott last edited by
I’ve been drafted into revamping the 404 Narrative and the Technical Summary associated with it. Last year was the first year (2006) my company filed and the narrative was a text nightmare put together by some well meaning internal auditors. Since then they’ve rubber-stamped the thing without updates to the original.
I’ve updated it pretty well and have included several process diagrams to help the document along but I’m struggling on the Technical Summary. I understand its purpose and how it should be associated with the narrative but the previous owners of the document listed only the applications associated with the critical processes and called it done.
From everything I’ve read, it should include applications and associated databases and servers and a rationale for the exclusion of applications that share common infrastructure. My internal auditors aren’t much help saying do what I think is necessary and they will be happy. So I need some advise.
Is a listing of the applications sufficient, or should it also include databases and servers? What about web-apps that serve as the front-end and any other application that is associated with the financials (EDI applications, credit card applications, etc.)?
Also… what data about these components should be included? I’ve not been able to find a (free) template or requirements anywhere.
harrywaldron last edited by
Hi and welcome to the forums
Do you have any contacts with your external auditors conducting SOX reviews as they may have examples or might approve what you’re sharing (as it sounds reasonable to me, although as an IT professional I don’t work directly on our SOX compliancy team). As the article found below states, you have a lot of flexibility as IT environments will vary greatly from company to company
I’m guessing the general SOX 404 narrative should be high-level and more business oriented, while the technical summary should be more detailed, specific, and IT oriented. In some quick research, I also found that you can point to existing detailed documentation so that hopefully you don’t have to ‘re-invent the wheel’
Good summary of SOX 404 (although an older article)
Please copy to browser as direct links are not permitted
The adequate documentation of significant controls is a prerequisite for their testing and evaluation. The most significant documentation issues facing companies include the form and content of the required documentation and the logistics of accumulating, maintaining, and reviewing the documentation.
Companies have a great deal of flexibility in choosing how internal control will be documented. Flowcharts, narrative descriptions, user manuals, and other documents all can provide a record of the company’s control policies and procedures . Adequate control documentation should include:
- A link between the control objective and the control policy or procedure
- A description of the control policy or procedure that achieves the control objective
- Information about how transactions are initiated, recorded, processed, and reported, and the flow of transactions to identify where errors could occur
- A description of how the control procedure is to be applied, who is responsible for performing the procedure, and how frequently the procedure is performed
OHScott last edited by
I went through the documentation but found that it also doesn’t address the particular requirements for the Technical Summary unless it is stating in general that you can use whatever as long as you can justify its use.
Much comes down to interpretation, but the understanding I have is that the Technical Summary is meant to identify those IT components that are significant to the financial operations of the organization that would be governed by the SOX legislation. Basically… it identifies the components in scope for the controls identified in the 4040 Narrative.
An example would be identification of the accounting application, its supporting database(s) and the servers that support these for generating your financial statements. These would be on the Technical Summary and then the Narrative would describe the controls regarding these components.
I do like the idea of approaching the external auditor. They may be willing to share an example or template of what they use/have seen.
Thanks again for providing feedback and best of luck to you.
I’d welcome any other opinions/thoughts on this topic as well.