**UPDATE** I shared this post on the InfoSec Island and a member commented on it with a link to a post on the Awareity Lessons Learned Blog.  Check out this post as it talks about a vital step in this process that I failed to talk about.  The step is the “Implementation Step”  - Blot Post, What is a “Failure to Implement”?

What is document management? It seems pretty straight-forward, but many people have looked at me cross-eyed when I’ve used the term, and some have come right out and said “What do you mean, document management?” There are many document management systems out there, both proprietary and open-source. Before I talk about systems we need to understand the process.  Document management isn’t just storing documents, its a process of reviews, approvals, storage and communication .  So lets dissect these processes.

Reviews: Reviewing documentation is a key step in ensuring it’s accuracy of the content.  You may not always be an expert with topic you are writing about.  So when writing documentation its important to obtain feedback from the reading audience or intended users.  Feedback could be someone stating that there is a step missing or could event be the document was not written in enough detail or to detailed.

Approvals: Most organizations require that policies, standards and sometimes procedures be approved.  Approval is also very important, because it will help in enforcement from the top down.  If an employee writes up a new procedure on how to do something and just sends it to the team, it is very unlikely that it will be implemented across all members. However if the procedure is approved by management its more likely to be implemented and used by all members of the team.

Communication: This step is where a lot of organizations struggle.  How in the world can an organization expect someone to follow policies if they don’t notify the user base when one is created, modified or retired?  You must communicate to the users in order to ensure that they are aware of the documents.

Storage: Last but also very important to the integrity of the documentation is how we store these documents securely, but also allow availability to the appropriate user communities.  When storing company policy documents you should have a source file (normally a word document) and then a published version (normally a pdf document). The source files should be stored in a secure location restricted so that only the author and document owner have access and then the pdf should be made public to the user community that needs to read the documents.

Now that you have the process, I will share some products that will help your implementation for a sound document management program. Storing the source files can be as simple as file shares on your network with proper security controls restricting access to the shares.  Microsoft’s SharePoint is also a very good solution for documentation management with a lot of features that may or may not be used. With SharePoint you can perform the entire process from reviews, approvals, communication and storing both source files and public files.  Microsoft has different version of SharePoint including a free version called WSS.  With WSS you loose some features, but the entire document management process can still be performed with WSS.  Another solution depending on your organization, could be utilizing your development team to develop an online document repository with a database back-end with a web front end.

There are many many systems for document management, so just do your research on the system to ensure that it supports your processes. So many times organizations buy a solution before they understand their own processes.  That’s a whole other topic to blog about , but “Solutions are not always resolved with Technology”.

Please comment with other solutions that have worked in your environment and or suggestions or questions regarding document management.

In an early post I gave some Tips for Writing Information Security Policies.  I’d like to continue with this topic and provide a frame work that will hopefully make it easier for you to develop all policies, standards & procedures needed for an Information Security Program.

There are many different ways to approach policy documentation.  What I have found to be the most effective for users, auditors & management to read and understand is to create a separate policy, standard and procedure for each topic.  Let me explain by using the example “Password Policy“.

So at the top of the pyramid there is Policy.  This is the overall policy that gives the “marching orders” to your users, policies should not change that often. Using our example the password policy a policy statement might be:

• Passwords must be complex.

Next there is Standards. This document will list out the technical details to support the policy.  Using our example, the standards may be:

• Passwords must be 8 characters long & contain upper case, lower case, number, symbol.

Following standards is Procedures. Your procedures are basically “How To’s“, creating these documents could be beneficial in cutting down support calls on how to do certain tasks.  Again using our example of the password policy, one procedure document could be:

• Changing Passwords

Finally there is what I call Supporting Documentation.  Basically what these documents are forms or checklists.  Supporting documentation may not be needed for each topic covered, but could be helpful for users that are required to follow these documents.

Okay, your probably thinking WOW this guy just quadrupled my documentation!  Well it does, however once this project is underway it really does make sense and enables you to manage documentation more effectively.

If you document everything in one big document that document will probably include policies, standards, and maybe some procedures.  As I said earlier policies shouldn’t change that often, however standards can change fairly regularly.  So if you change one item in your large document that contains all IT Policies & Standards, you now have to get that entire document approved again (could take awhile, depending who all first approved the document).  However, if you had one standards document for that specific topic, the approver would only need to review and approve that one item, not the policy or other policies and standards that doesn’t even apply to what was modified.

Using our example you might have the following for Passwords.

• Password Policy – CIO or Sr. Management approval depending on the organization
• Password Standards - Sr. Management approval, depending on organization
• Password Procedures - Department Manager, or Team Lead approval, depending on organization

I have used this framework many times to help develop IT Policies, Standards and Procedures for Corporate IT department with great success.  In my next post on regarding IT Documentation (Policies) I will talk about Document Management.  If you have comments or questions please post a comment.

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 policies 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 further can 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 proper modifications.

Policies involve compliance, business process, technology, and employee awareness, so include all managers in policy reviews. Review policy considerations at each management meeting. 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. Make education fun to maximize retention. Make monitoring policy compliance an integral part of a more encompassing employee awareness program.