Please enjoy reading this archived article; it may not include all images.

Synthesizing SAS 70 Audits and PMI’s Project Management Process Groups

Date Published: 1 July 2010

All projects at some point will come under fire, and in an uncertain economy, increased pressures to derive optimal value emphasize the need to deliver project success. Statement on Auditing Standards No. 70 (SAS 70), Service Organizations, audits can be expensive, particularly Type II audits. As companies are reducing budgets and staff, justifying the cost of this audit becomes important, with value and expectations increasing. Companies with smaller staffs and/or increased reliance on outsourcing are realizing that strong process is the key to better application development and avoiding expensive rework. Even in accelerated SAS 70 Type I project life cycles, project management (PM) best practices can be exercised.

Process is not about reinventing the wheel; rather, it is finding what has worked in the past and applying it to the present, using strong communication to deliver and manage these processes and paring away anything that diverts the team from project goals. The ultimate challenge for project management is to find a repeatable process and communicate it clearly so that multiple levels within an organization accept and support the benefits. The key to best practices in project management is no mystery; it lies in the execution.

PM is a process by which projects are defined, planned, organized, monitored, controlled and delivered in such a way that the agreed-upon goals are realized given the project’s scope, schedule, cost and quality constraints. Projects are unique, temporary undertakings with a start date and an end date (or end condition).

SAS 70, which provides for a uniform approach to reporting, is a defined standard developed by the American Institute of Certified Public Accountants (AICPA) as a set of criteria a service or user organization’s auditor should use while assessing the outsourced internal controls of a service organization. Service organizations typically provide outsourcing services that may affect the operations of the contracting company or user organization; such services may include transaction processing, web hosting, hosted data centers, paper shredding, credit processing, etc.

AICPA defines a standard for uniform audit reporting of SAS 70 audit findings without regard to the process of conducting an audit. A SAS 70 audit engagement is effectively a project with all the characteristics described in the Project Management Body of Knowledge (PMBOK) and could conceivably benefit from applying the best practices, tools and techniques of project management.

SAS 70 audit projects are distinctive and temporary, requiring a progressively elaborate set of auditing tasks that lasts for a couple of days to several months based on the type of audit. Regardless of the type of audit, the end result is a SAS 70 audit report commissioned at the request of the project sponsor (which is either a service organization or user organization). These audits are performed by accounting firms, often in collaboration with a Certified Information Systems Auditor™ (CISA®) along with other IT specialists as needed based on the scope of the audit.

This article will explore how a SAS 70 audit is improved by understanding and applying PM tools and techniques. To this end, the basic tenets of PM principles, as defined in A Guide to the Project Management Body of Knowledge (PMBOK Guide), will be examined and synthesized with the SAS 70 auditing process, emphasizing the ways to optimize SAS 70 auditing performance.

What Is a SAS 70 Audit?

SAS 70 is an auditing statement developed by the Auditing Standards Board of the AICPA. A SAS 70 audit is broadly recognized because it provides reasonable assurance that a service organization has been through an in-depth audit of its control activities, which generally include controls over IT and related processes.

In cases where data are regulated and/or sensitive, it is important for service organizations to have detailed and well-documented controls in place to ensure the safety and privacy of the data being processed, stored and transmitted. Perhaps most notably, the requirements of section 404 of the US Sarbanes-Oxley Act of 2002 heighten the importance of SAS 70 audit reporting on the effectiveness of internal control over financial reporting. A SAS 70 audit serves as an indicator of transparency and accountability; it establishes a high level of commitment by the service organization toward ensuring the reliability and security of its data by having its internal controls and activities examined (via an in-depth audit of control) by an independent auditing firm.

SAS 70 provides guidance to service auditors when they assess the internal controls of a service organization and issue a service auditor’s report. SAS 70 also provides guidance to auditors of financial statements of an entity that uses one or more service organizations. Service organizations are typically entities that provide outsourcing services that impact the control environment of their customers or user organization. Examples of service organizations are insurance and medical claims processors, trust companies, hosted data centers, application service providers, managed security providers, credit processing organizations, and clearinghouses, to name a few.

A formal report, called a service auditor’s report, which includes the auditor’s opinion or attestation statement, is issued to the service organization at the conclusion of a SAS 70 audit. This report is effectively an auditor-to-auditor communication between the service organization and user organization (the entity that has engaged a service organization, particularly if its financial statements are impacted by the services of the service organization).

Types of SAS 70 Audits

There are two different, yet complementary, types of SAS 70 audit reports, a Type I or Type II audit. Type I includes an opinion of the fairness of the presentation of the service organization’s description of controls that had been placed in operation and the suitability of the design of the controls to achieve the specified objectives. Type I reports describe the degree to which the service organization fairly represents its services in regard to controls that have been implemented in operations and its inherent design to achieve objectives set forth. This report typically examines controls only over one or two days, which arguably has limited value to a user organization.

A Type II service auditor’s report is the more thorough report of a SAS 70 audit because it contains a description of the controls in place and a description of the auditor’s tests of control effectiveness for a minimum testing period (usually the defined period is six months, but it can be longer). The Type II examination of the SAS 70 audit process begins the same as Type I, but adds more testing and observing procedures. These procedures analyze and test the controls vis-à-vis the Type I, which merely describes the controls in place. The Type II service auditor’s report states “whether the controls that were tested were operating with sufficient effectiveness to provide reasonable, but not absolute, assurance that the control objectives were achieved during the period specified.”1

A Type II service auditor’s report is more common and often the preferred choice of SAS 70 audits because it is a comprehensive analysis of not only what controls are in place, but how effective those controls are in meeting the desired objectives.

What Is PM?

The PMBOK Guide is a collection of processes, process groups and knowledge areas generally accepted as best practice within the PM discipline. As an internationally recognized standard (IEEE Std 1490-2003), it provides the fundamentals of project management, irrespective of the type of project.

The PMBOK Guide defines PM as “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.”2 In many ways, PM is a framework or guide for achieving goals while optimizing the use of resources (e.g., people, time, capital).

PM is, ultimately, about applying the appropriate skills to attract and manage the right team while using tools and techniques to get the job done to specification, on time and within budget. One of the traditional ways to measure whether a project’s objectives are being met is through Triple Constraint. PM Triple Constraint has been defined a number of ways. For this article, the variation of definitions is negligible since the challenge of every project is to be successful within the Triple Constraint framework. Triple Constraint consists of scope (project size, goals, requirements), cost (people, equipment, material) and schedule (task durations, dependencies, critical path), with quality (meeting or exceeding customer or sponsor satisfaction) serving as the requisite criterion for the three constraints. The three elements of a project are known to work in tandem with one another, forming an equilateral triangle that remains equilateral as elements are adjusted over time. Where one of these elements is restricted or extended, the other two elements will then also need to be either extended/increased in some way or restricted/reduced in some way.

Triple Constraint involves making trade-offs among scope, time and cost for a project. It is inevitable in a project life cycle that there will be changes to the scope, time or cost. Where many projects encounter difficulty is when one of the areas changes and appropriate adjustments are not made to the other areas. There is an ongoing balancing of the three elements that requires a skillful project manager who understands planning, resourcing and executing/controlling a project. The project manager is accountable for accomplishing the stated project objectives, oversees all the work identified to complete the project, and applies various tools and techniques. A project manager must simultaneously manage the four basic elements of a project: quality, cost, schedule and scope.

SAS 70 Auditing and PM Principles

Before synthesizing SAS 70 audits with PMBOK principles, it is important to demonstrate the parallel relationship between SAS 70 audits and PM principles. The association between the SAS 70 audit process and the concept of a project is outlined in figure 1.

3 4

All projects should have a well-defined objective or goal; a SAS 70 audit goal is either a Type I or a Type II audit report. A project should have a primary sponsor, who is the person responsible for providing direction and funding for the project; the SAS 70 audit sponsor is usually a senior manager or member of upper management. Another project characteristic is its uniqueness and sequencing of activities. Each SAS 70 audit must be uniquely tailored to the organization’s transaction processing controls, with appropriate sequencing of incremental audit tasks. SAS 70 audits should have a specified start and finish time frame, along with some allocated resources that comply with the attributes of the audit.

Since SAS 70 audits ostensibly meet all the attributes of a project as defined by PMBOK, it stands to reason that understanding and applying the best practices of PM are also beneficial to the SAS 70 process. Refer to figure 1 for a detailed listing of the SAS 70 audit project.

Synthesizing SAS 70 Audits With PM Techniques

Managing a SAS 70 project, as with any project, consists of executing defined activities to achieve project objectives. These project activities or processes, as defined by PMBOK, are quite similar for most projects. PM processes are grouped into five different process categories—each process constitutes a series of tasks directed toward some result. The process groups are initiating, planning, executing, monitoring and controlling, and closing. The process groups are linked by the output they produce; that is to say, inputs serve as the prerequisites or entry criteria to start the next process. Outputs are the exit criteria or the result of the process with which the process ends; the output of one process generally becomes an input to another process.

Performing a SAS 70 audit is a structured, multistep process that includes a number of predefined processes and procedures that must take place to ensure its successful and timely completion. Depending on the needs of the requesting organization, a SAS 70 Type II audit is generally performed for a specified period following the completion of a Type I. Generally, successfully completing a SAS 70 Type I and then moving toward Type II compliance for subsequent years is the most common path many service organizations choose.5

SAS 70 Type I and Type II audits are potentially improved by using the best practices of PM as identified in the PMBOK Guide process groups. Each PM process within the process groups is correlated to the SAS 70 audit process, as shown in figure 2.

Initiating Process and SAS 70 Audit

The SAS 70 initiation process is launched after soliciting or responding to a request for proposal (RFP) with a contract that commonly includes the cost of work; background and experience of the auditors; audit methodology; deliverables; project plan; and project leader/team along with résumés, assumptions and references.

A preliminary review, also referred to as a readiness review, is often performed for service organizations that are new to the SAS 70 audit process. The purpose of a readiness review is to define the key control objectives and control activities that will be covered in the forthcoming SAS 70 audit(s) and to identify those control weaknesses that need to be corrected prior to the SAS 70 Type I or Type II audit engagement.

When defining the scope, ideally the user organizations will have significant input into the scope or systems to be covered by the service organization’s SAS 70 audit. In practice, the service organization largely determines the audit scope based on its relationship with the user organizations or selective audit objectives deemed important.

Establishing a scope statement should follow a structured initiation process beginning with an audit contract that establishes executive understanding and commitment before starting a project. The project manager should ensure that a project has a designated project sponsor and should gather the necessary business and technological criteria to justify the project continuing with adequate executive support during its life cycle.

PM tools and techniques support the initiation processes— establishing the nature and scope of the project. Best practices for this stage suggest that if it is not performed well, it is unlikely that the project will be successful in meeting the business’s needs. The key project controls needed here are understanding the business environment and ensuring that all necessary controls are incorporated into the SAS 70 project.

Planning Process and SAS 70 Audit

After the initiation stage, the project is planned to an appropriate level of detail. The central purpose is to plan the work in terms of time, cost, people and other resources and in such a way that work estimates are possible and probable risk is identified. As with the initiation process group, failure to plan sufficiently significantly reduces the project’s chances of successfully conducting a SAS 70 audit.

Project planning generally consists of producing a project plan that includes the following:

  • Determining the audit category (Type I or Type II)
  • Further refining the scope statement
  • Creating a work breakdown structure (WBS) and identifying deliverables
  • Defining activities, durations and logical sequencing
  • Estimating the resource requirements for the activities
  • Estimating time and cost for activities
  • Planning quality
  • Developing a human resource plan
  • Developing the schedule
  • Developing the budget
  • Identifying risk and planning risk management

Comprehensive planning is critical, even with short development cycles for Type I audits. Project goals should be made attainable by prioritizing deliverables to keep a team tightly focused on specific issues. To understand exposures and the dangers to the project, the team, stakeholders and sponsors should be routinely involved in closely managed sessions to discuss each objective and clearly explain risks and benefits.

SAS 70 project planning is perhaps the most difficult and unappreciated process in the project stages. The central purpose of SAS 70 audit project planning is to guide audit execution. And, to guide execution, plans must be realistic and useful; this often requires an inordinate amount of time and effort. Best practices suggest audit planning should be a team effort with task-knowledgeable people planning the work. A basic planning tenet is: “A dollar spent up front in planning is worth one hundred dollars spent after the system is implemented.”6

Executing Process and SAS 70 Audit

Executing a SAS 70 audit involves coordinating people and resources, as well as integrating and performing the activities of the audit in accordance with the project management plan. Successfully executing a SAS 70 Type I or Type II audit involves developing the audit team to perform, according to the PM plan, information distribution and contract administration.

The project manager for the SAS 70 audit engagement is responsible for accomplishing the PM plan by integrating the following audit activities into one coordinated effort. These activities broadly include:

  • Coordinating an initial meeting to understand the scope, timing and final deliverables of the audit
  • Requesting the service organization to submit its SAS 70 readiness assessment for review, if available. Otherwise, a readiness assessment should be performed.
  • Facilitating a meeting for SAS 70 auditors and the service organization to collectively agree on any areas within the service organization’s control environment that require remediation prior to beginning the SAS 70 Type I or Type II fieldwork
  • Listing the documents and other deliverables that must be prepared prior to commencement of the SAS 70 Type I or Type II fieldwork
  • Directing the SAS 70 auditing team fieldwork activities based on the type of SAS 70 audit. Fieldwork may include the following:
    – Performing tests to evaluate appropriateness and operating effectiveness of control design (Type II only)
    – Identifying and communicating control deficiencies to management
    – Recommending required controls and guidelines to management
  • Facilitating the preparation of an initial draft report and coordinating meetings with the service organization to discuss findings
  • Coordinating the final closing meeting between the service auditors and the service organization to discuss the final SAS 70 service auditor’s report and management’s comments
  • Issuing the final SAS 70 service auditor’s report

