Independence and information systems services
For many years, the “Information Systems Design, Implementation, or Integration” interpretation (ET §1.295.145) in the AICPA Code of Professional Conduct provided guidance for information system services. Services of this type pose potential independence challenges and threats. The existing interpretation provided that the threats to independence would be at an acceptable level if a member took certain actions related to an attest client’s financial information system (FIS).
In particular, threats arising if a member installed or integrated an attest client’s FIS would be at an acceptable level as long as the member did not design or develop the system, and the member was also in compliance with the general requirements for performing nonattest services.
Though helpful, this language led to some questions and debate. For example, what did “install” mean, and how did this differ from “integrate”? Was this latter term the same as “design” and “implement”?
The existing interpretation also mentioned “off–the–shelf” software as an example of what would not create threats to independence. At least as many questions stemmed from what is considered an off–the–shelf accounting package. Some practitioners maintained that an off–the–shelf package should be any software product commercially available from a third party, such as a software vendor, and should include complex enterprise software products such as Oracle, SAP, and others. Those with this view believed these products could meet the requirement of not having been designed or developed by the member.
Others believed that the phrase “off–the–shelf” referred only to very simple software products that may be, for example, bought shrink–wrapped off the shelf or online from a retailer, loaded onto a client’s computer, and immediately ready to use. Underlying this belief was a view that complex enterprise software products, which often come with myriad processing and data options to be chosen by the user, could perhaps lead to new functionality not designed by the third party that produced the software. This would mean that the member could end up somehow designing and implementing a “custom” system that no longer meets the supposed definition of an off–the–shelf software package.
These considerations, along with the need for a new hosting interpretation, prompted the AICPA Professional Ethics Executive Committee (PEEC) to organize a task force of representatives from several accounting firms, supported by AICPA staff, to review the guidance in the interpretation and determine how it might be clarified and improved.
The result of the task force’s work was PEEC’s adoption of a modernized interpretation on information system services that was issued in June, takes effect Jan. 1, 2021, and allows for early implementation.
To better understand the revised interpretation, readers should bear in mind some important fundamental principles, concepts, and definitions. Let’s start with the definitions. At the core of many information systems services are terms such as “install,” “design,” “configure,” “develop,” “implement,” “customize,” “interface,” “commercial off–the–shelf (COTS) software,” and others.
Though there may be differing views about the intended scope or nuances of some of these terms, information technology (IT) practitioners and consultants who provide information systems services to clients have a general, common understanding of the meaning of such terms.
COTS software is generally understood to be commercially available software products that are designed, developed, distributed, and maintained by a third party — usually a software vendor. COTS products can be traditional, on–premises systems intended to run on the user’s own or some other party’s servers, or they can be cloud–based solutions that run on the vendor’s own or some other party’s servers. COTS software may also be open–source solutions that are not supported by any one third party. COTS software could be relatively simple programs that can be purchased from a retailer and only require loading onto a computer before they are ready to run, or they could be large, complex enterprise systems offered by vendors such as Oracle, Salesforce, SAP, and many others.
The main point of COTS software for the purposes of the revised interpretation is that such software — unless the member’s firm is the software vendor that designs, develops, and implements the software — is not software designed and developed by a member, no matter how complex the software may be.
This takes us to “design” and “develop.” Designing an information system, or a single program, means determining how it will function, process data, and produce results, such as reports and a variety of transmittal documents (for example, purchase orders). “Develop” means writing and testing software code, often by following a specified design. How the design and development steps are actually executed may depend on the applied methodology, such as waterfall vs. agile sprints, but this does not alter the basic meanings of the words for the purposes of the interpretation.
“Configuring” a COTS software solution requires a user to understand and decide which processing, display, and data options to select. A COTS software implementation consultant, who may be a member, typically assists the client in understanding the various configuration options and the implications of various choices, and then makes the selections within the system based on the client’s decisions. If limited solely to configuration activities, no matter how complex the COTS software solution, a member would not be engaging in design or development.
To customize a system, specifically a COTS software solution, means to enhance or modify the software by adding new features and functions, or altering existing features and functions that allow the solution to go beyond what the third–party vendor provides, generally through design and development of new or modified code. Likewise, creating an interface between two or more systems means enabling the systems to pass data from one system to the other. The building of interfaces involves design and development activities, unless the interface is effected through a third–party vendor’s ready–made software solution, such as an application programming interface (API), and no additional design and development activities are required to tailor or customize the API to make it work.
Another key activity in implementing a COTS software solution is data translation, sometimes referred to by IT professionals as data conversion. In general, data translation means changing the format of data from one system so it is compatible with the data format in another system. Data translation is typically required to populate a new COTS software solution with data from a client’s legacy system(s). Data translation may also be required in creating interfaces. Data translation programs, unless effected through a third–party vendor’s ready–made software solution without any modifications, require design and development activities in order to work.
Finally, to round out the definitions, let’s consider “install” and “implement” — two terms that are at opposite ends of the spectrum in terms of scope of activities. A COTS software solution is installed by performing an initial load of the software onto a client’s designated hosting site that may be a client’s own or a third party’s servers. In the case of cloud–based COTS solutions, this may involve establishing a new tenant in the third–party vendor’s hosting environment. Installing a COTS software solution does not involve design or development activities. Implementing a COTS software solution can mean a range or subset of activities, from installation, configuring, design, development, and data translation through cutover to production where the system is available for the client to use regularly.
The revised interpretation differentiates between two general classes of information systems: FISs and systems that are unrelated to an FIS (that is, non–FIS).
For the purposes of the interpretation, an FIS aggregates source data underlying the financial statements or generates information that is significant to either the financial statements in particular or financial processes as a whole. The reader should note that an FIS is not limited to applications such as the general ledger and other obvious accounting systems, but includes a wide array of systems that create transactions with cost or revenue implications, such as inventory control, supply chain, production scheduling, order placing, points of sale, and many others. These types of systems often generate data that can be used in an entity’s financial reporting processes. The revised interpretation provides guidance on determining whether certain systems or nonattest services are related to an FIS, such as systems that may include controls or output that may be subject to attest procedures or are part of the client’s systems of internal control over financial reporting.
Understanding the definitions related to information systems services terms and the definition of an FIS, we can now consider the central premises of the interpretation.
First, as long as the member is in compliance with the general requirements of the provision of nonattest services, threats would be at an acceptable level if the member performs design, development, and, more broadly, implementation services related to a non–FIS for an attest client.
Second, threats to a member’s independence would not be at an acceptable level and could not be reduced to an acceptable level if the member designs or develops an FIS for an attest client.
Third, as long as the member is in compliance with the general requirements for the provision of nonattest services, threats to a member’s independence would be at an acceptable level if a member performs implementation services related to an FIS COTS software solution where the services do not involve design, development, customizations, the building of interfaces, or the creation of data translation programs. The services may include the member assisting the client with understanding and effecting configuration options for the FIS COTS software solution, as long as the client makes all decisions with respect to selecting those options.
In addition to clarifying that “all COTS software solutions are COTS,” regardless of complexity and scale, the revised interpretation provides useful definitions that enable members to focus on the nature of certain specific information systems activities and services. The revised interpretation also provides more guidance on defining what constitutes an FIS and what does not.
The interpretation closes with guidance on what may be permissible and what may impair a member’s independence when it comes to services that may follow the implementation of an FIS or a non–FIS software solution. Also considered are IT components that may not be application software solutions, such as a client’s local area network.
In short, threats to a member’s independence cannot be brought to acceptable levels for services that involve a client outsourcing to the member an ongoing function or process, such as systems monitoring, support, or maintenance, as such services represent the member assuming a management responsibility, even if an individual with suitable skill, knowledge, and/or experience from client management is overseeing the services.
On the other hand, certain services that may represent separate and distinct engagements, and are not ongoing or continuous services, may be permissible. An example is being engaged by a client to analyze the client’s network and provide observations or recommendations for the client’s consideration.
Great care was taken to produce an interpretation that is responsive to evolving technology and practice needs while providing more clarity to independence requirements. By making sure they are complying with the interpretation, members can maintain independence while providing permissible and high–quality services to clients.
For additional information related to independence when providing cybersecurity services to attest clients, readers are encouraged to view the “Cybersecurity Services” subtopic in the Frequently Asked Questions: Nonattest Services document.
About the author
Dan O’Daly is a managing director in the National Office Independence Group at Deloitte LLP in San Francisco.
To comment on this article or to suggest an idea for another article, contact Ken Tysiac, the JofA‘s editorial director, at Kenneth.Tysiac@aicpa-cima.com or 919-402-2112.
AICPA resources
Articles
Publication
CPE self-study
Webcast
For more information or to make a purchase, go to aicpastore.com or call the Institute at 888-777-7077.
Podcast
Research & References of Independence and information systems services|A&C Accounting And Tax Services
Source
0 Comments