GLBA

GLBA and Data Centers | Tips for Compliance

GLBA Privacy Rule
Protecting the privacy of consumer information held by “financial institutions” and other third party vendors and service providers that provide “support services” to these “financial institutions” is at the heart of the financial privacy provisions of the Gramm-Leach-Bliley Financial Modernization Act of 1999. The GLB Act requires companies to give consumers privacy notices that explain the institutions’ information-sharing practices. In turn, consumers have the right to limit some - but not all - sharing of their information.

The GLB Act applies to “financial institutions” and other third party vendors and service providers; companies that offer and support financial products or services to individuals, like loans, financial or investment advice, or insurance. The Federal Trade Commission has authority to enforce the law with respect to “financial institutions” that are not covered by the federal banking agencies, the Securities and Exchange Commission, the Commodity Futures Trading Commission, and state insurance authorities. Among the institutions that fall under FTC jurisdiction for purposes of the GLB Act are non-bank mortgage lenders, loan brokers, some financial or investment advisers, tax preparers, providers of real estate settlement services, and debt collectors. At the same time, the FTC’s regulation applies only to companies that are “significantly engaged” in such financial activities, such as DATA CENTERS.

The law requires that financial institutions protect information collected about individuals; it does not apply to information collected in business or commercial activities.

Consumers and Customers
A company’s obligations under the GLB Act depend on whether the company has consumers or customers who obtain its services. A consumer is an individual who obtains or has obtained a financial product or service from a financial institution for personal, family or household reasons. A customer is a consumer with a continuing relationship with a financial institution. Generally, if the relationship between the financial institution and the individual is significant and/or long-term, the individual is a customer of the institution. For example, a person who gets a mortgage from a lender or hires a broker to get a personal loan is considered a customer of the lender or the broker, while a person who uses a check-cashing service is a consumer of that service.

Thus, in short data centers may very well be called upon to become GLBA compliant via an audit or assessment process. My advice, find a competent SAS 70 auditor who can help incorporate GLBA tests into a SAS 70 or find a competent GLBA auditor.

GLBA, HIPAA, SAS 70, PCI DSS | what is next for Compliance?

The trend of late has been Payment Card Industry (PCI) Data Security Standards (DSS) compliance, along with a continued emphasis on the well known SAS 70 auditing standard. And occasionally, calls for GLBA and HIPAA compliance come calling also. As an auditor for many years, I’m often asked to look into the crystal ball of compliance and give my prescient thoughts and answers.

First and foremost, the requirements for SAS 70 Type II audit and PCI DSS assessment compliance will continue to grow larger; larger in scope regarding the actual requirements and larger in the number of companies having to comply. Data breaches are occurring at a feverish pace, causing great unrest for all participants involved. And add to the notion of the continued importance of corporate governance, regulatory compliance and security, and it becomes quite evident that SAS 70 and PCI will play a critical role for many years.

Additionally, more and more states will start to adopt various provisions of the PCI DSS requirements, turning them into an actual codification of laws for their respective states. Minnesota became that first state with the MN Plastic Card Security Act, followed by Nevada and a host of other states who are seriously looking to an adoption of PCI into law.

As for GLBA and HIPAA, they will more than likely continue to “limp” along as they simply lack the regulatory “teeth” that SAS 70 and PCI have. This may change if the SEC and The Department of Health and Human Services give HIPAA and GLBA more explicit requirements on compliance, but this is highly doubtful.

If you want to learn more about compliance, visit the SAS 70 Resource Guide and the PCI DSS Resource Guide.

California Security Breach Information Act (SB-1386) | What You Need to Know.

In short, the California Security Breach Information Act (SB-1386) is a California state law requiring organizations that maintain personal information about individuals to inform those individuals if the security of their information has been breached or compromised. thus, the Act stipulates that if there’s a security breach of a database containing personal data, the responsible entity must notify each and every individual for whom it maintained the information for. The Act, which went into effect July 1, 2003, was created to help stem the alarming growth of identity theft, which has many consumers on the edge and frightened concerning the protection of their personal data.

Here’s what’s important to grasp for a regulatory compliance aspect. The California SB-1386 is a trend that is sweeping the nation and will only continue to grow as concerns for the security of confidential information become more paramount. Gov. Tim Pawlenty signed the MN Plastic Card Security Act, essentially codifying parts of the Payment Card Industry Data Security Standards (PCI DSSS) into law.

Auditors need to be aware of these rules and regulations and their overall impact they can have on an audit, be a SAS 70 audit, HIPAA or GLBA audit or even a PCI DSS Assessment.

SAS 70 Type II Audit Reports | Why SAS 70 is Here to Stay

We live in a world of heightened regulatory compliance and corporate governance. From the passage of the 2002 Sarbanes-Oxley Act to numerous other pieces of legislation (HIPAA, GLBA, just to name a few), “comply, comply, comply” is the new mantra being pushed throughout organizations and at all levels. SAS 70 audits, originally introduced as the 70th auditing standard in April of 1992, has stood the test of time as the main “go to” compliance audit for many of these regulatory requirements that have ushered from the halls of Congress.

Okay, so, why is it here to stay? Well, for a number of reasons. First and foremost, it will always be used as an audit tool for evaluating service organization’s that could have a material impact to a company’s “information system”-This term, “information system” is used to describe the user organization’s “information system”, that is, what services are being performed by the service organization that are considered a part of the user organization’s “information system”. Transactions, procedures (be it manual or automated), supporting information, the capturing of events and conditions-are all considered traits and activities that relate to, have an effect, and impact the user organization’s “information system”.

Second, the SAS 70 auditing standard has been quite flexible, adapting to the needs of service organizations that must have their control environment examined. Witness the numerous times the SAS 70 auditing standard has been amended over the last 16 years to keep “pace” with the changes of business.

Third, the SAS 70 auditing standard has become very quickly recognized as the global de facto audit for internal controls on service organizations. In short, it has built up quite a following that is simply very hard to ignore.

To learn more about SAS 70 audits, visit the official SAS 70 Resource Guide.

SAS70 & PCI Compliance | Creating Audit Efficiencies

SAS70 audits have grown tremendously in the past five years, largely due in part to the explosive growth of federal regulatory compliance laws and legislation. Interestingly also, Payment Card Industry (PCI) compliance has also received much attention as of recent, particularly with the recent breaches of security in a number of well publicized cases.

I’m often asked by organizations that have to be SAS70 & PCI compliant if these two audits can be a 2 for 1, that is, can I conduct SAS70 fieldwork and also hopefully piggyback off of that work to help augment a marginal part of the PCI compliance examination for QSA?

There are synergies that can be created, allowing an experienced auditor to use his or her best judgment for creating these synergies. If you look at the 12 core areas of the PCI compliance, you can extract elements from these very requirements that would most surely be included in a good, quality comprehensive SAS70 audit. I stress “good, quality” audit because the looseness of the SAS70 standard allows auditors to employ vastly different methodologies.

For example, PCI Requirement #9, “Restricting Physical Access to Cardholder Data” could be argued that this is very much in line with a common SAS70 control objective for “Physical Security”. Remember this, there are only so many regulatory compliance and governance laws that can be pushed forward before they start to become overlapping and redundant to a certain degree.

If you can find a quality firm that does both SAS70 auditing and PCI QSA compliance, then it would be most beneficial to create these synergies for the audit.

One of the most valuable tools I recently created was a SAS70 & PCI Gap analysis, showing you the overlapping features of both audits, allowing any firm to create these very efficiencies for these compliance examinations.

For more information on SAS70 audits, or to receive SAS70 sample reports, please visit the official SAS70 resource center