More policy reorganization

## Approval required pages. See also "Controlled Documents" for more from this section.

[Security Operations]

/content/handbook/security/standards/security-logging-standard.md @mcoons @joshlemos @jfuentes2 @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/policies_and_standards/security-logging-standard.md @mcoons @joshlemos @jfuentes2 @gitlab-com/egroup @gitlab-com/content-sites

^[solutions-architects]

/content/handbook/solutions-architects/ @jfullam

/content/handbook/people-group/offboarding/offboarding_standards.md @rallen3 @kiacobucci @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/people-policies/_index.md @cgudgenov @emilyplotkin @rallen3 @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/controlled-document-procedure.md @joshlemos @jlongo_gitlab @juliedavila @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/standards/cryptographic-standard.md @joshlemos @jlongo_gitlab @juliedavila @mloveless @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/standards/data-classification-standard.md @joshlemos @jlongo_gitlab @juliedavila @tdilbeck @emccrann @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/policies_and_standards/cryptographic-standard.md @joshlemos @jlongo_gitlab @juliedavila @mloveless @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/policies_and_standards/data-classification-standard.md @joshlemos @jlongo_gitlab @juliedavila @tdilbeck @emccrann @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/isms.md @joshlemos @jlongo_gitlab @juliedavila @corey-oas @cynthiamiller @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/standards/password-standard.md @joshlemos @jlongo_gitlab @juliedavila @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/standards/physical-security-standard-for-company-assets.md @joshlemos @jlongo_gitlab @juliedavila @jdicken @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/policies_and_standards/password-standard.md @joshlemos @jlongo_gitlab @juliedavila @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/policies_and_standards/physical-security-standard-for-company-assets.md @joshlemos @jlongo_gitlab @juliedavila @jdicken @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/product-security/vulnerability-management/_index.md @juliedavila @estrike @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/standards/records-retention-deletion.md @joshlemos @jlongo_gitlab @juliedavila @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/policies_and_standards/records-retention-deletion.md @joshlemos @jlongo_gitlab @juliedavila @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/security-and-technology-policies/access-management-policy.md @joshlemos @jlongo_gitlab @juliedavila @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/security-and-technology-policies/audit-logging-policy.md @joshlemos @jlongo_gitlab @juliedavila @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/security-assurance/governance/sec-training.md @cynthiamiller @tdilbeck @corey-oas @jlongo_gitlab @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/security-operations/sirt/sec-incident-response.md @joshlemos @cibericua @mcoons @cmoberly @rdickson1 @nslaughter @mjozenazemian @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/security-operations/sirt/security-incident-communication-plan.md @joshlemos @cibericua @mcoons @cmoberly @rdickson1 @nslaughter @mjozenazemian @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/security-operations/sirt/severity-matrix.md @joshlemos @cibericua @mcoons @cmoberly @rdickson1 @nslaughter @mjozenazemian @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/standards/software-development-lifecycle-standard.md @joshlemos @jlongo_gitlab juliedavila @cibericua @jdicken @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/security/policies_and_standards/software-development-lifecycle-standard.md @joshlemos @jlongo_gitlab juliedavila @cibericua @jdicken @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/support/workflows/personal_data_access_account_deletion.md @lyle @gitlab-com/egroup @gitlab-com/content-sites

/content/handbook/support/workflows/account_deletion_access_request_workflows.md @lyle @BronwynBarnett @gitlab-com/egroup @gitlab-com/content-sites

## <i class="fas fa-users" id="biz-tech-icons"></i> Links to GitLab Policies

1. <https://handbook.gitlab.com/handbook/security/security-and-technology-policies/access-management-policy/>

2. <https://handbook.gitlab.com/handbook/security/standards/password-standard/>

2. <https://handbook.gitlab.com/handbook/security/policies_and_standards/password-standard/>

3. <https://handbook.gitlab.com/handbook/security/security-and-technology-policies/change-management-policy/>

4. <https://handbook.gitlab.com/handbook/security/security-and-technology-policies/audit-logging-policy/>

5. <https://handbook.gitlab.com/handbook/business-technology/entapps-documentation/policies/gitlab-business-continuity-plan/>

