shopping cartShop
Call Us: 888 641 0500


Distributing Information Security Policies

To be effective, information security policies need to be read and understood by every member of the organization. This seemingly simple requirement is now becoming a standard practice to reduce risk, comply with regulations and demonstrate due-diligence.  Why is this control so important and how can it be done in practice?

Regulatory Requirements

Every regulatory framework or information security standard has some variation of the following requirement:  “Validate that written information security policies are distributed to every member of the organization.”  (See the table below)

Many organizations are being exposed to information security for the first time via a regulatory requirement.  For example, a company that processes credit cards must comply with PCI-DSS.  A contractor to a Federal agency may be required to adopt FISMA.  In these cases, organizations are presented with an onerous checklist of items they must comply with.  Often, the reasons behind these requirements are vague or difficult to understand.

There are two fundamental reasons why organizations must distribute security policies and track acknowledgement.   The first is that written security policies define “rules of behavior” for the way in which users interact with data and systems.  Given the fact that most data breaches can be traced back to some form of human error – this seems to be a reasonable way to reduce risk.   If employees don’t understand how to use systems securely, it creates a dramatic increase in potential risk.  These “rules of behavior” are most commonly expressed as Acceptable Use Policies.

The second (and perhaps less appreciated) reason is to demonstrate due-diligence regarding information security.  Information security is not a prescriptive science.  In other words, organization are often encourages to adjust their information controls based on “the size and scope of the business” or “the results of a risk assessment.”  Variations of these statements show up in regulations like HIPAA/HiTECH and GLBA.  This essentially implies that organization can add or remove controls based on a risk assessment or other business justification.

This is fine until there is a data breach or other serious incident.  Once an incident happens, the organizations are quickly under scrutiny to determine if they were are fault.  (The issue of culpability and issuing fines is way beyond the scope of this article.  However, there is a consistent pattern.  If organizations are willfully negligent, the penalties and fines increase dramatically.)

Reducing Risk

[In the classic view of risk analysis, information security controls have two primary functions:  To reduce the “likelihood” that an event will happen and reduce the “impact” of an event that does happen.  In that context, requiring users to read policies fits both conditions.   Educating uses should help them reduce mistakes, and performing due-diligence is likely to reduce fines or criminal charges for negligence.]

Demonstrating Due Diligence

Requiring users to read and acknowledge security policies is simply one of the most effective ways to demonstrate due-diligence with regard to information security.   Despite the large and growing army of technical solutions, information security is still a people-oriented business.  And information security policies represent a key control point where security technology meets human behavior.

There have been numerous legal cases in which users were disciplined for not following corporate policy.  However, in those cases some employees argued effectively that they have never seen or understood the policy.

This seems like a reasonable idea.  But for organizations with hundreds or thousands of employees and contractors, this can present a huge challenge.  In fact, the process is not really feasible unless some of technology is used to automate the process.

Policy User Acknowledgement: Key Elements

So now that we understand that this is a good idea, how does an organization go about doing this in practice?  For organizations with hundreds or thousands of employees and contractors, this can present a huge challenge.  Our experience with hundreds of organizations can be distilled into two key requirements.

Security Policy Design

First, make sure that security policies are targeted at the right audience.    Some organizations still make the mistake of “co-mingling” technical and process policies with user-oriented policies.  In other words, most users need to understand Acceptable Use of computer and communication systems.  They to NOT need to know how a firewall is configured or how to document a system change.  Information security policies need to be organized by topic and targeted at the appropriate user groups.

Security Policy Automation

Second, use a policy automation tool to distribute policies to different users groups. In fact, the entire policy distribution process is not really feasible unless some of technology is used to automate the process. Security policy automation or management tools provide the following key functions:

1. Enable a documented workflow for creating, reviewing and approving policy documents;

2. Enable targeting of specific users and groups based on their job functions;

3. Require formal acknowledgement of the written policy document;

4. Provide reports that document progress across the organization.

