Guidelines for building security policies
April 17, 2017
Building a successful set of security policies will ensure that your business stands the best possible chance of protecting company information, as well as safeguarding your customers, personnel, and reputation. The guidelines presented here will help you define the necessary components for building effective policies that meet the needs of your company.
From the guidelines:
You should approach a security policy as if it were an umbrella and make sure that it covers all aspects of information and/or systems usage. This can be as narrow or broad as your company operations. Start with software, then move onto hardware, and finally cover services or processes.
Gathering the details
To construct your security umbrella, you’ll need to build a team of IT and non-IT staff to ensure cohesion and root out process-based areas with which IT may not be familiar. This team will determine the security policies that will be put in place. Include requirements such as HIPAA or Sarbanes-Oxley to ensure that your policies are built with these as a foundation for business operations.
Start with the basic elements; accounts, passwords, workstations, and mobile devices. Work up to network hardware, then servers and applications. Account for existing software, hardware, and processes, as well as eventualities (security breaches, employee terminations, evaluating potential threats, etc.) From here you can build your policies working from the outside in; physical security, operating system security, application security, and so forth.
It’s also a good idea to conduct a risk analysis to identify potential areas of weakness, failure, or compromise in your environment. Group the results based on high, medium, and low risks. In similar fashion, you should next examine business services and categorize which ones are critical, important, or optional. Build your policies based on each.
For instance, email and remote access are likely critical and you should invest a lot of time and attention in securing these. Test systems may be important but merit less time, and fax machines or instant messaging might be low priority. Include what to do if a system or service fails or is breached. Can you bring up a spare or work with a vendor? Should you contact local law enforcement? Identify roles and responsibilities for security incident response.