| group_owner_slack_channel | Text | Add the Slack channel where the group owner  can be reached out for help. Example: #infrastructure-lounge | MR Author and contributors |

| business_owner | Text | The Business Owner is the individual(s) responsible for all budget and decision making around the tool. They should define how the tool is used and by whom. This person(s) usually has login access to the tool as `Owner` but login access isn't necessary in all cases. Please make sure you list individual people in this field, rather than teams. Example: Jane Doe, John Doe | MR Author and contributors |

| technical_owner | Text | The Technical Owner(s) all the `administrators` of a tool. This includes everyone with the administrative clearance to provision and deprovision access of a tool and/or as the technical expertise needed to manage it. Example: Jane Doe, John Doe. See guidance [above](/handbook/business-technology/tech-stack-applications/#tech-stack-definitions) for instances where a system does not require/have an administrator function | MR Author and contributors |

| data_classification | Text (Red, Orange, Yellow, Green) or Unknown** | Decided upon by the Security team, please leave as `null` while this process is completed. More information on [Data Classification Standards](/handbook/security/standards/data-classification-standard/).| Security Risk |

| data_classification | Text (Red, Orange, Yellow, Green) or Unknown** | Decided upon by the Security team, please leave as `null` while this process is completed. More information on [Data Classification Standards](/handbook/security/policies_and_standards/data-classification-standard/).| Security Risk |

| authentication_method | Text (Okta SWA, Okta SAML, ID and password, other) or Unknown** | Authentication method used to access the system. It can be [SWA](https://help.okta.com/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm), [SAML](https://support.okta.com/help/s/article/okta-saml?language=en_US) or other such as direct access (email and password login).  | MR Author and contributors |

|critical_systems_tier|Text (Tier 1 Mission Critical, Tier 2 Business Critical, Tier 3 Business Operational, Tier 4 Administrative, TBD) or Unknown**|This field classifies the system based on GitLab's [Critical System Tier Definitions](/handbook/security/security-assurance/security-risk/storm-program/critical-systems/). The assignment of a critical system tier is dependent on the completion of a [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis/) (BIA) questionnaire. The Security Risk Team will coordinate the completion of a BIA if it has not yet been completed at the time a system is being added to the Tech Stack.|Security Risk|

| collected_data | Text or Unknown**  | Data that is collected by the tool | MR Author and contributors |

We make things public by default because [transparency is one of our values](/handbook/values/#transparency).

Some things can't be made public and are either [internal](#internal) to the company or have [limited access](#limited-access) even within the company.

If something isn't listed in the sections below please refer to Security's [Data Classification Standard](/handbook/security/standards/data-classification-standard/) and Legal's [SAFE Framework](/handbook/legal/safe-framework/) in the Handbook for additional guidance.

If something isn't listed in the sections below please refer to Security's [Data Classification Standard](/handbook/security/policies_and_standards/data-classification-standard/) and Legal's [SAFE Framework](/handbook/legal/safe-framework/) in the Handbook for additional guidance.

### Internal

The [Privacy Team](/handbook/legal/privacy/) (part of GitLab’s Legal and Corporate Affairs Team) provides support and guidance to uphold consistent business processes around the protection of personal data. Privacy Team members collaborate cross-functionally and serve as advocates to ensure that the data privacy practices of GitLab meet the needs of our cross-functional partners and are continually balanced with an ever-changing global data privacy and protection landscape.

The GitLab [Data Classification Standard](/handbook/security/standards/data-classification-standard/) defines data categories and provides a matrix of security and privacy controls for the purposes of determining the level of protection to be applied to GitLab data throughout its lifecycle.

The GitLab [Data Classification Standard](/handbook/security/policies_and_standards/data-classification-standard/) defines data categories and provides a matrix of security and privacy controls for the purposes of determining the level of protection to be applied to GitLab data throughout its lifecycle.

As part of our commitment to privacy, GitLab ensures that, where appropriate, projects and personal data processing activities are subject to Privacy Reviews and a [Data Protection Impact Assessment](/handbook/legal/privacy/dpia/) (DPIA) as key components of a ‘Privacy by Design’ approach.