Every policy management tool must have some variation of these key requirements.   This has now become a required feature in Governance Risk and Compliance (GRC) tools. In 1998, there was only one commercial tool available to help automate policy management.  Today, there are dozens.  Information Shield has chosen to partner with Policy Hub because we believe it has the strongest set of functions available in the market when it comes to “pure” policy management.

Of course, commercial tools are not required.  Organization can develop their own systems using custom code, MS-Sharepoint or even a combination of email with logging software.   In general, though, unless these systems are already in place within the enterprise, it can be difficult to justify development when so many robust commercial tools are now available.


Information Security Policy Requirements of various compliance frameworks

ISO 27002: Section 5.1.1 “A set of policies for information security should be defined, approved by management, published and communicated to employees and relevant external parties.

“These policies should be communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader, e.g. in the context of an “information securi y awareness, education and training programme” (see 7.2.2).”

PCI-DSS 3.0:  12.1 Establish, publish, maintain, and disseminate a security policy.

Examination Procedures: 12.1 – Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners).

Gramm-Leach-Bliley Act (GLBA) Title V – Section 501 –  “Each Bank shall implement a comprehensive written information security program [policies] that includes administrative, technical and physical safeguards.”

NIST SP 800-53: AC-1 Control:  The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles] … An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;


New Security Policy Map for US CyberSecurity Framework

In February 2014, NIST released version 1.0 of the Framework for Improving Critical Infrastructure Cyber-security.   The frameworks is intended to be a “voluntary” set of standards that can help small and medium sized businesses develop an information security program.   (Part of the problem, of course, is that we don’t need another framework – but a rational and scaled down version of other frameworks such as NIST 800-53 or ISO 27002 that would make sense for small businesses.)  While the framework is currently voluntary, some speculate that it could become a default standard for evaluating smaller businesses and contractors that have a part of the critical infrastructure.

Mapping ISO 27002 to the CyberSecurity Framework

For those organizations that base their information security program on the ISO 27002 information security standard, we have developed a new policy map between the control categories of ISO 27002:2013 and the Cyber Security Framework.  This mapping should help your organization rationalize security controls across these two frameworks.  For existing customers, this mapping also includes references to the sample information security policies found within Information Security Policies Made Easy.

Download the ISO 27002:2013 to Cyber Security Framework Mapping Document.



The ROI of Pre-Written Information Security Policies

Often it is difficult to justify security policy development to management.   In many cases, this is due to a lack of understanding on just how detailed and complex policy writing can be.  “Just go find a template on the internet.”   For those of you who have tried this approach, you quickly discover that there is much more to the process IF you want to create a set of quality, consistent policy documents.

Buy or Build?

For those of you still struggling to justify the purchase of a policy package, download our whitepaper The ROI of Pre-Written Information Security Policies.   In this short paper we present a simple model for estimated the cost of writing information security policies.  Understanding this cost is the best way to computer a “return on investment” of purchasing a quality set of templates such as Information Security Policies Made Easy.

Understanding the Total Cost of Policy Development

But remember, developing information security policies is only one part of the ongoing management process.  To better understand the entire life-cycle costs of developing and maintaining policies, read our whitepaper The Total Cost of Information Security Policy Management.   Using these tools should help you estimate the costs of your policy development project, including using in-house resources versus outside consultants.



New Point-of-Sale Device Security Policy

The piercing lens of information security changes focus quite often.  In recent weeks the security vulnerability lens is focused on point-of-sale (POS) devices.  And there seems to be good reason.  The Target breach, perhaps the largest reporting breach in history, seems to be the result of malicious software inserted into these devices via a network hole and stolen vendor credentials.   As the news of the breach was unfolding, the National Cyber Investigations Joint Task Force (NCIJTF) issued new warnings about sophisticated malware attacks directly targeting POS devices.  While malicious software is a threat, the devices are also prone to physical tampering, prompting a new set of controls within the latest update to PCI-DSS 3.0.

As part of our ongoing updates to our PolicyShield Security Policy Subscription, we have added a new sample information security policy:  Point-of-Sale (POS) Device Security Policy.  This new security policy has controls that help mitigate the risks of malware infection, as well as the risks of physical tampering and theft.  The new sample policy is free to all existing PolicyShield subscribers.


