Agile in a highly regulated organization 2014
- 1. Tami Flowers KCDC - May 15, 2014 AGILE IN A HIGHLY REGULATED ORGANIZATION
- 2. Titanium Sponsors Platinum Sponsors Gold Sponsors
- 3. I worked for a company with these words in it’s name: Federal Home Loan Bank That meant we had to consider Sarbanes Oxley Act (SOx) COBIT = internal auditors, external auditors, internal risk management group, examiners = 6-9 months a year of being audited or examined HIGHLY REGULATED ENVIRONMENT
- 4. Why did some of these regulations come about? What do COBIT and SOx say? Ok, so what does that mean? Where to start What to do on a project Tips and lessons learned Implementing new or changed regulations TODAY’S DISCUSSION
- 5. Our friends at wikipedia say: A regulation is a rule or law designed to control or govern conduct. Regulation creates, limits, constrains a right, creates or limits a duty, or allocates a responsibility. REGULATION
- 6. MOST INDUSTRIES AND BUSINESSES HAVE REGULATIONS
- 7. Before its bankruptcy on December 2, 2001, Enron employed approximately 20,000 staff and was one of the world's major electricity, natural gas, communications, and pulp and paper companies, with claimed revenues of nearly $101 billion during 2000. Fortune named Enron "America's Most Innovative Company" for six consecutive years. At the end of 2001, it was revealed that its reported financial condition was sustained substantially by an institutionalized, systematic, and creatively planned accounting fraud. The scandal also brought into question the accounting practices and activities of many corporations in the United States and was a factor in the creation of the Sarbanes–Oxley Act of 2002. Arthur Anderson was dissolved, shareholders lost, employees lost their jobs and retirements. ENRON
- 8. SOx Sarbanes-Oxley; Senator Paul Sarbanes and Rep Michael Oxley Aka “Public Company Accounting Reform and Investor Protection Act” Thank you Enron, Tyco, and WorldCom Contains 11 titles, or sections, ranging from additional corporate board responsibilities to criminal penalties, and requires the Securities and Exchange Commission(SEC) to implement rulings on requirements to comply with the law Controls, assessment of internal controls, disclosures in reports, audits, etc. Controls around anything that impacts what goes onto a financial statement WHAT IS SOX?
- 9. Business units Any business department that impacts financial statements Accounting Finance HR (executive compensation, etc.) IT IT general controls IT application controls TYPES OF CONTROLS
- 10. Our friends at wikipedia say: IT control objectives relate to the confidentiality, integrity, and availability of data and the overall management of the IT function of the business enterprise. IT controls are often described in two categories: IT general controls and IT application controls. IT CONTROLS
- 11. Framework for IT Governance and Control Policy development and good practices for IT control “COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, enables alignment and simplifies implementation of the enterprises' IT governance and control framework.” COBIT
- 12. In all, 12 IT control objectives, which align to the Public Company Accounting Oversight Board (PCAOB) Auditing Standard No. 2 and Control Objectives for Information and related Technology (COBIT ®), were defined for Sarbanes-Oxley. Figure 1 provides a high-level mapping of the IT control objectives for Sarbanes-Oxley described in the IT Control Objectives for Sarbanes Oxley , 2nd edition document, IT general controls identified by the PCAOB and the COBIT 4.0 processes.
- 13. From the April 2004 issuance of IT Control Objectives for Sarbanes-Oxley: “The work required to meet the requirements of the Sarbanes -Oxley Act should not be regarded as a compliance process, but rather as an opportunity to establish strong governance models designed to result in accountability and responsiveness to business requirements. Building a strong internal control program within IT can help to: Gain competitive advantage through more efficient and effective operations Enhance risk management competencies and prioritization of initiatives Enhance overall IT governance Enhance the understanding of IT among executives Optimize operations with an integrated approach to security, availability and processing integrity Enable better business decisions by providing higher-quality, more timely information Contribute to the compliance of other regulatory requirements, such as privacy Align project initiatives with business requirements Prevent loss of intellectual assets and the possibility of system breach” IT GOVERNANCE INSTITUTE
- 14. Some of the important areas of responsibility for IT include: Understanding the organization’s internal control program and its financial reporting process Mapping the IT environment (IT services and processes) that supports internal control and the financial reporting process to the financial statements Identifying risks related to these IT systems Designing and implementing controls designed to mitigate the identified risks and monitoring them for continued effectiveness Documenting and testing IT and systems-based controls Ensuring that IT controls are updated and changed as necessary to correspond with changes in internal control or financial reporting processes Monitoring IT controls for effective operation over time Participating in the Sarbanes-Oxley project management office THINGS TO CONSIDER FROM THE IT GOVERNANCE INSTITUTE
- 15. Controls, not the HOW or the process, is the focus. As long as your process can show the controls, that the controls are implemented and tested Then the process you use to build software is up to you and your organization. WHAT DOES THIS MEAN?
- 16. Feasibility Initiation Release Planning Iterate Close Out PROJECT LIFECYCLE
- 17. MAP CONTROLS TO PROJECT LIFECYCLE Feasibility Initiation/Planning Iterate Close Out COBIT Prioritization of Requests Project Approvals Testing & Documentation Approach Project Status Reporting Testing Documentation and Sponsor Approvals Security Review - least privileges in an application Security Testing Documentation Change Management Approvals Cycle 0 Testing Documentation Cycle 0 Security Testing Documentation Code Storage SOx Prioritization of Requests Testing & Documentation Approach Testing Documentation and Sponsor Approvals Security Review – least privileges in an application Security Testing Documentation Change Management Approvals Cycle 0 Testing Documentation Cycle 0 Security Testing Documentation Install Documentation
- 18. Use your SDLC to define your project process and deliverables. Ensure those deliverables are created for each project. Make sure they are stored where they can be easily found when requested by auditors and examiners. SAY WHAT YOU ARE GOING TO DO, AND DO IT
- 19. One size of Agile may not be right for all types of projects and teams. For large longer-term projects, daily standups, release plans, iteration planning meetings, retrospectives may be required with stories and tasks located on a project board. An infrastructure team charged with installing servers, routers, and firewalls and keeping it all up and running may have an overall plan and daily standups with tasks as sticky notes on a Kanban board. ONE SIZE MAY NOT FIT ALL
- 20. Consider adding different Service Levels, with increasing types of deliverables, based on project characteristics. For instance, a year long project with a larger project team should have far more controls and deliverables than a 1 week project with one developer. Don’t have an overwhelming number of deliverables so it takes longer to do paperwork or document than it does to do the project. Want to learn more? Stay for my next session! CONSIDER USING SERVICE LEVELS
- 21. Identify SOX controls up-front during the early stages of project planning. When creating test scripts, explicitly identify the SOX controls that need to be tested. After testing, explicitly document that those controls were tested. This doesn’t mean provide pages of documentation; identify what you are testing, test it, and document that you tested it. A test scenario can be documented with a simple “pass” or “fail”. DURING A PROJECT
- 22. Stay tool-agnostic. Don’t tie yourself to specific tools when documenting your processes. Keep development environments, bug tracking software, testing tools, etc. out of the documentation. KEEP IT SIMPLE!
- 23. It’s rare that you know exactly what the regulation states until right before it’s supposed to be implemented Use time once you know about the reg until you know exactly what it states to: Research what it means Talk with regulators to understand it’s impacts, if possible Identify applications that need changed/created to implement the regulation Work with the product owner(s) to identify highest risks and value, prioritize work that you can upfront Agile helps you be flexible to make adjustments once you get the final ruling, regulations, etc. IMPLEMENTING REGULATORY CHANGES
- 24. Your SDLC should guide your deliverables. Keep it updated and “fresh”. Consider updating it and training your team members annually. Focus on deliverables that prove the controls have been tested. Don’t overdo it on deliverables. Keep it as simple as possible. Work to educate auditors, examiners, etc. on what Agile means. When possible, include them early in the development of your process. Say what you are going to do…and do it! Then make sure it’s saved and easy to find when asked. LESSONS LEARNED
- 25. Twitter: TamiLFlowers LinkedIn: Tami Flowers Slideshare: www.slideshare.nettamiflowers Thanks! ME
Editor's Notes
- #13: Public Company Accounting Oversight Board