Awards
- Community Pick
I have been involved in the process of writing a number of documents including corporate security policies, standards & procedures & below are some of the most common questions that come up during this process.
Yes it is a process. :)
What you should consider when developing an information security policy?
Consider what the policy structure will be before writing the policy. Policies are ineffective when employees dread reading them, can’t understand them, or can’t easily reference them. Information security policies by nature require periodic updating due to changes in regulatory requirements, technology, and business environments. The problem that many organizations experience is that their policies evolve over time into complex, disorganized documents.
The policy’s structure should allow users to find the requirements for a specific subject by perusing the table of contents. Categorize related policies appropriately so users don’t have to search for information. Proper layout also allows the policy administrator to accurately modify policies. The policy’s primary goal is to educate staff on the guidelines you establish. If the document isn’t legible and is poorly organized, contradictions and confusion can result.
What should be included in the policy?
Some common policy topics are setting data classifications, roles and responsibilities, acceptable use of the Internet and e-mail, remote access, protection measures, and response procedures. Depending on the organization and its business there could be many more security topics to cover in the security policy. Policies are legal documents, so include nondisclosure rules and an employee acceptance agreement.
Don’t write precise rules for every possible scenario. Doing so can create loopholes that can work against your organization. Instead, write policies in a general manner. For example, remote access rules should apply to any form of remote access. This accounts for future technology. When you authorize access, you can furhter define in a policy how it’s controlled.
Boards and management should regularly review policies and procedures to ensure their completeness and effectiveness. Mergers; changes in technology, business models, and staff roles; and new regulations are key instigators of the review process. As events occur, review existing policies to ensure coverage and any subsequent modifications and notifications that may be required.
Policies involve compliance, business process, technology, and employee awareness, so include all managers in policy reviews. Make sure there is a formal Policy Review agenda item at each management meeting where you can review policy considerations, discuss testing policies, or simply affirm there is no change. Assign a policy manager to facilitate policy review, approval, and writing, and employee awareness. Make policy review a section of your organizations third-party security assessment process that should be performed annually.
How do you monitor compliance?
Monitoring requires periodic testing. If you don’t test, there’s no way to know if your policies are being adhered to. With information technology (IT), seemingly minor procedural mistakes can go undetected until an incident occurs. A basic example is an e-mail policy. It’s hard to know if a user routinely opens unsolicited e-mail attachments until a worm cripples the network.
You can perform testing in creative and educational ways. You could have an outside firm perform a social engineering-based penetration test, where a mock attack is performed using techniques that exploit existing policy rules. Or you could implement a more direct policy test, using a Q&A exam sent via e-mail, hard copy, or intranet. Remember, the testing’s intent is to educate staff on their role in security, not to identify a guilty party.
Of course, there is education. You must ensure that everyone has the knowledge of how to use the Policy documents and what they contain. Make education fun to maximize retention. Make monitoring policy compliance an integral part of a more encompassing employee awareness program.
Yes it is a process. :)
What you should consider when developing an information security policy?
Consider what the policy structure will be before writing the policy. Policies are ineffective when employees dread reading them, can’t understand them, or can’t easily reference them. Information security policies by nature require periodic updating due to changes in regulatory requirements, technology, and business environments. The problem that many organizations experience is that their policies evolve over time into complex, disorganized documents.
The policy’s structure should allow users to find the requirements for a specific subject by perusing the table of contents. Categorize related policies appropriately so users don’t have to search for information. Proper layout also allows the policy administrator to accurately modify policies. The policy’s primary goal is to educate staff on the guidelines you establish. If the document isn’t legible and is poorly organized, contradictions and confusion can result.
What should be included in the policy?
Some common policy topics are setting data classifications, roles and responsibilities, acceptable use of the Internet and e-mail, remote access, protection measures, and response procedures. Depending on the organization and its business there could be many more security topics to cover in the security policy. Policies are legal documents, so include nondisclosure rules and an employee acceptance agreement.
Don’t write precise rules for every possible scenario. Doing so can create loopholes that can work against your organization. Instead, write policies in a general manner. For example, remote access rules should apply to any form of remote access. This accounts for future technology. When you authorize access, you can furhter define in a policy how it’s controlled.
Boards and management should regularly review policies and procedures to ensure their completeness and effectiveness. Mergers; changes in technology, business models, and staff roles; and new regulations are key instigators of the review process. As events occur, review existing policies to ensure coverage and any subsequent modifications and notifications that may be required.
Policies involve compliance, business process, technology, and employee awareness, so include all managers in policy reviews. Make sure there is a formal Policy Review agenda item at each management meeting where you can review policy considerations, discuss testing policies, or simply affirm there is no change. Assign a policy manager to facilitate policy review, approval, and writing, and employee awareness. Make policy review a section of your organizations third-party security assessment process that should be performed annually.
How do you monitor compliance?
Monitoring requires periodic testing. If you don’t test, there’s no way to know if your policies are being adhered to. With information technology (IT), seemingly minor procedural mistakes can go undetected until an incident occurs. A basic example is an e-mail policy. It’s hard to know if a user routinely opens unsolicited e-mail attachments until a worm cripples the network.
You can perform testing in creative and educational ways. You could have an outside firm perform a social engineering-based penetration test, where a mock attack is performed using techniques that exploit existing policy rules. Or you could implement a more direct policy test, using a Q&A exam sent via e-mail, hard copy, or intranet. Remember, the testing’s intent is to educate staff on their role in security, not to identify a guilty party.
Of course, there is education. You must ensure that everyone has the knowledge of how to use the Policy documents and what they contain. Make education fun to maximize retention. Make monitoring policy compliance an integral part of a more encompassing employee awareness program.
by: rdivilbiss on 2010-07-16 at 14:29:37ID: 17072
re: "The policy’s structure should allow users to find the requirements for a specific subject by perusing the table of contents."
As a former IT director I found it useful to number the policies against a master number list.
e.g. Section 300 of the policy book might be e-mail, and policy 310-# might be the how to deal with SPAM policy. Where # is the revision. As time goes by and situations change it is helpful to append a revision number to a policy.
FWIW: Some readers may wish to do this.