jburrows001 Added remaining guidance docs to handbook

source/handbook/engineering/security/guidance/AM.1.01_inventory_management.html.md

-# WIP - AM.1.01 - Inventory Management
+---
+layout: markdown_page
+title: "AM.1.01 - Inventory Management Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# AM.1.01 - Inventory Management
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/BC.1.01_business_continuity_plan.html.md

-# WIP - BC.1.01 - Business Continuity Plan
+---
+layout: markdown_page
+title: "BC.1.01 - Business Continuity Plan Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# BC.1.01 - Business Continuity Plan
 
 ## Control Statement
 
@@ -11,6 +22,15 @@ The review cycle for business continuity plans are designed to ensure all inform
 ## Scope
 
 The business continuity plan is comprehensive by nature and will impact all GitLab stakeholders.
+The scope of a Business Continuity Plan can be categorized into the following seven steps:
+
+Identify the critical business functions
+Identify the critical systems & its dependencies
+Identify the risks to business
+Specify and confirm the data backup and recovery plan are working efficiently.
+Clearly document the functions and procedures of the BC plan, who should lead the effort and who are all the players involved
+Prepare a detailed communication plan
+Test, assess, learn and improve
 
 ## Ownership
 

source/handbook/engineering/security/guidance/BC.1.03_continuity_testing.html.md

-# WIP - BC.1.03 - Continuity Testing
+---
+layout: markdown_page
+title: "BC.1.03 - Continuity Testing Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# BC.1.03 - Continuity Testing
 
 ## Control Statement
 
@@ -11,7 +22,11 @@ GitLab performs business contingency and disaster recovery tests quarterly and e
 
 ## Context
 
-The business continuity plan is only useful if it is both maintained and validated. The testing part of this process is meant to be that validation and determines the efficacy of the plan. The purpose of this control is to determine if the business continuity plan would work in the event of a disruption to normal GitLab operations.
+The business continuity plan is only useful if it is both maintained and validated. The testing part of this process is meant to be that validation and determines the efficacy of the plan. The purpose of this control is to determine if the business continuity plan would work in the event of a disruption to normal GitLab operations.  The BC plan these three main categories:
+
+* Recovery Planning:  Ensuring that Recovery processes and procedures are executed and maintained to timely restoration of systems or assets affected by any disruptive event.
+* Improvements:  Recovery planning and processes are improved by incorporating lessons learned into future activities.
+* Communications:  Restoration activities are coordinated with internal and external parties, such as coordinating centers, Internet Service Providers, system owners, victims and vendors.
 
 ## Scope
 

source/handbook/engineering/security/guidance/BC.1.04_business_impact_analysis.html.md

-# WIP - BC.1.04 - Business Impact Analysis
+---
+layout: markdown_page
+title: "BC.1.04 - Business Impact Analysis Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# BC.1.04 - Business Impact Analysis
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/BU.1.01_backup_configuration.html.md

-# WIP - BU.1.01 - Backup Configuration
+---
+layout: markdown_page
+title: "BU.1.01 - Backup Configuration Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# BU.1.01 - Backup Configuration
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/BU.1.02_resilience_testing.html.md

-# WIP - BU.1.02 - Resilience Testing
+---
+layout: markdown_page
+title: "BU.1.02 - Resilience Testing Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# BU.1.02 - Resilience Testing
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/CM.1.01_change_management_workflow.html.md

-# WIP - CM.1.01 - Change Management Workflow
+---
+layout: markdown_page
+title: "CM.1.01 - Change Management Workflow Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# CM.1.01 - Change Management Workflow
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/CM.1.02_change_approval.html.md

-# WIP - CM.1.02 - Change Approval
+---
+layout: markdown_page
+title: "CM.1.02 - Change Approval Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# CM.1.02 - Change Approval
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/CON.1.01_baseline_configuration_standard.html.md

-# WIP - CON.1.01 - Baseline Configuration Standard
+---
+layout: markdown_page
+title: "CON.1.01 - Baseline Configuration Standard Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# CON.1.01 - Baseline Configuration Standard
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/CON.1.03_configuration_checks.html.md

