Security Policies | What You Need to Know
What is a Security Policy?
Security policies are internal frameworks that formally document an organization’s requirements for the safe handling of sensitive information and assets. Effective security policies tend to be developed for employees from their perspectives regarding things like risk tolerance, how they value the information they have access to, and what information is available to them. It is because of this that most organizations cannot take a “one size fits all” approach to their IT security policies if they wish for them to be successful. Security policies are unique documents that should be specific to the roles and responsibilities of each organization’s employees.
However, there are some overarching concepts and concerns that good policies should address. With this in mind, we invited our Manager of Governance, Risk, and Compliance Chris Dixon, as well as our Staff Attorney Matt George, to discuss common questions about security policies and share their expertise.
What is a simple way to explain what a security policy should be to an organization?
Chris Dixon: To me, the easiest way to describe what a security policy is would be a document—or series of documents—that defines the security requirements for an organization and things like employees’ expectations and obligations. The security policy should set the tone for the security posture for the entire organization. It lays the groundwork for security, privacy, and compliance requirements for an organization and its employees.
Matt George: I agree with Chris, though I would add that it can be thought of as a hub that sets the posture for security and privacy for the entire organization. It is the central pillar that all other organizational policies relating to security and privacy should be built around.
Why is a security policy important and why should it be a priority for organizations?
CD: Security policies are vitally important because they lay out the framework for security postures across organizations. Also, they should do this in a way that is easily digestible for employees. Doing this sets an organization up for more success by aligning with industry best security practices and compliance obligations. Essentially, even if an organization has a good security process, but they don’t have an overall policy to dictate the rules that are enforceable and understood by employees, that security process won’t be successful.
MG: The security policy of an organization promotes cohesiveness and risk mitigation. It mitigates risk because it helps establish best practices, and having policies in place gives confidence to clients who may not have insight into an organization’s processes but can view the privacy policies that are in place for assurance. Thus, it protects the contractual relationships with clients because you have those policies well-documented.
What are some key things to consider when looking to develop and implement a security policy?
CD: Scope. Organizations must understand what it is they are trying to protect in their environment. If an organization handles data that falls under certain industry standards, like NACHA or PCI DSS, or laws and regulations, like CCPA and GDPR, they need to craft their policies to enforce those rules. Risk tolerance is also important. There can be a tradeoff between more stringent security requirements and business enablement. Taking a risk-based approach to policy decisions can better align requirements with the organization’s risk appetite.
MG: Scope is important. Something that I have found useful is to remember that less is more. I believe that accuracy is the most important thing of all, and there is a tendency for security policies to get “scope creep.” By this, I mean that writing a policy that places a bunch of additional restrictions just because it looks good doesn’t help an organization in real life. Whatever an organization writes down must be able to be complied with to the letter.
Also, when an organization is looking at their security policies and security posture, part of that project should be a data inventory. Identify and ask all key players in an organization: “What type of data is held, and where is it held?” Organizations may find that even though they may not work with a particular piece of data, they might still have this data in their environment and would thus be required to comply with regulations they may not have been aware of.
What makes a security policy good?
CD: One of the key things to making a security policy successful is making sure it is readable. It may seem simple, but communicating clearly and efficiently is crucial to make sure the requirements expressed are something organizations can enforce and something easily digestible for internal employees who need to abide by these requirements. Whatever policy an organization creates should have a clear purpose. If a point can’t be defined, the organization needs to rethink why they are including that piece.
MG: A good security policy structure will have a general overarching security policy and then a smaller policy for extreme compliance requirements and sensitive data. It should be built up with different elements applying to different areas of the business. Also, a good security policy is going to include metrics and concrete, actionable items organizations can use to determine whether they are complying with the policy or not.
Once you have a security policy, how do you enforce it?
CD: The first step here is to always focus on communication and awareness. People won’t follow what they aren’t aware of, so a best practice is to have policy acknowledgment at hire and then have employees review policies again on an annual basis. A good security policy will document what the repercussions are for not following the rules, or organizations could have separate violations or disciplinary policies in place for those who may violate the security policy.
MG: I agree with Chris, but I would add that if an organization is not engaging with their policy regularly, then they probably need to rework that policy. Building processes out to continuously monitor their environment is key to being able to accurately detect violations and resolve any issues that may arise. This could be an internal or external audit to ensure employees are following organizational policies.
How often should you look to update your security policy?
CD: In my experience, I would say it is best to take a risk-based approach to maintain a security policy. An organization should review its security policy on an annual basis at the very least, or after any significant internal or regulatory changes. A best practice is to assign each policy an owner who leads the effort to update that specific policy. This can help avoid things being overlooked as you try to maintain multiple policies. Also, I would recommend having a change control process to keep track of updates made to policies. This helps organizations know when something with a policy was changed and, more importantly, why the change happened.
MG: Ideally, security policy updates will happen organically because organizations should be regularly engaging with the policy by measuring the metrics that it sets up. If for some reason that doesn’t happen, then what Chris said is spot on. Regardless, organizations should be looking to continually improve security policy structures. Lastly, I will say that even if an organization doesn’t have changes to make to their policy, they should always seek feedback for clarity to make sure they are communicating it as effectively as possible.
Founded in 2010, TokenEx is an Oklahoma-based cloud tokenization provider committed to protecting the world’s most sensitive data from breach. Its industry-leading solution for data protection can secure and desensitize any structured data element to reduce risk, streamline operations, and enable its clients’ most critical business processes.
View the TokenEx resources page for industry case studies, ebooks, and webinars regarding PCI compliance solutions, PII compliance solutions, Nacha compliance solutions, credit card tokenization, and much more.