Compliance regulations can often seem intimidating and difficult to comprehend when they are first read.  Trying to compare two or more different regulations that seem unrelated often leads to frustrating questions, such as “Do we as an organization need to change our approaches to meet new regulations?”  Understanding these regulations and quickly mapping them to existing practices can be tremendously helpful, but often sounds like a daunting task.  In many ways, however, this is not nearly as difficult a task as it sounds.

At the beginning of most regulations comes a basic mission statement that covers both the scope and the purpose of the regulation.  The best example may be the Payment Card Industry’s Digital Security Standard (PCI DSS) that states in the very first line, “The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally.”

The key components to take from this is “what” is being protected and “who” is affected be the standard.  For PCI, it is “cardholder data” and who is “everyone processing cardholder data around the globe.”  Still, this would be a fairly small number of computers for a typical mid-sized business.  For FISMA, the scope includes not only Federal Government computer systems, but organizations that perform services for the Federal Government as well.  Sarbanes-Oxley (SOX) pertains to a company’s accounting systems, NERC CIP applies to the critical assets of the bulk electric grid, and HIPAA is relevant to systems with exposure to Protected Health Information.

The protections that regulations make at this level are either because of something important in the data (PHI, credit cards, customer information, etc.) or a set of systems based on function (accounting, government, bulk electric grid components, etc.).  Measures for protection for data versus function creates different strategies – an emphasis on barriers, encryption and isolation would come from data based regulations, while function-based regulations require a more holistic approach.

Once the mission is defined, at some point in the preamble there should be a brief discussion about the approach to be used for securing the organization.  Here the principles to follow are defined, setting the tone for how the company will structure their information security strategy.  There are different popular approaches, and they may be used in conjunction.  Here are a few examples:

Confidentiality, Integrity and Availability
Often referred to as the Three Pillars, the “CIA” model has become the most commonly referenced principle associated with regulation.  The first pillar, Confidentiality, explains that data must be kept private and that access rights given to individuals, such as those who need to use the data, contain only the specific privileges needed to perform their job duties.  The second pillar, Integrity, refers to preventing corruption, either intentional or unintentional, of the system.  And the third pillar, Availability, stipulates that security measures will not hinder an individual’s ability to function effectively, such as making a user enter 10 passwords to log into a computer.  The CIA model is a useful way to describe “computer security” as a multi-tier practice (policy, standards and procedures), and is either whole or in part described by FISMA, GLBA, SOX, HIPAA, PCI DSS, fitting virtually all policies and security standards.

Management, Organizational and Technical
Some regulations require a holistic evaluation of security, looking at everything from company management and oversight (vision, policy and standards), to organizational components (employees, physical security, training, etc.), to the technical controls and operating procedures used for information protection.  FISMA and HIPAA are excellent examples of regulations that endorse M/O/T controls.  These elements are associated with the National Security Agency’s Information Security Assurance Methodology (IAM) and are used to determine a complete picture of organizational information security.

Risk Management
One of the disciplines of project management is assessing risk.  The process of doing so is largely a financial exercise to determine the damage per incident, the frequency of occurrence, and to balance the cost of the control to identify and articulate any savings for protecting the asset.   Regulations take a generalized approach place an emphasis on risk management, such as SOX with the Commission of the Treadway Administration (COSO) standards, FISMA, and NCUA 748, among others. Risk management is also central to CoBIT policy development.

Minimum Technical Standards
Some regulators prefer to provide a specific standard for security controls in order to ensure compliance, such as requiring firewalls, account security practices, log management and encryption.  Regulations such as NERC CIP and PCI DSS have provisions for specifying minimum technical controls that extend past policy and reach the standards and even procedural level.   Many regulations also specify responsibility to an outside agency for defining the standards, such as to the National Institute of Standards for Technology used for NIST Special Publication 800-53 for FISMA and NIST Special Publication 800-66 for HIPAA.

Knowing the viewpoint from which a regulation was written can help locate similarities with other regulations.  Often, two regulations may intersect with principles that are similar, if not identical, in the way they should be implemented.  Once they are identified it is generally easier recycling similar policies and practices between the regulations to ensure compliance, rather than attempting to create and manage them individually.