increment patch for release (via Makefile)

automated asset refresh (via Makefile)
restore dependencies for release target
2025-12-15 10:43:47 +00:00 · 2018-05-18 11:38:32 -07:00 · 2018-05-18 11:38:23 -07:00 · 2018-05-18 11:38:13 -07:00 · 2018-05-18 11:37:18 -07:00 · 2018-05-18 11:16:51 -07:00
48 changed files with 2501 additions and 138 deletions
--- a/8
+++ b/8
@@ -104,9 +104,17 @@ release: release-env dist release-deps
 	--name comply-$(VERSION)-linux-amd64.tgz \
 	--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 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 push-assets 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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

 patch: clean gitsem
 	gitsem -m "increment patch for release (via Makefile)" patch
--- a/2
+++ b/2
@@ -1 +1 @@
-1.1.17
+1.1.21
--- a/example/narratives/organizational.md
+++ b/example/narratives/organizational.md
@@ -9,7 +9,6 @@ satisfies:
    - CC3.1
    - CC3.2
    - CC3.3
-    - CC3.4
 majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
--- 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/change.md
+++ b/example/policies/change.md
@@ -3,9 +3,49 @@ acronym: SCP
 satisfies:
  TSC:
    - CC8.1
+    - CC3.4
 majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This information security policy defines how changes to information systems are planned and implemented 