-# WIP - CON.1.03 - Configuration Checks
+---
+layout: markdown_page
+title: "CON.1.03 - Configuration Checks Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# CON.1.03 - Configuration Checks
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/CON.1.04_configuration_check_reconciliation.html.md

-# WIP - CON.1.04 - Configuration Check Reconciliation: CMDB
+---
+layout: markdown_page
+title: "CON.1.04 - Configuration Check Reconciliation: CMDB Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# CON.1.04 - Configuration Check Reconciliation: CMDB
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/CON.1.07_default_device_passwords.html.md

-# WIP - CON.1.07 - Default Device Passwords
+---
+layout: markdown_page
+title: "CON.1.07 - Default Device Passwords Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# CON.1.07 - Default Device Passwords
 
 ## Control Statement
 

source/handbook/engineering/security/guidance/DM.2.01_terms_of_service.html.md

+---
+layout: markdown_page
+title: "DM.2.01 - Terms of Service Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# DM.2.01 - Terms of Service
+
+## Control Statement
+
+Consent is obtained for GitLab's Terms of Service (ToS) prior to collecting personal information and when the ToS is updated.
+
+## Context
+
+One of the purposes of a ToS is to provide users specific information about what personal information GitLab collects and alert them when that agreement is changed. This promotes transparency and allows users to make informed choices. The purpose of this control is to ensure the ToS includes information on what personal information is collected and a mechanism to alert users of any changes is in place.
+
+## Scope
+
+This control applies to GitLab's ToS.
+
+## Ownership
+
+TBD
+
+## Implementation Guidance
+
+For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.2.01_terms_of_service.md).
+
+## Reference Links
+
+For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.2.01_terms_of_service.md).
+
+## Examples of evidence an auditor might request to satisfy this control
+
+For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.2.01_terms_of_service.md).
+
+## Framework Mapping
+
+* SOC2 CC
+  * CC2.3

source/handbook/engineering/security/guidance/DM.4.01_encryption_of_data_in_transit.html.md

+---
+layout: markdown_page
+title: "DM.4.01 - Encryption of Data in Transit Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# DM.4.01 - Encryption of Data in Transit
+
+## Control Statement
+
+GitLab encrypts red, orange, and yellow data transmitted over public networks.
+
+## Context
+
+Encrypting data transmitted over public networks helps ensure the confidentiality and integrity of that data. Without encryption, data in transit over public networks can easily be intercepted using automated, open source tools and viewed and maliciously modified by malicious actors.
+
+## Scope
+
+Encrypting data in transit over public networks applies to all red, orange, and yellow data.
+
+## Ownership
+
+TBD
+
+## Implementation Guidance
+
+For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.01_encryption_of_data_in_transit.md).
+
+## Reference Links
+
+For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.01_encryption_of_data_in_transit.md).
+
+## Examples of evidence an auditor might request to satisfy this control
+
+For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.01_encryption_of_data_in_transit.md).
+
+## Framework Mapping
+
+* ISO
+  * A.13.2.3
+  * A.14.1.2
+  * A.14.1.3
+  * A.18.1.4
+  * A.18.1.5
+* SOC2 CC
+  * CC6.7
+* PCI
+  * 2.3
+  * 4.1
+  * 4.1.1
+  * 8.2.1

source/handbook/engineering/security/guidance/DM.4.02_encryption_of_data_at_rest.html.md

+---
+layout: markdown_page
+title: "DM.4.02 - Encryption of Data at Rest Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# DM.4.02 - Encryption of Data at Rest
+
+## Control Statement
+
+Red, orange, and yellow data at rest is encrypted.
+
+## Context
+
+Encrypting data at rest helps ensure the confidentiality and integrity of that data. In the event a production instance, data store, or backup is compromised, without encryption, the data is near certain to be accessed, modified, and/or stolen. Encrypting sensitive data at rest adds another roadblock and layer of complexity for the adversary and helps protect customer, employee, and partner data.
+
+## Scope
+
+This control applies to red, orange, and yellow data.
+
+## Ownership
+
+TBD
+
+## Implementation Guidance
+
+For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.02_encryption_of_data_at_rest.md).
+
+## Reference Links
+
+For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.02_encryption_of_data_at_rest.md).
+
+## Examples of evidence an auditor might request to satisfy this control
+
+For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.02_encryption_of_data_at_rest.md).
+
+## Framework Mapping
+
+* ISO
+  * A.18.1.4
+  * A.18.1.5
+  * A.8.2.3
+* PCI
+  * 3.4
+  * 3.5
+  * 3.5.3
+  * 3.6
+  * 3.6.3
+  * 8.2.1

