A: These days it seems that compliance has a direct impact on nearly everything we do and in a lot of cases with very good reason. Regulatory compliance concerns are, for the most part, designed to protect organizations and individuals from some rather dire consequences, including identity theft and, in the case of the Health Insurance Portability and Accountability Act (HIPAA), health insurance abuse through the unauthorized disclosure of personal information.
Regardless of the regulatory compliance concern, it's safe to say that it will in one way or another have an effect on storage, particularly in information management. Information management is the treatment of information acquired by one or many disparate sources in a way that optimizes access by all who can benefit from that information. Compliance may have a broad impact on your organization's information management by predetermining the value of certain types of information. For example, if your organization provides financial services to consumers in the United States, you are subject to the Gramm-Leach-Bliley Act (GLBA), which includes a provision known as the Safeguards Rule.
The Safeguards Rule requires financial institutions to develop a written information security plan that describes how the company is prepared for and plans to continue to protect clients' nonpublic personal information. This plan must include:
When you examine the Safeguards Rule in GLBA, several items come to light that may impact the definition of "important" information in information management. For starters, from a storage perspective, you will need to partner closely with the designated employee (or perhaps assign responsible parties from your own area) to coordinate an information security program to protect customer information. Further, you might need to have direct involvement in monitoring and testing of safeguards and assist in the selection of service providers that can maintain appropriate safeguards. It is important to remember that the Safeguards Rule is just one section in a single area of regulatory compliance. Depending upon your organization's industry, market, and operations areas, many more regulations may apply, each of which bring with them their own unique impacts on the way information (and thus storage) is managed.
When information is required by business, it is dubbed "mission critical." When information is required by regulatory compliance, and it is your responsibility to ensure that it's provided, it goes beyond mission critical to "personal." Many regulatory compliance concerns can hold internal stakeholders directly accountable for the accuracy and availability of information, and the legal ramifications associated with failing to comply with regulations can be quite significant.
Compliance concerns directly impact business continuity planning during the analysis phase and should be identified as a potential impact during the business impact assessment (BIA) portion of the analysis. The purpose of a BIA is to create a document that can be used to understand what impact a disruptive event might have on the business. Impacts may be financial (quantitative), operational (qualitative), or legal, which is usually a combination of both quantitative and qualitative measures as fines and or disruptions to operations may occur. Compliance concerns present a liability and risk management concern and should be handled as such. In risk management, there are essentially three things that an organization can do with any risk:
During the BIA process, it will be important to correlate the threat of loss with the potential for impact and the perceived outcome that may occur. Once understood, this information can then be used to generate a business case to provide justification to protect against the impact and mitigate the risk. For example, if a regulatory compliance concern has a potential to subject an organization to a civil penalty of $100,000 USD per loss, disclosure, or misuse of information, and its officers are made personally liable for up to $10,000 USD (as is the case with GLBA), an additional $20,000 USD spent per year to protect against this concern may be worth the expense.
The second option is to offset the risk. Depending upon the specific regulatory compliance concern, this may not always be possible; however, it would usually entail making some other party responsible for the portion of the process that presents the risk. For example, if handling medical information in the U.S. is a concern for your organization, you might be able to offset a great deal of risk by partnering with a third-party vendor who could assume the responsibility (risk) of warehousing the information. This may minimize your responsibility to just the information that is accessed by your organization rather than being wholly responsible for all the information.
In the example given earlier—that the Safeguards Rule makes organizations accountable for "selection of service providers that can maintain appropriate safeguards, making sure that contracts require them to maintain safeguards, and oversee their handling of customer information"—it is important to note that it may not be always possible to offset all the risk. For these and any further questions relating to regulatory compliance responsibilities, it is imperative that your organization contact a skilled attorney, preferably one who specializes in compliance law.
The last option, acceptance, is almost never consciously taken, though many organizations today who claim ignorance of regulatory compliance concerns are doing just that. Risks should only be accepted when their potential to impact the organization can be justifiably offset by the unlikelihood that they might occur or when the cost to deal with the risk is more than the cost of the risk itself. In the case of regulatory compliance, acceptance of risk may, in and of itself, mean violation of the law and should be considered immediate cause for a discussion with an attorney.
A: Compliance and litigation introduce some rather complex concerns into the storage environment that will need to be considered as part of an ongoing evaluation of liability and risk management. United States regulatory bodies such as the Securities and Exchange Commission (SEC), Department of Health and Human Services (DHHS), Environmental Protection Agency (EPA), Food and Drug Administration (FDA), and Federal Aviation Administration (FAA) as well international bodies, such as the European Union (EU), have in recent years stepped up monitoring and enforcement of regulations, and the penalties for organization falling out of compliance can be quite severe. In such an environment of increasingly complex compliance concerns, it must be understood that standardization is your friend, variability is your enemy, and complexity should not be feared.
Storage architects and administrators depend upon your line of business, data owners, legal, and risk management partners to provide clear information classification. Expectations of data service availability as well as confidentiality and integrity should be given due care during the creation of service level agreements (SLAs) and clearly documented for all parties. Doing so will provide a central point of clarification and clear documentation between line of business partners, records managers, legal counsel, and storage administrators.
As Q3.2 discussed, standardizing product and service offerings will decrease time to market and provision a more efficient storage infrastructure. Standardization both on external products and services as part of an IT procurement roadmap and internally through standard product and service offerings is key to simplifying the infrastructure—and the more simplified the infrastructure becomes, the more rapidly it can react to changing requirements.
Compliance should play a large role during the information classification phase of information lifecycle management (ILM). Ensure that the appropriate liability and risk management partners are engaged during this process so that information is properly classified.
A: Regulatory and compliance concerns are generated as an outcome of changes that occur to law or regulations that are enforced through an oversight body, such as the National Association of Securities Dealers (NASD), which is the Self Regulatory Organization (SRO) responsible for the regulation of persons and companies involved in the securities industry in the United States. The underlying question then becomes, "What influences, or drives, the changes in laws and regulations?"
Changes to law and regulations are usually driven by real-world events. The creation of the Sarbanes-Oxley Act (SOX) was driven by a need for reform in business practices in the United States as evidenced by the Enron scandal of 2001. The Health Insurance Portability and Accountability Act (HIPAA) was driven primarily by concerns over patient privacy and the portability of patient information within the health care and health care insurance provider infrastructure. Something usually must happen to trigger a response in the form of a law or regulation to cover a legal contingency. The only exception to this general rule is in the area of merged regulatory discipline. For example, with the formation of the European Union (EU), many different bodies, such as the Financial Services Authority (FSA), Environmental Protection Agency (EPA), and Information Commissioner initially had specific regulatory compliance concerns that in some cases overlap. This makes regulatory compliance in the EU particularly challenging, and future regulatory compliance initiatives may stem from a growing need to consolidate these concerns not only within the EU but also within the international space.
All these factors may drive changes in the underlying laws or regulations, and the storage solutions of tomorrow will need to be prepared. This preparedness will likely manifest itself in a need for greater control, assurance of control, and information security features being demanded within the storage infrastructure.
A: United States-based compliance requirements are going to be of concern not only to U.S.based companies but also to any international company that wants to do business within the U.S. Each of these major compliance and regulatory concerns will affect organizations differently depending upon the business that is being conducted within the U.S., so let's examine each of these items as they may impact storage and information management.
The Sarbanes-Oxley Act of 2002, which is often referred to as SARBOX or simply SOX and is also known as the Public Company Accounting Reform and Investor Protection Act of 2002, is a U.S. federal law that establishes new or enhanced standards for all U.S. public company boards, management, and public accounting firms. Consisting of 11 titles and including guidance and regulation on corporate board responsibilities, SOX spells out in detail criminal penalties associated with non-compliance. Under SOX, two separate certification sections came into effect—one civil and the other criminal—which are often referred to as sections 302 and 906, respectively.
IT auditors, managers, and storage solutions architects are often most concerned, however, with section 404 of the act, which requires management to produce an "internal control report" as part of each annual Exchange Act report. To provide this report, an audit of the IT infrastructure must take place, and there are two non-exclusive frameworks auditors may use to meet this goal— those produced by the Committee of Sponsoring Organizations (COSO) and Control Objectives for Information and related Technology (COBIT).
The Gramm-Leach-Bliley Act, also known as the Gramm-Leach-Bliley Financial Services Modernization Act or GLBA, is an act of the U.S. Congress that repealed the Glass-Steagall Act and opened up competition among banks, securities companies, and insurance companies. This resulted in a rather broad definition of the term "financial institution," which now applies to nearly any organization that handles money.
Three provisions within GLBA restrict the collection and use of consumer data and may impact any organization that has a cause to process or store financial data. The Financial Privacy Rule and the Pretexting (also known as Social Engineering) Provisions of GLBA both set forth business practices and apply more to the actual business processes around the handling of consumer financial information than the third provision: The Safeguards Rule requires organizations to implement proactive measures to ensure the security of customer information and most directly impacts storage and information management.
To be in compliance with GLBA, an organization must develop a written information security plan that describes how the company is prepared for and plans to continue to protect clients' nonpublic personal information. An organization found to be in violation of GLBA may face civil action brought by the U.S. Attorney General the outcome of which can include stiff penalties of as much as $100,000 USD in fines for each violation. In addition to the organization itself, however, the officers and directors of the financial institution shall be subject to, and shall be personally liable for, a civil penalty of not more than $10,000 for each such violation. A heavy price to pay when a misconfiguration within a storage or information management setting may lead to hundreds if not thousands or tens of thousands of violations. Like all regulatory and compliance concerns, the key to success is to follow the directions set forth within the act to the letter of the law and implement a sound auditing program to ensure compliance.
The Securities Exchange Commission (SEC) Rule 17a-4 requires broker-dealers to create and preserve in an easily accessible manner a detailed record of each securities transaction. These preserved records are used by the SEC to monitor compliance with applicable securities laws, including antifraud provisions and financial responsibility standards.
To ensure compliance with SEC Rule 17a-4, if electronic storage media is used by a member, broker, or dealer, it must comply with the following requirements set forth in sections 2 and 3 of Rule 17a-4:
Rule 17a-4 Section 2: If electronic storage media is used by a member, broker, or dealer, it shall comply with the following requirements
Rule 17a-4 Section 3: If a member, broker, or dealer uses micrographic media or electronic storage media, it shall:
NASD, Inc. whose name was originally the National Association of Securities Dealers but now is referred to simply as NASD, is the primary Self Regulatory Organization (SRO) responsible for the regulation of persons and companies involved in the securities industry in the United States, with delegated authority from the Securities and Exchange Commission (SEC). NASD is not a law but rather a governing body that oversees and regulates trading in equities, corporate bonds, securities futures, and options. Any organization that may trade in these commodities will need to adhere to NASD regulations.
Unlike SOX and GLBA, which are both primarily concerned with financial information, the Health Insurance Portability and Accountability Act (HIPAA) is focused on medical information and was enacted by the U.S. Congress in 1996. HIPAA is separated into two major sections, referred to within HIPAA as Titles. HIPAA Title I addresses Health Care Access, Portability, and Renewability. HIPAA Title II, however, focuses on preventing health care fraud and abuse, ensuring administrative simplification, and enacting medical liability reform and defines numerous offenses relating to health care and sets civil and criminal penalties for them. Of significant interest to storage and information managers that manage patient information are the Privacy Rule and the Security Rule.
The Privacy Rule establishes regulations for the use and disclosure of protected health information, which is essentially any information related to an individual's health status, provision of health care, or payment for health care. Storage and information architects must be conscious of this concern to ensure that any system designed to operate within a HIPAA environment has the appropriate level of controls in place to meet this requirement.
The HIPAA Security Rule complements the Privacy Rule and lays out three kinds of security safeguards required for compliance. They are:
A: The first step to ensuring compliance is to accurately understand each compliance concern your organization may be faced with and implement the appropriate response. Question 5.4 covered many United States-based compliance concerns, and Question 5.6 addresses several international concerns, but neither list is all inclusive. There may still be further compliance concerns faced at the international, national, or regional level, so the first step in ensuring compliance in your environment is to understand the outside factors that may impact your organization and take steps to comply with all applicable laws. Once your organization takes action to comply, the only way to ensure compliance is to be audited by the same standards upon which your organization will face by an external auditor. Two of the most common methods used by auditors are Committee of Sponsoring Organizations of the Treadway Commission (COSO) and Control Objectives for Information and related Technology (COBIT).
COSO is a U.S. private-sector initiative formed in 1985 to identify the factors that cause fraudulent financial reporting and make recommendations to reduce its incidence, which directly compliments the Sarbanes-Oxley Act (SOX) legislation. COSO has released IT auditing guidelines that are commonly referred to as simply "COSO" and focus on five key areas:
COBIT is a framework of best practices for IT management created by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI) in 1992. Currently in version 4, the COBIT Framework is generally accepted as being one of the most comprehensive works for IT governance, organization, and process and risk management. COBIT provides effective practices for the management of IT processes in a manageable and logical structure, meeting the multiple needs of enterprise management by bridging the gaps between business risks, technical issues, control needs, and performance measurement requirements.
COBIT defines IT activities in a generic process model within four domains:
This domain typically addresses the following management questions:
This domain typically addresses the following management questions:
It typically addresses the following management questions:
It typically addresses the following management questions:
Auditing your environment with either one of these standards as a framework will help to ensure that your organization remains compliant. Depending upon the size and footprint of your company, you might want to hire and maintain an internal staff of auditors to accomplish this task, but routine external auditing should still take place on a regular basis to ensure nothing is overlooked.
A: International standards such as DoD 5015.2, ISO 15489, and MoREQ all have the potential to impact storage or information management systems in the global space: DoD 5015.2 for any application that may need to interface or interact with a United States Department of Defense (DoD) system, ISO 15489 as a generally accepted standard for records management, and Model Requirements for the Management of Electronic Records (MoREQ) as a European standard for electronic records management systems. Let's examine each of these standards and how they may impact storage and information management requirements for your organization should it have a need to operate in this space.
DoD 5015.2 is a records management certification managed by the Joint Interoperability Test Command of the U.S. DoD. Under this article, there are actually two separate and distinct certifications: Chapter 2 and Chapter 4. Certification under Chapter 2 entails certification of mandatory criteria that is required by all records management applications used by U.S. government agencies, and Chapter 4 is specific to applications that process classified records.
Both certifications can be quite arduous and if your organization has no need to interact directly with the U.S. DoD in a records management capacity, you may not be inclined to attempt to ensure this level of records management certification. DoD 5015.2, however, does provide very specific requirements that will benefit any organization that has a desire to formalize and manage its records management program. Although the full detail of DoD 5015.2 is quite lengthy, the general requirements for a records management application (RMA) are provided here to illustrate some of the effects this standard may have on information management.
Managing Records. RMAs shall manage records in accordance with this Standard, regardless of storage media or other characteristics (see 44 U.S.C. 3103 and 36 CFR 1222.10, references (p) and (q)).
Accommodating Dates and Date Logic. RMAs shall correctly accommodate and process information that contains dates in current, previous, and future centuries (see FIPS 4-2, reference (r)). The capability shall include, but not be limited to, century recognition, calculation, and logic that accommodates same century and multi-century formulas and date values, and date interface values that reflect the century. RMAs shall store years in a 4-digit format. Leap year calculations shall be accommodated (e.g., 1900 is not a leap year; 2000 is a leap year).
Implementing Standard Data. RMAs shall allow for the implementation of standardized data in accordance with DoD 8320.1-M (reference (s)). When selecting commercial-off-the-shelf (COTS) products to support RMA requirements, selection criteria should include the feasibility and capability of the COTS products to implement and maintain DoD data standards. This requirement implies the capability for adding user-defined metadata fields and modifying existing field labels.
Backward Compatibility. RMAs shall provide the capability to access information from their superseded repositories and databases. This capability shall support at least one previously verified version of backward compatibility.
Accessibility. The available documentation for RMAs shall include product information that describes features that address 36 CFR parts 1194.21 and 1194.31 (references (t) and (u)). For web-based applications, 36 CFR part 1194.22 (reference (v)) shall also apply (see 29 U.S.C. 794d, reference (w)).
ISO 15489 was the first international standard to address records management and provides a comprehensive basis for auditing full and partial records management programs. ISO 15489 provides a framework for planning and implementing a records management program and includes provisions for:
MoREQ an international specification that focuses mainly on the functional requirements for the management of electronic records. Throughout the various sections of MoREQ, several areas of interest to storage and information management emerge, including access control, email security, encryption, performance and scalability, and metadata specifications—all of which may have a significant impact on storage and information management. Key areas of focus within the MoREQ specification include:
A: Ensuring corporate governance, or more specifically corporate IT governance, is a central theme throughout many regulatory and compliance concerns. Someone, some office, or some small group must be held accountable for the actions of the organization. The concept is not unique, however, to compliance. Good management practices dictate the same logic. Roles and responsibilities must be clearly defined and people need to be responsible and accountable for their actions. So how can you help ensure corporate governance?
Regulatory compliance often thrusts financial accountability on to the organization or in the case of the Gramm-Leach-Bliley Act (GLBA), onto individuals within an organization. Although extremely motivating, financial accountability cannot be enforced throughout most organizations; after all, an organization would have a hard time maintaining employee morale with a "you break it, you bought it" mentality on compliance. It is possible, however, to encourage associates to be emotionally accountable. Being accountable in its most basic definition means not only to be responsible for something but to answer to its shortcomings. The parent of a child who gets in trouble is more than just responsible for the child, they often become accountable for the incident and are motivated to be accountable not out of any financial driver but out of their love for the child. This level of emotional accountability can be built within a corporate culture by developing leaders that are willing to be part of an accountable process. Unlike responsibility, you can't force someone to be accountable. It is more of a proactive state of responsibility. You can, however, grow and incent leaders that take accountable action.
Emphasizing process over people is often misunderstood as being anti-people. On the contrary, by empowering process over people, an organization removes many barriers, or roadblocks, to individual success by limiting an individual's responsibility and accountability to their level of control over a process—which is both freeing to the individual and conducive to teamwork and process-centric business practices. Not many people, for example, would be comfortable identifying, defining, measuring, analyzing, implementing, and then performing postimplementation control over a $100 Million USD application system. It would be quite literally an onslaught of responsibility and the work effort alone would require so many differentiated roles that no one person could effectively run the entire operation as efficiently or effectively as a team of engineers, project managers, service delivery managers, and business support. By emphasizing process over people leadership, responsibility and accountability can be portioned out in a manner that ensures positive control over IT while ensuring the best people are in place within the process and don't become overwhelmed.
Determining "strategic value" is likely to be one of the most difficult jobs within any organization. After all, it is quite rare that a project jumps off the page at the decision maker's desk and clearly make its case for why it's important to the enterprise. Identifying strategic value, however, is key to ensuring corporate IT governance. Without this understanding, decisions often appear as if they're made within a vacuum with little or no consensus among stakeholders.
So how can your organization fight to identify strategic value? First, make sure all the key stakeholders are at the table. Understanding strategic value is going to require a clear understanding of what is strategically important to all line of business areas. A design and engineering team's best idea, for example, is completely useless unless the shipping department can box it up and send it out the door. Drive for a holistic view that weighs the needs of all the stakeholders and then determine which projects are implemented based upon that understanding.
It seems that most organizations these days are in a constant state of change. Although change in and of itself is often good, it can be over done and too much change can cause associates to lose track of priorities in the process. No one could conceive a medical doctor accepting a new teaching position and his first action once he hears about it is to walk out of the operating room in the middle of a surgery to study; yet in many organizations, IT managers do exactly that. The reason why is a clear lack of priorities. Determine what is a priority for your organization, or even for your department or yourself, and set clear guidance on how to maintain those priorities. A financial institution, for example, may have concerns around regulatory compliance, customer feedback, and privacy, but all these are just secondary to the clear priority of "ensuring the customer trusts us." If a bank, for example, lost the trust of the public, everything else would be in ruin. Set and maintain clear priorities.
Many organizations have a very positive perception of themselves. No one likes to think that they work for a sloppy organization, so oftentimes, whether it be under the guise of morale or team spirit, we allow our organizational ego to get inflated. Although it may feel good, it is often vanity. Auditing of the infrastructure for compliance with applicable regulations is necessary to keep that vanity in check.