The Lord of the Audits, Part 2: The Two Engagements

In 2008, as a successful SaaS provider of supply chain software for the healthcare industry, MediClick’s current and prospective customers began requesting a SAS70 Type 2 audit from us. We heard warnings that our developers would revolt if we launched the auditing process. We started to expect red flags due to our customer support methodology. We even anticipated the audit would cause trouble for our agile development process. But the value of a SAS70 Type 2 audit was too great. Once we decided to dive into the process, there was no turning back.

To head off any backlash from an audit, we wanted to ensure we had the right team in place. We first set out to find an auditing firm that understood the importance of preserving the successful process we had built during our seven years in business.  Since a certified public accountant must perform each SAS 70 audit, we found a firm that understood SaaS and could effectively work with us to build control objectives that reflected our business model.

After we had the auditing firm in place, we needed to undertake two engagements to achieve a successful SAS70 Type 2 audit: a readiness assessment and the final audit.

The first engagement, a readiness assessment, took place in March 2008. Much like the PSATs that high school students take to gauge their performance prior to taking the full SATs for college entrance, the readiness assessment would allow us to get a first-hand grasp of the entire process and the types of activities the auditors performed. We worked with the auditors to define our control objectives, which we designed so that an auditor could test and report on the effectiveness of the objective. Objectives ranged from the security of the MediClick network environment to the documentation of our development, testing and deployment processes.

Prior to the readiness assessment the auditors requested that we provide them with detailed documents, such as an organization chart, recent employee handbooks, listings of firewall changes, data backup schedules, visitor logs, hot fixes and service packs applied to production systems.

The auditors were on site for a week to perform the assessment; at the end they produced their findings and recommendations for remediation. The auditors assigned each recommendation with a risk level – from low to medium to high – and included a resolution difficulty rating with each.

We felt good about the results of the assessment because it revealed no “gotchas.” The recommended resolutions were doable within our 3-month remediation period. During this time we corrected any shortcomings discovered, such as using generic userids, tightening up our employee access rights and hardening our network and application passwords.

With a better idea of what to expect during the audit, our next step was to talk to the employees about SAS70. Because employee buy-in was essential for success, we needed to ensure all MediClick employees thoroughly understood the purposes of the audit process and what their roles would be. We held internal meetings with all the employees to explain the process and the importance of the audit to MediClick. This was a significant moment in our auditing process because we could see how the employees would react to the audit. It was a success! No one revolted as we had been warned would happen! In fact, just the opposite occurred: acceptance and enthusiasm.

After completing the remediation tasks and employee orientation, we were ready for the second engagement. Our actual audit period was from July 1, 2008, through Dec. 31, 2008. Our first official SAS70 audit would cover a 6-month time period. Then we would have an audit done for each subsequent 12-month cycle.

Two auditors were on site for two weeks during the month of December 2008, pouring through our system logs, documents and development processes. They held interviews with each department manager to review controls and operational procedures. The auditors observed MediClick personnel in their daily activities, looking at such detail as how well they enforced visitor sign-in protocol at the front entrance to our office. The auditors left with tons of data to review.

Even though we successfully navigated the readiness assessment, we held our collective breaths as we waited several weeks for the preliminary findings. Would we experience any of the doomsday scenarios my industry colleagues had painted in my head?

The results were in and we did it! Our first audit was clean and all tests of control objectives showed no relevant exceptions. The final report was delivered in January 2009 and immediately sent out to a backlog of customers who had requested the report.

Despite the tales of woe that we had heard, we had learned for ourselves how to successfully navigate the SAS70 audit process.

Next is The Lord of the Audits Trilogy, Part 3: The Return of Art. In this segment I will reflect on my views on what it takes for a successful audit, what are the critical areas you need to review when receiving a SAS70 Type 2 audit and the future of the SAS70 audit.

The Lord of the Audits Trilogy, Part 1: The Fellowship of the IT Executives

“Be prepared to lose half of your developers! They’re not gonna tolerate all the controls, checks and balances getting in the way of coding and implementing your applications. I know this for a fact because it happened at my own shop.”

That was the advice I received from a fellow IT executive while discussing a SAS70 Type 2 audit at a meeting on IT governances. At the time, the company he worked for had already undergone the audit, which MediClick was considering. The process involved a complete, independent review of his company’s controls and operations, ending in a published report assessing the effectiveness of those controls.

The executive offered his cautionary tale about SAS70 in late 2007 during a Triangle Technology Executive Council (TTEC) meeting in North Carolina’s Research Triangle Park. Now with a membership of more than 100 senior IT executives from over 100 companies, TTEC included only a dozen or so executives at the time MediClick was considering SAS70.

I sought the wisdom of these IT executives because we were experiencing an increased demand for MediClick to become SAS70 compliant, something we purposely put on the back burner. Why? Because we were concerned that our own SAS70 audit would be cost prohibitive for a company of our size and that it would slow our development process to a crawl.

A bit of company history may put our SAS70 dilemma into perspective.

Formed in 2000, executives wanted MediClick to be an Application Service Provider (now referred to as SaaS) for healthcare. We saw a need to advance the industry beyond the traditional software solutions our larger competitors were putting on the market.

Our success depended on our ability to deploy our application quickly and effectively. We had to be lean and mean, which meant employing rapid development methodologies and a hosting site for our software.

Fast forward seven years, we met these obligations and became a successful SaaS company. It was then when our hospital customers began requesting that we become SAS70 compliant. Before we could do that, though, we had to be careful not to change the positive impact we were having on our customers.

“MediClick’s customer support is very helpful. If we have problems, they log on and solve them. They get back to us fairly quickly.”

“MediClick has a sprint process for enhancements instead of doing a rebuild each year. Every eight weeks they do one of these small builds and get things fixed. I have never seen a company be so efficient.”

Published by an independent organization that evaluates healthcare companies, these quotes reaffirm our commitment to efficiency and customer service. We were – and still are – a more nimble software company. We were afraid a SAS70 audit would change that.

For one, we expected that an audit would flag us when our support team signed on to the customer’s application to resolve issues. The SaaS model made this easy because we could access the application via the Internet. Unfortunately, all MediClick personnel used a single sign on to the databases. That was a no-no for SAS70 as it left no audit trail that documented what a particular MediClick support person did.

While those sign-on issues were a top priority, protecting our development methodology became a main concern. Since we had introduced the tenets of agile development and abandoned the standard 12 to 18 month release model, our customers were used to seeing our enhancements every 6 to 8 weeks.

For seven years, we had been fine tuning our process so we could effectively deliver value to our customers. We questioned whether a SAS70 audit would set up road blocks and cause us to lose our competitive edge. Would it frustrate developers resulting in a mass migration to the exit doors? Would we have to revert back to a long release cycle? These questions resulted in many sleepless nights.

So why did we choose the route that my peer advised me against?

First, we wanted to give our customers what they wanted. Plus, as we met more and more industry prospects asking for our SAS70 validation, it became apparent that MediClick would have to take the SAS70 plunge sooner rather than later.

So late in 2007 the decision was made; there was no turning back. We would attack this problem as MediClick has always responded to a challenge: jump into the SAS70 waters with enthusiasm to get the job done completely and correctly. Failure was not an option.

The most difficult part was determining where you start the SAS70 process. How prepared were we? Were there other vulnerabilities we were not aware of? Would there be a potential for a poor report and how would that affect our business?

The storm clouds formed over the horizon and the Dark Lords of the invidious auditors began their approach.

Next is The Lord of the Audits Trilogy, Part 2 – The Two Engagements.