Written security policies do not directly improve network security, so some security practitioners sneer at written policy requirements. However, security practitioners in mature organizations not only understand the importance and benefits of written policies, they draft and promote the regulations that declare formally drafted policies as the basic requirement to start down the path to security maturity.
Policies provide a foundation of directives, regulations, rules, and practices that define how each organization will manage, protect, and distribute information. Additionally, regulators often cite a lack of formal policies as negligence as well as cause for higher fines and punishments after a breach.
This article will explore IT security policies through the following topics:
- What Is the Ultimate Goal of an IT Security Policy?
- The Importance & Objectives of IT Security Policies
- 6 Top IT Security Policy Benefits
- 3 Types of Security Policies
- 5 Best Practices for Writing IT Security Policies
- How to Create a Security Policy in 4 Steps
- Bottom Line: Create Policies to Improve Focus
What Is the Ultimate Goal of an IT Security Policy?
The ultimate goal of an IT security policy is to provide a formalized set of rules and policies to benchmark the IT and cybersecurity posture of an organization. This benchmark can be used for a variety of purposes, but will most often be used to:
- Demonstrate that risks are controlled and managed
- Meet compliance obligations
- Measure quality and capabilities of controls and staff
- Mitigate liabilities in the event of a breach
The Importance & Core Objectives of IT Security Policies
The U.S. National Institute of Standards and Technology (NIST) published An Introduction to Information Security (NIST SP 800-12) that declares:
“Information security policy is defined as an aggregate of directives, regulations, rules, and practices that prescribes how an organization manages, protects, and distributes information.”
To organizations new to written policies, starting the process of developing security policies can be intimidating. Yet all organizations deploy security strategies that act as unwritten and unofficial strategies. The key disadvantage to these unwritten security strategies is that when they fail to protect the resources, the organization will struggle to prove to regulators and juries that the IT and security teams executed an appropriate and sufficient cybersecurity strategy.
Written policies, especially those that require regular reports, naturally generate the evidence of compliance. They also show a formal security strategy that has been approved by corporate management.
Most importantly, written policies enable key IT security objectives that will have a daily impact on the organization by formalizing IT security strategies, goals, and objectives; managing user behavior; and measuring IT security success.
Formalize IT Security Strategies, Goals, & Objectives
Written policies provide written instructions that can be used to show the intended strategy of the organization. Most strategies focus on the key objectives of information security:
- Confidentiality: Allow access to specific data only to the users that need access
- Integrity: Prevent accidental or unauthorized modification of data in storage or in transit
- Availability: Provide continual access to data and systems for legitimate users
However, not all existing practices will always be found to incorporate best practices or adequately address these key objectives. The process of developing a security policy helps the IT security team to reflect on and improve the current practices as they are forced to write them down and compare them against goals and compliance requirements.
The policy creation process also helps to align the IT security goals and objectives with those of the business as policy goes through review by non-technical executives affected by the policies. In the end, the organization should enjoy the benefits of a policy that provides formal strategies, goals, and objectives that enable business growth within the protection of validated IT security strategies.
Manage User Behavior
Policies provide rules for acceptable use, access, and penalties for non-compliance for users of all kinds, from guest users on the public Wi-Fi network to administrative access of data center servers. These written policies then guide the settings within identity and access management (IAM) or privileged access management (PAM) tools.
Of course, IAM and PAM tools can be established without written policies, but written policies ensure consistent rules applied across the organization. The formal policies also provide a standard that can be compared against practices to determine if the practices are sufficient and within compliance.
Measure IT Security Success
An effective policy sets clear expectations for the IT security team. Reports required by policies should show compliance with the policy and enable the IT security team to measure their success to meet the goals of the policy.
While employees always strive for success, falling short can also be used to justify increases in resources. For example, if reports required by the patch management policy show that the patching of critical updates takes longer than desired, the management can consider adding more resources or outsourcing some functions.
6 Top IT Security Policy Benefits
Organizations of all sizes tend to avoid the hassle of documentation because the task seems overwhelming, tedious, and constraining. However, an effective security policy delivers six key benefits: IT hardening, employment defense, executive and board member peace of mind, litigation protection, compliance easy button, and improved operational efficiency and resilience.
IT Hardening
Developing an effective security policy will naturally enable a security process that hardens the IT environment against attack. Although some might consider compliance the primary motivation for written policies, the process of creating the policy forces security teams to evaluate systems more rigorously and address issues that might be overlooked in day-to-day operations.
Employment Defense
Despite the best efforts of the IT team, people will still click on phishing links, zero-day vulnerabilities will still be discovered, and company resource constraints may require some vulnerabilities to remain exposed. Although compliance with security policies can reduce the risk, attacks may still succeed in damaging the organization.
In many cases, executives may initially look for a scapegoat to take the blame for an incident and IT or security teams often will be targeted. An IT or security team that can demonstrate compliance with an executive-approved security policy also shows that best efforts were made to prevent possible breaches. This documentation can protect employees against unfair treatment after a breach and protect their jobs.
Executive & Board Member Peace of Mind
Effective security policies require reports that can be shared with non-technical executives to enable confidence in the IT and security teams. Policies reduce technical details into numeric reports and easy-to-understand metrics that make the status of security processes understandable and accessible to non-technical executives.
Clear reports enable smooth communication with executives and the board of directors of an organization to help build confidence in the security posture of the organization. Such reports not only demonstrate that the organization considers information security a high priority, but also build confidence that can translate into improved support for additional resources.
Litigation Protection
In the event of a breach or successful cybersecurity attack, government agencies or stakeholders may attempt to pursue legal action against the organization. Fortunately, legal standards generally only require “reasonable efforts,” which can be supported with the documentation from an effective security policy and the reports that demonstrate the policies have been implemented.
Organizations without formal reporting and processes will need to scramble to figure out what documentation may be required to support past efforts and then hope they still have the archival logs or other data to create that documentation. Organizations with formal documentation and reporting will already have a significant portion of their evidence ready to present with minimal effort or business disruption.
Compliance Easy Button
An effective security policy should be designed to reflect the compliance requirements of the organization. Auditors always ask for written policies to help them easily understand the objectives of the organization and the type of evidence they can expect to receive.
Fulfilling a written policy that has already conformed to a compliance framework makes it easy for the organization to satisfy the regulatory requirements. The organization’s regular internal reports will naturally provide evidence of compliance without any additional effort or steps.
Improved Operational Efficiency & Resiliency
An effective portfolio of security policies can help the organization:
- Recognize end-of-life hardware and software for replacement
- Quickly recognize infrastructure under strain from attack, failure, or workload
- Verify settings and integration between systems
- Ensure resilience of systems to minimize downtime
- Ensure integrity and availability of data
- Document uptime for internal and customer service level agreements (SLAs)
The survival of the business depends upon uptime and protected assets. Formalized documentation of security processes provide an internal checklist to protect assets, maintain uptime, and minimize mistakes.
Written policies also help with IT personnel transitions by providing documentation of expectations and reports of past activity. These will combine to save time by helping new IT employees grasp the status and expectations of the organization with less training.
3 Types of Security Policies
When developing a comprehensive set of security policies, an organization can get lost in the details. The SANS institute alone provides templates for more than 60 different policies! These granular policies help a mature organization, but an organization just getting started needs a bit more focus.
The three types of policies defined by the National Institute of Standards and Technology (NIST) Special Publication 800-12 include program, issue-specific, and system-specific policies.
Program policies provide strategic, high-level guides of the overall information security program. These can be singular programs, such as this program policy for the University of Arizona, that provide an overview of the goals and objectives of the security program. These policies are intended to be evergreen and not require frequent updates, and often will reference other types of policies in an appendix that can be updated more frequently without requiring updates for the program policy itself. Program policies tend to be too vague to measure or verify. Other types of non-security program policies might include business continuity or risk management.
Issue-specific policies provide directed guides for specific components of the information security program, but at a level of abstraction that describes goals, objectives, and reporting requirements instead of naming specific tools, techniques, and settings. These policies need to be reviewed periodically to ensure they remain current in the face of organizational, technological, or compliance changes. Examples of issue-specific security policies include network security, password, endpoint, and encryption policies. Some issue-specific policies may fall under multiple program policies such as data backup (security, business continuity) or acceptable-use policies for employees (security, HR).
System-specific policies describe how issue-specific policies will be applied and enforced on specific systems. For example, how the network security, user access, vulnerability management, and change control policies might be enforced for a specific firewall or a classification of servers in a data center. These detailed policies will be enforced through settings on the devices or through centralized software that can manage the devices.
Common Issue-Specific Policies
For an organization beginning to implement security policies, the focus should start with relevant issue-specific policies. The specific key policies will depend upon the organization. Although many will start with access, network, endpoint, and password policies, these priorities reflect a traditional IT environment. A small virtual office of five stock brokers using Google Workspace might instead focus on policies for data security, data backup, and remote access policies to comply with SEC and FINRA requirements.
Here are 10 common issue-specific and related policies:
- Acceptable Use Policy (AUP)
- Instructs the organization how end users are permitted to use IT systems and services (computers, networks, data, internet, email)
- Related policies: security awareness training policy, executive and administrative access policy
- Access Policy
- Instructs an organization how to classify, enforce, and manage access, authentication, and accounting of users across various system and data classifications
- Related policies: physical access policy, system access policy, privileged access policy, remote access policy (may include remote desktop [RDP] or virtual private network [VPN] policies), password policy, identity and access management policy, multi-factor authentication (MFA) policy, vendor management policy
- Application Security Policy
- Instructs an organization how to secure code development and the connections to other corporate resources
- Related policies: application programming interface (API) security policy, database security policy, application development policy
- Cloud Security Policy
- Instructs an organization how to secure access, data, networks, and applications on cloud-based resources
- Related policies: cloud use policy, software as a service (SaaS) security policy, infrastructure as a service (IaaS) policy
- Data Management Policy
- Instructs an organization on the retention, management, and security of different classifications of data
- Related policies: data retention policy, insider threat protection policy, encryption and cryptography policy, information security policy, data and asset classification policy, regulated data policy
- Disaster Recovery Plan
- Instructs an organization how to proceed with business recovery under various emergency circumstances
- Related policies: Backups policy, redundancy policy, capacity planning policy, stress testing policy
- Endpoint Security Policy
- Instructs an organization how to secure access, data, and applications on user-accessed endpoints that connect to the organization’s network and other resources
- Related policies: endpoint security policy, bring-your-own-device (BYOD) security policy, mobile device policy, server security policy, container security policy
- Incident Response and Monitoring Policy
- Instructs and organization how to detect, identify, validate, track, mitigate, remediate, and manage potential security incidents
- Related policies: log tracking and audit policy, attack-specific policies (ransomware, DDoS, etc.), data breach response policy
- Network Security Policy
- Instructs an organization how to secure access, data flows, and monitor connections between users and data
- Related policies: firewall security policy, network security policy, email protection and security policy, wireless network and guest access policy
- Vulnerability Management Policy
- Instructs an organization how to locate, validate, prioritize, mitigate, and track vulnerabilities
- Related policies: patch management policy, change management policy, vulnerability scanning policy, penetration test policy
5 Best Practices for Writing IT Security Policies
An organization can create an effective security policy by following five key best practices, focus on what to do rather than how, make policies practical, right-size policy length, keep policies distinct, and make policies verifiable.
Focus on What to Do, Not How
Technology changes so quickly that a policy will usually not be able to keep up with the technical details such as security tools and IT architecture specifics. When writing any IT-related policy, the policy should focus on the high-level goals, key deliverables, and compliance requirements.
The IT team will then use those requirements in combination with their budget and personnel constraints to develop an appropriate solution. Too many details either force the policy to be updated constantly or lock the IT team into obsolete tools, practices, or perspectives that may ultimately undermine instead of strengthening security. Where needed, exhibits or additional reports can be used to provide details that may need to be changed more frequently than the policy itself.
Some organizations will consider system-specific policies an exception that requires detailed descriptions of tools, settings, and allowed users. However, others keep system-specific policies at a high level and maintain specific work instructions that maintain the details. This is a matter of preference for the individual organization.
Make Policies Practical
Security policies won’t be successful if they do not work for the team responsible for the policy, are not understandable, or don’t fit the organization. In some cases, these objectives will come into conflict and the policy creating team will need to work with stakeholders to enable an effective balance.
Stakeholder-Friendly Policies
Stakeholder-friendly policies will be more readily adopted by IT and security teams responsible for implementing the policy or the users affected by them. When policies demand too many changes, impractical requirements, or exceed the resource constraints, the policies may be undermined, circumvented, or ignored.
To enable stakeholder friendly policies, don’t dramatically change practices or add unnecessary details and instructions. Unless required by compliance or best practices, build off of existing practices to enable rapid adoption by both affected users and the teams enforcing the policy.
Additionally, use titles instead of names and tool categories instead of specific security tool names. This prevents the need to change the policy for every tool change, personnel change, or outsourcing engagement.
Understandable Policies
Not all readers have English as their first language, especially in international companies attempting to standardize policies worldwide. When drafting policies, use simple language written plainly for both the non-technical and non-legal audience.
During the drafting process, the document should be distributed to executives, legal counsel, and key staff members responsible for implementing the policy. Any confusion, vagueness, or uncertainty should be addressed and eliminated before approving the policy.
Fit Organization Needs
Tools and processes must fit the true needs of the organization and should not be followed blindly or without thought. Although every organization should begin drafting policies based upon existing practices and capabilities, this can lead to a trap of preserving incomplete processes into written policies. The organization should carefully examine their environment and ensure the policy reflects their true needs.
For example, an IT team of a hospital may use a commercial tool to conduct vulnerability scanning of their IT environment, but the tool may only scan PCs, network devices, and servers, which leaves an enormous range of healthtech devices unscanned for vulnerabilities. Their policy requirements should not reflect the limited devices currently scanned, but the full range of devices that need to be included in the vulnerability management process.
Policies should also have minimal exceptions and those exceptions should be documented. If the C-suite executives insist on being exempted from the password policy, then they should also be prepared to justify that exemption in court once the company suffers a breach. Just like employees, senior management should understand, agree with, and be bound by security policies.
Right-Size Policy Length
Policies should be no longer and no shorter than needed. IT and security teams often favor shorter policies because the lack of defined requirements provide them with maximum flexibility for execution. However, the lack of defined requirements often leaves gaps in requirements or makes the policies hard to verify for management or compliance.
On the other hand, attorneys often feel compelled to lock down as many details as possible to make verification more simple and to clarify as many points as possible. Unfortunately, this often tends to lead to over-prescriptive requirements that lock an IT team into the requirements of the moment and leave little room for keeping up with a dynamic IT environment.
These opposing forces must be balanced. IT teams, executives, and attorneys must work together to enable a document with sufficient detail so that the IT team can clearly demonstrate compliance with the policy, but not so much detail the policy becomes a shackle on the vulnerability management process.
Keep Policies Distinct
Security and compliance teams will look for information in expected policies. For example, to look up policies regarding endpoint protection, most would first look for an overall security policy or a specific endpoint protection policy. To bury the information in a vulnerability management policy is unintuitive and may lead to confusion.
Security policy creation teams should also avoid the temptation to copy-paste elements from other existing policies, such as a password policy, into semi-related policies (remote access, endpoint protection, etc.) for completeness. Unless the documents are linked to enable automatic updates, the copied information will rapidly become out of date. Instead of inserting sections of the other existing policies, reference them as needed.
Policies should be individually comprehensive with minimal overlap. Overlap with other policies can lead to language conflicts, uncertainties, and gaps in compliance and security. In the event an organization decides to mix policies, an index or guide should be produced to help team members locate policy information rapidly.
Make Policies Verifiable
Vague policies with nebulous, undefined deliverables satisfy only the requirement to have a policy, not the requirement to have a useful one. Effective policies define the deliverables clearly so that the IT or security team will have no difficulty satisfying policy requirements.
The security process should be measurable and testable to prove compliance with the policy as well as any relevant compliance frameworks. Reporting requirements should document metrics for measurement, define needed evidence (log files, vulnerability scans, etc.), the frequency of reports, and who should receive the reports.
How to Create a Security Policy in 4 Steps
Organizations large and small can create a functional security policy by following four key steps: determine the security policy principles, verify the vulnerability management policy, approve the vulnerability management policy, and review and modify the vulnerability management policy.
Determine the Security Policy Principles
The person or team drafting the policy will first need to determine the critical rules and steps within the vulnerability management policy. For example, some fundamental questions to answer include:
- Who is responsible for the security process or standard?
- Which people, assets, or systems will be covered by the security process or standard?
- What are the security processes, standards, components, and priorities for each?
- How can the security process or standard be validated and verified?
- What reports are needed to establish and measure success and compliance for the security process or standard?
Don’t know where to start? Write down the current practice. Most IT teams have at least an informal process for nearly all security practices, even if they are not written down or monitored. This first draft can simply be notes. Formal paragraphs and language can come later after the basic principles have been outlined.
Verify the Security Policy
With the basic rules or principles in place, the policy development team should verify them against external requirements and practical limitations.
External Security Policy Requirements
Every organization faces general or specific regulations from international, federal, state, or local governments. Additionally, the organization may be forced or choose to comply with compliance frameworks (NIST, PCI DSS, etc.) and industry standards.
Some compliance standards will be broad and vague, but others will be detailed or have specific requirements. The policy development team needs to check these external regulations and revise any rule that does not meet the compliance requirements.
Practical Security Policy Limitations
Most organizations have limited resources, and often idealized policies do not take these limitations into account. The security policy development team should test the proposed rules with the IT and security teams. If these teams cannot comply with standards and requirements with their current resources, the organization will need to adjust the rules or resources as necessary.
For example, when developing a patch management policy, the IT team may not have the ability to meet the patch management schedule requirements with the current tools and staffing resources. The organization will then need to consider adjusting the schedule (if allowed by compliance requirements) or adding additional resources (tool upgrades, staffing increases, outsourcing, etc.).
Approve the Security Policy
After verification of the proposed security policy rules, the rules need to be formalized and approved by the organization’s management. Now is the time where rough notes need to be revised into formal paragraphs, tables, and appendices.
Once drafted, pass the policy to corporate management and legal counsel for review and approval. The policy can be modified as required and the final draft should be signed by the executives of the organization to ratify and acknowledge the requirements.
Review & Modify the Security Policy
Even though the security policy is approved in step three, the organization, IT resources, and regulations will change over time. All policies should be living documents that evolve as the organization changes. and should be periodically reviewed and updated. Generally, policies will be reviewed on a fixed schedule (quarterly, annually, bi-annually, etc.); however, notable events such as dramatic changes to IT architecture, adopting significantly different security tools, or a security breach may merit off-schedule review.
Bottom Line: Create Policies to Improve Focus
Organizations tend to view formal paperwork as a burden, but effective IT security policies enable organizations to improve their security posture, spend less time on compliance, and to eliminate many worries. With current and effective policies, Large and small businesses, non-profit organizations, and even government entities can validate their presumed security posture and gain the confidence to focus on challenges more critical to their core mission.
To read more about related topics, consider:
