Ensure the right people have the right access

Employees are constantly turning over and changing roles. It is important to have a process in place to help ensure that as employees turn over or change roles, their access remains commensurate with their job responsibilities. New access requests should be approved by an appropriate level of management prior to access being granted. Access should also be removed or disabled for terminated employees in a timely manner. In addition to having a process to add and remove access, it is a good idea to perform periodic access reviews to ensure access remains appropriate over time.

Require and use strong passwords

Systems that authenticate using Microsoft Active Directory should be configured to systematically require the use of complex passwords. This can be accomplished by setting the group policy object’s password policy to require the use of complex passwords. If your application does not use Active Directory to authenticate, determine if your application can be configured to require password complexity and configure it to do so. If you are not able to systematically enforce password complexity, you should educate users on the importance of using complex passwords and changing them periodically. The following are some best practices for password requirements:

• Have a minimum of eight characters
• Contain a combination of lowercase and uppercase alphanumeric characters and symbols
• Should not contain any part of the user name that is associated with the password
• Be changed every 60 – 90 days
• Should not be the same as any of the user’s previous 10 passwords

Ensure patching and antivirus levels are up to date

It is important to ensure that applications and operating systems are up to date on patch and antivirus levels to help mitigate the risk of known security vulnerabilities. Ensure that your company has a process for periodically scanning applications, operating systems, and hardware to ensure that patching and antivirus levels are up to date. Tools such as Microsoft WSUS (Windows Server Update Services) can be used to manage the distribution of patches to computers. Tools such as McAfee’s ePolicy Orchestrator (ePO) can be used to periodically scan and update antivirus definitions. In conjunction with tools used to scan applications and infrastructure, have a process to follow up on repeated failed update attempts to ensure they are eventually applied successfully.

While these tips are by no means inclusive of all of the security precautions your company should be taking, they are a good start to helping ensure the security of your systems and infrastructure. Don’t get caught neglecting the basics.

SOC 1 Report

These reports are intended to meet the needs of entities that use service organizations (user entities) and the CPAs who audit the user entities’ financial statements (user auditors) when evaluating the effect of controls at the service organization on the user entities’ financial statements.  User auditors use these reports to plan and perform audits of the user entities’ financial statements.  SOC 1 engagements are performed under Statement on Standards for Attestation Engagements (SSAE) No. 16, Reporting on Controls at a Service Organization (AICPA, Professional Standards, AT sec. 801), and the AICPA Guide Service Organization’s Applying SSAE No. 16, Reporting on Controls at a Service Organization.  In other words, if the service organization plays a role in their clients’ financials (including hosting systems, such as Oracle or SAP financials), then a SOC 1 audit report is the correct choice.

SOC 2 Report

These reports are intended to meet the needs of a broad range of users who need information and assurance about controls at a service organization that affect the security, availability, or processing integrity of the systems that the service organization uses to process users’ data or the confidentiality or privacy of the information processed by these systems.  Examples of stakeholders who may need these reports are management or those charged with governance of the user entities and service organization, customers of the service organization, regulators, business partners, suppliers, and others who have an understanding of the service organization and its controls.  These engagements are performed under AT section 101, Attest Engagements (AICPA, Professional Standards), and the AICPA Guide Reporting on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy.  Simply put, every service organization that does not fall into the SOC 1 criteria should obtain a SOC 2 audit report.

So what should a service or user organization do?

Service organizations are now in the unforeseen position of receiving requests for both types of reports.  Since a service organization may have clients (i.e., user organizations) that meet the criteria for both reports, it is inevitable that a service organization will have to obtain both types of reports.  For example, this is becoming a more common situation with data center companies, though it is not unique to them.  Service and user organizations should simply discuss which report is needed while understanding that the content of a SOC 1 or a SOC 2 report is often as closely related as the names of the reports themselves.

Am I using a trusted service organization?  Ask whether the service organization has undergone an SSAE 16/SOC 1 (formerly SAS 70) examination.  These third-party examinations are performed by independent auditors who examine the design and operating effectiveness of internal controls that support information security, transaction processing, reporting, service availability, and other functions at these service organizations.  Executives should ask service organizations whether they have undergone such an examination as part of their due diligence procedures.

Have I considered the value and risk to the information that I am outsourcing to the service organization?  Although a user organization can outsource certain functions to a service organization, management of the user organization cannot abdicate responsibility.  SSAE 16 reports can assist user organizations with their evaluation of the value and risk of outsourcing certain activities.  The internal controls tested as part of a SSAE 16 examination are required to be described in detail.  This report helps the user organization understand their risk profile and the anticipated value from outsourcing.

Have I considered how knowledge of the business processes would be retained should I wish to switch back from outsourcing?  Fear of losing internal knowledge when outsourcing certain activities is often dismissed when the service organization has a SSAE 16 report.  The reason is simple: the people, systems, data,  processes, and supporting controls are usually described in sufficient detail within a SSAE 16 report so to enable user organizations to switch back from outsourcing should the need arise.  Companies need not fear as internal processes can be rebuilt using the SSAE 16 report as a tool in the event they need to switch back to in-sourcing.

Do I have a detailed list of controls based on cloud security, operational, and business risks to determine how the service organization complies with them?  This is an example of one more area where a SSAE 16 report excels.  Internal controls specific to the services the service organization is providing are described in detail within the SSAE 16 report.  This is true regardless of whether the internal controls are based on security, operational, or otherwise.  This enables companies to understand the control environment at the service organization as well as the controls they themselves would be responsible for (i.e., user control considerations).

Does my service organization meet the regulatory or compliance requirements needed by my organization?  SSAE 16 reports are designed to meet the testing and reporting requirements associated with many regulations, such as the Sarbanes-Oxley Act (also known as SOX) requirements.  The reports cover internal controls related to systems that support financial reporting.  These reports are accepted and used by public companies and their auditors all over the world.

How do I audit or evaluate controls outsourced to a service organization?  Simply request the SSAE 16 report and evaluate the contents.  This is easily the most efficient and comprehensive way to perform these due diligence procedures.  User organizations should place reliance on the competence and independence of the auditing firm that has been engaged to report on the service organization’s internal controls.  Other methods of evaluation may lack in scope, depth, and be cost and time prohibitive.

User organizations should let these questions be a guide when considering cloud offerings by service organizations.

Critical Areas and Common Red Flags

The following are suggestions for reviewing audit reports from vendors:

• Accounting Firm:  The name of the accounting firm is located in section I. Check with the firm’s state licensing board to confirm they are a licensed CPA firm.  Sadly, a surprising number are non-CPA firms, which in most states, including Colorado and New York, is illegal.  Colorado and New York license verification.
• Management’s Assertion:  Now that SAS 70 has been replaced by SSAE 16, Management is required to include their written assertion in the report stating the report’s accuracy.  Already, SSAE 16 reports are turning up with this assertion missing.  If it’s missing, a conversation with the auditor is warranted.
• Location: Vendors often have multiple locations, which is to be expected in the global economy.  Make sure the report and audit testing covers the locations in which the vendor is performing services for your company.  If it is not obvious, ask the vendor to clarify.  A vendor passing off narrow scope audit reports is more common than you might think.  Vendors do it to save costs, auditors agree to obtain work, but the public suffers.
• Report Dates:  More than a few vendors try to pass off old reports as current reports. Make sure the vendor provides a current report.
• Processes, People, & Systems:  The processes as well as the people and systems that support the processes should be adequately described in the report.  Make sure there is sufficient detail so you can understand what the vendor is doing and what they are not doing.  If a key process (eg, information security) is not described in the report, ask the vendor about it.
• User Control Considerations: User control considerations are simply controls that reside at the service organization.  Most audit reports have them.  Make sure your company considers these carefully.
• Extent of Testing:  Since SAS 70/SSAE 16 are attestation engagements; auditors are required to perform audit procedures beyond inquiry (ie, asking questions) and observation.  The auditors are required to perform a significant part of the examination through inspection and where necessary, re-performance procedures.  In the results of tests—usually Section III—review the language used to describe the tests to see if it meets the criteria just described.

To sort this out and avoid muddying the waters any further, SSAE 16 reports (ie, SOC 1) are the reports service organizations should consider first, when evaluating which type of report to receive.

In some limited number of cases, it would be incorrect for a service organization (eg, a Help Desk Management SaaS provider) to receive a SSAE 16 report. They probably should receive a SOC 2 or 3 report.  Why? Help desk activities are not likely to play a role in financial reporting, which is a requirement for an SSAE 16 report.  The reality is that the marketplace only understands one report for service organizations and it is not SOC 2 or 3, or SysTrust, WebTrust, or even SOC 1 or SSAE 16.  It understands SAS 70, but unfortunately that known brand is going away and being replaced by something that currently is not well known.  For now, just think SAS 70 = SSAE 16 = SOC 1 and you will be right 98% of the time.

