Regulatory Requirements and Audit – Bonney

Screen Shot 2016-08-14 at 1.34.37 PM

In the first chapter, I talk a little about regulatory oversight. I point out, for instance, that in the overall scheme of information security, regulatory requirements are really cover charges. I also noted that typically, in mature organizations with well-known or substantial regulatory requirements, corporate governance would be structured to comply with mandatory management oversight obligations. To be clear, I believe that regulations and compliance requirements mandate minimum standards of due care.

The reality is that while regulatory and compliance requirements do not in and of themselves keep your data secure, they are obligatory, with the specifics depending on industry, locale, and organizational structure. But, truth be told, despite the disdain that many hold for compliance activities and requirements, they can often be leveraged as a foundation for a good information security program.

In this chapter, I will expand on some of those thoughts and talk about setting up your program for regulatory success, leveraging that foundation for successful governance, and engaging with your internal and external audit teams as key partners in your governance program. I will take the questions for this chapter in order. What are my regulatory requirements? How do I set up my program for success? And how do I engage my auditors and regulators?

How Do I Know What My Regulatory Requirements Are?

That brings us to the first question I am going to address: how do I know what my regulatory requirements are? I’m going to take an expansive view of this. By expansive, I mean I’ll consider a wider range of compliance regimes that aren’t all strictly regulatory.

Let’s begin with the obvious: if the organization is a publically-traded company listed in the U.S., it is subject to compliance with the Sarbanes-Oxley Act of 2002, which was enacted to ensure reliability in financial reports filed by public companies with the U.S. Securities and Exchange Commission. Check with your Chief Information Officer (CIO), Chief Technology Officer (CTO), Chief Operations Officer (COO), Chief Financial Officer (CFO) or Corporate Controller to understand how these obligations are currently managed and how you should engage with the appropriate teams. In general, you’ll be responsible for some subset of the Information Technology General Controls (ITGCs) that your organization has defined to comply with Section 404.

If the organization holds personal data for employees or customers, it is likely subject to privacy regulations from applicable state privacy and breach laws, along with potential international implications depending on the localities involved. Prior to European Union (EU) rules changes in 2015, U.S. multi-nationals complied with the European Safe Harbor rules, but as of this writing, the Safe Harbor protections are being redefined. Check with your Chief Privacy Officer (CPO), Chief Risk Officer (CRO), or Chief Legal Officer (CLO). If your organization doesn’t have these leadership positions a good fallback is the CFO, who will often own risk for medium sized firms. Here you’ll again have a subset of IT controls.

For good proxies on what is required to meet these controls, you can use the Massachusetts privacy regulations (201 CMR 17.00) for preventative control requirements and Nevada breach notification law (N.R.S. § 603A.010) and the California data breach notification law (SB 1386) for breach notification requirements and, to provide a sober reminder of the reach of some state regulations, review the Texas extreme notification requirements (Texas Medical Records Privacy Act), which are actually more stringent than those found in the federal Health Insurance Portability and Accountability Act (HIPAA).

Of course HIPAA is one of the other major regulatory regimes you’ll need to pay attention to if you are a “covered entity,” which are generally healthcare clearinghouses, employer sponsored health plans, health insurers, and medical service providers. One of the more interesting features of HIPAA is that covered entities are required to cascade their obligations to Business Partners and Business Associates (look for any business associate agreement (BAA) your organization has signed) to ensure that all third parties that are involved in handling Protected Health Information (PHI) are obligated to safeguard the PHI in their care.

Besides healthcare, there are other industries that have their own regulatory regimes. Some examples:

Federal agencies must comply with FISMA, the Federal Information Security Management Act. DoD contractors are subject to DFARS 252.204-7012, which requires a subset of NIST 800-53 controls and DoD contractors that handle classified information are subject DFARS Rule 78 Fed. Reg. 69273.

Organizations that accept credit cards for payment or process credit cards are subject to the Payment Card Industry Data Security Standards (PCI-DSS) and organizations that use Experian data agree to comply with the Experian Independent Third Party Assessment (EI3PA).

Finally, similar to the contractual requirement of adhering to PCI-DSS controls (these are not regulations, you agree to comply in your contract with the Payment Card Industry), organizations often agree to data handling requirements that usually include security requirements by accepting contact language specifying security and privacy related duties.

To get a picture of all of the contractual security compliance regimes, it is best to start with your executive peers for a general idea of what requirements you have, but do a deep dive with the procurement team or whichever group is responsible for managing contractual compliance. Contractual compliance is something most audit firms will look at while conducting financial audits, which implies some group within the organization will be responsible for tracking the obligations that have been agreed to. If the structure within your organization is not obvious, you can start with the CFO or Controller.

Typically, signed addendums, engagement letters for third-party assessors, and the resulting attestations will list the individuals in the organization who are authorized to represent the organization and that is an excellent place to start to determine what has been committed and who is executing and testing controls.

For banks and certain other financial institutions, there are a host of compliance regimes, including compliance with the Gramm–Leach–Bliley Act (GLBA) and adhering to guidance from the IT Examination handbook of the Federal Financial Institutions Examination Council (FFIEC), the multi-agency bank regulator. Other organizations that provide services to the financial industry are often required to provide third-party attestations about their controls. This used to be called a “Statement on Auditing Standards No. 70” (SAS-70) report, but in 2011, the American Institute of Certified Public Accounts (AICPA) replaced the over-burdened SAS-70 with a new standard called the “Statement on Standards for Attestation Engagements No. 16” (SSAE-16). This was more than a name change.

In addition to creating extra burdens on the organization obtaining the audit (called the “Service Provider”) and transferring some responsibility from the auditing firm (called the “Service Auditor”) to the Service Provider, the changes also defined and formalized additional types of attestations (SSAE-16 SOC2 and SOC3) based on trust principles, including: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Financial institutions typically have mandated management duties as well, and the CFO or Chief Audit Officer (CAO) can be consulted to start your discovery for these compliance requirements.

What I have covered above is not meant to be 100% complete. An entire book could be dedicated to listing and describing all the compliance regimes touching information (or data) security. Rather, I have laid out several fundamental principles. First, there are some mandatory security regulations for nearly every organization, certainly any organization that would require a full time CISO. Second, compliance obligations come in both mandatory (regulations) and voluntary (contractual) varieties. And third, for each requirement there are logical places to start your discovery about what is required and determine the role you must play.

Ch2-1 New-01

Setting Up for Success

Now I’d like to turn to setting up your program for success. The underlying assumption of this section is…

Copyright © 2016 CISO DRG JV – All Rights Reserved.