source/handbook/engineering/security/guidance/DM.7.01_secure_disposal_of_media.html.md

+---
+layout: markdown_page
+title: "DM.7.01 - Secure Disposal of Media Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# DM.7.01 - Secure Disposal of Media
+
+## Control Statement
+
+GitLab securely erases media containing decommissioned red and orange data and obtains a certificate or log of erasure; media pending erasure are stored within a secured facility.
+
+## Context
+
+Securely disposing of both electronic and physical media adds a layer of protection from the data being disposed being recovered by unauthorized persons. There are several effective, publicly available tools and techniques to recover data from electronic and physical media, including hard drives and shredded paper. This control aims to reduce the risk of data being recovered by unauthorized persons and shows customers, GitLabbers, and partners we take measures to protect their data even after it's done being used.
+
+## Scope
+
+This control applies to both electronic and physical (for example, paper printouts) media.
+
+## Ownership
+
+TBD
+
+## Implementation Guidance
+
+For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.7.01_secure_disposal_of_media.md).
+
+## Reference Links
+
+For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.7.01_secure_disposal_of_media.md).
+
+## Examples of evidence an auditor might request to satisfy this control
+
+For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.7.01_secure_disposal_of_media.md).
+
+
+
+## Framework Mapping
+
+* ISO
+  * A.11.2.7
+  * A.8.3.2
+* SOC2 CC
+  * CC6.5
+* PCI
+  * 9.8
+  * 9.8.1
+  * 9.8.2

source/handbook/engineering/security/guidance/IAM.1.01_logical_access_provisioning.html.md

+---
+layout: markdown_page
+title: "IAM.1.01 - Logical Access Provisioning Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# IAM.1.01 - Logical Access Provisioning
+
+## Control Statement
+
+Logical access provisioning to information systems requires approval from appropriate personnel.
+
+## Context
+
+The purpose of this control is to ensure there is a process in place to review and authorize new user account requests. Ensuring only people who require access to a system or service receive access helps improve GitLab's overall security posture by limiting the number of accounts with access and reducing the overall likelihood of an account being compromised.
+
+## Scope
+
+This control applies to any system or service where user accounts can be provisioned.
+
+## Ownership
+
+TBD
+
+## Implementation Guidance
+
+For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.01_logical_access_provisioning.md).
+
+## Reference Links
+
+For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.01_logical_access_provisioning.md).
+
+## Examples of evidence an auditor might request to satisfy this control
+
+For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.01_logical_access_provisioning.md).
+
+## Framework Mapping
+
+* ISO
+  * A.9.2.1
+  * A.9.2.2
+  * A.9.2.3
+  * A.9.4.1
+  * A.12.5.1
+  * A.18.1.3
+* SOC2 CC
+  * CC6.1
+  * CC6.2
+  * CC6.3
+  * CC6.6
+  * CC6.7
+* PCI
+  * 7.1.4
+  * 8.1.2

source/handbook/engineering/security/guidance/IAM.1.02_logical_access_deprovisioning.html.md

+---
+layout: markdown_page
+title: "IAM.1.02 - Logical Access De-Provisioning Control Guidance"
+---
+
+## On this page
+{:.no_toc}
+
+- TOC
+{:toc}
+
+# IAM.1.02 - Logical Access De-Provisioning
+
+## Control Statement
+
+Logical access that is no longer required in the event of a termination is documented, communicated to management, and revoked.
+
+## Context
+
+The purpose of this control is to ensure there is a process in place to remove access to user accounts that is no longer necessary. This control helps ensure that only authorized and active accounts can be accessed and used to prevent any unauthorized use or access of GitLab customer, GitLab teammember, and partner data.
+
+## Scope
+
+This control applies to any system or service where user accounts can be provisioned.
+
+## Ownership
+
+TBD
+
+## Implementation Guidance
+
+For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.02_logical_access_deprovisioning.md).