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 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 that are rooted correctly or incorrectly within concepts found in the Constitution. I like to think of policy as a scaffolding or a blueprint, a tool that can be used to construct almost anything. Once policy is in place, it can be disseminated to tens or thousands of other people to serve as a guiding light for specifics that may be required in order to ensure objectives are met.
When have I drifted away from policy language?
This is such an important question to ask yourself. I’ll be talking about my opinion based on my experiences, but I certainly would understand that some of my readers may disagree with me and I genuinely would be happy to listen and incorporate the thoughts of the community 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.
If Policy is generic, where do I get into the details?
From a high level view, your standards and procedures contain specific language that reference 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 simply evolved to mean different things to different people. Let’s tackle procedures before moving on to the standard minefield.
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 really interesting thing about procedures is that many procedures can be written from the perspective of many different people but still be applicable 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 additionally 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 very real challenges associated with ensuring the right people can access, edit and approve procedural language.
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 thought of as the list of ingredients. Standards tend to reference discrete values for example:
Passwords must contain at least 12 characters.
They are particularly useful 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 simply 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 benefit 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 procedure, what a standard is and how one can be referenced by multiple policies or procedures. These foundational concepts are good for your understanding on 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 you have a small business, these may serve as a good starting point, but if your business is data intensive or subject to outside governmental or institutional regulations, it’s highly unlikely 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 in order 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.
Getting Started, finally.
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 with which they are most familiar.
In the security world, there are a number of expected top level policy titles, including:
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 may be 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 in order to detect and react to inappropriate access to, or use of, 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.
The purpose of this policy is 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 that is designed to reduce the number of security breaches that occur through a lack of employee security awareness.
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 providing comprehensive protection from sophisticated malware and evolving zero-day threats.
The purpose of the incident management policy is to provide organization-wide guidance to employees on proper response to, and 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 as, 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 administrators and IT teams use 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.
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 instructions for handling password compromises.
Physical and Environmental Security
Physical and Environmental Security refers to measures taken to protect systems, buildings, and related supporting infrastructure against threats associated with their physical environment.
Portable Media Security
Portable media such as USB keys, flash memory, CDs/DVDs, etc. are a crucial part of daily business. However, portable media is easily lost or stolen and may cause a security breach.
The purpose of the risk management policy is to provide guidance regarding the management of risk to support the achievement of 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 are taking the expected steps to meet organizational and regulatory security requirements.
This policy details security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network.
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 the risks associated with them.
This policy outlines the methods used to ensure the prevention of unauthorized access or damage to computers or data using wireless networks, which include 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 contain articles that serve as an outline for 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?