Regulatory Compliance Standards


Statement on Auditing Standards (SAS) No. 70, Service Organizations, is a widely recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA).

A service auditor's examination performed in accordance with SAS No. 70 (also commonly referred to as a "SAS 70 Audit") is widely recognized, because it represents that a service organization has been through an in-depth audit of their control objectives and control activities, which often include controls over information technology and related processes.

In today's global economy, service organizations or service providers must demonstrate that they have adequate controls and safeguards when they host or process data belonging to their customers. In addition, the requirements of Section 404 of the Sarbanes-Oxley Act of 2002 make SAS 70 audit reports even more important to the process of reporting on the effectiveness of internal control over financial reporting.


The report issued by an auditor following an SSAE 16 audit (be it a Type 1 or Type 2 report) is officially known as a Service Organization Control 1 ("SOC1") Report.

While SSAE 16 makes some adjustments to the content of the auditor's report, it effectively remains, like SAS 70, an audit of the service provider's internal controls against the service provider's control objectives and does not provide an objective standard by which such controls may be measured.

If a customer is looking for a service provider's security controls to meet objective standards, then it may wish to impose a requirement that the service provider is audited to the AICPA's Service Organization Control 2 ("SOC2") and Service Organization Control 3 ("SOC3") standards.

Unlike an SSAE 16 SOC1 audit, where the service provider identifies the objectives against which it is audited, both the SOC2 and SOC3 audits require a service provider to provide assurance about whether its internal controls relating to security, availability, processing integrity, confidentiality and the privacy of its system and information meet pre-defined AICPA Trust Services principles and criteria.

SOC2 and SOC3 reports provide the same level of assurance, however the SOC3 report does not contain a detailed description of the testing carried out by an auditor and can therefore be freely distributed or posted on a website as a seal. SOC3 should therefore become the objective certification standard for service providers storing customer data that SAS 70 has misleadingly been portrayed as.


Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM and POS cards.

Defined by the Payment Card Industry Security Standards Council, the standard was created to increase controls around cardholder data to reduce credit card fraud via its exposure. Validation of compliance is done annually by an external Qualified Security Assessor (QSA) for organizations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes.


The Gramm-Leach-Bliley Act requires financial institutions—companies that offer consumers financial products or services like loans, financial or investment advice, or insurance—to explain their information-sharing practices to their customers and to safeguard sensitive data.


Websites that are collecting information from children under the age of thirteen are required to comply with the
Federal Trade Commission (FTC) Children's Online Privacy Protection Act (COPPA).

ISO 27002

The ISO 27002 standard is the rename of the ISO 17799 standard, and is a code of practice for information security. It basically outlines hundreds of potential controls and control mechanisms, which may be implemented, in theory, subject to the guidance provided within ISO 27001.

The standard "established guidelines and general principles for initiating, implementing, maintaining, and improving information security management within an organization."

The actual controls listed in the standard are intended to address the specific requirements identified via a formal risk assessment. The standard is also intended to provide a guide for the development of "organizational security standards and effective security management practices and to help build confidence in inter-organizational activities."


The Health Information Trust Alliance, or HITRUST, in collaboration with healthcare, technology and information security leaders, has established the Common Security Framework (CSF), a certifiable framework that can be used by any and all organizations that create, access, store or exchange personal health and financial information. The most widely adopted security control framework in the U.S. healthcare industry, the CSF includes a prescriptive set of controls and supporting requirements that clearly define how organizations meet the objectives of the framework.

The HITRUST Common Security Framework (CSF) is a framework that normalizes the security requirements of healthcare organizations including federal (e.g., ARRA and HIPAA), state (Mass.), third party (e.g., PCI and COBIT) and government (e.g., NIST, FTC and CMS). The CSF is not a new standard; this is a misconception. The CSF supplements the existing controls with the industry knowledge and leading practices of HITRUST's community and provides the clarity and consistency lacking in many standards and regulations.


Privacy Rule

The effective compliance date of the Privacy Rule was April 14, 2003, with a one-year extension for certain "small plans."

The HIPAA Privacy Rule regulates the use and disclosure of Protected Health Information (PHI) held by "covered entities" (generally, health care clearinghouses, employer sponsored health plans, health insurers, and medical service providers that engage in certain transactions.

By regulation, the Department of Health and Human Services (DHHS) extended the HIPAA privacy rule to independent contractors of covered entities who fit within the definition of "business associate."

PHI is any information held by a covered entity that concerns health status, provision of health care, or payment for health care that can be linked to an individual. This is interpreted rather broadly and includes any part of an individual's medical record or payment history.

Covered entities must disclose PHI to the individual within 30 days upon request. They also must disclose PHI when required to do so by law, such as reporting suspected child abuse to state child welfare agencies.

A covered entity may disclose PHI to facilitate treatment, payment, or health care operations, or if the covered entity has obtained authorization from the individual. However, when a covered entity discloses any PHI, it must make a reasonable effort to disclose only the minimum necessary information required to achieve its purpose.

The Privacy Rule gives individuals the right to request that a covered entity correct any inaccurate PHI. It also requires covered entities to take reasonable steps to ensure the confidentiality of communications with individuals. For example, an individual can ask to be called at his or her work number, instead of home or cell phone number.

The Privacy Rule requires covered entities to notify individuals of uses of their PHI. Covered entities must also keep track of disclosures of PHI and document privacy policies and procedures. They must appoint a Privacy Official and a contact person responsible for receiving complaints and train all members of their workforce in procedures regarding PHI.

An individual who believes that the Privacy Rule is not being upheld can file a complaint with the Department of Health and Human Services Office for Civil Rights (OCR). However, according to the Wall Street Journal, the OCR has a long backlog and ignores most complaints. "Complaints of privacy violations have been piling up at the Department of Health and Human Services. Between April of 2003 and November of 2006, the agency fielded 23,886 complaints related to medical-privacy rules, but it has not yet taken any enforcement actions against hospitals, doctors, insurers or anyone else for rule violations. A spokesman for the agency says it has closed three-quarters of the complaints, typically because it found no violation or provided informal guidance to the parties involved."

However, in July 2011, UCLA agreed to pay $865,500 in a settlement regarding potential HIPAA violations. An HHS Office for Civil Rights investigation showed from 2005 to 2008 unauthorized employees, repeatedly and without legitimate cause, looked at the electronic protected health information of numerous UCLAHS patients.