Information Security Policies, Writing Security Policies
5 Elements of Effective Information Security Policies
Oct
Information Security Policies – The Foundation
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.
1. Information 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 employees or provide specific procedures. Security policies must stay at a high level and refer to procedures, standard and guidance.
Policy Tip: Security policies can be viewed as a “contract” between the organization and it’s information security related stakeholders: Management, Employees, Customers, Regulators and Auditors.
2. Security Policies are Specific
Security policies must be specific enough to refer to an individual “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:
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.
Policy Tip: Avoid vague language and target policies at specific actions or outcomes to make policies easy to deploy and measure.
3. 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 cyber domains and technical elements like access controls, malware and incident response. This makes the document very long and impossible for an average employee to read and understand. This also makes it difficult to match the policy document to your control framework.
You can include this control in your policy framework with an example like this:
Example Policy: All governance documents that make up the Company X information security program must follow templates established by the Information Security Department.
In most cases, the Acceptable Use of Assets Policy 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 who are responsible for those functions.
Policy Tip: Each policy should have a target audience that represents the group of individuals responsible for implementing the the policy.
4. 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 default account settings on IT systems before the systems 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 enforced across the entire enterprise.
Policy Tip: Make security policies refer to technical standards and procedures to fill in the implementation details.
5. Information Security Policies are Read and Understood
To be effective, information security policies need to be read and understood by all personnel. This requirement is now part of every cyber security compliance framework at some level. 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.
Sample Policy: All personnel must formally read and acknowledge the policies that apply to them.
While this seems obvious, many organizations are still not able to verify that Users are properly educated on security policies. If a policy is not read and formally acknowledged, policy sanctions are difficult to enforce.
Policy Tip: Information security policies cannot be enforced unless they are read and understood by all personnel.
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.
