Policy architecture is complex, and the difficulty is compounded as your organization attempts to comply with more regulations and frameworks. Ambiguity tends to be the culprit here. Fundamentally, we as humans like to fit things into a neat classification system. However, there is a mountain of terminology to master, and even then, we still often find that certain pieces of policy language can apply to more than one area.

The only reasonable way to navigate multiple control frameworks is to normalize framework concepts into your policy statements. That’s a mouthful, so let’s take a minute to break down the statement.

Normalizing Framework Concepts

A mathematician might think of this as finding the least common denominator, which is easy because there is a correct answer. In our world, it’s more complicated. We must rely on our interpretation of framework concepts to craft an appropriate policy statement. Let’s get started with a relatively straightforward example. Each of the controls listed below talks about the concept of encrypting data as it traverses a network. Some are more prescriptive, and others are more general. Note that HITRUST and CIS are very specific about the use of WPA2.

HITRUST 0502.09m1Organizational.5 — Wireless access points are configured with strong encryption (AES WPA2 at a minimum).

CIS 12.6 — Use secure network management and communication protocols (e.g., 802.1X, Wi-Fi Protected Access 2 (WPA2) Enterprise or greater).

PCI DSS 4.1.1 — Encrypt transmission of cardholder data across open, public networks

SOC2 CC6.7.2 — Uses Encryption Technologies or Secure Communication Channels to Protect Data — Encryption technologies or secured communication channels protect data transmission and other communications beyond connectivity access points.

HIPAA 164.312(e)(2)(ii) — Implement a mechanism to encrypt electronically protected health information whenever deemed appropriate.

Let’s try to craft a policy statement (we call it an article) in our Wireless Security Policy that normalizes the above language for our use. We can accomplish this by looking at the concepts above and including those concepts that are common to all in our statement. Concepts: encryption, transit, wireless. This can get tricky because several of the controls above make no mention of wireless. It’s our responsibility to understand that transmission can happen over wired or wireless networks.

“Wireless access points must be configured with strong encryption. At a minimum, AES WPA 2 must be configured.”

The process of normalizing policy language is compelling. It means that we can state our intentions in our vernacular while adhering to principles defined by others.

So if we were to take our newly crafted article and bring it into our Wireless Policy, it might look like this:

1.3 Wireless Encryption

Wireless access points must be configured with solid encryption. At a minimum, AES WPA 2 must be configured.

HITRUST 0502.09m1Organizational.5

CIS 12.6

PCI DSS 4.1.1

SOC2 CC6.7.2

HIPAA 164.312(e)(2)(ii)

We’ve responsibly displayed the article and all applicable controls. The problem is that we wrote this in Word or Google Docs, which means these are just words on a page. There is no meaning embedded in these concepts, which means additional repetitive work for everyone. For example:

We don’t know that Wireless Encryption is the third article in the policy

We don’t know that this article is linked to 5 different framework controls

We don’t know the meaning or definitions of these controls

Procedures

Different frameworks place varying emphasis on the presence of procedures. At PolicyCo, we strongly feel that each article should be accompanied by at least one procedure; after all, the article states what you intend to do while the procedure explains how you plan to go about it.

The incredibly vital part of admitting that you need a procedure is knowing that you only need to write it once to satisfy all the controls mapped to the article. In our example above, the procedure for ensuring that wireless access points are encrypted is as follows:

“Encryption is enforced through the Meraki wireless configuration dashboard at https://meraki.com. The dashboard enforces WPA2 for all access points, and the IT Director is in charge of the setup and enforcement of this security setting.”

This procedure, as written, states who is responsible for the execution and where to access the setting. We only had to write the procedure once to satisfy Article 1.3 plus the five related controls.

Evidence (Control Testing)

In much the same way procedures benefit from being tied to a single article, Evidence (Control Testing) benefits. The only responsible way to verify that procedures are being followed is to provide evidence of the activities described in the procedure. Interestingly, by the time we arrive at the description for testing, we don’t care much about the meaning of the controls. Our only responsibility is to validate that the procedure is being followed. This test follows a logical path back to the control (Evidence: Procedure: Article: Control).

Build Relationships

It’s an excellent motto for life and policy management. The only responsible way to tame multiple control frameworks is to normalize your internal language and build these relational connections. The process takes time, and careful consideration, but the rewards come in the form of peace of mind, productivity gains, and preparedness.

For a given control, which policies are referenced (and where is it in the policy)?

How many controls and frameworks are applicable for a given article within a policy?

Do I have control requirements without policy associations?

Am I missing procedures for some controls/articles?

Am I collecting Evidence (Control Testing) for all of my controls required?

Those are just five questions, but we can answer dozens more by exploring the rich relationships created in the PolicyCo platform.