NetSPI Blog

Is your Compliance Driven by More Than an Audit?

Seth Peter
July 14th, 2009

Preparing for an audit can be one of the best ways to fund and improve your security program, but this “stimulus package” for your compliance effort typically dwindles once an organization completes or passes an audit. I see this happen frequently in recurring or annual audits, but it is particularly relevant with the recent news of Merrick Bank. Specifically, Merrick Bank is suing Savvis for certifying CardSystems Solutions to be Visa CISP compliant prior to a breach that exposed some 40 million payment card records and resulted in $16 million in fines to the card brands. While this is the not the first breach of a PCI-audited company, it is the first one in which the auditor has been sued. The case raises an important question: Who is ultimately responsible for ensuring that a good security program is in place? Here are some simple, yet critical, points to ensure your security program is driven by something more than the audit itself.

  1. Understand the role of the auditor. When preparing or undergoing an information security audit, it’s critical for organizations to consider the role the auditor performs within a security program. This role should never be a member of your security team or a designer/implementer of your security systems; it must be strictly be a reviewer of your security state at a point in time. While some coaching and direction can be good, all decisions and program enhancements must be driven by the organization itself.
  2. An audit is not a design session. If your security program design is heavily based on the initial audit gap report, your program will not be sustainable. Although you and your auditor share the same goal, ensuring you are compliant, your auditor’s coaching will be targeted on one thing—meeting a specific requirement. Your program will then also be designed merely to meet the standard and not take into consideration sustainability, holistic approaches, and integration with existing business requirements.
  3. If you are not 100% ready for the audit, you should not be audited. Because an audit is intended strictly to be an independent review of the security program, if your organization does not feel it can meet all aspects of the audit, you should fix it first. Don’t consider your audit a pass/fail game between you and your auditor. That is not the point of being measured, nor is it a best practice. Plus, any audit that is worth something requires a joint attestation by you and your auditor; if you can’t sign off on it, neither should the auditor.
  4. Aim higher than the compliance requirements alone. Information security is one of those areas where going above and beyond the call of duty can be a good thing. Compliance requirements are meant to be the minimum standard by which you are allowed to operate; strive to exceed them. Don’t budget based on just meeting the requirement, but budget based on what you think is required for your organization to manage risk effectively. Yes, that’s risk, not compliance.

As an information security auditor and advisor, I have seen numerous organizations pour budget and resources into a compliance initiative and then literally stop everything after an audit has been conducted. By conveying the importance of building a program based on security that meets compliance, an organization will be better prepared to defend against breaches and satisfy its auditor at the same time.


Comments are closed.