Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • We will use controls and control activities interchangeably throughout the presentation.
  • Overarching set of requirements that impact independent auditors and management. Accept responsibility = = “I, Name and position, am personally responsible for controls in my company ...” Support evaluation with sufficient evidence = “I, Name and position, certify that my company has evaluated the controls…” Support evaluation with sufficient evidence = “I, Name and position, certify that we have gathered sufficient testing evidence and documented our company controls…” Provide written assessment of control effectiveness = “I, Name and position, certify in writing that our company controls are effective…”
  • What IT controls are in scope – controls that are related to the company’s ability to initiate, authorize, record, process, and report financial data. Note that the dictionary terminology is different. Data input and output controls are usually encapsulated in the ‘operations security’ captions. This is an ‘audit act’ and we must use audit terminology. Data input and output controls are called ‘application controls.’
  • All these examples of changes impact IT
  • How general IT controls fit in the picture: In step 2, a result of the risk assessment will be obtaining a list of high-risk application systems on which critical transactions are processed. Critical transactions are defined as having an impact (accuracy or completeness) on financial data. For those applications, general IT controls will be evaluated.
  • Documentation is key to SOX. Must choose a framework to document controls.
  • COSO components; 1 through 6. 7 and 8 are new requirements uncovered by SOX 404.
  • Note that if you have 10 operating systems supporting application systems, 20 firewalls, 30 routers, 40 databases, 50 applications that are the SOX 404 project scope, you will probability need to develop 10+20+30+40+50=150 documents if the controls are not consistent across all systems. So, it would be probably wise to develop templates to ensure 100 people involved in documenting those 150 documents use a consistent approach. So, you would probably need some type of database or tool. We will discuss some tools later.
  • Note that from the total population of security controls, the organization should select only those that have a clear, direct relationship to financial statement accuracy and completeness. How? Through risk assessment and project scoping.
  • Note 1: Do not get carried away to document how passwords are stored by administrators. Do not write the great American novel, you do not have time to do that. Let the reviewing manager or the auditor ask for more information. Document what you have, not what you would like to have or should have. Note 2: Security administration control weaknesses, including password control weaknesses, will be deemed control deficiencies.
  • The degree of automation and type of control will enable the person(s) who do the testing of operational effectiveness to understand the control better before they test. This will save the sys admin’s time hopefully, because testers will go to the person who documented (sys admin) to ask for clarifications.
  • Do not have to have all of these - however, lack of policies and procedures are considered deficiencies. Note: the auditors will be asking 2 questions: 1) What kind of information is provided to employees to they are aware of their control responsibilities? 2) How is this information communicated, through what channels and are the channels sufficient (upstream, downstream) and do not entail reprisals?
  • Definition of monitoring - what processes are implemented by management to ensure control activities are performed consistently and continuously? Again, do not document monitoring controls if they are not related to the objective or activity.
  • This is just an example. Could also be rated simply as High, Medium, Low. Caveat: Use the same rating system for documenting security controls as everyone else in the organization. Consistency is key! Remember: no one is asking to make recommendations to bring the system to a risk-free level; or to make improvements for which the costs exceed the benefits.
  • Could be a 3-level rating system: Inadequate, Adequate, and Mature. Whatever the organization decides to use must be well defined, documented, agreed upon, and used consistently. Could be another rating system: 0 – unfavorable material impact on financial statements, 1 – significant deficiency, 2 – minor control gap, 3 – meets control guidance.
  • It is objective. We chose to assign an’ insufficient’ rating because the control activities required significant improvement due to lack of certain pw controls.
  • If you do not want to use spreadsheets or Word documents or MS Access, and from a continuity, effort level, and coordination standpoint, using such tools may be a bit overwhelming, look for a tool.

