When I started the PolicyCo journey, I always focused on treating policy like we treat the agile process for software development. Being agile doesn’t mean the process is perfect, but it does allow for flexibility, transparency, and accountability. PolicyCo’s system stresses these qualities by having a documented and reportable workflow at each step of the process, including versioned commits, branch management, release candidates, code reviews, and limited role access for deployments. These are all important for the evolution of policy management.

Those responsible for writing policy aren’t programmers, and the concepts mentioned above can be overly technical. It's essential to balance flexibility and usability when applying programming concepts to policy management evolution. This is an effort to get my thoughts on paper to talk about how PolicyCo addresses this today and, more importantly, how we plan to close the loop in the future.

Some Background

Before getting into the details, it’s important to understand that PolicyCo takes a unique approach to writing and ensuring compliance with Policy. We believe that process is to break down the Policy into articles. A policy is typically centered around a broad theme, regulation, or law, while the articles break down the specific requirements and business strategies into testable areas within that broader theme. Software developers don’t place all of their code into a single file; it’s a collection of files related to one another, each with a specific function. There is strength derived from adopting this mindset. Controls can be built specifically to each article mapped directly to the Policy (e.g., security frameworks or federal regulations). These mappings ensure that the organization is testing for compliance at the granular level, ensuring accountability, and can be extended logically as your organization grows into new regulatory areas.

Versioned Commits

When developers commit code, they submit their changes to a central repository. Team members with the proper permission can see (a) the exact code that was committed, (b) the difference between the new and old code, (c) the exact time it was committed, and (d) the identity of the individual. In fact, this information can be viewed at the time of the commit, but it’s possible to go back in time to see the entire history of all commits from the beginning.

This same process can be used for versioning Policy.  At the moment, PolicyCo requires users to (a) write/edit a draft article of a Policy, (b) submit it for review to the appropriate governance level, and then (c) publish it. This does provide accountability, but it’s clear we are still missing a step. If we were to compare this to a coding process, it most closely resembles a commit that’s been accepted through a PR (pull request). But just because a commit has been accepted via a PR doesn’t mean it’s ready for prime time. It’s important to orchestrate multiple commits into a release and then deploy that release responsibly. So, for Policy, that would mean understanding your organization’s governance process to ensure Policy updates are documented and approved in accordance with that structure.  PolicyCo has developed a workflow that will work for any organization’s governance structure to ensure that each updated version of an article is incorporated into the Policy and that the appropriate authority approves policy within your organization.  Each stage of the review and approval process is viewable, documented, and reportable, including seeing prior versions.

Branch Management

In the software development world, we manage branches religiously. There are many philosophies but think of branches as parallel highway lanes that eventually merge into one. Following our logic above for draft articles, it is possible to change several articles within an overall policy. Under our current workflow, after the changes pass through the review and publish stages, it’s immediately effective; that is to say, it is now an active part of your new policy, however, to ensure your specific organization’s governance process is incorporated into our system, we are modifying the process to ensure that once the articles are modified, you have control to review and approve the Policy in accordance with your organization’s governance process.  This means if you have a specific review date or period for reviewing and updating policies (whether due to set time or update related to regulation or new law), our process will ensure that you are notified of the need to review and update the applicable articles. Once those articles have been updated and approved by your organization, the Policy as a whole document will be ready for review, approval by your governing body, and then publication. This automated workflow process ensures that each article impacted by the change is reviewed and updated as well as the Policy as a whole.

Release Candidates

We are actively planning to change the term published to approved. The reasoning here is that when an article reaches a published state, it’s still not ready to become public. We need another step to allow the manager to review approved articles and incorporate them into a new policy version for the appropriate governing body to approve the Policy. Additionally, your organization may not want to publish immediately upon approval, so we’ve added the ability to specify an effective date for the publication of a policy. Drawing from software development, we plan to use minor versions (1.0.1) to indicate release candidates (article approvals) and major versions (1.1) to indicate policy releases.

Deployment

Deploying software involves gathering up commits that have passed muster and merging them into the main branch. A sophisticated framework called git makes it relatively easy to ensure that new code is responsibly introduced into production. Since we have defined approved articles as eligible commits, let’s follow the table below to understand how we can responsibly version policy over time, providing accountability for new content. For our example below, let’s assume that your current Policy is version 1.0 with an effective date of 1/1/2022.

So, at this point, the effective policy is still 1.0, and we have two candidate policies ready for your organization’s governing body to approve:

As you can see, each policy candidate contains the cumulative changes from the minor versions generated as articles are approved. Since each candidate is cumulative, it’s only possible to promote the highest candidate version. At this point, it’s important to note that each organization may have different rules that need to be followed to promote a candidate to a release. Some may require board approval, while others may only require Manager level approval. Also, notably at the time of release, it’s essential to require an effective date to make crossover impossible. Document control ensures that two different versions of the same policy will not be active during the same period of time.

Let’s assume that we are ready to publish Policy 1.0.2. An authorized manager for the policy will select it from the list of candidates, ensure the appropriate approval has been obtained and set the publication release date. Your organization will have the ability to decide whether to name that version 1.1 or 2.0. The flexibility of our system ensures that you can choose whether to publish after an article (or articles) are approved or to ensure publication only after the whole Policy has been approved. Following this, you may set the publication date immediately upon obtaining approval or an effective date set as far into the future as you like. Let’s make the following selections:

Policy version 1.1, Effective 2/1/2022

This policy will automatically take effect on the date chosen, in this case, February 1, 2022. The cycle will now start over, but now the baseline is version 1.1, and candidates will increment as 1.1.1, 1.1.2 until they are ready to be promoted to a new release Policy version. You will be able to see the prior version 1.0 as well as the draft articles 1.1.1 and 1.1.2, which have not yet been published, and 1.1, the new updated version Policy.

I hope this has been helpful. We haven’t completed this work yet and would be happy to hear from you if you have any questions or suggestions about modifying our approach to this process.