A Guide to Developing Policies and Procedures

But how effective are they? After all, malicious users do not comply with these documents. Just because the sign instructs drivers to go at a maximum speed of 30 mph doesn't mean they have to. It's up to the driver.

Imagine a scenario where laws are established but there is no personnel to enforce them. This is a major misconception about policies and procedures.

When releasing the guides and constraints for how actions should be carried out, we need to start with the basics of day-to-day operations. If users aren't aware of these policies, they will be largely ineffective. Ensuring everyone is informed and understands how to follow them is crucial.

This list isn't even the tip of the iceberg when it comes to all of the potential documentation organizations can develop to address risks according to their operations and scale.

In terms of governance, risk, and compliance (GRC), policies and procedures are typically intertwined with the risks that security frameworks, standards, and legislation are targeted to mitigate. For example, the PCI DSS (Payment Card Information Data Security Standard) was established to protect cardholder data (CHD), with nearly every requirement and sub-requirement involving documentation of some sort with that single goal in mind.

Over the years, the NIST (National Institute of Standards and Technology) has released a harmonious library of information security publications to address specific aspects of security, such as supply chain risk management (NIST SP 800-161), asset management (NIST SP 1800-5) and others.

For more information on the NIST, have a look at the article written on this site called "Frameworks and Standards from the NIST".

As usual, I want to pivot from information that anyone can look up toward actionable advice to protect you and your organization.

Earlier in this post, we mentioned that policies address what we say we're going to do, while audits address what we're actually doing.

When developing documentation, I recommend an active-active approach, in which policies, procedures, and guidelines are written and refined after the risks have been mitigated that they address. For example, spam filters, email encryption, securing email servers, and anti-phishing tools and techniques should be put in place before an email security policy is put in place. Doing so will ensure that "what we say we are doing, is what we are actually doing."

The unfortunate reality is that control implementation is much harder than writing a policy. In a lot of cases, it may be impossible or unfeasible to implement certain controls as they require time, expertise, costs, and maintenance. In this case, other documentation may be developed, such as a plan of action and milestones, or POA&M. In other situations, we may require a compensating control to address the risk that the original control aimed to address.

We may not know that we require a compensating control without review, and thus, the written policy will need to be updated to reflect this change.

This may not be the case for all documentation, however, as policies, procedures, and guidelines have a different scope and goal. Guidelines are meant to be quite broad, almost like a cultural matrix that is blanketed over an organization, while policies and procedures are more specific, often going into the details of the processes and technologies used.

This is especially the case for system security plans, or SSPs, which are more of a collection of policies and controls than a single policy itself, but again, this can vary depending on the size of the organization. Startups may have a single document that encompasses all security efforts.

Policies and procedures in and of themselves are controls, however, they typically depict other controls that are in place.

I also want to introduce you to a newer concept called policy-as-code, or compliance-as-code, which are policies written in scripting, programming languages, or human-readable scripts such as cloud resource policies using YAML and JSON.

For example, in Microsoft Azure, resources are automatically assigned a resource ID from Azure Resource Manager (ARM). These resources can be grouped and tagged for policies that apply a variety of constraints. The same can be done for AWS with resources having an ARN, or AWS Resource Number.

We'll go into more detail on this in future posts, as I'd like to keep the scope of the article as an introduction and overview.

In addition, the documentation may be internal or external, as in public-facing for end users or only meant for internal staff, with public policies not disclosing sensitive organizational information.

And of course, depending on the standard or policy that your policies are based on, periodic evaluations of policies may be required, typically at least annually.

In future posts, I'll go over how to develop policies with examples to assist you with developing effective policies for your organization. However, here are some resources to help you get started, such as policy templates provided by the SANS Institute, an organization founded in 1989 specializing in information security training and resources.