Compliance fatigue can afflict just about any enterprise facing the growing list of regulatory requirements placing pressuring on their security practices. Sometimes it may seem that there is just not enough money or time to keep up. But governance, risk, and compliance (GRC) experts believe that the key to bringing things into equilibrium is a solid foundation set by unified policies that can guide security standards and procedures to both minimize risk and comply with regulations now and in the future.

Unfortunately, many organizations fail to do a good job establishing effective policies. Dark Reading recently talked to some experts in the industry, who offered helpful tips on what organizations should and shouldn't be doing when developing their security and compliance policies.

Don't Get Bogged Down In Individual Regulations
"Organizations today have numerous government and industry-specific regulations that they need to be mindful of," says Andres Kohn, vice president of technology at Proofpoint. "The evolving regulatory environment becomes even more complicated due to multiregulation and cross-border regulations."

Not to mention that Gartner's predicting that by 2014, 70 percent of IT risk and security officers in Global 2000 organizations will be required to report annually to the board of directors on the state of security, Kohn says. He believes that with so many individual requirements, it can be easy to get mired in the details.

"Don't be bogged down by specific regulations," he says, warning that creating policies off-the-cuff to fit specific regulatory mandates can lead to trouble. It makes more sense to develop a policy framework that can be managed and adjusted as required by all risk considerations — including new mandates.

Do Let Risk Lead Policy Decisions
No matter what industry you're in, Rick Doten, vice president of cybersecurity for DMI, says it is important to always remember security's No. 1 motivator: Cybersecurity is all about managing risk. So let risk considerations lead policy decisions and then map compliance reporting to that, not vice versa.

"For instance, regulatory compliance is considered one of the primary business risks for industries such as the energy utilities. The National Energy Regulatory Commission (NERC) can fine a company up to $1 million a day for noncompliance," Doten says. "Others, such as the large financial institutions, have dozens of regulations they need to follow. They focus on building a security program where controls are appropriate to protect the business, and consider regulatory compliance as merely a reporting exercise to show how their controls map to meet the regulatory criteria."

According to Jeff Schmidt, global head of business continuity, security, and governance for BT Global Services, good policies start with an understanding of one's risk appetite.

"By having a risk appetite defined, you then know and can manage to the risk posture of the business. This creates a foundation for the business metrics of what 'good' looks like for your organization as it relates to security," Schmidt says. "It allows the chief information security officer to report in a meaningful way without jargon and without needing to leverage Fear, Uncertainty, and Doubt [FUD]."

Don't Confuse Policies With Standards Or Procedures
Do you know the difference between a policy, a standard, and a procedure? No? Join the club, says Jeff VanSickel, practice leader for compliance at SystemsExperts.

"This is probably the No. 1 issue in the development of an information security program," VanSickel says. "Simply put, a policy is management's definitive position on a specific issue to ensure consistency. A standard is a specific measurable requirement that governs an operation, configuration, or process in order to satisfy a policy. A procedure is a set of step-by-step instructions required to satisfy a given standard."

Understanding how each feeds into the other will enable your organization to perform better according to directives in each, and it will make it easier to bring clarity to policies.

"Policies are not about technology; they are about defining the objectives of the organization through the description of requirements," says Dave Frymier, vice president and CISO for Unisys.

As he puts it, policies should sit at the top of pyramid of documents that consist not only of standards and procedures, but also end-user guidelines.

"In this manner, security policy can remain constant even if, for example, an organization changes its router vendor," Frymier says. "Only the standards and procedural documents would change, and there may be minor or no changes required for the end-user guidelines."

Do Your Framework Homework
Compliance frameworks are one of the most reliable tools for fleshing out a unified set of policies, even if it takes a considerable amount of tweaking to suit specific needs of your business.

"Read the basic framework documents from organizations that provide security policy guidance, and then use their major headings as a checklist to tailor a policy for your own situation," Frymier says, suggesting usual suspects such as COBIT and NIST-800. "You’ll find that 90 percent of these frameworks cover the same ground, and the remaining 10 percent is industry-specific. You'll get a great start to your policy by covering that 90 percent."

Don't Maroon Policies On IT Island
Are your policies taking just IT risks into account? Don't get trapped in such myopic thinking, Doten warns.

"Have your policy set at the right level, not just corporate audit or CSO level," Doten says. "Regulatory compliance is part of a larger set of business risks and should be prioritized as such."

According to Frank Villavicencio, executive vice president for Identropy, policies need to align with the strategic direction the organization wants to follow.

"But at the same, make sure they are attainable," Villavicencio says, warning that if procedures will need to change drastically to support a policy shift, then IT needs to gain buy-in from stakeholders on the front-end. "If a new policy requires a significant change in how things are done, you're more likely to get the buy-in you need from any stakeholders before the policy goes into effect. Reaching out to others involved in any procedural change will also open up lines of communication if there are problems or kinks that need to be worked out after the policy is instated."

Do Make Policy Statements Auditable
Policy statements should not only be designed to help mitigate risk, they should also be created with auditability in mind.

"It is very important to ensure that documented security policy and standard statements are auditable, producing evidence to show that controls are operating effectively," VanSickel says. "Since many policies and standards are driven by legal or regulatory requirements, this evidence is useful toward demonstrating compliance whenever the company is audited on those controls."

Once developed, organizations can fine-tune policies and procedures based on frequent audit results, says Michael Hamelin, chief security architect for Tufin.

"When it comes to systems or network management, audit, audit, and then audit again. That way you have the context needed to develop the best policy or set of policies best suited for both operations and compliance," Hamelin says. "The goal should be to maintain compliance, not check the box -- that kind of thinking can potentially land your company with a fine, and perpetuates the reactive culture security pros are working so hard to move away from."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.