Best Practices
How Do I Write A Policy?
May 12, 2021
With such a straightforward title, how could this possibly be a difficult question to answer? Most people who’ve ventured into policy writing start a few sentences and quickly realize how daunting the task becomes.
Policy language is typically a guiding principle. The US Constitution is a great example of a policy. It prescribes ideals that may or may not stand the test of time, and it’s open to interpretation. There are hundreds of thousands of laws rooted correctly or incorrectly within concepts found in the Constitution. I like to think of policy as scaffolding or a blueprint, a tool that can be used to construct almost anything. Once the policy is in place, it can be disseminated to tens of thousands of other people to serve as a guiding light for specifics that may be required to ensure objectives are met.
This is such an important question to ask yourself. I’ll be talking about my opinion based on my experiences. Still, I certainly would understand that some of my readers may disagree with me, and I genuinely would be happy to listen and incorporate the community’s thoughts into my understanding. Policy language must speak to overarching objectives without becoming too granular. If a policy contains specific people, dates, metrics, or brand names, it’s probably morphing into a standard or a procedure. Let’s look at an example.
Documented security and privacy awareness training must be developed as part of the employee and contractor onboarding program.
The above statement is a good example of policy language. It has a clear subject, “Documented security and privacy awareness training.” It has the definitive “must” to indicate that it’s required. It states the “when” as part of a process rather than specific dates.
All employees and contractors are to receive HIPAA training through Udemy within two weeks of date of hire. Jane Smith is in charge of verifying that training was completed. The minimum acceptable score is 90%.
The above statement is not policy language. Further, it’s an exceptionally poorly written procedure because it leaves out countless details related to execution.
From a high-level view, your standards and procedures contain specific language that references your policies. There’s actually a fair amount of debate in the compliance ecosystem about what constitutes a standard. I’ll present an opinion on the subject, but I’ll refrain from discounting other interpretations because standards have evolved to mean different things to different people. Let’s tackle procedures before moving on to the standard minefield.
Procedures
Think of procedures as a recipe or a playbook. Procedures should answer questions like: “Who specifically is responsible for this task?”; “What are the steps required to perform the task?”; “Which systems are involved in performing the tasks?”; “When should the task be performed?”. The fascinating thing about procedures is that many procedures can be written from the perspective of many different people but still apply to a specific section of a policy. Let’s take this article from a Business Continuity and Disaster Recovery Policy: “Backups of information and software must be made, and tests of the media and restoration procedures must be regularly performed at appropriate intervals.” If your organization relies on even the most basic technology, this statement will apply to your customer CRM, your email, your website, shared file systems like Google Drive or Sharepoint, etc. Each of the procedures must satisfy the policy language and include the who, what, when, and where. Furthermore, the various departments in your organization each hold the knowledge required to write relevant procedures. It is critical to delegate procedure writing to subject matter experts, those who understand the operational flow of the company. There are real challenges associated with ensuring the right people can access, edit and approve procedural language.
Standards
Where policy addresses broad concepts (let’s make a chocolate cake) and procedures address the steps to get there (mix, heat the oven), standards might be considered the list of ingredients. Standards tend to reference discrete values, for example:
Passwords must contain at least 12 characters.
They are instrumental because they can be referenced (or cited) by multiple policies and procedures. When a standard changes, it’s quite possible that the policy will remain unchanged. In some cases, even the procedure will remain unchanged, particularly if you reference the standard in your procedure. Well-written procedures will call out a standard, as in this example.
Our Client CRM is accessed by employees using an approved username and password
As you can see, the procedure does not have to include the standard definition of an appropriate password because those details can be maintained within the standard. Keeping this separation brings added benefits when updating the standard. It wouldn’t be surprising to see language about passwords in dozens of different procedures. Since the standard is stored in a single location, all that needs to be changed is the standard itself, saving hours of tedious work.
At this point, we’ve discussed and illustrated what is and what is not a well-written policy statement, how policy differs from the procedure, what a standard is, and how multiple policies or procedures can reference one. These foundational concepts are good for your understanding of what not to do, but how do they help you get started? The Internet abounds with starting points. A quick google search for policies will reveal hundreds of boilerplate policies for a variety of needs. If you need a fairly generic policy and a small business, these may serve as a good starting point. Still, if your business is data-intensive or subject to outside governmental or institutional regulations, it’s doubtful that these highly generic templates will fully meet your compliance needs as is or that they will grow with you. There are so many unknown unknowns at this point. Do you have strict regulations or frameworks that apply to your business? Do you have clients who demand specific certifications? Do your business units fall under differing industry or international regulations and compliance requirements? If these questions apply to you, the expense associated with obtaining the correct policies jumps to thousands of dollars. In many cases, the policies come without guidance or expertise. It’s easy to waste time and money by going down dead-ends. There are just as many companies and individuals out there offering consulting services targeting policy and security planning. In many cases, this process starts with a baseline security assessment. You’ll find that the pricing can vary widely. An engagement can last from several weeks to a few months, depending on the complexity of your organization. A security assessment is designed to review all of your resources to determine what your security posture looks like. Are you taking measures to lock down critical resources? Are you vetting employees, contractors, and vendors? Are you exposing information that could lead to a successful breach? How sensitive is your data? You will learn a lot from a security baseline assessment, and, assuming you’ve selected a reputable organization, it’s almost always a good starting point. It’s a good idea to already understand your objectives before entering into an assessment. Are you trying to win some new business that requires a SOC2 or HITRUST certification? Are you trying to bring insurance rates down? Are there legal requirements with which you must comply? Make sure that you have clear objectives. This will save you time and money in the long run.
Policy language should be structured according to grouped concepts. As an example, if you were to include a topic within a policy related to employee background checks, it should be grouped under Human Resources -> Hiring -> Background checks. By effectively grouping concepts, we make it easier to find related policy language. We also compartmentalize concepts so that experts in each area can review concepts they are most familiar with. In the security world, there are several expected top-level policy titles, including:
Access Control
Access control policies are high-level requirements that specify how access is managed and who may access information under what circumstances. For instance, policies may pertain to resource usage within or across organizational units or based on need-to-know, competence, authority, obligation, or conflict-of-interest fact.
Audit Logging and Monitoring
Audit logging and monitoring policies are designed to provide accurate and comprehensive audit logs to detect and react to inappropriate access to or use information systems or data.
Business Continuity and Disaster Recovery
A business continuity policy is the set of standards and guidelines an organization enforces to ensure resilience and proper risk management. Business continuity policies vary by organization and industry and require periodic updates as technologies evolve and business risks change.
Configuration Management
This policy aims to set practices for establishing the mandatory requirements for the installation, configuration, and implementation of information technology systems.
Data Protection and Privacy
This policy defines who has access to data and enumerates the tools and policies used to restrict access to that data.
Education, Training, and Awareness
A Security Education, Training, and Awareness (SETA) program is defined as an educational program designed to reduce the number of security breaches that occur through a lack of employee security awareness.
Endpoint Protection
Endpoint Protection is the practice of securing endpoints or entry points of end-user devices such as desktops, laptops, and mobile devices from being exploited by malicious actors and campaigns. Endpoint security systems protect these endpoints on a network or in the cloud from cybersecurity threats. Endpoint security has evolved from traditional antivirus software to comprehensive protection from sophisticated malware and evolving zero-day threats.
Incident Management
The purpose of the incident management policy is to provide organization-wide guidance to employees on the proper response to an efficient and timely reporting of computer security-related incidents, such as computer viruses, unauthorized user activity, and suspected compromise of data.
Information Protection Program
Information protection involves mitigating risks through secure systems and architecture that eliminate or reduce vulnerabilities. It deals with both operations and technology to try and create a successful method for eliminating vulnerabilities in the system that can be used to gain unauthorized access or compromise or steal data. It may include facets such as vulnerability management, penetration testing, and technological solutions such as firewalls, antivirus, data loss prevention, and encryption.
Mobile Device Security
Mobile devices, such as smartphones and tablet computers, are important tools for the organization, and Company supports their use to achieve business goals. However, mobile devices also represent a significant risk to data security. If the appropriate security applications and procedures are not applied, they can be a conduit for unauthorized access to the organization’s data and IT infrastructure. This can subsequently lead to data leakage and system infection.
Network Protection
Network administrators and IT teams use the Network Protection policy to control their network environments and protect their organizations against evolving threats. Network Management policy streamlines security policy design and enforcement. It applies rules and best practices to manage firewalls and other devices more effectively, efficiently, and consistently.
Password Management
This policy provides guidelines for the consistent and secure management of passwords for employees and system and service accounts. It includes mandates on how passwords should be generated, used, stored, and changed, as well as for instructions for handling password compromises.
Physical and Environmental Security
Physical and Environmental Security refers to measures taken to protect systems, buildings, and related infrastructure against threats associated with their physical environment.
Portable Media Security
Portable media such as USB keys, flash memory, CDs/DVDs, etc., are crucial for daily business. However, portable media is easily lost or stolen and may cause a security breach.
Risk Management
The purpose of the risk management policy is to guide the management of risk to support corporate objectives, protect staff and business assets and ensure financial sustainability.
Third-Party Assurance
This policy is designed to ensure that the organization’s third-party suppliers, contractors, and vendors take the expected steps to meet organizational and regulatory security requirements.
Transmission Protection
This policy details security measures to guard against unauthorized access to ePHI transmitted over an electronic communications network.
Vulnerability Management
This Policy is designed to establish the rules for the review, evaluation, application, and verification of system updates to mitigate vulnerabilities in the IT environment and their associated risks.
Wireless Security
This policy outlines the methods used to prevent unauthorized access or damage to computers or data using wireless networks, including Wi-Fi networks. While this isn’t a comprehensive list, it does serve as a solid foundation upon which to build. Each of the policies shown above contains articles that outline how your organization intends to act. At this stage, it can be tempting to write a set of policies that speak to a single compliance objective. This places limits on your ability to add other frameworks in the future. If you craft policy language that addresses, for example, SOC2 requirements, you will find that the language may be too specific or too general for HIPAA or HITRUST should you need to add these in the future. Take the time to normalize your policy language-futureproof your organization by writing policies that describe your organization and its values. As frameworks come and go, your policy will stand on its own. PolicyCo is a platform designed specifically for the challenges associated with bridging the gap between policy and compliance. Our world-class editor enforces strict relationships between articles, standards, procedures, controls, and evidence that all live in one secure platform. Want to learn more about our compliance management software platform?
Best Practices
How Do I Write A Policy?
May 12, 2021
With such a straightforward title, how could this possibly be a difficult question to answer? Most people who’ve ventured into policy writing start a few sentences and quickly realize how daunting the task becomes.
Policy language is typically a guiding principle. The US Constitution is a great example of a policy. It prescribes ideals that may or may not stand the test of time, and it’s open to interpretation. There are hundreds of thousands of laws rooted correctly or incorrectly within concepts found in the Constitution. I like to think of policy as scaffolding or a blueprint, a tool that can be used to construct almost anything. Once the policy is in place, it can be disseminated to tens of thousands of other people to serve as a guiding light for specifics that may be required to ensure objectives are met.
This is such an important question to ask yourself. I’ll be talking about my opinion based on my experiences. Still, I certainly would understand that some of my readers may disagree with me, and I genuinely would be happy to listen and incorporate the community’s thoughts into my understanding. Policy language must speak to overarching objectives without becoming too granular. If a policy contains specific people, dates, metrics, or brand names, it’s probably morphing into a standard or a procedure. Let’s look at an example.
Documented security and privacy awareness training must be developed as part of the employee and contractor onboarding program.
The above statement is a good example of policy language. It has a clear subject, “Documented security and privacy awareness training.” It has the definitive “must” to indicate that it’s required. It states the “when” as part of a process rather than specific dates.
All employees and contractors are to receive HIPAA training through Udemy within two weeks of date of hire. Jane Smith is in charge of verifying that training was completed. The minimum acceptable score is 90%.
The above statement is not policy language. Further, it’s an exceptionally poorly written procedure because it leaves out countless details related to execution.
From a high-level view, your standards and procedures contain specific language that references your policies. There’s actually a fair amount of debate in the compliance ecosystem about what constitutes a standard. I’ll present an opinion on the subject, but I’ll refrain from discounting other interpretations because standards have evolved to mean different things to different people. Let’s tackle procedures before moving on to the standard minefield.
Procedures
Think of procedures as a recipe or a playbook. Procedures should answer questions like: “Who specifically is responsible for this task?”; “What are the steps required to perform the task?”; “Which systems are involved in performing the tasks?”; “When should the task be performed?”. The fascinating thing about procedures is that many procedures can be written from the perspective of many different people but still apply to a specific section of a policy. Let’s take this article from a Business Continuity and Disaster Recovery Policy: “Backups of information and software must be made, and tests of the media and restoration procedures must be regularly performed at appropriate intervals.” If your organization relies on even the most basic technology, this statement will apply to your customer CRM, your email, your website, shared file systems like Google Drive or Sharepoint, etc. Each of the procedures must satisfy the policy language and include the who, what, when, and where. Furthermore, the various departments in your organization each hold the knowledge required to write relevant procedures. It is critical to delegate procedure writing to subject matter experts, those who understand the operational flow of the company. There are real challenges associated with ensuring the right people can access, edit and approve procedural language.
Standards
Where policy addresses broad concepts (let’s make a chocolate cake) and procedures address the steps to get there (mix, heat the oven), standards might be considered the list of ingredients. Standards tend to reference discrete values, for example:
Passwords must contain at least 12 characters.
They are instrumental because they can be referenced (or cited) by multiple policies and procedures. When a standard changes, it’s quite possible that the policy will remain unchanged. In some cases, even the procedure will remain unchanged, particularly if you reference the standard in your procedure. Well-written procedures will call out a standard, as in this example.
Our Client CRM is accessed by employees using an approved username and password
As you can see, the procedure does not have to include the standard definition of an appropriate password because those details can be maintained within the standard. Keeping this separation brings added benefits when updating the standard. It wouldn’t be surprising to see language about passwords in dozens of different procedures. Since the standard is stored in a single location, all that needs to be changed is the standard itself, saving hours of tedious work.
At this point, we’ve discussed and illustrated what is and what is not a well-written policy statement, how policy differs from the procedure, what a standard is, and how multiple policies or procedures can reference one. These foundational concepts are good for your understanding of what not to do, but how do they help you get started? The Internet abounds with starting points. A quick google search for policies will reveal hundreds of boilerplate policies for a variety of needs. If you need a fairly generic policy and a small business, these may serve as a good starting point. Still, if your business is data-intensive or subject to outside governmental or institutional regulations, it’s doubtful that these highly generic templates will fully meet your compliance needs as is or that they will grow with you. There are so many unknown unknowns at this point. Do you have strict regulations or frameworks that apply to your business? Do you have clients who demand specific certifications? Do your business units fall under differing industry or international regulations and compliance requirements? If these questions apply to you, the expense associated with obtaining the correct policies jumps to thousands of dollars. In many cases, the policies come without guidance or expertise. It’s easy to waste time and money by going down dead-ends. There are just as many companies and individuals out there offering consulting services targeting policy and security planning. In many cases, this process starts with a baseline security assessment. You’ll find that the pricing can vary widely. An engagement can last from several weeks to a few months, depending on the complexity of your organization. A security assessment is designed to review all of your resources to determine what your security posture looks like. Are you taking measures to lock down critical resources? Are you vetting employees, contractors, and vendors? Are you exposing information that could lead to a successful breach? How sensitive is your data? You will learn a lot from a security baseline assessment, and, assuming you’ve selected a reputable organization, it’s almost always a good starting point. It’s a good idea to already understand your objectives before entering into an assessment. Are you trying to win some new business that requires a SOC2 or HITRUST certification? Are you trying to bring insurance rates down? Are there legal requirements with which you must comply? Make sure that you have clear objectives. This will save you time and money in the long run.
Policy language should be structured according to grouped concepts. As an example, if you were to include a topic within a policy related to employee background checks, it should be grouped under Human Resources -> Hiring -> Background checks. By effectively grouping concepts, we make it easier to find related policy language. We also compartmentalize concepts so that experts in each area can review concepts they are most familiar with. In the security world, there are several expected top-level policy titles, including:
Access Control
Access control policies are high-level requirements that specify how access is managed and who may access information under what circumstances. For instance, policies may pertain to resource usage within or across organizational units or based on need-to-know, competence, authority, obligation, or conflict-of-interest fact.
Audit Logging and Monitoring
Audit logging and monitoring policies are designed to provide accurate and comprehensive audit logs to detect and react to inappropriate access to or use information systems or data.
Business Continuity and Disaster Recovery
A business continuity policy is the set of standards and guidelines an organization enforces to ensure resilience and proper risk management. Business continuity policies vary by organization and industry and require periodic updates as technologies evolve and business risks change.
Configuration Management
This policy aims to set practices for establishing the mandatory requirements for the installation, configuration, and implementation of information technology systems.
Data Protection and Privacy
This policy defines who has access to data and enumerates the tools and policies used to restrict access to that data.
Education, Training, and Awareness
A Security Education, Training, and Awareness (SETA) program is defined as an educational program designed to reduce the number of security breaches that occur through a lack of employee security awareness.
Endpoint Protection
Endpoint Protection is the practice of securing endpoints or entry points of end-user devices such as desktops, laptops, and mobile devices from being exploited by malicious actors and campaigns. Endpoint security systems protect these endpoints on a network or in the cloud from cybersecurity threats. Endpoint security has evolved from traditional antivirus software to comprehensive protection from sophisticated malware and evolving zero-day threats.
Incident Management
The purpose of the incident management policy is to provide organization-wide guidance to employees on the proper response to an efficient and timely reporting of computer security-related incidents, such as computer viruses, unauthorized user activity, and suspected compromise of data.
Information Protection Program
Information protection involves mitigating risks through secure systems and architecture that eliminate or reduce vulnerabilities. It deals with both operations and technology to try and create a successful method for eliminating vulnerabilities in the system that can be used to gain unauthorized access or compromise or steal data. It may include facets such as vulnerability management, penetration testing, and technological solutions such as firewalls, antivirus, data loss prevention, and encryption.
Mobile Device Security
Mobile devices, such as smartphones and tablet computers, are important tools for the organization, and Company supports their use to achieve business goals. However, mobile devices also represent a significant risk to data security. If the appropriate security applications and procedures are not applied, they can be a conduit for unauthorized access to the organization’s data and IT infrastructure. This can subsequently lead to data leakage and system infection.
Network Protection
Network administrators and IT teams use the Network Protection policy to control their network environments and protect their organizations against evolving threats. Network Management policy streamlines security policy design and enforcement. It applies rules and best practices to manage firewalls and other devices more effectively, efficiently, and consistently.
Password Management
This policy provides guidelines for the consistent and secure management of passwords for employees and system and service accounts. It includes mandates on how passwords should be generated, used, stored, and changed, as well as for instructions for handling password compromises.
Physical and Environmental Security
Physical and Environmental Security refers to measures taken to protect systems, buildings, and related infrastructure against threats associated with their physical environment.
Portable Media Security
Portable media such as USB keys, flash memory, CDs/DVDs, etc., are crucial for daily business. However, portable media is easily lost or stolen and may cause a security breach.
Risk Management
The purpose of the risk management policy is to guide the management of risk to support corporate objectives, protect staff and business assets and ensure financial sustainability.
Third-Party Assurance
This policy is designed to ensure that the organization’s third-party suppliers, contractors, and vendors take the expected steps to meet organizational and regulatory security requirements.
Transmission Protection
This policy details security measures to guard against unauthorized access to ePHI transmitted over an electronic communications network.
Vulnerability Management
This Policy is designed to establish the rules for the review, evaluation, application, and verification of system updates to mitigate vulnerabilities in the IT environment and their associated risks.
Wireless Security
This policy outlines the methods used to prevent unauthorized access or damage to computers or data using wireless networks, including Wi-Fi networks. While this isn’t a comprehensive list, it does serve as a solid foundation upon which to build. Each of the policies shown above contains articles that outline how your organization intends to act. At this stage, it can be tempting to write a set of policies that speak to a single compliance objective. This places limits on your ability to add other frameworks in the future. If you craft policy language that addresses, for example, SOC2 requirements, you will find that the language may be too specific or too general for HIPAA or HITRUST should you need to add these in the future. Take the time to normalize your policy language-futureproof your organization by writing policies that describe your organization and its values. As frameworks come and go, your policy will stand on its own. PolicyCo is a platform designed specifically for the challenges associated with bridging the gap between policy and compliance. Our world-class editor enforces strict relationships between articles, standards, procedures, controls, and evidence that all live in one secure platform. Want to learn more about our compliance management software platform?
Best Practices
How Do I Write A Policy?
May 12, 2021
With such a straightforward title, how could this possibly be a difficult question to answer? Most people who’ve ventured into policy writing start a few sentences and quickly realize how daunting the task becomes.
Policy language is typically a guiding principle. The US Constitution is a great example of a policy. It prescribes ideals that may or may not stand the test of time, and it’s open to interpretation. There are hundreds of thousands of laws rooted correctly or incorrectly within concepts found in the Constitution. I like to think of policy as scaffolding or a blueprint, a tool that can be used to construct almost anything. Once the policy is in place, it can be disseminated to tens of thousands of other people to serve as a guiding light for specifics that may be required to ensure objectives are met.
This is such an important question to ask yourself. I’ll be talking about my opinion based on my experiences. Still, I certainly would understand that some of my readers may disagree with me, and I genuinely would be happy to listen and incorporate the community’s thoughts into my understanding. Policy language must speak to overarching objectives without becoming too granular. If a policy contains specific people, dates, metrics, or brand names, it’s probably morphing into a standard or a procedure. Let’s look at an example.
Documented security and privacy awareness training must be developed as part of the employee and contractor onboarding program.
The above statement is a good example of policy language. It has a clear subject, “Documented security and privacy awareness training.” It has the definitive “must” to indicate that it’s required. It states the “when” as part of a process rather than specific dates.
All employees and contractors are to receive HIPAA training through Udemy within two weeks of date of hire. Jane Smith is in charge of verifying that training was completed. The minimum acceptable score is 90%.
The above statement is not policy language. Further, it’s an exceptionally poorly written procedure because it leaves out countless details related to execution.
From a high-level view, your standards and procedures contain specific language that references your policies. There’s actually a fair amount of debate in the compliance ecosystem about what constitutes a standard. I’ll present an opinion on the subject, but I’ll refrain from discounting other interpretations because standards have evolved to mean different things to different people. Let’s tackle procedures before moving on to the standard minefield.
Procedures
Think of procedures as a recipe or a playbook. Procedures should answer questions like: “Who specifically is responsible for this task?”; “What are the steps required to perform the task?”; “Which systems are involved in performing the tasks?”; “When should the task be performed?”. The fascinating thing about procedures is that many procedures can be written from the perspective of many different people but still apply to a specific section of a policy. Let’s take this article from a Business Continuity and Disaster Recovery Policy: “Backups of information and software must be made, and tests of the media and restoration procedures must be regularly performed at appropriate intervals.” If your organization relies on even the most basic technology, this statement will apply to your customer CRM, your email, your website, shared file systems like Google Drive or Sharepoint, etc. Each of the procedures must satisfy the policy language and include the who, what, when, and where. Furthermore, the various departments in your organization each hold the knowledge required to write relevant procedures. It is critical to delegate procedure writing to subject matter experts, those who understand the operational flow of the company. There are real challenges associated with ensuring the right people can access, edit and approve procedural language.
Standards
Where policy addresses broad concepts (let’s make a chocolate cake) and procedures address the steps to get there (mix, heat the oven), standards might be considered the list of ingredients. Standards tend to reference discrete values, for example:
Passwords must contain at least 12 characters.
They are instrumental because they can be referenced (or cited) by multiple policies and procedures. When a standard changes, it’s quite possible that the policy will remain unchanged. In some cases, even the procedure will remain unchanged, particularly if you reference the standard in your procedure. Well-written procedures will call out a standard, as in this example.
Our Client CRM is accessed by employees using an approved username and password
As you can see, the procedure does not have to include the standard definition of an appropriate password because those details can be maintained within the standard. Keeping this separation brings added benefits when updating the standard. It wouldn’t be surprising to see language about passwords in dozens of different procedures. Since the standard is stored in a single location, all that needs to be changed is the standard itself, saving hours of tedious work.
At this point, we’ve discussed and illustrated what is and what is not a well-written policy statement, how policy differs from the procedure, what a standard is, and how multiple policies or procedures can reference one. These foundational concepts are good for your understanding of what not to do, but how do they help you get started? The Internet abounds with starting points. A quick google search for policies will reveal hundreds of boilerplate policies for a variety of needs. If you need a fairly generic policy and a small business, these may serve as a good starting point. Still, if your business is data-intensive or subject to outside governmental or institutional regulations, it’s doubtful that these highly generic templates will fully meet your compliance needs as is or that they will grow with you. There are so many unknown unknowns at this point. Do you have strict regulations or frameworks that apply to your business? Do you have clients who demand specific certifications? Do your business units fall under differing industry or international regulations and compliance requirements? If these questions apply to you, the expense associated with obtaining the correct policies jumps to thousands of dollars. In many cases, the policies come without guidance or expertise. It’s easy to waste time and money by going down dead-ends. There are just as many companies and individuals out there offering consulting services targeting policy and security planning. In many cases, this process starts with a baseline security assessment. You’ll find that the pricing can vary widely. An engagement can last from several weeks to a few months, depending on the complexity of your organization. A security assessment is designed to review all of your resources to determine what your security posture looks like. Are you taking measures to lock down critical resources? Are you vetting employees, contractors, and vendors? Are you exposing information that could lead to a successful breach? How sensitive is your data? You will learn a lot from a security baseline assessment, and, assuming you’ve selected a reputable organization, it’s almost always a good starting point. It’s a good idea to already understand your objectives before entering into an assessment. Are you trying to win some new business that requires a SOC2 or HITRUST certification? Are you trying to bring insurance rates down? Are there legal requirements with which you must comply? Make sure that you have clear objectives. This will save you time and money in the long run.
Policy language should be structured according to grouped concepts. As an example, if you were to include a topic within a policy related to employee background checks, it should be grouped under Human Resources -> Hiring -> Background checks. By effectively grouping concepts, we make it easier to find related policy language. We also compartmentalize concepts so that experts in each area can review concepts they are most familiar with. In the security world, there are several expected top-level policy titles, including:
Access Control
Access control policies are high-level requirements that specify how access is managed and who may access information under what circumstances. For instance, policies may pertain to resource usage within or across organizational units or based on need-to-know, competence, authority, obligation, or conflict-of-interest fact.
Audit Logging and Monitoring
Audit logging and monitoring policies are designed to provide accurate and comprehensive audit logs to detect and react to inappropriate access to or use information systems or data.
Business Continuity and Disaster Recovery
A business continuity policy is the set of standards and guidelines an organization enforces to ensure resilience and proper risk management. Business continuity policies vary by organization and industry and require periodic updates as technologies evolve and business risks change.
Configuration Management
This policy aims to set practices for establishing the mandatory requirements for the installation, configuration, and implementation of information technology systems.
Data Protection and Privacy
This policy defines who has access to data and enumerates the tools and policies used to restrict access to that data.
Education, Training, and Awareness
A Security Education, Training, and Awareness (SETA) program is defined as an educational program designed to reduce the number of security breaches that occur through a lack of employee security awareness.
Endpoint Protection
Endpoint Protection is the practice of securing endpoints or entry points of end-user devices such as desktops, laptops, and mobile devices from being exploited by malicious actors and campaigns. Endpoint security systems protect these endpoints on a network or in the cloud from cybersecurity threats. Endpoint security has evolved from traditional antivirus software to comprehensive protection from sophisticated malware and evolving zero-day threats.
Incident Management
The purpose of the incident management policy is to provide organization-wide guidance to employees on the proper response to an efficient and timely reporting of computer security-related incidents, such as computer viruses, unauthorized user activity, and suspected compromise of data.
Information Protection Program
Information protection involves mitigating risks through secure systems and architecture that eliminate or reduce vulnerabilities. It deals with both operations and technology to try and create a successful method for eliminating vulnerabilities in the system that can be used to gain unauthorized access or compromise or steal data. It may include facets such as vulnerability management, penetration testing, and technological solutions such as firewalls, antivirus, data loss prevention, and encryption.
Mobile Device Security
Mobile devices, such as smartphones and tablet computers, are important tools for the organization, and Company supports their use to achieve business goals. However, mobile devices also represent a significant risk to data security. If the appropriate security applications and procedures are not applied, they can be a conduit for unauthorized access to the organization’s data and IT infrastructure. This can subsequently lead to data leakage and system infection.
Network Protection
Network administrators and IT teams use the Network Protection policy to control their network environments and protect their organizations against evolving threats. Network Management policy streamlines security policy design and enforcement. It applies rules and best practices to manage firewalls and other devices more effectively, efficiently, and consistently.
Password Management
This policy provides guidelines for the consistent and secure management of passwords for employees and system and service accounts. It includes mandates on how passwords should be generated, used, stored, and changed, as well as for instructions for handling password compromises.
Physical and Environmental Security
Physical and Environmental Security refers to measures taken to protect systems, buildings, and related infrastructure against threats associated with their physical environment.
Portable Media Security
Portable media such as USB keys, flash memory, CDs/DVDs, etc., are crucial for daily business. However, portable media is easily lost or stolen and may cause a security breach.
Risk Management
The purpose of the risk management policy is to guide the management of risk to support corporate objectives, protect staff and business assets and ensure financial sustainability.
Third-Party Assurance
This policy is designed to ensure that the organization’s third-party suppliers, contractors, and vendors take the expected steps to meet organizational and regulatory security requirements.
Transmission Protection
This policy details security measures to guard against unauthorized access to ePHI transmitted over an electronic communications network.
Vulnerability Management
This Policy is designed to establish the rules for the review, evaluation, application, and verification of system updates to mitigate vulnerabilities in the IT environment and their associated risks.
Wireless Security
This policy outlines the methods used to prevent unauthorized access or damage to computers or data using wireless networks, including Wi-Fi networks. While this isn’t a comprehensive list, it does serve as a solid foundation upon which to build. Each of the policies shown above contains articles that outline how your organization intends to act. At this stage, it can be tempting to write a set of policies that speak to a single compliance objective. This places limits on your ability to add other frameworks in the future. If you craft policy language that addresses, for example, SOC2 requirements, you will find that the language may be too specific or too general for HIPAA or HITRUST should you need to add these in the future. Take the time to normalize your policy language-futureproof your organization by writing policies that describe your organization and its values. As frameworks come and go, your policy will stand on its own. PolicyCo is a platform designed specifically for the challenges associated with bridging the gap between policy and compliance. Our world-class editor enforces strict relationships between articles, standards, procedures, controls, and evidence that all live in one secure platform. Want to learn more about our compliance management software platform?
Bill Butler