User control considerations or UCCs in the audit jargon are simply controls that reside at the service organization. These controls are usually delineated in the SAS 70 / SSAE 16 reports within their own report sub-section and/or next to the control objectives they relate. UCCs together with the control activities at the service organization work in conjunction to achieve the related control objective.

The following is an example of a UCC: User organizations should have controls in place to restrict access to the secure web portal that is used to transmit data to the service organization to only authorized individuals. Controls should include notifying the service organization when an individual’s access is no longer required or if authentication credentials have been compromised.

Most SAS 70 / SSAE 16 audit reports have UCCs since they are integral to the design and operating effectiveness of the control environment. The UCCs are usually tested by the user auditor in conjunction with the performance of the financial statement audit of the user organization. If a SAS 70 / SSAE 16 audit report does not have any UCCs this may be an indication of an incomplete report and therefore lead to inadequate financial statement audits at user organizations. If in doubt, talk to the service auditor. In most cases, they should be more than willing to answer questions on user control considerations.

What are the differences between a Type I and a Type II SAS70 / SSAE 16 audit report?

This question often comes up when a service organization is considering their first SAS 70 / SSAE 16 audit. A Type I report is as-of a point in time (eg, September 30th) whereas a Type II report covers a period of time (eg, October 1, 2010 – September 30, 2011).  Also, a Type I report only cover the design effectiveness of internal controls.  A Type II report covers design as well as the operating effectiveness of internal controls.

Many service organizations will elect a Type I if they have never gone through the SAS 70 / SSAE 16 audit before.  First, this approach often allows service organizations to become familiar with the audit process to give them a sense of what is required to undergo a Type II audit.  Second,  it often helps instill service organization to instill the discipline necessary to successfully complete a Type II audit. Finally, in most situations at least six months have to elapse in order to have a Type II report. When potential customers are looking for assurance that a provider has a SAS 70 / SSAE 16, the Type I audit is a great stop gap measure to show commitment while the Type II audit is underway.

There is another significant difference between a Type I and a Type II report.  In order for a SAS 70 / SSAE 16 “[t]o be useful to user auditors, the report should ordinarily cover a minimum reporting period of six months.”  See AICPA AU 324.53.  This is only possible with a Type II report, since it covers a period of time.

Testing exceptions are simply deviations from the expected result from testing one or more control activities. Consider the following example:

Control Objective: Controls provide reasonable assurance that statement processing is appropriately scheduled and that deviations in processing are identified and resolved.

Control Activity: Statement batch totals are used in order to identify and resolve deviations in processing.

Testing Performed: Inspected a sample of batches used to process statements and noted that batch control totals were used to help maintain the integrity of the statements processed.

Using the example above, if one or more of the samples selected did not use batch control totals as expected and indicated by the service organization, that deviation would be a testing exception.

So what does this exception mean to the SAS 70/SSAE 16 examination?

Testing exceptions generally fall into one of four categories: clearly inconsequential, relevant to the user auditor, and control failure, and precludes the achievement of the control objective. Those testing exceptions that are clearly inconsequential should not be noted in the report. The others should.

Referring again to the example above, a testing exception for the batch control totals should be described in the report though it would not necessarily preclude the achievement of the control objective. Additional tests and considerations would have to be made before that happened.

Summary

Most reports have testing exceptions. It is normal. Abnormal are perfectly clean reports that show no exceptions. In cases such as these, user organizations and user auditors have to wonder how robust the service auditor’s procedures actually were.

The CPA profession has done an inadequate job in educating user organizations on what a SAS 70 is and is not, so we can only blame ourselves for this predicament. A SaaS provider hosting their systems in a data center that has a SAS 70/SSAE 16 report is good; however, it is only good to a point. Whatever extra services the provider is performing relevant to the user organization’s financial reporting is the rest of the story that is not covered by the data center’s report on internal controls. User organizations and service organizations themselves should consider what is and is not covered by a SAS 70/SSAE 16 report. Given that over 80% of this terribly small sample yielded some interesting results, my guess is that this problem is systemic. Hopefully with the change to SSAE 16, organizations will be prompted to re-evaluate the role of these important compliance reports and use them in the intended manner.