increment patch for release (via Makefile)

dependency fix for homebrew tap
tidy go.sum
2025-12-15 19:00:50 +00:00 · 2021-05-17 11:07:12 -07:00 · 2021-05-17 10:56:43 -07:00 · 2021-03-10 12:18:46 -08:00 · 2020-09-14 15:20:10 -07:00 · 2020-09-14 13:45:15 -07:00
1166 changed files with 191127 additions and 84894 deletions
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,5 @@
 comply
 output
 dist
+.envrc
+bindata.go
--- a/AUTHORS.txt
+++ b/AUTHORS.txt
@@ -1,3 +1,12 @@
 # Authors in alphabetical order:

+arambhashura
+Alan Cox
+Andy Magnusson
+Anthony Oliver
+Justin Bodeutsch
 Justin McCarthy <justin@strongdm.com>
+Kevin N. Murphy
+Manisha Singh
+Mason Hensley
+Matt Simerson
--- a/21
+++ b/21
@@ -0,0 +1,21 @@
+FROM strongdm/pandoc:latest
+
+# based on implementation by James Gregory <james@jagregory.com>
+MAINTAINER Comply <comply@strongdm.com>
+
+RUN apt-get update -y \
+  && apt-get install -y curl
+
+ARG COMPLY_VERSION
+ENV COMPLY_VERSION ${COMPLY_VERSION:-1.4.0}
+
+EXPOSE 4000/tcp
+
+# install comply binary
+RUN curl -J -L -o /tmp/comply.tgz https://github.com/strongdm/comply/releases/download/v${COMPLY_VERSION}/comply-v${COMPLY_VERSION}-linux-amd64.tgz \
+  && tar -xzf /tmp/comply.tgz \
+  && mv ./comply-v${COMPLY_VERSION}-linux-amd64 /usr/local/bin/comply
+
+WORKDIR /source
+
+ENTRYPOINT ["/bin/bash"]
--- a/Gopkg.lock
+++ b/Gopkg.lock
@@ -1,262 +0,0 @@
-# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.
-
-
-[[projects]]
-  name = "github.com/Microsoft/go-winio"
-  packages = ["."]
-  revision = "7da180ee92d8bd8bb8c37fc560e673e6557c392f"
-  version = "v0.4.7"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/chzyer/readline"
-  packages = ["."]
-  revision = "f6d7a1f6fbf35bbf9beb80dc63c56a29dcfb759f"
-
-[[projects]]
-  name = "github.com/davecgh/go-spew"
-  packages = ["spew"]
-  revision = "346938d642f2ec3594ed81d874461961cd0faa76"
-  version = "v1.1.0"
-
-[[projects]]
-  name = "github.com/docker/distribution"
-  packages = [
-    "digest",
-    "reference"
-  ]
-  revision = "48294d928ced5dd9b378f7fd7c6f5da3ff3f2c89"
-  version = "v2.6.2"
-
-[[projects]]
-  name = "github.com/docker/docker"
-  packages = [
-    "api/types",
-    "api/types/blkiodev",
-    "api/types/container",
-    "api/types/events",
-    "api/types/filters",
-    "api/types/mount",
-    "api/types/network",
-    "api/types/reference",
-    "api/types/registry",
-    "api/types/strslice",
-    "api/types/swarm",
-    "api/types/time",
-    "api/types/versions",
-    "api/types/volume",
-    "client",
-    "pkg/tlsconfig"
-  ]
-  revision = "092cba3727bb9b4a2f0e922cd6c0f93ea270e363"
-  version = "v1.13.1"
-
-[[projects]]
-  name = "github.com/docker/go-connections"
-  packages = [
-    "nat",
-    "sockets",
-    "tlsconfig"
-  ]
-  revision = "3ede32e2033de7505e6500d6c868c2b9ed9f169d"
-  version = "v0.3.0"
-
-[[projects]]
-  name = "github.com/docker/go-units"
-  packages = ["."]
-  revision = "0dadbb0345b35ec7ef35e228dabb8de89a65bf52"
-  version = "v0.3.2"
-
-[[projects]]
-  name = "github.com/elazarl/go-bindata-assetfs"
-  packages = ["."]
-  revision = "30f82fa23fd844bd5bb1e5f216db87fd77b5eb43"
-  version = "v1.0.0"
-
-[[projects]]
-  name = "github.com/fatih/color"
-  packages = ["."]
-  revision = "507f6050b8568533fb3f5504de8e5205fa62a114"
-  version = "v1.6.0"
-
-[[projects]]
-  name = "github.com/fsnotify/fsnotify"
-  packages = ["."]
-  revision = "c2828203cd70a50dcccfb2761f8b1f8ceef9a8e9"
-  version = "v1.4.7"
-
-[[projects]]
-  name = "github.com/gohugoio/hugo"
-  packages = ["watcher"]
-  revision = "f414966b942b5aad75565bee6c644782a07f0658"
-  version = "v0.37.1"
-
-[[projects]]
-  name = "github.com/golang/protobuf"
-  packages = ["proto"]
-  revision = "925541529c1fa6821df4e44ce2723319eb2be768"
-  version = "v1.0.0"
-
-[[projects]]
-  name = "github.com/google/go-github"
-  packages = ["github"]
-  revision = "e48060a28fac52d0f1cb758bc8b87c07bac4a87d"
-  version = "v15.0.0"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/google/go-querystring"
-  packages = ["query"]
-  revision = "53e6ce116135b80d037921a7fdd5138cf32d7a8a"
-
-[[projects]]
-  name = "github.com/gorilla/websocket"
-  packages = ["."]
-  revision = "ea4d1f681babbce9545c9c5f3d5194a789c89f5b"
-  version = "v1.2.0"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/jcelliott/lumber"
-  packages = ["."]
-  revision = "dd349441af25132d146d7095c6693a15431fc9b1"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/juju/ansiterm"
-  packages = [
-    ".",
-    "tabwriter"
-  ]
-  revision = "720a0952cc2ac777afc295d9861263e2a4cf96a1"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/lunixbochs/vtclean"
-  packages = ["."]
-  revision = "d14193dfc626125c831501c1c42340b4248e1f5a"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/manifoldco/promptui"
-  packages = [
-    ".",
-    "list",
-    "screenbuf"
-  ]
-  revision = "c0c0d3afc6a03bcb5c1df10b70b862a650db9f9b"
-
-[[projects]]
-  name = "github.com/mattn/go-colorable"
-  packages = ["."]
-  revision = "167de6bfdfba052fa6b2d3664c8f5272e23c9072"
-  version = "v0.0.9"
-
-[[projects]]
-  name = "github.com/mattn/go-isatty"
-  packages = ["."]
-  revision = "0360b2af4f38e8d38c7fce2a9f4e702702d73a39"
-  version = "v0.0.3"
-
-[[projects]]
-  name = "github.com/mattn/go-runewidth"
-  packages = ["."]
-  revision = "9e777a8366cce605130a531d2cd6363d07ad7317"
-  version = "v0.0.2"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/nanobox-io/golang-scribble"
-  packages = ["."]
-  revision = "ced58d671850da57ce8c11315424513b608083d7"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/olekukonko/tablewriter"
-  packages = ["."]
-  revision = "b8a9be070da40449e501c3c4730a889e42d87a9e"
-
-[[projects]]
-  name = "github.com/pkg/errors"
-  packages = ["."]
-  revision = "645ef00459ed84a119197bfb8d8205042c6df63d"
-  version = "v0.8.0"
-
-[[projects]]
-  name = "github.com/robfig/cron"
-  packages = ["."]
-  revision = "b024fc5ea0e34bc3f83d9941c8d60b0622bfaca4"
-  version = "v1"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/skratchdot/open-golang"
-  packages = ["open"]
-  revision = "75fb7ed4208cf72d323d7d02fd1a5964a7a9073c"
-
-[[projects]]
-  name = "github.com/urfave/cli"
-  packages = ["."]
-  revision = "cfb38830724cc34fedffe9a2a29fb54fa9169cd1"
-  version = "v1.20.0"
-
-[[projects]]
-  name = "github.com/yosssi/ace"
-  packages = ["."]
-  revision = "ea038f4770b6746c3f8f84f14fa60d9fe1205b56"
-  version = "v0.0.5"
-
-[[projects]]
-  branch = "master"
-  name = "golang.org/x/net"
-  packages = [
-    "context",
-    "context/ctxhttp",
-    "proxy"
-  ]
-  revision = "d0aafc73d5cdc42264b0af071c261abac580695e"
-
-[[projects]]
-  branch = "master"
-  name = "golang.org/x/oauth2"
-  packages = [
-    ".",
-    "internal"
-  ]
-  revision = "7af32f14d0a25aec7873e0683e8e48dcead159a8"
-
-[[projects]]
-  branch = "master"
-  name = "golang.org/x/sys"
-  packages = [
-    "unix",
-    "windows"
-  ]
-  revision = "dd2ff4accc098aceecb86b36eaa7829b2a17b1c9"
-
-[[projects]]
-  name = "google.golang.org/appengine"
-  packages = [
-    "internal",
-    "internal/base",
-    "internal/datastore",
-    "internal/log",
-    "internal/remote_api",
-    "internal/urlfetch",
-    "urlfetch"
-  ]
-  revision = "150dc57a1b433e64154302bdc40b6bb8aefa313a"
-  version = "v1.0.0"
-
-[[projects]]
-  name = "gopkg.in/yaml.v2"
-  packages = ["."]
-  revision = "7f97868eec74b32b0982dd158a51a446d1da7eb5"
-  version = "v2.1.1"
-
-[solve-meta]
-  analyzer-name = "dep"
-  analyzer-version = 1
-  inputs-digest = "4fd2ff9f9869c3f3e30601504f4b00fce69d282ae8df42583a1c60848bfd0766"
-  solver-name = "gps-cdcl"
-  solver-version = 1
--- a/Gopkg.toml
+++ b/Gopkg.toml
@@ -1,30 +0,0 @@
-# Gopkg.toml example
-#
-# Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
-# for detailed Gopkg.toml documentation.
-#
-# required = ["github.com/user/thing/cmd/thing"]
-# ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"]
-#
-# [[constraint]]
-#   name = "github.com/user/project"
-#   version = "1.0.0"
-#
-# [[constraint]]
-#   name = "github.com/user/project2"
-#   branch = "dev"
-#   source = "github.com/myfork/project2"
-#
-# [[override]]
-#   name = "github.com/x/y"
-#   version = "2.4.0"
-#
-# [prune]
-#   non-go = false
-#   go-tests = true
-#   unused-packages = true
-
-
-[prune]
-  go-tests = true
-  unused-packages = true
--- a/53
+++ b/53
@@ -3,10 +3,9 @@ GO_SOURCES := $(shell find . -name '*.go')
 THEME_SOURCES := $(shell find themes)

 assets: $(THEME_SOURCES)
-	@go get github.com/jteeuwen/go-bindata/...
-	@go get github.com/elazarl/go-bindata-assetfs/...
-	@go install github.com/elazarl/go-bindata-assetfs
-	go-bindata-assetfs -o bindata.go -pkg theme -prefix themes themes/...
+	go install -mod=vendor github.com/containous/go-bindata/go-bindata
+	go install -mod=vendor github.com/elazarl/go-bindata-assetfs/go-bindata-assetfs
+	go-bindata-assetfs -pkg theme -prefix themes themes/...
 	mv bindata.go internal/theme/themes_bindata.go

 comply: assets $(GO_SOURCES)
@@ -19,12 +18,14 @@ dist: clean
 	$(eval LDFLAGS := -ldflags='-X "github.com/strongdm/comply/internal/cli.Version=$(VERSION)"')
 	mkdir dist
 	echo $(VERSION)
-	GOOS=darwin GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) $(LDFLAGS) -o dist/comply-$(VERSION)-darwin-amd64 .
-	GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) $(LDFLAGS) -o dist/comply-$(VERSION)-linux-amd64 .
+	GOOS=darwin GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) -ldflags '-extldflags "-static"' $(LDFLAGS) -o dist/comply-$(VERSION)-darwin-amd64 .
+	GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) -ldflags '-extldflags "-static"' $(LDFLAGS) -o dist/comply-$(VERSION)-linux-amd64 .
+	GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) -ldflags '-extldflags "-static"' $(LDFLAGS) -o dist/comply-$(VERSION)-windows-amd64.exe .
 	cd dist && tar -czvf comply-$(VERSION)-darwin-amd64.tgz comply-$(VERSION)-darwin-amd64
 	cd dist && tar -czvf comply-$(VERSION)-linux-amd64.tgz comply-$(VERSION)-linux-amd64
+	cd dist && zip comply-$(VERSION)-windows-amd64.zip comply-$(VERSION)-windows-amd64.exe

-brew: clean assets $(GO_SOURCES)
+brew: clean $(GO_SOURCES)
 	$(eval VERSION := $(shell cat version))
 	$(eval LDFLAGS := -ldflags='-X "github.com/strongdm/comply/internal/cli.Version=$(VERSION)"')
 	mkdir bin
@@ -38,7 +39,7 @@ clean:
 install: assets $(GO_SOURCES)
 	go install github.com/strongdm/comply

-push-assets: is-clean export-example assets
+push-assets: is-clean assets
 	git commit -am "automated asset refresh (via Makefile)"
 	git push

@@ -50,19 +51,8 @@ else
 	@exit 1
 endif