How to Structure Information Security Policies

We talk to customers every day about  security policies.   One of the most common questions we receive is this:  How should we structure our information security policies?  When we dig deeper, we usually find that this is a really a two-part question regarding policy structure.

  1. First, how should we name and organize our documents.
  2. Second, what content or detail should go in each policy document.   These are both great questions and we will address each separately.

Why the Confusion?  HIPAA, PCI, FERC, NIST – Oh My!

Why do people struggle with this basic starting point for developing policies?  In our opinion, this has to do with the various and confusing outlines of different information security frameworks and laws such as ISO 27002, HIPAA,PCI-DSS and NIST.    People who (quite naturally) want to base their security policies on an established standard fall into a trap.  These common frameworks are designed to organization information security requirements, not form an outline for security policies.  For example, the NIST 800-53 outline is heavily biased toward technology.  The first major section of PCI-DSS is devoted almost entirely to managing firewalls.

These common frameworks are designed to organization information security requirements, not form an outline for security policies.

As an example, the first control objective (5.1 Information Security Policy Document) of ISO 27002 requires that an organization have a written security policy.  It does not specify how they will organized or grouped.  If you simply adopt the ISO 27002 outline, you will find it very difficult to place certain items, such as Acceptable Use of Assets, which are targeted at end-users.  The topic of IT Risk Management (which is called out in HIPAA and NIST) is not even part of the 11 domains listed.  The NIST outline specifies that written policies and procedures are required in each of the 17 different domains.   But if you simply adopt the NIST 800-53 outline, you will have challenges addressing common items like Third Party Security or Internet Acceptable Use.

The Common Policy Approach

We recommend a simple approach that is based on subject matter and target audience.  We use this approach in our Common Policy Library (CPL).  Using the CPL approach, information security policies are broken into a set of 10-20 policy documents, each covering a specific topic.  These topics are chosen to overlap with the most common requirements of various laws and regulations.  (Notice, we didn’t say ALL of the topics, but most of them.)    Here is a sample list of documents using the CPL outline:

  1. IT Risk Management Policy (Risk Assessment)
  2. Security Program Policy (Policy, Planning, Personnel)
  3. Asset Management Policy (Inventory, Acceptable Use, Protection)
  4. Information Management Policy (Collection, Classification, Storage, Disposal)
  5. Third Party Security Policy (Assessment, Contracts)
  6. Personnel Security Policy (Screening, training, termination)
  7. Access Control Policy (Systems, Accounts, Passwords)
  8. Network Security  Policy  (Firewalls, Structure, Wireless)
  9. Physical Security Policy(Visitors, IT Systems)
  10. Operations Management (Configuration, Change Control, Malware)
  11. Application Security Policy (Development, Testing)
  12. Security Incident Management Policy (Reporting, Response, Investigation)
  13. IT Business Continuity Policy    (backup, Business Continuity)
  14. Security Monitoring Policy (Logging, Audit, Monitoring)
  15. Customer Privacy Policy
  16. Employee Data Privacy Policy

Using this approach, each policy document contains all of the essential controls fora broad security topic (or domain using ISO terminology.)   Each documents contains a set of more specific policies, usually between five and twenty statements per document.   This provides enough detail to mitigate the risks of each category, but does overwhelm the stakeholders with information.  (This is the approach we use with our information security policy library.)

