Who do you report to?
The COO [chief operating officer]. We don't have a dedicated CIO role right now; our CTO is largely performing that function. However, my boss is a former CIO. The CTO and I report to the COO. What percentage of your job is spent working on compliance regulations?
In 2004, I spent approximately 40% of my time on compliance. Things really fired up in 2004. When I came on board, compliance activities had been building for at least the last 12 months. I was originally hired NOT to do compliance directly. I was to handle the security aspects of compliance only. Then last fall, my boss asked for me to become corporate compliance officer, in addition to my role as CSO. So now I'm involved with other compliance issues. There was no single, executive-level focal point before I took it over. Prior to that, each business unit would identify their issues and address compliance at their own levels. Do you have any other staff dedicated to compliance?
I have one full-time coordinator and two part-time coordinators working on compliance. We also involve the appropriate business people. The full-time coordinator is a temporary position, ending later this year (2005). Then we'll be relying upon the part-time positions to provide program coordination and help the individual contributors when they have problems. The full-time temporary person was needed initially to get the program on its feet. What compliance regulations have you had to comply with in the past year? Which were the most challenging?
In 2004, our emphasis was on two areas. First with Visa. Visa has a cardholder information security program. We had to demonstrate compliance with that. Most people might not consider Visa compliance as a big deal compared with SOX [Sarbanes-Oxley] or GLBA [Gramm-Leach-Bliley Act] -- but it was important to our organization. There were real consequences if we didn't meet their test -- they could revoke our right to process Visa transactions. Visa has to approve anyone that wants to process transactions. This security program is a big strategic initiative for them. It also includes a lot of risk for us -- considering we could lose a huge revenue stream.
The other big regulation challenge in 2004 was getting our SAS 70 Type 2 compliance report. We needed to get this report for our customers -- all financial institutions. SAS 70 is a third-party attestation, a common instrument used when two parties work closely together and they want to make sure the other is doing what they're contractually obligated to do. When a bank outsources work to a vendor, examining the SAS 70 report is typically part of the financial institution's risk management program. The banks will look for certain controls in the vendor's organization.
It's an annual event for us; 2004 was our first one. Industry-wide, the increased emphasis on SAS 70, which has been around for quite some time now, has developed as a direct result of increased regulatory pressure on financial institutions. Financial institutions need to demonstrate good risk management practices when they are working with particular vendors or service providers. It's a reality for any financial institution because almost all of them outsource some aspect of their IT or tech operations, thus placing customer date at risk. You're not a publicly traded company, so you didn't have to meet the SOX deadline. But do you have to meet any of the guidelines indirectly since you work with mostly publicly traded companies?
We have decided to adopt various aspects of the SOX requirements. We think it's just a matter of good business practice. We're currently analyzing now which practices we should adopt and how and when to do it. Most business leaders would probably tell you that if you're a company today that's not subject to SOX or other major regulations, it's just a matter of time before you will be. Eventually, I believe the government will extend these requirements to nonpublic institutions. All of your customers are financial institutions. Is there even more pressure from them for you to be 100% compliant at all time?
Yes. Since we only serve financial institutions, we are getting increased pressure. I believe there are two specific reasons. First, the auditors themselves are getting more sophisticated on how they evaluate financial institutions. Secondly, the regulations are getting much more strict. As most people know, it's a common practice among financial institutions to outsource some or all of their IT to TSPs [technology service providers]. The regulators have guidelines that tell financial institutions how they should manage TSPs. One specific requirement is that financial institutions can not outsource risk management.
Banks in the past have tended to implicitly outsource risk management along with the systems. Regulators are now demanding that financial institutions prove they are actively conducting risk management on any technology outsourcing contracts. One thing we try to do is recognize what the burden is on the customer. From the auditors -- we try to deliver our services in a way that they meet that burden of proof. We see a lot of the compliance work we do on behalf of our customers as a way to differentiate ourselves in the market. Do you send any work offshore? If so, is compliance an issue when working with an offshore customer or partner?
We don't send work offshore. We have customers who do that, though. We try to work with our customers on how to manage their risk with offshore partners. For example, we perform a certain amount of systems monitoring and forward anything we find to our customers. I'll give you a specific problem for which there is no easy answer: We bond all of our staff which requires a certain amount of background checking, which is fairly straightforward in the U.S. When a customer of ours is doing business with an offshore partner, our customer typically will want to perform similar background checks. However, it's not always clear how to do that with people overseas. It's usually an issue of how do you find a level of scrutiny that's equivalent to a check you've done with a U.S. worker. But, how does that work in India or wherever your offshore partner happens to be? What's considered to be equivalent? Have you been audited for any compliance regulations? If so, did they uncover any issues?
Yes, we largely have had customers auditing us. In 2004, we had no less than 10 external audits. We also had six internal audits.
Issues have come up, but nothing I consider to be serious. One example is we had some faulty maintenance performed on an exterior door to our building. When the auditor was checking our physical perimeter, they found the door didn't close completely all the time. Even though that door provided no direct access to a protected area, the incident was noted in the report and we did a follow-up with the maintenance group to explain how important this issue was.
Some of our time and effort working with external auditors is spent working with auditors to help them interpret the regulations for our specific context. These regulations are very complex themselves. Issues brought up by the auditors are often matters of interpretation. We sometimes have to point out to the auditors that there isn't an issue and why -- typically because we have a different control or other compensating controls. But in the end, if the auditor is insistent, we will usually accept the issue and make the necessary changes for the customers. However, there have never been any real show stoppers. Does the business side fully support any efforts and spending for compliance? Do they realize the value and importance of these initiatives?
Yes, for us it's very obvious. There's a clear connection between compliance and business success. We have no problems with having the business recognize the value of compliance. However, because there is so much compliance that needs to be done, the business often has a difficult time prioritizing what needs to get done. I read that you have an off-site business continuity and disaster recovery site in Colorado. I assume DR/BC [Disaster Recovery/Business Continuance] plans are essential to the success of compliance regulations. Is that correct? Did you have this site set up before many of the regulations and auditors starting coming out?
There are several compliance initiatives that officially told us we had to have this; VISA CISP, for example. Even so, the reason we have DR/BC is that the business recognizes that the money spent today to ensure business continuity will pay off. You're talking about companies [our customers] that if they're not able to process transactions, the revenue loss for them could be astounding, much more than they are paying for the DR/BC plans. Therefore, the first priority is how to prevent loss of revenue. I think compliance issues are also addressed in there, but ensuring continuous revenue is our No. 1 goal here. Do new customers ask about your compliance plans or situation? Is it as important to them?
We make sure our compliance goals are included in our initial marketing pitches -- we state we're very in-tuned with their compliance needs. In some cases we're more aware of their compliance regulations than they are. On their side, there's an initial line of questions about whether we're compliant -- basically to make sure we're credible. Most of the customer's effort then moves to making sure we can deliver on their technological goals and that we come in at a good price point. Once they know we're viable -- they'll do more due diligence on us. My point is that they're interested in our compliance efforts, but it's not their No. 1 priority. They want to make sure we can deliver the service first.