+
+a. This policy applies to the entire information security program at the organization (i.e. to all information and communications technology, as well as related documentation).
+
+a. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work for the organization, or who have been granted to the organization’s information and communications technology, must comply with this policy.
+
+# Background
+
+a. This policy defines specific requirements to ensure that changes to systems and applications are properly planned, evaluated, reviewed, approved, communicated, implemented, documented, and reviewed, thereby ensuring the greatest probability of success. Where changes are not successful, this document provides mechanisms for conducting post-implementation review such that future mistakes and errors can be prevented.
+
+# Policy
+
+a. Any changes to the security architecture or customer data handling of a system must be formally requested in writing to the organization’s Information Security Manager (ISM), and approved by the ISM and the Chief Information Officer (CIO).
+
+a. All change requests must be documented.
+
+a. All change requests must be prioritized in terms of benefits, urgency, effort required, and potential impacts to the organization’s operations.
+
+a. All implemented changes must be communicated to relevant users. 
+
+a. Change management must be conducted according to the following procedure:
+    
+    i. *Planning*: plan the change, including the implementation design, scheduling, and implementation of a communications plan, testing plan, and roll-back plan.
+    
+    i. *Evaluation*: evaluate the change, including priority level of the service and risk that the proposed change introduces to the system; determine the change type and the specific step-by-step process to implement the change.
+    
+    i. *Review*: review the change plan amongst the CIO, ISM, Engineering Lead, and, if applicable, Business Unit Manager.
+    
+    i. *Approval*: the CIO must approve the change plan. 
+    
+    i. *Communication*: communicate the change to all users of the system.
+    
+    i. *Implementation*: test and implement the change.
+    
+    i. *Documentation*: record the change and any post-implementation issues.
+    
+    i. *Post-change review*: conduct a post-implementation review to determine how the change is impacting the organization, either positively or negatively. Discuss and document any lessons learned.
+
--- a/example/policies/conduct.md
+++ b/example/policies/conduct.md
@@ -8,4 +8,89 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+  a. The purpose of this policy is to define expected behavior from employees towards their colleagues, supervisors, and the overall organization. 
+
+  a. We expect all employees to follow our Code of Conduct. Offensive behavior, disruptive behavior, and participation in serious disputes should be avoided. Employees are expected to foster a respectful and collaborative environment. 
+
+  a. This policy applies to all employees and contractors. They are bound by their Employment Offer Letter or Independent Contractor Agreement to follow the Code of Conduct Policy while performing their duties. The Code of Conduct is outlined below: 
+
+#Policy
+
+  a. *Compliance with law*
+      
+      i. Employees should have an understanding of and comply with all environmental, safety, and fair dealing laws. When performing their job duty and dealing with the company’s products, finances, critical information, & public image, employees are expected to be ethical and responsible. If an employee is unsure of whether a contemplated action is permitted by law or Company policy, they should seek advice from the resource manager.  
+
+  a. *Respect in the workplace*
+
+      i. Employees should respect their colleagues. Discriminatory behavior, harassment, or victimization will not be tolerated. 
+
+  a. *Protection of company property*
+
+      i. Company property, both material or intangible, should be treated with respect and care. Employees and contractors: 
+      
+        1. Should not misuse company equipment 
+      
+        1. Should respect all intangible property, including trademarks, copyright, information, reports, and other property. These materials should be used only to complete job duties. 
+
+        1. Should protect company facilities and other material property from damage and vandalism, whenever possible. 
+
+\pagebreak 
+
+  a. *Personal appearance*
+
+      i. When in the workplace, employees must present themselves in an appropriate & professional manner. They should abide by the company dress code. 
+
+  a. *Corruption*
+
+      i. Employees are discouraged from accepting gifts from clients or partners. Briberies are prohibited for the benefit of any external or internal party. 
+
+  a. *Job duties and authority*
+
+      i. Employees should fulfill their job duties with integrity and respect towards all individuals involved. 
+
+      i. Supervisors and managers may not use abuse their authority. Competency and workload should be taken into account when delegating duties to team members. 
+
+      i. Team members are expected to follow their leaders’ instructions and complete their duties with thoughtfulness and in a timely manner. 
+
+  a. *Absenteeism and tardiness*
+
+      i. Employees should be punctual when coming to and leaving from work and follow the schedule determined by their hiring manager. Exceptions can be made for occasions that prevent employees from following standard working hours or days, with approval from their hiring manager. 
+
+  a. *Conflict of interest*
+
+      i. Employees should avoid any personal, financial, or other interests that might compete with their job duties. 
+
+  a. *Collaboration*
+
+      i. Employees should be friendly with their colleagues and open to collaboration. They should not disrupt the workplace or present obstacles to their colleagues’ work. 
+
+  a. *Communication*
+
+      i. Colleagues, supervisors, or team members must be open to communication amongst each other. 
+
+  a. *Benefits*
+
+      i. We expect employees to not abuse their employment benefits. This can refer to time off, insurance, facilities, subscriptions, or other benefits our company offers. Refer to Human Resources for more information on benefits. 
+
+  a. *Policies*
+
+      i. All employees must comply with company policies. Questions should be directed to their hiring managers and/or Human Resources. 
+
+  a. *Disciplinary actions*
+
+      i. Repeated or intentional violation of the Code of Conduct Policy will be met with disciplinary action. Consequences will vary depending on the violation, but can include:  
+
+        1. demotion
+        1. reprimand
+        1. suspension or  termination 
+        1. detraction of benefits for a definite or indefinite time
+
+      ii. Cases of corruption, theft, embezzlement, or other unlawful behavior may call for legal action. 
+
+
+
+
+
+
--- a/example/policies/confidentiality.md
+++ b/example/policies/confidentiality.md
@@ -9,4 +9,92 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This policy outlines expected behavior of employees to keep confidential information about clients, partners, and our company secure. 
+
+a. This policy applies to all employees, board members, investors, and contractors, who may have access to confidential information. This policy must be made readily available to all whom it
+applies to.
+
+# Background
+
+a. The company's confidential information must be protected for two reasons:
+
+    i. It may be legally binding (i.e. sensitive customer data)
+
+    i. It may be fundamental to our business (i.e. business processes) 
+
+a. Common examples of confidential information in our company includes, but is not limited to: 
+
+    i. Unpublished financial information
+
+    i. Customer/partner/vendor/external party data
+
+    i. Patents, formulas, new technologies, and other intellectual property
+
+    i. Existing and prospective customer lists
+
+    i. Undisclosed business strategies including pricing & marketing
+
+    i. Materials & processes explicitly marked as “confidential”
+	
+a. Employees will have varying levels of authorized access to confidential information. 
+
+# Policy
+
+a. *Employee procedure for handling confidential information*
+
+    i. Lock and secure confidential information at all times
+
+    i. Safely dispose (i.e. shred) documents when no longer needed
+
+    i. View confidential information only on secure devices
+
+    i. Disclose information only when authorized and necessary
+
+    i. Do not use confidential information for personal gain, benefit, or profit
+
+    i. Do not disclose confidential information to anyone outside the company or to anyone within the company who does not have appropriate privileges 
+
+    i. Do not store confidential information or replicates of confidential information in unsecured manners (i.e. on unsecured devices) 
+
+    i. Do not remove confidential documents from company's premises unless absolutely necessary to move 
+
+a. *Offboarding measures*
+
+    i. The Hiring Manager should confirm the off-boarding procedure has been completed by final date of employment. 
+
+a. *Confidentiality measures*
+
+    i. The company will take the following measures to ensure protection of confidential information: 
+
+        1. Store and lock paper documents
+
+        1. Encrypt electronic information and implement appropriate technical measures to safeguard databases
+
+        1. Require employees to sign non-disclosure/non-compete agreements
+
+        1. Consult with senior management before granting employees access to certain confidential information 
+
+a. *Exceptions*
+
+    i. Under certain legitimate conditions, confidential information may need to be disclosed. Examples include: 
+
+        1. If a regulatory agency requests information as part of an audit or investigation
+
+        1. If the company requires disclosing information (within legal bounds) as part of a venture or partnership
+
+    i. In such cases, employee must request and receive prior written authorization from their hiring manager before disclosing confidential information to any third parties.
+
+a. *Disciplinary consequences* 
+
+    i. Employees who violate the confidentiality policy will face disciplinary and possible legal action. 
+
+    i. A suspected breach of this policy will trigger an investigation. Intentional violations will be met with termination and repeated unintentional violations may also face termination. 
+
+    i. This policy is binding even after the termination of employment. 
+
+
+
+
+  
--- a/example/policies/continuity.md
+++ b/example/policies/continuity.md
@@ -8,4 +8,89 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+
+# Purpose and Scope
+
+a.  The purpose of this policy is to ensure that the organization establishes objectives, plans and, procedures such that a major disruption to the organization’s key business activities is minimized.  
+
+a. This policy applies to all infrastructure and data within the organization’s information security program.
+
+a. This policy applies to all management, employees, and suppliers that are involved in decisions and processes affecting the organization’s business continuity. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a.  The success of the organization is reliant upon the preservation of critical business operations and essential functions used to deliver key products and services. The purpose of this policy is to define the criteria for continuing business operations for the organization in the event of a disruption. Specifically, this document defines:
+
+    i. The structure and authority to ensure business resilience of key processes and systems.
+
+    i. The requirements for efforts to manage through a disaster or other disruptive event when the need arises. 
+
+    i. The criteria to efficiently and effectively resume normal business operations after a disruption.
+
+a.  Within this document, the following definitions apply: 
+
+    i. *Business impact analysis/assessment* - an exercise that determines the impact of losing the support of any resource to an enterprise, establishes the escalation of that loss over time, identifies the minimum resources needed to return to a normal level of operation, and prioritizes recovery of processes and the supporting system. 
+
+    i. *Disaster recovery plan* - a set of human, physical, technical, and procedural resources to return to a normal level of operation, within a defined time and cost, when an activity is interrupted by an emergency or disaster. 
+    
+    i. *Recovery time objective* - the amount of time allowed for the recovery of a business function or resource to a normal level after a disaster or disruption occurs. 
+    
+    i. *Recovery point objective* - determined based on the acceptable data loss in the case of disruption of operations. 
+
+# Policy
+
+a.  *Business Risk Assessment and Business Impact Analysis*
+
+    i. Each manager is required to perform a business risk assessment and business impact analysis for each key business system within their area of responsibility. 
+
+    i. The business risk assessment must identify and define the criticality of key business systems and the repositories that contain the relevant and necessary data for the key business system. 
+
+    i. The business risk assessment must define and document the Disaster Recovery Plan (DRP) for their area of responsibility.  Each DRP shall include:
+    
+        1. Key business processes.
+        
+        1. Applicable risk to availability.
+
+        1. Prioritization of recovery.
+
+        1. Recovery Time Objectives (RTOs).
+
+        1. Recovery Point Objectives (RPOs).
+
+a.  *Disaster Recovery Plan*
+
+    i. Each key business system must have a documented DRP to provide guidance when hardware, software, or networks become critically dysfunctional or cease to function (short and long term outages).
+
+    i. Each DRP must include an explanation of the magnitude of information or system unavailability in the event of an outage and the process that would be implemented to continue business operations during the outage. Where feasible, the DRP must consider the use of alternative, off-site computer operations (cold, warm, hot sites).
+
+    i. Each plan must be reviewed against the organization’s strategy, objectives, culture, and ethics, as well as policy, legal, statutory and regulatory requirements.
+
+    i. Each DRP must include:
+
+        1. An emergency mode operations plan for continuing operations in the event of temporary hardware, software, or network outages.
+
+        1. A recovery plan for returning business functions and services to normal on-site operations. 
+
+        1. Procedures for periodic testing, review, and revisions of the DRP for all affected business systems, as a group and/or individually.
+
+a.  *Data Backup and Restoration Plans*
+
+    i. Each system owner must implement a data backup and restoration plan. 
+
+    i. Each data backup and restoration plan must identify:
+
+        1. The data custodian for the system.
+
+
+        1. The backup schedule of each system.
+
+
+        1. Where backup media is to be stored and secured, as well as how access is maintained.
+
+        1. Who may remove backup media and transfer it to storage.
+
+        1. Appropriate restoration procedures to restore key business system data from backup media to the system.
+ 
+        1. The restoration testing plan and frequency of testing to confirm the effectiveness of the plan. 
+
+        1. The method for restoring encrypted backup media. 
--- 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/datacenter.md
+++ b/example/policies/datacenter.md
@@ -8,4 +8,52 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define security procedures within the organization’s data centers and secure equipment areas.
+
+a. This policy applies to any cloud hosted providers and facilities within the organization that are labeled as either a data center or a secure equipment area. Such facilities are explicitly called out within this document.
+
+a. This policy applies to all management, employees and suppliers that conduct business operations within cloud host or data centers and secure equipment areas.
+
+# Background
+
+a. This policy defines the policies and rules governing data centers and secure equipment areas from both a physical and logical security perspective. The document lists all data centers and secure equipment areas in use by the organization, prescribes how access is controlled and enforced, and establishes procedures for any visitor or third party access. This policy also defines prohibited activities and requirements for periodic safety and security checks.
+
+# Policy
+
+a. The following locations are classified by the organization as secure areas and are goverened by this policy:
+
+    i. [list all data center locations and secure areas under the organization’s control]
+
+a. Each data center and secure area must have a manager assigned. The manager’s name must be documented in the organization’s records. In the case of any on-prem data centers, the manager’s name must also be posted in and near the secure area.
+
+a. Each secure area must be clearly marked. Access to the secure area must be controlled by at least a locked door. A visitor access log must be clearly marked and easily accessible just inside the door.
+
+a. Persons who are not employed by the organization are considered to be visitors. Visitors accessing secure areas shall:
+
+    i. Obtain access to secure areas in accordance with reference a.
+
+    i. Only enter and remain in secure areas when escorted by a designated employee. The employee must stay with the visitor during their entire stay inside the secure area.
+
+    i. Log the precise time of entry and exit in the visitor access log.
+
+a. The following activities are prohibited inside secure areas:
+
+    i. Photography, or video or audio recordings of any kind.
+
+    i. Connection of any electrical device to a power supply, unless specifically authorized by the responsible person.
+
+    i. Unauthorized usage of or tampering with any installed equipment.
+
+    i. Connection of any device to the network, unless specifically authorized by the responsible person.
+
+    i. Storage or archival of large amounts of paper materials.
+
+    i. Storage of flammable materials or equipment.
+
+    i. Use of portable heating devices.
+
+    i. Smoking, eating, or drinking.
+
+a. Secure areas must be checked for compliance with security and safety requirements on at least a quarterly basis.
--- a/example/policies/disaster.md
+++ b/example/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/example/policies/incident.md
+++ b/example/policies/incident.md
@@ -10,4 +10,102 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This security incident response policy is intended to establish controls to ensure detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches.
+
+a. This document also provides implementing instructions for security incident response, to include definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).
+
+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. A key objective of the organization’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. The organization is committed to protecting its employees, customers, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly. Despite this, incidents and data breaches are likely to happen; when they do, the organization is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving , and communicating information related to the breach.
+
+a. This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, the organization must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents. If a vulnerability is identified, it must be resolved within a set period of time based on its severity. If an incident is identified, it must be investigated within a set period of time based on its severity. If an incident is confirmed as a breach, a set procedure must be followed to contain, investigate, resolve, and communicate information to employees, customers, partners and other stakeholders.  
+
+c. Within this document, the following definitions apply:
+
+    i. *Information Security Vulnerability:* a vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorized access to information or to disrupt critical processing.
+
+    i. *Information Security Incident:* a suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.
+
+# Policy
+a. All users must report any system vulnerability , incident, or event pointing to a possible incident to the Information Security Manager (ISM) as quickly as possible but no later than 24 hours. Incidents must be reported by sending an email message to <insert email address here> with details of the incident.
+
+a. Users must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents. Failure to report information security incidents shall be considered to be a security violation and will be reported to the Human Resources (HR) Manager for disciplinary action.
+
+a. Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved in the event that they need to be used as evidence of a crime.
+
+a. All information security incidents must be responded to through the incident management procedures defined below.
+
+a. In order to appropriately plan and prepare for incidents, the organization must review incident response procedures at least once per year for currency, and update as required.
+
+a. The incident response procedure must be tested on at least twice per year
+
+a. The incident response logs must be reviewed once per month to assess response effectiveness.
+
+# Procedure For Establishing Incident Response System
+
+a. Define on-call schedule and assign an Information Security Manager (ISM) responsible for managing incident response procedure during each availability window.
+
+a. Define notification channel to alert the on-call ISM of a potential security incident.  Establish company resource that includes up to date contact information for on-call ISM.
+
+a. Assign management sponsors from the Engineering, Legal, HR, Marketing, and C-Suite teams.
+
+a. Distribute Procedure For Execute Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource. 
+
+a. Require all staff to complete training for Procedure For Executing Incident Response at least twice per year.
+
+# Procedure For Executing Incident Response
+
+a. When an information security incident is identified or detected, users must notify their immediate manager within 24 hours. The manager must immediately notify the ISM on call for proper response. The following information must be included as part of the notification:
+
+    i. Description of the incident
+
+    i. Date, time, and location of the incident
+
+    i. Person who discovered the incident
+
+    i. How the incident was discovered
+
+    i. Known evidence of the incident
+
+    i. Affected system(s)
+
+a. Within 48 hours of the incident being reported, the ISM shall conduct a preliminary investigation and risk assessment to review and confirm the details of the incident. If the incident is confirmed, the ISM must assess the impact to the organization and assign a severity level, which will determine the level of remediation effort required:
+
+    i. High: the incident is potentially catastrophic to the organization and/or disrupts the organization’s day-to-day operations; a violation of legal, regulatory or contractual requirements is likely.
+
+    i. Medium: the incident will cause harm to one or more business units within the organization and/or will cause delays to a business unit’s activities.
+
+    i. Low: the incident is a clear violation of organizational security policy, but will not substantively impact the business.
+
+
+a. The ISM, in consultation with management sponsors, shall determine appropriate incident response activities in order to contain and resolve incidents.
+
+a. The ISM must take all necessary steps to preserve forensic evidence (e.g. log information, files, images) for further investigation to determine if any malicious activity has taken place. All such information must be preserved and provided to law enforcement if the incident is determined to be malicious.
+
+a. If the incident is deemed as High or Medium, the ISM must work with the VP Brand/Creative, General Counsel, and HR Manager to create and execute a communications plan that communicates the incident to users, the public, and others affected.
+
+a. The ISM must take all necessary steps to resolve the incident and recover information systems, data, and connectivity. All technical steps taken during an incident must be documented in the organization’s incident log, and must contain the following:
+
+    i. Description of the incident
+
+    i. Incident severity level
+
+    i. Root cause (e.g. source address, website malware, vulnerability)
+
+    i. Evidence
+
+    i. Mitigations applied (e.g. patch, re-image)
+
+    i. Status (open, closed, archived)
+
+    i. Disclosures (parties to which the details of this incident were disclosed to, such as customers, vendors, law enforcement, etc.)
+
+a. After an incident has been resolved, the ISM must conduct a post mortem that includes root cause analysis and documentation any lessons learned.
+
+a. Depending on the severity of the incident, the Chief Executive Officer (CEO) may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.
+
+a. The ISM must notify all users of the incident, conduct additional training if necessary, and present any lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed as malicious.
--- a/example/policies/information.md
+++ b/example/policies/information.md
@@ -8,4 +8,86 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This information security policy defines the purpose, principles, objectives and basic rules for information security management.
+
+a. This document also defines procedures to implement high level information security protections within the organization, including definitions, procedures, responsibilities and performance measures (metrics and reporting mechanisms).
+
+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 high level objectives and implementation instructions for the organization’s information security program. It includes the organization’s information security objectives and requirements; such objectives and requirements are to be referenced when setting detailed information security policy for other areas of the organization. This policy also defines management roles and responsibilities for the organization’s Information Security Management System (ISMS). Finally, this policy references all security controls implemented within the organization.
+
+a. Within this document, the following definitions apply:
+
+    i. *Confidentiality*: a characteristic of information or information systems in which such information or systems are only available to authorized entities.
+
+    i. *Integrity*: a characteristic of information or information systems in which such information or systems may only be changed by authorized entities, and in an approved manner.
+
+    i. *Availability*: a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
+
+    i. *Information Security*: the act of preserving the confidentiality, integrity, and, availability of information and information systems.
+
+    i. *Information Security Management System (ISMS)*: the overall management process that includes the planning, implementation, maintenance, review, and, improvement of information security.
+
+# References
+
+a. Encryption Policy
+
+a. Data Center Security Policy
+
+a. Disaster Recovery Policy
+
+a. Password Policy
+
+a. Remote Access Policy
+
+a. Removable Media/Cloud Storage/BYOD Policy
+
+a. Risk Assessment Policy
+
+a. Security Incident Response Policy
+
+a. Software Development Lifecycle Policy
+
+a. System Availability Policy
+
+a. Workstation Security Policy 
+
+# Policy
+
+a. *Managing Information Security*
+
+    i. The organization’s main objectives for information security include the following:
+
+        1. [list the reasons/objectives for maintaining information security at the organization. Examples include a better market image, reduced risk of data breaches and compromises, and compliance with legal, regulatory, and contractual requirements.]
+
+    i. The organization’s objectives for information security are in line with the organization’s business objectives, strategy, and plans.
+
+    i. Objectives for individual security controls or groups of controls are proposed by the company management team, including but not limited to [list key roles inside the organization that will participate in information security matters], and others as appointed by the CEO; these security controls are approved by the CEO in accordance with the Risk Assessment Policy (Reference (a)).
+
+    i. All objectives must be reviewed at least once per year.
+
+    i. The company will measure the fulfillment of all objectives. The measurement will be performed at least once per year. The results must be analyzed, evaluated, and reported to the management team.
+
+a. *Information Security Requirements* 
+
+    i. This policy and the entire information security program must be compliant with legal and regulatory requirements as well as with contractual obligations relevant to the organization.
+
+    i. All employees, contractors, and other individuals subject to the organization’s information security policy must read and acknowledge all information security policies.
+
+    i. The process of selecting information security controls and safeguards for the organization is defined in Reference (a).
+
+    i. The organization prescribes guidelines for remote workers as part of the Remote Access Policy (reference (b)).
+
+    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/log.md
+++ b/example/policies/log.md
@@ -8,4 +8,60 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This log management and review policy defines specific requirements for information systems to generate, store, process, and aggregate appropriate audit logs across the organization’s entire environment in order to provide key information and detect indicators of potential compromise.
+
+a. This policy applies to all information systems within the organization’s production network.
+
+a. This policy applies to all employees, contractors, and partners of the organization that administer or provide maintenance on the organization’s production systems. Throughout this policy, these individuals are referred to as system administrators.
+
+# Background
+
+a. In order to measure an information system’s level of security through confidentiality, integrity, and availability, the system must collect audit data that provides key insights into system performance and activities. This audit data is collected in the form of system logs. Logging from critical systems, applications, and services provides information that can serve as a starting point for metrics and incident investigations. This policy provides specific requirements and instructions for how to manage such logs.
+
+# Policy
+
+a. All production systems within the organization shall record and retain audit-logging information that includes the following information:
+
+    i. Activities performed on the system.
+
+    i. The user or entity (i.e. system account) that performed the activity, including the system that the activity was performed from.
+    
+    i. The file, application, or other object that the activity was performed on.
+    
+    i. The time that the activity occurred.
+
+    i. The tool that the activity was performed with.
+
+    i. The outcome (e.g., success or failure) of the activity.
+
+a. Specific activities to be logged must include, at a minimum:
+
+    i. Information (including authentication information such as usernames or passwords) is created, read, updated, or deleted. 
+
+    i. Accepted or initiated network connections. 
+
+    i. User authentication and authorization to systems and networks.
+
+    i. Granting, modification, or revocation of access rights, including adding a new user or group; changing user privileges, file permissions, database object permissions, firewall rules, and passwords.
+
+    i. System, network, or services configuration changes, including software installation, patches, updates, or other installed software changes.
+  
+    i. Startup, shutdown, or restart of an application. 
+  
+    i. Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault.
+
+    i. Detection of suspicious and/or malicious activity from a security system such as an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.
+
+a. Unless technically impractical or infeasible, all logs must be aggregated in a central system so that activities across different systems can be correlated, analyzed, and tracked for similarities, trends, and cascading effects. Log aggregation systems must have automatic and timely log ingest, event and anomaly tagging and alerting, and ability for manual review.
+
+a. Logs must be manually reviewed on a regular basis:
+  
+    i. The activities of users, administrators and system operators must be reviewed on at least a monthly basis.
+
+    ii. Logs related to PII must be reviewed on at least a monthly basis in order to identify unusual behavior.
+
+a. When using an outsourced cloud environment, logs must be kept on cloud environment access and use, resource allocation and utilization, and changes to PII. Logs must be kept for all administrators and operators performing activities in cloud environments.
+
+a. All information systems within the organization must synchronize their clocks by implementing Network Time Protocol (NTP) or a similar capability. All information systems must synchronize with the same primary time source.
--- a/example/policies/office.md
+++ b/example/policies/office.md
@@ -8,4 +8,92 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This policy establishes the rules governing controls, monitoring, and removal of physical access to company’s facilities.
+
+a. This policy applies to all staff, contractors, or third parties who require access to any physical location owned, operated, or otherwise occupied by the company. A separate policy exists for governing access to the company data center. 
+
+# Policy
+
+a. *Management responsibilities*
+
+    i. Management shall ensure:
+
+        1. appropriate entry controls are in place for secure areas
+
+        1. security personnel, identification badges, or electronic key cards should be used to validate employee access to facilities
+
+        1. confirm visitor & guest access procedure has been followed by host staff 
+        
+        1. management periodically reviews list of individuals with physical access to facilities 
+        
+        1. card access records and visitor logs are kept for a minimum of 90 days and are periodically reviewed for unusual activity 
+
+a. *Key access & card systems*
+      
+    i. The following policies are applied to all facility access cards/keys:
+    
+        1. Access cards/keys shall not be shared or loaned to others
+      
+        1. Access cards/keys shall not have identifying information other than a return mail address
+      
+        1. Access cards/keys shall be returned to Human Resources when they are no longer needed
+      
+        1. Lost or stolen access cards/keys shall be reported immediately 
+      
+        1. If an employee changes to a role that no longer requires physical access or leaves the company, their access cards/keys will be suspended 
+      
+        1. Human Resources will regularly review physical security privileges and review access logs 
+
+\pagebreak 
+
+a. *Staff & contractor access procedure* 
+
+    i. Access to physical locations is granted to employees and contractors based on individual job function and will be granted by Human Resources. 
+
+    i. Any individual granted access to physical spaces will be issued a physical key or access key card. Key and card issuance is tracked by Human Resources and will be periodically reviewed. 
+
+    i. In the case of termination, Human Resources should ensure immediate revocation of access 
+(i.e. collection of keys, access cards, and any other asset used to enter facilities) through the offboarding procedure. 
+
+a. *Visitor & guest access procedure*
+	
+    i. The following policies are applied to identification & authorization of visitors and guests:
+
+        1. All visitors must request and receive written onsite authorization from a staff member. 
+
+        1. Visitor access shall be tracked with a sign in/out log. The log shall contain:visitor’s name, firm represented, purpose of visit, and onsite personnel authorizing access
+
+        1. The log shall be retained for a minimum of 90 days
+
+        1. Visitors shall be given a badge or other identification that visibly distinguishes visitors from onsite personnel 
+
+        1. Visitor badges shall be surrendered before leaving the facility
+
+a. *Audit controls & management*
+
+    i. Documented procedures and evidence of practice should be in place for this policy. Acceptable controls and procedures include:
+
+        1. visitor logs
+
+        1. access control procedures
+        
+        1. operational key-card access systems
+        
+        1. video surveillance systems (with retrievable data)
+        
+        1. ledgers if issuing physical keys 
+
+a. *Enforcement*
+
+    i. Employees, contractors, or third parties found in violation of this policy (whether intentional or accidental) may be subject to disciplinary action, including:
+      
+        1. reprimand
+        
+        1. loss of access to premises
+        
+        1. termination
+
+
+
--- a/example/policies/password.md
+++ b/example/policies/password.md
@@ -8,4 +8,32 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope 
+
+a. The Password Policy describes the procedure to select and securely manage passwords. 
+
+a. This policy applies to all employees, contractors, and any other personnel who have an account on any system that resides at any company facility or has access to the company network.  
+
+# Policy
+
+a. *Rotation requirements* 
+
+    i. All system-level passwords should be rotated on at least a quarterly basis. All user-level passwords should be rotated at least every six months. 
+
+    i. If a credential is suspected of being compromised, the password in question should be rotated immediately and the Engineering/Security team should be notified. 
+
+a. Password protection
+
+    i. All passwords are treated as confidential information and should not be shared with anyone. If you receive a request to share a password, deny the request and contact the system owner for assistance in provisioning an individual user account. 
+
+    i. Do not write down passwords, store them in emails, electronic notes, or mobile devices, or share them over the phone. If you must store passwords electronically, do so with a password manager that has been approved by IT. If you truly must share a password, do so through a designated password manager or grant access to an application through a single sign on provider. 
+
+    i. Do not use the “Remember Password” feature of applications and web browsers. 
+
+    i. If you suspect a password has been compromised, rotate the password immediately and notify engineering/security. 
+
+a. Enforcement
+
+    i. An employee or contractor found to have violated this policy may be subject to disciplinary action. 
+
+
--- a/example/policies/policy.md
+++ b/example/policies/policy.md
@@ -7,5 +7,24 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Purpose and Scope