In many cases, these topics align nicely with major categories of the ISO 27002 standard or NIST 800-53.   Just as important is the fact these topics also have a specific target audiences (or “stakeholders”.   For example, a Security Program Policy is generally targeted at management, oversight committees or external auditors.  A Personnel Security Policy is targeted at hiring manager and the Human Resources department.   Having a well-defined set of stakeholders makes each policy easier to review, update, approve and manage.  This point is worth repeating:

Having a well-defined set of stakeholders will make any policy easier to approve and manage.

Avoid  The One-To-Many Policy Approach

Some information security practitioners use what we call the “One to Many Approach”.  In this approach, the organization has a single, overarching policy document with a group of very high-level policy statements.  An example would be, “Company X protects access to all sensitive data”.  These documents then refer to a group of  “standards” documents to provide more detail.  In our experience, this approach simply creates another level of abstraction that does not help get security policies written and approved.

Information Security Policies Versus Standards and Procedures

Another key to this approach is to make sure that these documents contain only “policy” statements.  In other words, these documents describe very specific rules for what behavior and processes and technologies will be implemented within the organization.   But they don’t specify how they will be implemented.  For example, the Incident Management Policy can (and should) require that the organization develop specific incident response procedures.  But these procedures should be in separate documents that refer back to the policy they are designed to support.  (Procedures support and implement policies.)  As another example, a baseline standard for an operating system can list the specific settings for parameters, accounts, and services.  But these details should never be part of a security policy.  Standards can be updated as frequently as needed.

Off the Shelf and Into Action

One of the great advantages of organizing security policies by topic and stakeholders (organizational roles) comes during implementation.   For example, most information security regulations specify that personnel should be training on the policies that apply to them.   When an organization mixes technical management and personnel policies in a single document, this becomes very difficult.   When you limit each document to a limited set of policy statements, and then limit those to a specific audience, the process is very simple.  Using this approach makes it very simple to use automated policy management tools.

Summary: Effective Security Policy Structure

In summary, break your security policy development into a series of policy documents covering various topics.   Anywhere from 10 to 30 documents is common, depending on the size and scope of the organization.   Within each document, have a group of specific security policy statements (from 5 to 25 is common.)   Try to break up the topics to match the requirements of your business as well as the target audience.  This approach not only makes it easy for your organization to demonstrate compliance with a specific law, but it will dramatically reduce the effort required to manage each policy.








Information Security Policies for PCI-DSS V3

The PCI Security Standards Council just released Version 3.0 of the Payment Card Industry Data Security Standard (PCI-DSS), the set of requirements for protecting credit card data.  The update had some significant changes, including a greater focus on third-party information security.

There are many articles describing the new changes to PCI-DSS V3, including a nice summary of changes from the Council, so we won’t duplicate that effort here.  For our purposes, we wanted to look at the implications for information security policy development, so we will focus our analysis on Requirement 12:  Maintain and Information Security Policy.

Requirement 12 – A misnomer

First, Requirement 12 “Maintain an Information Security Policy” is essentially misnamed.  While it does outline the specific requirements of written information security policies (12.1), it should really be named “Maintain an Information Security Program” – since it covers all of the organizational aspects of information security, including risk assessments, personnel security, and third-party security.  Unfortunately, this name carried forward to the new update.

This confusing name just adds to the overall global confusion regarding security compliance and security policy.  Customers met with these requirement go looking for a single “information security policy” – when in fact what they need is a SET of information security policies and procedures that document their information security program.

PCI-DSS Information Security Policy Requirements

PCI has always been a strange standard compared with other outlines like ISO 27002 or NIST.  While the PCI recommendations go into specific detail in areas like firewall management and configuration (what we might refer to as a “standard” or even technical configurations), requirement 12 makes much higher-level statements about security policy.

12.1 Changes – Security Policies Moved

One of the key PCI-DSS requirements is that the organization have written security policies and procedures that cover each of the security categories.   But now they say it a bit differently.

One of the major changes in the outline was to take the previous requirement (12.1) to have written policies and procedures and spread it out into the various topic sections.  So rather than saying you must “have policies and procedures that cover the PCI-DSS topics” it simply adds that requirement at the end of each section (physical security, access control, etc.)  This is more in line with the NIST SP 800-53 approach.  But it adds little in the way of guidance or clarity.   This approach also seems to leave out the requirements to document the previous 11 categories of the standard, which is clearly not the case.

PCI-DSS Information Security Policies in 4 Steps

So what DOES PCI-DSS V3 really say about Information Security Policy?   Let us try to summarize in four basic steps:

1. Written security policies should document the overall structure of your information security program, (as such, written information security policies are key pieces of evidence for auditors and assessors seeking to validate your program)

2. You must have written information security policies and procedures that cover all of the control categories of your security program.  (Access control, physical security, personnel security, incident response, etc.) (12.1)

3. Like your program, information security policies must be reviewed and updated to reflect changes in your program and security environment, (12.2)

4. Your written policies should be distributed to the key personnel that need to follow them. (12.1)

Not surprisingly, this is what ISO 27002 says about written policies (5.1) and HIPAA says about information security policy.  Did we need another standard with another numbering system?  We’ll let you be the judge of that.

The bottom line is that these are the core components of any effective information security policy program.  If your organization adopts these best practices, then addressing the specific requirements of different regulations will basically fall into place.

About Information Shield

Information Shield publishes the leading library of information security policy templates, including Information Security Policies Made Easy.   Our products allow organizations to quickly document their information security program for compliance with regulations and frameworks including PCI-DSS, HIPAA, NIST, ISO 27002 and CoBIT.



ISO 27002:2013 Change Summary Heatmap

The British Standards Institute (BSI)  recently released an updated version of ISO/IEC 27002 – Code of Practice for Information Security Controls.  This was the first major update since the 2005 release.  Many organizations are interested in how the changes will impact their information security program.

What Really Changed?

In our review, very little in the way of information security substance was changed in this version.  While several controls were added and several more removed, the update is largely an exercise in moving and renumbering.  The essential “key” controls are still required – they have just been moved to a different location.

Some of the key moves seem justified – like consolidating all third-party security controls into one domain.   (Understanding the rationale for renaming the domain “Supplier Relationships” from ‘Third-Party” is more difficult.)  While some sections such as 5.0 Information Security Policy remained unchanged, several areas such as Operational Security had major changes.

The ISO 27002:2013 Change Heat Map

In our efforts to decipher the changes between ISO 27002:2005 and 2013, we found it very difficult to wade through the vast numbering changes.  In order to help our clients manage this information, we created a change “heat map”.  In short, the map uses color coding to try to indicate areas of large change (red) versus areas that remained similar (green).

The heat map aligns both of the versions (like this sample image) to try to visualize what was maintained, added and removed between versions.

So what does this mean for Information Security Policies?

Most organizations will change little with this update -  unless they included specific ISO 27002 references in written policy documents.  In that case, they will have to change a large number of references.  (Which it might make sense to remove for future versions!)

The core requirements to develop, maintain and distribute written information security policies are still key to the standard.   (As they are with every information security regulation.)   The work will be in deciding how and when to address  the new control objectives, and then include those within your written information security policies.  In future releases of  our PolicyShield Security Policy Subscription and Information Security Policies Made Easy, we will include any needed sample policies to fill in the gaps.

 Get the ISO 27002 Change Summary Heat Map here.





Information Security Policies According to NIST

Five Best Practices from NIST 800-53

In April 2013, NIST made the final updates to their complete catalog of information security requirements, Special Publication 800-53 Revision 4 – Security and Privacy Controls for Federal Information Systems and Organizations.  The catalog is BIG – it contains hundreds of information security and data privacy requirements organized into 17 different topic categories.  Each category is called a “family”, and covers a key information security topic such as access control (AC), incident response (IR) or physical security (PE).

For people not familiar with FISMA or NIST, this document is essentially the security “encyclopedia” for how to protect systems and organizations.  As such, even organizations that are not required to comply with federal information security laws still reference the NIST standards for guidance on all things security.

So what does NIST SP 800-53 say about written information security policies?  In this article we take a slice through the outline and pull out the requirements as they relate to information security policies.  For this article, we will use the NIST family Access Control (AC) as a working example.  The result is a list of five key principles of information security policies according to NIST:

1: Written information security policies and procedures are essential

The first control in every domain is a requirement to have written information security policies.  The specific requirement says:

The organization Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: (1) An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;

Notice the term “documents”.  This implies that policies need to be written down.  While this seems obvious, many organization still fall short in documenting their specific security policies.  (This is often sites as the greatest deficiency when audits are conducted for HIPAA/HiTECH by the OCR.)  The second part calls for written procedures to support the policy:

(2)    Procedures to facilitate the implementation of the access control policy and associated access controls; and

Each of the 17 other control categories (or families) follows the same format, with the first requirement always calling for written for policies and procedures.  What this also implies is that the policy document for each section covers the key controls required for that domain.   For example, within Access Control (AC), your Access Control Security Policies could cover:  Account management (AC-2), access enforcement (AC-3), information flow enforcement (AC-4), separation of duties (AC-5) and so on.  While NIST also specified a minimum set of these controls, the typical organization may choose a smaller subset.  But the structure can remain the same – one or more policy statements for each topic.

2: Security policy documents must have a defined structure

NIST SP 800-53 also goes into detail about what needs to be covered within the security policies.  The requirement for an Access Control Policy specifies that the organization develop:

(1)    An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;

For example, each document should cover the “scope” of the organization or systems that the policy applies to.  It should also include references to specific organizational roles required to take action as part of the policy.  To address these requirements, each policy and procedure document should have a standard format with sections addressing each of these required areas.  A standard format not only speeds up the review and update cycle, it helps the written information security policies integrated with other standard corporate policies.   A similar standard format is built into each of the 30 sample policy documents included within Information Security Policies Made Easy.

3:  Security policies must be periodically updated

The NIST guidance is once again very specific about this requirement.  Written information security policies and procedures need to updates to reflect the latest changes in the organization.

The organization: (b) Reviews and updates the current: (1) Access control policy [Assignment: organization-defined frequency]; and (2) Access control procedures [Assignment: organization-defined frequency].

Notice that the requirement allows the organization to set a specific time-period or frequency for updates.  A common time period is annually for information security policies.  Information security procedures can be updated at the same period or triggered as part of a policy update.  For example, the organization may update the Employment Termination Procedure to reflect new requirements, but the Personnel Security Policy that requires this procedure can remain unchanged.

4: Security policies must be distributed to the organization

Information security policies and procedures are not effective unless the drive organizational behavior.  To do this, policy and procedure documents need to be distributed to the users in the organization so they can be read and understood.

The organization Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

Some other implied requirements come from the need to “disseminate.”  First, organizations should target specific policies to user groups and roles within the organization.  For example, all users do not need to be aware of the contents of the Network Security Policy, while all users should know how to safely use the internet and email.   Another implied requirement is that these documents are understood.  The organization should perform due-diligence in educating users on the security requirements of their jobs, including the information security policies and procedures that apply to them.

5: Security policies must be managed with a defined process

The previous four elements lead up to this key requirement:  Organizations must establish a formal management process for information security documents.  This requires that the organization treat information security policy documentation as an ongoing project, not a one-time event.   This implies several other requirements, such as assigning ownership to each policy document and to the entire policy management process.  How can an organization possibly manage the specific security policy elements – including reviewing, management commitment, coordination and compliance – without a management process?  Sadly, this is where many organizations fail.  The development of information security policies is delegating to a single individual as a part-time project with minimum visibility into management, rather than being treated as a project that requires funding and resources.  While this approach may get the organization by, it usually fails after the first major audit.  As always, up-to-date information security policies are key pieces of evidence to support due-diligence.


While your organization may not be required to comply with FISMA, the NIST family of publications can provide excellent guidance on developing and managing an information security program.  When it comes to written information security policies, the message is clear:  Security and privacy policies need to be living documents.


Example:  The full catalog listing for AC-1 within NIST SP 800-53.


Control:  The organization:

a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

  1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
  2. Procedures to facilitate the implementation of the access control policy and associated access controls; and

b. Reviews and updates the current:

  1. Access control policy [Assignment: organization-defined frequency]; and
  2. Access control procedures [Assignment: organization-defined frequency].

Supplemental Guidance:  This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

Control Enhancements:  None.

References:  NIST Special Publications 800-12, 800-100.

Priority and Baseline Allocation:

P1 LOW   AC-1 MOD   AC-1


Security Policies Key to HIPAA BA Compliance

In January the Department of Health and Human Services (HHS) released the much-awaited final updates to the HIPAA Security, Privacy and Enforcement Rules. These updates, known as the “Omnibus Rule” were required by the HITECH Act and have been in proposal form since 2010.  The new law incorporates some major changes in the HIPAA security and privacy rules, including a new focus on the risk of third party vendors (aka Business Associates).

300,000 Business Associates Impacted

Perhaps the most sweeping change was the extension of HIPAA to “make business associates of covered entities directly liable for compliance with certain of the HIPAA Privacy and Security Rules’ requirements.”  In short, Business Associates (BA) that process electronic health information (ePHI) are now required to conform to the same data protection requirements as covered entities (CA).  In addition to the compliance requirements, the legal liability of HIPAA violations was also extended to the vendors.

According to HHS, an estimated 250,000 to 400,000 new organizations will be required to comply with HIPAA security requirements.  This represents a substantial number of small and medium-sized businesses that are suddenly faced with the burden of compliance.

In addition to this compliance requirement on the vendors, each covered entity (CA) will be required to perform due-diligence in screening, managing and assessing third party vendors.  As usual, a key part of this validation will be the effectiveness of the written information security policies of the business associate.

§ 164.308 Administrative safeguards.

“(8) Standard: Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity’s or business associate’s security policies and procedures meet the requirements of this subpart.”

The Cost of Compliance – Are they serious?

Here’s the good news – if you believe HHS, you can charge these new compliance efforts to your corporate credit card.  It its required economic impact analysis, HHS estimates the total impact of this new compliance effort of business associates to be between 22 and 113 million.  If you assume the highest estimate for 400,000 organizations -  this works out to be roughly $250 per organization.  (Are they serious?)  In the real world, these costs will likely be much higher.  A robust information security program that can be validated by a third party is not a small effort.   At Information Shield we are doing our part by offering cost-effective solutions to help you establish and document your written information security program.

Solutions for the Human Side of Security

HIPAA Compliance should not just be a documentation exercise.  If your organization is going to make the effort, why not create a sound information security program that actually reduces risk?  Information Shield solutions help you accomplish this sensible goal.  We have everything you need to manage the “people” side of information security and privacy:  quality information security policies, security awareness training and compliance management.  You can spend millions of dollars on technical security (firewalls, antivirus, spam filtering, IDS) and still have a breach with ONE human mistake.




New Guidance Requires Social Media Security Policies

In January 2013, the Federal Financial Institutions Examination Council (FFIEC) posted a set of proposed guidelines for financial institutions to maintain compliance in the world of social media.   The document entitled “Social Media: Consumer Compliance Risk Management Guidance,” includes a number of specific recommendations for financial institutions that must protect customer information.  The FFIEC security requirements are key for GLBA compliance.

People + Information = RISK

As is often the case with security recommendations, information security policies are a key part of the equation.  In fact, one of the key “reputational risk” areas highlighted in the document concerns employee use of the social networking sites.   To quote from the official document:

“Financial institutions should be aware that employees’ communications via social media—even through employees’ own personal social media accounts—may be viewed by the public as reflecting the financial institution’s official policies or may otherwise reflect poorly on the financial institution, depending on the form and content of the communications. Employee communications can also subject the financial institution to compliance risk as well as reputation risk. Therefore, financial institutions should establish appropriate policies to address employee participation in social media that implicates the financial institution.”

After the comment period is complete, some version of these guidelines will be part of the official requirements. Accordingly, institutions will be expected to use the guidance in their efforts to ensure that their policies and procedures provide oversight and controls commensurate with the risks posed by their social media activities.

While these requirements are for financial institutions, the lessons are valid for every organization.  Studies show that 80% of employees access some type of social networking sites at work.  And where there are people and information together – there is risk.

Sample Social Media Security Policies

Does your organization have Social Media Acceptable Use Policies in place?  The PolicyShield Security Policy Subscription includes sample documents including Acceptable Use of Social Networking, which provides policies for safe use of online communities and social sites.  An additional sample, Corporate Use of Social Networking provides policies for organizations that are actively using social media to engage customers.  Don’t reinvent the wheel!  We have incorporated the latest social media risks into our standard security policy templates.

Older posts «