-export-example:
-	cp example/narratives/* themes/comply-soc2/narratives
-	cp example/procedures/* themes/comply-soc2/procedures
-	cp example/policies/* themes/comply-soc2/policies
-	cp example/standards/* themes/comply-soc2/standards
-	cp example/templates/* themes/comply-soc2/templates
-	cp example/templates/* themes/comply-blank/templates
-	cp example/*.md themes/comply-soc2
-	cp example/*.md themes/comply-blank
-
 docker:
 	cd build && docker build -t strongdm/pandoc .
-	docker tag jagregory/pandoc:latest strongdm/pandoc:latest
 	docker push strongdm/pandoc

 cleanse:
@@ -78,6 +68,9 @@ release-env:
 ifndef GH_LOGIN
 	$(error GH_LOGIN must be set to a valid GitHub token)
 endif
+ifndef COMPLY_TAPDIR
+	$(error COMPLY_TAPDIR must be set to the path of the comply homebrew tap repo)
+endif

 release: release-env dist release-deps
 	$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
@@ -105,11 +98,21 @@ release: release-env dist release-deps
 	--file dist/comply-$(VERSION)-linux-amd64.tgz

 	@echo "Update homebrew formula with the following: "
-	@echo "version $(VERSION)"
-	@curl -L https://github.com/strongdm/comply/archive/$(VERSION).tar.gz |shasum -a 256
-patch-release: release-env push-assets patch release
+	$(eval SHA := $(shell curl -s -L https://github.com/strongdm/comply/archive/$(VERSION).tar.gz |shasum -a 256|cut -d" " -f1))
+	@echo "version $(VERSION) sha $(SHA)"
+	cd $$COMPLY_TAPDIR && ./update.sh $(VERSION) $(SHA)

-minor-release: release-env push-assets minor release
+patch-release: release-env patch release
+	$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
+	curl -X POST --data-urlencode 'payload={"channel": "#release", "username": "release", "text": "comply $(VERSION) released", "icon_emoji": ":shipit:"}' https://hooks.slack.com/services/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
+
+minor-release: release-env minor release
+	$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
+	curl -X POST --data-urlencode 'payload={"channel": "#release", "username": "release", "text": "comply $(VERSION) released", "icon_emoji": ":shipit:"}' https://hooks.slack.com/services/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
+
+docker-release:
+	docker build --build-arg COMPLY_VERSION=`cat VERSION` -t strongdm/comply .
+	docker push strongdm/comply

 patch: clean gitsem
 	gitsem -m "increment patch for release (via Makefile)" patch
@@ -124,7 +127,7 @@ minor: clean gitsem
 release-deps: gitsem gh-release

 gitsem:
-	go get -u github.com/Clever/gitsem
+	go install github.com/Clever/gitsem

 gh-release:
-	go get -u github.com/aktau/github-release
+	go install github.com/aktau/github-release
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# Comply
+![Comply](https://github.com/strongdm/comply/blob/master/logo.png)

 Comply is a SOC2-focused compliance automation tool:

@@ -12,6 +12,10 @@ macOS:

 `brew tap strongdm/comply; brew install comply`

+Linux:
+
+[Download latest release](https://github.com/strongdm/comply/releases)
+
 Go users:

 `go get github.com/strongdm/comply`
@@ -34,6 +38,8 @@ Join us in [Comply Users](https://join.slack.com/t/comply-users/shared_invite/en

 # Screenshots

+[Demo video](https://vimeo.com/270257486)
+
 ## Start a Project
 ![screencast 1](sc-1.gif)

@@ -48,6 +54,10 @@ Join us in [Comply Users](https://join.slack.com/t/comply-users/shared_invite/en
 ## Dashboard
 ![screencast 2](sc-3.gif)

+## Dependencies
+
+Comply relies on [pandoc](https://pandoc.org/), which can be installed directly as an OS package or invoked via Docker.
+
 ## CLI

 ```
@@ -60,6 +70,7 @@ USAGE:
 COMMANDS:
     init             initialize a new compliance repository (interactive)
     build, b         generate a static website summarizing the compliance program
+     procedure, proc  create ticket by procedure ID
     scheduler        create tickets based on procedure schedule
     serve            live updating version of the build command
     sync             sync ticket status to local cache
@@ -67,3 +78,62 @@ COMMANDS:
     help, h          Shows a list of commands or help for one command
 ```

+## Running in Docker
+
+Comply is currently only released for Linux and macOS, however from other operating systems it's possible to run using Docker:
+
+```
+# first pull the latest published docker image
+$ docker pull strongdm/comply
+
+# from an empty directory that will contain your comply project
+$ docker run --rm -v "$PWD":/source -p 4000:4000 -it strongdm/comply
+root@ec4544732298:/source# comply init
+✗ Organization Name:
+
+# serve content live from an established project
+$ docker run --rm -v "$PWD":/source -p 4000:4000 -it strongdm/comply
+root@ae4d499583fc:/source# comply serve
+Serving content of output/ at http://127.0.0.1:4000 (ctrl-c to quit)
+```
+
+For Windows users, replace $PWD with the full path to your project directory
+
+
+## Ticketing Integrations:
+- Jira
+- Github
+- Gitlab
+
+## Configuring Jira
+When comply creates a ticket (through `proc`, for instance), it sets the following fields.
+
+- assignee
+- description
+- issuetype
+- labels
+- project key
+- reporter
+- summary
+
+Please make sure that the default *Create Screen* has all of those fields enabled. Additionally, make sure that there are no other required fields for the issue type you choose.
+
+
+
+
+## Forking and local development
+> Assumes installation of golang and configuration of GOPATH in .bash_profile, .zshrc, etc
+> Inspiration: http://code.openark.org/blog/development/forking-golang-repositories-on-github-and-managing-the-import-path
+
+```
+$ go get github.com/strongdm/comply
+$ cd $GOPATH/src/github.com/strongdm/comply ; go get ./...
+$ make
+$ cd example
+$ mv comply.yml.example comply.yml
+$ ../comply -h
+$ ../comply sync
+$ ../comply serve
+#
+$ make # recompile as needed with in $GOPATH/src/github.com/strongdm/comply
+```
--- a/2
+++ b/2
@@ -1 +1 @@
-1.1.19
+1.5.2
--- a/build/Dockerfile
+++ b/build/Dockerfile
@@ -1,3 +1,29 @@
-FROM scratch
+FROM haskell:latest

-MAINTAINER strongDM Comply <comply@strongdm.com>
+# based on implementation by James Gregory <james@jagregory.com>
+MAINTAINER Comply <comply@strongdm.com>
+
+# install latex packages
+RUN apt-get update -y \
+  && apt-get install -y -o Acquire::Retries=10 --no-install-recommends \
+    texlive-latex-base \
+    texlive-xetex \
+    texlive-fonts-recommended \
+    latex-xcolor \
+    texlive-latex-extra \
+    fontconfig \
+    unzip \
+    lmodern
+
+# will ease up the update process
+# updating this env variable will trigger the automatic build of the Docker image
+ENV PANDOC_VERSION "2.2.1"
+
+# install pandoc
+RUN cabal update && cabal install pandoc-${PANDOC_VERSION}
+
+WORKDIR /source
+
+ENTRYPOINT ["/root/.cabal/bin/pandoc"]
+
+CMD ["--help"]
--- a/example/comply.yml.example
+++ b/example/comply.yml.example
@@ -1,7 +1,31 @@
 name: "Acme"
 filePrefix: "Acme"
+
+# The following setting is optional.
+# If you set this (to, e.g. master), and you build the policies
+# on that branch, then a section is appended to each policy that
+# describes the approval. Text will look like:
+#
+# Last edit made by John Doe (jdoe@email.com) on Wed, 15 Aug 2018 12:45:28 -0400.
+# Approved by Joan Smith (jsmith@email.com) on Wed, 15 Aug 2018 16:54:48 -0400 in commit abc123123.
+#
+# The change author gets credit for the edit.
+# The person who committed or merged to the approval branch gets credit for approval.
+approvedBranch: master
 tickets:
  github:
    token: XXX
    username: strongdm
    repo: comply
+  # jira:
+  #   username: xxxx     # This is the username you log in to Jira's UI with. Probably your email address.
+  #   password: xxxx     # If you don't have a "managed account", use your password in this field. But if your organization
+  #                      # uses SAML or OAuth, or Jira's built-in multi-factor authentication, you need to use
+  #                      # an API token. Learn more here: https://confluence.atlassian.com/cloud/api-tokens-938839638.html
+  #   project: comply
+  #   url: https://yourjira
+  #   taskType: Task     # This must be an Issue, not a sub-task
+  # gitlab:
+  #   domain: https://gitlab.example.com:443/ # or https://gitlab.com/
+  #   token: token-here
+  #   repo: full-slug/of-project
--- a/example/narratives/control.md
+++ b/example/narratives/control.md
@@ -17,6 +17,78 @@ majorRevisions:

 # Control Environment Narrative

-Here we narrate why our control environment satisfies the control keys listed in the YML block
+The following provides a description of the control structure of {{.Name}}.

-# Template Coming Soon
+The intent of this description is to enumerate the logical, policy, and procedural controls that serve to monitor {{.Name}}'s application and data security. Changes uncovered by these procedures in the logical, policy, procedural, or customer environment are addressed by remediations specific to the noted change.
+
+# Logical Controls
+
+{{.Name}} employs several logical controls to protect confidential data and ensure normal operation of its core product.
+
+- Mandatory data encryption at rest and in motion
+- Multi-factor authentication for access to cloud infrastructure
+- Activity and anomaly monitoring on production systems
+- Vulnerability management program
+
+# Policy Controls
+
+{{.Name}} employs several policy controls to protect confidential data and ensure normal operation of its core product. These policies include, but are not limited to:
+
+- Access Control Policy
+- Encryption Policy
+- Office Security Policy
+- Password Policy
+- Policy Training Policy
+- Vendor Policy
+- Workstation Policy
+
+# Procedural Controls
+
+{{.Name}} has numerous scheduled procedures to monitor and tune the effectiveness of ongoing security controls, and a series of event-driven procedures to respond to security-related events.
+
+TODO: Finalize these lists
+
+## Scheduled Security and Audit Procedures
+
+- Review Access [quarterly]
+- Review Security Logs [weekly]
+- Review Cyber Risk Assessment (enumerate possible compromise scenarios) [quarterly]
+- Review Data Classification [quarterly]
+- Backup Testing [quarterly]
+- Disaster Recovery Testing [semi-annual]
+- Review Devices & Workstations [quarterly]
+- Review & Clear Low-Priority Alerts [weekly]
+- Apply OS Patches [monthly]
+- Verify Data Disposal per Retention Policy [quarterly]
+- Conduct Security Training [annual]
+- Review Security Monitoring and Alerting Configuration [quarterly]
+- Penetration Test [annual]
+- Whitebox Security Review [annual]
+- SOC2 Audit [annual]
+
+## Event-Driven Security and Audit Procedures
+
+- Onboard Employee
+- Offboard Employee
+- Investigate Security Alert
+- Investigate Security Incident
+
+# Remediations
+
+{{.Name}} uses the outcomes of the aforementioned controls and procedures to identify shortcomings in the existing control environment. Once identified, these shortcomes are remediated by improving existing controls and procedures, and creating new controls and procedures as needed.
+
+# Communications
+
+{{.Name}} communicates relevant information regarding the functioning of the above controls with internal and external parties on an as-needed basis and according to statutory requirements.
+
+## Internal
+
+{{.Name}} communicates control outcomes, anomalies, and remediations internally using the following channels:
+
+- Slack
+- Email
+- Github ticketing
+
+## External
+
+{{.Name}} communicates relevant control-related information to external parties including shareholders, customers, contractors, regulators, and government entities as needed according to contractual and regulatory/statutory obligation.
--- a/example/narratives/products.md
+++ b/example/narratives/products.md
@@ -9,4 +9,39 @@ majorRevisions:

 Here we describe the key products marketed by our organization

-# Template Coming Soon
+# Products
+
+## Product 1
+
+Overview of product 1
+
+### Architecture
+
+Brief architectural discussion of product 1
+
+### Security Considerations
+
+Specific security considerations for product 1. Refer to policies, procedures here.
+
+# References
+
+## Narratives
+
+List relevant narratives, probably including
+Organizational Narrative
+Security Narrative
+System Narrative
+
+## Policies
+
+List relevant policies, probably including
+Application Security Policy
+Datacenter Policy
+Log Management Policy
+Password Policy
+Security Incident Response Policy
+Risk Assessment Policy
+
+## Procedures
+
+List relevant procedures, probably including access review, patching, alert monitoring, log review, pen testing
--- a/example/narratives/security.md
+++ b/example/narratives/security.md
@@ -15,4 +15,99 @@ majorRevisions:

 Here we narrate why our org satisfies the control keys listed in the YML block

-# Template Coming Soon
+# {{.Name}} Product Architecture
+
+Describe product architecture here, emphasizing security implications
+
+# {{.Name}} Infrastructure
+
+## Product Infrastructure
+
+Describe product infrastructure, emphasizing security measures
+
+### Authorized Personnel
+
+- **AWS root account** access is granted only to the CTO and CEO
+- **AWS IAM** access is granted to to a limited group of **Operators**
+- **{{.Name}} SSH** access is granted to a limited group of **Operators**
+- **{{.Name}} DB** access is granted to a limited group of **Data Operators**
+
+## IT Infrastructure
+
+{{.Name}} uses the following cloud services for its internal infrastructure:
+
+- List cloud services
+
+Access to these cloud services is limited according to the role of the {{.Name}} employee and is reviewed quarterly as well as via regular onboarding/offboarding tasks for new and departing employees.
+
+# {{.Name}} Workstations
+
+{{.Name}} workstations are hardened against logical and physical attack by the following measures:
+
+- operating system must be within one generation of current
+- full-disk encryption
+- onboard antivirus/antimalware software
+- OS and AV automatically updated
+
+Workstation compliance with these measures is evaluated on a quarterly basis.
+
+## Remote Access
+
+Many {{.Name}} employees work remotely on a regular basis and connect to production and internal IT systems via the same methods as those employees connecting from the {{.Name}} physical office, i.e., direct encrypted access to cloud services. It is the employee's responsibility to ensure that only authorized personnel use {{.Name}} resources and access {{.Name}} systems.
+
+# Access Review
+
+Access to {{.Name}} infrastructure, both internal and product, is reviewed quarterly and inactive users are removed. Any anomalies are reported to the security team for further investigation. When employees start or depart, an onboarding/offboarding procedure is followed to provision or deprovision appropriate account access.
+
+# Penetration Testing
+
+{{.Name}} commissions an external penetration test on an annual basis. All findings are immediately reviewed and addressed to the satisfaction of the CTO/CEO.
+
+# {{.Name}} Physical Security
+
+{{.Name}} has one physical location, in San Francisco, CA. Key issuance is tracked by the Office Physical Security Policy Ledger. Office keys are additionally held by the lessor, property management, and custodial staff. These keys are not tracked by the Office Physical Security Policy Ledger. {{.Name}} managers regularly review physical access privileges.
+
+{{.Name}} infrastructure is located within AWS. {{.Name}} does not have physical access to AWS infrastructure.
+
+# Risk Assessment
+
+{{.Name}} updates its Cyber Risk Assessment on an annual basis in order to keep pace with the evolving threat landscape. The following is an inventory of adversarial and non-adversarial threats assessed to be of importance to {{.Name}}.
+
+## Adversarial Threats
+
+The following represents the inventory of adversarial threats:
+
+|Threat|Source|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+------------+-----------------+----------+------|
+| | | | | | |
+
+## Non-Adversarial Threats
+
+The following represents the inventory of non-adversarial threats:
+
+|Threat|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+-------------+----------+------|
+| | | | | |
+
+# References
+
+## Narratives
+
+Products and Services Narrative
+System Architecture Narrative
+
+## Policies
+
+Encryption Policy
+Log Management Policy
+Office Security Policy
+Remote Access Policy
+Security Incident Response Policy
+Workstation Policy
+
+## Procedures
+
+Apply OS Patches
+Review & Clear Low-Priority Alerts
+Review Access
+Review Devices & Workstations
--- a/example/policies/access.md
+++ b/example/policies/access.md
@@ -9,5 +9,49 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Purpose and Scope
+
+a. The purpose of this policy to define procedures to onboard and offboard users to technical infrastructure in a manner that minimizes the risk of information loss or exposure. 
+
+a. This policy applies to all technical infrastructure within the organization. 
+
+a. This policy applies to all full-time and part-time employees and contractors. 
+
+# Background
+
+a. In order to minimize the risk of information loss or exposure (from both inside and outside the organization), the organization is reliant on the principle of least privilege. Account creation and permission levels are restricted to only the resources absolutely needed to perform each person’s job duties. When a user’s role within the organization changes, those accounts and permission levels are changed/revoked to fit the new role and disabled when the user leaves the organization altogether. 
+
+# Policy
+
+a. *During onboarding:*
+
+    i. Hiring Manager informs HR upon hire of a new employee.
+
+    i. HR emails IT to inform them of a new hire and their role. 
+
+    i. IT creates a checklist of accounts and permission levels needed for that role. 
+
+    i. The owner of each resource reviews and approves account creation and the 
+associated permissions. 
+
+    i. IT works with the owner of each resource to set up the user. 
+
+a. *During offboarding:*
+
+    i. Hiring Manager notifies HR when an employee has been terminated. 
+
+    i. HR sends a weekly email report to IT summarizing list of users terminated and instructs IT to disable their access. 
+
+    i. IT terminates access within five business days from receipt of notification. 
+
+a. *When an employee changes roles within the organization:*
+
+    i. Hiring Manager will inform HR of a change in role.
+    
+    i. HR and IT will follow the same steps as outlined in the onboarding and offboarding procedures. 
+
+a. *Review of accounts and permissions:*
+
+    i. Each month, IT and HR will review accounts and permission levels for accuracy. 
+

-# Coming Soon
--- a/example/policies/application.md
+++ b/example/policies/application.md
@@ -8,4 +8,111 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This application security policy defines the security framework and requirements for applications, notably web applications, within the organization’s production environment.
+
+a. This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
+
+a. This policy applies to all applications within the organization’ production environment, as well as administrators and users of these applications. This typically includes employees and contractors.
+
+# Background
+
+a. Application vulnerabilities typically account for the largest number of initial attack vectors after malware infections. As a result, it is important that applications are designed with security in mind, and that they are scanned and continuously monitored for malicious activity that could indicate a system compromise. Discovery and subsequent mitigation of application vulnerabilities will limit the organization’s attack surface, and ensures a baseline level of security across all systems.
+
+a. In addition to scanning guidance, this policy also defines technical requirements and procedures  to ensure that applications are properly hardened in accordance with security best practices.
+
+# References
+
+a. Data Classification Policy
+
+a. OWASP Risk Rating Methodology
+
+a. OWASP Testing Guide
+
+a. OWASP Top Ten Project
+
+# Policy
+
+a. The organization must ensure that all applications it develops and/or acquires are securely configured and managed.
+
+a. The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
+
+    i. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (a)).
+
+    i. If the application processes confidential information, a confidential record banner must be prominently displayed which highlights the type of confidential data being accessed (e.g., personally-identifiable information (PII), protected health information (PHI), etc.)
+
+    i. Sensitive data, especially data specifically restricted by law or policy (e.g., social security numbers, passwords, and credit card data) should not be displayed in plaintext.
+
+    i. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct. Examples include, but are not limited to cross-site scripting, buffer overflow errors, and injection flaws.
+
+    i. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, impair security mechanisms, or crash the system.
+
+    i. Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual. Provide an automated review of authorizations on a regular basis, where possible.
+
+    i. Ensure that applications encrypt data at rest and in transit.
+
+    i. Implement application logging to the extent practical. Retain logs of all users and access events for at least 14 days.
+
+    i. Qualified peers conduct security reviews of code  for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data. Document all actions taken.
+
+    i. Implement a change management process for changes to existing software applications.
+
+    i. Standard configuration of the application must be documented. 
+
+    i. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
+
+    i. Applications must require complex passwords in accordance with current security best practices (at least 8 characters in length, combination of alphanumeric upper/lowercase characters and symbols).
+
+    i. During development and testing, applications must not have access to live data.
+
+a. Where applications are acquired from a third party, such as a vendor:
+
+    i. Only applications that are supported by an approved vendor shall be procured and used.
+
+    i. Full support contracts must be arranged with the application vendor for full life-cycle support.
+
+    i. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
+
+    i. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible.
+
+    i. A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
+
+a. Web applications must be assessed according to the following criteria:
+
+    i. New or major application releases must have a full assessment prior to approval of the change control documentation and/or release into the production environment.
+
+    i. Third-party or acquired applications must have a full assessment prior to deployment.
+
+    i. Software releases must have an appropriate assessment, as determined by the organization’s information security manager, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
+
+    i. Emergency releases may forego security assessments and carry the assumed risk until a proper assessment can be conducted. Emergency releases must be approved by the Chief Information Officer or designee.
+
+a. Vulnerabilities that are discovered during application assessments must be mitigated based upon the following risk levels, which are based on the Open Web Application Security Project (OWASP) Risk Rating Methodology (reference (b)):
+
+    i. High - issues categorized as high risk must be fixed immediately, otherwise alternate mitigation strategies must be implemented to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
+
+    i. Medium - issues categorized as medium risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled. Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues; multiple issues may increase the risk to an unacceptable level. Issues may be fixed in patch releases unless better mitigation options are present.
+
+    i. Low - issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
+
+a. Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
+
+a. The following security assessment types may be leveraged to perform an application security assessment:
+
+    i. Full - comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference (c)). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
+
+    i. Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (d)).
+
+    i. Targeted - verifies vulnerability remediation changes or new application functionality.
+
+    i. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference (c)).
+
+    i. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (d)).
+
+    i. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (e)).
+
+    i. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (f)).
+
+    i. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (g)).
+
--- a/example/policies/availability.md
+++ b/example/policies/availability.md
@@ -9,4 +9,92 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for proper controls to protect the availability of the organization’s information systems.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the amount of unexpected or unplanned downtime (also known as outages) of information systems under the organization’s control. This policy prescribes specific measures for the organization that will increase system redundancy, introduce failover mechanisms, and implement monitoring such that outages are prevented as much as possible. Where they cannot be prevented, outages will be quickly detected and remediated.
+
+a. Within this policy, an availability is defined as a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. Information systems must be consistently available to conduct and support business operations.
+
+a. Information systems must have a defined availability classification, with appropriate controls enabled and incorporated into development and production processes based on this classification.
+
+a. System and network failures must be reported promptly to the organization’s lead for Information Technology (IT) or designated IT operations manager.
+
+a. Users must be notified of scheduled outages (e.g., system maintenance) that require periods of downtime. This notification must specify the date and time of the system maintenance, expected duration, and anticipated system or service resumption time.
+
+a. Prior to production use, each new or significantly modified application must have a completed risk assessment that includes availability risks. Risk assessments must be completed in accordance with the Risk Assessment Policy (reference (a)).
+
+a. Capacity management and load balancing techniques must be used, as deemed necessary, to help minimize the risk and impact of system failures.
+
+a. Information systems  must have an appropriate data backup plan that ensures:
+
+    i. All sensitive data can be restored within a reasonable time period.
+
+    i. Full backups of critical resources are performed on at least a weekly basis.
+
+    i. Incremental backups for critical resources are performed on at least a daily basis.
+
+    i. Backups and associated media are maintained for a minimum of thirty (30) days and retained for at least one (1) year, or in accordance with legal and regulatory requirements.
+
+    i. Backups are stored off-site with multiple points of redundancy and protected using encryption and key management.
+
+    i. Tests of backup data must be conducted once per quarter. Tests of configurations must be conducted twice per year.
+
+a. Information systems  must have an appropriate redundancy and failover plan that meets the following criteria:
+
+    i. Network infrastructure that supports critical resources must have system-level redundancy (including but not limited to a secondary power supply, backup disk-array, and secondary computing system). Critical core components (including but not limited to routers, switches, and other devices linked to Service Level Agreements (SLAs)) must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers that support critical resources must have redundant power supplies and network interface cards. All servers must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers classified as high availability must use disk mirroring.
+
+a. Information systems must have an appropriate business continuity plan that meets the following criteria:
+
+    i. Recovery time and data loss limits are defined in Table 3. 
+
+    i. Recovery time requirements and data loss limits must be adhered to with specific documentation in the plan.
+
+    i. Company and/or external critical resources, personnel, and necessary corrective actions must be specifically identified.
+
+    i. Specific responsibilities and tasks for responding to emergencies and resuming business operations must be included in the plan.
+
+    i. All applicable legal and regulatory requirements must be satisfied.
+
+-------------------+------------------+---------------+-------------------+------------------+
+|**Availability**   | **Availability** | **Scheduled** | **Recovery Time** | **Data Loss or** |
+|**Classification** | **Requirements** | **Outage**    | **Requirements**  | **Impact Loss**  |
+===================+==================+===============+===================+==================+
+| High              | High to          | 30 minutes    | 1 hour            | Minimal          |
+|                   | Continuous       |               |                   |                  |
+-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
+-------------------+------------------+---------------+-------------------+------------------+
+| Medium            | Standard         | 2 hours       | 4 hours           | Some data loss   |
+|                   | Availability     |               |                   | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
+-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
+-------------------+------------------+---------------+-------------------+------------------+
+| Low               | Limited          | 4 hours       | Next              | Some data loss   |
+|                   | Availability     |               | business day      | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
+-------------------+------------------+---------------+-------------------+------------------+
+
+Table 3: Recovery Time and Data Loss Limits 
--- a/example/policies/classification.md
+++ b/example/policies/classification.md
@@ -7,5 +7,279 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Appendices 
+
+Appendix A: Handling of Classified Information
+
+Appendix B: Form - Confidentiality Statement
+
+# Purpose and Scope
+
+a. This data classification policy defines the requirements to ensure that information within the organization is protected at an appropriate level.
+
+a. This document applies to the entire scope of the organization’s information security program. It includes all types of information, regardless of its form, such as paper or electronic documents, applications and databases, and knowledge or information that is not written.
+
+a. This policy applies to all individuals and systems that have access to information kept by the organization.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s data classification scheme. This includes data classification levels, as well as procedures for the classification, labeling and handling of data within the organization. Confidentiality and non-disclosure agreements maintained by the organization must reference this policy.
+
+# References
+
+a. Risk Assessment Policy
+
+a. Security Incident Management Policy
+
+# Policy
+
+a. If classified information is received from outside the organization, the person who receives the information must classify it in accordance with the rules prescribed in this policy. The person thereby will become the owner of the information.
+
+a. If classified information is received from outside the organization and handled as part of business operations activities (e.g., customer data on provided cloud services), the information classification, as well as the owner of such information, must be made in accordance with the specifications of the respective customer service agreement and other legal requirements.
+
+a. When classifying information, the level of confidentiality is determined by:
+
+    i. The value of the information, based on impacts identified during the risk assessment process. More information on risk assessments is defined in the Risk Assessment Policy (reference (a)).
+
+    i. Sensitivity and criticality of the information, based on the highest risk calculated for each information item during the risk assessment.
+
+    i. Legal, regulatory and contractual obligations. 
+
+
+-------------------+------------------+---------------------------+---------------------------+
+|**Confidentiality**| **Label**        |  **Classification**       |  **Access**               |
+|     **Level**     |                  |   **Criteria**            | **Restrictions**          |
+===================+==================+===========================+============================+
+| Public            | For Public       | Making the information    | Information is available  |   
+|                   | Release          | public will not harm      | to the public.            |
+|                   |                  | the organization in       |                           |        
+|                   |                  | any way.                  |                           |
+-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
+-------------------+------------------+---------------------------+---------------------------+
+| Internal Use      | Internal Use     | Unauthorized access       | Information is available  |
+|                   |                  | may cause minor damage    | to all employees and      |   
+|                   |                  | and/or inconvenience      | authorized third parties. |        
+|                   |                  | to the organization.      | 
+-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
+-------------------+------------------+---------------------------+---------------------------+
+| Restricted        | Restricted       | Unauthorized access to    | Information is available  |
+|                   |                  | information may cause     | to a specific group of    |
+|                   |                  | considerable damage to    | employees and authhorized |
+|                   |                  | the business and/or       | third parties.            |
+|                   |                  | the organization's        |                           |
+|                   |                  | reputation.               |                           |           
+-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
+-------------------+------------------+---------------------------+---------------------------+
+| Confidential      |Confidential      | Unauthorized access to    | Information is available  |           
+|                   |                  | information may cause     | only to specific indivi-  |
+|                   |                  | catastrophic damage to    | duals in the              |
+|                   |                  | business and/or the       | organization.             |
+|                   |                  | organization's reputation.|                           |
+-------------------+------------------+---------------------------+---------------------------+
+
+Table 3: Information Confidentiality Levels
+
+&nbsp;
+
+d. Information must be classified based on confidentiality levels as defined in Table 3.
+
+e. Information and information system owners should try to use the lowest confidentiality level that ensures an adequate level of protection, thereby avoiding unnecessary production costs.
+
+f. Information classified as “Restricted” or “Confidential” must be accompanied by a list of authorized persons in which the information owner specifies the names or job functions of persons who have the right to access that information.
+
+g. Information classified as “Internal Use” must be accompanied by a list of authorized persons only if individuals outside the organization will have access to the document.
+
+h. Information and information system owners must review the confidentiality level of their information assets every five years and assess whether the confidentiality level should be changed. Wherever possible, confidentiality levels should be lowered.
+
+a. For cloud-based software services provided to customers, system owners under the company’s control must also review the confidentiality level of their information systems after service agreement changes or after a customer’s formal notification. Where allowed by service agreements, confidentiality levels should be lowered.
+
+a. Information must be labeled according to the following:
+
+    i. Paper documents: the confidentiality level is indicated on the top and bottom of each document page; it is also indicated on the front of the cover or envelope carrying such a document as well as on the filing folder in which the document is stored. If a document is not labeled, its default classification is Internal Use.
+
+    i. Electronic documents: the confidentiality level is indicated on the top and bottom of each document page. If a document is not labeled, its default classification is Internal Use.
+
+    i. Information systems: the confidentiality level in applications and databases must be indicated on the system access screen, as well as on the screen when displaying such information.
+    
+    i. Electronic mail: the confidentiality level is indicated in the first line of the email body. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Electronic storage media (disks, memory cards, etc.): the confidentiality level must be indicated on the top surface of the media. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Information transmitted orally: the confidentiality level should be mentioned before discussing information during face-to-face communication, by telephone, or any other means of oral communication.
+    
+a. All persons accessing classified information must follow the guidelines listed in Appendix A, “Handling of Classified Information.”
+
+a. All persons accessing classified information must complete and submit a Confidentiality Statement to their immediate supervisor or company point-of-contact. A sample Confidentiality Statement is in Appendix B.
+
+a. Incidents related to the improper handling of classified information must be reported in accordance with the Security Incident Management Policy (reference (b)).
+    
+\pagebreak 
+
+# Appendix A: Handling of Classified Information
+
+Information and information systems must be handled according to the following guidelines*:
+
+a. Paper Documents
+    
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+        
+        1. If sent outside the organization, the document must be sent as registered mail.
+
+        1. Documents may only be kept in rooms without public access.
+
+        1. Documents must be removed expeditiously from printers and fax machines.
+
+    i. Restricted
+
+        1. The document must be stored in a locked cabinet.
+
+        1. Documents may be transferred within and outside the organization only in a closed envelope.
+
+        1. If sent outside the organization, the document must be mailed with a return receipt service.
+
+        1. Documents must immediately be removed from printers and fax machines.
+
+        1. Only the document owner may copy the document.
+
+        1. Only the document owner may destroy the document.
+
+    i. Confidential
+      
+        1. The document must be stored in a safe.
+
+        1. The document may be transferred within and outside the organization only by a trustworthy person in a closed and sealed envelope.
+
+        1. Faxing the document is not permitted.
+
+        1. The document may be printed only if the authorized person is standing next to the printer.
+
+a. Electronic Documents
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. When documents are exchanged via unencrypted file sharing services such as FTP, they must be password protected.
+
+        1. Access to the information system where the document is stored must be protected by a strong password.
+
+        1. The screen on which the document is displayed must be automatically locked after 10 minutes of inactivity.
+
+    i. Restricted
+
+        1. Only persons with authorization for this document may access the part of the information system where this document is stored.
+
+        1. When documents are exchanged via file sharing services of any type, they must be encrypted.
+
+        1. Only the document owner may erase the document.
+
+    i. Confidential
+
+        1. The document must be stored in encrypted form.
+
+        1. The document may be stored only on servers which are controlled by the organization.
+
+        1. The document may only be shared via file sharing services that are encrypted such as HTTPS and SSH. Further, the document must be encrypted and protected with a string password when transferred.
+
+a. Information Systems
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Access to the information system must be protected by a strong password.
+
+        1. The screen must be automatically locked after 10 minutes of inactivity.
+
+        1. The information system may be only located in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Users must log out of the information system if they have temporarily or permanently left the workplace.
+
+        1. Data must be erased only with an algorithm that ensures secure deletion.
+
+    i. Confidential
+
+        1. Access to the information system must be controlled through multi-factor authentication (MFA).
+
+        1. The information system may only be installed on servers controlled by the organization.
+
+        1. The information system may only be located in rooms with controlled physical access and identity control of people accessing the room.
+
+a. Electronic Mail
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. The sender must carefully check the recipient.
+
+        1. All rules stated under “information systems” apply.
+
+    i. Restricted
+
+        1. Email must be encrypted if sent outside the organization.
+
+    i. Confidential
+
+        1. Email must be encrypted.
+
+a. Electronic Storage Media
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Media or files must be password protected.
+
+        1. If sent outside the organization, the medium must be sent as registered mail.
+
+        1. The medium may only be kept in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Media and files must be encrypted.
+
+        1. Media must be stored in a locked cabinet.
+
+        1. If sent outside the organization, the medium must be mailed with a return receipt service.
+
+        1. Only the medium owner may erase or destroy the medium.
+
+    i. Confidential
+
+        1. Media must be stored in a safe.
+
+        1. Media may be transferred within and outside the organization only by a trustworthy person and in a closed and sealed envelope.
+
+a. Information Transmitted Orally
+
+    i. Internal Use
+
+        1. Only authorized persons may have access to information.
+
+        1. Unauthorized persons must not be present in the room when the information is communicated.
+
+    i. Restricted
+
+        1. The room must be sound-proof.
+
+        1. The conversation must not be recorded.
+
+    i. Confidential
+
+        1. Conversation conducted through electronic means must be encrypted.
+
+        1. No transcript of the conversation may be kept.
+
+In this document, controls are implemented cumulatively, meaning that controls for any confidentiality level imply the implementation of controls defined for lower confidentiality levels - if stricted controls are prescribed for a higher confidentiality level, then only such controls are implemented.
+
+
+

-# Coming Soon
--- a/example/policies/cyber.md
+++ b/example/policies/cyber.md
@@ -8,4 +8,61 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the procedures to assess and treat information security risks within the organization, and to define the acceptable level of risk overall.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all information systems which are used within the organization or which could have an impact on the organization’s information security.
+
+a. This policy applies to all management and employees that take part in the organization’s risk assessments. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines a step-by-step process for conducting risk assessments, as well as to treat identified risks from an information security perspective. This policy also describes how to prepare the Risk Assessment Report required as part of the risk assessment process.
+
+a. When conducting a risk assessment, the organization must identify all organizational information systems . It must then identify all threats and vulnerabilities having to do with such systems , and rate the severity of such threats and vulnerabilities according to a predefined rating scale. Asset and risk owners must be defined for each risk item.
+
+a. Once the risk assessment is completed, the organization shall determine how to manage risks where the overall assessed risk rating is deemed as too high. This management is known as risk treatment. Risk treatment options include but are not limited to applying security controls, outsourcing risk, accepting risk, or discontinuing the activity associated with the risk.
+
+a. A penetration test must be performed by a third party to verify the accuracy of the risk assessment and effectiveness of deployed risk treatments.
+
+# Procedure To Execute Risk Assessment Report
+
+a. Confirms that the entire risk assessment and risk treatment process has been carried out according to the Risk Assessment Policy.
+
+a. The purpose of the risk assessment was to identify all information systems  their vulnerabilities, and threats that could exploit vulnerabilities. These parameters were further evaluated in order to establish the criticality of individual risks.
+
+a. The purpose of the risk treatment was to define the systematic means of reducing or controlling the risks identified in the risk assessment.
+
+a. All risk assessment and treatment activities were completed within the scope of the organization’s information security program.
+
+a. The risk assessment was implemented in the period from [day/month/year] to [day/month/year]. The risk treatment was implemented from [day/month/year] to [day/month/year]. Final reports were prepared during [specify period].
+
+a. The risk assessment and risk treatment process was managed by [person responsible for managing the risk assessment process] with expert assistance provided by [person or company responsible for assistance].
+
+a. During the risk assessment, information was collected through questionnaires and interviews with responsible persons, namely the asset owners across organizational units.
+
+a. The process was conducted as follows:
+
+    i. All information systems and their owners were identified.
+
+    i. Threats were identified for each asset, and corresponding vulnerabilities were identified for each threat.
+    i. Risk owners were identified for each risk.
+
+    i. Consequences of the loss of confidentiality, integrity and availability were evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The likelihood of risk occurrence (i.e. that the threat will exploit the vulnerability) was evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The level of risk was calculated by adding up the consequence and likelihood.
+
+    i. Risks with a score of 3 or 4 were determined to be unacceptable risks.
+
+    i. For each unacceptable risk, a risk treatment option was considered, and appropriate information security controls were selected.
+
+    i. After controls were applied, residual risks were assessed.
+
+a. The following documents were used or generated during the implementation of risk assessment and risk treatment:
+    
+    i. Risk Assessment Table (Appendix A): for each combination of systems , vulnerabilities and threats, this table shows the values for consequence and likelihood, and calculates the risk.
+
+    i. Risk Treatment Table (Appendix B): defines the options for risk treatment, selection of controls for each unacceptable risk, and the level of residual risk.
--- a/example/policies/development.md
+++ b/example/policies/development.md
@@ -8,4 +8,188 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for establishing and maintaining baseline protection standards for company software, network devices, servers, and desktops.
+
+a. This policy applies to all users performing software development, system administration, and management of these activities within the organization. This typically includes employees and contractors, as well as any relevant external parties involved in these activities (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+a. This policy also applies to enterprise-wide systems and applications developed by the organization or on behalf of the organization for production implementation.
+
+# Background
+
+a. The intent of this policy is to ensure a well-defined, secure and consistent process for managing the entire lifecycle of software and information systems, from initial requirements analysis until system decommission. The policy defines the procedure, roles, and responsibilities, for each stage of the software development lifecycle.
+
+a. Within this policy, the software development lifecycle consists of requirements analysis, architecture and design, development, testing, deployment/implementation, operations/maintenance, and decommission. These processes may be followed in any form; in a waterfall model, it may be appropriate to follow the process linearly, while in an agile development model, the process can be repeated in an iterative fashion.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. The organization’s Software Development Life Cycle (SDLC) includes the following phases:
+
+    i. Requirements Analysis
+
+    i. Architecture and Design
+
+    i. Testing
+
+    i. Deployment/Implementation
+
+    i. Operations/Maintenance
+
+    i. Decommission
+
+a. During all phases of the SDLC where a system is not in production, the system must not have live data sets that contain information identifying actual people or corporate entities, actual financial data such as account numbers, security codes, routing information, or any other financially identifying data. Information that would be considered sensitive must never be used outside of production environments.
+
+a. The following activities must be completed and/or considered during the requirements analysis phase:
+
+    i. Analyze business requirements.
+
+    i. Perform a risk assessment. More information on risk assessments is discussed in the Risk Assessment Policy (reference (a)).
+
+    i. Discuss aspects of security (e.g., confidentiality, integrity, availability) and how they might apply to this requirement.
+
+    i. Review regulatory requirements and the organization’s policies, standards, procedures and guidelines.
+
+    i. Review future business goals.
+
+    i. Review current business and information technology operations.
+
+    i. Incorporate program management items, including:
+
+        1. Analysis of current system users/customers.
+
+        1. Understand customer-partner interface requirements (e.g., business-level, network).
+
+        1. Discuss project timeframe.
+
+    i. Develop and prioritize security solution requirements.
+
+    i. Assess cost and budget constraints for security solutions, including development and operations.
+
+    i. Approve security requirements and budget.
+
+    i. Make “buy vs. build” decisions for security services based on the information above.
+
+a. The following must be completed/considered during the architecture and design phase:
+
+    i. Educate development teams on how to create a secure system.
+
+    i. Develop and/or refine infrastructure security architecture.
+
+    i. List technical and non-technical security controls.
+
+    i. Perform architecture walkthrough.
+
+    i. Create a system-level security design.
+
+    i. Create high-level non-technical and integrated technical security designs.
+
+    i. Perform a cost/benefit analysis for design components.
+
+    i. Document the detailed technical security design.
+
+    i. Perform a design review, which must include, at a minimum, technical reviews of application and infrastructure, as well as a review of high-level processes.
+
+    i. Describe detailed security processes and procedures, including: segregation of duties and segregation of development, testing and production environments. 
+
+    i. Design initial end-user training and awareness programs.
+
+    i. Design a general security test plan.
+
+    i. Update the organization’s policies, standards, and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+
+    i. Design and establish separate development and test environments.
+
+a. The following must be completed and/or considered during the development phase:
+
+    i. Set up a secure development environment (e.g., servers, storage).
+
+    i. Train infrastructure teams on installation and configuration of applicable software, if required.
+
+    i. Develop code for application-level security components.
+
+    i. Install, configure and integrate the test infrastructure.
+
+    i. Set up security-related vulnerability tracking processes.
+
+    i. Develop a detailed security test plan for current and future versions (i.e., regression testing).
+
+    i. Conduct unit testing and integration testing.
+
+a. The following must be completed and/or considered during the testing phase:
+
+    i. Perform a code and configuration review through both static and dynamic analysis of code to identify vulnerabilities. 
+
+    i. Test configuration procedures.
+
+    i. Perform system tests.
+
+    i. Conduct performance and load tests with security controls enabled.
+
+    i. Perform usability testing of application security controls.
+
+
+    i. Conduct independent vulnerability assessments of the system, including the infrastructure and application.
+
+a. The following must be completed and/or considered during the deployment phase:
+
+    i. Conduct pilot deployment of the infrastructure, application and other relevant components.
+
+    i. Conduct transition between pilot and full-scale deployment.
+
+    i. Perform integrity checking on system files to ensure authenticity.
+
+    i. Deploy training and awareness programs to train administrative personnel and users in the system’s security functions.
+
+    i. Require participation of at least two developers in order to conduct full-scale deployment to the production environment.
+
+a. The following must be completed and/or considered during the operations/maintenance phase:
+
+    i. Several security tasks and activities must be routinely performed to operate and administer the system, including but not limited to:
+
+        1. Administering users and access.
+
+        1. Tuning performance.
+
+        1. Performing backups according to requirements defined in the System Availability Policy 
+
+        1. Performing system maintenance (i.e., testing and applying security updates and patches).
+
+        1. Conducting training and awareness.
+
+        1. Conducting periodic system vulnerability assessments.
+
+        1. Conducting annual risk assessments.
+
+    i. Operational systems must:
+
+        1. Be reviewed to ensure that the security controls, both automated and manual, are functioning correctly and effectively.
+
+        1. Have logs that are periodically reviewed to evaluate the security of the system and validate audit controls.
+
+        1. Implement ongoing monitoring of systems and users to ensure detection of security violations and unauthorized changes.
+
+        1. Validate the effectiveness of the implemented security controls through security training as required by the Procedure For Executing Incident Response.
+
+        1. Have a software application and/or hardware patching process that is performed regularly in order to eliminate software bug and security problems being introduced into the organization’s technology environment. Patches and updates must be applied within ninety (90) days of release to provide for adequate testing and propagation of software updates. Emergency, critical, break-fix, and zero-day vulnerability patch releases must be applied as quickly as possible.
+
+a. The following must be completed and/or considered during the decommission phase:
+
+    i. Conduct unit testing and integration testing on the system after component removal.
+
+    i. Conduct operational transition for component removal/replacement.
+
+    i. Determine data retention requirements for application software and systems data.
+
+    i. Document the detailed technical security design.
+
+    i. Update the organization’s policies, standards and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+
--- a/example/policies/disaster.md
+++ b/example/policies/disaster.md
@@ -9,4 +9,144 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the organization’s procedures to recover Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a set Recovery Time Objective (RTO).
+
+a. This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management.
+
+a. This policy applies to all management, employees and suppliers that are involved in the recovery of IT infrastructure and services within the organization. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines the overall disaster recovery strategy for the organization. The strategy describes the organization’s Recovery Time Objective (RTO), which is defined as the duration of time and service level for critical business processes to be restored after a disaster or other disruptive event, as well as the procedures, responsibility and technical guidance required to meet the RTO. This policy also lists the contact information for personnel and service providers that may be needed during a disaster recovery event.
+
+a. The following conditions must be met for this plan to be viable:
+
+    i. All equipment, software and data (or their backups/failovers) are available in some manner.
+
+    i. If an incident takes place at the organization’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties.
+
+    i. The Information Security Officer is responsible for coordinating and conducting a bi-annual (at least) rehearsal of this continuity plan. 
+
+a. This plan does not cover the following types of incidents:
+
+    i. Incidents that affect customers or partners but have no effect on the organization’s systems; in this case, the customer must employ their own continuity processes to make sure that they can continue to interact with the organization and its systems.
+
+    i. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including but not limited to Google, Heroku, and Amazon Web Services. The organization depends on such suppliers to employ their own continuity processes.
+
+# Policy
+
+a. *Relocation*
+
+    i. If the organization’s primary work site is unavailable, an alternate work site shall be used by designated personnel. The organization’s alternate work site is located at [list the address of the alternate work site that the organization will use].
+
+    i. The personnel required to report to the alternate work site during a disaster includes [list the personnel titles responsible for reporting to the alternate work site].
+
+a. *Critical Services, Key Tasks and, Service Level Agreements (SLAs)*
+
+    i. The following services and technologies are considered to be critical for business operations, and must immediately be restored (in priority order):
+  
+        1. [list the critical services and technologies that must remain running during a disaster]
+
+    i. The following key tasks and SLAs must be considered during a disaster recovery event, in accordance with the organization’s objectives, agreements, and legal, contractual or regulatory obligations:
+
+        1. [list of key tasks / SLAs that must be kept operational, with respective deadlines]
+
+a. The organization’s Recovery Time Objective (RTO) is [set the maximum amount of time before critical processes must be restored, to include relocation and getting critical services/technologies back online]. Relocation and restoration of critical services and technologies must be completed within this time period.
+
+a. *Notification of Plan Initiation*
+
+    i. The following personnel must be notified when this plan is initiated:
+
+      1. [list all personnel (including titles) that must be notified of plan initiation ]
+
+    i. [person responsible for notifications, including title] is responsible for notifying the personnel listed above.
+
+a. *Plan Deactivation*
+
+    i. This plan must only be deactivated by [person or persons with authority to deactivate the plan, including job title].
+
+    i. In order for this plan to be deactivated, all relocation activities and critical service / technology tasks  as detailed above must be fully completed and/or restored. If the organization is still operating in an impaired scenario, the plan may still be kept active at the discretion of [person or persons with authority to deactivate the plan, including job title].
+
+    i. The following personnel must be notified when this plan is deactivated:
+
+        1. [list all personnel (including titles) that must be notified of plan activation]
+
+a. The organization must endeavor to restore its normal level of business operations as soon as possible.
+
+a. A list of relevant points of contact both internal and external to the organization is enclosed in Appendix A.
+
+a. During a crisis, it is vital for certain recovery tasks to be performed right away. The following actions are pre-authorized in the event of a disaster recovery event:
+
+    i. [job title] must take all steps specified in this disaster recovery plan in order to recover the organization’s information technology infrastructure and services.
+    
+    i. [job title] is authorized to make urgent purchases of equipment and services up to [amount].
+    
+    i. [job title] is authorized to communicate with clients.
+    
+    i. [job title] is authorized to communicate with the public.
+    
+    i. [job title] is authorized to communicate with public authorities such as state and local governments and law enforcement.
+    
+    i. [job title] is authorized to cooperate with [name of supplier/outsourcing partner].
+    
+    i. [add/modify/remove authorizations in this section as necessary]
+
+a. Specific recovery steps for information systems infrastructure and services are provided in Appendix B.
+
+\pagebreak 
+
+# Appendix A: Relevant Points of Contact
+
+Internal Contacts
+
+------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
+==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+
+External Contacts
+
+------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
+==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+
+\pagebreak
+
+# Appendix B: Recovery Steps for Information Systems Infrastructure & Services
+
+Specific recovery procedures are described in detail below:
+
+----------------------------+----------------------+------------------------------------+
+|     Recovery Procedure     |  Person Responsible  |  Person(s) Notified When Complete  |
+============================+======================+====================================+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
+----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    |  
+|                            |                      |                                    |
+----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |   
+|                            |                      |                                    |              
+----------------------------+----------------------+------------------------------------+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
+----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    | 
+|                            |                      |                                    |    
+----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |    
+|                            |                      |                                    |             
+----------------------------+----------------------+------------------------------------+
--- a/example/policies/encryption.md
+++ b/example/policies/encryption.md
@@ -7,5 +7,76 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Purpose and Scope
+
+a. This policy defines organizational requirements for the use of cryptographic controls, as well as the requirements for cryptographic keys, in order to protect the confidentiality, integrity, authenticity and nonrepudiation of information.
+
+a. This policy applies to all systems, equipment, facilities and information within the scope of the organization’s information security program.
+
+a. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work on behalf of the organization having to do with cryptographic systems, algorithms, or keying material are subject to this policy and must comply with it.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s use of cryptographic algorithms and keys. It is vital that the organization adopt a standard approach to cryptographic controls across all work centers in order to ensure end-to-end security, while also promoting interoperability. This document defines the specific algorithms approved for use, requirements for key management and protection, and requirements for using cryptography in cloud environments.
+
+# Policy
+
+a. The organization must protect individual systems or information by means of cryptographic controls as defined in Table 3: 
+
+\pagebreak 
+
+---------------------+-------------------+----------------+--------------+
+| **Name of System/** | **Cryptographic** | **Encryption** | **Key Size** |
+| **Type of**         | **Tool**          | **Algorithm**  |              |
+| **Information**     |                   |                |              |
+=====================+===================+================+==============+
+| Public Key          |  OpenSSL          | AES-256        | 256-bit key  |
+| Infrastructure for  |                   |                |              |
+| Authentication      |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+| Data Encryption     |  OpenSSL          | AES-256        | 256-bit key  |
+| Keys                |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+| Virtual Private     |  OpenSSL and      | AES-256        | 256-bit key  |
+| Network (VPN)       |  OpenVPN          |                |              |
+| keys                |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+| Website SSL         |  OpenSSL, CERT    | AES-256        | 256-bit key  |
+| Certificate         |                   |                |              | 
+---------------------+-------------------+----------------+--------------+
+
+Table 3: Cryptographic Controls 
+
+&nbsp;
+
+b. Except where otherwise stated, keys must be managed by their owners.
+
+c. Cryptographic keys must be protected against loss, change or destruction by applying appropriate access control mechanisms to prevent unauthorized use and backing up keys on a regular basis.
+
+d. When required, customers of the organization’s cloud-based software or platform offering must be able to obtain information regarding:
+
+    i. The cryptographic tools used to protect their information.
+
+    i. Any capabilities that are available to allow cloud service customers to apply their own cryptographic solutions.
+
+    i. The identity of the countries where the cryptographic tools are used to store or transfer cloud service customers’ data.
+
+a. The use of organizationally-approved encryption must be governed in accordance with the laws of the country, region, or other regulating entity in which users perform their work. Encryption must not be used to violate any laws or regulations including import/export restrictions. The encryption used by the Company conforms to international standards and U.S. import/export requirements, and thus can be used across international boundaries for business purposes.
+
+a. All key management must be performed using software that automatically manages access control, secure storage, backup and rotation of keys. Specifically:
+
+  i. The key management service must provide key access to specifically-designated users, with the ability to encrypt/decrypt information and generate data encryption keys.
+
+  i. The key management service must provide key administration access to specifically-designated users, with the ability to create, schedule delete, enable/disable rotation, and set usage policies for keys.
+
+  i. The key management service must store and backup keys for the entirety of their operational lifetime.
+
+  i. The key management service must rotate keys at least once every 12 months.
+

-# Coming Soon
--- a/example/policies/media.md
+++ b/example/policies/media.md
@@ -8,4 +8,133 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This removable media, cloud storage and Bring Your Own Device (BYOD) policy defines the objectives, requirements and implementing instructions for storing data on removable media, in cloud environments, and on personally-owned devices, regardless of data classification level.
+
+a. This policy applies to all information and data within the organization’s information security program, as well as all removable media, cloud systems and personally-owned devices either owned or controlled by the organization.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. This policy defines the procedures for safely using  removable media, cloud storage and personally-owned devices to limit data loss or exposure.  Such forms of storage must be strictly controlled because of the sensitive data that can be stored on them. Because each of these storage types are inherently ephemeral or portable in nature, it is possible for the organization to lose the ability to oversee or control the information stored on them if strict security standards are not followed.
+
+a. This document consists of three sections pertaining to removable media, cloud storage, and personally-owned devices. Each section contains requirements and implementing instructions for the registration, management, maintenance, and disposition of each type of storage.
+
+a. Within this policy, the term sensitive information refers to information that is classified as RESTRICTED or CONFIDENTIAL in accordance with the Data Classification Policy (reference (a)).
+
+# References
+
+a. Data Classification Policy
+
+a. Asset Inventory
+
+a. Security Incident Response Policy
+
+a. Encryption Policy
+
+# Policy
+
+a. *Removable Media*
+
+    i. All removable media in active use and containing data pertinent to the organization must be registered in the organization’s Asset Inventory (reference (b)).
+
+    i. All removable media listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization.
+
+        1. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM).
+
+        1. The ISM must treat any removable media that cannot be located as lost, and a security incident report must be logged in accordance with the Security Incident Response Policy (reference (c)).
+
+    i. The owner of the removable media must conduct all appropriate maintenance on the item at intervals appropriate to the type of media, such as cleaning, formatting, labeling, etc.
+
+    i. The owner of the removable media, where practical, must ensure that an alternate or backup copy of the information located on the device exists.
+
+    i. Removable media must be stored in a safe place that has a reduced risk of fire or flooding damage. 
+
+    i. If the storage item contains sensitive information, removable media must:
+
+        1. Be stored in a locked cabinet or drawer.
+
+        1. Store only encrypted data that is securely enciphered in accordance with the Encryption Policy (reference (d)).
+
+    i. All data on removable media devices must be erased, or the device must be destroyed, before it is reused or disposed of.
+
+    i. When removable media devices are disposed, the device owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Cloud Storage*
+
+    i. All cloud storage systems in active use and containing data pertinent to the organization must be registered in reference (b). Registration may be accomplished by manual or automated means.
+
+
+    i. All cloud storage systems listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM). Re-inventory may be accomplished by manual or automated means.
+
+    i. The owner of the cloud storage system must conduct all appropriate maintenance on the system at regular intervals to include system configuration, access control, performance monitoring, etc.
+
+    i. Data on cloud storage systems must be replicated to at least one other physical location. Depending on the cloud storage provider, this replication may be automatically configured.
+
+    i. The organization must only use cloud storage providers that can demonstrate, either through security accreditation, demonstration, tour, or other means that their facilities are secured, both physically and electronically, using best practices.
+
+    i. If the cloud storage system contains sensitive information, that information must be encrypted in accordance with reference (d).
+
+    i. Data must be erased from from cloud storage systems using a technology and process that is approved by the ISM. 
+
+    i. When use of a cloud storage system is discontinued, the system owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Personally-owned Devices*
+
+    i. Organizational data that is stored, transferred or processed on personally-owned devices remains under the organization’s ownership, and the organization retains the right to control such data even though it is not the owner of the device.
+
+    i. The ISM is responsible for conducting overall management of personally-owned devices, to include:
+
+        1. Installation and maintenance of Mobile Device Management (MDM) software that can effectively manage, control and wipe data under the organization’s control from personally-owned devices.
+
+        1. Maintain a list of job titles and/or persons authorized to use personally-owned devices for the organization’s business, as well as the applications and databases that may be accessed from such devices.
+
+        1. Maintain a list of applications prohibited from use on personally-owned devices, and ensuring that device users are aware of these restrictions.
+
+    i. Personally-identifiable information (PII) may not be stored, processed or accessed at any time on a personally-owned device.
+
+    i. The following acceptable use requirements must be observed by users of personally-owned devices:
+
+        1. All organizational data must be backed up at regular intervals.
+
+        1. MDM and endpoint protection software must be installed on the device at all times.
+
+        1. Sensitive information stored on the device must be encrypted in accordance with reference (d).
+
+        1. The device must be secured using a password, pin, unlock pattern, fingerprint or equivalent security mechanism.
+
+        1. The device must only connect to secure and encrypted wireless networks.
+
+        1. When using the device outside of the organization’s premises, it must not be left unattended, and if possible, physically secured.
+
+        1. When using the device in public areas, the owner must take measures to ensure that the data cannot be read or accessed by unauthorized persons.
+
+        1. Patches and updates must be installed regularly.
+
+        1. Classified information must be protected in accordance with reference (a).
+
+        1. The device owner must install the ISM before the device is disposed of, sold, or provided to a third party for servicing.
+
+        1. It is prohibited to:
+
+            a. Allow device access for anyone except its owner.
+        
+            a. Store illegal materials on the device.
+
+            a. Install unlicensed software.
+
+            a. Locally-store passwords.
+
+            a. Transfer organizational data to other devices which have not been approved by the organization.
+
+    i. The organization must reserve the right to view, edit, and/or delete any organizational information that is stored, processed or transferred on the device.
+
+    i. The organization must reserve the right to perform full deletion of all of its data on the device if it considers that necessary for the protection of company-related data, without the consent of the device owner.
+
+    i. The organization will not pay the employees (the owners of BYOD) any fee for using the device for work purposes.
+
+    i. The organization will pay for any new software that needs to be installed for company use.
+
+    i. All security breaches related to personally-owned devices must be reported immediately to the ISM. 
--- a/example/policies/remote.md
+++ b/example/policies/remote.md
@@ -10,4 +10,50 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for connecting to the organization’s systems and networks from remote hosts, including personally-owned devices, in order to minimize data loss/exposure.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily accessible to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the organization’s exposure to damages which may result from the unauthorized remote use of resources, including but not limited to: the loss of sensitive, company confidential data and intellectual property; damage to the organization’s public image; damage to the organization’s internal systems; and fines and/or other financial liabilities incurred as a result of such losses.
+
+a. Within this policy, the following definitions apply:
+
+    i. *Mobile computing equipment:* includes portable computers, mobile phones, smart phones, memory cards and other mobile equipment used for storage, processing and transfer of data.
+
+    i. *Remote host:* is defined as an information system, node or network that is not under direct control of the organization.
+
+    i. *Telework:* the act of using mobile computing equipment and remote hosts to perform work outside the organization’s physical premises. Teleworking does not include the use of mobile phones.
+
+# Policy
+
+a. *Security Requirements for Remote Hosts and Mobile Computing Equipment*
+
+    i. Caution must be exercised when mobile computing equipment is placed or used in uncontrolled spaces such as vehicles, public spaces, hotel rooms, meeting places, conference centers, and other unprotected areas outside the organization’s premises.
+
+    i. When using remote hosts and mobile computing equipment, users must take care that information on the device (e.g. displayed on the screen) cannot be read by unauthorized persons if the device is being used to connect to the organization’s systems or work with the organization’s data.
+
+    i. Remote hosts must be updated and patched for the latest security updates on at least a monthly basis.
+
+    i. Remote hosts must have endpoint protection software (e.g. malware scanner) installed and updated at all times.
+
+    i. Persons using mobile computing equipment off-premises are responsible for regular backups of organizational data that resides on the the device.
+
+    i. Access to the organization’s systems must be done through an encrypted and authenticated VPN connection with multi-factor authentication enabled. All users requiring remote access must be provisioned with VPN credentials from the organization’s information technology team. VPN keys must be rotated at least twice per year. Revocation of VPN keys must be included in the Offboarding Policy. 
+
+    i. Information stored on mobile computing equipment must be encrypted using hard drive full disk encryption.
+
+a. *Security Requirements for Telework*
+
+    i. Employees must be specifically authorized for telework in writing from their hiring manager .
+
+    i. Only device’s assigned owner is permitted to use remote nodes and mobile computing equipment. Unauthorized users (such as others living or working at the location where telework is performed) are not permitted to use such devices.
+
+    i. Devices must be authorized using certificates
+
+    i. Users performing telework are responsible for the appropriate configuration of the local network used for connecting to the Internet at their telework location.
+
+    i. Users performing telework must protect the organization’s intellectual property rights, either for software or other materials that are present on remote nodes and mobile computing equipment.
--- a/example/policies/retention.md
+++ b/example/policies/retention.md
@@ -10,4 +10,79 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+#Appendices
+Appendix A: Retention Periods
+
+# Purpose and Scope
+
+a. This data retention policy defines the objectives and requirements for data retention within the organization.
+
+a. This policy covers all data within the organization’s custody or control, irregardless of the medium the data is stored in (electronic form, paper form, etc.) Within this policy, the medium which holds data is referred to as information, no matter what form it is in.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information the organization owns or controls (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The organization is bound by multiple legal, regulatory and contractual obligations with regard to the data it retains. These obligations stipulate how long data can be retained, and how data must be destroyed. Examples of legal, regulatory and contractual obligations include laws and regulations in the local jurisdiction where the organization conducts business, and contracts made with employees, customers, service providers, partners and others.
+
+a. The organization may also be involved in events such as litigation or disaster recovery scenarios that require it to have access to original information in order to protect the organization’s interests or those of its employees, customers, service providers, partners and others. As a result, the organization may need to archive and store information for longer that it may be needed for day-to-day operations.
+ 
+ \pagebreak 
+
+# Policy
+
+a. *Information Retention*
+
+    i. Retention is defined as the maintenance of information in a production or live environment which can be accessed by an authorized user in the ordinary course of business. 
+
+    i. Information used in the development, staging, and testing of systems shall not be retained beyond their active use period nor copied into production or live environments.
+
+    i. By default, the retention period of information shall be an active use period of exactly two years from its creation unless an exception is obtained permitting a longer or shorter retention period. The business unit responsible for the information must request the exception.
+
+    i. After the active use period of information is over in accordance with this policy and approved exceptions, information must be archived for a defined period. Once the defined archive period is over, the information must be destroyed.
+
+    i. Each business unit is responsible for the information it creates, uses, stores, processes and destroys, according to the requirements of this policy. The responsible business unit is considered to be the information owner.
+
+    i. The organization’s legal counsel may issue a litigation hold to request that information relating to potential or actual litigation, arbitration or other claims, demands, disputes or regulatory action be retained in accordance with instructions from the legal counsel.
+
+    i. Each employee and contractor affiliated with the company must return information in their possession or control to the organization upon separation and/or retirement.
+
+    i. Information owners must enforce the retention, archiving and destruction of information, and communicate these periods to relevant parties.
+
+a. *Information Archiving*
+
+    i. Archiving is defined as secured storage of information such that the information is rendered inaccessible by authorized users in the ordinary course of business but can be retrieved by an administrator designated by company management.
+
+        1. Physical (e.g., paper) records must be archived in secured storage (onsite or offsite) and clearly labeled in archive boxes naming the information owner.
+
+        1. Electronic records must be archived with strict access controls set by the information owner and appropriate to secure the confidentiality, integrity and accessibility of the information.
+
+    i. The default archiving period of information shall be 7 years unless an approved exception permits a longer or shorter period. Exceptions must be requested by the information owner.
+
+        1. As a guideline, an archiving period of more than 7 years may be granted for information with a vital historical purpose such as corporate records, contracts, and technical/trade secrets.
+
+        1. As a guideline, an archiving period of less than 7 years may be granted for information with a limited business purpose such as email, travel itineraries, pre-trip advisories, or to comply with specific legal, contractual and/or regulatory requirements (e.g., PCI DSS, GDPR, etc.)
+
+    i. Information must be destroyed (defined below) at the end of the elapsed archiving period.  
+
+a. *Information Destruction*
+
+    i. Destruction is defined as the physical or technical destruction sufficient to render the information contained in the document irretrievable by ordinary commercially-available means.
+
+    i. The organization must maintain and enforce a detailed list of approved destruction methods appropriate for each type of information archived, whether in physical storage media such as CD-ROMs, DVDs, backup tapes, hard drives, mobile devices, portable drives or in database records or backup files. Physical information in paper form must be shredded using an authorized shredding device; waste must be periodically removed by approved personnel.
+
+a. Retention and archival periods for information that is created, processed, stored and used by the organization is defined in Appendix A, “Retention Periods.” 
+
+\pagebreak 
+
+# Appendix A: Retention Periods 
+
+------------------+-------------------+------------------+------------------+-----------------+
+| Information Type | Information Owner | Storage Location | Retention Period | Archival Period |
+==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
--- a/example/policies/risk.md
+++ b/example/policies/risk.md
@@ -8,4 +8,130 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within the organization, and to define the acceptable level of risk as set by the organization’s leadership.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all assets which are used within the organization or which could have an impact on information security within it.
+
+a. This policy applies to all employees of the organization who take part in risk assessment and risk treatment.
+
+# Background
+
+a. A key element of the organization’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for the organization to identify information security risks. The process consists of four parts: identification of the organization’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.
+
+# References
+
+a. Risk Assessment Report Template
+
+# Policy
+
+a. *Risk Assessment*
+
+    i. The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.
+
+    i. The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
+
+    i. The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities. A sample risk assessment table is provided as part of the Risk Assessment Report Template (reference (a)).
+
+    i. For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
+
+    i. Once risk owners are identified, they must assess:
+
+        1. Consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes. 
+
+        1. Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).
+
+        1. Criteria for determining consequence and likelihood are defined in Tables 3 and 4.
+    
+    i. The risk level is calculated by adding the consequence score and the likelihood score.
+
+-----------------+-----------------+--------------------------------------------------------------+
+| **Consequence** | **Consequence** | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
+=================+=================+==============================================================+
+| Low             | 0               | Loss of confidentiality, integrity, or availability will not |     
+|                 |                 | affect the organization's cash flow, legal, or contractual   |                    
+|                 |                 | obligations, or reputation.                                  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Loss of confidentiality, integrity, or availability may incur|     
+|                 |                 | financial cost and has low or moderate impact on the         |                    
+|                 |                 | organization's legal or contractual obligations and/or       |
+|                 |                 | reputation.                                                  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Loss of confidentiality, integrity, or availability will have|     
+|                 |                 | immediate and or/considerable impact on the organization's   |                    
+|                 |                 | cash flow, operations, legal and contractual obligations,and/|
+|                 |                 | or reputation.                                               |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+
+Table 3: Description of Consequence Levels and Criteria
+
+-----------------+-----------------+--------------------------------------------------------------+
+| **Likelihood**  | **Likelihood**  | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
+=================+=================+==============================================================+
+| Low             | 0               | Either existing security controls are strong and have so far |     
+|                 |                 | provided an adequate level of protection, or the probability |                    
+|                 |                 | of the risk being realized is extremely low. No new incidents|
+|                 |                 | are expected in the future.                                  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Either existing security controls have most provided an      |     
+|                 |                 | adequate level of protection or the probability of the risk  |                    
+|                 |                 | being realized is moderate. Some minor incidents may have    |
+|                 |                 | occured. New incidents are possible, but not highly likely.  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Either existing security controls are not in place or        |
+|                 |                 | ineffective; there is a high probability of the risk being   |                    
+|                 |                 | realized. Incidents have a high likelihood of occuring in the|
+|                 |                 | future.                                             |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+
+Table 4: Description of Likelihood Levels and Criteria
+
+&nbsp;
+
+b. *Risk Acceptance Criteria*
+
+    i. Risk values 0 through 2 are considered to be acceptable risks.
+
+    i. Risk values 3 and 4 are considered to be unacceptable risks. Unacceptable risks must be treated.
+
+c. *Risk Treatment*
+
+    i. Risk treatment is implemented through the Risk Treatment Table. All risks from the Risk Assessment Table must be copied to the Risk Treatment Table for disposition, along with treatment options and residual risk. A sample Risk Treatment Table is provided in reference (a).
+
+    i. As part of this risk treatment process, the CEO and/or other company managers shall determine objectives for mitigating or treating risks. All unacceptable risks must be treated. For continuous improvement purposes, company managers may also opt to treat other risks for company assets, even if their risk score is deemed to be acceptable.
+
+    i. Treatment options for risks include the following options:
+
+        1. Selection or development of security control(s).
+
+        1. Transferring the risks to a third party; for example, by purchasing an insurance policy or signing a contract with suppliers or partners.
+
+        1. Avoiding the risk by discontinuing the business activity that causes such risk.
+
+        1. Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.
+
+    i. After selecting a treatment option, the risk owner should estimate the new consequence and likelihood values after the planned controls are implemented.
+
+a. *Regular Reviews of Risk Assessment and Risk Treatment*
+
+    i. The Risk Assessment Table and Risk Treatment Table must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year. It is highly recommended that the Risk Assessment and Risk Treatment Table be updated when significant changes occur to the organization, technology, business objectives, or business environment.
+
+a. *Reporting*
+
+    i. The results of risk assessment and risk treatment, and all subsequent reviews, shall be documented in a Risk Assessment Report.
+
--- a/example/policies/vendor.md
+++ b/example/policies/vendor.md
@@ -8,4 +8,40 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This policy defines the rules for relationships with the organization’s Information Technology (IT) vendors and partners. 
+
+a. This policy applies to all IT vendors and partners who have the ability to impact the confidentiality, integrity, and availability of the organization’s technology and sensitive information, or who are within the scope of the organization’s information security program.
+
+a. This policy applies to all employees and contractors that are responsible for the management and oversight of IT vendors and partners of the organization. 
+
+# Background
+
+a. The overall security of the organization is highly dependent on the security of its contractual relationships with its IT suppliers and partners. This policy defines  requirements for effective management and oversight of such suppliers and partners from an information security perspective. The policy prescribes minimum standards a vendor must meet from an information security standpoint, including security clauses, risk assessments, service level agreements, and incident management.
+
+# References
+
+a. Information Security Policy
+
+a. Security Incident Response Policy
+
+# Policy
+
+a. IT vendors are prohibited from accessing the organization’s information security assets until  a contract containing security controls is agreed to and signed by the appropriate parties.
+
+a. All IT vendors must comply with the security policies defined and derived from the Information Security Policy (reference (a)). 
+
+a. All security incidents by IT vendors or partners must be documented in accordance with the organization’s Security Incident Response Policy (reference (b)) and immediately forwarded to the Information Security Manager (ISM). 
+
+a. The organization must adhere to the terms of all Service Level Agreements (SLAs) entered into with IT vendors. As terms are updated, and as new ones are entered into, the organization must implement any changes or controls needed to ensure it remains in compliance. 
+
+a. Before entering into a contract and gaining access to the parent organization’s information systems, IT vendors must undergo a risk assessment. 
+
+    i. Security risks related to IT vendors and partners must be identified during the risk assessment process. 
+    
+    i. The risk assessment must identify risks related to information and communication technology, as well as risks related to IT vendor supply chains, to include sub-suppliers. 
+
+a. IT vendors and partners must ensure that organizational records are protected, safeguarded, and disposed of securely. The organization strictly adheres to all applicable legal, regulatory and contractual requirements regarding the collection, processing, and transmission of sensitive data such as Personally-Identifiable Information (PII). 
+
+a. The organization may choose to audit IT vendors and partners to ensure compliance with applicable security policies, as well as legal, regulatory and contractual obligations.
--- a/example/procedures/offboarding.md
+++ b/example/procedures/offboarding.md
@@ -2,4 +2,10 @@ id: "offboard"
 name: "Offboard User"
 ---

-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Immediately suspend user in SSO
+- [ ] Append HR termination request e-mail to this ticket
+- [ ] Look up manually-provisioned applications for this role or user
+- [ ] Validate access revocation in each
+- [ ] Append confirmation or revocation to this ticket
--- a/example/procedures/onboarding.md
+++ b/example/procedures/onboarding.md
@@ -2,4 +2,11 @@ id: "onboard"
 name: "Onboard New User"
 ---

-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Append HR add request e-mail to this ticket
+- [ ] Proactively validate role assignment with manager (see HR request e-mail)
+- [ ] Add user to default group for the specified role
+- [ ] Provision any manually-provisioned applications by role
+    - [ ] Append manual provisioning confirmation to this ticket
+- [ ] Proactively confirm with new user that they can access all provisioned systems
--- a/example/procedures/patch.md
+++ b/example/procedures/patch.md
@@ -1,6 +1,15 @@
 id: "patch"
 name: "Apply OS patches"
-cron: "0 0 1 * * *"
+cron: "0 0 0 15 * *"
 ---

-# Coming Soon
+# OS Patch Procedure
+
+Resolve this ticket by executing the following steps:
+
+- [ ] Pull the latest scripts from the Ops repository
+- [ ] Execute `ENV=staging patch-all.sh`
+- [ ] Inspect output
+    - [ ] Errors? Investigate and resolve
+- [ ] Execute `ENV=production patch-all.sh`
+- [ ] Attach log output to this ticket
--- a/example/procedures/workstation.md
+++ b/example/procedures/workstation.md
@@ -1,6 +1,40 @@
 id: "workstation"
 name: "Collect Workstation Details"
-cron: "0 0 * * * *"
+cron: "0 0 0 15 4 *"
 ---

-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Send the communications below
+- [ ] For any email replies, attach content to this ticket
+- [ ] Validate responses are received from each
+
+
+```
+To: Desktop support
+Subject: Annual workstation inventory
+
+Please attach the current workstation inventory to the following ticket: [REPLACE WITH URL TO THIS TICKET]
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```
+
+
+```
+To: Outsourced Call Center IT
+Subject: Annual workstation inventory
+
+As part of our ongoing compliance efforts and per our services agreement, we require a current inventory of workstations in use in the service of our account.
+
+Please respond to this message with the current inventory.
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```
--- a/example/templates/index.ace
+++ b/example/templates/index.ace
@@ -15,20 +15,11 @@ html lang=en
        document.querySelectorAll('.cron').forEach(function(el) {
          el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
        })
-        if (window.location.hash != "") {
-          var hashComponents = window.location.hash.split('#')
-          if (hashComponents.length>1) {
-            var destination = hashComponents[1]
-            if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
-              show(destination)
-            }
-          }
-        }
      })

      function show(name) {
        if (history.replaceState) {
-            history.replaceState(null, null, '#'+name);
+            history.replaceState(null, null, '#'+name)
        }

        var items = document.getElementsByClassName('top-nav')
@@ -233,7 +224,14 @@ html lang=en
        .content.has-text-centered
          p {{.Project.OrganizationName}} Confidential 2018
  = javascript
-    // commented for development
    if (window.location.hash=="") {
      show('overview')
+    } else {
+      var hashComponents = window.location.hash.split('#')
+      if (hashComponents.length>1) {
+        var destination = hashComponents[1]
+        if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
+          show(destination)
+        }
+      }
    }
--- a/go.mod
+++ b/go.mod
@@ -0,0 +1,50 @@
+module github.com/strongdm/comply
+
+go 1.12
+
+require (
+	github.com/Clever/gitsem v1.0.4
+	github.com/Microsoft/go-winio v0.4.14 // indirect
+	github.com/aktau/github-release v0.8.1
+	github.com/andygrunwald/go-jira v1.12.0
+	github.com/containous/go-bindata v1.0.0
+	github.com/cpuguy83/go-md2man/v2 v2.0.0 // indirect
+	github.com/davecgh/go-spew v1.1.1
+	github.com/docker/distribution v2.7.1+incompatible // indirect
+	github.com/docker/docker v1.13.1
+	github.com/docker/go-connections v0.4.0 // indirect
+	github.com/docker/go-units v0.4.0 // indirect
+	github.com/elazarl/go-bindata-assetfs v1.0.1
+	github.com/fatih/color v1.9.0
+	github.com/fatih/structs v1.1.0 // indirect
+	github.com/github-release/github-release v0.8.1 // indirect
+	github.com/gohugoio/hugo v0.75.0
+	github.com/google/go-github v17.0.0+incompatible
+	github.com/gorilla/websocket v1.4.2
+	github.com/hashicorp/go-retryablehttp v0.6.7 // indirect
+	github.com/inconshreveable/log15 v0.0.0-20200109203555-b30bc20e4fd1 // indirect
+	github.com/jcelliott/lumber v0.0.0-20160324203708-dd349441af25 // indirect
+	github.com/kevinburke/rest v0.0.0-20200429221318-0d2892b400f8 // indirect
+	github.com/lunixbochs/vtclean v1.0.0 // indirect
+	github.com/manifoldco/promptui v0.7.0
+	github.com/mattn/go-colorable v0.1.7 // indirect
+	github.com/mattn/go-runewidth v0.0.9 // indirect
+	github.com/nanobox-io/golang-scribble v0.0.0-20190309225732-aa3e7c118975
+	github.com/olekukonko/tablewriter v0.0.4
+	github.com/opencontainers/go-digest v1.0.0 // indirect
+	github.com/pkg/errors v0.9.1
+	github.com/robfig/cron v1.2.0
+	github.com/skratchdot/open-golang v0.0.0-20200116055534-eef842397966
+	github.com/tomnomnom/linkheader v0.0.0-20180905144013-02ca5825eb80 // indirect
+	github.com/trivago/tgo v1.0.7 // indirect
+	github.com/urfave/cli v1.22.4
+	github.com/voxelbrain/goptions v0.0.0-20180630082107-58cddc247ea2 // indirect
+	github.com/xanzy/go-gitlab v0.30.1
+	github.com/yosssi/ace v0.0.5
+	golang.org/x/net v0.0.0-20200904194848-62affa334b73 // indirect
+	golang.org/x/oauth2 v0.0.0-20200902213428-5d25da1a8d43
+	golang.org/x/sys v0.0.0-20200909081042-eff7692f9009 // indirect
+	golang.org/x/time v0.0.0-20200630173020-3af7569d3a1e // indirect
+	gopkg.in/blang/semver.v1 v1.1.0 // indirect
+	gopkg.in/yaml.v2 v2.3.0
+)
--- a/go.sum
+++ b/go.sum
--- a/internal/cli/app.go
+++ b/internal/cli/app.go
@@ -6,15 +6,24 @@ import (
 	"io"
 	"io/ioutil"
 	"log"
+	"math/rand"
+	"net/http"
 	"os"
+	"os/exec"
 	"path/filepath"
+	"regexp"
+	"strconv"
 	"strings"
 	"time"
+	"unicode"
+	"unicode/utf8"

 	"github.com/docker/docker/api/types"
 	"github.com/docker/docker/client"
 	"github.com/pkg/errors"
 	"github.com/strongdm/comply/internal/config"
+	"github.com/strongdm/comply/internal/gitlab"
+	"github.com/strongdm/comply/internal/jira"
 	"github.com/strongdm/comply/internal/plugin/github"
 	"github.com/urfave/cli"
 )
@@ -40,17 +49,20 @@ func newApp() *cli.App {
 	app.Usage = "policy compliance toolkit"

 	app.Commands = []cli.Command{
-		initCommand,
+		beforeCommand(initCommand, notifyVersion),
 	}

-	app.Commands = append(app.Commands, beforeCommand(buildCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(schedulerCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(serveCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(syncCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(todoCommand, projectMustExist))
+	app.Commands = append(app.Commands, beforeCommand(buildCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(procedureCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(schedulerCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(serveCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(syncCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(todoCommand, projectMustExist, notifyVersion))

 	// Plugins
 	github.Register()
+	jira.Register()
+	gitlab.Register()

 	return app
 }
@@ -95,7 +107,157 @@ func ticketingMustBeConfigured(c *cli.Context) error {
 	return nil
 }

-func dockerMustExist(c *cli.Context) error {
+// notifyVersion asynchronously notifies the availability of version updates
+func notifyVersion(c *cli.Context) error {
+	go func() {
+		defer func() {
+			recover() // suppress panic
+		}()
+
+		r, err := http.Get("http://comply-releases.s3.amazonaws.com/channel/stable/VERSION")
+		body, err := ioutil.ReadAll(r.Body)
+		if err != nil {
+			// fail silently
+		}
+
+		version := strings.TrimSpace(string(body))
+
+		// only when numeric versions are present
+		firstRune, _ := utf8.DecodeRuneInString(string(body))
+		if unicode.IsDigit(firstRune) && version != Version {
+			// only once every ~10 times
+			if rand.Intn(10) == 0 {
+				fmt.Fprintf(os.Stderr, "a new version of comply is available")
+			}
+		}
+	}()
+	return nil
+}
+
+func pandocMustExist(c *cli.Context) error {
+	eitherMustExistErr := fmt.Errorf("\n\nPlease install either Docker or the pandoc package and re-run `%s`. Find OS-specific pandoc installation instructions at: [TODO]", c.Command.Name)
+
+	pandocExistErr, found, goodVersion, pdfLatex := pandocBinaryMustExist(c)
+	dockerExistErr, inPath, isRunning := dockerMustExist(c)
+
+	config.SetPandoc(pandocExistErr == nil, dockerExistErr == nil)
+	check := func(b bool) string {
+		if b {
+			return "✔"
+		} else {
+			return "✖"
+		}
+
+	}
+
+	if pandocExistErr != nil && dockerExistErr != nil {
+
+		fmt.Printf(`
+[%s] pandoc binary installed and in PATH
+[%s] pandoc version compatible
+[%s] pdflatex binary installed and in PATH
+[%s] docker binary installed
+[%s] docker running
+
+`, check(found), check(goodVersion), check(pdfLatex), check(inPath), check(isRunning))
+
+		return eitherMustExistErr
+	}
+
+	// if we don't have pandoc, but we do have docker, execute a pull
+	if (pandocExistErr != nil && dockerExistErr == nil) || config.WhichPandoc() == config.UseDocker {
+		dockerPull(c)
+	}
+
+	return nil
+}
+
+func pandocBinaryMustExist(c *cli.Context) (e error, found, goodVersion, pdfLatex bool) {
+	cmd := exec.Command("pandoc", "-v")
+	outputRaw, err := cmd.Output()
+
+	e = nil
+	found = false
+	goodVersion = false
+	pdfLatex = false
+
+	if err != nil {
+		e = errors.Wrap(err, "error calling pandoc")
+	} else {
+		found = true
+		goodVersion = true
+		output := strings.TrimSpace((string(outputRaw)))
+		versionErr := errors.New("cannot determine pandoc version")
+		if !strings.HasPrefix(output, "pandoc") {
+			e = versionErr
+			goodVersion = false
+		} else {
+			re := regexp.MustCompile(`pandoc (\d+)\.(\d+)`)
+			result := re.FindStringSubmatch(output)
+			if len(result) != 3 {
+				e = versionErr
+				goodVersion = false
+			} else {
+				major, err := strconv.Atoi(result[1])
+				if err != nil {
+					e = versionErr
+					goodVersion = false
+				}
+				minor, err := strconv.Atoi(result[2])
+				if err != nil {
+					e = versionErr
+					goodVersion = false
+				}
+				if major < 2 || minor < 1 {
+					e = errors.New("pandoc 2.1 or greater required")
+					goodVersion = false
+				}
+			}
+		}
+	}
+
+	// pdflatex must also be present
+	cmd = exec.Command("pdflatex", "--version")
+	outputRaw, err = cmd.Output()
+	if err != nil {
+		e = errors.Wrap(err, "error calling pdflatex")
+	} else if !strings.Contains(string(outputRaw), "TeX") {
+		e = errors.New("pdflatex is required")
+	} else {
+		pdfLatex = true
+	}
+
+	return e, found, goodVersion, pdfLatex
+}
+
+func dockerMustExist(c *cli.Context) (e error, inPath, isRunning bool) {
+	dockerErr := fmt.Errorf("Docker must be available in order to run `%s`", c.Command.Name)
+
+	inPath = true
+	cmd := exec.Command("docker", "--version")
+	_, err := cmd.Output()
+	if err != nil {
+		inPath = false
+	}
+
+	isRunning = true
+	ctx := context.Background()
+	cli, err := client.NewEnvClient()
+	if err != nil {
+		isRunning = false
+		return dockerErr, inPath, isRunning
+	}
+
+	_, err = cli.Ping(ctx)
+	if err != nil {
+		isRunning = false
+		return dockerErr, inPath, isRunning
+	}
+
+	return nil, inPath, isRunning
+}
+
+func dockerPull(c *cli.Context) error {
 	dockerErr := fmt.Errorf("Docker must be available in order to run `%s`", c.Command.Name)

 	ctx := context.Background()
@@ -145,12 +307,17 @@ func dockerMustExist(c *cli.Context) error {
 }

 func cleanContainers(c *cli.Context) error {
-	dockerErr := fmt.Errorf("Docker must be available in order to run `%s`", c.Command.Name)
-
 	ctx := context.Background()
 	cli, err := client.NewEnvClient()
 	if err != nil {
-		return dockerErr
+		// no Docker? nothing to clean.
+		return nil
+	}
+
+	_, err = cli.Ping(ctx)
+	if err != nil {
+		// no Docker? nothing to clean.
+		return nil
 	}

 	containers, err := cli.ContainerList(ctx, types.ContainerListOptions{All: true})
--- a/internal/cli/build.go
+++ b/internal/cli/build.go
@@ -11,7 +11,7 @@ var buildCommand = cli.Command{
 	ShortName: "b",
 	Usage:     "generate a static website summarizing the compliance program",
 	Action:    buildAction,
-	Before:    beforeAll(dockerMustExist, cleanContainers),
+	Before:    beforeAll(pandocMustExist, cleanContainers),
 }

 func buildAction(c *cli.Context) error {
--- a/internal/cli/init.go
+++ b/internal/cli/init.go
@@ -100,7 +100,7 @@ func initAction(c *cli.Context) error {

 	chooser = promptui.Select{
 		Label: "Ticket System",
-		Items: []string{"GitHub", "Jira", "None"},
+		Items: []string{"GitHub", "Jira", "GitLab", "None"},
 	}

 	choice, _, err = chooser.Run()
@@ -116,8 +116,9 @@ func initAction(c *cli.Context) error {
 	case 0:
 		ticketing = model.GitHub
 	case 1:
-		fmt.Println("\nHello Jira user! The Jira ticketing plugin is currently in development, please join us on Slack for a status update.")
-		ticketing = model.NoTickets
+		ticketing = model.Jira
+	case 2:
+		ticketing = model.GitLab
 	default:
 		ticketing = model.NoTickets
 	}
--- a/internal/cli/procedure.go
+++ b/internal/cli/procedure.go
@@ -0,0 +1,53 @@
+package cli
+
+import (
+	"fmt"
+
+	"github.com/strongdm/comply/internal/config"
+	"github.com/strongdm/comply/internal/model"
+	"github.com/urfave/cli"
+)
+
+var procedureCommand = cli.Command{
+	Name:      "procedure",
+	ShortName: "proc",
+	Usage:     "create ticket by procedure ID",
+	ArgsUsage: "procedureID",
+	Action:    procedureAction,
+	Before:    beforeAll(projectMustExist, ticketingMustBeConfigured),
+}
+
+func procedureAction(c *cli.Context) error {
+	procedures, err := model.ReadProcedures()
+	if err != nil {
+		return err
+	}
+
+	if c.NArg() != 1 {
+		return cli.NewExitError("provide a procedure ID", 1)
+	}
+
+	procedureID := c.Args().First()
+
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return cli.NewExitError("error in ticket system configuration", 1)
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
+
+	for _, procedure := range procedures {
+		if procedure.ID == procedureID {
+			err = tp.Create(&model.Ticket{
+				Name: procedure.Name,
+				Body: fmt.Sprintf("%s\n\n\n---\nProcedure-ID: %s", procedure.Body, procedure.ID),
+			}, []string{"comply", "comply-procedure"})
+			if err != nil {
+				return err
+			}
+			return nil
+		}
+	}
+
+	return cli.NewExitError(fmt.Sprintf("unknown procedure ID: %s", procedureID), 1)
+}
--- a/internal/cli/serve.go
+++ b/internal/cli/serve.go
@@ -9,8 +9,15 @@ import (
 var serveCommand = cli.Command{
 	Name:  "serve",
 	Usage: "live updating version of the build command",
+	Flags: []cli.Flag{
+		cli.IntFlag{
+			Name:        "port",
+			Value:       4000,
+			Destination: &render.ServePort,
+		},
+	},
 	Action: serveAction,
-	Before: beforeAll(dockerMustExist, cleanContainers),
+	Before: beforeAll(pandocMustExist, cleanContainers),
 }

 func serveAction(c *cli.Context) error {
--- a/internal/cli/sync.go
+++ b/internal/cli/sync.go
@@ -1,6 +1,7 @@
 package cli

 import (
+	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 	"github.com/urfave/cli"
 )
@@ -13,8 +14,12 @@ var syncCommand = cli.Command{
 }

 func syncAction(c *cli.Context) error {
-	// TODO: unhardcode plugin
-	tp := model.GetPlugin(model.GitHub)
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return cli.NewExitError("error in ticket system configuration", 1)
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
 	tickets, err := tp.FindByTagName("comply")
 	if err != nil {
 		return err
--- a/internal/config/config.go
+++ b/internal/config/config.go
@@ -1,6 +1,7 @@
 package config

 import (
+	"errors"
 	"io/ioutil"
 	"os"
 	"path/filepath"
@@ -10,6 +11,22 @@ import (

 var projectRoot string

+var dockerAvailable, pandocAvailable bool
+
+const (
+	Jira      = "jira"
+	GitHub    = "github"
+	GitLab    = "gitlab"
+	NoTickets = "none"
+)
+
+const (
+	// UseDocker invokes pandoc within Docker
+	UseDocker = "docker"
+	// UsePandoc invokes pandoc directly
+	UsePandoc = "pandoc"
+)
+
 // SetProjectRoot is used by the test suite.
 func SetProjectRoot(dir string) {
 	projectRoot = dir
@@ -17,8 +34,31 @@ func SetProjectRoot(dir string) {

 type Project struct {
 	Name           string                 `yaml:"name"`
+	Pandoc         string                 `yaml:"pandoc,omitempty"`
 	FilePrefix     string                 `yaml:"filePrefix"`
 	Tickets        map[string]interface{} `yaml:"tickets"`
+	ApprovedBranch string                 `yaml:"approvedBranch"`
+}
+
+// SetPandoc records pandoc availability during initialization
+func SetPandoc(pandoc bool, docker bool) {
+	pandocAvailable = pandoc
+	dockerAvailable = docker
+}
+
+// WhichPandoc indicates which pandoc invocation path should be used
+func WhichPandoc() string {
+	cfg := Config()
+	if cfg.Pandoc == UsePandoc {
+		return UsePandoc
+	}
+	if cfg.Pandoc == UseDocker {
+		return UseDocker
+	}
+	if pandocAvailable {
+		return UsePandoc
+	}
+	return UseDocker
 }

 // YAML is the parsed contents of ProjectRoot()/config.yml.
@@ -42,14 +82,14 @@ func Exists() bool {
 }

 // Config is the parsed contents of ProjectRoot()/config.yml.
-func Config() Project {
+func Config() *Project {
 	p := Project{}
 	cfgBytes, err := ioutil.ReadFile(filepath.Join(ProjectRoot(), "comply.yml"))
 	if err != nil {
 		panic("unable to load config.yml: " + err.Error())
 	}
 	yaml.Unmarshal(cfgBytes, &p)
-	return p
+	return &p
 }

 // ProjectRoot is the fully-qualified path to the root directory.
@@ -64,3 +104,29 @@ func ProjectRoot() string {

 	return projectRoot
 }
+
+// TicketSystem indicates the type of the configured ticket system
+func (p *Project) TicketSystem() (string, error) {
+	if len(p.Tickets) > 1 {
+		return NoTickets, errors.New("multiple ticket systems configured")
+	}
+
+	for k := range p.Tickets {
+		switch k {
+		case GitHub:
+			return GitHub, nil
+		case Jira:
+			return Jira, nil
+		case GitLab:
+			return GitLab, nil
+		case NoTickets:
+			return NoTickets, nil
+		default:
+			// explicit error for this case
+			return "", errors.New("unrecognized ticket system configured")
+		}
+	}
+
+	// no ticket block configured
+	return NoTickets, nil
+}
--- a/internal/gitlab/gitlab.go
+++ b/internal/gitlab/gitlab.go
@@ -0,0 +1,218 @@
+package gitlab
+
+import (
+	"fmt"
+	"strconv"
+	"sync"
+
+	"github.com/pkg/errors"
+	"github.com/strongdm/comply/internal/model"
+	"github.com/xanzy/go-gitlab"
+)
+
+const (
+	cfgDomain = "domain"
+	cfgToken  = "token"
+	cfgRepo   = "repo"
+)
+
+var prompts = map[string]string{
+	cfgDomain: "Fully Qualified GitLab Domain",
+	cfgToken:  "GitLab Token",
+	cfgRepo:   "GitLab Repository",
+}
+
+// Prompts are human-readable configuration element names
+func (g *gitlabPlugin) Prompts() map[string]string {
+	return prompts
+}
+
+// Register causes the Github plugin to register itself
+func Register() {
+	model.Register(model.GitLab, &gitlabPlugin{})
+}
+
+type gitlabPlugin struct {
+	domain   string
+	token    string
+	reponame string
+
+	clientMu sync.Mutex
+	client   *gitlab.Client
+}
+
+func (g *gitlabPlugin) api() *gitlab.Client {
+	g.clientMu.Lock()
+	defer g.clientMu.Unlock()
+	if g.client == nil {
+		// get go-gitlab client
+		gl := gitlab.NewClient(nil, g.token)
+		gl.SetBaseURL(g.domain)
+		g.client = gl
+	}
+	return g.client
+}
+
+func (g *gitlabPlugin) Get(ID string) (*model.Ticket, error) {
+	return nil, nil
+}
+
+func (g *gitlabPlugin) Configured() bool {
+	return g.reponame != "" && g.token != ""
+}
+
+func (g *gitlabPlugin) Links() model.TicketLinks {
+	links := model.TicketLinks{}
+	links.AuditAll = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=all&label_name[]=comply-audit", g.domain, g.reponame)
+	links.AuditOpen = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=opened&label_name[]=comply-audit", g.domain, g.reponame)
+	links.ProcedureAll = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=all&label_name[]=comply-procedure", g.domain, g.reponame)
+	links.ProcedureOpen = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=opened&label_name[]=comply-procedure", g.domain, g.reponame)
+	return links
+}
+
+func (g *gitlabPlugin) Configure(cfg map[string]interface{}) error {
+	var err error
+
+	if g.domain, err = getCfg(cfg, cfgDomain); err != nil {
+		return err
+	}
+	if g.token, err = getCfg(cfg, cfgToken); err != nil {
+		return err
+	}
+	if g.reponame, err = getCfg(cfg, cfgRepo); err != nil {
+		return err
+	}
+
+	return nil
+}
+
+func getCfg(cfg map[string]interface{}, k string) (string, error) {
+	v, ok := cfg[k]
+	if !ok {
+		return "", errors.New("Missing key: " + k)
+	}
+
+	vS, ok := v.(string)
+	if !ok {
+		return "", errors.New("Malformatted key: " + k)
+	}
+	return vS, nil
+}
+
+func getProjectIssues(g *gitlabPlugin, options *gitlab.ListProjectIssuesOptions) ([]*gitlab.Issue, error) {
+	issues := []*gitlab.Issue{}
+	options.Page = 1
+
+	for {
+		pageIssues, resp, err := g.api().Issues.ListProjectIssues(g.reponame, options)
+		if err != nil {
+			return nil, errors.Wrap(err, "error retreiving issues from gitlab")
+		}
+
+		issues = append(issues, pageIssues...)
+
+		if resp.CurrentPage >= resp.TotalPages {
+			break
+		}
+		options.Page = resp.NextPage
+	}
+
+	return issues, nil
+}
+
+func (g *gitlabPlugin) FindOpen() ([]*model.Ticket, error) {
+	options := &gitlab.ListProjectIssuesOptions{
+		State: gitlab.String("opened"),
+	}
+
+	issues, err := getProjectIssues(g, options)
+	if err != nil {
+		return nil, errors.Wrap(err, "error during FindOpen")
+	}
+
+	return toTickets(issues), nil
+}
+
+func (g *gitlabPlugin) FindByTag(name, value string) ([]*model.Ticket, error) {
+	panic("not implemented")
+}
+
+func (g *gitlabPlugin) FindByTagName(name string) ([]*model.Ticket, error) {
+	options := &gitlab.ListProjectIssuesOptions{
+		State:  gitlab.String("all"),
+		Labels: []string{name},
+	}
+
+	issues, err := getProjectIssues(g, options)
+	if err != nil {
+		return nil, errors.Wrap(err, "error during FindByTagName")
+	}
+
+	return toTickets(issues), nil
+}
+
+func (g *gitlabPlugin) LinkFor(t *model.Ticket) string {
+	panic("not implemented")
+}
+
+func (g *gitlabPlugin) Create(ticket *model.Ticket, labels []string) error {
+	l := gitlab.Labels(labels)
+	options := &gitlab.CreateIssueOptions{
+		Title:       gitlab.String(ticket.Name),
+		Description: gitlab.String(ticket.Body),
+		Labels:      &l,
+	}
+	_, _, err := g.api().Issues.CreateIssue(g.reponame, options)
+	return err
+}
+
+func toTickets(issues []*gitlab.Issue) []*model.Ticket {
+	var tickets []*model.Ticket
+	for _, i := range issues {
+		tickets = append(tickets, toTicket(i))
+	}
+	return tickets
+}
+
+func toTicket(i *gitlab.Issue) *model.Ticket {
+	t := &model.Ticket{Attributes: make(map[string]interface{})}
+	t.ID = strconv.Itoa(i.ID)
+	t.Name = i.Title
+	t.Body = i.Description
+	t.CreatedAt = i.CreatedAt
+	t.State = toState(i.State)
+
+	for _, l := range i.Labels {
+		if l == "audit" {
+			t.SetBool("comply-audit")
+		}
+		if l == "procedure" {
+			t.SetBool("comply-procedure")
+		}
+
+		// seems redundant, but fixes a bug the other two labels introduce
+		// whereby open comply tickets aren't properly accounted for in the UI
+		if l == "comply-audit" {
+			t.SetBool("comply-audit")
+		}
+		if l == "comply-procedure" {
+			t.SetBool("comply-procedure")
+		}
+	}
+	return t
+}
+
+func toState(state string) model.TicketState {
+	switch state {
+	case "closed":
+		return model.Closed
+	}
+	return model.Open
+}
+
+func ss(s *string) string {
+	if s == nil {
+		return ""
+	}
+	return *s
+}
--- a/internal/gitlab/gitlab_test.go
+++ b/internal/gitlab/gitlab_test.go
@@ -0,0 +1,9 @@
+package gitlab
+
+import (
+	"testing"
+)
+
+func TestGitlab(t *testing.T) {
+	createOne()
+}
--- a/internal/jira/jira.go
+++ b/internal/jira/jira.go
@@ -0,0 +1,193 @@
+package jira
+
+import (
+	"fmt"
+	"sync"
+	"time"
+
+	"github.com/pkg/errors"
+	"github.com/strongdm/comply/internal/model"
+
+	jira "github.com/andygrunwald/go-jira"
+)
+
+const (
+	cfgUsername = "username"
+	cfgPassword = "password"
+	cfgURL      = "url"
+	cfgProject  = "project"
+	cfgTaskType = "taskType"
+)
+
+var prompts = map[string]string{
+	cfgUsername: "Jira Username",
+	cfgPassword: "Jira Password",
+	cfgURL:      "Jira URL",
+	cfgProject:  "Jira Project Code",
+	cfgTaskType: "Jira Task Type",
+}
+
+// Prompts are human-readable configuration element names
+func (j *jiraPlugin) Prompts() map[string]string {
+	return prompts
+}
+
+// Register causes the Github plugin to register itself
+func Register() {
+	model.Register(model.Jira, &jiraPlugin{})
+}
+
+type jiraPlugin struct {
+	username string
+	password string
+	url      string
+	project  string
+	taskType string
+
+	clientMu sync.Mutex
+	client   *jira.Client
+}
+
+func (j *jiraPlugin) api() *jira.Client {
+	j.clientMu.Lock()
+	defer j.clientMu.Unlock()
+
+	if j.client == nil {
+		tp := jira.BasicAuthTransport{
+			Username: j.username,
+			Password: j.password,
+		}
+
+		client, _ := jira.NewClient(tp.Client(), j.url)
+		j.client = client
+	}
+	return j.client
+}
+
+func (j *jiraPlugin) Get(ID string) (*model.Ticket, error) {
+	return nil, nil
+}
+
+func (j *jiraPlugin) Configured() bool {
+	return j.username != "" && j.password != "" && j.url != "" && j.project != "" && j.taskType != ""
+}
+
+func (j *jiraPlugin) Links() model.TicketLinks {
+	links := model.TicketLinks{}
+	links.ProcedureAll = fmt.Sprintf("%s/issues/?jql=labels+=+comply-procedure", j.url)
+	links.ProcedureOpen = fmt.Sprintf("%s/issues/?jql=labels+=+comply-procedure+AND+resolution+=+Unresolved", j.url)
+	// links.AuditAll = fmt.Sprintf("%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", j.url)
+	// links.AuditOpen = fmt.Sprintf("%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", j.url)
+	return links
+}
+
+func (j *jiraPlugin) Configure(cfg map[string]interface{}) error {
+	var err error
+
+	if j.username, err = getCfg(cfg, cfgUsername); err != nil {
+		return err
+	}
+	if j.password, err = getCfg(cfg, cfgPassword); err != nil {
+		return err
+	}
+	if j.url, err = getCfg(cfg, cfgURL); err != nil {
+		return err
+	}
+	if j.project, err = getCfg(cfg, cfgProject); err != nil {
+		return err
+	}
+	if j.taskType, err = getCfg(cfg, cfgTaskType); err != nil {
+		return err
+	}
+
+	return nil
+}
+
+func getCfg(cfg map[string]interface{}, k string) (string, error) {
+	v, ok := cfg[k]
+	if !ok {
+		return "", errors.New("Missing key: " + k)
+	}
+
+	vS, ok := v.(string)
+	if !ok {
+		return "", errors.New("Malformatted key: " + k)
+	}
+	return vS, nil
+}
+
+func (j *jiraPlugin) FindOpen() ([]*model.Ticket, error) {
+	panic("not implemented")
+}
+
+func (j *jiraPlugin) FindByTag(name, value string) ([]*model.Ticket, error) {
+	panic("not implemented")
+}
+
+func (j *jiraPlugin) FindByTagName(name string) ([]*model.Ticket, error) {
+	issues, _, err := j.api().Issue.Search("labels=comply", &jira.SearchOptions{MaxResults: 1000})
+	if err != nil {
+		return nil, errors.Wrap(err, "unable to fetch Jira issues")
+	}
+	return toTickets(issues), nil
+}
+
+func (j *jiraPlugin) LinkFor(t *model.Ticket) string {
+	panic("not implemented")
+}
+
+func (j *jiraPlugin) Create(ticket *model.Ticket, labels []string) error {
+	i := jira.Issue{
+		Fields: &jira.IssueFields{
+			Type: jira.IssueType{
+				Name: j.taskType,
+			},
+			Project: jira.Project{
+				Key: j.project,
+			},
+			Summary:     ticket.Name,
+			Description: ticket.Body,
+			Labels:      labels,
+		},
+	}
+
+	_, _, err := j.api().Issue.Create(&i)
+	if err != nil {
+		return errors.Wrap(err, "unable to create ticket")
+	}
+	return nil
+}
+
+func toTickets(issues []jira.Issue) []*model.Ticket {
+	var tickets []*model.Ticket
+	for _, i := range issues {
+		tickets = append(tickets, toTicket(&i))
+	}
+	return tickets
+}
+
+func toTicket(i *jira.Issue) *model.Ticket {
+	t := &model.Ticket{Attributes: make(map[string]interface{})}
+	t.ID = i.ID
+	t.Name = i.Fields.Summary
+	t.Body = i.Fields.Description
+	createdAt := time.Time(i.Fields.Created)
+	t.CreatedAt = &createdAt
+	t.State = toState(i.Fields.Resolution)
+
+	for _, l := range i.Fields.Labels {
+		t.SetBool(l)
+	}
+	return t
+}
+
+func toState(status *jira.Resolution) model.TicketState {
+	if status == nil {
+		return model.Open
+	}
+	switch status.Name {
+	case "Done":
+		return model.Closed
+	}
+	return model.Open
+}
--- a/internal/jira/jira_test.go
+++ b/internal/jira/jira_test.go
@@ -0,0 +1,9 @@
+package jira
+
+import (
+	"testing"
+)
+
+func TestJira(t *testing.T) {
+	createOne()
+}
--- a/internal/model/document.go
+++ b/internal/model/document.go
@@ -2,7 +2,7 @@ package model

 import "time"

-type Policy struct {
+type Document struct {
 	Name    string `yaml:"name"`
 	Acronym string `yaml:"acronym"`

--- a/internal/model/fs.go
+++ b/internal/model/fs.go
@@ -91,8 +91,8 @@ func ReadStandards() ([]*Standard, error) {
 }

 // ReadNarratives loads narrative descriptions from the filesystem.
-func ReadNarratives() ([]*Narrative, error) {
-	var narratives []*Narrative
+func ReadNarratives() ([]*Document, error) {
+	var narratives []*Document

 	files, err := path.Narratives()
 	if err != nil {
@@ -100,7 +100,7 @@ func ReadNarratives() ([]*Narrative, error) {
 	}

 	for _, f := range files {
-		n := &Narrative{}
+		n := &Document{}
 		mdmd := loadMDMD(f.FullPath)
 		err = yaml.Unmarshal([]byte(mdmd.yaml), &n)
 		if err != nil {
@@ -141,8 +141,8 @@ func ReadProcedures() ([]*Procedure, error) {
 }

 // ReadPolicies loads policy documents from the filesystem.
-func ReadPolicies() ([]*Policy, error) {
-	var policies []*Policy
+func ReadPolicies() ([]*Document, error) {
+	var policies []*Document

 	files, err := path.Policies()
 	if err != nil {
@@ -150,7 +150,7 @@ func ReadPolicies() ([]*Policy, error) {
 	}

 	for _, f := range files {
-		p := &Policy{}
+		p := &Document{}
 		mdmd := loadMDMD(f.FullPath)
 		err = yaml.Unmarshal([]byte(mdmd.yaml), &p)
 		if err != nil {
@@ -179,6 +179,9 @@ func loadMDMD(path string) metadataMarkdown {

 	content := string(bytes)
 	components := strings.Split(content, "---")
+	if components[0] == "" && (len(components) > 1) {
+		components = components[1:]
+	}
 	if len(components) == 1 {
 		panic(fmt.Sprintf("Malformed metadata markdown in %s, must be of the form: YAML\\n---\\nmarkdown content", path))
 	}
--- a/internal/model/model.go
+++ b/internal/model/model.go
@@ -2,8 +2,8 @@ package model

 type Data struct {
 	Standards  []*Standard
-	Narratives []*Narrative
-	Policies   []*Policy
+	Narratives []*Document
+	Policies   []*Document
 	Procedures []*Procedure
 	Tickets    []*Ticket
 	Audits     []*Audit
--- a/internal/model/narrative.go
+++ b/internal/model/narrative.go
@@ -1,15 +0,0 @@
-package model
-
-import "time"
-
-type Narrative struct {
-	Name    string `yaml:"name"`
-	Acronym string `yaml:"acronym"`
-
-	Revisions      []Revision   `yaml:"majorRevisions"`
-	Satisfies      Satisfaction `yaml:"satisfies"`
-	FullPath       string
-	OutputFilename string
-	ModifiedAt     time.Time
-	Body           string
-}
--- a/internal/model/plugin.go
+++ b/internal/model/plugin.go
@@ -17,11 +17,13 @@ type TicketSystem string

 const (
 	// Jira from Atlassian.
-	Jira = TicketSystem("jira")
+	Jira = TicketSystem(config.Jira)
 	// GitHub from GitHub.
-	GitHub = TicketSystem("github")
+	GitHub = TicketSystem(config.GitHub)
+	// GitLab from GitLab.
+	GitLab = TicketSystem(config.GitLab)
 	// NoTickets indicates no ticketing system integration.
-	NoTickets = TicketSystem("none")
+	NoTickets = TicketSystem(config.NoTickets)
 )

 type TicketLinks struct {
@@ -50,6 +52,10 @@ func GetPlugin(ts TicketSystem) TicketPlugin {
 	tsPluginsMu.Lock()
 	defer tsPluginsMu.Unlock()

+	if ts == NoTickets {
+		return &noopTicketSystem{}
+	}
+
 	tp, ok := tsPlugins[ts]
 	if !ok {
 		panic("Unknown ticket system: " + ts)
@@ -81,7 +87,10 @@ func GetPlugin(ts TicketSystem) TicketPlugin {
 					}
 					cfgStringed[kS] = v
 				}
-				tp.Configure(cfgStringed)
+				err := tp.Configure(cfgStringed)
+				if err != nil {
+					panic(fmt.Sprintf("Configuration error `%s` in project YAML", err))
+				}
 			}
 		})
 	}
@@ -100,3 +109,36 @@ func Register(ts TicketSystem, plugin TicketPlugin) {

 	tsPlugins[ts] = plugin
 }
+
+type noopTicketSystem struct{}
+
+func (*noopTicketSystem) Get(ID string) (*Ticket, error) {
+	return nil, nil
+}
+func (*noopTicketSystem) FindOpen() ([]*Ticket, error) {
+	return []*Ticket{}, nil
+}
+func (*noopTicketSystem) FindByTag(name, value string) ([]*Ticket, error) {
+	return []*Ticket{}, nil
+}
+func (*noopTicketSystem) FindByTagName(name string) ([]*Ticket, error) {
+	return []*Ticket{}, nil
+}
+func (*noopTicketSystem) Create(ticket *Ticket, labels []string) error {
+	return nil
+}
+func (*noopTicketSystem) Configure(map[string]interface{}) error {
+	return nil
+}
+func (*noopTicketSystem) Prompts() map[string]string {
+	return make(map[string]string)
+}
+func (*noopTicketSystem) Links() TicketLinks {
+	return TicketLinks{}
+}
+func (*noopTicketSystem) LinkFor(ticket *Ticket) string {
+	return ""
+}
+func (*noopTicketSystem) Configured() bool {
+	return false
+}
--- a/internal/plugin/github/github.go
+++ b/internal/plugin/github/github.go
@@ -3,7 +3,9 @@ package github
 import (
 	"context"
 	"fmt"
+	"os"
 	"strconv"
+	"strings"
 	"sync"

 	"github.com/google/go-github/github"
@@ -69,10 +71,10 @@ func (g *githubPlugin) Configured() bool {

 func (g *githubPlugin) Links() model.TicketLinks {
 	links := model.TicketLinks{}
-	links.AuditAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", g.username, g.reponame)
-	links.AuditOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", g.username, g.reponame)
-	links.ProcedureAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+label%3Acomply+label%3Aprocedure", g.username, g.reponame)
-	links.ProcedureOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aprocedure", g.username, g.reponame)
+	links.AuditAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+is%%3Aopen+label%%3Acomply+label%%3Aaudit", g.username, g.reponame)
+	links.AuditOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+is%%3Aopen+label%%3Acomply+label%%3Aaudit", g.username, g.reponame)
+	links.ProcedureAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+label%%3Acomply+label%%3Acomply-procedure", g.username, g.reponame)
+	links.ProcedureOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+is%%3Aopen+label%%3Acomply+label%%3Acomply-procedure", g.username, g.reponame)
 	return links
 }

@@ -95,8 +97,11 @@ func (g *githubPlugin) Configure(cfg map[string]interface{}) error {
 func getCfg(cfg map[string]interface{}, k string) (string, error) {
 	v, ok := cfg[k]
 	if !ok {
+		v = os.Getenv(fmt.Sprintf("GITHUB_%s", strings.ToUpper(k)))
+		if v == "" {
 			return "", errors.New("Missing key: " + k)
 		}
+	}

 	vS, ok := v.(string)
 	if !ok {
@@ -135,7 +140,8 @@ func (g *githubPlugin) FindByTagName(name string) ([]*model.Ticket, error) {
 }

 func (g *githubPlugin) LinkFor(t *model.Ticket) string {
-	return fmt.Sprintf("https://github.com/strongdm/comply/issues/%s", t.ID)
+	// return fmt.Sprintf("https://github.com/strongdm/comply/issues/%s", t.ID)
+	panic("not implemented")
 }

 func (g *githubPlugin) Create(ticket *model.Ticket, labels []string) error {
--- a/internal/render/controller.go
+++ b/internal/render/controller.go
@@ -5,6 +5,7 @@ import (
 	"sort"
 	"time"

+	"github.com/pkg/errors"
 	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 )
@@ -32,8 +33,8 @@ type renderData struct {
 	Name       string
 	Project    *project
 	Stats      *stats
-	Narratives []*model.Narrative
-	Policies   []*model.Policy
+	Narratives []*model.Document
+	Policies   []*model.Document
 	Procedures []*model.Procedure
 	Standards  []*model.Standard
 	Tickets    []*model.Ticket
@@ -93,8 +94,12 @@ func load() (*model.Data, *renderData, error) {
 	rd.Name = project.OrganizationName
 	rd.Controls = controls

-	// TODO: unhardcode plugin
-	tp := model.GetPlugin(model.GitHub)
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return nil, nil, errors.Wrap(err, "error in ticket system configuration")
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
 	if tp.Configured() {
 		links := tp.Links()
 		rd.Links = &links
@@ -133,7 +138,7 @@ func addStats(modelData *model.Data, renderData *renderData) {
 		}

 		if t.State == model.Open {
-			if t.Bool("procedure") {
+			if t.Bool("comply-procedure") {
 				stats.ProcedureOpen++
 				if t.CreatedAt != nil {
 					age := int(time.Since(*t.CreatedAt).Hours() / float64(24))
--- a/internal/render/document.go
+++ b/internal/render/document.go
@@ -2,7 +2,6 @@ package render

 import (
 	"bytes"
-	"context"
 	"fmt"
 	"io/ioutil"
 	"os"
@@ -12,97 +11,34 @@ import (
 	"text/template"
 	"time"

-	"github.com/docker/docker/api/types"
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
+	"os/exec"
+
 	"github.com/pkg/errors"
 	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 )

 // TODO: refactor and eliminate duplication among narrative, policy renderers
-func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *renderData, policy *model.Policy, live bool) {
+func renderToFilesystem(wg *sync.WaitGroup, errOutputCh chan error, data *renderData, doc *model.Document, live bool) {
 	// only files that have been touched
-	if !isNewer(policy.FullPath, policy.ModifiedAt) {
+	if !isNewer(doc.FullPath, doc.ModifiedAt) {
 		return
 	}
-	recordModified(policy.FullPath, policy.ModifiedAt)
-
-	ctx := context.Background()
-	cli, err := client.NewEnvClient()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to read Docker environment")
-		return
-	}
-
-	pwd, err := os.Getwd()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to get workding directory")
-		return
-	}
-
-	hc := &container.HostConfig{
-		Binds: []string{pwd + ":/source"},
-	}
+	recordModified(doc.FullPath, doc.ModifiedAt)

 	wg.Add(1)
-	go func(p *model.Policy) {
+	go func(p *model.Document) {
 		defer wg.Done()

-		if live {
-			rel, err := filepath.Rel(config.ProjectRoot(), p.FullPath)
-			if err != nil {
-				rel = p.FullPath
-			}
-			fmt.Printf("%s -> %s\n", rel, filepath.Join("output", p.OutputFilename))
-		}
-
 		outputFilename := p.OutputFilename
 		// save preprocessed markdown
-		err = preprocessPolicy(data, p, filepath.Join(".", "output", outputFilename+".md"))
+		err := preprocessDoc(data, p, filepath.Join(".", "output", outputFilename+".md"))
 		if err != nil {
 			errOutputCh <- errors.Wrap(err, "unable to preprocess")
 			return
 		}

-		resp, err := cli.ContainerCreate(ctx, &container.Config{
-			Image: "strongdm/pandoc",
-			Cmd: []string{"--smart", "--toc", "-N", "--template=/source/templates/default.latex", "-o",
-				fmt.Sprintf("/source/output/%s", outputFilename),
-				fmt.Sprintf("/source/output/%s.md", outputFilename),
-			},
-		}, hc, nil, "")
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to create Docker container")
-			return
-		}
-
-		defer func() {
-			timeout := 2 * time.Second
-			cli.ContainerStop(ctx, resp.ID, &timeout)
-			err := cli.ContainerRemove(ctx, resp.ID, types.ContainerRemoveOptions{Force: true})
-			if err != nil {
-				errOutputCh <- errors.Wrap(err, "unable to remove container")
-				return
-			}
-		}()
-
-		if err := cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{}); err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to start Docker container")
-			return
-		}
-
-		_, err = cli.ContainerWait(ctx, resp.ID)
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error awaiting Docker container")
-			return
-		}
-
-		_, err = cli.ContainerLogs(ctx, resp.ID, types.ContainerLogsOptions{ShowStdout: true})
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error reading Docker container logs")
-			return
-		}
+		pandoc(outputFilename, errOutputCh)

 		// remove preprocessed markdown
 		err = os.Remove(filepath.Join(".", "output", outputFilename+".md"))
@@ -110,10 +46,50 @@ func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *render
 			errOutputCh <- err
 			return
 		}
-	}(policy)
+
+		rel, err := filepath.Rel(config.ProjectRoot(), p.FullPath)
+		if err != nil {
+			rel = p.FullPath
+		}
+		fmt.Printf("%s -> %s\n", rel, filepath.Join("output", p.OutputFilename))
+	}(doc)
 }

-func preprocessPolicy(data *renderData, pol *model.Policy, fullPath string) error {
+func getGitApprovalInfo(pol *model.Document) (string, error) {
+	cfg := config.Config()
+
+	// if no approved branch specified in config.yaml, then nothing gets added to the document
+	if cfg.ApprovedBranch == "" {
+		return "", nil
+	}
+
+	// Decide whether we are on the git branch that contains the approved policies
+	gitBranchArgs := []string{"rev-parse", "--abbrev-ref", "HEAD"}
+	gitBranchCmd := exec.Command("git", gitBranchArgs...)
+	gitBranchInfo, err := gitBranchCmd.CombinedOutput()
+	if err != nil {
+		fmt.Println(string(gitBranchInfo))
+		return "", errors.Wrap(err, "error looking up git branch")
+	}
+
+	// if on a different branch than the approved branch, then nothing gets added to the document
+	if strings.Compare(strings.TrimSpace(fmt.Sprintf("%s", gitBranchInfo)), cfg.ApprovedBranch) != 0 {
+		return "", nil
+	}
+
+	// Grab information related to commit, so that we can put approval information in the document
+	gitArgs := []string{"log", "-n", "1", "--pretty=format:Last edit made by %an (%aE) on %aD.\n\nApproved by %cn (%cE) on %cD in commit %H.", "--", pol.FullPath}
+	cmd := exec.Command("git", gitArgs...)
+	gitApprovalInfo, err := cmd.CombinedOutput()
+	if err != nil {
+		fmt.Println(string(gitApprovalInfo))
+		return "", errors.Wrap(err, "error looking up git committer and author data")
+	}
+
+	return fmt.Sprintf("%s\n%s", "# Authorship and Approval", gitApprovalInfo), nil
+}
+
+func preprocessDoc(data *renderData, pol *model.Document, fullPath string) error {
 	cfg := config.Config()

 	var w bytes.Buffer
@@ -149,6 +125,11 @@ func preprocessPolicy(data *renderData, pol *model.Policy, fullPath string) erro
 		revisionTable = fmt.Sprintf("|Date|Comment|\n|---+--------------------------------------------|\n%s\nTable: Document history\n", rows)
 	}

+	gitApprovalInfo, err := getGitApprovalInfo(pol)
+	if err != nil {
+		return err
+	}
+
 	doc := fmt.Sprintf(`%% %s
 %% %s
 %% %s
@@ -164,6 +145,8 @@ foot-content: "%s confidential %d"
 %s

 \newpage
+%s
+
 %s`,
 		pol.Name,
 		cfg.Name,
@@ -174,6 +157,7 @@ foot-content: "%s confidential %d"
 		satisfiesTable,
 		revisionTable,
 		body,
+		gitApprovalInfo,
 	)
 	err = ioutil.WriteFile(fullPath, []byte(doc), os.FileMode(0644))
 	if err != nil {
--- a/internal/render/html.go
+++ b/internal/render/html.go
@@ -9,12 +9,16 @@ import (
 	"sync"

 	"github.com/pkg/errors"
+	"github.com/skratchdot/open-golang/open"
 	"github.com/yosssi/ace"
 )

 const websocketReloader = `<script>
 (function(){
-	var ws = new WebSocket("ws://localhost:5122/ws")
+	var ws = new WebSocket("ws://localhost:%d/ws")
+	if (location.host != "") {
+		ws = new WebSocket("ws://"+location.host+"/ws")
+	}
 	var connected = false
 	ws.onopen = function(e) {
 		connected = true
@@ -29,6 +33,8 @@ const websocketReloader = `<script>
 </script>`

 func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
+	opened := false
+
 	for {
 		files, err := ioutil.ReadDir(filepath.Join(".", "templates"))
 		if err != nil {
@@ -56,9 +62,7 @@ func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 				return
 			}

-			if live {
 			fmt.Printf("%s -> %s\n", filepath.Join("templates", fileInfo.Name()), outputFilename)
-			}

 			tpl, err := ace.Load("", filepath.Join("templates", basename), aceOpts)
 			if err != nil {
@@ -73,14 +77,21 @@ func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 			}

 			if live {
-				w.Write([]byte(websocketReloader))
+				w.Write([]byte(fmt.Sprintf(websocketReloader, ServePort)))
 			}
 			w.Close()
 		}
-		if !live {
+
+		if live {
+			if !opened {
+				opened = true
+				open.Run(fmt.Sprintf("http://127.0.0.1:%d/", ServePort))
+			}
+		} else {
 			wg.Done()
 			return
 		}
+
 		<-subscribe()
 	}
 }
--- a/internal/render/narrative.go
+++ b/internal/render/narrative.go
@@ -1,185 +0,0 @@
-package render
-
-import (
-	"bytes"
-	"context"
-	"fmt"
-	"io/ioutil"
-	"os"
-	"path/filepath"
-	"strings"
-	"sync"
-	"text/template"
-	"time"
-
-	"github.com/docker/docker/api/types"
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
-	"github.com/pkg/errors"
-	"github.com/strongdm/comply/internal/config"
-	"github.com/strongdm/comply/internal/model"
-)
-
-// TODO: refactor and eliminate duplication among narrative, policy renderers
-func renderNarrativeToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *renderData, narrative *model.Narrative, live bool) {
-	// only files that have been touched
-	if !isNewer(narrative.FullPath, narrative.ModifiedAt) {
-		return
-	}
-	recordModified(narrative.FullPath, narrative.ModifiedAt)
-
-	ctx := context.Background()
-	cli, err := client.NewEnvClient()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to read Docker environment")
-		return
-	}
-
-	pwd, err := os.Getwd()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to get workding directory")
-		return
-	}
-
-	hc := &container.HostConfig{
-		Binds: []string{pwd + ":/source"},
-	}
-
-	wg.Add(1)
-	go func(p *model.Narrative) {
-		defer wg.Done()
-
-		if live {
-			rel, err := filepath.Rel(config.ProjectRoot(), p.FullPath)
-			if err != nil {
-				rel = p.FullPath
-			}
-			fmt.Printf("%s -> %s\n", rel, filepath.Join("output", p.OutputFilename))
-		}
-
-		outputFilename := p.OutputFilename
-		// save preprocessed markdown
-		err = preprocessNarrative(data, p, filepath.Join(".", "output", outputFilename+".md"))
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to preprocess")
-			return
-		}
-
-		cmd := []string{"--smart", "--toc", "-N", "--template=/source/templates/default.latex", "-o",
-			fmt.Sprintf("/source/output/%s", outputFilename),
-			fmt.Sprintf("/source/output/%s.md", outputFilename)}
-
-		resp, err := cli.ContainerCreate(ctx, &container.Config{
-			Image: "strongdm/pandoc",
-			Cmd:   cmd},
-			hc, nil, "")
-
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to create Docker container")
-			return
-		}
-
-		defer func() {
-			timeout := 2 * time.Second
-			cli.ContainerStop(ctx, resp.ID, &timeout)
-			err := cli.ContainerRemove(ctx, resp.ID, types.ContainerRemoveOptions{Force: true})
-			if err != nil {
-				errOutputCh <- errors.Wrap(err, "unable to remove container")
-				return
-			}
-		}()
-
-		if err := cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{}); err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to start Docker container")
-			return
-		}
-
-		_, err = cli.ContainerWait(ctx, resp.ID)
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error awaiting Docker container")
-			return
-		}
-
-		_, err = cli.ContainerLogs(ctx, resp.ID, types.ContainerLogsOptions{ShowStdout: true})
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error reading Docker container logs")
-			return
-		}
-
-		// remove preprocessed markdown
-		err = os.Remove(filepath.Join(".", "output", outputFilename+".md"))
-		if err != nil {
-			errOutputCh <- err
-			return
-		}
-	}(narrative)
-}
-
-func preprocessNarrative(data *renderData, pol *model.Narrative, fullPath string) error {
-	cfg := config.Config()
-
-	var w bytes.Buffer
-	bodyTemplate, err := template.New("body").Parse(pol.Body)
-	if err != nil {
-		w.WriteString(fmt.Sprintf("# Error processing template:\n\n%s\n", err.Error()))
-	} else {
-		bodyTemplate.Execute(&w, data)
-	}
-	body := w.String()
-
-	revisionTable := ""
-	satisfiesTable := ""
-
-	// ||Date|Comment|
-	// |---+------|
-	// | 4 Jan 2018 | Initial Version |
-	// Table: Document history
-
-	if len(pol.Satisfies) > 0 {
-		rows := ""
-		for standard, keys := range pol.Satisfies {
-			rows += fmt.Sprintf("| %s | %s |\n", standard, strings.Join(keys, ", "))
-		}
-		satisfiesTable = fmt.Sprintf("|Standard|Controls Satisfied|\n|-------+--------------------------------------------|\n%s\nTable: Control satisfaction\n", rows)
-	}
-
-	if len(pol.Revisions) > 0 {
-		rows := ""
-		for _, rev := range pol.Revisions {
-			rows += fmt.Sprintf("| %s | %s |\n", rev.Date, rev.Comment)
-		}
-		revisionTable = fmt.Sprintf("|Date|Comment|\n|---+--------------------------------------------|\n%s\nTable: Document history\n", rows)
-	}
-
-	doc := fmt.Sprintf(`%% %s
-%% %s
-%% %s
-
---
-header-includes: yes
-head-content: "%s"
-foot-content: "%s confidential %d"
---
-
-%s
-
-%s
-
-\newpage
-%s`,
-		pol.Name,
-		cfg.Name,
-		fmt.Sprintf("%s %d", pol.ModifiedAt.Month().String(), pol.ModifiedAt.Year()),
-		pol.Name,
-		cfg.Name,
-		time.Now().Year(),
-		satisfiesTable,
-		revisionTable,
-		body,
-	)
-	err = ioutil.WriteFile(fullPath, []byte(doc), os.FileMode(0644))
-	if err != nil {
-		return errors.Wrap(err, "unable to write preprocessed narrative to disk")
-	}
-	return nil
-}
--- a/internal/render/pandoc.go
+++ b/internal/render/pandoc.go
@@ -0,0 +1,101 @@
+package render
+
+import (
+	"context"
+	"fmt"
+	"os"
+	"os/exec"
+	"time"
+
+	"github.com/docker/docker/api/types"
+	"github.com/docker/docker/api/types/container"
+	"github.com/docker/docker/client"
+	"github.com/pkg/errors"
+	"github.com/strongdm/comply/internal/config"
+)
+
+var pandocArgs = []string{"-f", "markdown+smart", "--toc", "-N", "--template", "templates/default.latex", "-o"}
+
+func pandoc(outputFilename string, errOutputCh chan error) {
+	if config.WhichPandoc() == config.UsePandoc {
+		err := pandocPandoc(outputFilename)
+		if err != nil {
+			errOutputCh <- err
+		}
+	} else {
+		dockerPandoc(outputFilename, errOutputCh)
+	}
+}
+
+func dockerPandoc(outputFilename string, errOutputCh chan error) {
+	pandocCmd := append(pandocArgs, fmt.Sprintf("/source/output/%s", outputFilename), fmt.Sprintf("/source/output/%s.md", outputFilename))
+	ctx := context.Background()
+	cli, err := client.NewEnvClient()
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to read Docker environment")
+		return
+	}
+
+	pwd, err := os.Getwd()
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to get workding directory")
+		return
+	}
+
+	hc := &container.HostConfig{
+		Binds: []string{pwd + ":/source"},
+	}
+
+	resp, err := cli.ContainerCreate(ctx, &container.Config{
+		Image: "strongdm/pandoc",
+		Cmd:   pandocCmd},
+		hc, nil, "")
+
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to create Docker container")
+		return
+	}
+
+	defer func() {
+		timeout := 2 * time.Second
+		cli.ContainerStop(ctx, resp.ID, &timeout)
+		err := cli.ContainerRemove(ctx, resp.ID, types.ContainerRemoveOptions{Force: true})
+		if err != nil {
+			errOutputCh <- errors.Wrap(err, "unable to remove container")
+			return
+		}
+	}()
+
+	if err := cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{}); err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to start Docker container")
+		return
+	}
+
+	_, err = cli.ContainerWait(ctx, resp.ID)
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "error awaiting Docker container")
+		return
+	}
+
+	_, err = cli.ContainerLogs(ctx, resp.ID, types.ContainerLogsOptions{ShowStdout: true})
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "error reading Docker container logs")
+		return
+	}
+
+	if _, err = os.Stat(fmt.Sprintf("output/%s", outputFilename)); err != nil && os.IsNotExist(err) {
+		errOutputCh <- errors.Wrap(err, "output not generated; verify your Docker image is up to date")
+		return
+	}
+}
+
+// 🐼
+func pandocPandoc(outputFilename string) error {
+	cmd := exec.Command("pandoc", append(pandocArgs, fmt.Sprintf("output/%s", outputFilename), fmt.Sprintf("output/%s.md", outputFilename))...)
+	outputRaw, err := cmd.CombinedOutput()
+	if err != nil {
+		fmt.Println(string(outputRaw))
+		return errors.Wrap(err, "error calling pandoc")
+	}
+	return nil
+}
--- a/internal/render/pdf.go
+++ b/internal/render/pdf.go
@@ -25,7 +25,7 @@ func pdf(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 			return
 		}
 		for _, policy := range policies {
-			renderPolicyToDisk(&pdfWG, errOutputCh, data, policy, live)
+			renderToFilesystem(&pdfWG, errOutputCh, data, policy, live)
 		}

 		narratives, err := model.ReadNarratives()
@@ -35,7 +35,7 @@ func pdf(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 		}

 		for _, narrative := range narratives {
-			renderNarrativeToDisk(&pdfWG, errOutputCh, data, narrative, live)
+			renderToFilesystem(&pdfWG, errOutputCh, data, narrative, live)
 		}

 		pdfWG.Wait()
--- a/internal/render/site.go
+++ b/internal/render/site.go
@@ -1,17 +1,20 @@
 package render

 import (
+	"fmt"
 	"net/http"
 	"os"
+	"path/filepath"
 	"sync"
 	"time"

 	"github.com/gorilla/websocket"
 	"github.com/pkg/errors"
-	"github.com/skratchdot/open-golang/open"
 	"github.com/yosssi/ace"
 )

+var ServePort int
+
 var upgrader = websocket.Upgrader{
 	ReadBufferSize:  1024,
 	WriteBufferSize: 1024,
@@ -88,6 +91,16 @@ func Build(output string, live bool) error {

 	if live {
 		watch(errCh)
+
+		go func() {
+			http.Handle("/", http.FileServer(http.Dir(filepath.Join(".", "output"))))
+			err := http.ListenAndServe(fmt.Sprintf("0.0.0.0:%d", ServePort), nil)
+			if err != nil {
+				panic(err)
+			}
+		}()
+
+		fmt.Printf("Serving content of output/ at http://127.0.0.1:%d (ctrl-c to quit)\n", ServePort)
 	}
 	// PDF
 	wg.Add(1)
@@ -103,10 +116,6 @@ func Build(output string, live bool) error {
 		close(wgCh)
 	}()

-	if live {
-		open.Run("output/index.html")
-	}
-
 	select {
 	case <-wgCh:
 		// success
--- a/internal/render/watch.go
+++ b/internal/render/watch.go
@@ -45,7 +45,6 @@ func watch(errCh chan error) {
 	}

 	http.HandleFunc("/ws", serveWs)
-	go http.ListenAndServe("127.0.0.1:5122", nil)

 	return
 }
--- a/internal/theme/themes_bindata.go
+++ b/internal/theme/themes_bindata.go
--- a/internal/ticket/scheduler.go
+++ b/internal/ticket/scheduler.go
@@ -5,7 +5,9 @@ import (
 	"sort"
 	"time"

+	"github.com/pkg/errors"
 	"github.com/robfig/cron"
+	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 )

@@ -68,7 +70,10 @@ func TriggerScheduled() error {
 				// in the future, nothing to do
 				continue
 			}
-			trigger(procedure)
+			err = trigger(procedure)
+			if err != nil {
+				return err
+			}
 		} else {
 			// don't go back further than 13 months
 			tooOld := time.Now().Add(-1 * time.Hour * 24 * (365 + 30))
@@ -88,7 +93,10 @@ func TriggerScheduled() error {
 				}

 				// is in the past? then trigger.
-				trigger(procedure)
+				err = trigger(procedure)
+				if err != nil {
+					return err
+				}
 				break SEARCH
 			}
 		}
@@ -97,13 +105,18 @@ func TriggerScheduled() error {
 	return nil
 }

-func trigger(procedure *model.Procedure) {
+func trigger(procedure *model.Procedure) error {
 	fmt.Printf("triggering procedure %s (cron expression: %s)\n", procedure.Name, procedure.Cron)

-	// TODO: don't hardcode GH
-	tp := model.GetPlugin(model.GitHub)
-	tp.Create(&model.Ticket{
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return errors.Wrap(err, "error in ticket system configuration")
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
+	err = tp.Create(&model.Ticket{
 		Name: procedure.Name,
 		Body: fmt.Sprintf("%s\n\n\n---\nProcedure-ID: %s", procedure.Body, procedure.ID),
 	}, []string{"comply", "comply-procedure"})
+	return err
 }
--- a/logo.png
+++ b/logo.png
--- a/themes/comply-blank/templates/index.ace
+++ b/themes/comply-blank/templates/index.ace
@@ -15,20 +15,11 @@ html lang=en
        document.querySelectorAll('.cron').forEach(function(el) {
          el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
        })
-        if (window.location.hash != "") {
-          var hashComponents = window.location.hash.split('#')
-          if (hashComponents.length>1) {
-            var destination = hashComponents[1]
-            if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
-              show(destination)
-            }
-          }
-        }
      })

      function show(name) {
        if (history.replaceState) {
-            history.replaceState(null, null, '#'+name);
+            history.replaceState(null, null, '#'+name)
        }

        var items = document.getElementsByClassName('top-nav')
@@ -233,7 +224,14 @@ html lang=en
        .content.has-text-centered
          p {{.Project.OrganizationName}} Confidential 2018
  = javascript
-    // commented for development
    if (window.location.hash=="") {
      show('overview')
+    } else {
+      var hashComponents = window.location.hash.split('#')
+      if (hashComponents.length>1) {
+        var destination = hashComponents[1]
+        if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
+          show(destination)
+        }
+      }
    }
--- a/themes/comply-soc2/narratives/control.md
+++ b/themes/comply-soc2/narratives/control.md
@@ -17,6 +17,78 @@ majorRevisions:

 # Control Environment Narrative

-Here we narrate why our control environment satisfies the control keys listed in the YML block
+The following provides a description of the control structure of {{.Name}}.

-# Template Coming Soon
+The intent of this description is to enumerate the logical, policy, and procedural controls that serve to monitor {{.Name}}'s application and data security. Changes uncovered by these procedures in the logical, policy, procedural, or customer environment are addressed by remediations specific to the noted change.
+
+# Logical Controls
+
+{{.Name}} employs several logical controls to protect confidential data and ensure normal operation of its core product.
+
+- Mandatory data encryption at rest and in motion
+- Multi-factor authentication for access to cloud infrastructure
+- Activity and anomaly monitoring on production systems
+- Vulnerability management program
+
+# Policy Controls
+
+{{.Name}} employs several policy controls to protect confidential data and ensure normal operation of its core product. These policies include, but are not limited to:
+
+- Access Control Policy
+- Encryption Policy
+- Office Security Policy
+- Password Policy
+- Policy Training Policy
+- Vendor Policy
+- Workstation Policy
+
+# Procedural Controls
+
+{{.Name}} has numerous scheduled procedures to monitor and tune the effectiveness of ongoing security controls, and a series of event-driven procedures to respond to security-related events.
+
+TODO: Finalize these lists
+
+## Scheduled Security and Audit Procedures
+
+- Review Access [quarterly]
+- Review Security Logs [weekly]
+- Review Cyber Risk Assessment (enumerate possible compromise scenarios) [quarterly]
+- Review Data Classification [quarterly]
+- Backup Testing [quarterly]
+- Disaster Recovery Testing [semi-annual]
+- Review Devices & Workstations [quarterly]
+- Review & Clear Low-Priority Alerts [weekly]
+- Apply OS Patches [monthly]
+- Verify Data Disposal per Retention Policy [quarterly]
+- Conduct Security Training [annual]
+- Review Security Monitoring and Alerting Configuration [quarterly]
+- Penetration Test [annual]
+- Whitebox Security Review [annual]
+- SOC2 Audit [annual]
+
+## Event-Driven Security and Audit Procedures
+
+- Onboard Employee
+- Offboard Employee
+- Investigate Security Alert
+- Investigate Security Incident
+
+# Remediations
+
+{{.Name}} uses the outcomes of the aforementioned controls and procedures to identify shortcomings in the existing control environment. Once identified, these shortcomes are remediated by improving existing controls and procedures, and creating new controls and procedures as needed.
+
+# Communications
+
+{{.Name}} communicates relevant information regarding the functioning of the above controls with internal and external parties on an as-needed basis and according to statutory requirements.
+
+## Internal
+
+{{.Name}} communicates control outcomes, anomalies, and remediations internally using the following channels:
+
+- Slack
+- Email
+- Github ticketing
+
+## External
+
+{{.Name}} communicates relevant control-related information to external parties including shareholders, customers, contractors, regulators, and government entities as needed according to contractual and regulatory/statutory obligation.
--- a/themes/comply-soc2/narratives/products.md
+++ b/themes/comply-soc2/narratives/products.md
@@ -9,4 +9,39 @@ majorRevisions:

 Here we describe the key products marketed by our organization

-# Template Coming Soon
+# Products
+
+## Product 1
+
+Overview of product 1
+
+### Architecture
+
+Brief architectural discussion of product 1
+
+### Security Considerations
+
+Specific security considerations for product 1. Refer to policies, procedures here.
+
+# References
+
+## Narratives
+
+List relevant narratives, probably including
+Organizational Narrative
+Security Narrative
+System Narrative
+
+## Policies
+
+List relevant policies, probably including
+Application Security Policy
+Datacenter Policy
+Log Management Policy
+Password Policy
+Security Incident Response Policy
+Risk Assessment Policy
+
+## Procedures
+
+List relevant procedures, probably including access review, patching, alert monitoring, log review, pen testing
--- a/themes/comply-soc2/narratives/security.md
+++ b/themes/comply-soc2/narratives/security.md
@@ -15,4 +15,99 @@ majorRevisions:

 Here we narrate why our org satisfies the control keys listed in the YML block

-# Template Coming Soon
+# {{.Name}} Product Architecture
+
+Describe product architecture here, emphasizing security implications
+
+# {{.Name}} Infrastructure
+
+## Product Infrastructure
+
+Describe product infrastructure, emphasizing security measures
+
+### Authorized Personnel
+
+- **AWS root account** access is granted only to the CTO and CEO
+- **AWS IAM** access is granted to to a limited group of **Operators**
+- **{{.Name}} SSH** access is granted to a limited group of **Operators**
+- **{{.Name}} DB** access is granted to a limited group of **Data Operators**
+
+## IT Infrastructure
+
+{{.Name}} uses the following cloud services for its internal infrastructure:
+
+- List cloud services
+
+Access to these cloud services is limited according to the role of the {{.Name}} employee and is reviewed quarterly as well as via regular onboarding/offboarding tasks for new and departing employees.
+
+# {{.Name}} Workstations
+
+{{.Name}} workstations are hardened against logical and physical attack by the following measures:
+
+- operating system must be within one generation of current
+- full-disk encryption
+- onboard antivirus/antimalware software
+- OS and AV automatically updated
+
+Workstation compliance with these measures is evaluated on a quarterly basis.
+
+## Remote Access
+
+Many {{.Name}} employees work remotely on a regular basis and connect to production and internal IT systems via the same methods as those employees connecting from the {{.Name}} physical office, i.e., direct encrypted access to cloud services. It is the employee's responsibility to ensure that only authorized personnel use {{.Name}} resources and access {{.Name}} systems.
+
+# Access Review
+
+Access to {{.Name}} infrastructure, both internal and product, is reviewed quarterly and inactive users are removed. Any anomalies are reported to the security team for further investigation. When employees start or depart, an onboarding/offboarding procedure is followed to provision or deprovision appropriate account access.
+
+# Penetration Testing
+
+{{.Name}} commissions an external penetration test on an annual basis. All findings are immediately reviewed and addressed to the satisfaction of the CTO/CEO.
+
+# {{.Name}} Physical Security
+
+{{.Name}} has one physical location, in San Francisco, CA. Key issuance is tracked by the Office Physical Security Policy Ledger. Office keys are additionally held by the lessor, property management, and custodial staff. These keys are not tracked by the Office Physical Security Policy Ledger. {{.Name}} managers regularly review physical access privileges.
+
+{{.Name}} infrastructure is located within AWS. {{.Name}} does not have physical access to AWS infrastructure.
+
+# Risk Assessment
+
+{{.Name}} updates its Cyber Risk Assessment on an annual basis in order to keep pace with the evolving threat landscape. The following is an inventory of adversarial and non-adversarial threats assessed to be of importance to {{.Name}}.
+
+## Adversarial Threats
+
+The following represents the inventory of adversarial threats:
+
+|Threat|Source|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+------------+-----------------+----------+------|
+| | | | | | |
+
+## Non-Adversarial Threats
+
+The following represents the inventory of non-adversarial threats:
+
+|Threat|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+-------------+----------+------|
+| | | | | |
+
+# References
+
+## Narratives
+
+Products and Services Narrative
+System Architecture Narrative
+
+## Policies
+
+Encryption Policy
+Log Management Policy
+Office Security Policy
+Remote Access Policy
+Security Incident Response Policy
+Workstation Policy
+
+## Procedures
+
+Apply OS Patches
+Review & Clear Low-Priority Alerts
+Review Access
+Review Devices & Workstations
--- a/themes/comply-soc2/policies/access.md
+++ b/themes/comply-soc2/policies/access.md
@@ -9,5 +9,49 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Purpose and Scope
+
+a. The purpose of this policy is to define procedures to onboard and offboard users to technical infrastructure in a manner that minimizes the risk of information loss or exposure. 
+
+a. This policy applies to all technical infrastructure within the organization. 
+
+a. This policy applies to all full-time and part-time employees and contractors. 
+
+# Background
+
+a. In order to minimize the risk of information loss or exposure (from both inside and outside the organization), the organization is reliant on the principle of least privilege. Account creation and permission levels are restricted to only the resources absolutely needed to perform each person’s job duties. When a user’s role within the organization changes, those accounts and permission levels are changed/revoked to fit the new role and disabled when the user leaves the organization altogether. 
+
+# Policy
+
+a. *During onboarding:*
+
+    i. Hiring Manager informs HR upon hire of a new employee.
+
+    i. HR emails IT to inform them of a new hire and their role. 
+
+    i. IT creates a checklist of accounts and permission levels needed for that role. 
+
+    i. The owner of each resource reviews and approves account creation and the 
+associated permissions. 
+
+    i. IT works with the owner of each resource to set up the user. 
+
+a. *During offboarding:*
+
+    i. Hiring Manager notifies HR when an employee has been terminated. 
+
+    i. HR sends a weekly email report to IT summarizing list of users terminated and instructs IT to disable their access. 
+
+    i. IT terminates access within five business days from receipt of notification. 
+
+a. *When an employee changes roles within the organization:*
+
+    i. Hiring Manager will inform HR of a change in role.
+    
+    i. HR and IT will follow the same steps as outlined in the onboarding and offboarding procedures. 
+
+a. *Review of accounts and permissions:*
+
+    i. Each month, IT and HR will review accounts and permission levels for accuracy. 
+

-# Coming Soon
--- a/themes/comply-soc2/policies/application.md
+++ b/themes/comply-soc2/policies/application.md
@@ -8,4 +8,111 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This application security policy defines the security framework and requirements for applications, notably web applications, within the organization’s production environment.
+
+a. This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
+
+a. This policy applies to all applications within the organization’ production environment, as well as administrators and users of these applications. This typically includes employees and contractors.
+
+# Background
+
+a. Application vulnerabilities typically account for the largest number of initial attack vectors after malware infections. As a result, it is important that applications are designed with security in mind, and that they are scanned and continuously monitored for malicious activity that could indicate a system compromise. Discovery and subsequent mitigation of application vulnerabilities will limit the organization’s attack surface, and ensures a baseline level of security across all systems.
+
+a. In addition to scanning guidance, this policy also defines technical requirements and procedures  to ensure that applications are properly hardened in accordance with security best practices.
+
+# References
+
+a. Data Classification Policy
+
+a. OWASP Risk Rating Methodology
+
+a. OWASP Testing Guide
+
+a. OWASP Top Ten Project
+
+# Policy
+
+a. The organization must ensure that all applications it develops and/or acquires are securely configured and managed.
+
+a. The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
+
+    i. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (a)).
+
+    i. If the application processes confidential information, a confidential record banner must be prominently displayed which highlights the type of confidential data being accessed (e.g., personally-identifiable information (PII), protected health information (PHI), etc.)
+
+    i. Sensitive data, especially data specifically restricted by law or policy (e.g., social security numbers, passwords, and credit card data) should not be displayed in plaintext.
+
+    i. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct. Examples include, but are not limited to cross-site scripting, buffer overflow errors, and injection flaws.
+
+    i. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, impair security mechanisms, or crash the system.
+
+    i. Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual. Provide an automated review of authorizations on a regular basis, where possible.
+
+    i. Ensure that applications encrypt data at rest and in transit.
+
+    i. Implement application logging to the extent practical. Retain logs of all users and access events for at least 14 days.
+
+    i. Qualified peers conduct security reviews of code  for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data. Document all actions taken.
+
+    i. Implement a change management process for changes to existing software applications.
+
+    i. Standard configuration of the application must be documented. 
+
+    i. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
+
+    i. Applications must require complex passwords in accordance with current security best practices (at least 8 characters in length, combination of alphanumeric upper/lowercase characters and symbols).
+
+    i. During development and testing, applications must not have access to live data.
+
+a. Where applications are acquired from a third party, such as a vendor:
+
+    i. Only applications that are supported by an approved vendor shall be procured and used.
+
+    i. Full support contracts must be arranged with the application vendor for full life-cycle support.
+
+    i. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
+
+    i. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible.
+
+    i. A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
+
+a. Web applications must be assessed according to the following criteria:
+
+    i. New or major application releases must have a full assessment prior to approval of the change control documentation and/or release into the production environment.
+
+    i. Third-party or acquired applications must have a full assessment prior to deployment.
+
+    i. Software releases must have an appropriate assessment, as determined by the organization’s information security manager, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
+
+    i. Emergency releases may forego security assessments and carry the assumed risk until a proper assessment can be conducted. Emergency releases must be approved by the Chief Information Officer or designee.
+
+a. Vulnerabilities that are discovered during application assessments must be mitigated based upon the following risk levels, which are based on the Open Web Application Security Project (OWASP) Risk Rating Methodology (reference (b)):
+
+    i. High - issues categorized as high risk must be fixed immediately, otherwise alternate mitigation strategies must be implemented to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
+
+    i. Medium - issues categorized as medium risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled. Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues; multiple issues may increase the risk to an unacceptable level. Issues may be fixed in patch releases unless better mitigation options are present.
+
+    i. Low - issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
+
+a. Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
+
+a. The following security assessment types may be leveraged to perform an application security assessment:
+
+    i. Full - comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference (c)). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
+
+    i. Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (d)).
+
+    i. Targeted - verifies vulnerability remediation changes or new application functionality.
+
+    i. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference (c)).
+
+    i. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (d)).
+
+    i. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (e)).
+
+    i. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (f)).
+
+    i. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (g)).
+
--- a/themes/comply-soc2/policies/availability.md
+++ b/themes/comply-soc2/policies/availability.md
@@ -9,4 +9,92 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for proper controls to protect the availability of the organization’s information systems.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the amount of unexpected or unplanned downtime (also known as outages) of information systems under the organization’s control. This policy prescribes specific measures for the organization that will increase system redundancy, introduce failover mechanisms, and implement monitoring such that outages are prevented as much as possible. Where they cannot be prevented, outages will be quickly detected and remediated.
+
+a. Within this policy, an availability is defined as a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. Information systems must be consistently available to conduct and support business operations.
+
+a. Information systems must have a defined availability classification, with appropriate controls enabled and incorporated into development and production processes based on this classification.
+
+a. System and network failures must be reported promptly to the organization’s lead for Information Technology (IT) or designated IT operations manager.
+
+a. Users must be notified of scheduled outages (e.g., system maintenance) that require periods of downtime. This notification must specify the date and time of the system maintenance, expected duration, and anticipated system or service resumption time.
+
+a. Prior to production use, each new or significantly modified application must have a completed risk assessment that includes availability risks. Risk assessments must be completed in accordance with the Risk Assessment Policy (reference (a)).
+
+a. Capacity management and load balancing techniques must be used, as deemed necessary, to help minimize the risk and impact of system failures.
+
+a. Information systems  must have an appropriate data backup plan that ensures:
+
+    i. All sensitive data can be restored within a reasonable time period.
+
+    i. Full backups of critical resources are performed on at least a weekly basis.
+
+    i. Incremental backups for critical resources are performed on at least a daily basis.
+
+    i. Backups and associated media are maintained for a minimum of thirty (30) days and retained for at least one (1) year, or in accordance with legal and regulatory requirements.
+
+    i. Backups are stored off-site with multiple points of redundancy and protected using encryption and key management.
+
+    i. Tests of backup data must be conducted once per quarter. Tests of configurations must be conducted twice per year.
+
+a. Information systems  must have an appropriate redundancy and failover plan that meets the following criteria:
+
+    i. Network infrastructure that supports critical resources must have system-level redundancy (including but not limited to a secondary power supply, backup disk-array, and secondary computing system). Critical core components (including but not limited to routers, switches, and other devices linked to Service Level Agreements (SLAs)) must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers that support critical resources must have redundant power supplies and network interface cards. All servers must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers classified as high availability must use disk mirroring.
+
+a. Information systems must have an appropriate business continuity plan that meets the following criteria:
+
+    i. Recovery time and data loss limits are defined in Table 3. 
+
+    i. Recovery time requirements and data loss limits must be adhered to with specific documentation in the plan.
+
+    i. Company and/or external critical resources, personnel, and necessary corrective actions must be specifically identified.
+
+    i. Specific responsibilities and tasks for responding to emergencies and resuming business operations must be included in the plan.
+
+    i. All applicable legal and regulatory requirements must be satisfied.
+
+-------------------+------------------+---------------+-------------------+------------------+
+|**Availability**   | **Availability** | **Scheduled** | **Recovery Time** | **Data Loss or** |
+|**Classification** | **Requirements** | **Outage**    | **Requirements**  | **Impact Loss**  |
+===================+==================+===============+===================+==================+
+| High              | High to          | 30 minutes    | 1 hour            | Minimal          |
+|                   | Continuous       |               |                   |                  |
+-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
+-------------------+------------------+---------------+-------------------+------------------+
+| Medium            | Standard         | 2 hours       | 4 hours           | Some data loss   |
+|                   | Availability     |               |                   | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
+-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
+-------------------+------------------+---------------+-------------------+------------------+
+| Low               | Limited          | 4 hours       | Next              | Some data loss   |
+|                   | Availability     |               | business day      | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
+-------------------+------------------+---------------+-------------------+------------------+
+
+Table 3: Recovery Time and Data Loss Limits 
--- a/themes/comply-soc2/policies/classification.md
+++ b/themes/comply-soc2/policies/classification.md
@@ -7,5 +7,279 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Appendices 
+
+Appendix A: Handling of Classified Information
+
+Appendix B: Form - Confidentiality Statement
+
+# Purpose and Scope
+
+a. This data classification policy defines the requirements to ensure that information within the organization is protected at an appropriate level.
+
+a. This document applies to the entire scope of the organization’s information security program. It includes all types of information, regardless of its form, such as paper or electronic documents, applications and databases, and knowledge or information that is not written.
+
+a. This policy applies to all individuals and systems that have access to information kept by the organization.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s data classification scheme. This includes data classification levels, as well as procedures for the classification, labeling and handling of data within the organization. Confidentiality and non-disclosure agreements maintained by the organization must reference this policy.
+
+# References
+
+a. Risk Assessment Policy
+
+a. Security Incident Management Policy
+
+# Policy
+
+a. If classified information is received from outside the organization, the person who receives the information must classify it in accordance with the rules prescribed in this policy. The person thereby will become the owner of the information.
+
+a. If classified information is received from outside the organization and handled as part of business operations activities (e.g., customer data on provided cloud services), the information classification, as well as the owner of such information, must be made in accordance with the specifications of the respective customer service agreement and other legal requirements.
+
+a. When classifying information, the level of confidentiality is determined by:
+
+    i. The value of the information, based on impacts identified during the risk assessment process. More information on risk assessments is defined in the Risk Assessment Policy (reference (a)).
+
+    i. Sensitivity and criticality of the information, based on the highest risk calculated for each information item during the risk assessment.
+
+    i. Legal, regulatory and contractual obligations. 
+
+
+-------------------+------------------+---------------------------+---------------------------+
+|**Confidentiality**| **Label**        |  **Classification**       |  **Access**               |
+|     **Level**     |                  |   **Criteria**            | **Restrictions**          |
+===================+==================+===========================+============================+
+| Public            | For Public       | Making the information    | Information is available  |   
+|                   | Release          | public will not harm      | to the public.            |
+|                   |                  | the organization in       |                           |        
+|                   |                  | any way.                  |                           |
+-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
+-------------------+------------------+---------------------------+---------------------------+
+| Internal Use      | Internal Use     | Unauthorized access       | Information is available  |
+|                   |                  | may cause minor damage    | to all employees and      |   
+|                   |                  | and/or inconvenience      | authorized third parties. |        
+|                   |                  | to the organization.      | 
+-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
+-------------------+------------------+---------------------------+---------------------------+
+| Restricted        | Restricted       | Unauthorized access to    | Information is available  |
+|                   |                  | information may cause     | to a specific group of    |
+|                   |                  | considerable damage to    | employees and authhorized |
+|                   |                  | the business and/or       | third parties.            |
+|                   |                  | the organization's        |                           |
+|                   |                  | reputation.               |                           |           
+-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
+-------------------+------------------+---------------------------+---------------------------+
+| Confidential      |Confidential      | Unauthorized access to    | Information is available  |           
+|                   |                  | information may cause     | only to specific indivi-  |
+|                   |                  | catastrophic damage to    | duals in the              |
+|                   |                  | business and/or the       | organization.             |
+|                   |                  | organization's reputation.|                           |
+-------------------+------------------+---------------------------+---------------------------+
+
+Table 3: Information Confidentiality Levels
+
+&nbsp;
+
+d. Information must be classified based on confidentiality levels as defined in Table 3.
+
+e. Information and information system owners should try to use the lowest confidentiality level that ensures an adequate level of protection, thereby avoiding unnecessary production costs.
+
+f. Information classified as “Restricted” or “Confidential” must be accompanied by a list of authorized persons in which the information owner specifies the names or job functions of persons who have the right to access that information.
+
+g. Information classified as “Internal Use” must be accompanied by a list of authorized persons only if individuals outside the organization will have access to the document.
+
+h. Information and information system owners must review the confidentiality level of their information assets every five years and assess whether the confidentiality level should be changed. Wherever possible, confidentiality levels should be lowered.
+
+a. For cloud-based software services provided to customers, system owners under the company’s control must also review the confidentiality level of their information systems after service agreement changes or after a customer’s formal notification. Where allowed by service agreements, confidentiality levels should be lowered.
+
+a. Information must be labeled according to the following:
+
+    i. Paper documents: the confidentiality level is indicated on the top and bottom of each document page; it is also indicated on the front of the cover or envelope carrying such a document as well as on the filing folder in which the document is stored. If a document is not labeled, its default classification is Internal Use.
+
+    i. Electronic documents: the confidentiality level is indicated on the top and bottom of each document page. If a document is not labeled, its default classification is Internal Use.
+
+    i. Information systems: the confidentiality level in applications and databases must be indicated on the system access screen, as well as on the screen when displaying such information.
+    
+    i. Electronic mail: the confidentiality level is indicated in the first line of the email body. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Electronic storage media (disks, memory cards, etc.): the confidentiality level must be indicated on the top surface of the media. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Information transmitted orally: the confidentiality level should be mentioned before discussing information during face-to-face communication, by telephone, or any other means of oral communication.
+    
+a. All persons accessing classified information must follow the guidelines listed in Appendix A, “Handling of Classified Information.”
+
+a. All persons accessing classified information must complete and submit a Confidentiality Statement to their immediate supervisor or company point-of-contact. A sample Confidentiality Statement is in Appendix B.
+
+a. Incidents related to the improper handling of classified information must be reported in accordance with the Security Incident Management Policy (reference (b)).
+    
+\pagebreak 
+
+# Appendix A: Handling of Classified Information
+
+Information and information systems must be handled according to the following guidelines*:
+
+a. Paper Documents
+    
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+        
+        1. If sent outside the organization, the document must be sent as registered mail.
+
+        1. Documents may only be kept in rooms without public access.
+
+        1. Documents must be removed expeditiously from printers and fax machines.
+
+    i. Restricted
+
+        1. The document must be stored in a locked cabinet.
+
+        1. Documents may be transferred within and outside the organization only in a closed envelope.
+
+        1. If sent outside the organization, the document must be mailed with a return receipt service.
+
+        1. Documents must immediately be removed from printers and fax machines.
+
+        1. Only the document owner may copy the document.
+
+        1. Only the document owner may destroy the document.
+
+    i. Confidential
+      
+        1. The document must be stored in a safe.
+
+        1. The document may be transferred within and outside the organization only by a trustworthy person in a closed and sealed envelope.
+
+        1. Faxing the document is not permitted.
+
+        1. The document may be printed only if the authorized person is standing next to the printer.
+
+a. Electronic Documents
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. When documents are exchanged via unencrypted file sharing services such as FTP, they must be password protected.
+
+        1. Access to the information system where the document is stored must be protected by a strong password.
+
+        1. The screen on which the document is displayed must be automatically locked after 10 minutes of inactivity.
+
+    i. Restricted
+
+        1. Only persons with authorization for this document may access the part of the information system where this document is stored.
+
+        1. When documents are exchanged via file sharing services of any type, they must be encrypted.
+
+        1. Only the document owner may erase the document.
+
+    i. Confidential
+
+        1. The document must be stored in encrypted form.
+
+        1. The document may be stored only on servers which are controlled by the organization.
+
+        1. The document may only be shared via file sharing services that are encrypted such as HTTPS and SSH. Further, the document must be encrypted and protected with a string password when transferred.
+
+a. Information Systems
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Access to the information system must be protected by a strong password.
+
+        1. The screen must be automatically locked after 10 minutes of inactivity.
+
+        1. The information system may be only located in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Users must log out of the information system if they have temporarily or permanently left the workplace.
+
+        1. Data must be erased only with an algorithm that ensures secure deletion.
+
+    i. Confidential
+
+        1. Access to the information system must be controlled through multi-factor authentication (MFA).
+
+        1. The information system may only be installed on servers controlled by the organization.
+
+        1. The information system may only be located in rooms with controlled physical access and identity control of people accessing the room.
+
+a. Electronic Mail
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. The sender must carefully check the recipient.
+
+        1. All rules stated under “information systems” apply.
+
+    i. Restricted
+
+        1. Email must be encrypted if sent outside the organization.
+
+    i. Confidential
+
+        1. Email must be encrypted.
+
+a. Electronic Storage Media
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Media or files must be password protected.
+
+        1. If sent outside the organization, the medium must be sent as registered mail.
+
+        1. The medium may only be kept in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Media and files must be encrypted.
+
+        1. Media must be stored in a locked cabinet.
+
+        1. If sent outside the organization, the medium must be mailed with a return receipt service.
+
+        1. Only the medium owner may erase or destroy the medium.
+
+    i. Confidential
+
+        1. Media must be stored in a safe.
+
+        1. Media may be transferred within and outside the organization only by a trustworthy person and in a closed and sealed envelope.
+
+a. Information Transmitted Orally
+
+    i. Internal Use
+
+        1. Only authorized persons may have access to information.
+
+        1. Unauthorized persons must not be present in the room when the information is communicated.
+
+    i. Restricted
+
+        1. The room must be sound-proof.
+
+        1. The conversation must not be recorded.
+
+    i. Confidential
+
+        1. Conversation conducted through electronic means must be encrypted.
+
+        1. No transcript of the conversation may be kept.
+
+In this document, controls are implemented cumulatively, meaning that controls for any confidentiality level imply the implementation of controls defined for lower confidentiality levels - if stricted controls are prescribed for a higher confidentiality level, then only such controls are implemented.
+
+
+

-# Coming Soon
--- a/themes/comply-soc2/policies/cyber.md
+++ b/themes/comply-soc2/policies/cyber.md
@@ -8,4 +8,61 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the procedures to assess and treat information security risks within the organization, and to define the acceptable level of risk overall.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all information systems which are used within the organization or which could have an impact on the organization’s information security.
+
+a. This policy applies to all management and employees that take part in the organization’s risk assessments. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines a step-by-step process for conducting risk assessments, as well as to treat identified risks from an information security perspective. This policy also describes how to prepare the Risk Assessment Report required as part of the risk assessment process.
+
+a. When conducting a risk assessment, the organization must identify all organizational information systems . It must then identify all threats and vulnerabilities having to do with such systems , and rate the severity of such threats and vulnerabilities according to a predefined rating scale. Asset and risk owners must be defined for each risk item.
+
+a. Once the risk assessment is completed, the organization shall determine how to manage risks where the overall assessed risk rating is deemed as too high. This management is known as risk treatment. Risk treatment options include but are not limited to applying security controls, outsourcing risk, accepting risk, or discontinuing the activity associated with the risk.
+
+a. A penetration test must be performed by a third party to verify the accuracy of the risk assessment and effectiveness of deployed risk treatments.
+
+# Procedure To Execute Risk Assessment Report
+
+a. Confirms that the entire risk assessment and risk treatment process has been carried out according to the Risk Assessment Policy.
+
+a. The purpose of the risk assessment was to identify all information systems  their vulnerabilities, and threats that could exploit vulnerabilities. These parameters were further evaluated in order to establish the criticality of individual risks.
+
+a. The purpose of the risk treatment was to define the systematic means of reducing or controlling the risks identified in the risk assessment.
+
+a. All risk assessment and treatment activities were completed within the scope of the organization’s information security program.
+
+a. The risk assessment was implemented in the period from [day/month/year] to [day/month/year]. The risk treatment was implemented from [day/month/year] to [day/month/year]. Final reports were prepared during [specify period].
+
+a. The risk assessment and risk treatment process was managed by [person responsible for managing the risk assessment process] with expert assistance provided by [person or company responsible for assistance].
+
+a. During the risk assessment, information was collected through questionnaires and interviews with responsible persons, namely the asset owners across organizational units.
+
+a. The process was conducted as follows:
+
+    i. All information systems and their owners were identified.
+
+    i. Threats were identified for each asset, and corresponding vulnerabilities were identified for each threat.
+    i. Risk owners were identified for each risk.
+
+    i. Consequences of the loss of confidentiality, integrity and availability were evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The likelihood of risk occurrence (i.e. that the threat will exploit the vulnerability) was evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The level of risk was calculated by adding up the consequence and likelihood.
+
+    i. Risks with a score of 3 or 4 were determined to be unacceptable risks.
+
+    i. For each unacceptable risk, a risk treatment option was considered, and appropriate information security controls were selected.
+
+    i. After controls were applied, residual risks were assessed.
+
+a. The following documents were used or generated during the implementation of risk assessment and risk treatment:
+    
+    i. Risk Assessment Table (Appendix A): for each combination of systems , vulnerabilities and threats, this table shows the values for consequence and likelihood, and calculates the risk.
+
+    i. Risk Treatment Table (Appendix B): defines the options for risk treatment, selection of controls for each unacceptable risk, and the level of residual risk.
--- a/themes/comply-soc2/policies/development.md
+++ b/themes/comply-soc2/policies/development.md
@@ -8,4 +8,188 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for establishing and maintaining baseline protection standards for company software, network devices, servers, and desktops.
+
+a. This policy applies to all users performing software development, system administration, and management of these activities within the organization. This typically includes employees and contractors, as well as any relevant external parties involved in these activities (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+a. This policy also applies to enterprise-wide systems and applications developed by the organization or on behalf of the organization for production implementation.
+
+# Background
+
+a. The intent of this policy is to ensure a well-defined, secure and consistent process for managing the entire lifecycle of software and information systems, from initial requirements analysis until system decommission. The policy defines the procedure, roles, and responsibilities, for each stage of the software development lifecycle.
+
+a. Within this policy, the software development lifecycle consists of requirements analysis, architecture and design, development, testing, deployment/implementation, operations/maintenance, and decommission. These processes may be followed in any form; in a waterfall model, it may be appropriate to follow the process linearly, while in an agile development model, the process can be repeated in an iterative fashion.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. The organization’s Software Development Life Cycle (SDLC) includes the following phases:
+
+    i. Requirements Analysis
+
+    i. Architecture and Design
+
+    i. Testing
+
+    i. Deployment/Implementation
+
+    i. Operations/Maintenance
+
+    i. Decommission
+
+a. During all phases of the SDLC where a system is not in production, the system must not have live data sets that contain information identifying actual people or corporate entities, actual financial data such as account numbers, security codes, routing information, or any other financially identifying data. Information that would be considered sensitive must never be used outside of production environments.
+
+a. The following activities must be completed and/or considered during the requirements analysis phase:
+
+    i. Analyze business requirements.
+
+    i. Perform a risk assessment. More information on risk assessments is discussed in the Risk Assessment Policy (reference (a)).
+
+    i. Discuss aspects of security (e.g., confidentiality, integrity, availability) and how they might apply to this requirement.
+
+    i. Review regulatory requirements and the organization’s policies, standards, procedures and guidelines.
+
+    i. Review future business goals.
+
+    i. Review current business and information technology operations.
+
+    i. Incorporate program management items, including:
+
+        1. Analysis of current system users/customers.
+
+        1. Understand customer-partner interface requirements (e.g., business-level, network).
+
+        1. Discuss project timeframe.
+
+    i. Develop and prioritize security solution requirements.
+
+    i. Assess cost and budget constraints for security solutions, including development and operations.
+
+    i. Approve security requirements and budget.
+
+    i. Make “buy vs. build” decisions for security services based on the information above.
+
+a. The following must be completed/considered during the architecture and design phase:
+
+    i. Educate development teams on how to create a secure system.
+
+    i. Develop and/or refine infrastructure security architecture.
+
+    i. List technical and non-technical security controls.
+
+    i. Perform architecture walkthrough.
+
+    i. Create a system-level security design.
+
+    i. Create high-level non-technical and integrated technical security designs.
+
+    i. Perform a cost/benefit analysis for design components.
+
+    i. Document the detailed technical security design.
+
+    i. Perform a design review, which must include, at a minimum, technical reviews of application and infrastructure, as well as a review of high-level processes.
+
+    i. Describe detailed security processes and procedures, including: segregation of duties and segregation of development, testing and production environments. 
+
+    i. Design initial end-user training and awareness programs.
+
+    i. Design a general security test plan.
+
+    i. Update the organization’s policies, standards, and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+
+    i. Design and establish separate development and test environments.
+
+a. The following must be completed and/or considered during the development phase:
+
+    i. Set up a secure development environment (e.g., servers, storage).
+
+    i. Train infrastructure teams on installation and configuration of applicable software, if required.
+
+    i. Develop code for application-level security components.
+
+    i. Install, configure and integrate the test infrastructure.
+
+    i. Set up security-related vulnerability tracking processes.
+
+    i. Develop a detailed security test plan for current and future versions (i.e., regression testing).
+
+    i. Conduct unit testing and integration testing.
+
+a. The following must be completed and/or considered during the testing phase:
+
+    i. Perform a code and configuration review through both static and dynamic analysis of code to identify vulnerabilities. 
+
+    i. Test configuration procedures.
+
+    i. Perform system tests.
+
+    i. Conduct performance and load tests with security controls enabled.
+
+    i. Perform usability testing of application security controls.
+
+
+    i. Conduct independent vulnerability assessments of the system, including the infrastructure and application.
+
+a. The following must be completed and/or considered during the deployment phase:
+
+    i. Conduct pilot deployment of the infrastructure, application and other relevant components.
+
+    i. Conduct transition between pilot and full-scale deployment.
+
+    i. Perform integrity checking on system files to ensure authenticity.
+
+    i. Deploy training and awareness programs to train administrative personnel and users in the system’s security functions.
+
+    i. Require participation of at least two developers in order to conduct full-scale deployment to the production environment.
+
+a. The following must be completed and/or considered during the operations/maintenance phase:
+
+    i. Several security tasks and activities must be routinely performed to operate and administer the system, including but not limited to:
+
+        1. Administering users and access.
+
+        1. Tuning performance.
+
+        1. Performing backups according to requirements defined in the System Availability Policy 
+
+        1. Performing system maintenance (i.e., testing and applying security updates and patches).
+
+        1. Conducting training and awareness.
+
+        1. Conducting periodic system vulnerability assessments.
+
+        1. Conducting annual risk assessments.
+
+    i. Operational systems must:
+
+        1. Be reviewed to ensure that the security controls, both automated and manual, are functioning correctly and effectively.
+
+        1. Have logs that are periodically reviewed to evaluate the security of the system and validate audit controls.
+
+        1. Implement ongoing monitoring of systems and users to ensure detection of security violations and unauthorized changes.
+
+        1. Validate the effectiveness of the implemented security controls through security training as required by the Procedure For Executing Incident Response.
+
+        1. Have a software application and/or hardware patching process that is performed regularly in order to eliminate software bug and security problems being introduced into the organization’s technology environment. Patches and updates must be applied within ninety (90) days of release to provide for adequate testing and propagation of software updates. Emergency, critical, break-fix, and zero-day vulnerability patch releases must be applied as quickly as possible.
+
+a. The following must be completed and/or considered during the decommission phase:
+
+    i. Conduct unit testing and integration testing on the system after component removal.
+
+    i. Conduct operational transition for component removal/replacement.
+
+    i. Determine data retention requirements for application software and systems data.
+
+    i. Document the detailed technical security design.
+
+    i. Update the organization’s policies, standards and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+
--- a/themes/comply-soc2/policies/disaster.md
+++ b/themes/comply-soc2/policies/disaster.md
@@ -8,5 +8,144 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+#Purpose and Scope 

-# Coming Soon
+a. The purpose of this policy is to define the organization’s procedures to recover Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a set Recovery Time Objective (RTO).
+
+a. This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management.
+
+a. This policy applies to all management, employees and suppliers that are involved in the recovery of IT infrastructure and services within the organization. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines the overall disaster recovery strategy for the organization. The strategy describes the organization’s Recovery Time Objective (RTO), which is defined as the duration of time and service level for critical business processes to be restored after a disaster or other disruptive event, as well as the procedures, responsibility and technical guidance required to meet the RTO. This policy also lists the contact information for personnel and service providers that may be needed during a disaster recovery event.
+
+a. The following conditions must be met for this plan to be viable:
+
+    i. All equipment, software and data (or their backups/failovers) are available in some manner.
+
+    i. If an incident takes place at the organization’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties.
+
+    i. The Information Security Officer is responsible for coordinating and conducting a bi-annual (at least) rehearsal of this continuity plan. 
+
+a. This plan does not cover the following types of incidents:
+
+    i. Incidents that affect customers or partners but have no effect on the organization’s systems; in this case, the customer must employ their own continuity processes to make sure that they can continue to interact with the organization and its systems.
+
+    i. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including but not limited to Google, Heroku, and Amazon Web Services. The organization depends on such suppliers to employ their own continuity processes.
+
+# Policy
+
+a. *Relocation*
+
+    i. If the organization’s primary work site is unavailable, an alternate work site shall be used by designated personnel. The organization’s alternate work site is located at [list the address of the alternate work site that the organization will use].
+
+    i. The personnel required to report to the alternate work site during a disaster includes [list the personnel titles responsible for reporting to the alternate work site].
+
+a. *Critical Services, Key Tasks and, Service Level Agreements (SLAs)*
+
+    i. The following services and technologies are considered to be critical for business operations, and must immediately be restored (in priority order):
+  
+        1. [list the critical services and technologies that must remain running during a disaster]
+
+    i. The following key tasks and SLAs must be considered during a disaster recovery event, in accordance with the organization’s objectives, agreements, and legal, contractual or regulatory obligations:
+
+        1. [list of key tasks / SLAs that must be kept operational, with respective deadlines]
+
+a. The organization’s Recovery Time Objective (RTO) is [set the maximum amount of time before critical processes must be restored, to include relocation and getting critical services/technologies back online]. Relocation and restoration of critical services and technologies must be completed within this time period.
+
+a. *Notification of Plan Initiation*
+
+    i. The following personnel must be notified when this plan is initiated:
+
+      1. [list all personnel (including titles) that must be notified of plan initiation ]
+
+    i. [person responsible for notifications, including title] is responsible for notifying the personnel listed above.
+
+a. *Plan Deactivation*
+
+    i. This plan must only be deactivated by [person or persons with authority to deactivate the plan, including job title].
+
+    i. In order for this plan to be deactivated, all relocation activities and critical service / technology tasks  as detailed above must be fully completed and/or restored. If the organization is still operating in an impaired scenario, the plan may still be kept active at the discretion of [person or persons with authority to deactivate the plan, including job title].
+
+    i. The following personnel must be notified when this plan is deactivated:
+
+        1. [list all personnel (including titles) that must be notified of plan activation]
+
+a. The organization must endeavor to restore its normal level of business operations as soon as possible.
+
+a. A list of relevant points of contact both internal and external to the organization is enclosed in Appendix A.
+
+a. During a crisis, it is vital for certain recovery tasks to be performed right away. The following actions are pre-authorized in the event of a disaster recovery event:
+
+    i. [job title] must take all steps specified in this disaster recovery plan in order to recover the organization’s information technology infrastructure and services.
+    
+    i. [job title] is authorized to make urgent purchases of equipment and services up to [amount].
+    
+    i. [job title] is authorized to communicate with clients.
+    
+    i. [job title] is authorized to communicate with the public.
+    
+    i. [job title] is authorized to communicate with public authorities such as state and local governments and law enforcement.
+    
+    i. [job title] is authorized to cooperate with [name of supplier/outsourcing partner].
+    
+    i. [add/modify/remove authorizations in this section as necessary]
+
+a. Specific recovery steps for information systems infrastructure and services are provided in Appendix B.
+
+\pagebreak 
+
+# Appendix A: Relevant Points of Contact
+
+Internal Contacts
+
+------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
+==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+
+External Contacts
+
+------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
+==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+
+\pagebreak
+
+# Appendix B: Recovery Steps for Information Systems Infrastructure & Services
+
+Specific recovery procedures are described in detail below:
+
+----------------------------+----------------------+------------------------------------+
+|     Recovery Procedure     |  Person Responsible  |  Person(s) Notified When Complete  |
+============================+======================+====================================+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
+----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    |  
+|                            |                      |                                    |
+----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |   
+|                            |                      |                                    |              
+----------------------------+----------------------+------------------------------------+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
+----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    | 
+|                            |                      |                                    |    
+----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |    
+|                            |                      |                                    |             
+----------------------------+----------------------+------------------------------------+
--- a/themes/comply-soc2/policies/encryption.md
+++ b/themes/comply-soc2/policies/encryption.md
@@ -7,5 +7,76 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Purpose and Scope
+
+a. This policy defines organizational requirements for the use of cryptographic controls, as well as the requirements for cryptographic keys, in order to protect the confidentiality, integrity, authenticity and nonrepudiation of information.
+
+a. This policy applies to all systems, equipment, facilities and information within the scope of the organization’s information security program.
+
+a. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work on behalf of the organization having to do with cryptographic systems, algorithms, or keying material are subject to this policy and must comply with it.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s use of cryptographic algorithms and keys. It is vital that the organization adopt a standard approach to cryptographic controls across all work centers in order to ensure end-to-end security, while also promoting interoperability. This document defines the specific algorithms approved for use, requirements for key management and protection, and requirements for using cryptography in cloud environments.
+
+# Policy
+
+a. The organization must protect individual systems or information by means of cryptographic controls as defined in Table 3: 
+
+\pagebreak 
+
+---------------------+-------------------+----------------+--------------+
+| **Name of System/** | **Cryptographic** | **Encryption** | **Key Size** |
+| **Type of**         | **Tool**          | **Algorithm**  |              |
+| **Information**     |                   |                |              |
+=====================+===================+================+==============+
+| Public Key          |  OpenSSL          | AES-256        | 256-bit key  |
+| Infrastructure for  |                   |                |              |
+| Authentication      |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+| Data Encryption     |  OpenSSL          | AES-256        | 256-bit key  |
+| Keys                |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+| Virtual Private     |  OpenSSL and      | AES-256        | 256-bit key  |
+| Network (VPN)       |  OpenVPN          |                |              |
+| keys                |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
+---------------------+-------------------+----------------+--------------+
+| Website SSL         |  OpenSSL, CERT    | AES-256        | 256-bit key  |
+| Certificate         |                   |                |              | 
+---------------------+-------------------+----------------+--------------+
+
+Table 3: Cryptographic Controls 
+
+&nbsp;
+
+b. Except where otherwise stated, keys must be managed by their owners.
+
+c. Cryptographic keys must be protected against loss, change or destruction by applying appropriate access control mechanisms to prevent unauthorized use and backing up keys on a regular basis.
+
+d. When required, customers of the organization’s cloud-based software or platform offering must be able to obtain information regarding:
+
+    i. The cryptographic tools used to protect their information.
+
+    i. Any capabilities that are available to allow cloud service customers to apply their own cryptographic solutions.
+
+    i. The identity of the countries where the cryptographic tools are used to store or transfer cloud service customers’ data.
+
+a. The use of organizationally-approved encryption must be governed in accordance with the laws of the country, region, or other regulating entity in which users perform their work. Encryption must not be used to violate any laws or regulations including import/export restrictions. The encryption used by the Company conforms to international standards and U.S. import/export requirements, and thus can be used across international boundaries for business purposes.
+
+a. All key management must be performed using software that automatically manages access control, secure storage, backup and rotation of keys. Specifically:
+
+  i. The key management service must provide key access to specifically-designated users, with the ability to encrypt/decrypt information and generate data encryption keys.
+
+  i. The key management service must provide key administration access to specifically-designated users, with the ability to create, schedule delete, enable/disable rotation, and set usage policies for keys.
+
+  i. The key management service must store and backup keys for the entirety of their operational lifetime.
+
+  i. The key management service must rotate keys at least once every 12 months.
+

-# Coming Soon
--- a/themes/comply-soc2/policies/media.md
+++ b/themes/comply-soc2/policies/media.md
@@ -8,4 +8,133 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This removable media, cloud storage and Bring Your Own Device (BYOD) policy defines the objectives, requirements and implementing instructions for storing data on removable media, in cloud environments, and on personally-owned devices, regardless of data classification level.
+
+a. This policy applies to all information and data within the organization’s information security program, as well as all removable media, cloud systems and personally-owned devices either owned or controlled by the organization.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. This policy defines the procedures for safely using  removable media, cloud storage and personally-owned devices to limit data loss or exposure.  Such forms of storage must be strictly controlled because of the sensitive data that can be stored on them. Because each of these storage types are inherently ephemeral or portable in nature, it is possible for the organization to lose the ability to oversee or control the information stored on them if strict security standards are not followed.
+
+a. This document consists of three sections pertaining to removable media, cloud storage, and personally-owned devices. Each section contains requirements and implementing instructions for the registration, management, maintenance, and disposition of each type of storage.
+
+a. Within this policy, the term sensitive information refers to information that is classified as RESTRICTED or CONFIDENTIAL in accordance with the Data Classification Policy (reference (a)).
+
+# References
+
+a. Data Classification Policy
+
+a. Asset Inventory
+
+a. Security Incident Response Policy
+
+a. Encryption Policy
+
+# Policy
+
+a. *Removable Media*
+
+    i. All removable media in active use and containing data pertinent to the organization must be registered in the organization’s Asset Inventory (reference (b)).
+
+    i. All removable media listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization.
+
+        1. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM).
+
+        1. The ISM must treat any removable media that cannot be located as lost, and a security incident report must be logged in accordance with the Security Incident Response Policy (reference (c)).
+
+    i. The owner of the removable media must conduct all appropriate maintenance on the item at intervals appropriate to the type of media, such as cleaning, formatting, labeling, etc.
+
+    i. The owner of the removable media, where practical, must ensure that an alternate or backup copy of the information located on the device exists.
+
+    i. Removable media must be stored in a safe place that has a reduced risk of fire or flooding damage. 
+
+    i. If the storage item contains sensitive information, removable media must:
+
+        1. Be stored in a locked cabinet or drawer.
+
+        1. Store only encrypted data that is securely enciphered in accordance with the Encryption Policy (reference (d)).
+
+    i. All data on removable media devices must be erased, or the device must be destroyed, before it is reused or disposed of.
+
+    i. When removable media devices are disposed, the device owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Cloud Storage*
+
+    i. All cloud storage systems in active use and containing data pertinent to the organization must be registered in reference (b). Registration may be accomplished by manual or automated means.
+
+
+    i. All cloud storage systems listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM). Re-inventory may be accomplished by manual or automated means.
+
+    i. The owner of the cloud storage system must conduct all appropriate maintenance on the system at regular intervals to include system configuration, access control, performance monitoring, etc.
+
+    i. Data on cloud storage systems must be replicated to at least one other physical location. Depending on the cloud storage provider, this replication may be automatically configured.
+
+    i. The organization must only use cloud storage providers that can demonstrate, either through security accreditation, demonstration, tour, or other means that their facilities are secured, both physically and electronically, using best practices.
+
+    i. If the cloud storage system contains sensitive information, that information must be encrypted in accordance with reference (d).
+
+    i. Data must be erased from from cloud storage systems using a technology and process that is approved by the ISM. 
+
+    i. When use of a cloud storage system is discontinued, the system owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Personally-owned Devices*
+
+    i. Organizational data that is stored, transferred or processed on personally-owned devices remains under the organization’s ownership, and the organization retains the right to control such data even though it is not the owner of the device.
+
+    i. The ISM is responsible for conducting overall management of personally-owned devices, to include:
+
+        1. Installation and maintenance of Mobile Device Management (MDM) software that can effectively manage, control and wipe data under the organization’s control from personally-owned devices.
+
+        1. Maintain a list of job titles and/or persons authorized to use personally-owned devices for the organization’s business, as well as the applications and databases that may be accessed from such devices.
+
+        1. Maintain a list of applications prohibited from use on personally-owned devices, and ensuring that device users are aware of these restrictions.
+
+    i. Personally-identifiable information (PII) may not be stored, processed or accessed at any time on a personally-owned device.
+
+    i. The following acceptable use requirements must be observed by users of personally-owned devices:
+
+        1. All organizational data must be backed up at regular intervals.
+
+        1. MDM and endpoint protection software must be installed on the device at all times.
+
+        1. Sensitive information stored on the device must be encrypted in accordance with reference (d).
+
+        1. The device must be secured using a password, pin, unlock pattern, fingerprint or equivalent security mechanism.
+
+        1. The device must only connect to secure and encrypted wireless networks.
+
+        1. When using the device outside of the organization’s premises, it must not be left unattended, and if possible, physically secured.
+
+        1. When using the device in public areas, the owner must take measures to ensure that the data cannot be read or accessed by unauthorized persons.
+
+        1. Patches and updates must be installed regularly.
+
+        1. Classified information must be protected in accordance with reference (a).
+
+        1. The device owner must install the ISM before the device is disposed of, sold, or provided to a third party for servicing.
+
+        1. It is prohibited to:
+
+            a. Allow device access for anyone except its owner.
+        
+            a. Store illegal materials on the device.
+
+            a. Install unlicensed software.
+
+            a. Locally-store passwords.
+
+            a. Transfer organizational data to other devices which have not been approved by the organization.
+
+    i. The organization must reserve the right to view, edit, and/or delete any organizational information that is stored, processed or transferred on the device.
+
+    i. The organization must reserve the right to perform full deletion of all of its data on the device if it considers that necessary for the protection of company-related data, without the consent of the device owner.
+
+    i. The organization will not pay the employees (the owners of BYOD) any fee for using the device for work purposes.
+
+    i. The organization will pay for any new software that needs to be installed for company use.
+
+    i. All security breaches related to personally-owned devices must be reported immediately to the ISM. 
--- a/themes/comply-soc2/policies/remote.md
+++ b/themes/comply-soc2/policies/remote.md
@@ -10,4 +10,50 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for connecting to the organization’s systems and networks from remote hosts, including personally-owned devices, in order to minimize data loss/exposure.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily accessible to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the organization’s exposure to damages which may result from the unauthorized remote use of resources, including but not limited to: the loss of sensitive, company confidential data and intellectual property; damage to the organization’s public image; damage to the organization’s internal systems; and fines and/or other financial liabilities incurred as a result of such losses.
+
+a. Within this policy, the following definitions apply:
+
+    i. *Mobile computing equipment:* includes portable computers, mobile phones, smart phones, memory cards and other mobile equipment used for storage, processing and transfer of data.
+
+    i. *Remote host:* is defined as an information system, node or network that is not under direct control of the organization.
+
+    i. *Telework:* the act of using mobile computing equipment and remote hosts to perform work outside the organization’s physical premises. Teleworking does not include the use of mobile phones.
+
+# Policy
+
+a. *Security Requirements for Remote Hosts and Mobile Computing Equipment*
+
+    i. Caution must be exercised when mobile computing equipment is placed or used in uncontrolled spaces such as vehicles, public spaces, hotel rooms, meeting places, conference centers, and other unprotected areas outside the organization’s premises.
+
+    i. When using remote hosts and mobile computing equipment, users must take care that information on the device (e.g. displayed on the screen) cannot be read by unauthorized persons if the device is being used to connect to the organization’s systems or work with the organization’s data.
+
+    i. Remote hosts must be updated and patched for the latest security updates on at least a monthly basis.
+
+    i. Remote hosts must have endpoint protection software (e.g. malware scanner) installed and updated at all times.
+
+    i. Persons using mobile computing equipment off-premises are responsible for regular backups of organizational data that resides on the the device.
+
+    i. Access to the organization’s systems must be done through an encrypted and authenticated VPN connection with multi-factor authentication enabled. All users requiring remote access must be provisioned with VPN credentials from the organization’s information technology team. VPN keys must be rotated at least twice per year. Revocation of VPN keys must be included in the Offboarding Policy. 
+
+    i. Information stored on mobile computing equipment must be encrypted using hard drive full disk encryption.
+
+a. *Security Requirements for Telework*
+
+    i. Employees must be specifically authorized for telework in writing from their hiring manager .
+
+    i. Only device’s assigned owner is permitted to use remote nodes and mobile computing equipment. Unauthorized users (such as others living or working at the location where telework is performed) are not permitted to use such devices.
+
+    i. Devices must be authorized using certificates
+
+    i. Users performing telework are responsible for the appropriate configuration of the local network used for connecting to the Internet at their telework location.
+
+    i. Users performing telework must protect the organization’s intellectual property rights, either for software or other materials that are present on remote nodes and mobile computing equipment.
--- a/themes/comply-soc2/policies/retention.md
+++ b/themes/comply-soc2/policies/retention.md
@@ -10,4 +10,79 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+#Appendices
+Appendix A: Retention Periods
+
+# Purpose and Scope
+
+a. This data retention policy defines the objectives and requirements for data retention within the organization.
+
+a. This policy covers all data within the organization’s custody or control, irregardless of the medium the data is stored in (electronic form, paper form, etc.) Within this policy, the medium which holds data is referred to as information, no matter what form it is in.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information the organization owns or controls (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The organization is bound by multiple legal, regulatory and contractual obligations with regard to the data it retains. These obligations stipulate how long data can be retained, and how data must be destroyed. Examples of legal, regulatory and contractual obligations include laws and regulations in the local jurisdiction where the organization conducts business, and contracts made with employees, customers, service providers, partners and others.
+
+a. The organization may also be involved in events such as litigation or disaster recovery scenarios that require it to have access to original information in order to protect the organization’s interests or those of its employees, customers, service providers, partners and others. As a result, the organization may need to archive and store information for longer that it may be needed for day-to-day operations.
+ 
+ \pagebreak 
+
+# Policy
+
+a. *Information Retention*
+
+    i. Retention is defined as the maintenance of information in a production or live environment which can be accessed by an authorized user in the ordinary course of business. 
+
+    i. Information used in the development, staging, and testing of systems shall not be retained beyond their active use period nor copied into production or live environments.
+
+    i. By default, the retention period of information shall be an active use period of exactly two years from its creation unless an exception is obtained permitting a longer or shorter retention period. The business unit responsible for the information must request the exception.
+
+    i. After the active use period of information is over in accordance with this policy and approved exceptions, information must be archived for a defined period. Once the defined archive period is over, the information must be destroyed.
+
+    i. Each business unit is responsible for the information it creates, uses, stores, processes and destroys, according to the requirements of this policy. The responsible business unit is considered to be the information owner.
+
+    i. The organization’s legal counsel may issue a litigation hold to request that information relating to potential or actual litigation, arbitration or other claims, demands, disputes or regulatory action be retained in accordance with instructions from the legal counsel.
+
+    i. Each employee and contractor affiliated with the company must return information in their possession or control to the organization upon separation and/or retirement.
+
+    i. Information owners must enforce the retention, archiving and destruction of information, and communicate these periods to relevant parties.
+
+a. *Information Archiving*
+
+    i. Archiving is defined as secured storage of information such that the information is rendered inaccessible by authorized users in the ordinary course of business but can be retrieved by an administrator designated by company management.
+
+        1. Physical (e.g., paper) records must be archived in secured storage (onsite or offsite) and clearly labeled in archive boxes naming the information owner.
+
+        1. Electronic records must be archived with strict access controls set by the information owner and appropriate to secure the confidentiality, integrity and accessibility of the information.
+
+    i. The default archiving period of information shall be 7 years unless an approved exception permits a longer or shorter period. Exceptions must be requested by the information owner.
+
+        1. As a guideline, an archiving period of more than 7 years may be granted for information with a vital historical purpose such as corporate records, contracts, and technical/trade secrets.
+
+        1. As a guideline, an archiving period of less than 7 years may be granted for information with a limited business purpose such as email, travel itineraries, pre-trip advisories, or to comply with specific legal, contractual and/or regulatory requirements (e.g., PCI DSS, GDPR, etc.)
+
+    i. Information must be destroyed (defined below) at the end of the elapsed archiving period.  
+
+a. *Information Destruction*
+
+    i. Destruction is defined as the physical or technical destruction sufficient to render the information contained in the document irretrievable by ordinary commercially-available means.
+
+    i. The organization must maintain and enforce a detailed list of approved destruction methods appropriate for each type of information archived, whether in physical storage media such as CD-ROMs, DVDs, backup tapes, hard drives, mobile devices, portable drives or in database records or backup files. Physical information in paper form must be shredded using an authorized shredding device; waste must be periodically removed by approved personnel.
+
+a. Retention and archival periods for information that is created, processed, stored and used by the organization is defined in Appendix A, “Retention Periods.” 
+
+\pagebreak 
+
+# Appendix A: Retention Periods 
+
+------------------+-------------------+------------------+------------------+-----------------+
+| Information Type | Information Owner | Storage Location | Retention Period | Archival Period |
+==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
+------------------+-------------------+------------------+------------------+-----------------+
--- a/themes/comply-soc2/policies/risk.md
+++ b/themes/comply-soc2/policies/risk.md
@@ -8,4 +8,130 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within the organization, and to define the acceptable level of risk as set by the organization’s leadership.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all assets which are used within the organization or which could have an impact on information security within it.
+
+a. This policy applies to all employees of the organization who take part in risk assessment and risk treatment.
+
+# Background
+
+a. A key element of the organization’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for the organization to identify information security risks. The process consists of four parts: identification of the organization’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.
+
+# References
+
+a. Risk Assessment Report Template
+
+# Policy
+
+a. *Risk Assessment*
+
+    i. The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.
+
+    i. The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
+
+    i. The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities. A sample risk assessment table is provided as part of the Risk Assessment Report Template (reference (a)).
+
+    i. For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
+
+    i. Once risk owners are identified, they must assess:
+
+        1. Consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes. 
+
+        1. Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).
+
+        1. Criteria for determining consequence and likelihood are defined in Tables 3 and 4.
+    
+    i. The risk level is calculated by adding the consequence score and the likelihood score.
+
+-----------------+-----------------+--------------------------------------------------------------+
+| **Consequence** | **Consequence** | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
+=================+=================+==============================================================+
+| Low             | 0               | Loss of confidentiality, integrity, or availability will not |     
+|                 |                 | affect the organization's cash flow, legal, or contractual   |                    
+|                 |                 | obligations, or reputation.                                  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Loss of confidentiality, integrity, or availability may incur|     
+|                 |                 | financial cost and has low or moderate impact on the         |                    
+|                 |                 | organization's legal or contractual obligations and/or       |
+|                 |                 | reputation.                                                  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Loss of confidentiality, integrity, or availability will have|     
+|                 |                 | immediate and or/considerable impact on the organization's   |                    
+|                 |                 | cash flow, operations, legal and contractual obligations,and/|
+|                 |                 | or reputation.                                               |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+
+Table 3: Description of Consequence Levels and Criteria
+
+-----------------+-----------------+--------------------------------------------------------------+
+| **Likelihood**  | **Likelihood**  | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
+=================+=================+==============================================================+
+| Low             | 0               | Either existing security controls are strong and have so far |     
+|                 |                 | provided an adequate level of protection, or the probability |                    
+|                 |                 | of the risk being realized is extremely low. No new incidents|
+|                 |                 | are expected in the future.                                  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Either existing security controls have most provided an      |     
+|                 |                 | adequate level of protection or the probability of the risk  |                    
+|                 |                 | being realized is moderate. Some minor incidents may have    |
+|                 |                 | occured. New incidents are possible, but not highly likely.  |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Either existing security controls are not in place or        |
+|                 |                 | ineffective; there is a high probability of the risk being   |                    
+|                 |                 | realized. Incidents have a high likelihood of occuring in the|
+|                 |                 | future.                                             |
+-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
+-----------------+-----------------+--------------------------------------------------------------+
+
+Table 4: Description of Likelihood Levels and Criteria
+
+&nbsp;
+
+b. *Risk Acceptance Criteria*
+
+    i. Risk values 0 through 2 are considered to be acceptable risks.
+
+    i. Risk values 3 and 4 are considered to be unacceptable risks. Unacceptable risks must be treated.
+
+c. *Risk Treatment*
+
+    i. Risk treatment is implemented through the Risk Treatment Table. All risks from the Risk Assessment Table must be copied to the Risk Treatment Table for disposition, along with treatment options and residual risk. A sample Risk Treatment Table is provided in reference (a).
+
+    i. As part of this risk treatment process, the CEO and/or other company managers shall determine objectives for mitigating or treating risks. All unacceptable risks must be treated. For continuous improvement purposes, company managers may also opt to treat other risks for company assets, even if their risk score is deemed to be acceptable.
+
+    i. Treatment options for risks include the following options:
+
+        1. Selection or development of security control(s).
+
+        1. Transferring the risks to a third party; for example, by purchasing an insurance policy or signing a contract with suppliers or partners.
+
+        1. Avoiding the risk by discontinuing the business activity that causes such risk.
+
+        1. Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.
+
+    i. After selecting a treatment option, the risk owner should estimate the new consequence and likelihood values after the planned controls are implemented.
+
+a. *Regular Reviews of Risk Assessment and Risk Treatment*
+
+    i. The Risk Assessment Table and Risk Treatment Table must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year. It is highly recommended that the Risk Assessment and Risk Treatment Table be updated when significant changes occur to the organization, technology, business objectives, or business environment.
+
+a. *Reporting*
+
+    i. The results of risk assessment and risk treatment, and all subsequent reviews, shall be documented in a Risk Assessment Report.
+
--- a/themes/comply-soc2/policies/vendor.md
+++ b/themes/comply-soc2/policies/vendor.md
@@ -8,4 +8,40 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This policy defines the rules for relationships with the organization’s Information Technology (IT) vendors and partners. 
+
+a. This policy applies to all IT vendors and partners who have the ability to impact the confidentiality, integrity, and availability of the organization’s technology and sensitive information, or who are within the scope of the organization’s information security program.
+
+a. This policy applies to all employees and contractors that are responsible for the management and oversight of IT vendors and partners of the organization. 
+
+# Background
+
+a. The overall security of the organization is highly dependent on the security of its contractual relationships with its IT suppliers and partners. This policy defines  requirements for effective management and oversight of such suppliers and partners from an information security perspective. The policy prescribes minimum standards a vendor must meet from an information security standpoint, including security clauses, risk assessments, service level agreements, and incident management.
+
+# References
+
+a. Information Security Policy
+
+a. Security Incident Response Policy
+
+# Policy
+
+a. IT vendors are prohibited from accessing the organization’s information security assets until  a contract containing security controls is agreed to and signed by the appropriate parties.
+
+a. All IT vendors must comply with the security policies defined and derived from the Information Security Policy (reference (a)). 
+
+a. All security incidents by IT vendors or partners must be documented in accordance with the organization’s Security Incident Response Policy (reference (b)) and immediately forwarded to the Information Security Manager (ISM). 
+
+a. The organization must adhere to the terms of all Service Level Agreements (SLAs) entered into with IT vendors. As terms are updated, and as new ones are entered into, the organization must implement any changes or controls needed to ensure it remains in compliance. 
+
+a. Before entering into a contract and gaining access to the parent organization’s information systems, IT vendors must undergo a risk assessment. 
+
+    i. Security risks related to IT vendors and partners must be identified during the risk assessment process. 
+    
+    i. The risk assessment must identify risks related to information and communication technology, as well as risks related to IT vendor supply chains, to include sub-suppliers. 
+
+a. IT vendors and partners must ensure that organizational records are protected, safeguarded, and disposed of securely. The organization strictly adheres to all applicable legal, regulatory and contractual requirements regarding the collection, processing, and transmission of sensitive data such as Personally-Identifiable Information (PII). 
+
+a. The organization may choose to audit IT vendors and partners to ensure compliance with applicable security policies, as well as legal, regulatory and contractual obligations.
--- a/themes/comply-soc2/procedures/offboarding.md
+++ b/themes/comply-soc2/procedures/offboarding.md
@@ -2,4 +2,10 @@ id: "offboard"
 name: "Offboard User"
 ---

-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Immediately suspend user in SSO
+- [ ] Append HR termination request e-mail to this ticket
+- [ ] Look up manually-provisioned applications for this role or user
+- [ ] Validate access revocation in each
+- [ ] Append confirmation or revocation to this ticket
--- a/themes/comply-soc2/procedures/onboarding.md
+++ b/themes/comply-soc2/procedures/onboarding.md
@@ -2,4 +2,11 @@ id: "onboard"
 name: "Onboard New User"
 ---

-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Append HR add request e-mail to this ticket
+- [ ] Proactively validate role assignment with manager (see HR request e-mail)
+- [ ] Add user to default group for the specified role
+- [ ] Provision any manually-provisioned applications by role
+    - [ ] Append manual provisioning confirmation to this ticket
+- [ ] Proactively confirm with new user that they can access all provisioned systems
--- a/themes/comply-soc2/procedures/patch.md
+++ b/themes/comply-soc2/procedures/patch.md
@@ -1,6 +1,15 @@
 id: "patch"
 name: "Apply OS patches"
-cron: "0 0 1 * * *"
+cron: "0 0 0 15 * *"
 ---

-# Coming Soon
+# OS Patch Procedure
+
+Resolve this ticket by executing the following steps:
+
+- [ ] Pull the latest scripts from the Ops repository
+- [ ] Execute `ENV=staging patch-all.sh`
+- [ ] Inspect output
+    - [ ] Errors? Investigate and resolve
+- [ ] Execute `ENV=production patch-all.sh`
+- [ ] Attach log output to this ticket
--- a/themes/comply-soc2/procedures/workstation.md
+++ b/themes/comply-soc2/procedures/workstation.md
@@ -1,6 +1,40 @@
 id: "workstation"
 name: "Collect Workstation Details"
-cron: "0 0 * * * *"
+cron: "0 0 0 15 4 *"
 ---

-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Send the communications below
+- [ ] For any email replies, attach content to this ticket
+- [ ] Validate responses are received from each
+
+
+```
+To: Desktop support
+Subject: Annual workstation inventory
+
+Please attach the current workstation inventory to the following ticket: [REPLACE WITH URL TO THIS TICKET]
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```
+
+
+```
+To: Outsourced Call Center IT
+Subject: Annual workstation inventory
+
+As part of our ongoing compliance efforts and per our services agreement, we require a current inventory of workstations in use in the service of our account.
+
+Please respond to this message with the current inventory.
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```
--- a/themes/comply-soc2/templates/index.ace
+++ b/themes/comply-soc2/templates/index.ace
@@ -15,20 +15,11 @@ html lang=en
        document.querySelectorAll('.cron').forEach(function(el) {
          el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
        })
-        if (window.location.hash != "") {
-          var hashComponents = window.location.hash.split('#')
-          if (hashComponents.length>1) {
-            var destination = hashComponents[1]
-            if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
-              show(destination)
-            }
-          }
-        }
      })

      function show(name) {
        if (history.replaceState) {
-            history.replaceState(null, null, '#'+name);
+            history.replaceState(null, null, '#'+name)
        }

        var items = document.getElementsByClassName('top-nav')
@@ -233,7 +224,14 @@ html lang=en
        .content.has-text-centered
          p {{.Project.OrganizationName}} Confidential 2018
  = javascript
-    // commented for development
    if (window.location.hash=="") {
      show('overview')
+    } else {
+      var hashComponents = window.location.hash.split('#')
+      if (hashComponents.length>1) {
+        var destination = hashComponents[1]
+        if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
+          show(destination)
+        }
+      }
    }
--- a/tools.go
+++ b/tools.go
@@ -0,0 +1,10 @@
+// +build tools
+
+package tools
+
+import (
+	_ "github.com/Clever/gitsem"
+	_ "github.com/aktau/github-release"
+	_ "github.com/containous/go-bindata/go-bindata"              // v1.0.0
+	_ "github.com/elazarl/go-bindata-assetfs/go-bindata-assetfs" // v0.0.0-20170227122030-30f82fa23fd8
+)
--- a/vendor/github.com/Clever/gitsem/.drone.yml
+++ b/vendor/github.com/Clever/gitsem/.drone.yml
@@ -0,0 +1,24 @@
+image: bradrydzewski/go:1.3
+script:
+  - make test
+notify:
+  email:
+    recipients:
+      - drone@clever.com
+  hipchat:
+    room: Clever-Dev-CI
+    token: {{hipchat_token}}
+    on_started: true
+    on_success: true
+    on_failure: true
+publish:
+  github:
+    branch: master
+    script:
+      - make release
+    artifacts:
+      - release
+    tag: v$(cat VERSION)
+    token: {{github_token}}
+    user: Clever
+    repo: gitsem
--- a/vendor/github.com/Clever/gitsem/.gitignore
+++ b/vendor/github.com/Clever/gitsem/.gitignore
@@ -0,0 +1,25 @@
+# Compiled Object files, Static and Dynamic libs (Shared Objects)
+*.o
+*.a
+*.so
+
+# Folders
+_obj
+_test
+
+# Architecture specific extensions/prefixes
+*.[568vq]
+[568vq].out
+
+*.cgo1.go
+*.cgo2.c
+_cgo_defun.c
+_cgo_gotypes.go
+_cgo_export.*
+
+_testmain.go
+
+*.exe
+*.test
+
+gitsem
--- a/vendor/github.com/Clever/gitsem/Makefile
+++ b/vendor/github.com/Clever/gitsem/Makefile
@@ -0,0 +1,54 @@
+SHELL := /bin/bash
+PKG = github.com/Clever/gitsem
+PKGS = $(PKG)
+VERSION := $(shell cat VERSION)
+EXECUTABLE := gitsem
+BUILDS := \
+	build/$(EXECUTABLE)-v$(VERSION)-darwin-amd64 \
+	build/$(EXECUTABLE)-v$(VERSION)-linux-amd64 \
+	build/$(EXECUTABLE)-v$(VERSION)-windows-amd64
+COMPRESSED_BUILDS := $(BUILDS:%=%.tar.gz)
+RELEASE_ARTIFACTS := $(COMPRESSED_BUILDS:build/%=release/%)
+
+.PHONY: test golint
+
+golint:
+	@go get github.com/golang/lint/golint
+
+test: $(PKGS)
+
+$(PKGS): golint
+	@go get -d -t $@
+	@gofmt -w=true $(GOPATH)/src/$@*/**.go
+ifneq ($(NOLINT),1)
+	@echo "LINTING..."
+	@PATH=$(PATH):$(GOPATH)/bin golint $(GOPATH)/src/$@*/**.go
+	@echo ""
+endif
+ifeq ($(COVERAGE),1)
+	@go test -cover -coverprofile=$(GOPATH)/src/$@/c.out $@ -test.v
+	@go tool cover -html=$(GOPATH)/src/$@/c.out
+else
+	@echo "TESTING..."
+	@go test $@ -test.v
+endif
+
+run:
+	@go run main.go
+
+build/$(EXECUTABLE)-v$(VERSION)-darwin-amd64:
+	GOARCH=amd64 GOOS=darwin go build -o "$@/$(EXECUTABLE)"
+build/$(EXECUTABLE)-v$(VERSION)-linux-amd64:
+	GOARCH=amd64 GOOS=linux go build -o "$@/$(EXECUTABLE)"
+build/$(EXECUTABLE)-v$(VERSION)-windows-amd64:
+	GOARCH=amd64 GOOS=windows go build -o "$@/$(EXECUTABLE).exe"
+build: $(BUILDS)
+%.tar.gz: %
+	tar -C `dirname $<` -zcvf "$<.tar.gz" `basename $<`
+$(RELEASE_ARTIFACTS): release/% : build/%
+	mkdir -p release
+	cp $< $@
+release: $(RELEASE_ARTIFACTS)
+
+clean:
+	rm -rf build release
--- a/vendor/github.com/Clever/gitsem/README.md
+++ b/vendor/github.com/Clever/gitsem/README.md
@@ -0,0 +1,34 @@
+# gitsem
+
+A command line utility for managing semantically versioned (semver) git tags.
+
+Run this in a git repository to bump the version and write the new data back to the VERSION file.
+It will also create a version commit and (optional) tag, and fail if the repo is not clean.
+
+## Installation
+
+```shell
+$ go get github.com/Clever/gitsem
+```
+
+## Example
+```shell
+$ gitsem patch
+$ gitsem -m "Upgrade to %s for reasons" patch
+$ gitsem minor
+```
+
+## Usage
+
+```shell
+gitsem [options] version
+```
+
+`version` can be one of: `newversion | patch | minor | major`
+
+The version argument should be a valid semver string, or a field of a semver string (one of "patch", "minor", or "major").
+In the second case, the existing version will be incremented by 1 in the specified field.
+
+### Options
+  - `m=%s` specifies a commit message to use when bumping the version. If %s appears, it will be replaced with the new version number.
+  - `tag=true` whether or not to create a tag at the version commit
--- a/vendor/github.com/Clever/gitsem/VERSION
+++ b/vendor/github.com/Clever/gitsem/VERSION
@@ -0,0 +1 @@
+1.0.4
--- a/vendor/github.com/Clever/gitsem/git.go
+++ b/vendor/github.com/Clever/gitsem/git.go
@@ -0,0 +1,39 @@
+package main
+
+import (
+	"bytes"
+	"os/exec"
+	"strings"
+)
+
+func isRepoClean() (bool, error) {
+	cmd := exec.Command("git", "status", "-s")
+	result := &bytes.Buffer{}
+	cmd.Stdout = result
+	if err := cmd.Run(); err != nil {
+		return false, err
+	}
+	return result.String() == "", nil
+}
+
+func repoRoot() (string, error) {
+	cmd := exec.Command("git", "rev-parse", "--show-toplevel")
+	result := &bytes.Buffer{}
+	cmd.Stdout = result
+	if err := cmd.Run(); err != nil {
+		return "", err
+	}
+	return strings.TrimSpace(result.String()), nil
+}
+
+func addFile(path string) error {
+	return exec.Command("git", "add", path).Run()
+}
+
+func commit(message string) error {
+	return exec.Command("git", "commit", "-m", message).Run()
+}
+
+func tag(version string) error {
+	return exec.Command("git", "tag", version).Run()
+}
--- a/vendor/github.com/Clever/gitsem/main.go
+++ b/vendor/github.com/Clever/gitsem/main.go
@@ -0,0 +1,126 @@
+package main
+
+import (
+	"flag"
+	"fmt"
+	"gopkg.in/blang/semver.v1"
+	"io/ioutil"
+	"log"
+	"os"
+	"path/filepath"
+	"strings"
+)
+
+func commitMessage(message, version string) string {
+	if strings.Contains(message, "%s") {
+		return fmt.Sprintf(message, version)
+	}
+	return message
+}
+
+func getCurrentVersion(path string) (*semver.Version, error) {
+	if _, err := os.Stat(path); os.IsNotExist(err) {
+		return &semver.Version{}, nil
+	}
+	contents, err := ioutil.ReadFile(path)
+	if err != nil {
+		return nil, err
+	}
+	return semver.New(strings.TrimSpace(string(contents)))
+}
+
+const versionFileName = "VERSION"
+
+func exitWithError(message string) {
+	fmt.Fprintf(os.Stderr, message+"\n\n")
+	flag.Usage()
+	os.Exit(1)
+}
+
+func bump(old *semver.Version, part string) *semver.Version {
+	// We don't want to mutate the input, but there's no Clone or Copy method on a semver.Version,
+	// so we make a new one by parsing the string version of the old one.
+	// We ignore any errors because we know it's valid semver.
+	new, _ := semver.New(old.String())
+	switch part {
+	case "major":
+		new.Major++
+		new.Minor = 0
+		new.Patch = 0
+	case "minor":
+		new.Minor++
+		new.Patch = 0
+	case "patch":
+		new.Patch++
+	}
+	return new
+}
+
+func main() {
+	flag.Usage = func() {
+		fmt.Fprintf(os.Stderr, "Usage of %s: [options] version\n\n", os.Args[0])
+		fmt.Fprintf(os.Stderr, "version can be one of: newversion | patch | minor | major\n\n")
+		fmt.Fprintf(os.Stderr, "options:\n")
+		flag.PrintDefaults()
+	}
+	message := flag.String("m", "%s", "commit message for version commit")
+	help := flag.Bool("h", false, "print usage and exit")
+	shouldTag := flag.Bool("tag", true, "whether or not to make a tag at the version commit")
+	flag.Parse()
+
+	if *help {
+		flag.Usage()
+		os.Exit(0)
+	}
+
+	if *message == "" {
+		exitWithError("missing message")
+	}
+
+	if clean, err := isRepoClean(); err != nil {
+		log.Fatal(err)
+	} else if !clean {
+		log.Fatal("repo isn't clean")
+	}
+
+	root, err := repoRoot()
+	if err != nil {
+		log.Fatal(err)
+	}
+	versionFile := filepath.Join(root, versionFileName)
+	version, err := getCurrentVersion(versionFile)
+	if err != nil {
+		log.Fatal(err)
+	}
+	if len(flag.Args()) != 1 {
+		exitWithError("gitsem takes exactly one non-flag argument: version")
+	}
+
+	newVersion := flag.Args()[0]
+	switch newVersion {
+	case "patch", "minor", "major":
+		version = bump(version, newVersion)
+	default:
+		if version, err = semver.New(newVersion); err != nil {
+			log.Fatalf("failed to parse %s as semver: %s", newVersion, err.Error())
+		}
+	}
+
+	if err := ioutil.WriteFile(versionFile, []byte(version.String()), 0666); err != nil {
+		log.Fatal(err)
+	}
+	if err := addFile(versionFile); err != nil {
+		log.Fatal(err)
+	}
+	versionString := "v" + version.String()
+	*message = commitMessage(*message, versionString)
+	if err := commit(*message); err != nil {
+		log.Fatal(err)
+	}
+	if *shouldTag {
+		if err := tag(versionString); err != nil {
+			log.Fatal(err)
+		}
+	}
+	fmt.Println(versionString)
+}
--- a/vendor/github.com/Microsoft/go-winio/file.go
+++ b/vendor/github.com/Microsoft/go-winio/file.go
@@ -16,6 +16,7 @@ import (
 //sys createIoCompletionPort(file syscall.Handle, port syscall.Handle, key uintptr, threadCount uint32) (newport syscall.Handle, err error) = CreateIoCompletionPort
 //sys getQueuedCompletionStatus(port syscall.Handle, bytes *uint32, key *uintptr, o **ioOperation, timeout uint32) (err error) = GetQueuedCompletionStatus
 //sys setFileCompletionNotificationModes(h syscall.Handle, flags uint8) (err error) = SetFileCompletionNotificationModes
+//sys wsaGetOverlappedResult(h syscall.Handle, o *syscall.Overlapped, bytes *uint32, wait bool, flags *uint32) (err error) = ws2_32.WSAGetOverlappedResult

 type atomicBool int32

@@ -79,6 +80,7 @@ type win32File struct {
 	wg            sync.WaitGroup
 	wgLock        sync.RWMutex
 	closing       atomicBool
+	socket        bool
 	readDeadline  deadlineHandler
 	writeDeadline deadlineHandler
 }
@@ -109,7 +111,13 @@ func makeWin32File(h syscall.Handle) (*win32File, error) {
 }

 func MakeOpenFile(h syscall.Handle) (io.ReadWriteCloser, error) {
-	return makeWin32File(h)
+	// If we return the result of makeWin32File directly, it can result in an
+	// interface-wrapped nil, rather than a nil interface value.
+	f, err := makeWin32File(h)
+	if err != nil {
+		return nil, err
+	}
+	return f, nil
 }

 // closeHandle closes the resources associated with a Win32 handle
@@ -190,6 +198,10 @@ func (f *win32File) asyncIo(c *ioOperation, d *deadlineHandler, bytes uint32, er
 			if f.closing.isSet() {
 				err = ErrFileClosed
 			}
+		} else if err != nil && f.socket {
+			// err is from Win32. Query the overlapped structure to get the winsock error.
+			var bytes, flags uint32
+			err = wsaGetOverlappedResult(f.handle, &c.o, &bytes, false, &flags)
 		}
 	case <-timeout:
 		cancelIoEx(f.handle, &c.o)
@@ -265,6 +277,10 @@ func (f *win32File) Flush() error {
 	return syscall.FlushFileBuffers(f.handle)
 }

+func (f *win32File) Fd() uintptr {
+	return uintptr(f.handle)
+}
+
 func (d *deadlineHandler) set(deadline time.Time) error {
 	d.setLock.Lock()
 	defer d.setLock.Unlock()
--- a/vendor/github.com/Microsoft/go-winio/fileinfo.go
+++ b/vendor/github.com/Microsoft/go-winio/fileinfo.go
@@ -20,7 +20,8 @@ const (
 // FileBasicInfo contains file access time and file attributes information.
 type FileBasicInfo struct {
 	CreationTime, LastAccessTime, LastWriteTime, ChangeTime syscall.Filetime
-	FileAttributes                                          uintptr // includes padding
+	FileAttributes                                          uint32
+	pad                                                     uint32 // padding
 }

 // GetFileBasicInfo retrieves times and attributes for a file.
--- a/vendor/github.com/Microsoft/go-winio/go.mod
+++ b/vendor/github.com/Microsoft/go-winio/go.mod
@@ -0,0 +1,9 @@
+module github.com/Microsoft/go-winio
+
+go 1.12
+
+require (
+	github.com/pkg/errors v0.8.1
+	github.com/sirupsen/logrus v1.4.1
+	golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b
+)
--- a/vendor/github.com/Microsoft/go-winio/go.sum
+++ b/vendor/github.com/Microsoft/go-winio/go.sum
@@ -0,0 +1,16 @@
+github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
+github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
+github.com/konsorten/go-windows-terminal-sequences v1.0.1 h1:mweAR1A6xJ3oS2pRaGiHgQ4OO8tzTaLawm8vnODuwDk=
+github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
+github.com/pkg/errors v0.8.1 h1:iURUrRGxPUNPdy5/HRSm+Yj6okJ6UtLINN0Q9M4+h3I=
+github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
+github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
+github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
+github.com/sirupsen/logrus v1.4.1 h1:GL2rEmy6nsikmW0r8opw9JIRScdMF5hA8cOYLH7In1k=
+github.com/sirupsen/logrus v1.4.1/go.mod h1:ni0Sbl8bgC9z8RoU9G6nDWqqs/fq4eDPysMBDgk/93Q=
+github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
+github.com/stretchr/testify v1.2.2 h1:bSDNvY7ZPG5RlJ8otE/7V6gMiyenm9RtJ7IUVIAoJ1w=
+github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
+golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
+golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b h1:ag/x1USPSsqHud38I9BAC88qdNLDHHtQ4mlgQIZPPNA=
+golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
--- a/vendor/github.com/Microsoft/go-winio/hvsock.go
+++ b/vendor/github.com/Microsoft/go-winio/hvsock.go
@@ -0,0 +1,305 @@
+package winio
+
+import (
+	"fmt"
+	"io"
+	"net"
+	"os"
+	"syscall"
+	"time"
+	"unsafe"
+
+	"github.com/Microsoft/go-winio/pkg/guid"
+)
+
+//sys bind(s syscall.Handle, name unsafe.Pointer, namelen int32) (err error) [failretval==socketError] = ws2_32.bind
+
+const (
+	afHvSock = 34 // AF_HYPERV
+
+	socketError = ^uintptr(0)
+)
+
+// An HvsockAddr is an address for a AF_HYPERV socket.
+type HvsockAddr struct {
+	VMID      guid.GUID
+	ServiceID guid.GUID
+}
+
+type rawHvsockAddr struct {
+	Family    uint16
+	_         uint16
+	VMID      guid.GUID
+	ServiceID guid.GUID
+}
+
+// Network returns the address's network name, "hvsock".
+func (addr *HvsockAddr) Network() string {
+	return "hvsock"
+}
+
+func (addr *HvsockAddr) String() string {
+	return fmt.Sprintf("%s:%s", &addr.VMID, &addr.ServiceID)
+}
+
+// VsockServiceID returns an hvsock service ID corresponding to the specified AF_VSOCK port.
+func VsockServiceID(port uint32) guid.GUID {
+	g, _ := guid.FromString("00000000-facb-11e6-bd58-64006a7986d3")
+	g.Data1 = port
+	return g
+}
+
+func (addr *HvsockAddr) raw() rawHvsockAddr {
+	return rawHvsockAddr{
+		Family:    afHvSock,
+		VMID:      addr.VMID,
+		ServiceID: addr.ServiceID,
+	}
+}
+
+func (addr *HvsockAddr) fromRaw(raw *rawHvsockAddr) {
+	addr.VMID = raw.VMID
+	addr.ServiceID = raw.ServiceID
+}
+
+// HvsockListener is a socket listener for the AF_HYPERV address family.
+type HvsockListener struct {
+	sock *win32File
+	addr HvsockAddr
+}
+
+// HvsockConn is a connected socket of the AF_HYPERV address family.
+type HvsockConn struct {
+	sock          *win32File
+	local, remote HvsockAddr
+}
+
+func newHvSocket() (*win32File, error) {
+	fd, err := syscall.Socket(afHvSock, syscall.SOCK_STREAM, 1)
+	if err != nil {
+		return nil, os.NewSyscallError("socket", err)
+	}
+	f, err := makeWin32File(fd)
+	if err != nil {
+		syscall.Close(fd)
+		return nil, err
+	}
+	f.socket = true
+	return f, nil
+}
+
+// ListenHvsock listens for connections on the specified hvsock address.
+func ListenHvsock(addr *HvsockAddr) (_ *HvsockListener, err error) {
+	l := &HvsockListener{addr: *addr}
+	sock, err := newHvSocket()
+	if err != nil {
+		return nil, l.opErr("listen", err)
+	}
+	sa := addr.raw()
+	err = bind(sock.handle, unsafe.Pointer(&sa), int32(unsafe.Sizeof(sa)))
+	if err != nil {
+		return nil, l.opErr("listen", os.NewSyscallError("socket", err))
+	}
+	err = syscall.Listen(sock.handle, 16)
+	if err != nil {
+		return nil, l.opErr("listen", os.NewSyscallError("listen", err))
+	}
+	return &HvsockListener{sock: sock, addr: *addr}, nil
+}
+
+func (l *HvsockListener) opErr(op string, err error) error {
+	return &net.OpError{Op: op, Net: "hvsock", Addr: &l.addr, Err: err}
+}
+
+// Addr returns the listener's network address.
+func (l *HvsockListener) Addr() net.Addr {
+	return &l.addr
+}
+
+// Accept waits for the next connection and returns it.
+func (l *HvsockListener) Accept() (_ net.Conn, err error) {
+	sock, err := newHvSocket()
+	if err != nil {
+		return nil, l.opErr("accept", err)
+	}
+	defer func() {
+		if sock != nil {
+			sock.Close()
+		}
+	}()
+	c, err := l.sock.prepareIo()
+	if err != nil {
+		return nil, l.opErr("accept", err)
+	}
+	defer l.sock.wg.Done()
+
+	// AcceptEx, per documentation, requires an extra 16 bytes per address.
+	const addrlen = uint32(16 + unsafe.Sizeof(rawHvsockAddr{}))
+	var addrbuf [addrlen * 2]byte
+
+	var bytes uint32
+	err = syscall.AcceptEx(l.sock.handle, sock.handle, &addrbuf[0], 0, addrlen, addrlen, &bytes, &c.o)
+	_, err = l.sock.asyncIo(c, nil, bytes, err)
+	if err != nil {
+		return nil, l.opErr("accept", os.NewSyscallError("acceptex", err))
+	}
+	conn := &HvsockConn{
+		sock: sock,
+	}
+	conn.local.fromRaw((*rawHvsockAddr)(unsafe.Pointer(&addrbuf[0])))
+	conn.remote.fromRaw((*rawHvsockAddr)(unsafe.Pointer(&addrbuf[addrlen])))
+	sock = nil
+	return conn, nil
+}
+
+// Close closes the listener, causing any pending Accept calls to fail.
+func (l *HvsockListener) Close() error {
+	return l.sock.Close()
+}
+
+/* Need to finish ConnectEx handling
+func DialHvsock(ctx context.Context, addr *HvsockAddr) (*HvsockConn, error) {
+	sock, err := newHvSocket()
+	if err != nil {
+		return nil, err
+	}
+	defer func() {
+		if sock != nil {
+			sock.Close()
+		}
+	}()
+	c, err := sock.prepareIo()
+	if err != nil {
+		return nil, err
+	}
+	defer sock.wg.Done()
+	var bytes uint32
+	err = windows.ConnectEx(windows.Handle(sock.handle), sa, nil, 0, &bytes, &c.o)
+	_, err = sock.asyncIo(ctx, c, nil, bytes, err)
+	if err != nil {
+		return nil, err
+	}
+	conn := &HvsockConn{
+		sock:   sock,
+		remote: *addr,
+	}
+	sock = nil
+	return conn, nil
+}
+*/
+
+func (conn *HvsockConn) opErr(op string, err error) error {
+	return &net.OpError{Op: op, Net: "hvsock", Source: &conn.local, Addr: &conn.remote, Err: err}
+}
+
+func (conn *HvsockConn) Read(b []byte) (int, error) {
+	c, err := conn.sock.prepareIo()
+	if err != nil {
+		return 0, conn.opErr("read", err)
+	}
+	defer conn.sock.wg.Done()
+	buf := syscall.WSABuf{Buf: &b[0], Len: uint32(len(b))}
+	var flags, bytes uint32
+	err = syscall.WSARecv(conn.sock.handle, &buf, 1, &bytes, &flags, &c.o, nil)
+	n, err := conn.sock.asyncIo(c, &conn.sock.readDeadline, bytes, err)
+	if err != nil {
+		if _, ok := err.(syscall.Errno); ok {
+			err = os.NewSyscallError("wsarecv", err)
+		}
+		return 0, conn.opErr("read", err)
+	} else if n == 0 {
+		err = io.EOF
+	}
+	return n, err
+}
+
+func (conn *HvsockConn) Write(b []byte) (int, error) {
+	t := 0
+	for len(b) != 0 {
+		n, err := conn.write(b)
+		if err != nil {
+			return t + n, err
+		}
+		t += n
+		b = b[n:]
+	}
+	return t, nil
+}
+
+func (conn *HvsockConn) write(b []byte) (int, error) {
+	c, err := conn.sock.prepareIo()
+	if err != nil {
+		return 0, conn.opErr("write", err)
+	}
+	defer conn.sock.wg.Done()
+	buf := syscall.WSABuf{Buf: &b[0], Len: uint32(len(b))}
+	var bytes uint32
+	err = syscall.WSASend(conn.sock.handle, &buf, 1, &bytes, 0, &c.o, nil)
+	n, err := conn.sock.asyncIo(c, &conn.sock.writeDeadline, bytes, err)
+	if err != nil {
+		if _, ok := err.(syscall.Errno); ok {
+			err = os.NewSyscallError("wsasend", err)
+		}
+		return 0, conn.opErr("write", err)
+	}
+	return n, err
+}
+
+// Close closes the socket connection, failing any pending read or write calls.
+func (conn *HvsockConn) Close() error {
+	return conn.sock.Close()
+}
+
+func (conn *HvsockConn) shutdown(how int) error {
+	err := syscall.Shutdown(conn.sock.handle, syscall.SHUT_RD)
+	if err != nil {
+		return os.NewSyscallError("shutdown", err)
+	}
+	return nil
+}
+
+// CloseRead shuts down the read end of the socket.
+func (conn *HvsockConn) CloseRead() error {
+	err := conn.shutdown(syscall.SHUT_RD)
+	if err != nil {
+		return conn.opErr("close", err)
+	}
+	return nil
+}
+
+// CloseWrite shuts down the write end of the socket, notifying the other endpoint that
+// no more data will be written.
+func (conn *HvsockConn) CloseWrite() error {
+	err := conn.shutdown(syscall.SHUT_WR)
+	if err != nil {
+		return conn.opErr("close", err)
+	}
+	return nil
+}
+
+// LocalAddr returns the local address of the connection.
+func (conn *HvsockConn) LocalAddr() net.Addr {
+	return &conn.local
+}
+
+// RemoteAddr returns the remote address of the connection.
+func (conn *HvsockConn) RemoteAddr() net.Addr {
+	return &conn.remote
+}
+
+// SetDeadline implements the net.Conn SetDeadline method.
+func (conn *HvsockConn) SetDeadline(t time.Time) error {
+	conn.SetReadDeadline(t)
+	conn.SetWriteDeadline(t)
+	return nil
+}
+
+// SetReadDeadline implements the net.Conn SetReadDeadline method.
+func (conn *HvsockConn) SetReadDeadline(t time.Time) error {
+	return conn.sock.SetReadDeadline(t)
+}
+
+// SetWriteDeadline implements the net.Conn SetWriteDeadline method.
+func (conn *HvsockConn) SetWriteDeadline(t time.Time) error {
+	return conn.sock.SetWriteDeadline(t)
+}
--- a/vendor/github.com/Microsoft/go-winio/pipe.go
+++ b/vendor/github.com/Microsoft/go-winio/pipe.go
@@ -3,10 +3,13 @@
 package winio

 import (
+	"context"
 	"errors"
+	"fmt"
 	"io"
 	"net"
 	"os"
+	"runtime"
 	"syscall"
 	"time"
 	"unsafe"
@@ -15,10 +18,51 @@ import (
 //sys connectNamedPipe(pipe syscall.Handle, o *syscall.Overlapped) (err error) = ConnectNamedPipe
 //sys createNamedPipe(name string, flags uint32, pipeMode uint32, maxInstances uint32, outSize uint32, inSize uint32, defaultTimeout uint32, sa *syscall.SecurityAttributes) (handle syscall.Handle, err error)  [failretval==syscall.InvalidHandle] = CreateNamedPipeW
 //sys createFile(name string, access uint32, mode uint32, sa *syscall.SecurityAttributes, createmode uint32, attrs uint32, templatefile syscall.Handle) (handle syscall.Handle, err error) [failretval==syscall.InvalidHandle] = CreateFileW
-//sys waitNamedPipe(name string, timeout uint32) (err error) = WaitNamedPipeW
 //sys getNamedPipeInfo(pipe syscall.Handle, flags *uint32, outSize *uint32, inSize *uint32, maxInstances *uint32) (err error) = GetNamedPipeInfo
 //sys getNamedPipeHandleState(pipe syscall.Handle, state *uint32, curInstances *uint32, maxCollectionCount *uint32, collectDataTimeout *uint32, userName *uint16, maxUserNameSize uint32) (err error) = GetNamedPipeHandleStateW
 //sys localAlloc(uFlags uint32, length uint32) (ptr uintptr) = LocalAlloc
+//sys ntCreateNamedPipeFile(pipe *syscall.Handle, access uint32, oa *objectAttributes, iosb *ioStatusBlock, share uint32, disposition uint32, options uint32, typ uint32, readMode uint32, completionMode uint32, maxInstances uint32, inboundQuota uint32, outputQuota uint32, timeout *int64) (status ntstatus) = ntdll.NtCreateNamedPipeFile
+//sys rtlNtStatusToDosError(status ntstatus) (winerr error) = ntdll.RtlNtStatusToDosErrorNoTeb
+//sys rtlDosPathNameToNtPathName(name *uint16, ntName *unicodeString, filePart uintptr, reserved uintptr) (status ntstatus) = ntdll.RtlDosPathNameToNtPathName_U
+//sys rtlDefaultNpAcl(dacl *uintptr) (status ntstatus) = ntdll.RtlDefaultNpAcl
+
+type ioStatusBlock struct {
+	Status, Information uintptr
+}
+
+type objectAttributes struct {
+	Length             uintptr
+	RootDirectory      uintptr
+	ObjectName         *unicodeString
+	Attributes         uintptr
+	SecurityDescriptor *securityDescriptor
+	SecurityQoS        uintptr
+}
+
+type unicodeString struct {
+	Length        uint16
+	MaximumLength uint16
+	Buffer        uintptr
+}
+
+type securityDescriptor struct {
+	Revision byte
+	Sbz1     byte
+	Control  uint16
+	Owner    uintptr
+	Group    uintptr
+	Sacl     uintptr
+	Dacl     uintptr
+}
+
+type ntstatus int32
+
+func (status ntstatus) Err() error {
+	if status >= 0 {
+		return nil
+	}
+	return rtlNtStatusToDosError(status)
+}

 const (
 	cERROR_PIPE_BUSY      = syscall.Errno(231)
@@ -26,21 +70,20 @@ const (
 	cERROR_PIPE_CONNECTED = syscall.Errno(535)
 	cERROR_SEM_TIMEOUT    = syscall.Errno(121)

-	cPIPE_ACCESS_DUPLEX            = 0x3
-	cFILE_FLAG_FIRST_PIPE_INSTANCE = 0x80000
 	cSECURITY_SQOS_PRESENT = 0x100000
 	cSECURITY_ANONYMOUS    = 0

-	cPIPE_REJECT_REMOTE_CLIENTS = 0x8
-
-	cPIPE_UNLIMITED_INSTANCES = 255
-
-	cNMPWAIT_USE_DEFAULT_WAIT = 0
-	cNMPWAIT_NOWAIT           = 1
-
 	cPIPE_TYPE_MESSAGE = 4

 	cPIPE_READMODE_MESSAGE = 2
+
+	cFILE_OPEN   = 1
+	cFILE_CREATE = 2
+
+	cFILE_PIPE_MESSAGE_TYPE          = 1
+	cFILE_PIPE_REJECT_REMOTE_CLIENTS = 2
+
+	cSE_DACL_PRESENT = 4
 )

 var (
@@ -121,6 +164,11 @@ func (f *win32MessageBytePipe) Read(b []byte) (int, error) {
 		// zero-byte message, ensure that all future Read() calls
 		// also return EOF.
 		f.readEOF = true
+	} else if err == syscall.ERROR_MORE_DATA {
+		// ERROR_MORE_DATA indicates that the pipe's read mode is message mode
+		// and the message still has more bytes. Treat this as a success, since
+		// this package presents all named pipes as byte streams.
+		err = nil
 	}
 	return n, err
 }
@@ -133,40 +181,53 @@ func (s pipeAddress) String() string {
 	return string(s)
 }

+// tryDialPipe attempts to dial the pipe at `path` until `ctx` cancellation or timeout.
+func tryDialPipe(ctx context.Context, path *string) (syscall.Handle, error) {
+	for {
+		select {
+		case <-ctx.Done():
+			return syscall.Handle(0), ctx.Err()
+		default:
+			h, err := createFile(*path, syscall.GENERIC_READ|syscall.GENERIC_WRITE, 0, nil, syscall.OPEN_EXISTING, syscall.FILE_FLAG_OVERLAPPED|cSECURITY_SQOS_PRESENT|cSECURITY_ANONYMOUS, 0)
+			if err == nil {
+				return h, nil
+			}
+			if err != cERROR_PIPE_BUSY {
+				return h, &os.PathError{Err: err, Op: "open", Path: *path}
+			}
+			// Wait 10 msec and try again. This is a rather simplistic
+			// view, as we always try each 10 milliseconds.
+			time.Sleep(time.Millisecond * 10)
+		}
+	}
+}
+
 // DialPipe connects to a named pipe by path, timing out if the connection
-// takes longer than the specified duration. If timeout is nil, then the timeout
-// is the default timeout established by the pipe server.
+// takes longer than the specified duration. If timeout is nil, then we use
+// a default timeout of 2 seconds.  (We do not use WaitNamedPipe.)
 func DialPipe(path string, timeout *time.Duration) (net.Conn, error) {
 	var absTimeout time.Time
 	if timeout != nil {
 		absTimeout = time.Now().Add(*timeout)
-	}
-	var err error
-	var h syscall.Handle
-	for {
-		h, err = createFile(path, syscall.GENERIC_READ|syscall.GENERIC_WRITE, 0, nil, syscall.OPEN_EXISTING, syscall.FILE_FLAG_OVERLAPPED|cSECURITY_SQOS_PRESENT|cSECURITY_ANONYMOUS, 0)
-		if err != cERROR_PIPE_BUSY {
-			break
-		}
-		now := time.Now()
-		var ms uint32
-		if absTimeout.IsZero() {
-			ms = cNMPWAIT_USE_DEFAULT_WAIT
-		} else if now.After(absTimeout) {
-			ms = cNMPWAIT_NOWAIT
 	} else {
-			ms = uint32(absTimeout.Sub(now).Nanoseconds() / 1000 / 1000)
+		absTimeout = time.Now().Add(time.Second * 2)
 	}
-		err = waitNamedPipe(path, ms)
-		if err != nil {
-			if err == cERROR_SEM_TIMEOUT {
+	ctx, _ := context.WithDeadline(context.Background(), absTimeout)
+	conn, err := DialPipeContext(ctx, path)
+	if err == context.DeadlineExceeded {
 		return nil, ErrTimeout
 	}
-			break
-		}
+	return conn, err
 }
+
+// DialPipeContext attempts to connect to a named pipe by `path` until `ctx`
+// cancellation or timeout.
+func DialPipeContext(ctx context.Context, path string) (net.Conn, error) {
+	var err error
+	var h syscall.Handle
+	h, err = tryDialPipe(ctx, &path)
 	if err != nil {
-		return nil, &os.PathError{Op: "open", Path: path, Err: err}
+		return nil, err
 	}

 	var flags uint32
@@ -175,16 +236,6 @@ func DialPipe(path string, timeout *time.Duration) (net.Conn, error) {
 		return nil, err
 	}

-	var state uint32
-	err = getNamedPipeHandleState(h, &state, nil, nil, nil, nil, 0)
-	if err != nil {
-		return nil, err
-	}
-
-	if state&cPIPE_READMODE_MESSAGE != 0 {
-		return nil, &os.PathError{Op: "open", Path: path, Err: errors.New("message readmode pipes not supported")}
-	}
-
 	f, err := makeWin32File(h)
 	if err != nil {
 		syscall.Close(h)
@@ -209,41 +260,85 @@ type acceptResponse struct {
 type win32PipeListener struct {
 	firstHandle syscall.Handle
 	path        string
-	securityDescriptor []byte
 	config      PipeConfig
 	acceptCh    chan (chan acceptResponse)
 	closeCh     chan int
 	doneCh      chan int
 }

-func makeServerPipeHandle(path string, securityDescriptor []byte, c *PipeConfig, first bool) (syscall.Handle, error) {
-	var flags uint32 = cPIPE_ACCESS_DUPLEX | syscall.FILE_FLAG_OVERLAPPED
-	if first {
-		flags |= cFILE_FLAG_FIRST_PIPE_INSTANCE
-	}
-
-	var mode uint32 = cPIPE_REJECT_REMOTE_CLIENTS
-	if c.MessageMode {
-		mode |= cPIPE_TYPE_MESSAGE
-	}
-
-	sa := &syscall.SecurityAttributes{}
-	sa.Length = uint32(unsafe.Sizeof(*sa))
-	if securityDescriptor != nil {
-		len := uint32(len(securityDescriptor))
-		sa.SecurityDescriptor = localAlloc(0, len)
-		defer localFree(sa.SecurityDescriptor)
-		copy((*[0xffff]byte)(unsafe.Pointer(sa.SecurityDescriptor))[:], securityDescriptor)
-	}
-	h, err := createNamedPipe(path, flags, mode, cPIPE_UNLIMITED_INSTANCES, uint32(c.OutputBufferSize), uint32(c.InputBufferSize), 0, sa)
+func makeServerPipeHandle(path string, sd []byte, c *PipeConfig, first bool) (syscall.Handle, error) {
+	path16, err := syscall.UTF16FromString(path)
 	if err != nil {
 		return 0, &os.PathError{Op: "open", Path: path, Err: err}
 	}
+
+	var oa objectAttributes
+	oa.Length = unsafe.Sizeof(oa)
+
+	var ntPath unicodeString
+	if err := rtlDosPathNameToNtPathName(&path16[0], &ntPath, 0, 0).Err(); err != nil {
+		return 0, &os.PathError{Op: "open", Path: path, Err: err}
+	}
+	defer localFree(ntPath.Buffer)
+	oa.ObjectName = &ntPath
+
+	// The security descriptor is only needed for the first pipe.
+	if first {
+		if sd != nil {
+			len := uint32(len(sd))
+			sdb := localAlloc(0, len)
+			defer localFree(sdb)
+			copy((*[0xffff]byte)(unsafe.Pointer(sdb))[:], sd)
+			oa.SecurityDescriptor = (*securityDescriptor)(unsafe.Pointer(sdb))
+		} else {
+			// Construct the default named pipe security descriptor.
+			var dacl uintptr
+			if err := rtlDefaultNpAcl(&dacl).Err(); err != nil {
+				return 0, fmt.Errorf("getting default named pipe ACL: %s", err)
+			}
+			defer localFree(dacl)
+
+			sdb := &securityDescriptor{
+				Revision: 1,
+				Control:  cSE_DACL_PRESENT,
+				Dacl:     dacl,
+			}
+			oa.SecurityDescriptor = sdb
+		}
+	}
+
+	typ := uint32(cFILE_PIPE_REJECT_REMOTE_CLIENTS)
+	if c.MessageMode {
+		typ |= cFILE_PIPE_MESSAGE_TYPE
+	}
+
+	disposition := uint32(cFILE_OPEN)
+	access := uint32(syscall.GENERIC_READ | syscall.GENERIC_WRITE | syscall.SYNCHRONIZE)
+	if first {
+		disposition = cFILE_CREATE
+		// By not asking for read or write access, the named pipe file system
+		// will put this pipe into an initially disconnected state, blocking
+		// client connections until the next call with first == false.
+		access = syscall.SYNCHRONIZE
+	}
+
+	timeout := int64(-50 * 10000) // 50ms
+
+	var (
+		h    syscall.Handle
+		iosb ioStatusBlock
+	)
+	err = ntCreateNamedPipeFile(&h, access, &oa, &iosb, syscall.FILE_SHARE_READ|syscall.FILE_SHARE_WRITE, disposition, 0, typ, 0, 0, 0xffffffff, uint32(c.InputBufferSize), uint32(c.OutputBufferSize), &timeout).Err()
+	if err != nil {
+		return 0, &os.PathError{Op: "open", Path: path, Err: err}
+	}
+
+	runtime.KeepAlive(ntPath)
 	return h, nil
 }

 func (l *win32PipeListener) makeServerPipe() (*win32File, error) {
-	h, err := makeServerPipeHandle(l.path, l.securityDescriptor, &l.config, false)
+	h, err := makeServerPipeHandle(l.path, nil, &l.config, false)
 	if err != nil {
 		return nil, err
 	}
@@ -354,18 +449,9 @@ func ListenPipe(path string, c *PipeConfig) (net.Listener, error) {
 	if err != nil {
 		return nil, err
 	}
-	// Immediately open and then close a client handle so that the named pipe is
-	// created but not currently accepting connections.
-	h2, err := createFile(path, 0, 0, nil, syscall.OPEN_EXISTING, cSECURITY_SQOS_PRESENT|cSECURITY_ANONYMOUS, 0)
-	if err != nil {
-		syscall.Close(h)
-		return nil, err
-	}
-	syscall.Close(h2)
 	l := &win32PipeListener{
 		firstHandle: h,
 		path:        path,
-		securityDescriptor: sd,
 		config:      *c,
 		acceptCh:    make(chan (chan acceptResponse)),
 		closeCh:     make(chan int),
--- a/vendor/github.com/Microsoft/go-winio/pkg/guid/guid.go
+++ b/vendor/github.com/Microsoft/go-winio/pkg/guid/guid.go
@@ -0,0 +1,235 @@
+// Package guid provides a GUID type. The backing structure for a GUID is
+// identical to that used by the golang.org/x/sys/windows GUID type.
+// There are two main binary encodings used for a GUID, the big-endian encoding,
+// and the Windows (mixed-endian) encoding. See here for details:
+// https://en.wikipedia.org/wiki/Universally_unique_identifier#Encoding
+package guid
+
+import (
+	"crypto/rand"
+	"crypto/sha1"
+	"encoding"
+	"encoding/binary"
+	"fmt"
+	"strconv"
+
+	"golang.org/x/sys/windows"
+)
+
+// Variant specifies which GUID variant (or "type") of the GUID. It determines
+// how the entirety of the rest of the GUID is interpreted.
+type Variant uint8
+
+// The variants specified by RFC 4122.
+const (
+	// VariantUnknown specifies a GUID variant which does not conform to one of
+	// the variant encodings specified in RFC 4122.
+	VariantUnknown Variant = iota
+	VariantNCS
+	VariantRFC4122
+	VariantMicrosoft
+	VariantFuture
+)
+
+// Version specifies how the bits in the GUID were generated. For instance, a
+// version 4 GUID is randomly generated, and a version 5 is generated from the
+// hash of an input string.
+type Version uint8
+
+var _ = (encoding.TextMarshaler)(GUID{})
+var _ = (encoding.TextUnmarshaler)(&GUID{})
+
+// GUID represents a GUID/UUID. It has the same structure as
+// golang.org/x/sys/windows.GUID so that it can be used with functions expecting
+// that type. It is defined as its own type so that stringification and
+// marshaling can be supported. The representation matches that used by native
+// Windows code.
+type GUID windows.GUID
+
+// NewV4 returns a new version 4 (pseudorandom) GUID, as defined by RFC 4122.
+func NewV4() (GUID, error) {
+	var b [16]byte
+	if _, err := rand.Read(b[:]); err != nil {
+		return GUID{}, err
+	}
+
+	g := FromArray(b)
+	g.setVersion(4) // Version 4 means randomly generated.
+	g.setVariant(VariantRFC4122)
+
+	return g, nil
+}
+
+// NewV5 returns a new version 5 (generated from a string via SHA-1 hashing)
+// GUID, as defined by RFC 4122. The RFC is unclear on the encoding of the name,
+// and the sample code treats it as a series of bytes, so we do the same here.
+//
+// Some implementations, such as those found on Windows, treat the name as a
+// big-endian UTF16 stream of bytes. If that is desired, the string can be
+// encoded as such before being passed to this function.
+func NewV5(namespace GUID, name []byte) (GUID, error) {
+	b := sha1.New()
+	namespaceBytes := namespace.ToArray()
+	b.Write(namespaceBytes[:])
+	b.Write(name)
+
+	a := [16]byte{}
+	copy(a[:], b.Sum(nil))
+
+	g := FromArray(a)
+	g.setVersion(5) // Version 5 means generated from a string.
+	g.setVariant(VariantRFC4122)
+
+	return g, nil
+}
+
+func fromArray(b [16]byte, order binary.ByteOrder) GUID {
+	var g GUID
+	g.Data1 = order.Uint32(b[0:4])
+	g.Data2 = order.Uint16(b[4:6])
+	g.Data3 = order.Uint16(b[6:8])
+	copy(g.Data4[:], b[8:16])
+	return g
+}
+
+func (g GUID) toArray(order binary.ByteOrder) [16]byte {
+	b := [16]byte{}
+	order.PutUint32(b[0:4], g.Data1)
+	order.PutUint16(b[4:6], g.Data2)
+	order.PutUint16(b[6:8], g.Data3)
+	copy(b[8:16], g.Data4[:])
+	return b
+}
+
+// FromArray constructs a GUID from a big-endian encoding array of 16 bytes.
+func FromArray(b [16]byte) GUID {
+	return fromArray(b, binary.BigEndian)
+}
+
+// ToArray returns an array of 16 bytes representing the GUID in big-endian
+// encoding.
+func (g GUID) ToArray() [16]byte {
+	return g.toArray(binary.BigEndian)
+}
+
+// FromWindowsArray constructs a GUID from a Windows encoding array of bytes.
+func FromWindowsArray(b [16]byte) GUID {
+	return fromArray(b, binary.LittleEndian)
+}
+
+// ToWindowsArray returns an array of 16 bytes representing the GUID in Windows
+// encoding.
+func (g GUID) ToWindowsArray() [16]byte {
+	return g.toArray(binary.LittleEndian)
+}
+
+func (g GUID) String() string {
+	return fmt.Sprintf(
+		"%08x-%04x-%04x-%04x-%012x",
+		g.Data1,
+		g.Data2,
+		g.Data3,
+		g.Data4[:2],
+		g.Data4[2:])
+}
+
+// FromString parses a string containing a GUID and returns the GUID. The only
+// format currently supported is the `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`
+// format.
+func FromString(s string) (GUID, error) {
+	if len(s) != 36 {
+		return GUID{}, fmt.Errorf("invalid GUID %q", s)
+	}
+	if s[8] != '-' || s[13] != '-' || s[18] != '-' || s[23] != '-' {
+		return GUID{}, fmt.Errorf("invalid GUID %q", s)
+	}
+
+	var g GUID
+
+	data1, err := strconv.ParseUint(s[0:8], 16, 32)
+	if err != nil {
+		return GUID{}, fmt.Errorf("invalid GUID %q", s)
+	}
+	g.Data1 = uint32(data1)
+
+	data2, err := strconv.ParseUint(s[9:13], 16, 16)
+	if err != nil {
+		return GUID{}, fmt.Errorf("invalid GUID %q", s)
+	}
+	g.Data2 = uint16(data2)
+
+	data3, err := strconv.ParseUint(s[14:18], 16, 16)
+	if err != nil {
+		return GUID{}, fmt.Errorf("invalid GUID %q", s)
+	}
+	g.Data3 = uint16(data3)
+
+	for i, x := range []int{19, 21, 24, 26, 28, 30, 32, 34} {
+		v, err := strconv.ParseUint(s[x:x+2], 16, 8)
+		if err != nil {
+			return GUID{}, fmt.Errorf("invalid GUID %q", s)
+		}
+		g.Data4[i] = uint8(v)
+	}
+
+	return g, nil
+}
+
+func (g *GUID) setVariant(v Variant) {
+	d := g.Data4[0]
+	switch v {
+	case VariantNCS:
+		d = (d & 0x7f)
+	case VariantRFC4122:
+		d = (d & 0x3f) | 0x80
+	case VariantMicrosoft:
+		d = (d & 0x1f) | 0xc0
+	case VariantFuture:
+		d = (d & 0x0f) | 0xe0
+	case VariantUnknown:
+		fallthrough
+	default:
+		panic(fmt.Sprintf("invalid variant: %d", v))
+	}
+	g.Data4[0] = d
+}
+
+// Variant returns the GUID variant, as defined in RFC 4122.
+func (g GUID) Variant() Variant {
+	b := g.Data4[0]
+	if b&0x80 == 0 {
+		return VariantNCS
+	} else if b&0xc0 == 0x80 {
+		return VariantRFC4122
+	} else if b&0xe0 == 0xc0 {
+		return VariantMicrosoft
+	} else if b&0xe0 == 0xe0 {
+		return VariantFuture
+	}
+	return VariantUnknown
+}
+
+func (g *GUID) setVersion(v Version) {
+	g.Data3 = (g.Data3 & 0x0fff) | (uint16(v) << 12)
+}
+
+// Version returns the GUID version, as defined in RFC 4122.
+func (g GUID) Version() Version {
+	return Version((g.Data3 & 0xF000) >> 12)
+}
+
+// MarshalText returns the textual representation of the GUID.
+func (g GUID) MarshalText() ([]byte, error) {
+	return []byte(g.String()), nil
+}
+
+// UnmarshalText takes the textual representation of a GUID, and unmarhals it
+// into this GUID.
+func (g *GUID) UnmarshalText(text []byte) error {
+	g2, err := FromString(string(text))
+	if err != nil {
+		return err
+	}
+	*g = g2
+	return nil
+}
--- a/vendor/github.com/Microsoft/go-winio/syscall.go
+++ b/vendor/github.com/Microsoft/go-winio/syscall.go
@@ -1,3 +1,3 @@
 package winio

-//go:generate go run $GOROOT/src/syscall/mksyscall_windows.go -output zsyscall_windows.go file.go pipe.go sd.go fileinfo.go privilege.go backup.go
+//go:generate go run $GOROOT/src/syscall/mksyscall_windows.go -output zsyscall_windows.go file.go pipe.go sd.go fileinfo.go privilege.go backup.go hvsock.go
--- a/vendor/github.com/Microsoft/go-winio/zsyscall_windows.go
+++ b/vendor/github.com/Microsoft/go-winio/zsyscall_windows.go
@@ -1,4 +1,4 @@
-// MACHINE GENERATED BY 'go generate' COMMAND; DO NOT EDIT
+// Code generated by 'go generate'; DO NOT EDIT.

 package winio

@@ -38,19 +38,25 @@ func errnoErr(e syscall.Errno) error {

 var (
 	modkernel32 = windows.NewLazySystemDLL("kernel32.dll")
+	modws2_32   = windows.NewLazySystemDLL("ws2_32.dll")
+	modntdll    = windows.NewLazySystemDLL("ntdll.dll")
 	modadvapi32 = windows.NewLazySystemDLL("advapi32.dll")

 	procCancelIoEx                                           = modkernel32.NewProc("CancelIoEx")
 	procCreateIoCompletionPort                               = modkernel32.NewProc("CreateIoCompletionPort")
 	procGetQueuedCompletionStatus                            = modkernel32.NewProc("GetQueuedCompletionStatus")
 	procSetFileCompletionNotificationModes                   = modkernel32.NewProc("SetFileCompletionNotificationModes")
+	procWSAGetOverlappedResult                               = modws2_32.NewProc("WSAGetOverlappedResult")
 	procConnectNamedPipe                                     = modkernel32.NewProc("ConnectNamedPipe")
 	procCreateNamedPipeW                                     = modkernel32.NewProc("CreateNamedPipeW")
 	procCreateFileW                                          = modkernel32.NewProc("CreateFileW")
-	procWaitNamedPipeW                                       = modkernel32.NewProc("WaitNamedPipeW")
 	procGetNamedPipeInfo                                     = modkernel32.NewProc("GetNamedPipeInfo")
 	procGetNamedPipeHandleStateW                             = modkernel32.NewProc("GetNamedPipeHandleStateW")
 	procLocalAlloc                                           = modkernel32.NewProc("LocalAlloc")
+	procNtCreateNamedPipeFile                                = modntdll.NewProc("NtCreateNamedPipeFile")
+	procRtlNtStatusToDosErrorNoTeb                           = modntdll.NewProc("RtlNtStatusToDosErrorNoTeb")
+	procRtlDosPathNameToNtPathName_U                         = modntdll.NewProc("RtlDosPathNameToNtPathName_U")
+	procRtlDefaultNpAcl                                      = modntdll.NewProc("RtlDefaultNpAcl")
 	procLookupAccountNameW                                   = modadvapi32.NewProc("LookupAccountNameW")
 	procConvertSidToStringSidW                               = modadvapi32.NewProc("ConvertSidToStringSidW")
 	procConvertStringSecurityDescriptorToSecurityDescriptorW = modadvapi32.NewProc("ConvertStringSecurityDescriptorToSecurityDescriptorW")
@@ -69,6 +75,7 @@ var (
 	procLookupPrivilegeDisplayNameW                          = modadvapi32.NewProc("LookupPrivilegeDisplayNameW")
 	procBackupRead                                           = modkernel32.NewProc("BackupRead")
 	procBackupWrite                                          = modkernel32.NewProc("BackupWrite")
+	procbind                                                 = modws2_32.NewProc("bind")
 )

 func cancelIoEx(file syscall.Handle, o *syscall.Overlapped) (err error) {
@@ -120,6 +127,24 @@ func setFileCompletionNotificationModes(h syscall.Handle, flags uint8) (err erro
 	return
 }

+func wsaGetOverlappedResult(h syscall.Handle, o *syscall.Overlapped, bytes *uint32, wait bool, flags *uint32) (err error) {
+	var _p0 uint32
+	if wait {
+		_p0 = 1
+	} else {
+		_p0 = 0
+	}
+	r1, _, e1 := syscall.Syscall6(procWSAGetOverlappedResult.Addr(), 5, uintptr(h), uintptr(unsafe.Pointer(o)), uintptr(unsafe.Pointer(bytes)), uintptr(_p0), uintptr(unsafe.Pointer(flags)), 0)
+	if r1 == 0 {
+		if e1 != 0 {
+			err = errnoErr(e1)
+		} else {
+			err = syscall.EINVAL
+		}
+	}
+	return
+}
+
 func connectNamedPipe(pipe syscall.Handle, o *syscall.Overlapped) (err error) {
 	r1, _, e1 := syscall.Syscall(procConnectNamedPipe.Addr(), 2, uintptr(pipe), uintptr(unsafe.Pointer(o)), 0)
 	if r1 == 0 {
@@ -176,27 +201,6 @@ func _createFile(name *uint16, access uint32, mode uint32, sa *syscall.SecurityA
 	return
 }

-func waitNamedPipe(name string, timeout uint32) (err error) {
-	var _p0 *uint16
-	_p0, err = syscall.UTF16PtrFromString(name)
-	if err != nil {
-		return
-	}
-	return _waitNamedPipe(_p0, timeout)
-}
-
-func _waitNamedPipe(name *uint16, timeout uint32) (err error) {
-	r1, _, e1 := syscall.Syscall(procWaitNamedPipeW.Addr(), 2, uintptr(unsafe.Pointer(name)), uintptr(timeout), 0)
-	if r1 == 0 {
-		if e1 != 0 {
-			err = errnoErr(e1)
-		} else {
-			err = syscall.EINVAL
-		}
-	}
-	return
-}
-
 func getNamedPipeInfo(pipe syscall.Handle, flags *uint32, outSize *uint32, inSize *uint32, maxInstances *uint32) (err error) {
 	r1, _, e1 := syscall.Syscall6(procGetNamedPipeInfo.Addr(), 5, uintptr(pipe), uintptr(unsafe.Pointer(flags)), uintptr(unsafe.Pointer(outSize)), uintptr(unsafe.Pointer(inSize)), uintptr(unsafe.Pointer(maxInstances)), 0)
 	if r1 == 0 {
@@ -227,6 +231,32 @@ func localAlloc(uFlags uint32, length uint32) (ptr uintptr) {
 	return
 }

+func ntCreateNamedPipeFile(pipe *syscall.Handle, access uint32, oa *objectAttributes, iosb *ioStatusBlock, share uint32, disposition uint32, options uint32, typ uint32, readMode uint32, completionMode uint32, maxInstances uint32, inboundQuota uint32, outputQuota uint32, timeout *int64) (status ntstatus) {
+	r0, _, _ := syscall.Syscall15(procNtCreateNamedPipeFile.Addr(), 14, uintptr(unsafe.Pointer(pipe)), uintptr(access), uintptr(unsafe.Pointer(oa)), uintptr(unsafe.Pointer(iosb)), uintptr(share), uintptr(disposition), uintptr(options), uintptr(typ), uintptr(readMode), uintptr(completionMode), uintptr(maxInstances), uintptr(inboundQuota), uintptr(outputQuota), uintptr(unsafe.Pointer(timeout)), 0)
+	status = ntstatus(r0)
+	return
+}
+
+func rtlNtStatusToDosError(status ntstatus) (winerr error) {
+	r0, _, _ := syscall.Syscall(procRtlNtStatusToDosErrorNoTeb.Addr(), 1, uintptr(status), 0, 0)
+	if r0 != 0 {
+		winerr = syscall.Errno(r0)
+	}
+	return
+}
+
+func rtlDosPathNameToNtPathName(name *uint16, ntName *unicodeString, filePart uintptr, reserved uintptr) (status ntstatus) {
+	r0, _, _ := syscall.Syscall6(procRtlDosPathNameToNtPathName_U.Addr(), 4, uintptr(unsafe.Pointer(name)), uintptr(unsafe.Pointer(ntName)), uintptr(filePart), uintptr(reserved), 0, 0)
+	status = ntstatus(r0)
+	return
+}
+
+func rtlDefaultNpAcl(dacl *uintptr) (status ntstatus) {
+	r0, _, _ := syscall.Syscall(procRtlDefaultNpAcl.Addr(), 1, uintptr(unsafe.Pointer(dacl)), 0, 0)
+	status = ntstatus(r0)
+	return
+}
+
 func lookupAccountName(systemName *uint16, accountName string, sid *byte, sidSize *uint32, refDomain *uint16, refDomainSize *uint32, sidNameUse *uint32) (err error) {
 	var _p0 *uint16
 	_p0, err = syscall.UTF16PtrFromString(accountName)
@@ -518,3 +548,15 @@ func backupWrite(h syscall.Handle, b []byte, bytesWritten *uint32, abort bool, p
 	}
 	return
 }
+
+func bind(s syscall.Handle, name unsafe.Pointer, namelen int32) (err error) {
+	r1, _, e1 := syscall.Syscall(procbind.Addr(), 3, uintptr(s), uintptr(name), uintptr(namelen))
+	if r1 == socketError {
+		if e1 != 0 {
+			err = errnoErr(e1)
+		} else {
+			err = syscall.EINVAL
+		}
+	}
+	return
+}
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Justin McCarthy	7b75522ee0	increment patch for release (via Makefile)	2021-05-17 11:07:12 -07:00
Justin McCarthy	ccb78ddfbd	dependency fix for homebrew tap	2021-05-17 10:56:43 -07:00
Ulderico Cirello	efb59fd233	tidy go.sum	2021-03-10 12:18:46 -08:00
Phillip Markert	4370d2292c	YAML front-matter delimiter support #91 (#92 )	2020-09-14 15:20:10 -07:00
Justin McCarthy	dbe49a09b3	increment patch for release (via Makefile)	2020-09-14 13:45:15 -07:00
Justin McCarthy	73bebe0202	go.mod: go mod vendor Addresses #94	2020-09-14 13:44:19 -07:00
Justin McCarthy	f5f7c08b73	increment minor for release (via Makefile)	2020-09-14 12:01:37 -07:00
Justin McCarthy	b2276f9e54	increment patch for release (via Makefile)	2020-09-14 11:54:47 -07:00
Justin McCarthy	f1b5bbeff9	manual version bump	2020-09-14 11:54:24 -07:00
Justin McCarthy	b7acb1eecf	increment patch for release (via Makefile)	2020-09-14 11:43:46 -07:00
Justin McCarthy	da8a574e86	increment patch for release (via Makefile)	2020-09-14 11:41:38 -07:00
Justin McCarthy	7468711b3b	go.mod: update gitlab dep to v0.30.1 Releases after github.com/xanzy/go-gitlab@v0.31.0 introduce breaking changes to the NewClient call. Addresses #94	2020-09-14 11:31:56 -07:00
Michael E. Gruen	8baf787ed7	Bug fixes (gitlab.go): pagination, labels (#84 )	2020-09-14 11:11:09 -07:00
Justin McCarthy	4c5c18964b	go.mod: update dependencies Addresses #94	2020-09-14 11:08:56 -07:00
U Cirello	c5a1bd804b	Merge pull request #65 from ucirello/master chore: migrate to go modules	2019-08-13 00:42:53 +02:00
Carlos C	c303b68201	chore: migrate to go modules	2019-07-14 13:51:10 -03:00
Paddy Byers	87e8266f1b	Allow github config to be passed in env (#62 )	2019-06-18 12:28:16 -04:00
Justin McCarthy	e8d6d536a8	doc enhancements	2019-03-16 00:28:08 -07:00
Justin McCarthy	ef7a4092a7	increment patch for release (via Makefile)	2019-03-16 00:21:09 -07:00
Justin McCarthy	9bcc88eebc	all interfaces	2019-03-16 00:21:01 -07:00
Justin McCarthy	edd3c7dd44	prep port exposure from docker	2019-03-16 00:20:46 -07:00
Justin McCarthy	25058359ea	increment minor for release (via Makefile)	2019-03-16 00:05:08 -07:00
Justin McCarthy	c4a0b7afff	do not refresh assets during release	2019-03-16 00:04:55 -07:00
Justin McCarthy	ef32942dad	Serve now provides an HTTP server, listening on port 4000 by default. Listen port can be set with the --port flag to the serve command. Websocket refresh remains intact.	2019-03-16 00:02:50 -07:00
Justin McCarthy	0c9dbd736b	slightly better description	2019-02-21 00:54:22 -08:00
Justin McCarthy	b98d179847	Dockerfile example	2019-02-20 22:51:41 -08:00
Justin McCarthy	435ac086c0	increment patch for release (via Makefile)	2018-12-17 14:52:27 -08:00
Justin McCarthy	0ddbb6cf52	automated asset refresh (via Makefile)	2018-12-17 14:52:19 -08:00
Justin McCarthy	3ebccc2811	Revert "automated asset refresh (via Makefile)" This reverts commit `24ff9dd762`.	2018-12-17 14:51:46 -08:00
Justin McCarthy	b39bec8108	do not auto-clobber from example	2018-12-17 14:51:07 -08:00
Justin McCarthy	c699c64627	increment patch for release (via Makefile)	2018-12-17 14:43:58 -08:00
Justin McCarthy	24ff9dd762	automated asset refresh (via Makefile)	2018-12-17 14:43:50 -08:00
Justin McCarthy	5c160d1ec5	increment patch for release (via Makefile)	2018-12-17 14:43:31 -08:00
Justin McCarthy	f3088bfe28	update authors	2018-12-17 14:43:00 -08:00
Kevin N. Murphy	aa57be25c9	fix markdown whitespace on heading (#59 )	2018-12-17 14:41:37 -08:00
arambhashura	2cef618abb	Minor correction. (#58 ) The word "is" was missing in the first sentence of Purpose and Scope.	2018-12-17 14:41:27 -08:00
Justin McCarthy	e8a0ecd076	Jira fields were swapped	2018-12-17 14:41:09 -08:00
Andy Magnusson	1a3e2a2bf7	Merge branch 'master' of https://github.com/strongdm/comply	2018-12-06 10:39:15 -05:00
Andy Magnusson	7225741a46	Adding new templates to proper soc2 narratives location	2018-12-06 10:10:18 -05:00
Justin McCarthy	7105d2d4ef	increment patch for release (via Makefile)	2018-11-08 22:10:44 -08:00
Justin McCarthy	e3fb66b0e4	automated asset refresh (via Makefile)	2018-11-08 22:10:37 -08:00
Justin McCarthy	1028521ea7	increment patch for release (via Makefile)	2018-11-08 21:57:00 -08:00
Justin McCarthy	b2c2bf3558	update authors	2018-11-08 21:56:23 -08:00
Matt Simerson	d44af2e1cd	gitlab: search for the label name that issues have (#57 ) * gitlab: search for the label name that issues have comply creates tags with "comply-" prefix, so search for that * fix issue counters by using correct label name	2018-11-08 21:53:17 -08:00
Andy Magnusson	e2281b5fe3	Backporting new narrative content to Comply	2018-10-04 10:23:24 -04:00
Justin McCarthy	d43aca58ba	increment patch for release (via Makefile)	2018-08-29 15:50:07 -07:00
Justin McCarthy	9e4cd2cf1a	automated asset refresh (via Makefile)	2018-08-29 15:49:56 -07:00
Justin McCarthy	3711e0054d	fmt	2018-08-29 15:48:07 -07:00
Justin McCarthy	2e9f6cf270	getGitApprovalInfo early exit if approvedBranch unspecified. go fmt.	2018-08-29 15:47:02 -07:00
Justin McCarthy	c5868fa544	update authors	2018-08-29 15:45:27 -07:00
Alan Cox	274986ad9c	Optionally, authorship and approval information appended to policies (#54 )	2018-08-29 15:39:50 -07:00
Alan Cox	bcc9b06ac4	Specifying Jira Issuetype in config.yaml (#53 ) * Jira integration documentation improved. Added ability to specify what type of issue to create in Jira * Apparently, Go doesn't like http/https in front of package name in	2018-08-29 15:17:00 -07:00
Justin McCarthy	8f3d668789	incorrect ticket label	2018-08-17 13:32:35 -07:00
Andy Magnusson	358ac431a6	Retitled CC2.1, CC2.2, CC2.3	2018-08-16 13:40:29 -04:00
Justin McCarthy	365e98222b	increment patch for release (via Makefile)	2018-07-23 11:57:14 -07:00
Justin McCarthy	84589a83f4	automated asset refresh (via Makefile)	2018-07-23 11:57:06 -07:00
Justin McCarthy	b329107079	reverting `cd89840164`	2018-07-23 11:56:44 -07:00
Justin McCarthy	3f5d9b4409	increment minor for release (via Makefile)	2018-07-20 17:55:58 -07:00
Justin McCarthy	3df822206e	automated asset refresh (via Makefile)	2018-07-20 17:55:51 -07:00
Justin McCarthy	007cf3dd3c	dep ensure	2018-07-20 17:55:27 -07:00
Justin McCarthy	97989c5cf6	Merge branch 'master' of github.com:strongdm/comply	2018-07-20 17:45:33 -07:00
Mason Hensley	ce5c4c3a4a	Add gitlab issue integration (#51 ) * Add gitlab issue integration * Clean up gitlab issue integration	2018-07-20 17:45:20 -07:00
Justin Bodeutsch	cd89840164	Fixed date on generated PDFs (#52 ) * Percent signs need to be escaped in Printf * Update usage of ModifiedAt to fix date stamp on generated PDFs	2018-07-20 17:45:07 -07:00
Justin McCarthy	e60d7285f4	more precise cross-platform dependency checking	2018-07-20 17:44:28 -07:00
Justin McCarthy	c99d800397	use filepath join to open index html	2018-07-20 17:08:09 -07:00
Justin McCarthy	0f1badca5b	prepare Makefile for introduction of Windows binary	2018-07-05 17:26:29 -07:00
Justin McCarthy	00b59ed620	update to reflect contributions	2018-07-02 17:12:00 -07:00
Justin Bodeutsch	749017761d	Percent signs need to be escaped in Printf (#49 )	2018-07-02 17:10:00 -07:00
Justin McCarthy	f502225cde	increment patch for release (via Makefile)	2018-06-25 17:50:51 -07:00
Justin McCarthy	6cf6f70296	automated asset refresh (via Makefile)	2018-06-25 17:50:42 -07:00
Justin McCarthy	3494bdce7b	prep version notification and release channel structure	2018-06-25 17:50:07 -07:00
Justin McCarthy	924dd25744	increment patch for release (via Makefile)	2018-06-15 16:51:26 -07:00
Justin McCarthy	02d3b75731	automated asset refresh (via Makefile)	2018-06-15 16:51:17 -07:00
Justin McCarthy	4a314c62d1	pandoc 2 args; validate presence of PDF after calling docker pandoc.	2018-06-15 16:00:37 -07:00
Anthony Oliver	f2ef58e7bd	Added package for missing fonts, otherwise updated pandoc 2 with pandoc -f markdown+smart doesn't work and throws a mktextfm ecrm1000 error (#46 )	2018-06-15 11:49:45 -07:00
Justin McCarthy	fc1a1d9abc	brew goal should not compile assets, which depends on go get	2018-06-09 22:27:49 -07:00
Justin McCarthy	65dddc4332	increment patch for release (via Makefile)	2018-06-07 22:24:17 -07:00
Justin McCarthy	eecfe49fbd	automated asset refresh (via Makefile)	2018-06-07 22:24:09 -07:00
Justin McCarthy	44931ca808	fixes #45	2018-06-07 22:23:51 -07:00
Justin McCarthy	06b8a2fe44	increment patch for release (via Makefile)	2018-06-04 16:16:45 -07:00
Justin McCarthy	2d088cdf45	automated asset refresh (via Makefile)	2018-06-04 16:16:37 -07:00
Justin McCarthy	fb60f405ba	Feature/jira (#43 ) * automated asset refresh (via Makefile) * increment patch for release (via Makefile)	2018-06-04 16:14:06 -07:00
Justin McCarthy	3c696e6d01	Merge pull request #41 from strongdm/feature/jira Initial Jira implementation	2018-06-01 17:37:41 -07:00
Justin McCarthy	4d63cf559b	dep ensure	2018-06-01 17:37:01 -07:00
Justin McCarthy	0ff74208cc	link format	2018-06-01 17:36:41 -07:00
Justin McCarthy	75a80189ce	correct tag name	2018-06-01 17:27:56 -07:00
Justin McCarthy	f6c9f89792	use Resolution field rather than Status	2018-06-01 17:18:41 -07:00
Justin McCarthy	25f7156ac2	enable Jira	2018-06-01 17:07:36 -07:00
Justin McCarthy	2d5e6b48cb	config override should cause image to be pulled	2018-06-01 17:04:52 -07:00
Justin McCarthy	4d830789ec	never pull the docker container if pandoc is present and working in the PATH	2018-06-01 17:01:22 -07:00
Justin McCarthy	4969d179ec	find by tag / label	2018-06-01 16:57:06 -07:00
Justin McCarthy	10dc0b70e0	partial jira implementation; TODO: all Find/Read and Link cases.	2018-05-30 16:28:31 -07:00
Justin McCarthy	0f68acae10	increment patch for release (via Makefile)	2018-05-29 16:35:06 -07:00
Justin McCarthy	19e100801a	automated asset refresh (via Makefile)	2018-05-29 16:34:57 -07:00
Justin McCarthy	46aaf1c663	document model	2018-05-29 14:42:37 -07:00
Justin McCarthy	815e7e5f61	the data model for Narratives and Policies have converged, allowing both to be represented by a common Docume nt struct.	2018-05-28 17:05:56 -05:00
Justin McCarthy	ff626a5ee2	pandoc must also include pdflatex	2018-05-28 16:46:35 -05:00
Justin McCarthy	1ec70a67d1	increment minor for release (via Makefile)	2018-05-23 17:16:55 -07:00
Justin McCarthy	096ad03ee1	automated asset refresh (via Makefile)	2018-05-23 17:16:47 -07:00
Justin McCarthy	5d67d60fd4	increment patch for release (via Makefile)	2018-05-23 17:04:43 -07:00
Justin McCarthy	8e3ebdc94a	automated asset refresh (via Makefile)	2018-05-23 17:04:35 -07:00
Justin McCarthy	39fd371c4e	spelled .envrc wrong	2018-05-23 17:04:03 -07:00
Justin McCarthy	1e5383eb01	env file to ignore	2018-05-23 16:53:07 -07:00
Justin McCarthy	49e950c3c0	If `pandoc` appears in the path, it will be preferred over Docker. The pandoc version must be 2.2.1 or greater. Defaults can be overridden by an optional "pandoc: pandoc" or "pandoc: docker" in the comply.yml.	2018-05-23 16:48:35 -07:00
Justin McCarthy	ff350a2b89	Prepare pandoc upgrade (not pushed to docker hub yet)	2018-05-23 16:46:28 -07:00
Justin McCarthy	82baa57684	note pandoc dependency	2018-05-23 14:18:28 -07:00
Justin McCarthy	bb4200ff43	replace dockerMustExist with pandocMustExist dependency on build and serve commands	2018-05-23 14:15:39 -07:00
Justin McCarthy	1b807da10e	Update AUTHORS.txt	2018-05-20 22:57:37 -07:00
Justin McCarthy	57a617abd5	increment patch for release (via Makefile)	2018-05-18 17:33:15 -07:00
Justin McCarthy	1170ad6a92	automated asset refresh (via Makefile)	2018-05-18 17:33:06 -07:00
Justin McCarthy	b81d8388ef	link to demo video	2018-05-18 17:32:54 -07:00
Justin McCarthy	36331849c8	point Linux users to releases	2018-05-18 17:29:29 -07:00
Justin McCarthy	1d3dcc8f54	logo (small)	2018-05-18 17:27:28 -07:00
Manisha Singh	9309194a40	Merge branch 'master' of github.com:strongdm/comply	2018-05-18 17:25:14 -07:00
Manisha Singh	a37e8dc233	Initial commit of Access	2018-05-18 17:25:11 -07:00
Justin McCarthy	bef531973f	increment patch for release (via Makefile)	2018-05-18 16:48:36 -07:00
Justin McCarthy	a025ea5e39	automated asset refresh (via Makefile)	2018-05-18 16:48:28 -07:00
Justin McCarthy	cee7553319	invoke update in tap dir	2018-05-18 16:48:25 -07:00
Justin McCarthy	4c55c371af	increment patch for release (via Makefile)	2018-05-18 16:44:29 -07:00
Justin McCarthy	af4fb6e0d2	automated asset refresh (via Makefile)	2018-05-18 16:44:21 -07:00
Justin McCarthy	0e1eed80c9	capture sha	2018-05-18 16:44:16 -07:00
Justin McCarthy	deeb8c1695	capture sha	2018-05-18 16:44:16 -07:00
Manisha Singh	2a4486315e	Merge branch 'master' of github.com:strongdm/comply	2018-05-18 16:41:22 -07:00
Manisha Singh	df159a5f0d	Initial commit of Risk	2018-05-18 16:41:18 -07:00
Justin McCarthy	f8a742556d	increment patch for release (via Makefile)	2018-05-18 16:31:38 -07:00
Justin McCarthy	eb00183724	automated asset refresh (via Makefile)	2018-05-18 16:31:30 -07:00
Manisha Singh	5acf683e04	Initial commit of Availability	2018-05-18 16:09:48 -07:00
Manisha Singh	491bd00b20	Updated Table 3	2018-05-18 16:02:38 -07:00
Manisha Singh	a642c812e3	Initial commit of Encryption	2018-05-18 15:42:35 -07:00
Manisha Singh	69d036b00b	Merge branch 'master' of github.com:strongdm/comply	2018-05-18 14:48:11 -07:00
Manisha Singh	736dfc539c	Initial commit of Data Classification	2018-05-18 14:48:08 -07:00
Justin McCarthy	f5b28a1bac	introduce procedure command	2018-05-18 14:42:55 -07:00
Justin McCarthy	80c8978034	increment patch for release (via Makefile)	2018-05-18 12:35:15 -07:00
Justin McCarthy	592852ad38	automated asset refresh (via Makefile)	2018-05-18 12:35:06 -07:00
Manisha Singh	179477b4ef	Merge branch 'master' of github.com:strongdm/comply	2018-05-18 12:33:51 -07:00
Manisha Singh	46fd0e6987	Initial commit of Vendor	2018-05-18 12:33:48 -07:00
Justin McCarthy	9a357f7bd6	workstation procedure example	2018-05-18 12:33:08 -07:00
Justin McCarthy	378a27542f	Merge branch 'master' of github.com:strongdm/comply	2018-05-18 12:21:00 -07:00
Justin McCarthy	1b010e0d04	Procedure examples	2018-05-18 12:20:53 -07:00
Manisha Singh	1eebcaeee1	Initial commit of Development	2018-05-18 12:11:48 -07:00
Manisha Singh	6973675228	Initial commit of Removable Media	2018-05-18 11:56:09 -07:00
Manisha Singh	5e82aa0cfe	Merge branch 'master' of github.com:strongdm/comply	2018-05-18 11:47:03 -07:00
Manisha Singh	ed8d8a9404	Initial commit of Remote Access	2018-05-18 11:46:58 -07:00
Justin McCarthy	f7b13952af	increment patch for release (via Makefile)	2018-05-18 11:38:32 -07:00
Justin McCarthy	d79d9a934b	automated asset refresh (via Makefile)	2018-05-18 11:38:23 -07:00
Justin McCarthy	f6410c6fb9	restore dependencies for release target	2018-05-18 11:38:13 -07:00
Justin McCarthy	14bde98a9f	release webhook	2018-05-18 11:37:18 -07:00
Manisha Singh	430e01fa7c	Initial commit of Disaster Recovery	2018-05-18 11:16:51 -07:00
Manisha Singh	0ba9f063c5	Initial commit of Data Retention	2018-05-18 10:48:56 -07:00
Manisha Singh	5c40d95dd0	Initial commit of Cyber Risk	2018-05-18 10:32:25 -07:00
Manisha Singh	fdc8038c95	Merge branch 'master' of github.com:strongdm/comply	2018-05-18 10:19:55 -07:00
Manisha Singh	1a92fc92c4	Initial commit of Application Security	2018-05-18 10:19:43 -07:00
Justin McCarthy	f0117bd807	increment patch for release (via Makefile)	2018-05-17 23:21:26 -07:00
Justin McCarthy	816be6d613	automated asset refresh (via Makefile)	2018-05-17 23:21:18 -07:00
Justin McCarthy	4c1b6fad7e	trigger procedure by ID	2018-05-17 23:08:34 -07:00
Justin McCarthy	8fbc7ab65a	more verbose output in the interest of educating users on input and output paths	2018-05-17 22:52:39 -07:00
Justin McCarthy	e97f0684ac	move all calls to show to bottom block	2018-05-17 22:46:17 -07:00
Justin McCarthy	7aa267dbb6	only open html after render is complete during serve	2018-05-17 22:45:39 -07:00
@@ -1 +1 @@
 .1.19
 .5.2