-# Coming Soon
+a. This policy addresses policy education requirements for employees and contractors. 
+
+a. This policy applies to all full-time employees, part-time employees, and contractors. Adherence to assigned policies is binding under their Employment Offer Letter and/or Independent Contractor Agreement. 
+
+# Applicability
+
+a. Upon hire of a new employee or contractor, the Hiring Manager will determine which subsets of policies will apply to that individual. The individual will have five working days to read the assigned policies. The following will be logged in the Policy Training Policy Ledger:
+    
+    i. Assignment date
+    
+    i. Completion date
+    
+    i. Policy
+    
+    i. Assignee
+    
+    i. Assigner
+    
+    i. Notes
--- 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/workstation.md
+++ b/example/policies/workstation.md
@@ -8,4 +8,44 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope 
+
+a. This policy defines best practices to reduce the risk of data loss/exposure through workstations. 
+
+a. This policy applies to all employees and contractors. Workstation is defined as the collection of all company-owned and personal devices containing company data. 
+
+# Policy 
+
+a. Workstation devices must meet the following criteria:
+    
+    i. Operating system must be no more than one generation older than current
+    
+    i. Device must be encrypted at rest
+    
+    i. Device must be locked when not in use or when employee leaves the workstation 
+    
+    i. Workstations must be used for authorized business purposes only 
+    
+    i. Loss or destruction of devices should be reported immediately 
+    
+    i. Laptops and desktop devices should run the latest version of antivirus software that has been approved by IT 
+
+a. *Desktop & laptop devices*
+
+    i. Employees will be issued a desktop, laptop, or both by the company, based on their job duties. Contractors will provide their own laptops. 
+
+	  i. Desktops and laptops must operate on macOS or Windows.
+
+a. *Mobile devices*
+
+    i. Mobile devices must be operated as defined in the Removable Media Policy, Cloud Storage, and Bring Your Own Device Policy. 
+
+    i. Mobile devices must operate on iOS or Android.
+
+    i. Company data may only be accessed on mobile devices with Slack and Gmail. 
+
+a. *Removable media*
+
+    i. Removable media must be operated as defined in the Removable Media Policy, Cloud Storage, and Bring Your Own Device Policy. 
+
+    i. Removable media is permitted on approved devices as long as it does not conflict with other policies. 
--- a/example/templates/index.ace
+++ b/example/templates/index.ace
@@ -13,11 +13,15 @@ html lang=en
    = javascript
      document.addEventListener("DOMContentLoaded", function(event) {
        document.querySelectorAll('.cron').forEach(function(el) {
-          el.innerHTML = prettyCron.toString(el.innerHTML)
+          el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
        })
      })

      function show(name) {
+        if (history.replaceState) {
+            history.replaceState(null, null, '#'+name)
+        }
+
        var items = document.getElementsByClassName('top-nav')
        for (var i=0; i<items.length; i++) {
          var item = items[i]
@@ -220,5 +224,14 @@ html lang=en
        .content.has-text-centered
          p {{.Project.OrganizationName}} Confidential 2018
  = javascript
-    // commented for development
-    show('overview')
+    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/internal/cli/app.go
+++ b/internal/cli/app.go
@@ -44,6 +44,7 @@ func newApp() *cli.App {
 	}

 	app.Commands = append(app.Commands, beforeCommand(buildCommand, projectMustExist))
+	app.Commands = append(app.Commands, beforeCommand(procedureCommand, 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))
--- a/internal/cli/procedure.go
+++ b/internal/cli/procedure.go
@@ -0,0 +1,44 @@
+package cli
+
+import (
+	"fmt"
+
+	"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:    projectMustExist,
+}
+
+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()
+
+	for _, procedure := range procedures {
+		if procedure.ID == procedureID {
+			// TODO: don't hardcode GH
+			tp := model.GetPlugin(model.GitHub)
+			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 nil
+		}
+	}
+
+	return cli.NewExitError(fmt.Sprintf("unknown procedure ID: %s", procedureID), 1)
+}
--- a/internal/render/html.go
+++ b/internal/render/html.go
@@ -9,6 +9,7 @@ import (
 	"sync"

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

@@ -22,13 +23,15 @@ const websocketReloader = `<script>
 	ws.onclose = function(e) {
 		// reload!
 		if (connected) {
-			window.location=window.location
+			window.location.reload(true)
 		}
 	}
 })()
 </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 +59,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)
-			}
+			fmt.Printf("%s -> %s\n", filepath.Join("templates", fileInfo.Name()), outputFilename)

 			tpl, err := ace.Load("", filepath.Join("templates", basename), aceOpts)
 			if err != nil {
@@ -77,10 +78,17 @@ func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 			}
 			w.Close()
 		}
-		if !live {
+
+		if live {
+			if !opened {
+				opened = true
+				open.Run("output/index.html")
+			}
+		} else {
 			wg.Done()
 			return
 		}
+
 		<-subscribe()
 	}
 }
--- a/internal/render/narrative.go
+++ b/internal/render/narrative.go
@@ -49,14 +49,6 @@ func renderNarrativeToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *ren
 	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"))
@@ -112,6 +104,13 @@ func renderNarrativeToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *ren
 			errOutputCh <- err
 			return
 		}
+
+		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))
+
 	}(narrative)
 }

--- a/internal/render/policy.go
+++ b/internal/render/policy.go
@@ -49,14 +49,6 @@ func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *render
 	go func(p *model.Policy) {
 		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"))
@@ -110,6 +102,12 @@ func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *render
 			errOutputCh <- err
 			return
 		}
+
+		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))
 	}(policy)
 }

--- a/internal/render/site.go
+++ b/internal/render/site.go
@@ -8,7 +8,6 @@ import (

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

@@ -103,10 +102,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
@@ -14,6 +14,7 @@ func watch(errCh chan error) {
 		return
 	}
 	b.Add("./templates/")
+	b.Add("./narratives/")
 	b.Add("./policies/")
 	b.Add("./procedures/")

--- a/internal/theme/themes_bindata.go
+++ b/internal/theme/themes_bindata.go
--- a/internal/ticket/scheduler.go
+++ b/internal/ticket/scheduler.go
@@ -98,6 +98,8 @@ func TriggerScheduled() error {
 }

 func trigger(procedure *model.Procedure) {
+	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{
--- a/themes/comply-blank/templates/index.ace
+++ b/themes/comply-blank/templates/index.ace
@@ -13,11 +13,15 @@ html lang=en
    = javascript
      document.addEventListener("DOMContentLoaded", function(event) {
        document.querySelectorAll('.cron').forEach(function(el) {
-          el.innerHTML = prettyCron.toString(el.innerHTML)
+          el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
        })
      })

      function show(name) {
+        if (history.replaceState) {
+            history.replaceState(null, null, '#'+name)
+        }
+
        var items = document.getElementsByClassName('top-nav')
        for (var i=0; i<items.length; i++) {
          var item = items[i]
@@ -220,5 +224,14 @@ html lang=en
        .content.has-text-centered
          p {{.Project.OrganizationName}} Confidential 2018
  = javascript
-    // commented for development
-    show('overview')
+    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/organizational.md
+++ b/themes/comply-soc2/narratives/organizational.md
@@ -9,7 +9,6 @@ satisfies:
    - CC3.1
    - CC3.2
    - CC3.3
-    - CC3.4
 majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
--- 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/change.md
+++ b/themes/comply-soc2/policies/change.md
@@ -3,9 +3,49 @@ acronym: SCP
 satisfies:
  TSC:
    - CC8.1
+    - CC3.4
 majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This information security policy defines how changes to information systems are planned and implemented 
+
+a. This policy applies to the entire information security program at the organization (i.e. to all information and communications technology, as well as related documentation).
+
+a. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work for the organization, or who have been granted to the organization’s information and communications technology, must comply with this policy.
+
+# Background
+
+a. This policy defines specific requirements to ensure that changes to systems and applications are properly planned, evaluated, reviewed, approved, communicated, implemented, documented, and reviewed, thereby ensuring the greatest probability of success. Where changes are not successful, this document provides mechanisms for conducting post-implementation review such that future mistakes and errors can be prevented.
+
+# Policy
+
+a. Any changes to the security architecture or customer data handling of a system must be formally requested in writing to the organization’s Information Security Manager (ISM), and approved by the ISM and the Chief Information Officer (CIO).
+
+a. All change requests must be documented.
+
+a. All change requests must be prioritized in terms of benefits, urgency, effort required, and potential impacts to the organization’s operations.
+
+a. All implemented changes must be communicated to relevant users. 
+
+a. Change management must be conducted according to the following procedure:
+    
+    i. *Planning*: plan the change, including the implementation design, scheduling, and implementation of a communications plan, testing plan, and roll-back plan.
+    
+    i. *Evaluation*: evaluate the change, including priority level of the service and risk that the proposed change introduces to the system; determine the change type and the specific step-by-step process to implement the change.
+    
+    i. *Review*: review the change plan amongst the CIO, ISM, Engineering Lead, and, if applicable, Business Unit Manager.
+    
+    i. *Approval*: the CIO must approve the change plan. 
+    
+    i. *Communication*: communicate the change to all users of the system.
+    
+    i. *Implementation*: test and implement the change.
+    
+    i. *Documentation*: record the change and any post-implementation issues.
+    
+    i. *Post-change review*: conduct a post-implementation review to determine how the change is impacting the organization, either positively or negatively. Discuss and document any lessons learned.
+
--- a/themes/comply-soc2/policies/conduct.md
+++ b/themes/comply-soc2/policies/conduct.md
@@ -8,4 +8,89 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+  a. The purpose of this policy is to define expected behavior from employees towards their colleagues, supervisors, and the overall organization. 
+
+  a. We expect all employees to follow our Code of Conduct. Offensive behavior, disruptive behavior, and participation in serious disputes should be avoided. Employees are expected to foster a respectful and collaborative environment. 
+
+  a. This policy applies to all employees and contractors. They are bound by their Employment Offer Letter or Independent Contractor Agreement to follow the Code of Conduct Policy while performing their duties. The Code of Conduct is outlined below: 
+
+#Policy
+
+  a. *Compliance with law*
+      
+      i. Employees should have an understanding of and comply with all environmental, safety, and fair dealing laws. When performing their job duty and dealing with the company’s products, finances, critical information, & public image, employees are expected to be ethical and responsible. If an employee is unsure of whether a contemplated action is permitted by law or Company policy, they should seek advice from the resource manager.  
+
+  a. *Respect in the workplace*
+
+      i. Employees should respect their colleagues. Discriminatory behavior, harassment, or victimization will not be tolerated. 
+
+  a. *Protection of company property*
+
+      i. Company property, both material or intangible, should be treated with respect and care. Employees and contractors: 
+      
+        1. Should not misuse company equipment 
+      
+        1. Should respect all intangible property, including trademarks, copyright, information, reports, and other property. These materials should be used only to complete job duties. 
+
+        1. Should protect company facilities and other material property from damage and vandalism, whenever possible. 
+
+\pagebreak 
+
+  a. *Personal appearance*
+
+      i. When in the workplace, employees must present themselves in an appropriate & professional manner. They should abide by the company dress code. 
+
+  a. *Corruption*
+
+      i. Employees are discouraged from accepting gifts from clients or partners. Briberies are prohibited for the benefit of any external or internal party. 
+
+  a. *Job duties and authority*
+
+      i. Employees should fulfill their job duties with integrity and respect towards all individuals involved. 
+
+      i. Supervisors and managers may not use abuse their authority. Competency and workload should be taken into account when delegating duties to team members. 
+
+      i. Team members are expected to follow their leaders’ instructions and complete their duties with thoughtfulness and in a timely manner. 
+
+  a. *Absenteeism and tardiness*
+
+      i. Employees should be punctual when coming to and leaving from work and follow the schedule determined by their hiring manager. Exceptions can be made for occasions that prevent employees from following standard working hours or days, with approval from their hiring manager. 
+
+  a. *Conflict of interest*
+
+      i. Employees should avoid any personal, financial, or other interests that might compete with their job duties. 
+
+  a. *Collaboration*
+
+      i. Employees should be friendly with their colleagues and open to collaboration. They should not disrupt the workplace or present obstacles to their colleagues’ work. 
+
+  a. *Communication*
+
+      i. Colleagues, supervisors, or team members must be open to communication amongst each other. 
+
+  a. *Benefits*
+
+      i. We expect employees to not abuse their employment benefits. This can refer to time off, insurance, facilities, subscriptions, or other benefits our company offers. Refer to Human Resources for more information on benefits. 
+
+  a. *Policies*
+
+      i. All employees must comply with company policies. Questions should be directed to their hiring managers and/or Human Resources. 
+
+  a. *Disciplinary actions*
+
+      i. Repeated or intentional violation of the Code of Conduct Policy will be met with disciplinary action. Consequences will vary depending on the violation, but can include:  
+
+        1. demotion
+        1. reprimand
+        1. suspension or  termination 
+        1. detraction of benefits for a definite or indefinite time
+
+      ii. Cases of corruption, theft, embezzlement, or other unlawful behavior may call for legal action. 
+
+
+
+
+
+
--- a/themes/comply-soc2/policies/confidentiality.md
+++ b/themes/comply-soc2/policies/confidentiality.md
@@ -9,4 +9,92 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This policy outlines expected behavior of employees to keep confidential information about clients, partners, and our company secure. 
+
+a. This policy applies to all employees, board members, investors, and contractors, who may have access to confidential information. This policy must be made readily available to all whom it
+applies to.
+
+# Background
+
+a. The company's confidential information must be protected for two reasons:
+
+    i. It may be legally binding (i.e. sensitive customer data)
+
+    i. It may be fundamental to our business (i.e. business processes) 
+
+a. Common examples of confidential information in our company includes, but is not limited to: 
+
+    i. Unpublished financial information
+
+    i. Customer/partner/vendor/external party data
+
+    i. Patents, formulas, new technologies, and other intellectual property
+
+    i. Existing and prospective customer lists
+
+    i. Undisclosed business strategies including pricing & marketing
+
+    i. Materials & processes explicitly marked as “confidential”
+	
+a. Employees will have varying levels of authorized access to confidential information. 
+
+# Policy
+
+a. *Employee procedure for handling confidential information*
+
+    i. Lock and secure confidential information at all times
+
+    i. Safely dispose (i.e. shred) documents when no longer needed
+
+    i. View confidential information only on secure devices
+
+    i. Disclose information only when authorized and necessary
+
+    i. Do not use confidential information for personal gain, benefit, or profit
+
+    i. Do not disclose confidential information to anyone outside the company or to anyone within the company who does not have appropriate privileges 
+
+    i. Do not store confidential information or replicates of confidential information in unsecured manners (i.e. on unsecured devices) 
+
+    i. Do not remove confidential documents from company's premises unless absolutely necessary to move 
+
+a. *Offboarding measures*
+
+    i. The Hiring Manager should confirm the off-boarding procedure has been completed by final date of employment. 
+
+a. *Confidentiality measures*
+
+    i. The company will take the following measures to ensure protection of confidential information: 
+
+        1. Store and lock paper documents
+
+        1. Encrypt electronic information and implement appropriate technical measures to safeguard databases
+
+        1. Require employees to sign non-disclosure/non-compete agreements
+
+        1. Consult with senior management before granting employees access to certain confidential information 
+
+a. *Exceptions*
+
+    i. Under certain legitimate conditions, confidential information may need to be disclosed. Examples include: 
+
+        1. If a regulatory agency requests information as part of an audit or investigation
+
+        1. If the company requires disclosing information (within legal bounds) as part of a venture or partnership
+
+    i. In such cases, employee must request and receive prior written authorization from their hiring manager before disclosing confidential information to any third parties.
+
+a. *Disciplinary consequences* 
+
+    i. Employees who violate the confidentiality policy will face disciplinary and possible legal action. 
+
+    i. A suspected breach of this policy will trigger an investigation. Intentional violations will be met with termination and repeated unintentional violations may also face termination. 
+
+    i. This policy is binding even after the termination of employment. 
+
+
+
+
+  
--- a/themes/comply-soc2/policies/continuity.md
+++ b/themes/comply-soc2/policies/continuity.md
@@ -8,4 +8,89 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+
+# Purpose and Scope
+
+a.  The purpose of this policy is to ensure that the organization establishes objectives, plans and, procedures such that a major disruption to the organization’s key business activities is minimized.  
+
+a. This policy applies to all infrastructure and data within the organization’s information security program.
+
+a. This policy applies to all management, employees, and suppliers that are involved in decisions and processes affecting the organization’s business continuity. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a.  The success of the organization is reliant upon the preservation of critical business operations and essential functions used to deliver key products and services. The purpose of this policy is to define the criteria for continuing business operations for the organization in the event of a disruption. Specifically, this document defines:
+
+    i. The structure and authority to ensure business resilience of key processes and systems.
+
+    i. The requirements for efforts to manage through a disaster or other disruptive event when the need arises. 
+
+    i. The criteria to efficiently and effectively resume normal business operations after a disruption.
+
+a.  Within this document, the following definitions apply: 
+
+    i. *Business impact analysis/assessment* - an exercise that determines the impact of losing the support of any resource to an enterprise, establishes the escalation of that loss over time, identifies the minimum resources needed to return to a normal level of operation, and prioritizes recovery of processes and the supporting system. 
+
+    i. *Disaster recovery plan* - a set of human, physical, technical, and procedural resources to return to a normal level of operation, within a defined time and cost, when an activity is interrupted by an emergency or disaster. 
+    
+    i. *Recovery time objective* - the amount of time allowed for the recovery of a business function or resource to a normal level after a disaster or disruption occurs. 
+    
+    i. *Recovery point objective* - determined based on the acceptable data loss in the case of disruption of operations. 
+
+# Policy
+
+a.  *Business Risk Assessment and Business Impact Analysis*
+
+    i. Each manager is required to perform a business risk assessment and business impact analysis for each key business system within their area of responsibility. 
+
+    i. The business risk assessment must identify and define the criticality of key business systems and the repositories that contain the relevant and necessary data for the key business system. 
+
+    i. The business risk assessment must define and document the Disaster Recovery Plan (DRP) for their area of responsibility.  Each DRP shall include:
+    
+        1. Key business processes.
+        
+        1. Applicable risk to availability.
+
+        1. Prioritization of recovery.
+
+        1. Recovery Time Objectives (RTOs).
+
+        1. Recovery Point Objectives (RPOs).
+
+a.  *Disaster Recovery Plan*
+
+    i. Each key business system must have a documented DRP to provide guidance when hardware, software, or networks become critically dysfunctional or cease to function (short and long term outages).
+
+    i. Each DRP must include an explanation of the magnitude of information or system unavailability in the event of an outage and the process that would be implemented to continue business operations during the outage. Where feasible, the DRP must consider the use of alternative, off-site computer operations (cold, warm, hot sites).
+
+    i. Each plan must be reviewed against the organization’s strategy, objectives, culture, and ethics, as well as policy, legal, statutory and regulatory requirements.
+
+    i. Each DRP must include:
+
+        1. An emergency mode operations plan for continuing operations in the event of temporary hardware, software, or network outages.
+
+        1. A recovery plan for returning business functions and services to normal on-site operations. 
+
+        1. Procedures for periodic testing, review, and revisions of the DRP for all affected business systems, as a group and/or individually.
+
+a.  *Data Backup and Restoration Plans*
+
+    i. Each system owner must implement a data backup and restoration plan. 
+
+    i. Each data backup and restoration plan must identify:
+
+        1. The data custodian for the system.
+
+
+        1. The backup schedule of each system.
+
+
+        1. Where backup media is to be stored and secured, as well as how access is maintained.
+
+        1. Who may remove backup media and transfer it to storage.
+
+        1. Appropriate restoration procedures to restore key business system data from backup media to the system.
+ 
+        1. The restoration testing plan and frequency of testing to confirm the effectiveness of the plan. 
+
+        1. The method for restoring encrypted backup media. 
--- 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/datacenter.md
+++ b/themes/comply-soc2/policies/datacenter.md
@@ -8,4 +8,52 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define security procedures within the organization’s data centers and secure equipment areas.
+
+a. This policy applies to any cloud hosted providers and facilities within the organization that are labeled as either a data center or a secure equipment area. Such facilities are explicitly called out within this document.
+
+a. This policy applies to all management, employees and suppliers that conduct business operations within cloud host or data centers and secure equipment areas.
+
+# Background
+
+a. This policy defines the policies and rules governing data centers and secure equipment areas from both a physical and logical security perspective. The document lists all data centers and secure equipment areas in use by the organization, prescribes how access is controlled and enforced, and establishes procedures for any visitor or third party access. This policy also defines prohibited activities and requirements for periodic safety and security checks.
+
+# Policy
+
+a. The following locations are classified by the organization as secure areas and are goverened by this policy:
+
+    i. [list all data center locations and secure areas under the organization’s control]
+
+a. Each data center and secure area must have a manager assigned. The manager’s name must be documented in the organization’s records. In the case of any on-prem data centers, the manager’s name must also be posted in and near the secure area.
+
+a. Each secure area must be clearly marked. Access to the secure area must be controlled by at least a locked door. A visitor access log must be clearly marked and easily accessible just inside the door.
+
+a. Persons who are not employed by the organization are considered to be visitors. Visitors accessing secure areas shall:
+
+    i. Obtain access to secure areas in accordance with reference a.
+
+    i. Only enter and remain in secure areas when escorted by a designated employee. The employee must stay with the visitor during their entire stay inside the secure area.
+
+    i. Log the precise time of entry and exit in the visitor access log.
+
+a. The following activities are prohibited inside secure areas:
+
+    i. Photography, or video or audio recordings of any kind.
+
+    i. Connection of any electrical device to a power supply, unless specifically authorized by the responsible person.
+
+    i. Unauthorized usage of or tampering with any installed equipment.
+
+    i. Connection of any device to the network, unless specifically authorized by the responsible person.
+
+    i. Storage or archival of large amounts of paper materials.
+
+    i. Storage of flammable materials or equipment.
+
+    i. Use of portable heating devices.
+
+    i. Smoking, eating, or drinking.
+
+a. Secure areas must be checked for compliance with security and safety requirements on at least a quarterly basis.
--- 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/incident.md
+++ b/themes/comply-soc2/policies/incident.md
@@ -10,4 +10,102 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This security incident response policy is intended to establish controls to ensure detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches.
+
+a. This document also provides implementing instructions for security incident response, to include definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).
+
+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. A key objective of the organization’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. The organization is committed to protecting its employees, customers, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly. Despite this, incidents and data breaches are likely to happen; when they do, the organization is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving , and communicating information related to the breach.
+
+a. This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, the organization must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents. If a vulnerability is identified, it must be resolved within a set period of time based on its severity. If an incident is identified, it must be investigated within a set period of time based on its severity. If an incident is confirmed as a breach, a set procedure must be followed to contain, investigate, resolve, and communicate information to employees, customers, partners and other stakeholders.  
+
+c. Within this document, the following definitions apply:
+
+    i. *Information Security Vulnerability:* a vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorized access to information or to disrupt critical processing.
+
+    i. *Information Security Incident:* a suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.
+
+# Policy
+a. All users must report any system vulnerability , incident, or event pointing to a possible incident to the Information Security Manager (ISM) as quickly as possible but no later than 24 hours. Incidents must be reported by sending an email message to <insert email address here> with details of the incident.
+
+a. Users must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents. Failure to report information security incidents shall be considered to be a security violation and will be reported to the Human Resources (HR) Manager for disciplinary action.
+
+a. Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved in the event that they need to be used as evidence of a crime.
+
+a. All information security incidents must be responded to through the incident management procedures defined below.
+
+a. In order to appropriately plan and prepare for incidents, the organization must review incident response procedures at least once per year for currency, and update as required.
+
+a. The incident response procedure must be tested on at least twice per year
+
+a. The incident response logs must be reviewed once per month to assess response effectiveness.
+
+# Procedure For Establishing Incident Response System
+
+a. Define on-call schedule and assign an Information Security Manager (ISM) responsible for managing incident response procedure during each availability window.
+
+a. Define notification channel to alert the on-call ISM of a potential security incident.  Establish company resource that includes up to date contact information for on-call ISM.
+
+a. Assign management sponsors from the Engineering, Legal, HR, Marketing, and C-Suite teams.
+
+a. Distribute Procedure For Execute Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource. 
+
+a. Require all staff to complete training for Procedure For Executing Incident Response at least twice per year.
+
+# Procedure For Executing Incident Response
+
+a. When an information security incident is identified or detected, users must notify their immediate manager within 24 hours. The manager must immediately notify the ISM on call for proper response. The following information must be included as part of the notification:
+
+    i. Description of the incident
+
+    i. Date, time, and location of the incident
+
+    i. Person who discovered the incident
+
+    i. How the incident was discovered
+
+    i. Known evidence of the incident
+
+    i. Affected system(s)
+
+a. Within 48 hours of the incident being reported, the ISM shall conduct a preliminary investigation and risk assessment to review and confirm the details of the incident. If the incident is confirmed, the ISM must assess the impact to the organization and assign a severity level, which will determine the level of remediation effort required:
+
+    i. High: the incident is potentially catastrophic to the organization and/or disrupts the organization’s day-to-day operations; a violation of legal, regulatory or contractual requirements is likely.
+
+    i. Medium: the incident will cause harm to one or more business units within the organization and/or will cause delays to a business unit’s activities.
+
+    i. Low: the incident is a clear violation of organizational security policy, but will not substantively impact the business.
+
+
+a. The ISM, in consultation with management sponsors, shall determine appropriate incident response activities in order to contain and resolve incidents.
+
+a. The ISM must take all necessary steps to preserve forensic evidence (e.g. log information, files, images) for further investigation to determine if any malicious activity has taken place. All such information must be preserved and provided to law enforcement if the incident is determined to be malicious.
+
+a. If the incident is deemed as High or Medium, the ISM must work with the VP Brand/Creative, General Counsel, and HR Manager to create and execute a communications plan that communicates the incident to users, the public, and others affected.
+
+a. The ISM must take all necessary steps to resolve the incident and recover information systems, data, and connectivity. All technical steps taken during an incident must be documented in the organization’s incident log, and must contain the following:
+
+    i. Description of the incident
+
+    i. Incident severity level
+
+    i. Root cause (e.g. source address, website malware, vulnerability)
+
+    i. Evidence
+
+    i. Mitigations applied (e.g. patch, re-image)
+
+    i. Status (open, closed, archived)
+
+    i. Disclosures (parties to which the details of this incident were disclosed to, such as customers, vendors, law enforcement, etc.)
+
+a. After an incident has been resolved, the ISM must conduct a post mortem that includes root cause analysis and documentation any lessons learned.
+
+a. Depending on the severity of the incident, the Chief Executive Officer (CEO) may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.
+
+a. The ISM must notify all users of the incident, conduct additional training if necessary, and present any lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed as malicious.
--- a/themes/comply-soc2/policies/information.md
+++ b/themes/comply-soc2/policies/information.md
@@ -8,4 +8,86 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This information security policy defines the purpose, principles, objectives and basic rules for information security management.
+
+a. This document also defines procedures to implement high level information security protections within the organization, including definitions, procedures, responsibilities and performance measures (metrics and reporting mechanisms).
+
+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 high level objectives and implementation instructions for the organization’s information security program. It includes the organization’s information security objectives and requirements; such objectives and requirements are to be referenced when setting detailed information security policy for other areas of the organization. This policy also defines management roles and responsibilities for the organization’s Information Security Management System (ISMS). Finally, this policy references all security controls implemented within the organization.
+
+a. Within this document, the following definitions apply:
+
+    i. *Confidentiality*: a characteristic of information or information systems in which such information or systems are only available to authorized entities.
+
+    i. *Integrity*: a characteristic of information or information systems in which such information or systems may only be changed by authorized entities, and in an approved manner.
+
+    i. *Availability*: a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
+
+    i. *Information Security*: the act of preserving the confidentiality, integrity, and, availability of information and information systems.
+
+    i. *Information Security Management System (ISMS)*: the overall management process that includes the planning, implementation, maintenance, review, and, improvement of information security.
+
+# References
+
+a. Encryption Policy
+
+a. Data Center Security Policy
+
+a. Disaster Recovery Policy
+
+a. Password Policy
+
+a. Remote Access Policy
+
+a. Removable Media/Cloud Storage/BYOD Policy
+
+a. Risk Assessment Policy
+
+a. Security Incident Response Policy
+
+a. Software Development Lifecycle Policy
+
+a. System Availability Policy
+
+a. Workstation Security Policy 
+
+# Policy
+
+a. *Managing Information Security*
+
+    i. The organization’s main objectives for information security include the following:
+
+        1. [list the reasons/objectives for maintaining information security at the organization. Examples include a better market image, reduced risk of data breaches and compromises, and compliance with legal, regulatory, and contractual requirements.]
+
+    i. The organization’s objectives for information security are in line with the organization’s business objectives, strategy, and plans.
+
+    i. Objectives for individual security controls or groups of controls are proposed by the company management team, including but not limited to [list key roles inside the organization that will participate in information security matters], and others as appointed by the CEO; these security controls are approved by the CEO in accordance with the Risk Assessment Policy (Reference (a)).
+
+    i. All objectives must be reviewed at least once per year.
+
+    i. The company will measure the fulfillment of all objectives. The measurement will be performed at least once per year. The results must be analyzed, evaluated, and reported to the management team.
+
+a. *Information Security Requirements* 
+
+    i. This policy and the entire information security program must be compliant with legal and regulatory requirements as well as with contractual obligations relevant to the organization.
+
+    i. All employees, contractors, and other individuals subject to the organization’s information security policy must read and acknowledge all information security policies.
+
+    i. The process of selecting information security controls and safeguards for the organization is defined in Reference (a).
+
+    i. The organization prescribes guidelines for remote workers as part of the Remote Access Policy (reference (b)).
+
+    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/log.md
+++ b/themes/comply-soc2/policies/log.md
@@ -8,4 +8,60 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This log management and review policy defines specific requirements for information systems to generate, store, process, and aggregate appropriate audit logs across the organization’s entire environment in order to provide key information and detect indicators of potential compromise.
+
+a. This policy applies to all information systems within the organization’s production network.
+
+a. This policy applies to all employees, contractors, and partners of the organization that administer or provide maintenance on the organization’s production systems. Throughout this policy, these individuals are referred to as system administrators.
+
+# Background
+
+a. In order to measure an information system’s level of security through confidentiality, integrity, and availability, the system must collect audit data that provides key insights into system performance and activities. This audit data is collected in the form of system logs. Logging from critical systems, applications, and services provides information that can serve as a starting point for metrics and incident investigations. This policy provides specific requirements and instructions for how to manage such logs.
+
+# Policy
+
+a. All production systems within the organization shall record and retain audit-logging information that includes the following information:
+
+    i. Activities performed on the system.
+
+    i. The user or entity (i.e. system account) that performed the activity, including the system that the activity was performed from.
+    
+    i. The file, application, or other object that the activity was performed on.
+    
+    i. The time that the activity occurred.
+
+    i. The tool that the activity was performed with.
+
+    i. The outcome (e.g., success or failure) of the activity.
+
+a. Specific activities to be logged must include, at a minimum:
+
+    i. Information (including authentication information such as usernames or passwords) is created, read, updated, or deleted. 
+
+    i. Accepted or initiated network connections. 
+
+    i. User authentication and authorization to systems and networks.
+
+    i. Granting, modification, or revocation of access rights, including adding a new user or group; changing user privileges, file permissions, database object permissions, firewall rules, and passwords.
+
+    i. System, network, or services configuration changes, including software installation, patches, updates, or other installed software changes.
+  
+    i. Startup, shutdown, or restart of an application. 
+  
+    i. Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault.
+
+    i. Detection of suspicious and/or malicious activity from a security system such as an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.
+
+a. Unless technically impractical or infeasible, all logs must be aggregated in a central system so that activities across different systems can be correlated, analyzed, and tracked for similarities, trends, and cascading effects. Log aggregation systems must have automatic and timely log ingest, event and anomaly tagging and alerting, and ability for manual review.
+
+a. Logs must be manually reviewed on a regular basis:
+  
+    i. The activities of users, administrators and system operators must be reviewed on at least a monthly basis.
+
+    ii. Logs related to PII must be reviewed on at least a monthly basis in order to identify unusual behavior.
+
+a. When using an outsourced cloud environment, logs must be kept on cloud environment access and use, resource allocation and utilization, and changes to PII. Logs must be kept for all administrators and operators performing activities in cloud environments.
+
+a. All information systems within the organization must synchronize their clocks by implementing Network Time Protocol (NTP) or a similar capability. All information systems must synchronize with the same primary time source.
--- a/themes/comply-soc2/policies/office.md
+++ b/themes/comply-soc2/policies/office.md
@@ -8,4 +8,92 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope
+
+a. This policy establishes the rules governing controls, monitoring, and removal of physical access to company’s facilities.
+
+a. This policy applies to all staff, contractors, or third parties who require access to any physical location owned, operated, or otherwise occupied by the company. A separate policy exists for governing access to the company data center. 
+
+# Policy
+
+a. *Management responsibilities*
+
+    i. Management shall ensure:
+
+        1. appropriate entry controls are in place for secure areas
+
+        1. security personnel, identification badges, or electronic key cards should be used to validate employee access to facilities
+
+        1. confirm visitor & guest access procedure has been followed by host staff 
+        
+        1. management periodically reviews list of individuals with physical access to facilities 
+        
+        1. card access records and visitor logs are kept for a minimum of 90 days and are periodically reviewed for unusual activity 
+
+a. *Key access & card systems*
+      
+    i. The following policies are applied to all facility access cards/keys:
+    
+        1. Access cards/keys shall not be shared or loaned to others
+      
+        1. Access cards/keys shall not have identifying information other than a return mail address
+      
+        1. Access cards/keys shall be returned to Human Resources when they are no longer needed
+      
+        1. Lost or stolen access cards/keys shall be reported immediately 
+      
+        1. If an employee changes to a role that no longer requires physical access or leaves the company, their access cards/keys will be suspended 
+      
+        1. Human Resources will regularly review physical security privileges and review access logs 
+
+\pagebreak 
+
+a. *Staff & contractor access procedure* 
+
+    i. Access to physical locations is granted to employees and contractors based on individual job function and will be granted by Human Resources. 
+
+    i. Any individual granted access to physical spaces will be issued a physical key or access key card. Key and card issuance is tracked by Human Resources and will be periodically reviewed. 
+
+    i. In the case of termination, Human Resources should ensure immediate revocation of access 
+(i.e. collection of keys, access cards, and any other asset used to enter facilities) through the offboarding procedure. 
+
+a. *Visitor & guest access procedure*
+	
+    i. The following policies are applied to identification & authorization of visitors and guests:
+
+        1. All visitors must request and receive written onsite authorization from a staff member. 
+
+        1. Visitor access shall be tracked with a sign in/out log. The log shall contain:visitor’s name, firm represented, purpose of visit, and onsite personnel authorizing access
+
+        1. The log shall be retained for a minimum of 90 days
+
+        1. Visitors shall be given a badge or other identification that visibly distinguishes visitors from onsite personnel 
+
+        1. Visitor badges shall be surrendered before leaving the facility
+
+a. *Audit controls & management*
+
+    i. Documented procedures and evidence of practice should be in place for this policy. Acceptable controls and procedures include:
+
+        1. visitor logs
+
+        1. access control procedures
+        
+        1. operational key-card access systems
+        
+        1. video surveillance systems (with retrievable data)
+        
+        1. ledgers if issuing physical keys 
+
+a. *Enforcement*
+
+    i. Employees, contractors, or third parties found in violation of this policy (whether intentional or accidental) may be subject to disciplinary action, including:
+      
+        1. reprimand
+        
+        1. loss of access to premises
+        
+        1. termination
+
+
+
--- a/themes/comply-soc2/policies/password.md
+++ b/themes/comply-soc2/policies/password.md
@@ -8,4 +8,32 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope 
+
+a. The Password Policy describes the procedure to select and securely manage passwords. 
+
+a. This policy applies to all employees, contractors, and any other personnel who have an account on any system that resides at any company facility or has access to the company network.  
+
+# Policy
+
+a. *Rotation requirements* 
+
+    i. All system-level passwords should be rotated on at least a quarterly basis. All user-level passwords should be rotated at least every six months. 
+
+    i. If a credential is suspected of being compromised, the password in question should be rotated immediately and the Engineering/Security team should be notified. 
+
+a. Password protection
+
+    i. All passwords are treated as confidential information and should not be shared with anyone. If you receive a request to share a password, deny the request and contact the system owner for assistance in provisioning an individual user account. 
+
+    i. Do not write down passwords, store them in emails, electronic notes, or mobile devices, or share them over the phone. If you must store passwords electronically, do so with a password manager that has been approved by IT. If you truly must share a password, do so through a designated password manager or grant access to an application through a single sign on provider. 
+
+    i. Do not use the “Remember Password” feature of applications and web browsers. 
+
+    i. If you suspect a password has been compromised, rotate the password immediately and notify engineering/security. 
+
+a. Enforcement
+
+    i. An employee or contractor found to have violated this policy may be subject to disciplinary action. 
+
+
--- a/themes/comply-soc2/policies/policy.md
+++ b/themes/comply-soc2/policies/policy.md
@@ -7,5 +7,24 @@ majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
 ---
+# Purpose and Scope

-# Coming Soon
+a. This policy addresses policy education requirements for employees and contractors. 
+
+a. This policy applies to all full-time employees, part-time employees, and contractors. Adherence to assigned policies is binding under their Employment Offer Letter and/or Independent Contractor Agreement. 
+
+# Applicability
+
+a. Upon hire of a new employee or contractor, the Hiring Manager will determine which subsets of policies will apply to that individual. The individual will have five working days to read the assigned policies. The following will be logged in the Policy Training Policy Ledger:
+    
+    i. Assignment date
+    
+    i. Completion date
+    
+    i. Policy
+    
+    i. Assignee
+    
+    i. Assigner
+    
+    i. Notes
--- 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/workstation.md
+++ b/themes/comply-soc2/policies/workstation.md
@@ -8,4 +8,44 @@ majorRevisions:
    comment: Initial document
 ---

-# Coming Soon
+# Purpose and Scope 
+
+a. This policy defines best practices to reduce the risk of data loss/exposure through workstations. 
+
+a. This policy applies to all employees and contractors. Workstation is defined as the collection of all company-owned and personal devices containing company data. 
+
+# Policy 
+
+a. Workstation devices must meet the following criteria:
+    
+    i. Operating system must be no more than one generation older than current
+    
+    i. Device must be encrypted at rest
+    
+    i. Device must be locked when not in use or when employee leaves the workstation 
+    
+    i. Workstations must be used for authorized business purposes only 
+    
+    i. Loss or destruction of devices should be reported immediately 
+    
+    i. Laptops and desktop devices should run the latest version of antivirus software that has been approved by IT 
+
+a. *Desktop & laptop devices*
+
+    i. Employees will be issued a desktop, laptop, or both by the company, based on their job duties. Contractors will provide their own laptops. 
+
+	  i. Desktops and laptops must operate on macOS or Windows.
+
+a. *Mobile devices*
+
+    i. Mobile devices must be operated as defined in the Removable Media Policy, Cloud Storage, and Bring Your Own Device Policy. 
+
+    i. Mobile devices must operate on iOS or Android.
+
+    i. Company data may only be accessed on mobile devices with Slack and Gmail. 
+
+a. *Removable media*
+
+    i. Removable media must be operated as defined in the Removable Media Policy, Cloud Storage, and Bring Your Own Device Policy. 
+
+    i. Removable media is permitted on approved devices as long as it does not conflict with other policies. 
--- a/themes/comply-soc2/templates/index.ace
+++ b/themes/comply-soc2/templates/index.ace
@@ -13,11 +13,15 @@ html lang=en
    = javascript
      document.addEventListener("DOMContentLoaded", function(event) {
        document.querySelectorAll('.cron').forEach(function(el) {
-          el.innerHTML = prettyCron.toString(el.innerHTML)
+          el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
        })
      })

      function show(name) {
+        if (history.replaceState) {
+            history.replaceState(null, null, '#'+name)
+        }
+
        var items = document.getElementsByClassName('top-nav')
        for (var i=0; i<items.length; i++) {
          var item = items[i]
@@ -220,5 +224,14 @@ html lang=en
        .content.has-text-centered
          p {{.Project.OrganizationName}} Confidential 2018
  = javascript
-    // commented for development
-    show('overview')
+    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)
+        }
+      }
+    }
Author	SHA1	Message	Date
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
Justin McCarthy	fed98f76e7	increment patch for release (via Makefile)	2018-05-17 18:28:47 -07:00
Justin McCarthy	8070ea37bc	automated asset refresh (via Makefile)	2018-05-17 18:28:39 -07:00
Justin McCarthy	e04e5d7d89	switch cron to 6-figure expressions. introduce hashes by tab.	2018-05-17 18:27:21 -07:00
Manisha Singh	65c0a598ad	Initial commit to Workstation	2018-05-17 17:12:31 -07:00
Manisha Singh	40e08cf5ba	Initial commit to system changes	2018-05-17 17:06:50 -07:00
Manisha Singh	39657f3cac	Initial commit of Incident response	2018-05-17 16:56:14 -07:00
Manisha Singh	ed41a4364a	Testing VS code git integration	2018-05-17 16:42:06 -07:00
Manisha Singh	423dc4d0f6	Initial commit of Policy Training	2018-05-17 16:30:49 -07:00
Manisha Singh	8480003113	Initial commit of Password	2018-05-17 15:51:42 -07:00
Manisha Singh	859124e842	Initial commit of Office Security	2018-05-17 15:24:42 -07:00
Manisha Singh	b6ab6c5f64	Initial commit of Log Management	2018-05-17 14:29:37 -07:00
Manisha Singh	db63ad64e5	Initial commit of Information Security	2018-05-17 12:46:13 -07:00
Manisha Singh	c070363fb7	Initial commit of Datacenter	2018-05-17 12:27:15 -07:00
Manisha Singh	b9350ac83d	Initial commit of Confidentiality	2018-05-17 12:05:44 -07:00
Manisha Singh	fd89b6a5de	Initial commit to Code of Conduct	2018-05-17 11:41:46 -07:00
Manisha Singh	8cb7dc7bf8	Initial commit of Business Continuity	2018-05-17 11:00:58 -07:00
Justin McCarthy	91f16e4729	also watch narratives dir	2018-05-16 17:27:01 -07:00
Justin McCarthy	1ddb9217a0	move default satisfaction from org to change policy	2018-05-16 17:26:44 -07:00
Justin McCarthy	a5651a5cd7	increment patch for release (via Makefile)	2018-05-16 16:52:09 -07:00
Justin McCarthy	54d84b0eed	automated asset refresh (via Makefile)	2018-05-16 16:52:00 -07:00
Justin McCarthy	28a9f1d3a3	make updating homebrew formula easier	2018-05-16 16:51:51 -07:00
@@ -1 +1 @@
 .1.17
 .1.21