Author Archives: admin

SSAE 16 and the Federal HealthCare Exchange


With the issues surrounding HealthCare.gov and the various contractors who played a role in the development, one question that comes to mind is: How many of the over 50 companies contracted had an SSAE 16 (SOC 1) audit performed over the services they were providing?

This is important to know and could be part of the reasons why the development efforts appear to have fallen short of best practices.

The standard change management / development process should flow accordingly:

  1. Define scope of the project or individual change / fix planned for development
  2. Review of the request and development plan by a committee to validate the appropriateness, priority, and potential conflicts that could arise.
  3. If approved, determine a high level development plan including dependencies and interfaces, create test procedures to validate the change, and roll back procedures.
  4. Complete the development / coding required.
  5. Development and end users perform robust testing / QA based on the test procedures and their standard use of the application.
  6. Project manager or appropriate Management personnel perform a final review and approve for promotion into production or main branch of the application (if multiple concurrent changes being made).
  7. Validate functionality of application post-implementation to further ensure no issues exist.

From the information currently available it appears that in the rush to meet Organizational goals and tight deadlines, steps 5-7 were performed hastily leading to unexpected issues once the system went live. It was even mentioned that basic Alpha testing of the entire exchange ecosystem was barely completed before the roll out. This experience proves more than ever that having a properly controlled change management process with a priority placed on testing is key when performing development activities impacting the core functionality of an application. The complexity of this project just serves to further highlight these basic, but often overlooked, steps.

healthcare exchange ssae 16 audit

Chances are that if the various contractors used to develop the Health Exchange were audited regularly, these controls would have had a higher priority placed on them within their respective Organizations and performed accordingly at the risk of failing their next SSAE 16 audit and creating the mess we are in today.

These miscues serve as a perfect example of knowing and being comfortable with the controls in place at a contracted 3rd party service provider. This assurance is what an SSAE 16 audit is intended to provide and why they are so important in today’s business environment.

Are Service Provider Contract Updates Needed with SSAE 18?


While some companies still request a SAS 70 report (why, who knows…), many contracts now require a SSAE 16 report, and with the change to SSAE 18 many are now asking, what is the right language to use going forward? To fix this, the AICPA is now stating the standard number or reference should no longer to be used, and formally referred to as a SOC 1 report. This will hopefully help to prevent this situation in the future when new updates are inevitably implemented (SSAE 19, 20, …). A minor, but, helpful change.

So – while you do not *have* to update your contracts, it’s typically the best course of action, and now, going forward you shouldn’t have to worry about it again.

Are there any other nagging items like this you are running into? If so, contact us or leave a comment and we will do our best to clarify.

SOC 2 Report – Trust Services Principles


The System and Organization Controls (SOC) 2 Report will be performed in accordance with AT-C 205 (formerly under AT-101) and based upon the Trust Services Principles, with the ability to test and report on the design (Type I) and operating (Type II) effectiveness of a service organization’s controls (just like SOC 1 / SSAE 18). The SOC 2 report focuses on a business’s non-financial reporting controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system, as opposed to SOC 1/SSAE 18 which is focused on the financial reporting controls. SOC2-Security: The system is protected, both logically and physically, against unauthorized access.Availability: The system is available for operation and use as committed or agreed to.Processing Integrity:  System processing is complete, accurate, timely, and authorized.Confidentiality:  Information that is designated confidential is protected as committed or agreed.Privacy: Personal information is collected, used, retained, and disclosed in conformity with the commitments in the entity’s privacy notice  and with the privacy principles put forth by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA).

The Trust Service Principles which SOC 2 is based upon are modeled around four broad areas: Policies, Communications, Procedures, and Monitoring. Each of the principles have defined criteria (controls) which must be met to demonstrate adherence to the principles and produce an unqualified opinion (no significant exceptions found during your audit). The great thing about the trust principles is that the criteria businesses must meet are predefined, making it easier for business owners to know what compliance needs are required and for users of the report to read and assess the adequacy.

Many entities outsource tasks or entire functions to service organizations that operate, collect, process, transmit, store, organize, maintain and dispose of information for user entities. SOC 2 was put in place to address demands in the marketplace for assurance over non-financial controls to prevent SOC 1 from being misused just like SAS 70 was.

Did you know? A business isn’t required to address all the principles, the reviews can be limited only to the principles that are relevant to the outsourced service being performed. Some example industries that might have a need for a SOC 2 include: SaaS Providers, Data Center/ Colocations, Document Production, and Data Analytics providers.

SSAE 16 vs ISAE 3402 – Part 2 – Intentional Acts


The first difference between the SSAE 16 and ISAE 3402 Standards is that SSAE 16 requires the service auditor to assess the risk associated with potential “Intentional Acts by Service Organization Personnel”.
Under SSAE 16, If the service auditor, while performing their review, notices deviations that could have been a result of an intentional act by an employee of the service organization, the auditor is required to dig into it. The reasoning for this is to determine whether or not the description of the service organization’s system is not fairly presented and that the controls are not suitably designed or operating effectively.
So, it seems that in this case, the SSAE 16 standard is a bit stricter. If the auditor is not required to dig into an intentional act committed by an employee of the service organization, how would the Auditing Firm and User Organizations feel comfortable with the report? In my opinion, they shouldn’t. Without any consequences for the service organization (failed report), there is an incentive for the service organization to try and operate outside the control structure as defined as it is unlikely that they would be held responsible for their actions. This might be a question you would want to dig into if you are going to use a company that has only been issued an ISAE 3402 report.
Be on the lookout for the next post related to the difference between SSAE 16 and ISAE 3402, Anomalies.