What Security Policies Should I Have As An SMB?

One of the foundational elements of an organizational security plan should be the underlying policies in place. These are not the exciting or sexy security controls and blinky boxes that you’re going to see in marketing material and vendor pitches, but they can prove to be extremely critical when trying to build or mature an information security program. This can hold especially true in smaller organizations, as the operating environment and security team can often change very quickly. A strong baseline of security policies can help your security program support business operations in these fast-paced environments and help you avoid drifting away from important security practices.

There are a number of different standards that are out there which you can use to identify some starter policies. Which standard is right for you really depends on what industry you’re in, what regulatory compliance standards you need to meet, and what the overall maturity of your security program. The PCI DSS, HIPAA, NIST, and the CIS Top 20 all allude to different policies that they recommend. Additionally, SANS offers a set of policy templates that organization’s can use as a starting point. We’re going to focus on the policies that apply across the board, for the most part. So let’s take a look at robust set of initial policies that can help a small to medium-sized business improve their security program.

Overarching Information Security Policy

We’ll start off with the most obvious here. An overarching Information Security Policy is important because it sets the framework for a culture of security within the organization. It gives executive leadership an opportunity to show that they are serious about security, assign the responsibility for the security program to individuals in the organization, define the environment/scope of security in the organization, and create a framework for the other policies/procedures/standards that the organization uses. Besides these core items, this may be a good place to add any security-related topics that you need a policy for but may not have their own dedicated document, such as password policies, access control policies, account management policies, etc.

Asset Inventory/Asset Management Policy

An Asset Management Policy is often overlooked, even by large and fairly mature organizations. This policy should be one of the first you focus on in your company, as a good asset management and inventory process will make all the other security programs you want to roll out better and more efficient. If you don’t know what you have at any given time, it’s hard to protect it!

Hardening Policy/Configuration Management Policy

Right behind knowing what you have is securing what you have, and that’s where a hardening policy comes into play. This should require and define the basic process/standards used to harden systems and devices within your computing environment. Besides just hardening the systems to begin with, you want to make sure that this policy includes a feedback loop to continually update this hardening process, as new vulnerabilities are identified and mitigated. Finally, either within the policy or as a separate policy you should implement a configuration management plan to control the changes that are made to certain systems/devices with regards to their installed software and configuration.

Personnel Security Policy/Security Awareness Training Policy

A Personnel Security Policy should define the basic expectations surrounding employees and information security, starting with hiring and onboarding then continuing through to termination. Are background checks required of all employees? Are employees required to undergo security awareness training? How often? All of these things can be addressed at the policy level in this kind of document.

Acceptable Use Policy/Remote Access Policy

This is pretty straight-forward and something that most organizations have in place regardless of their security maturity. What may be missing from your acceptable use policy are the security-related items such as acceptable use of critical programs/software/technologies. This should include direction on use of VPN products, Internet browsers, email, etc. An Acceptable Use Policy is a great place to communicate security expectations of your users and have them read and acknowledge these expectations regularly.

Vendor Management Policy

A Vendor Management Policy is used to describe the due diligence process implemented for onboarding new vendors. A risk-based approach when investigating new vendor partnerships can help improve your organizational security without over-expending resources unnecessarily. Identifying the risk-levels you want to use for vendors, the requirements expected of each level of vendor, and the re-investigation period for how often you want to assess your vendors should all be defined.

Disaster Recovery/Business Continuity Policy

Disaster Recovery and Business Continuity plans are of vital importance for your organization’s longevity and ability to respond to disaster scenarios, security incidents, and data breaches. These two can be part of the same policy or different documents, but they are both critical. The Disaster Recovery plan should address what the organization will do to recover from disaster scenarios, what constitutes a disaster, who decides when an event is a disaster, and how often the recovery plan should be exercised. Differently, the Business Continuity Plan should address the priorities for recovering business services to best support continuing business operations, the maximum allowable downtime for assets (based on input from business leaders), the maximum amount of data loss that is considered acceptable, etc. All of these decisions will help drive future information security spending and resource allocation.

Backup/Recovery Policy

In order to meet those business continuity expectations and recover from disaster scenarios, your organization is going to need a back-up strategy. This documented back-up strategy should mandate the format of back-ups, interval of those back-ups, how often back-up recovery/integrity is tested, and designate an individual or team responsibility for verifying back-ups on a regular basis.

Incident Response Plan

Last but most definitely not least, every organization should have some kind of incident response plan. For small to medium-sized businesses, this may be as simple as stating that you will perform some initial information gathering but then call in a designated third-party to perform additional analysis. There’s no problem with this, as the majority of organizations simply don’t have the expertise needed to perform these types of investigations on staff. Alternatively, this plan can detail the expected level of investigation the organization should undergo to verify and recover from security incidents. In either case, there should be some guide for when to declare an incident, what criticality is given to particular incidents, and what the expected response time should be based on that criticality.

Considerations Beyond Security Policies

While policies are a good place to start, they aren’t where you should stop your information security program’s documentation. A solid set of procedures, guidelines, and standards underneath the individual policies can also help form a mature and repeatable security program. Any documentation will help alleviate some of the pain of staff turnover, make sure your security resources can be interchanged in processes to avoid single points of failure, and give you something to iterate on as you figure out what works and what doesn’t, when it comes to preventive, detective, and corrective controls you’re implementing.