Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 4 down vote favorite

From what I have read and known, SEC compliance is quite vague. It is best to be addressed in a strong manner, but when it comes to hosting in third-parties, the only way for you to prove their compliance is via audits.

Since there are no concrete rules (ex: "all third parties must be SAS 70 compliant"), what serves as acceptable? Does "SAS 70 Type II" compliance serve as acceptable? If not, what are some recommendations for dealing with third parties?

Since I know stackexchange hates vague questions, what other audits are proof that third parties are "compliant solutions?"

Thanks,

Matt

share|improve this question
2  
It isn't clear what you mean by "SEC compliant". Is there a specific rule, regulation, or requirement from the SEC that you're concerned with satisfying? There's a slew of legislation, rules, and regulations that might be considered SEC compliance issues - see sec.gov/about/laws.shtml - but just saying "SEC compliance" doesn't tell me anything. – gowenfawr Sep 20 '11 at 15:30
That's completely and totally true. I suppose we are concerned with rule 204-2, but there are some modifications that only apply to broker/dealers, specifically the need for WORM storage when dealing with electronic information records. Basically, compliance is to err on the side of caution. There is no black and white answer here; so better safe than sorry. Generally stated, it seems: "make it so that the smallest quantity of questions are asked about your procedures." Tried-and-true. – mbrownnyc Sep 20 '11 at 20:04

2 Answers

up vote 4 down vote

SAS-70 (including Type II) is not a certification standard. It's a statement of what you claim to do, coupled with an attestation by an auditor that you do what you say. You have incredibly wide flexibility to define exactly what it is that you do, so no two SAS-70's are exactly alike. I don't know which SEC rules you're referring to, but SAS-70's are in any case not a precisely defined certification, so they're hard to compare with anything else.

share|improve this answer
Thanks for the response. I suppose the problem I seem to be coming across while working with my compliance team is that everything single thing seems to be completely vague. It seems to have come down to a "risk-assessment" or I'll just describe in layman's terms, "opinion." – mbrownnyc Sep 20 '11 at 20:00
up vote 3 down vote

SAS-70 reports are designed to show that an auditor has seen that the company in review performs certain actions that the company under review enumerates. One example that we use around here to demonstrate the nature of a SAS-70 is that we could review a requirement that, "All our trashcans are round."

When you outsource a function that is critical to your business, you are often still responsible for that function. A SAS-70 shows that certain controls are in place at your service provider. Hopefully the person receiving the report from their service provider has reviewed the report to ensure that those controls are sensible.

Remember that for a SAS-70, the client enumerates their controls and whether they really make sense or for a particular business need is not a part of the review. What you want to see is a Type-II (controls in place for the entire testing period) and you want to make sure that you feel those controls are effective.

While we're at it, the as we know it SAS-70 is dead as of this year. In the future, you're looking for SOC-1, SOC-2, or SOC-3 reports. See http://www.ssae16.org/ssae-16-reporting/aicpa-soc-reporting-framework.html

share|improve this answer
Thanks for the info on the SOC audits. I'll check them out. – mbrownnyc Sep 21 '11 at 1:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.