This isn’t just happening in the world of publishing, but also in the real world.  Over the past twelve months, I’ve received a number of requests from clients to have SAS 70 Type II audits completed.  And that’s just the tip of the iceberg.  From what I’m seeing, compliance is one of the most important contemporary issues that is being addressed and considered.

 The real question is, “What measures are important and how best to implement those measures?”   The next important question, especially with regard to colocation contracts, is, “What and how should this be addressed in a Service Level Agreement?”

 There are compliance guidelines and directives for every different business sector and in general including:

• Sarbanes-Oxley;
• Service Organizations Controls (formerly SAS 70);
• Basel II and III;
• PCI/DSS;
• HITEC & HIPAA;
• TIA 942;
• NYSE Rule 446;
• NASD Rule 3510;
• Check 21, and many others.

 A Little History…

In December 2009, the International Auditing and Assurance Standards Board (IAASB) issued new International Standards on Assurance Engagements (ISAE) 3402 replacing the prior standard, SAS 70 and subsequently issuing SSAE Number 16 for reporting on controls at a service organization.  This represented the first significant change to the AICPA standards since SAS 70 was originally issued in 1992.  There are now three different Service Organization Control reports (SOC 1, 2 & 3) that have supplanted the SAS 70 and SSAE 16 (which now falls under SOC 1).  Included under the SAS 70 standard was service auditor guidance, user auditor guidance for the purpose of reporting on controls for financial services audits.  There seemed to be a high occurrence of misinterpreting SAS 70 reports as a means to obtain assurance regarding controls over compliance and operations.   Separately offered were Trust Services Principles and Criteria that included security, availability, processing integrity, confidentiality and privacy.  All of this has now been reorganized under:

• The SOC 1 includes SSAE 16 (service auditor guidance), Restricted User Report (Type I or II) for the purpose of reporting on controls for financial service audits. SOC 1 reports are tailored to address controls at an organization that provides services to user entities when those controls are likely to be relevant to user entities’ internal control over financial reporting;

• The SOC 2 includes Attest Engagements 101 (AT 101) to assist CPAs in reporting on the effectiveness of a service organization’s controls related to operations compliance.  This combines Trust Services criteria with the reporting detail of SSAE 16.  Also included is a generally restricted use report (Type I or II) for the purpose of reporting on controls related to compliance or operations.  SOC 2 reports are meant to address security, availability, processing integrity, confidentiality and privacy.  This report is perfectly applied to the SaaS or cloud provider that wishes to assuage the concerns or its customers that the service organization maintains the confidentiality of its customers’ information in a secure manner and that the information will be available when it is needed; and

• SOC 3, which, similarly to SOC 2, includes AT 101 plus a general use report with a public seal for the purpose of reporting on controls related to compliance or operations.  The SOC 3 report is designed for companies that use a business partner to perform part of its operations for selling goods via the Internet and want reassurance that such transactions occur in a private and secure environment.

As important as it is to audit processes and procedures, the implementation of security measures is where the rubber meets the road.  This is exemplified in Payment Card Industry (PCI) Compliance.  This standard not only relates to hardening the security perimeter, but also creating a secure interior set of requirements that prevent insider security breaches.  According to recent white paper written by Sumner Blount for CA Technologies, PCI compliance can be achieved by adhering to six steps:

1)      Build and maintain a secure network. This requires installing and maintaining a firewall configuration to protect data as well as creating custom system passwords and other security parameters;

2)      Protect customer data.  The imperative is to protect all stored data and encrypt transmission of that data and other sensitive information across public networks;

3)      Maintain a vulnerability management program.  This requires that anti-virus software is used and regularly updated.  Development and maintenance of secure systems and applications is a must;

4)      Implement strong access control measures.  Access to data is restricted based on a need-to-know, unique IDs are assigned to each person with computer system access and physical access to data is restricted;

5)      Regularly monitor and test networks.  Without tracking, monitoring and testing access to network resources, data, systems and processes, there is no accountability model;

6)      Maintain an information security policy.  Your policy must address information security first and foremost.

Application to the Service Level Agreement

This will certainly be determined by the type of space or services being rendered by the provider.  In the case of a powered shell, the degree of security will be limited to physical measures and facility availability while in the case of managed services, or private cloud services, those measures should be significantly extended.  In many cases, service providers will not directly monitor or secure any equipment that it doesn’t own or operate.  Network availability and uptime of the data center can and must be protected and there should be a 100% guarantee of backbone network uptime as well as other services delivered such as power.  Other measures of latency and packet loss should also have measurable standards of reliability and security procedures are certainly applicable in this case.

Conclusion

Using the PCI Compliance model as an overly and then auditing the IT landscape with the preparation of a SOC report goes a long way toward building a secure environment.  Of course, other compliance requirements that are industry-specific will be a necessity, but by implementing these two aforementioned steps, the process will be considerably streamlined.