Information Security Policies, Writing Security Policies
5 Elements of Effective Information Security Policies
Bad Information Security Policies
Information Security Policies are the foundation of your cyber security program. They create the “written rules” that define how controls are implemented and audited. They are typically the first set of “evidence” used to validate your program to third parties. Yet organizations often make common mistakes when writing information security policies that make the documents bad, boring, or just plain ineffective.
After developing custom information security policies for hundreds of organizations, we have identified some important characteristics that make some Information Security Policies better than others. Follow these rules and develop security policies that are clear, concise and understandable.
Security Policies are NOT Optional
Information security policies are not supposed to be optional. They are “business rules” that must be followed. Effective security policies use the word “must” to define behaviors or technical implementations. Many organizations make the mistake of using vague language in policy statements. “Users should consider security when accessing the internet.”
Avoid using vague words like “May” or “should”. Also don’t mix policies with “guidance” documents that are design to train or provide specific procedures. Security policies must stay at a high level.
Security policies can be viewed as “contract” between the organization and it’s information security related stakeholders: Management, Employees, Customers, Regulators and Auditors.
Security Policies are Focused
Security policies must be specific enough to refer to a specific “Control” that can be tracked and audited. For example, a common policy we see is “All users should exercise caution when accessing email.” This policy is not only vague, it is impossible to measure. A better example:
Policy: Users must never click on a link within an email to download a document or visit a web site unless the site has been verified.
Effective information security policies support internal Controls. Both management and technical. Another example of a policy that supports a specific control:
Example Policy: Company X must test the Disaster Recovery Plan at least once annually using simulated events.
This policy not only ties to specific requirements of various regulations, it is clear and measurable via evidence. Avoid vague language and target policies at specific actions or outcomes to make policies easy to deploy and measure.
Security Policies have a Target Audience
Another common mistake is writing security policies for “everyone”. In other words, the security policy document has no specific target audience. The most common example of this is having one large “Security Policy for the entire organization. This “everyone” policy contains a bunch of technical elements like access controls, malware and incident response. This makes the document impossible for an average employee to read and understand.
In most cases, the Acceptable Use of Assets should be the only document that is read by everyone. Other domains such as Incident Response Policy or IT Operations Policy should be targeted only at technical staff or who are responsible for those functions.
Policy Tip: The target audience of a policy is the group of individuals responsible for implementing the control in the policy.
Security Policies are Technology Agnostic
Information security policies should not refer to any specific technical platform. Policies are not machine settings, but high-level rules that may ultimately be implemented by ‘standards’ on various technologies. So an Access Control Policy can define common controls such as password length and complexity, but should never reference a specific platform such as MS Office or databases like MySQL.
In cases where security policies do not provide this level of detail, they can then refer to standards that DO provide this level of detail. When would we want to put details in standards instead of policies? Let’s look at a common example relating to systems.
Example Policy: “Company X must change all default passwords and account settings on IT systems before they are placed into production.”
In this example, a “Configuration Baseline Standard” for various types of operating systems, firewalls, databases, etc. would provide enough detail so that this policy can be implemented on all of the various technologies now in use in most organizations. This would enable to the organization to create a single policy that can be enforces across the entire enterprise.
Information Security Policies are Read and Understood
To be effective, information security policies need to be read and understood by all employees. This requirement is now part of every cyber security compliance framework at some level. To be able to support this Control in audits, the organization should maintain an “Audit Trail” or record of employee engagement. For example, automated tools like Compliance Shield enable the organization to automatically distribute security policy documents to employees and track formal acknowledgement.
While this seems obvious, many organizations are still not able to verify that Users are properly educated on security policies. Most often, policy mistakes like the ones in this article stop the written policies from being effective and easy to understand. So they stay on the “digital” shelf.
1000 Security Policy Audits Can’t Be Wrong
What makes us the experts in writing information security policies? First, we are security experts that have been developing and updating information security policies for over 20 years. Second, our Security Policy Template Library (ISPME) has been used by over 10,000 customers and 60 countries. Third, our policies have passed hundreds of audits, both internal and external. Have questions? Contact us today.
