Mitigating SAS70 Requirements 2420



  • Our External Auditors are hung up on us having SAS 70 agreements with all our vendors, AND that the ‘User Controls’ are well defined to govern the interactions between the vendors and us in IT.
    Some of our vendors don’t have SAS 70 agreements, and fewer still have the User Controls well defined for us to review.
    What are some things we may be able to do internally to mitigate the risk associated with this? I’d like to think that as long as we clearly define who on our side is the contact with that vendor, and what our and their responsibilities are, we should be in decent shape.



  • Hi and welcome to the forums 🙂
    We’re also a SAS 70 compliant firm. While the external auditors have good intentions, I agree that software firm SAS compliancy agreements aren’t the answer.
    Software vendors can only ‘advertise’ that they are compliant. Just because someone rates a product as SAS 70 compliant, won’t mean it’ll achieve that goal in the real world. It’s still based on how it’s rolled out, user controls, security, etc.
    Some software products will be more compliant with SAS 70 compliancy needs out-of-the-box than others. They may have a better security design or they may be designed around the standards themselves.
    It’s up to the company implementing these service oriented standards to achieve compliancy, whether it’s with physical security, software, or standards and procedures. Most likely the key to solving these issues are as follows:

    1. Inventory all major software products
    2. Document work flows and control points
    3. Perform risk and control design analysis of each (with help of Internal Audit or other ‘neutral’ entities)
    4. Where you have vendors that are rated as compliant, this can be documented as a plus
    5. Where vendors don’t have the agreement in place, ensure the product and it’s surrounding controls are in a SAS 70 compliant framework (e.g., proper checks-and-balances, automony controls, etc)
      I’ve always found Wikipedia to provide some good summaries and links, and this might also help in the research:
      http://en.wikipedia.org/wiki/SAS_70


  • Thanks Harry.
    If we were to implement a policy whereby we define our interactions with each vendor, how far would that take us?
    This information would include which email addresses they send notifications to, who they call if anything comes up, who the contact people are on the vendor’s side, etc.
    Thanks again.



  • Yes, what you’ve shared is a good idea 🙂
    I’d suggest documenting each vendor’s position on SAS-70 compliancy in an e-library and keeping this on file.
    It might include the following for each vendor:
    – General information on the vendor (e.g., contacts, support web pages, name and address, etc)
    – SAS-70 statement of compliancy (e.g., those vendors who rate their software as being compliant, or any capturing any special agreements you may specifically have on file)
    – SAS-70 documentation of any non-compliant areas or issues
    – Workarounds or special procedures implemented to achieve SAS-70 compliancy for the business application.


Log in to reply