Implementing your policies and libraries entails four major steps:
Separating the writing of the actual policy language from the discussion of the intent of the policy change is a good way to build a consensus. During this step, you should discuss the drivers for the change in terms of the operating model and principles. This reinforces the shared beliefs and helps promote the desired culture. As much as possible, it is desirable to have a consensus on at least the purpose of a policy. You may or may not be able to achieve consensus on all the detailed items in a policy, but at least the purpose should be one that has broad support.
This separation also has the added advantage of reducing the time it takes to develop the actual policy language. Too often time is wasted disagreeing with policy language when, in fact, the real disagreement is on the need for the policy. If you have agreement on the need for the security control and the intended outcome, then writing the policy language is easier. The actual writing simply documents this agreement. This approach also makes the review and approval easier, because there’s already an awareness of the need for the policy change and an understanding of its intent.
Throughout your research and interview processes with operational users and their managers, you should have prepared them for changes that the information security (IS) department will be mandating. This give-and-take process helps to improve the quality of the document content. It also helps with buy-in from those who are subject to the rules and controls you’ll be implementing based on the risk analysis and assessment work completed.
Once they are written, you need to share your documents again with those who helped you develop them. Let those employees review the policy documents’ language well before you implement them. These reviews allow you to assess the impact of the policy or standard on the organization before deploying it in a potentially disruptive fashion.
These reviews sometimes require you to revise parts of a policy or standard to allow for current conditions. Or, you may need to postpone implementing some controls until the environment is better prepared for compliance. Early in your overall policy development project, you should work with your organization’s audit group to determine how soon after policy publication they will audit based on the policy. By allowing a grace period for compliance, you are helping to ensure that the policies will be enforceable. A grace period gives personnel time to implement any project, processes, or internal communications necessary for compliance.
Allow sufficient time to gather and address concerns, as well as sufficient time for the business to prepare its employees for the change. Once you gain the concurrence of those subject to the policies, it’s vital to gain approval from their managers or their management team. Often, executive managers appoint delegates for standards reviews and rely on recommendations before they approve or reject changes. If you’ve done a good job with those subject to the specific standards, approvals should be timely.
If you cannot implement controls immediately, postpone the implementation date. Let people know that new controls are coming at a future specific date. Depending on the size of the organization, the grace period can be from a few months to one year.
Ultimately, your goal is to gain senior executive approval of the policy or standard. The executive approver may be the chief information security officer (CISO), if the role exists. That person is unlikely to give approval if all parties have not reviewed the document. Internal reviews within the IS department should help mitigate some of the executive approver’s concerns once the document reaches him or her for approval. Here are some suggested people who should be given the opportunity to become a second or third layer of review:
Although these review steps may seem onerous, early buy-in is needed to ensure there are no surprises when policy changes take effect. It’s better to put in the time and effort early in the process to avoid rework later.
Once policies and standards are approved, you need to distribute them in ways that work best in your organization.
Publishing your policy and standards library depends on the communications tools available in your organization. Many organizations use some form of an intranet for internal communications. Different departments may have their own subsection of the intranet, and IS should have its own. An intranet generally has a front page or portal that announces new content on the site. It also includes news, other announcements, access to standard forms, and so on.
Sometimes, intranet sites use a back-office engine for managing content, like Microsoft SharePoint Server. Departments can use SharePoint for the documents and contact information they wish to share, and then publish the content to the intranet for anyone to access.
If your organization uses a content management tool for departmental websites, you might consider using that for publishing your documents. Documents must be readily obtainable at any time, with a copy placed on the internal network shared drives or the organization intranet. Some of the best practices for publishing your documents are to create separate webpages for each document and to provide a link to the document itself on that webpage. The page should contain:
The medium you choose for developing your policy content may determine the level of difficulty you’ll encounter in the review cycle. Word processing documents are appealing because they’re easy to use and convenient. However, for review purposes, word processing documents aren’t always efficient. When you’re ready with a final draft, you can create a set of PDF documents that comprise the policy and standards library. You then publish the library in a way that’s best for your organization.
You might consider a roadshow prior to the publication of major policy changes. In this context, a roadshow refers to showing up at a large gathering of employees and explaining the change. This could be as simple as being a guest at a normally scheduled department meeting or calling a town-hall meeting to announce the upcoming changes. This approach is usually more appropriate for larger organizations.
A class of software, called Governance, Risk, and Compliance (GRC), is available to support policy management and publication. Functions that are commonly found in a GRC tool include:
GRC tools are typically delivered as modules that plug in to a central GRC engine. Usually, you can license a policy and standards module. With this module, you can use the workflow features to develop and share your documents for reviews and approvals, publish the library as webpages, and search for relevant documents. Some organizations use the tools for:
As part of a continuous improvement effort, plan to review and update published policies and other framework documents periodically. You’ll learn about document review and maintenance later in this chapter.
The following GRC tools, as well as several others, are widely used:
Implementation requires educating personnel not only on each of the core elements, but also on changing their role to emphasize protecting data and systems. Ongoing security awareness training, including training on new policies, is a critical aspect of policy implementation.
An awareness program can motivate employees and promote the shared beliefs discussed earlier in this chapter. Motivating employees is as important as mastering a technology. A motivated employee can deal with the unexpected. This is particularly important when dealing with unexpected security events. Remember, it’s not getting employees to learn the policy that’s important; it’s motivating employees to execute the policy. Additionally, this communication creates a foundation for other discussions, such as performance appraisals and process improvement. Consequently, a security awareness program is one of the key factors for the successful implementation of an organization-wide security policy. Awareness tools should describe and outline the specific mandate for all employees to secure organization assets. It should also explain the core elements of the security policies and standards. The program is aimed at generating an increased interest in the information security field in a way that’s easy to understand.
Gaining management awareness and buy-in should be your first step. Without management support and commitment, it’s unlikely that your efforts to educate the masses later on will succeed. As you’re selling the program to your executive sponsor(s) and gaining approval for issuing your documents, use that time to leverage their authority with managers and direct reports to ensure compliance. With that level of buy-in secure, the task of gaining buy-in from the rest of the organization is made that much easier.
Awareness programs are often divided into two parts: awareness and training. The purpose of awareness is to provide employees with a better understanding of security risks. The importance of security primarily focuses on the daily operation of the organization. Training should cover many potential security problems in detail, as well as introduce a set of easy-to-understand rules to reduce the risk of problems.
Here are a few techniques that many others have found useful in getting the message out:
Furthermore, you can help people perceive actual personal benefits from the security program, such as the new skills they will gain. For example, mention to them how this information can help them increase the security of their personal computers at home and their own information.
Varying the methods of education can increase the success of your awareness and training program. Ensure you have a fresh, ever-evolving, and dynamic education program. The following sections offer suggestions for broadening awareness and educating staff about security.
One interesting and valuable way to reach and educate your staff is a security newsletter. The main idea is to provide users with an interesting and engaging way of understanding the points outlined in the policy and standards library. You can send it via email or post it on your intranet. To be effective, it must be brief and interesting to read. Lengthy newsletters are less likely to be read. It is often effective to tie the newsletter to some breach or security issue that has been in the news recently.
If you develop your newsletter in-house, you may need to ask for help from others in the information security group. Also consider getting input from people outside the group who have security-related perspectives to share with the rest of the organization. An alternative is to subscribe to third-party security newsletters that you tailor to your organization.
Rather than a formal newsletter, you could set up an Information Security Awareness area on your intranet. You could maintain several pages of information that are linked and easily updated.
The following sections describe parts of a typical security newsletter.
Sometimes people appreciate reading detailed, in-depth information on a specific topic that helps them understand the subject more clearly. For example, if in a security awareness campaign you covered email threats, you could include an associated article in the next newsletter while the topic is still fresh in the employees’ minds. Essentially, articles go deeper than the newsletter, and provide more detail for those who wish to deep-dive into a topic.
The following are possible article topics:
Create a social network of evangelists throughout your organization. Some organizations have had success with identifying a specific security evangelist within each working group or department. These people will act as advocates for information security and help their specific departments or groups answer questions related to their obligations for compliance. You can start with people who show an above-average level of security interest or skills. Identify and promote these groups as a social network that speeds the adoption of security. Start by tracking the people who stand out during awareness sessions or other training opportunities.
This section of the newsletter educates or informs staff and acts as an information security glossary. It includes various security terms explained in a nontechnical, easy-to-understand way. General security topics such as Trojan horses, worms, and firewalls can be covered individually, as well as other topics or concepts that you think are useful, must-know, or can help with compliance to standards and policies.
You can include an “Ask Us” section in your newsletter. Over time, you can create a frequently asked questions (FAQ) document that summarizes the questions and answers to give users a richer experience when interacting with the IS department.
The questions and corresponding answers could be included in the next issue of the newsletter, so that it will not only be a collective information source to a large group of people, but also stimulate the asking of further questions.
A “Security Resources” section might include short news pieces that cover some aspect of information security in an easy-to-understand form. The idea is to help users understand the importance of security awareness via security news, news of the latest security breaches, losses suffered by companies due to security problems, and so on.
Make sure to include the contact details for the IS department so that users will know precisely whom to contact in case of a problem. Publish the intranet uniform resource locator (URL) to your site everywhere you can to help remind people that help may be a click away.
Changing policies is like any other change process. When changing technology, organizations usually have a change control board (CCB), sometimes referred to as a change advisory board (CAB). Changing policies should be no different. Effective oversight of the policy change ensures that security is implemented in a thoughtful way. Oversight of the policy change process usually falls under an existing committee. The committee members are often senior leaders who represent both the technology and the business interests. These individuals as leaders ensure that the right balance between protecting the organization and operating needs is maintained.
It’s important that changes not be made unilaterally or cause unexpected consequences. To avoid these situations, form a policy change control board or committee. You can organize this group ad hoc, meeting as needed for reviews and approvals. It can also be a standing committee or working group that meets regularly to address changes, additions, and enhancements to policies and standards. You can develop a standard that creates the board and establishes membership requirements. Minimally, you should include people from information security, compliance, audit, HR, leadership from other business units, and project managers (PMs). PMs set the agenda for the meetings, take meeting minutes, assign action items, and follow up on deliverables.
Security personnel need to be aware of policy and standards change requirements. They also need to understand the impact of the change on the IT environment. Because systems, applications, and networks are integrated, a change to one component can affect other components.
The objectives of the policy change control board are to:
A policy does not exist in a vacuum. If implemented well, it’s part of the day-to-day transactions and activity of a business. In that respect, there must be a process to track major events, such as what went right and what went wrong. For example, if there was a breach, a post-breach review would examine which controls should have prevented the event or mitigated the impact. Which policies were not effective in preventing the breach? The policy and standards change-management process ensures that policies and standards are refreshed when needed. It deals with new developments in technology and changes in the business environment. When potential changes are identified, change management determines whether the changes should be made or a new policy or standard is needed. There must also be a “lessons learned” process that allows for problems to be resolved and changes made to the policies and standards being designed.
The policy change control board assesses and approves RFCs. An RFC typically responds to known problems but can also include improvements. A challenge when handling an RFC is to determine whether it should be approved or whether a transitional policy or standard will resolve the issue.
A “lessons learned” process ensures that mistakes are made once and not repeated. Lessons learned can come from anyone and anywhere.
Additionally, there are business drivers for policy and standards changes, which may include the following:
Some change requests result in a complete redevelopment of the policy and standards library, or at least in one facet of the policy and standards development cycle.