Sarbanes-Oxley Sarbanes-Oxley Presentation Transcript

  • Sarbanes-Oxley 404 Security Controls: A Hands-on Perspective SDISSA Conference – November 16, 2004 Presented by: Alex Branisteanu [email_address]
  • Introductions
    • Alex Branisteanu, CISA, CPA
    • Information Security Officer, Scripps Health
    • Disclaimer:
    • - The information presented in this presentation represents a personal perspective on Sarbanes-Oxley Act (SOX) controls. It does not represent the opinion of and has not received endorsement from the presenter’s/author’s present or past employers, Security and Exchange Commission, Public Accounting Oversight Board, or any other organization. The presenter/author makes no representation or warranties and provides no assurance that an organization’s disclosure controls and procedures and the internal controls and procedures for financial reporting are compliant with the certification requirement and internal control reporting requirements of SOX, nor that an organization's plans are sufficient to address and correct any shortcomings that would prohibit the organization from making the required certification or reporting under SOX.
    • - The presenter/author makes no claim that the use of the information in this presentation will assure a successful outcome. The presentation should not be considered inclusive of any appropriate procedures and tests or exclusive of other procedures and tests that are reasonably directed to obtaining the same results. In determining the appropriateness of any procedure or test, professionals should apply their own professional judgment to the specific control circumstances presented by a particular system within its particular control environment.
    • - Examples provided in the presentation are only for illustration purposes and are not related in any way to any particular system that the presenter has ever reviewed, worked on, or made aware of. Tool examples provided are not endorsed by the presenter or her past or present employers.
  • Points covered in today’s presentation
    • Brief overview of SOX 404.
    • Management’s assessment attestation of the internal control effectiveness over financial reporting for Controls (ICOFR).
    • Overall project approach – the ‘big picture.’
    • Hands-on approach on documenting and testing security controls.
    • Lessons learned and references.
  • Brief overview of SOX 404
    • The Sarbanes-Oxley Act (SOX) of 2002 was signed into law by US Congress in 07/2002.
    • SOX is a reaction to the financial fall and malfeasance of several publicly traded companies, e.g., Enron, WorldCom, etc.
    • Most substantive legislation pertaining to publicly traded companies since the ‘Securities Acts of 1933 and 1934.’
    • Applicable to all public companies and their board of directors, audit committees, independent auditors, legal departments.
  • Brief overview of SOX 404 (cont) Sections 302 and 404
    • Numerous law sections, of which two (2) stand out:
    • Section 302 – requires CFOs and CEOs to certify quarterly that they are responsible for disclosure of design and operational effectiveness of controls, e.g., acts of fraud, “material weaknesses.”
    • Section 404 with ‘real teeth’ – requires an annual evaluation of internal controls for financial reporting, e.g., all controls that provide assurance that financial statements are accurate.
    • Definition of control ( or control activity):
      • Safeguards or processes that mitigate a risk, OR
      • Processes effected by people designed to accomplish specified objectives (COSO), OR
      • Actions designed to ensure data, code, infrastructure, and other components maintain the CIA (confidentiality, integrity, availability) triad.
  • Brief overview of SOX 404 (cont) Oversight and Enforcement
    • Enforcement agency : Securities and Exchange Commission (SEC)
    • Bodies that interpret/establish rule-making processes & auditing standards :
      • SEC
      • PCAOB (Public Company Accounting and Oversight Board).
    • In 2004, SEC approved PCAOB’s Auditing Standard #2 – ‘An Audit of Internal Controls over Financial Reporting (ICOFR) Performed in Conjunction with an Audit of Financial Statements.’
    • Compliance deadlines started in 2003 and depend on several factors: size of the company, when the fiscal year of the company ends, etc.
    • Section 404 effective for fiscal years ending on or after November 15, 2003 for accelerated filers, or on or after July 15, 2005.
  • Management’s assessment attestation of the internal control effectiveness Auditing Standards
    • Auditing Standard #2 on ICOFR requires that management:
    • A) Accept responsibility of control effectiveness;
    • B) Evaluate control effectiveness;
    • C) Support evaluation with sufficient evidence ;
    • D) Provide written assessment of control effectiveness.
  • Management’s assessment attestation (cont) Covered IT Areas
    • What: Specific IT general controls – integral part of ICOFR controls, e.g.:
      • Change management control
      • Security (logical and physical)
      • Back-up and recovery
      • Job scheduling and operations, etc.
      • Note : Business continuity and disaster recovery are not in scope.
    • What: Specific IT application controls – integral part of ICOFR controls, e.g.:
      • Edits and validation
      • Disallowance of duplicate transactions
      • Processing error correction
      • Processing report accuracy
    • Why : Most financial processes are automated and supported by IT systems. IT systems support financial processing and reporting.
  • Management’s assessment attestation (cont) IT Application Controls
    • Application controls = controls that ensure transaction related processes are complete and accurate. Covers:
      • Initiation,
      • Authorization,
      • Recording,
      • Processing,
      • Reporting.
    • Example: Changes to customer credit’s master file are authorized and enforced through system (application) edits: field length, number formats, etc.
  • Management’s assessment attestation (cont) IT General Controls
    • General IT Controls = controls that are pervasive across systems and provide the control foundation for application programmed controls, system implementations and maintenance, access security, duty segregation, etc.
      • Note . Of all general IT controls, focus on those that affect ICOFR, transaction integrity, i.e., accuracy and completeness. This is why disaster recovery is not in scope.
    • Example: Logging of unsuccessful sign-on attempts to the UNIX operating system that supports the payroll system, e.g.,
      • Unsuccessful su attempts
      • Unsuccessful attempts to change /etc/profile permissions
      • Unsuccessful attempts to change permissions to other critical system files
  • Management’s assessment attestation (cont) Frequency
    • How often : Management must re-evaluate controls quarterly or whenever a change occurs that materially impacts ICOFR, e.g.,
      • Mergers and acquisitions
      • New system implementations (additions)
      • Customers’ needs change
      • Technologies change
      • Acts of God
  • Management’s assessment attestation (cont) Evaluating Control Design & Operations Effectiveness
    • A) Control design effectiveness = Is the control designed properly to mitigate the identified risk? Can the control be circumvented?
      • Highly subjective
      • Based on professional judgment.
      • Who evaluates control design effectiveness? Management.
      • Value: Proves that mgmt. has thought the process ‘through’ and applied professional judgment in making the evaluation.
    • B) Control operational effectiveness = Is the control operating as intended/designed? Is there a need for remedying/enhancing the control?
      • Objective - Must be tested!
      • Based on test results.
      • Who: Generally, who evaluates the design effectiveness should not test the operational effectiveness.
      • Value: Will identify remediation items above and beyond items already identified by mgmt. during design effectiveness evaluation.
  • Management’s assessment attestation (cont) Control Design & Operations Effectiveness Examples
    • Example: Daily review of access to sensitive tables in the payroll system.
    • Control design effectiveness
    • While evaluating the controls documented by DBAs, the DBA manager noted that the automated reports ran daily, but no one reviews them.
    • The DBA manager rates the monitoring control design as ‘ineffective (insufficient).’
    • The DBA manager recommends remediation: Going forward, 2 DBAs will review reports, summarize/research potential exceptions, and report true exceptions to the DBA manager for further escalation.
    • B) Control operational effectiveness
    • While testing the monitoring controls, the internal auditors found that the daily monitoring performed by the 2 DBAs was ineffective.
    • The 2 DBAs would summarize the potential exceptions, but fail to report true exceptions to the DBA manager.
    • Furthermore, reports showing potential exceptions when users access sensitive data tables, were in fact, run only monthly.
  • Overall project approach
    • Step 1 :
      • Scope and plan the project,
      • Commit resources,
      • Ensure executive mgmt. sponsorship,
      • Form ‘disclosure’ committee,
      • Assign project manager,
      • Allocate resources.
    • Step 2 :
      • Select an Internal Control framework. Note : SEC recommends COSO (Committee of Sponsoring Organizations of the Treadway Commission.
      • Understand, assess, and define process of transaction flow.
      • Start with financial statements, work through accounts, and identify supporting IT systems.
      • Conduct a risk assessment and define the project scope.
      • Educate organization on what needs to be done.
    • Step 3 : Establish an Internal Control Program.
    • Step 4 : Implement Internal Control Program
      • Identify and document controls.
      • Design effectiveness and operational effectiveness testing.
      • Remedy inadequate controls – risk rank, prioritize.
      • Implement sustainable monitoring.
      • Certify and assert (management and independent auditors)
  • Overall project approach (cont) Documentation: COSO and the Control Environment
      • Five (5) COSO framework components:
      • Control environment - People’s attributes, including integrity, ethical values and competence.
      • Risk assessment - Define Control Objectives. Identify, analyze, and manage risks as pertaining to business operations.
      • Control Activities – Control policies, procedures, and other processes established to address identified risks to ensure objectives are accomplished.
      • Information and Communication – Enable people to capture and exchange information needed to contact, manage, and control operations.
      • Monitoring – Ensure that processes are assessed regularly and modifications are made as necessary to ensure control quality.
  • Documenting and Testing Security Controls Documentation: Example for Security Controls
    • Identify the relevant security control objectives
    • Identify risk for each objective: What can go wrong?
    • Identify relevant control activities
    • Supporting Documents
    • Information and Communication (I&C)
    • Monitoring
    • Evaluation of design effectiveness
    • Testing of operations effectiveness
  • Documenting and Testing Security Controls Get Organized – Use a Software Tool, Templates, or DB
    • For example, we are documenting file FW_ Authentication Objective.
    • When was the document created: This file created in MS Access on mm/dd/yyyy.
    • Who documented the file : Joe Blow, System Engineer with Firewall Administration duties, reports to John Doe, Sr. System Engineer.
    • Background/process : The organization has 4 firewalls all of which are XXX version 12.5. There are 3 system engineers with firewall administration responsibilities, all of which report to the Sr. System Engineer. User authentication, which requires security servers, and client authentication are both used. 3 options are used for passwords: OS, Radius, and TACACS. For client authentication, IP addresses are not shared. This objective focuses on client-to-console and console-to-firewall authentication. The mgmt. console is authenticated to the fw via IP address and pw., etc, etc, etc,
  • Documenting and Testing Security Controls Step 1: Identify Relevant Logical Security Objectives
    • Examples:
    • Identification and authentication effectiveness = password controls, sessions suspension after a predefined number of unsuccessful logon attempts.
    • Account management or administration (AKA account provisioning and de-provisioning); manage account additions, deletions, and changes.
    • Access authorization = role-based access to ensure segregation of duties, ACLs.
    • Temporary and emergency access = emergency passwords, logging of emergency maintenance activities, notification/escalation to management
    • Logging and monitoring of security violations .
    • Protection of and changes to security configuration changes : centralized security administration, protection of sensitive security data.
    • Encryption of data stored and transmitted = If used, document how keys are protected.
    • Anti-virus and other anti-malicious code controls = includes controls over media, freeware use, utilities, files/directories, patch management, vendor maintenance contracts.
      • Note. Listing may not be complete! You may need to add other control objectives.
  • Documenting and Testing Security Controls Step 2: For each Control Objective, Document the Risk
    • For the Authentication Effectiveness control objective example:
    • Risk /What can go wrong : Inadequate authentication could result in making inappropriate system (FW) changes and lack of accountability.
  • Documenting and Testing Security Controls Step 3: For each Control Objective, Document Relevant Control Activities
    • Control Activities for the Authentication Effectiveness Objective:
    • 1) Initial passwords are issued in a secure manner.
      • Upon hire, the Sr. System Engineer communicates the passwords to the newly hired system administrator verbally, not via email or phone.
    • 2) Passwords are changed on first use.
      • The OS (Solaris) forces password change upon initial use. However, RADIUS, and TACACS servers do not. Remediation?
    • 3) Passwords have a sufficient length.
      • The OS (Solaris), RADIUS, and TACACS all enforce passwords 8- character minimal length.
    • 4) Password change frequency is appropriate.
      • Neither the OS, nor the authentication servers enforce password change at predefined intervals. However, by policy, firewall administrators are required to change admin. passwords every 3 months.
  • Documenting and Testing Security Controls Step 3: For each Control Objective, Document Relevant Control Activities (cont)
    • 5) Password complexity is appropriate.
    • The OS requires that passwords have at least 1 alpha character and 1 digit. However, RADIUS, and TACACS servers do not. No password cracking tools are used to check passwords against dictionary listings. Remediation?
    • 6) Password history is enforced.
    • Neither the OS, nor the authentication servers prevent prior password usage. Therefore, users may recycle the same password. There are no relevant policies. Remediation?
    • 7) The password is changed upon reset and users are authenticated before resets.
    • Only 4 users have fw admin capabilities and hence, the ability to reset pws. All users are restricted to particular source and destination IP addresses. For resets of admin pws authentication is not an issue, as it is done only by one of 4 people.
    • 8) Users are suspended after a number of unsuccessful logon attempts.
    • The OS (Solaris), RADIUS, and TACACS lock users after 3 unsuccessful logon attempts. Both successful and unsuccessful logon attempts are logged. ETC. ETC.
    • Note. It is OK to document compensating controls, see 5) above.
  • Documenting and Testing Security Controls Step 3: For each Control Objective, Document Relevant Control Activities (cont)
    • To facilitate testing of operational effectiveness and minimize time impact, consider documenting the following for each control activity:
      • Whether the control is automated or manual.
      • Whether the control is preventive, detective, or corrective.
      • Who performs the activity.
  • Documenting and Testing Security Controls Step 4: For each Control Objective, Document Supporting Documents (AKA Artifacts)
    • For the Authentication objective, describe supporting documents or artifacts, e.g.,
      • System setting screens (pw),
      • Tech manual – Solaris
      • Admin proc. manual
      • Reports,
      • Screen shots - e.g., User Object Properties screen, Workstation Properties, Properties Setup, User Authentication Action Properties).,
      • Flowcharts,
      • Narratives, etc. etc.
    • Who maintains that supporting document (or artifact).
  • Documenting and Testing Security Controls Step 5: For each Control Objective, Document Relevant Information and Communication (I&C) Activities
    • Information and Communication (I&C) for the Authentication Effectiveness control objective, e.g.:
    • Policies and procedures. Computer, network, and email appropriate usage policy, see intranet http://....
    • Job descriptions . The system engineer job descriptions include clear security responsibilities.
    • Performance evaluations .
    • Email communications from management . Quarterly, the Info Sec Officer emails reminders about password change requirements. Also, the Info Sec Officer publishes monthly reminders: pw best practices on posters, newsletters, etc.
    • Verbal communications and on-the-job supervision . During monthly staff meetings, the sr. system engineer reminds fw admins about pw requirements. Quarterly one-on-one discussions are held to improve pw controls.
    • Training . The 4 sys admins attend security conferences at least annually. Quarterly ‘Informational Lunch’ security sessions sponsored by the Info Sec Officer. Attendance sheets or minutes. Training manuals.
    • Compliance Hotline, Human Resources, Ethics and Compliance Committees, Internal Audit .
  • Documenting and Testing Security Controls Step 6: For each Control Objective, Document Relevant Monitoring
    • Monitoring for the Authentication control objective and related activities, e.g.:
    • Report review - Logging only is not sufficient. Logs must be reviewed (daily, weekly, monthly, etc.)
      • Viewing logs may be sufficient if follow-up on violations is documented in writing.
    • Metrics
    • Annual performance reviews if security control activities are part of IS staff’s job duties.
    • Enforcement of policies and procedures , e.g., violation escalation: notifications in writing/warnings, escalation to sr. mgmt., and other reprisals, up to and including employment termination.
      • In the fw example: Administrator actions through the GUI are logged in fw.log file, which logs all actions performed through the policy manager, including pw related changes. On the OS, changes are logged in the syslog. However, none of the logs is reviewed by the system engineers or sr. system engineer with leadership duties. Remediation?
  • Documenting and Testing Security Controls Step 7: For each Control Objective, Document Evaluation of Design Effectiveness
    • Control design effectiveness = The reviewer asks herself: Is the control designed properly to mitigate the identified risk and meet that objective? Can the control be circumvented? Are the controls likely to prevent or detect an error related to financial statement assertions?
    • Using a rating system based on communication with the project team, independent auditors, and management’s input. Example of Evaluation of Design Effectiveness ratings:
        • Unreliable
        • Insufficient
        • Reliable
        • Optimal / Mature
    • Upon reading and performing a walkthrough of the control objective and underlying control activities, supporting documentation, information & communication, and monitoring, the reviewer rates the controls as RELIABLE.
    • However, she noted that several controls were missing or existing controls were not properly designed. She makes remediation recommendations, e.g.,
      • There are no controls or relevant policies/procedures for password history. Password complexity not enforced by TACACS or RADIUS, etc. Remediation may be required to implement password history controls, pw complexity, etc. etc.
  • Documenting and Testing Security Controls Step 8: For each Control Objective, Document Testing of Operations Effectiveness
    • Control operations effectiveness = Upon documenting the control objective and evaluating the design effectiveness, management, the internal auditors, a 3 rd party (or combination) test controls.
    • Purpose of test: Prove that designed controls operate as intended. Test examples:
      • Inquiring of the system engineers on her team.
      • Reviewing fw settings on different screens, system manuals, running pw cracker tools, etc.
    • Upon performing several tests on the fw, the tester determines that in addition to the control improvements identified by the reviewer, in fact there were additional weaknesses and rates the operations effectiveness as INSUFFICIENT.
      • The passwords were communicated via email.
      • The policies and procedures have not been updated for 5 years and in general, & other documentation is minimal.
      • Passwords were, in fact, changed every 2-3 years and when a system engineer transferred to another department, the console pw was not changed.
      • New system engineers are not made aware of their pw control responsibilities.
    • The tester makes additional remediation recommendations for remediation.
  • Documenting and Testing Security Controls Steps 7 and 8: Example Ratings for Overall Control Effectiveness
      • Unreliable (0), Insufficient (1), Reliable (2), Optimal / Mature (3)
    • Unreliable (0):
      • No relevant policies and procedures are documented.
      • No information & communication, i.e., employees are not aware of their control responsibilities.
      • No monitoring, i.e., management has no process to evaluate controls (design and operational effectiveness) and/or is unable to identify control deficiencies.
      • Conclusion: There is insufficient documentation to support management’s assertion. Required effort to document, test, and remedy controls is significant.
    • Insufficient (1):
      • Controls and related policies/procedures exist, but not fully documented.
      • There is monitoring, violations are reported and escalated, but the process is not fully documented.
      • Some information and Communication: Some, but not all employees are aware of their control duties.
      • The operating effectiveness of controls is not evaluated on a regular basis and the documentation is insufficient.
      • The design effectiveness deficiencies are identified, but it takes a long time to remedy the weaknesses.
      • Conclusion: There is insufficient document to support management’s assertion. Required effort to document, test, and remedy controls is significant.
  • Documenting and Testing Security Controls Steps 7 and 8: Ratings for Overall Control Effectiveness (cont)
    • Reliable (2):
      • Controls are documented, supporting documents are adequate.
      • Information and Communication is effective. Employees are aware of their control duties.
      • Monitoring with the process of escalating and reporting violations is effective, regular, at least quarterly, and documented.
      • Design deficiencies are identified and remedied timely.
      • Conclusion: There is sufficient documentation to support management’s assertion. Required effort to document, test, and remedy controls may be significant.
    • Optimal / Mature (3):
      • An annual enterprise-wide risk management program is in place. The control program is continuous and well documented.
      • Information and Communication is effective and continuous. Employees are continuously made aware of their control duties.
      • Management’s monitoring is real-time, based on a periodic self-assessment process that documents the control design effectiveness and operational effectives is tested periodically.
      • Control gaps are identified through various technologies and remedied timely.
      • The effort to document, test, and remedy controls is moderate and efficient.
  • Deficiency and Material Weakness Definitions
    • Deficiency (design or operation):
      • Control is missing, or
      • Control objective is not met (design def.)
      • Control is not operating as designed (operations def.)
      • The individual performing the control is not qualified or not authorized to perform the control (operations def.)
    • Deficiencies – range from insignificant to material.
  • Significant Deficiency and Material Weaknesses
    • Significant deficiency = Single or combination of deficiencies that
    • A) results in > a remote likelihood that a misstatement of financial statements is > inconsequential , and
    • B) will not be prevented or detected.
    • Material weakness = single of combination of deficiencies that
    • A) results in > a remote likelihood that a material misstatement of financial statements is > inconsequential , and
    • B) will not be prevented or detected.
  • Examples of Internal Control Deficiencies
    • Lack of policies and procedures on enterprise information security, incl. personnel security education and training.
    • Lack of certain basis security controls, including:
      • Security administration, e.g., pw controls
      • Access control, incl. 3 rd party access and periodic review of user profiles, permissions, monitoring
      • User account administration and mgmt.
      • Excessive number of system admin accounts (superusers)
      • Physical security
      • Security incident response
      • Anti-virus controls
      • Back-up and restore
      • Segregation of duties between business owner duties and IT custodianship duties.
  • Summary of documentation Security Control Doc. Example
    • Control objective
    • Risk associated with not meeting the objective
    • Relevant control activities
    • Supporting Documents
    • Information and Communication (I&C)
    • Monitoring
    • Evaluation of design effectiveness
    • Testing of operations effectiveness
      • - Overall rating: Unreliable (0), Insufficient (1), Reliable (2), Optimal / Mature (3). In the previous example: INSUFFICIENT (1)
  • Lessons Learned
    • It is a crunch! Stay positive.
    • Not an optional project.
    • Audit act and project. Get subject-matter help, e.g., internal and external auditors. Learn the control language.
    • Listen to and work with the independent auditors. They will do their own testing and issue ‘auditor’s opinions’ on a) effectiveness of ICOFR and b) management's assessment.
    • Use a consistent approach across the organization, e.g., templates, database forms, or a software tool.
    • The documentation and testing process will need to be sustained over time. Tools will get better, people will get better at documenting, the control environment will get better.
    • Everyone should attend the same training to minimize the inconsistencies and miscommunication.
  • More Lessons Learned
    • 8. The scope of the project is a result of the initial risk assessment:
      • Define systems in scope.
      • Agree upon control objectives that need to be documented.
      • Strictly document what you have (not should or would like to have).
      • Once you identified deficiencies, risk-rate, prioritize, and start remediation ASAP.
    • Restrict access to the SOX documentation. Treat SOX security controls like you treat any other security documentation.
    • 10. Think about this is a continuous improvement program. It will not go away.
      • Like security, it is a journey, not a destination.
      • Unlike security, it has strict deadlines. Top-down sponsorship and communication are key!
      • Believe it or not, it has benefits – security professionals will have a ‘louder’ voice.
      • It will teach you things you never knew about the security environment.
      • Keep abreast of developments – listserv, conferences, seminars, peer communications.
  • References
    • - CoBIT (from ISACA)
    • - IT Governance Institute – “IT Control Objectives for Sarbanes-Oxley” white paper (hyperlink from ISACA website)
    • - listserv – isaca sox.
    • - Archived SOX webcasts (well-worth $ and time)
  • Software Enabling Tool Examples
    • Movaris, see
    • Tools provided by ‘the big 4’ accounting firms: KPMG, E&Y, PWC, and Deloitte.
    • Protiviti, see
    • Paisley, see
    • Microsoft, see
    • ETC. ETC. ETC.