“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.
Comments