Many security professionals think that if they have done the hard work of securing their organization, that should be enough. There is, however, a next step: Documenting policies.
Even though drafting IT security policies can be a pain, formal policies provide a valuable resource to protect both the IT team and their organization.
In this article, we’ll briefly touch on what policies are; tips for writing them; and the advantages policies provide for compliance, transitions, and IT team liability.
Written Policies vs. Implemented IT Policies
IT practitioners sometimes become confused about the definition of a security policy because security practitioners use the word “policy” as terminology for two very different purposes:
- Implemented IT policies incorporated into operating system, firewall, or network rules
- Written documentation
Written policies and IT policies are certainly related, but they are distinct, and each needs to be implemented separately to create a mature security and compliance practice.
Written security policies
Written security policies should ideally be documented in a shareable digital format such as Google Docs or Microsoft Word files. However, even a handwritten spiral notebook could work for a small organization.
Written policies define the standards and objectives for an organization. While many policies may exist in an organization, IT security policies should focus specifically on the guidelines, principles, minimum standards, and goals that will be used to secure IT infrastructure.
Policies should be drafted to cover major IT infrastructure such as: networks, endpoints, access management, cloud resources, Internet of Things (IoT) devices, and vulnerability management. Any asset or control used to secure the organization should have an accompanying policy to define how the IT department intends to use it.
Policies can cover multiple technologies, but should be labeled clearly for internal and compliance auditor reference. For example, an Access Policy could have clearly labeled sections to define Password Policy, User Access, Privileged Access, Access Review Processes, and Remote Access because each of these access categories may be required to be reviewed by an auditor.
Also read: How to Create an Incident Response Plan
Implemented IT policies
Written IT policies set the guidelines, but implemented IT policies achieve them. While there probably should be different terms to differentiate between these different uses for “policy,” we can blame Microsoft and other IT behemoths that have blurred the use of the word.
For example, Microsoft developed a Group Policy Management Console to manage implemented policies applied to different user groups in a Windows environment. This can represent the implementation of a written policy put into action, but many inexperienced IT practitioners only know the Windows definition.
This mixing of terminology causes big headaches for compliance auditing. Some unfortunate IT teams confirm that they have policies, but become frustrated when a compliance auditor declares their screenshots of implemented policies as inadequate.
Security Policy Tips
For organizations or teams that don’t have written policies, creating them doesn’t have to be hard.
Start with what you have
It is okay to start by writing down what you have implemented in your IT environment. Take the implemented policies and then write them into a document. If, when compared against a target standard, the practice does not meet the standard, it can be modified in both the written and the implemented policy.
Use reference documents
Someone out there published their version of the policy you want to create. Don’t be afraid to find something to use as a reference or starting point.
Google the policy you want to write and add additional search terms such as “sample,” “template,” or even “.gov” or “.edu.” Public entities, especially universities, often publish their IT policies on their websites.
When using reference documents, be sure to edit the document carefully to ensure it reflects the actual policies of the organization and that the language feels natural to the IT staff. Published policies can sound awkward because they may have been written by lawyers instead of IT professionals, so some tweaks may be needed.
Pass it by legal
Written policies may come under scrutiny if the organization suffers a breach. Don’t take on all of the legal burden within the IT department. Pass the written policies by legal counsel (or at least company management), and have them sign off on the non-technical aspects of the document.
Also, ask legal to verify what compliance standards the organization needs to meet. All organizations fall under some regulatory compliance standard—even if they are an exception due to limited size or revenue.
Policies should be written to meet or exceed regulatory requirements. Be aware of what standards may be coming as the company grows, and build out your policies to reflect where you need to be in the next two to five years.
If the organization cannot currently meet immediate or future compliance standards, the policies should note what compensating controls are in place and the future plans of the organization to reach compliance. In this case policies also document the ongoing balance between compliance requirements and current business realities.
Also read: How to Comply with GDPR, PIPL and CCPA
Advantages to Written IT Security Policies
The key advantages to written IT security policies apply to compliance, transitions, and IT team liability.
Compliance
Almost all regulatory compliance requires written policies. It is impossible for compliance auditors to check every computer and application setting, so instead, they start with checking the written policies of an organization.
Written policies provide the first step for any compliance audit and are considered a fundamental requirement for mature IT security. Policies written to match a specific regulation can also provide a checklist for IT teams of possible security improvements that may be needed.
Keep in mind that compliance requirements will not ensure appropriate or sufficient security. However, checking against compliance requirements can help an organization to at least adopt some minimum requirements.
Also read: Top GRC Tools & Software
Transitions
Nothing is worse than walking into a new IT job, and there is no guidance or instruction for how to do the work. IT teams usually struggle to keep up with demands, and without written policies, new employees must also find time to figure out what the security was supposed to be and if any of the security settings meet those goals.
Written policies at least provide half of the picture. By writing down what security settings should be in place, an employee can survey the environment to locate any devices that fail to meet those settings.
Written policies can improve the efficiency for training new IT staff and for reducing the time for new IT employees to learn an organization’s IT environment. To be useful, consider adopting plain language practices to make sure the language in your policies remains clear and basic without too much legal jargon.
IT team liability
After any IT security breach, an organization may face lawsuits or even criminal charges for violating laws. Some organizations may face punishment from regulatory groups such as the Payment Card Industry (PCI) for credit card breaches or the Security and Exchange Commission (SEC) for financial breaches.
At the very least, the managers of the company will investigate and they’ll need the IT security team to prove their security plan was in place. Without written policies, the IT department may need to defend each breached machine’s security settings and individually argue their suitability.
If the IT team matches standards established within written policies that were also approved by management, the defense becomes easier. The implemented policies that match written policies demonstrate that the security levels used were approved in advance and implemented as required.
After a breach, some policies and security may be found insufficient and require changes. Still, an approved IT policy provides some insurance against the IT team becoming the scapegoat.
Start Writing
Every organization can easily create written policies.
Written policies do not need to be formal, but keep in mind that in the event of a breach, these policies may be used as exhibits in court. Rude or sarcastic language may be funny now, but are likely to be a lot less funny under cross examination from an angry attorney after a breach.
While we have illustrated three key benefits to written policies, as an organization matures, the written policies also help provide a framework for growth and future benefits. For example, as new technology is adopted, written policies will help the team to create checklists of security controls that must be implemented for that new cloud environment or to adopt a zero trust authorization.
To reap these benefits, IT security teams simply need to start writing. As we demonstrated above, this does not have to be an overly complex or time-consuming process. So, cover your associates (CYA), and start writing now, so you can have those annoying policies completed before the inevitable security breach arrives.
See our top picks for the Best Incident Response Tools and Software
