Chapter 16. Audit and Regulatory Compliance
Audit and regulatory compliance require that you establish IT controls to guide the way in which the team works. Your auditors may be internal employees or external consultants engaged by your firm. The internal audit team usually focuses on internal policy, whereas external auditors are often engaged to ensure compliance with federal regulatory guidelines. Whereas many technology professionals look at audit and regulatory compliance as just something that you have to do, others view it as an obligatory yet unfortunate waste of time and effort. Our focus is on establishing effective IT controls that help avoid both defects and risk. This chapter will help you understand how to use audit and regulatory compliance to ensure that you prevent the sorts of major systems glitches and outages that we read about all too often.
16.1 Goals of Audit and Regulatory Compliance
The goals of audit and regulatory compliance are to identify and then mitigate risks. As we have said before, risk is not always bad, especially when it is clearly identified and a plan for mitigating the risk established. But audit violations and failure to comply with regulatory standards are always bad. We have seen organizations that had serious violations with regulatory authorities actually issuing one or more warning letters outlining the violations and criteria for corrective action. If corrective actions are not forthcoming, the warning letter(s) could potentially be followed by a “cease and desist” letter, which could effectively force the company to leave a particular business area as a consequence of the noncompliance or, even worse, as a consequence of a serious incident. The goal of audit and regulatory compliance is to ensure that you do not run afoul of the rules that your company is required to follow. You should have a goal of using this guidance to improve your productivity and quality.
16.2 Why Are Audit and Regulatory Compliance Important?
Audit and regulatory compliance are essential to the success of your organization. Without meeting these criteria, your company could literally be forced out of areas that are the bread and butter of your business, fined, or sanctioned in other ways. News of violations can also tarnish your corporate reputation and result in your customers choosing the services of your competitors instead of you. We often hear managers disparage audit and compliance as a waste of time. Our view is these resources can be enlisted and directed to focus on valid risks, helping the firm address challenges and avoid costly incidents.
Security is also a key concern. Understanding and successfully implementing industry guidelines help avoid incidents, including those related to security.
We strongly believe that audit and regulatory compliance should really be focused on avoiding errors and reducing operational risk, as well as keeping you out of the news as the latest major incident. The controls that you establish will help your team to achieve excellence and your company to be successful.
16.3 Where Do I Start?
The first step is to understand the industry that you are in and your audit and regulatory compliance requirements. You start by adhering to the rules that you are compelled to follow, but next you need to understand your firm’s unique risk profile.
What are the things that could potentially go wrong with your systems? Could you accidently make a million-dollar trade, resulting in significant losses for your firm and your shareholders or expose confidential employee information? Could you accidently expose confidential patient information in violation of Health Insurance Portability and Accountability Act (HIPAA) regulations? Obviously, the risk of causing a problem in a life support system is more critical than exposing your favorite social networking password. But these days, there are many risks and consequences. You need to start by considering your organization’s profiles and priorities. Then focus on making your journey to implement IT controls and compliance an effort that focuses on improving quality and productivity.
You also need to consider the cost of compliance. Establishing IT controls takes time and resources. Of course, the cost of noncompliance could potentially be more—indeed much more. Our message is to move beyond just going through the motions and actually focus on assessing and improving your operational processes.
16.4 Compliance with What?
Establishing controls to meet audit and regulatory requirements really requires that you understand the guidance you are trying to follow. Your internal audit team likely has their own policies and will also review and follow the guidelines of other groups, such as information security in the organization. We will discuss compliance with laws such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and Section 404 of the Sarbanes-Oxley Act of 2002. These practices are typically guided by industry frameworks and standards. Common frameworks include ISACA Cobit 4.1, itSMF ITIL v3, and the Software Engineering Institute’s Capability Maturity Model Integrated (CMMI). Standards are typically based upon the consensus of working groups from the International Organization for Standardization (ISO) or the Institute of Electrical and Electronics Engineers (IEEE), among other standards organizations.
Companies may choose to comply with ISO 9001, which establishes a quality management system (QMS). Many firms focus on security-related guidelines such as National Institute of Standards and Technology (NIST) or ISO 27001.
Whatever your specific industry focus, you need to determine which standards and frameworks make the most sense for your company to use as a guideline for establishing your own IT controls.
16.5 Establishing IT Controls
IT controls are the guidelines that help you meet audit and regulatory compliance. IT controls are essential for a number of reasons. The most obvious is that many organizations have to comply with federal laws. We believe that good corporate citizenship should be an even more compelling reason to make sure you are in compliance. The rules that we will discuss just make sense, and organizations should comply regardless of whether or not their lawyers have found some way to avoid it. One serious area of concern is that many hedge funds do not have to comply with establishing IT controls and compliance. Sometimes this results in organizations where production passwords are openly shared and there is no separation of duties. We view this as a huge mistake and feel strongly that all compliance laws should apply equally to all financial services firms, not just banks. There is also a need for these types of controls for firms in other industries, such as pharmaceutical, medical, and military contractors, which, by and large, take these practices very seriously. Implementing these controls just makes sense, and their successful implementation is essential for any organization.
16.6 Internal Audit
The internal audit team is usually completely outgunned, and sometimes regarded by developers and other stakeholders as just a waste of time and energy. Our experience is that they are actually a source of untapped talent who, with some training, can fill a valuable role as the “beat cop” on the street. Too often the internal audit team is intentionally kept in the dark, relegated to writing up a few issues here and there. We have provided training to internal auditors so that they actually know what to look for and then sent them out to visit each development team. The key to success was to focus only on valid and useful IT controls that everyone agreed were the most essential best practices.
There was another positive effect from working proactively with the internal IT audit team, and that was receiving their support with senior management. We had accomplished two very important things with this effort. The first was that we trained and utilized the internal IT audit team to help us spread best practices throughout the firm. The second was unintended, but more important. With the training, the internal audit group no longer was writing up irrelevant stuff that wasted everyone’s time. The message here is that the DevOps approach should be utilized to facilitate communication and collaboration between the internal IT audit team and the other stakeholders who can help identify and reduce risk. Although the internal IT auditors are really part of the team and should be included in your DevOps implementation across the ALM, external audits can be a little more unpredictable.
16.7 External Audit
External auditors usually come in with a predetermined focus. Although many managers insist that you should never volunteer any information at all to an auditor, our approach is to accurately describe the IT controls that we have in place. Because we know that these best practices are aligned with federal regulatory requirements, along with industry standards and frameworks, we have always been confident interfacing with the external auditors.
One of the most important considerations from an audit perspective is ensuring compliance with federally mandated guidelines.
16.8 Federally Mandated Guidelines
There are many federally mandated guidelines, but we will start with those commonly known as SOX.
16.8.1 Section 404 of the Sarbanes-Oxley Act of 2002
The Sarbanes-Oxley Act of 2002 (SOX) was originally written by Senator Paul Sarbanes and Representative Michael Oxley as a response to several high-profile corporate scandals, including the much-publicized debacle at Enron Corporation. In this incident, there was a complete breakdown in corporate governance leading to huge losses for shareholders, many of whom were employed by the company. The purpose of the SOX legislation was to hold senior management responsible for seeing that financial reports were accurate and that there was full financial disclosure and transparency in corporate governance. In short, SOX requires that companies have accurate financial reports and that they establish proper IT controls. Section 404 of the Sarbanes-Oxley act specifies the requirements for management assessment of internal controls.
Section 404 requires that “[w]ith respect to the internal control assessment required by subsection (a), each registered public accounting firm that prepares or issues the audit report for the issuer shall attest to, and report on, the assessment made by the management of the issuer.” In practice, this meant that the public accounting firm established a tool for the organization’s subject matter experts (SMEs) to attest to compliance with each of the 34 required Cobit 4.1 controls. This was supposed to involve assessing current practices and then attesting to compliance. Where noncompliance existed, we proactively worked with the development teams to improve their configuration management (CM) practices so that they could pass their next audit. Even if the teams failed the first time, the important issue was that we had a short-term plan to help them quickly come into compliance. In most cases, this took less than a month. Unfortunately, we have also seen organizations where this effort was little more than a rubber stamp. In fact, we recall one incident where a senior manager in charge of compliance expected that the attestation would happen before the groups were reviewed and assessed! This organization obviously did not take SOX compliance seriously, and that was truly a lost opportunity, as these best practices can improve both productivity and quality.
Management Assessment of Internal Controls
As specified in the text of the act, Section 404 requires internal controls and accurate reporting:
(a) RULES REQUIRED.—The Commission shall prescribe rules requiring each annual report required by section 13(a) or 15(d) of the Securities Exchange Act of 1934 (15 U.S.C. 78m or 78o(d)) to contain an internal control report, which shall—
(1) state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and
(2) contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.
(b) INTERNAL CONTROL EVALUATION AND REPORTING.—With respect to the internal control assessment required by subsection (a), each registered public accounting firm that prepares or issues the audit report for the issuer shall attest to, and report on, the assessment made by the management of the issuer. An attestation made under this subsection shall be made in accordance with standards for attestation engagements issued or adopted by the Board. Any such attestation shall not be the subject of a separate engagement.
After the Sarbanes-Oxley act was passed, a number of organizations began working on establishing an effective control framework so that corporations would have adequate guidance and could comply with the requirements set forth under law. One of the first organizations to work on this effort is known as COSO.
Committee of Sponsoring Organizations (COSO)
The Committee of Sponsoring Organizations of the Treadway Commission (COSO) is a voluntary private-sector organization composed of five sponsoring professional associations. COSO is dedicated to guiding executive management and governance entities toward the establishment of more effective, efficient, and ethical business operations on a global basis. It sponsors and disseminates frameworks and guidance based on in-depth research, analysis, and best practices. In 1992, the Committee of Sponsoring Organizations outlined five essential components of any internal control system:
• Control environment
• Assessment of risk
• Control activities
• Accounting, information, and communication systems
• Self-assessment or monitoring
Cobit as a Framework for IT Controls
Although COSO is generally considered a proper starting point for establishing financial controls, Cobit is commonly used to assess IT controls. In the Cobit 4.1 framework, there are 34 high-level IT processes and 34 control objectives. These control objectives include guidance on establishing change and configuration management.
Cobit is a common framework, but it is not the only source of information on IT governance.
16.8.2 Financial Industry Regulatory Authority
Financial Industry Regulatory Authority, Inc. (FINRA) is a self-regulatory organization (SRO). Overseen by the Securities and Exchange Commission, FINRA provides a variety of services focused on regulatory oversight of securities firms. FINRA was formed by a consolidation of the member regulation, enforcement, and arbitration operations of the New York Stock Exchange, NYSE Regulation, Inc., and National Association of Securities Dealers (NASD). We have seen guidance from FINRA help public securities firms, including banks, benefit from FINRA’s well-defined cybersecurity governance structures and policies, along with training and awareness of potential risk vulnerabilities, including
• Data security standards
• Vendor management
• Incident response planning
• Independent cybersecurity penetration testing
• Cybersecurity planning and intelligence
• Safeguarding of personally identifiable information (PII)
From our experience, one of the most valuable services provided by FINRA is the self-administered risk assessment surveys, which help identify potential risks that need to be understood and mitigated. Although FINRA focuses on financial services firms, some of its guidance is of value to other industries as well. Many pharmaceutical and medical firms need to comply with HIPAA regulations, including safeguarding personally identifiable information, from Social Security numbers to confidential medical records.
16.8.3 Health Insurance Portability and Accountability Act of 1996
The HIPAA Privacy Rule protects the privacy of individually identifiable health information. The Patient Safety Rule also has confidentiality provisions, which protect identifiable information from being used to analyze patient safety events and improve patient safety. I have had technology professionals from pharmaceutical companies contact me to implement IT controls that were similar to those required by SOX and Cobit. In both cases, the organization has to comply with regulations that are described in a specific framework. I have been told that pharmaceutical companies may have their IT controls subject to review by agencies such as the Food and Drug Administration (FDA).
16.8.4 ISACA Cobit
ISACA Cobit is a framework commonly used to achieve compliance with Section 404 of the Sarbanes-Oxley act of 2002, which we discussed in Section 16.8. Our experience with the Cobit framework has been mostly focused on the 4.1 version, which consists of 34 high-level processes. We have found that the control objectives in this framework, including those focused on change and configuration control, are helpful in establishing effective IT controls. These same controls are described in other standards, including the IEEE 828-2012—Standard for Configuration Management in Systems and Software Engineering and the itSMF ITIL v3 framework.
16.8.5 Government Accountability Office
The Government Accountability Office (GAO) reviews government agencies and the subcontractors who work for them, making recommendations on areas where processes and procedures should be improved. The GAO describes the results of their reviews on their public website. For example, the GAO reviewed and commented on the configuration management practices used by the Federal Deposit Insurance Corporation (FDIC). The GAO cited several areas where the FDIC configuration management controls needed to be improved. For example, in May 2008 the GAO issued a report that said there were weaknesses in configuration management controls in two key FDIC financial systems. The GAO report stated that the FDIC did not adequately (1) maintain a full and complete baseline for system requirements; (2) assign unique identifiers to configuration items; (3) authorize, document, and report all configuration changes; and (4) perform configuration audits. This was not the first time that the FDIC had come under scrutiny for inadequate configuration management controls. In 2005, the FDIC Office of Inspector General (OIG) retained IBM Business Consulting Services to audit and report on the effectiveness of the FDIC’s configuration management controls over operating system software.
The report also noted that CM is a critical control for ensuring the integrity, security, and reliability of the information systems. Absent a disciplined process for managing software changes, management cannot be assured that systems will operate as intended, that software defects will be minimized, and that configuration changes will be made in an efficient and timely manner. The objective of the audit was to determine whether the FDIC had established and implemented configuration management controls over its operating system software that were consistent with federal standards and guidelines and industry-accepted practices.
16.8.6 Office of the Comptroller of the Currency (OCC)
The Office of the Comptroller of the Currency was created by Congress to charter national banks; to oversee a nationwide system of banking institutions; and to assure that national banks are safe and sound, competitive and profitable, and capable of serving the banking needs of their customers in the best possible manner. The OCC issued guidelines on internal controls.
The OCC also has identified cases in which internal control weaknesses included improper and untimely reconcilements of major asset or liability accounts resulting in bank losses. In others, the bank did not institute or follow normal separation of duties between the physical control of assets and liabilities and the record-keeping functions involving those assets and liabilities.1
1. Internal Controls—A Guide for Directors, Office of the Comptroller of the Currency, Washington DC, September 2000.
In practice, banks need configuration management best practices to maintain a separation of duties between the software developers who write the code and the operations teams that maintain the production systems. The calls that we have received were in regard to getting build engineers in place to compile, package, and deploy the code in a repeatable and traceable way. We have worked in organizations where the developers would do their own build and deployment, which was very bad for many reasons. In most cases, the procedure was not repeatable, and the developers relied upon being able to access production to fix last-minute problems that had been overlooked. This meant that when their build and deployment process was broken, the operations team could not roll back to a previous release, and there was little or no traceability into changes that were made to production systems. Developers, focused on writing great code, are not to blame. Another team was needed to provide traceability and repeatable deployment processes.
16.9 Essential Compliance Requirements
Understanding what is essential for meeting compliance requirements is very important. The fact is that companies that must comply with federal regulatory regulations usually have legal experts on staff (or on contract) who help interpret these regulations and guide the firm in understanding what they really need to do. You certainly need to be guided by your own legal advisors, as they will be with you, defending you, should any violations be identified. That said, we find that most of the controls focus on establishing an appropriate segregation of duties to avoid collusion. Our experience is that these controls also avoid human error, as we have described throughout this book, including in Chapter 6. Traceability is another key consideration in that, even if mistakes are made, being able to show exactly what changes were made to production is an essential practice required by every set of regulatory guidelines that we know of.
Too many folks focus on just meeting the letter of the law, often wasting time on silly, ineffective controls that allow the company to claim that they met the regulatory requirement, but all too often are simply busywork. We strongly prefer to establish effective IT controls that not only allow you to meet the letter of the law, but actually improve your quality and productivity as well.
16.10 Improving Quality and Productivity through Compliance
If you take the time to really understand audit and regulatory requirements, then you will see that their main intent is to avoid human error and reduce risk to the firm. Throughout this book, we have described how to implement IT controls that improve quality and productivity. In this chapter, we have explained the requirements for audit and regulatory requirements and gave several practical examples. But your focus should be to go even further and create an agile ALM that meets these requirements, thus helping your organization achieve success.
16.11 Conducting an Assessment
Assessing your existing practices and comparing them to the relevant industry standards and frameworks helps identify the important IT controls that you really need to establish. We are often involved with these efforts and have found that teams usually have some effective strategies in place, yet there are often many areas where improvement really needs to occur. Your task is to find the right balance and avoid just meeting the letter of the law, but rather bring about real change that helps your team achieve success.
16.12 Conclusion
Meeting audit and regulatory compliance is a critical objective. To be successful, you need to understand what you are required to establish and the practices that will help your team avoid errors and reduce risk. We view these practices as being essential for your success and the success of your organization.