Strong policies and procedures are the benchmark of any organization’s information security program. An information security policy defines the organization’s security standards and provides practical guidance to the company’s employees on security responsibilities.
When it comes to information security programs, there is a difference between policies and procedures. Policies establish the minimum information security requirements and acceptable or unacceptable behaviors—the “why.” Procedures set the “how” for each policy, and describe the processes that will enable or enforce the policy. Policies tend to be more constant and remain intact year over year, whereas procedures tend to be prescriptive and can have more flexibility. Think of it this way: for most organizations, a policy is typically published as a PDF, since it will remain relatively unchanged. Procedures, on the other hand, can live in shared team repositories like a wiki or another knowledge management tool that allows for regular management and verification.
For example, an organization might have a policy that any third-party vendor they work with must be reviewed and monitored on a periodic basis. The process of sending third-party vendors security questionnaires and documenting the vendor review is a procedure and may change on an ongoing basis.
Larry Kinkaid, senior consultant with BARR’s CISO Advisory practice, provided some insight on what makes a good (and bad) security policy, and outlined actions organizations can take to ensure they have strong policies and procedures in place. Let’s dive in further:
What Makes A Good Policy?
A good security policy varies from industry to industry. “Some organizations simply don’t need very prescriptive requirements and controls if their business doesn’t warrant it. As long as a policy is defined, managed, aligned with business and regulatory requirements, reviewed, approved on an annual basis, and accessible to personnel, it’s likely a strong policy,” Kinkaid explained.
There are a few important aspects to every strong security policy. According to Kinkaid, these include clearly defined purpose, scope, ownership, enforcement, roles and responsibilities.
Every good security policy begins with a clearly defined purpose. The purpose states the reason for the policy, and the language typically states that the organization has the policy in place to meet security and regulatory obligations and mitigate business risk.
A section defining specific policy ownership and roles and responsibilities related is another critical component of a good security policy. This section assigns the responsibilities of the policy to specific parties with the authority to execute on those responsibilities. For example, managing access for onboarded and terminated employees may be a clearly defined aspect of the chief people officer’s role, whereas monitoring security risks is a defined aspect of the chief security officer’s role. The key is to communicate clearly who owns the policy and who is responsible for enforcing and carrying it out.
The scope defines the audience and states who and what the policy applies to. This typically includes both the employees of the company and the data that the company stores, processes, or transmits. This component of the policy might also include who, or what, the policy does not apply to.
“A strong policy will also align with your organization’s business requirements, customer commitments, relevant regulations,” Kinkaid said. Standards like ISO 27001 or the CIS controls are really helpful for providing the information that needs to be defined in a policy. “The policy can then be directly mapped to compliance requirements,” Kinkaid added.
Lastly, the policy needs to be simple and accessible. Employees may not be inclined to read a 70+ page security policy, especially if it doesn’t relate to their role. Boil down the information that everyone needs to acknowledge into a succinct document. For the more detailed or robust policies, make sure they are available and accessible to those that need it. “For an information security policy to really be effective, it needs to be available and everyone in the organization needs to know where it is,” Kinkaid said.
And as for bad policy? “Using language that’s too broad can make for a weak security policy. The policy should be direct in defining expectations. That’s where technical writing comes into play,” said Kinkaid.
A technical writer can help organizations avoid vague language, and replace words like “should,” “would,” with “do” and “must” in order to be as direct as possible. Policy should clearly communicate what the requirements are without ambiguity.
So now we’ve discussed what makes a strong policy, what about a strong procedure? A good sign of a strong procedure is that it’s owned by the right person—someone who is a subject matter expert in that field and has the authority to verify, manage, and change the procedure as needed.
“Knowledge management solutions like Guru and Confluence are excellent tools to help manage procedures because they help the procedure owners and users to facilitate dialogue around the procedure with options to comment, review, and verify,” Kinkaid said. “I often recommend those tools to clients.” Collaboration tools also help with ensuring the procedures stay up to date and changes are easily made on the fly when things change.
Who’s responsible for the security policy?
Within every organization, someone needs to be accountable for security. For smaller organizations without the resources to hire a full-time security professional, Kinkaid recommends that senior leadership delegate an acting CISO. The acting CISO doesn’t need to have highly technical security expertise, but they do need to be able to leverage their authority to get things done. When the acting CISO may not have the right technical skills, we recommend assigning the role to both a leadership and technical resources (e.g., CTO and COO).
When it comes to security, companies can delegate everything except for accountability. Having an executive sponsor (or acting CISO), and a security committee who are responsible for managing, reviewing, and enforcing the security policy is essential for its success.
How often should information security policies be updated?
Policies must be reviewed at least annually and should be updated as necessary, or whenever there is a material change in your environment. An organization that updates their policies too often is missing the point between policies and procedures. Consider documenting the language in a procedure instead of constantly modifying policy.
“Anytime you do make changes to policies, I strongly advise you to provide your team and relevant stakeholders with deltas, or a summary of the changes you made and how it will impact them,” Kinkaid said.
Procedures can be updated more frequently than policies, but should be reviewed and updated on at least an annual basis.
How should a security policy be enforced?
Once a security policy is implemented, there needs to be clear expectations for how the policy will be enforced. Procedures for policy enforcement vary from organization to organization, but should include security awareness training that aligns with the policies.
The best policies and controls are ones that are configured so they can be enforced the way they should be. For example, if you have a policy stating employees need 16 character passwords, but your AWS environment only requires a 12 letter password, it becomes impossible to enforce. Using automated or system configurations such as these are the most effective way to enforce policies, specifically technical controls.
Part of enforcement must include some sort of defined disciplinary action. Policies without disciplinary action are not enforceable. For example, if an engineer did not complete their annual security awareness training in time, they may lose access to the systems they need to do their job. Disciplinary action can look really different for organizations depending on their culture. Disciplinary actions may include something as simple as removing a user’s access, but could also include termination if the violation is severe enough.
Just like all security practices, it’s better to have something rather than nothing. Having a simple security policy in place is better than not because once you have one started, it’s easier to build upon as needed. Start with the basics and work your way up from there. You won’t be able to implement policies and procedures that align with the most robust frameworks or requirements in a day, month, or even a year. It’s a process that requires diligence and continual improvement.
“The important thing to know about policies and procedures is they look very different from organization to organization and there’s no hard and fast rules to the way it needs to be done,” Kinkaid concluded.
Interested in learning more about security policies and how BARR’s CISO Advisory practice can help your organization? Contact us today.