Effective audit execution makes use of all the stakeholders (sponsor, clients, project team, support staff and so on) involved in the project. People are the single most important asset in organizations and on audit projects. As such, people perform much more effectively if they are in active communication with each other so that each dependency is clearly understood and managed. Holding weekly information sessions with the team to discuss issues and to collectively figure out correction strategies is yet another principle gleaned from PM best practices. If the team is scattered, the project manager should use collaborative tools to hold meetings and share information. The method is not as important as the ongoing communication activity itself.

Monitoring/Controlling Process and SAS 70 Audit

Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the audit project. The key benefit is that audit performance is observed and measured regularly to identify variances from the PM plan.

Monitoring and controlling includes:
  • Measuring the ongoing audit activities
  • Monitoring the project variables (cost, effort, scope, etc.) against the PM plan and the audit performance baseline
  • Identifying corrective actions to address issues and risks properly
  • Influencing the factors that could circumvent integrated change control so only approved changes are implemented

To assess the status of the audit, the project manager should schedule meetings regularly. Issues discussed during these meetings may include actual progress vs. work and cost estimates, requirements measurement for scope control, and overall quality measurements in productivity. The actual process is very flexible. Using the audit project charter as a guide, the team should prepare criteria that measure the entire project, and then use subsets of those criteria for assessment with each milestone. Short life cycle projects, i.e., Type I audits, can also benefit from regular meetings as long as they ensure that time is not wasted. Meetings should be kept short and to the point. Standard criteria for measurement, such as meeting deliverables, defect detection, resource utilization and rework, should be developed to find out where improvements are needed.

Closing Process and SAS 70 Audit

Closing includes the formal acceptance of the audit report and usually a debriefing meeting. Administrative activities include the archiving of the files and documenting lessons learned.

This phase consists of:
  • Finalizing all activities across all of the process groups to formally close the project or a project phase
  • Completing and settling the contract (including the resolution of any open items) and closing each contract applicable to the project or project phase
  • Issuing the SAS 70 audit report

A postmortem audit review should be conducted. This is the time to hash out any issues that will improve audit support and improve process for the next audit project. All audit issues that caused any delays or restructuring of project focus, implementation issues and support problems should be collected and noted.

Conclusion

SAS 70 audits have grown increasingly popular with the implementation of the Sarbanes-Oxley Act and its mandate for demonstrating the effectiveness of a service organization’s internal controls and data security safeguards. The primary challenge of SAS 70 audits as they relate to PM is to achieve all of the project goals and objectives while managing the ever-present scope, schedule and budget constraints that, according to the Standish Group,7 have thwarted many projects.

SAS 70 Type I or Type II audits are arguably an organizational investment since considerable time, money and other resources are committed with an expectation of receiving something of value in return. And, since SAS 70 audits are in fact projects (by virtue of meeting the criteria of a project as shown in figure 1), they stand to benefit from the best practices of PM as outlined in the PMBOK Guide.

The PMBOK Guide offers a framework that facilitates combining the body of knowledge of project management along with the body of knowledge of SAS 70 auditing, which allows for an improved philosophy and method for planning and managing a SAS 70 audit. The aggregate of SAS 70 auditing and project management bodies of knowledge provides a foundation for a logical, repeatable approach that improves the likelihood of successfully delivering value to the organization via a SAS 70 audit.

Aggregating SAS 70 auditing and PM bodies of knowledge can be overwhelming at first glance; however, a more prudent approach for audit projects would be to tailor the PMBOK Guide according to the project, rather than exhaustively attempting to address all the process areas. A tailored approach is best supported by creating and regularly updating a best practice library of methods that have worked for previous projects. This library should be a living repository that grows with each completed audit project. As audits are completed, a postmortem review should be performed to update or change procedures for continual improvement. The general rule of thumb is to strive for modularity, so that processes and procedures can be customized for a specific project based on size, complexity, team structure, etc.

Endnotes

1 SAS70.com, “About SAS 70,” 2000-2009, www.sas70.com/about.htm
2 PMI, A Guide to the Project Management Body of Knowledge, 3rd Edition, USA 2008
3 Association of Government Accountants (AGA), CPAG Research Series: Report No. 15, “SAS 70 Reports: Are They Useful and Can They Be Improved?,” July 2008
4 Ibid.
5 SAS 70 Resource Guide, “SAS 70 Primer,” NDB LLP, 2008, www.sas70.us.com/white-papers/introduction-to-theauditing-standard.php
6 Author unknown
7 Johnson, Jim; “CHAOS: The Dollar Drain of IT Project Failures,” Application Development Trends, January 1995

Thomas J. Bell III, Ph.D., CISA
is a professor of business administration in the School of Business at Texas Wesleyan University in Forth Worth, Texas, USA, and an IT security auditor for ComputerMinds.com in Euless, Texas, USA. His IT auditing specialty is IT audits for small community banks (IT security audits and external penetration testing) and SAS 70 Type I and II audits.