Skip to content
Snippets Groups Projects
Commit 64832a18 authored by Cynthia "Arty" Ng's avatar Cynthia "Arty" Ng :speech_balloon: Committed by Jamie Allen
Browse files

Change ref links to regular links

parent c995bdb2
No related branches found
No related tags found
1 merge request!11512Change ref links to regular links
Showing
with 76 additions and 76 deletions
......@@ -5,6 +5,6 @@ description: "The READMEs for the People Group team at GitLab can be found on th
## People Group READMEs
- [Cassiana Gudgenov's README (People Compliance Partner)]({{< ref "cgudgenov" >}})
- [Cassiana Gudgenov's README (People Compliance Partner)](/handbook/people-group/readmes/cgudgenov/)
- [Tre Ely's README (Director, Talent Development)]({{< ref "tely" >}})
- [Tre Ely's README (Director, Talent Development)](/handbook/people-group/readmes/tely/)
......@@ -60,7 +60,7 @@ A long-term relocation means that you will establish yourself in a new location.
It is at the company's discretion to determine whether it can approve the relocation:
- Some job positions require GitLab team members to be located in particular countries, locations, regions, or time zones. For example, a salesperson hired to serve a specific region may need to stay in that region, or an engineer hired to respond to customer requests in a specific region/country.
- GitLab only allows relocations to countries in which we already have a formed entity that carries no hiring restrictions. Review our [Country hiring guidelines]({{< ref "employment-solutions#country-hiring-guidelines" >}}) to see if the country is eligible for a relocation.
- GitLab only allows relocations to countries in which we already have a formed entity that carries no hiring restrictions. Review our [Country hiring guidelines](/handbook/people-group/employment-solutions/#country-hiring-guidelines) to see if the country is eligible for a relocation.
- GitLab cannot accept relocation requests to a location where there might be the possibility of the formation of a new entity until it is formally established, open for hiring, and the business objectives are fully understood.
- You can only work in countries where you can establish eligibility to work in the country without visa sponsorship provided by GitLab.
- Relocations can also result in an adjustment to compensation, including equity eligibility, based on the location and the location factor. Depending on the location factor and the benefits offered in the particular country, the adjustment will result in an increase or a decrease to the compensation package. The Company retains discretion to determine whether it can support the relocation due to the required adjustment.
......@@ -75,27 +75,27 @@ Adjusting [pay according to the local market in all cases](/handbook/total-rewar
**GitLab retains discretion at all times whether it can accommodate you to continue your role in the new location based on the requirements of your role and the potential impact on the business. In some instances a move will not align to your proposed location, (e.g. a recruiter hired in EMEA to support EMEA would not be approved to move to the US), and in other instances the company may not be able to support a relocation in the proposed location. Second, in almost all situations the compensation, including equity eligibility, can change. During the relocation process, you will learn how your compensation may be impacted and be able to make an informed decision. Any increases in compensation will need to go through an [approval process](/handbook/people-group/relocation/#approvals-phase). This allows the business to validate budget availability early in the process. If you like to understand how a relocation would impact you please submit a [Relocation Evaluation](https://helplab.gitlab.systems/esc?id=sc_cat_item&sys_id=45f7278647533d1067429ee0026d432d) request via HelpLab to the People Connect team.**
1. If you are considering applying for a long-term relocation to a new country, the first consideration is to ensure that GitLab has an [entity]({{< ref "employment-solutions#gitlab-entities-and-branches" >}}) in the country to which you would like to move. We currently only support relocations to GitLab Entities that are open for hiring and do not have hiring restrictions or headcount caps. This is in alignment with our [Country hiring guidelines]({{< ref "employment-solutions#country-hiring-guidelines" >}}).
1. If you are considering applying for a long-term relocation to a new country, the first consideration is to ensure that GitLab has an [entity](/handbook/people-group/employment-solutions/#gitlab-entities-and-branches) in the country to which you would like to move. We currently only support relocations to GitLab Entities that are open for hiring and do not have hiring restrictions or headcount caps. This is in alignment with our [Country hiring guidelines](/handbook/people-group/employment-solutions/#country-hiring-guidelines).
1. Consider any changes to [benefits]({{< ref "general-and-entity-benefits" >}}) as benefits can vary by country.
1. You must have the appropriate right to work documentation/visa requirements in the country that you are considering relocating to.
- Please note, at this moment GitLab only sponsors [relocations to the Netherlands]({{< ref "visas#right-to-immigrate-to-the-netherlands" >}}) and doesn't cover relocation costs for the team member's family members also looking to relocate.
- Please note, at this moment GitLab only sponsors [relocations to the Netherlands](/handbook/people-group/visas/#right-to-immigrate-to-the-netherlands) and doesn't cover relocation costs for the team member's family members also looking to relocate.
1. You must have satisfied the required one year tenure to be eligible for relocation.
#### Eligibility to Work
If you are interested in a long-term relocation (defined above), you need to confirm that you would be eligible to work in that location. [Except for the Netherlands]({{< ref "visas#right-to-immigrate-to-the-netherlands" >}}), GitLab does not provide any form of sponsorship or immigration aid for team members who choose to move to new countries. For more information, please refer to our [Visa page]({{< ref "visas" >}}). GitLab cannot assist or facilitate a process to help you become eligible to work in a location if you do not already have that eligibility. You are of course free to apply and gain that eligibility if there are steps you can take that do not involve GitLab. Once you are certain that you are eligible to work in your requested location country, you will need to provide proof of eligibility by [uploading the proof in the Documents tab of your Workday profile](https://docs.google.com/document/d/19B0lsMu7dMhof1ghPuBxHP23DuDqi2qpWF8pCWyEUN4/edit). If you move before establishing eligibility to work, but then cannot establish eligibility to work in the new location within the first six months of residency, it may affect your ability to continue your role with GitLab.
If you are interested in a long-term relocation (defined above), you need to confirm that you would be eligible to work in that location. [Except for the Netherlands](/handbook/people-group/visas/#right-to-immigrate-to-the-netherlands), GitLab does not provide any form of sponsorship or immigration aid for team members who choose to move to new countries. For more information, please refer to our [Visa page](/handbook/people-group/visas/). GitLab cannot assist or facilitate a process to help you become eligible to work in a location if you do not already have that eligibility. You are of course free to apply and gain that eligibility if there are steps you can take that do not involve GitLab. Once you are certain that you are eligible to work in your requested location country, you will need to provide proof of eligibility by [uploading the proof in the Documents tab of your Workday profile](https://docs.google.com/document/d/19B0lsMu7dMhof1ghPuBxHP23DuDqi2qpWF8pCWyEUN4/edit). If you move before establishing eligibility to work, but then cannot establish eligibility to work in the new location within the first six months of residency, it may affect your ability to continue your role with GitLab.
## How To Apply for a Long-Term Relocation
### Team Member
1. Review the [Country hiring guidelines]({{< ref "employment-solutions#country-hiring-guidelines" >}}) to see if we can support your relocation.
1. Review the [Country hiring guidelines](/handbook/people-group/employment-solutions/#country-hiring-guidelines) to see if we can support your relocation.
*If you are moving to a different country, please start this process no later than **3 months** prior to your ideal relocation date. If your relocation is within the same country, please start the process no later than 30 days before your ideal relocation date.*
1. If you are moving to a different country, upload eligibility documentation to Workday - Per the [Eligibility to Work](/handbook/people-group/relocation/#eligibility-to-work) section above.
1. Complete the [Relocation Request Form](https://helplab.gitlab.systems/esc?id=sc_cat_item&sys_id=3537489247173d1067429ee0026d43b7) via [HelpLab](/handbook/business-technology/enterprise-applications/guides/helplab-guide/#accessing-helplab) to submit the initial request to start the process. Upon completion, the form is sent automatically to People Connect who will review the details of your move and will work with the proper leaders and approvers to determine if the relocation can be approved (based on any budgetary and job duty impacts). Your manager will review if your role can be performed adequately in the new location without negatively impacting stakeholders or customers. Some positions require GitLab team members to be located in particular countries, locations, regions, or time zones and will not be eligible for relocation. People Connect will work with your manager on the final decision. Your manager will communicate the decision and the impact on your compensation so that you can make an informed final decision as to your move. Your assigned People Business Partner will also be informed of your request to relocate.
1. Start preparing and avoid a delay in your pay or change to your relocation effective date by ensuring you have all required work documentation prior to your relocation. The onus is on the team member to research these requirements in advance as GitLab doesn't provide immigration support, except for the [Netherlands]({{< ref "visas#right-to-immigrate-to-the-netherlands" >}}). Please take into account processing times for visa and other required appointments in the relocating country needed in order to receive a tax number, bank account, etc.
1. Start preparing and avoid a delay in your pay or change to your relocation effective date by ensuring you have all required work documentation prior to your relocation. The onus is on the team member to research these requirements in advance as GitLab doesn't provide immigration support, except for the [Netherlands](/handbook/people-group/visas/#right-to-immigrate-to-the-netherlands). Please take into account processing times for visa and other required appointments in the relocating country needed in order to receive a tax number, bank account, etc.
Note: Assuming your relocation is approved, any applicable changes in compensation will not be effective until your move date (or the date you start working in the new location), which will be listed as the effective date on your new contract. **We will not be able to process retroactive dated relocations. Please only use future dates when applying for your relocation.**
......@@ -182,7 +182,7 @@ The contract phase is unique based upon the team member's relocation. The differ
1. If applicable:
- A [Mutual Termination Agreement](https://docs.google.com/document/d/1MJCWQupiqfU7rUk99qowHuxd64OPIHKfD05gLlfs7K8/edit) is needed, if the team member is relocating from IT BV.
- A [Side letter Relocation - Transfer from one entity to another](https://docs.google.com/document/d/1UesnGAH1y0MMgWU37RRX2DuSP14mDLff/edit) is needed if the team member is relocating from one entity to another.
- Inform the current PEO of the relocation effective date. See People Connect 1password vault for contact details. A resignation email (within notice period) from the team member to their current PEO is also required, if the team member is relocating away from a location with [PEO Employment]({{< ref "employment-solutions#peo-professional-employer-organization-employer-of-record-and-not-a-gitlab-entity-or-branch" >}}).
- Inform the current PEO of the relocation effective date. See People Connect 1password vault for contact details. A resignation email (within notice period) from the team member to their current PEO is also required, if the team member is relocating away from a location with [PEO Employment](/handbook/people-group/employment-solutions/#peo-professional-employer-organization-employer-of-record-and-not-a-gitlab-entity-or-branch).
1. Ping a People Connect Team member for auditing in the `#connect-ops-team` private slack channel.
1. Stage the contract in DocuSign and send for signature first to the GitLab signatory and subsequently to the team member.
- In the event that the team member requests any changes to the contract, once approved and updated, send an email to the team member with the breakdown of the applicable changes once the contract has been sent for signature via DocuSign.
......
......@@ -10,14 +10,14 @@ As we continue to scale, we want to be intentional about Talent Development. Inv
GitLab's Talent Development Program includes the following initiatives:
- [Talent Assessment Tool](/handbook/people-group/talent-assessment)
- [360 Feedback]({{< ref "360-feedback" >}})
- [360 Feedback](/handbook/people-group/360-feedback/)
- [Organisational Structure and gaps](/handbook/company/structure/)
- [Performance Assessments and Succession Planning](/handbook/people-group/talent-assessment)
- [Career Development Conversations]({{< ref "1-1#career-development-discussion-at-the-1-1" >}})
- [Performance Improvement Plans (PIP)](/handbook/leadership/underperformance/#options-for-remediation)
- [Performance Enablement Review](/handbook/people-group/learning-and-development/career-development#performance-enablement-review)
- [Individual Growth Plan](https://docs.google.com/document/d/1ZjdIuK5mNpljiHnFMK4dvqfTOzV9iSJj66OtoYbniFM/edit)
- [Engagement Survey]({{< ref "engagement" >}})
- [Engagement Survey](/handbook/people-group/engagement/)
- [Annual Compensation Review](/handbook/total-rewards/compensation/compensation-review-cycle/#annual-compensation-review)
### Talent Development Program Chart
......@@ -36,7 +36,7 @@ graph LR
click Aid1 "/handbook/people-group/talent-assessment"
click Bid1 "/handbook/company/structure/"
click Did1 "{{< ref "360-feedback" >}}"
click Did1 "[360-feedback](/handbook/people-group/360-feedback/)"
click Eid1 "/handbook/people-group/talent-assessment"
click Fid1 "/handbook/hiring/"
click Gid1 "{{< ref "1-1#career-development-discussion-at-the-1-1" >}}"
......
......@@ -93,7 +93,7 @@ The team member relations function provides all GitLab team members an avenue to
- Team members can express themselves openly and freely without fear of retaliation.
- Professional behavior and conduct is expected from all team members. As a reminder use judgement in your conversations with other team members. We encourage all team members to [provide direct feedback]({{< ref "leadership#sts=Giving%20Feedback" >}}) to each other. The team member relations group is here to listen to team members concerns in an unbiased, open and professional manner.
- Team members can discuss [reasonable accommodations]({{< ref "inc-usa#reasonable-accommodation" >}}) or any related questions.
- Team members can discuss [reasonable accommodations](/handbook/people-policies/inc-usa/#reasonable-accommodation) or any related questions.
### For Managers
......
......@@ -5,7 +5,7 @@ description: "Information on travel visas, visa letters, and immigration to the
## Visa and Sponsorship Policy
GitLab does **not** offer any form of work or study sponsorship anywhere in the world, other than our specific, internal [Netherlands]({{< ref "visas#right-to-immigrate-to-the-netherlands" >}}) process and support for highly skilled candidates in *certain* countries, where a candidate is already based in that country. GitLab does **not** offer any form of support to transfer an existing work permit. During the [screening process](/handbook/hiring/interviewing/#what-to-expect-during-an-interview-with-a-recruiter), recruiters will ask applicants if they require any type of sponsorship or support.
GitLab does **not** offer any form of work or study sponsorship anywhere in the world, other than our specific, internal [Netherlands](/handbook/people-group/visas/#right-to-immigrate-to-the-netherlands) process and support for highly skilled candidates in *certain* countries, where a candidate is already based in that country. GitLab does **not** offer any form of support to transfer an existing work permit. During the [screening process](/handbook/hiring/interviewing/#what-to-expect-during-an-interview-with-a-recruiter), recruiters will ask applicants if they require any type of sponsorship or support.
For our purposes, visa sponsorship is defined as the requirement that a company or individual support a foreign national’s visa application. Sponsorship may be referred to by different terms depending on the country or visa, but any visa application or approval that is contingent on the company taking on certain obligations is considered synonymous with sponsorship.
......@@ -154,7 +154,7 @@ It is possible to make an appointment within 2 weeks.
If a team member wishes to immigrate and relocate to the Netherlands, they will need to first follow the [relocation process](/handbook/people-group/relocation/) and requirements and obtain approval to relocate. Once approved, team members will also need to pass the formal visa application process to qualify. The requirements are:
1. When using the [compensation calculator]({{< ref "calculator" >}}) you must meet the Dutch salary requirement for [highly skilled migrants for 3 more years](https://ind.nl/en/required-amounts-income-requirements#Application_for_residence_permit_highly_skilled_migrant_and_European_Blue_Card)
1. When using the [compensation calculator](/handbook/total-rewards/compensation/compensation-calculator/calculator/) you must meet the Dutch salary requirement for [highly skilled migrants for 3 more years](https://ind.nl/en/required-amounts-income-requirements#Application_for_residence_permit_highly_skilled_migrant_and_European_Blue_Card)
- Note, that the Dutch government has a higher requirement for team members aged 30 and above. The age related wage requirement does not increase when reaching 30 if you already have an approved migrant visa (with the same employer).
- The following pay elements are not included in the salary criterion and can't be used to meet the mimimum salary requirement: Vacation allowance; the value of payment made in kind; Uncertain, non-regular pay elements (for example overtime allowances, variable boni and payments from funds).
- *Note: This calculation should be based on what GitLab **would** pay the team member in the Netherlands in accordance with the compensation calculator, **not** based on the team member's current salary.*
......@@ -172,11 +172,11 @@ If you meet these requirements, kindly read our [Relocation](/handbook/people-gr
#### Transferring a partner visa to a highly skilled migrant visa
Someone already in the Netherlands on a partner visa can be transferred to their own highly skilled migrant visa in order to not be dependent anymore. The process can take up to three months and is subject to above [eligibility criteria]({{< ref "visas#right-to-immigrate-to-the-netherlands" >}}) and executive approval. Please reach out to the People Connect team via HelpLab to get this process started.
Someone already in the Netherlands on a partner visa can be transferred to their own highly skilled migrant visa in order to not be dependent anymore. The process can take up to three months and is subject to above [eligibility criteria](/handbook/people-group/visas/#right-to-immigrate-to-the-netherlands) and executive approval. Please reach out to the People Connect team via HelpLab to get this process started.
Tasks for People Connect:
1. The People Connect team member reviews if the [eligibility criteria]({{< ref "visas#right-to-immigrate-to-the-netherlands" >}}) are met and asks the manager to confirm that the team member is not on a Performance Improvement Plan (PIP)
1. The People Connect team member reviews if the [eligibility criteria](/handbook/people-group/visas/#right-to-immigrate-to-the-netherlands) are met and asks the manager to confirm that the team member is not on a Performance Improvement Plan (PIP)
1. The People Connect team member emails HR Savvy (see contact details in 1password) to confirm the total amount of fees for this process since they are subject to change
1. The People Connect team member emails the team member's Division's E-Group leader for their written approval and includes the total amount of fees in the email
1. Once approved the People Connect team member emails HR Savvy with the team member in cc to request the visa transfer
......
......@@ -73,7 +73,7 @@ Exceptions to this procedure will be tracked as per the [Information Security Po
### Anti-Harassment
Please see the [Anti-Harassment Policy]({{< ref "anti-harassment" >}}).
Please see the [Anti-Harassment Policy](/handbook/people-group/anti-harassment/).
### Anti-Retaliation
......@@ -388,7 +388,7 @@ To ensure the physical and mental health and safety of our team members in New Z
**Workplace Harassment Policy**
- [Anti-Harassment Policy]({{< ref "anti-harassment#introduction" >}})
- [Anti-Harassment Policy](/handbook/people-group/anti-harassment/#introduction)
- [Code of Business Conduct & Ethics](https://ir.gitlab.com/static-files/7d8c7eb3-cb17-4d68-a607-1b7a1fa1c95d)
**Fair Employment Practices Policy**
......
......@@ -227,7 +227,7 @@ Remote work is open to disabled workers in the following ways:
- Installation of special software;
- Adaptation of the working environment.
The [reasonable accommodation]({{< ref "inc-usa#reasonable-accommodation" >}}) section of the Company handbook provides complementary information.
The [reasonable accommodation](/handbook/people-policies/inc-usa/#reasonable-accommodation) section of the Company handbook provides complementary information.
#### 4. ORGANISATION OF THE WORKING TIME
......
......@@ -36,7 +36,7 @@ Violations of this policy, regardless of whether an actual law has been violated
### Harassment
Please refer to the [GitLab Anti-Harassment Policy]({{< ref "anti-harassment" >}}) for more information.
Please refer to the [GitLab Anti-Harassment Policy](/handbook/people-group/anti-harassment/) for more information.
## Individuals with Disabilities Policy
......
......@@ -70,4 +70,4 @@ When team members return from military service, they will be entitled to return
Team members should first review their own country's Military Leave policies to ensure they are reporting their leave in accordance with any reporting requirements. Whenever possible team members need to provide at least 30 days advanced notice by selecting `Military Leave` under the `Leaves` dropdown in Workday. GitLab reserves the right to request documentation related to the team member's Military service. The Absence Management Team will contact you if documentation is needed.
- For any questions about how to initiate a military leave or requests for reinstatement, please contact the Absence Management team (`leaves@gitlab.com`). For GitLab Inc or GitLab Federal team members, please additionally review the [Military Leave]({{< ref "us#military-leave" >}}) policy.
- For any questions about how to initiate a military leave or requests for reinstatement, please contact the Absence Management team (`leaves@gitlab.com`). For GitLab Inc or GitLab Federal team members, please additionally review the [Military Leave](/handbook/people-policies/leave-of-absence/us/#us-military-leave) policy.
......@@ -37,7 +37,7 @@ Our mission is to enable everyone to innovate and succeed on a safe, secure, and
- Avoiding security jargon
- Seek opportunities to help others succeed
To help achieve the vision of transparently leading the world to secure outcomes, the Security Division has nominated a [Security Culture Committee]({{< ref "security-culture" >}}).
To help achieve the vision of transparently leading the world to secure outcomes, the Security Division has nominated a [Security Culture Committee](/handbook/security/security-culture/).
### Division Structure
......@@ -137,7 +137,7 @@ We invest heavily in [device trust, identity management, and infrastructure gove
##### Security Program Management
Security Program Management is responsible for complete overview and driving security initiatives across Product, Engineering, and Business Enablement. This includes the tracking, monitoring, and influencing priority of significant security objectives, goals, and plans/roadmaps from all security sub-departments. [Security Program Manager Job Family]({{< ref "security-program-manager" >}})
Security Program Management is responsible for complete overview and driving security initiatives across Product, Engineering, and Business Enablement. This includes the tracking, monitoring, and influencing priority of significant security objectives, goals, and plans/roadmaps from all security sub-departments. [Security Program Manager Job Family](/job-families/security/security-program-manager/)
###### Security Program areas of focus
......@@ -158,7 +158,7 @@ In keeping with our [core values](/handbook/values/) and the belief that [everyo
#### Reporting vulnerabilities and security issues
For information regarding GitLab's [HackerOne bug bounty program]({{< ref "hackerone-process" >}}), and creating and scheduling security issues, please see our [engaging with security]({{< ref "engaging-with-security" >}}) page and our [Responsible Disclosure Policy](https://about.gitlab.com/security/disclosure/).
For information regarding GitLab's [HackerOne bug bounty program](/handbook/security/product-security/application-security/runbooks/hackerone-process/), and creating and scheduling security issues, please see our [engaging with security](/handbook/security/engaging-with-security/) page and our [Responsible Disclosure Policy](https://about.gitlab.com/security/disclosure/).
#### Reporting an Incident
......@@ -246,7 +246,7 @@ We believe it is important to share regular updates at various levels of the Sec
#### Ransomware
For an overview of the communication and response process for a suspected ransomware attack, please see our [Responding to Ransomware]({{< ref "responding-to-ransomware" >}}) page.
For an overview of the communication and response process for a suspected ransomware attack, please see our [Responding to Ransomware](/handbook/security/responding-to-ransomware/) page.
---
......@@ -304,7 +304,7 @@ When opening issues, please follow the [Creating New Security Issues]({{% ref "e
- [Security Best Practices]({{< ref "." >}}), using 1Password and similar tools, are documented
on their own [security best practices page]({{< ref "." >}}).
- [Secure Coding Training]({{< ref "secure-coding-training" >}}).
- [Secure Coding Training](/handbook/security/secure-coding-training/).
- GitLab.com [data breach notification policy](https://about.gitlab.com/security/#data-breach-notification-policy).
- GitLab Internal Acceptable Use [Policy](/handbook/people-group/acceptable-use-policy/).
- For GitLab.com, we have developed a [Google Cloud Platform (GCP) Security Guidelines Policy](https://docs.google.com/document/d/1BBTWC5OpIqrva7DqH4nkjYUmNZ3UFbc6erqV89P_N-o/edit?usp=sharing) document, which outlines recommended best practices, and is enforced through
......@@ -315,9 +315,9 @@ our security automation initiatives.
- and one [exclusively for stickers](https://gitlab.com/gitlab-com/marketing/corporate_marketing/corporate-marketing/-/blob/master/design/_deprecated/gitlab-brand-assets/gitlab-logo-files/gitlab-security-logo/print-cmyk/pdf/sticker/gitlab-security-icon-diecut-sticker-3x2_78in.pdf).
- [Security READMEs](/handbook/security/readmes/)
- [Working in Security](/handbook/security/working-in-security.md)
- [Contributing to GitLab the product as a Security team member]({{< ref "contributing-to-gitlab-the-product" >}})
- [Contributing to GitLab the product as a Security team member](/handbook/security/contributing-to-gitlab-the-product/)
- [Threat Modeling](product-security/application-security/threat-modeling/)
#### AI in Security Learning Group
This group is setup to help interested Security team members get up to speed with AI technologies and how to secure them. For more information, see the [AI in Security Learning Group page]({{< ref "learning-group-ai" >}}).
This group is setup to help interested Security team members get up to speed with AI technologies and how to secure them. For more information, see the [AI in Security Learning Group page](/handbook/security/learning-group-ai/).
......@@ -55,7 +55,7 @@ At minimum, controlled documents should cover the following key topic areas:
Creation of, or changes to, controlled documents must be approved by management or a formally designated representative of the owning department as defined in the Code Owners file prior to publishing.
Most controlled documents will be published to our public facing [handbook](/). However, if there is [non public data]({{< ref "data-classification-standard" >}}) included in the controlled document, it should be published via an *internal facing only* mechanism (e.g. an internal GitLab project or an internal only handbook page). Controlled documents should be accessible to all internal team members.
Most controlled documents will be published to our public facing [handbook](/). However, if there is [non public data](/handbook/security/data-classification-standard/) included in the controlled document, it should be published via an *internal facing only* mechanism (e.g. an internal GitLab project or an internal only handbook page). Controlled documents should be accessible to all internal team members.
#### Handbook header
......@@ -103,6 +103,6 @@ Once an exception request is submitted, the following general flow will commence
## References
- [GCF Compliance Controls]({{< ref "sec-controls" >}})
- [Data Classifiation Standard]({{< ref "data-classification-standard" >}})
- [GCF Compliance Controls](/handbook/security/security-assurance/security-compliance/sec-controls/)
- [Data Classifiation Standard](/handbook/security/data-classification-standard/)
- [Controlled Documents Work Instruction](https://gitlab.com/gitlab-com/gl-security/security-assurance/governance/controlled-documents-program/-/blob/main/runbooks/controlled_document_annual_review_work_instruction.md)
......@@ -105,4 +105,4 @@ Exceptions to this policy will be tracked as per the [Information Security Polic
## References
- [Controlled Document Procedure]({{< ref "controlled-document-procedure" >}})
- [Controlled Document Procedure](/handbook/security/controlled-document-procedure/)
......@@ -25,7 +25,7 @@ The Data Classification Standard applies to all GitLab team members, contractors
- Data Owners shall determine the classification of data in accordance with this standard. The Data Classification Index (internal only) provides a list of various types of data and their classification level. If you cannot identify the data element or are uncertain of the risk associated with the data and how it should be classified and handled, please contact the Security Risk team in Slack via @security-risk.
- To maintain our culture of security, transparency and to minimize the risk to our sensitive data and our customers, GitLab team members are required to complete Data Classification Training as part of GitLab's [Security Awareness Training]({{< ref "sec-training" >}}) to help understand the different types of data at GitLab and how to keep it [SAFE](/handbook/legal/safe-framework/). Training is available via [Level Up](https://levelup.gitlab.com/learn/dashboard), GitLab's internal learning platform.
- To maintain our culture of security, transparency and to minimize the risk to our sensitive data and our customers, GitLab team members are required to complete Data Classification Training as part of GitLab's [Security Awareness Training](/handbook/security/security-assurance/governance/sec-training/) to help understand the different types of data at GitLab and how to keep it [SAFE](/handbook/legal/safe-framework/). Training is available via [Level Up](https://levelup.gitlab.com/learn/dashboard), GitLab's internal learning platform.
### Customer Responsibilities
......@@ -53,7 +53,7 @@ Restricted and must remain confidential. This is GitLab's most sensitive data an
Examples include:
- Customer Data (see definition above in the [Data Classification Definitions section]({{< ref "data-classification-standard#data-classification-definitions" >}}))
- Customer Data (see definition above in the [Data Classification Definitions section](/handbook/security/data-classification-standard/#data-classification-definitions))
Red Data may not be transmitted from an approved Red data source to any other systems or solutions without first obtaining approval from the Privacy and Security teams. Any Vendors that process Red Data must first undergo a factual and legal analysis that justifies their processing in accordance with our Customer agreements, as well as global privacy and data security laws. For any questions or concerns related to the transmission of Red data between systems, please reach out to @Security-Risk within the #Sec-Assurance channel.
......@@ -96,7 +96,7 @@ Examples include:
- Asset registers
- General internal company communications
- Vendor contracts
- GitLab runbooks/work instructions/manuals/policies/procedures containing data NOT appropriate for [public consumption]({{< ref "confidentiality-levels#not-public" >}})
- GitLab runbooks/work instructions/manuals/policies/procedures containing data NOT appropriate for [public consumption](/handbook/communication/confidentiality-levels/#not-public)
- GitLab Team Member names
#### GREEN{.text-success #green}
......@@ -130,5 +130,5 @@ Exceptions to this policy will be tracked as per the [Information Security Polic
## References
- [Controlled Document Procedure]({{< ref "controlled-document-procedure" >}})
- [Controlled Document Procedure](/handbook/security/controlled-document-procedure/)
- [Data Classification Index](https://internal.gitlab.com/handbook/security/data_classification/) (internal only)
......@@ -26,15 +26,15 @@ If triage is delayed due to team availability, the delay should be communicated.
### Triage Rotation
See the [dedicated page]({{< ref "triage-rotation" >}}) to read about our Triage Rotation process.
See the [dedicated page](/handbook/security/product-security/application-security/runbooks/triage-rotation/) to read about our Triage Rotation process.
### HackerOne Process
See the [dedicated page]({{< ref "hackerone-process" >}}) to read about our HackerOne process.
See the [dedicated page](/handbook/security/product-security/application-security/runbooks/hackerone-process/) to read about our HackerOne process.
### Security Dashboard Review
See the [dedicated page]({{< ref "security-dashboard-review" >}}) to read about our dashboard review process.
See the [dedicated page](/handbook/security/product-security/application-security/runbooks/security-dashboard-review/) to read about our dashboard review process.
### CVE IDs
......@@ -50,7 +50,7 @@ On the day of the security release several things happen in order:
- All security patches are pushed to the public repository.
- The public is notified via the GitLab blog release post, security alerts email, and Twitter.
The GitLab issue should then be closed and - after 30 days - sanitized and made public. If the report was received via HackerOne, follow the [HackerOne process]({{< ref "hackerone-process#closing-out-and-disclosing-issues" >}}).
The GitLab issue should then be closed and - after 30 days - sanitized and made public. If the report was received via HackerOne, follow the [HackerOne process](/handbook/security/product-security/application-security/runbooks/hackerone-process/#closing-out--disclosing-issues).
### Process for disclosing security issues
......@@ -62,7 +62,7 @@ At GitLab we value [being as transparent as possible](/handbook/values/#transpar
1. If an issue does not have `~keep confidential`, remove sensitive information from the description and comments, e.g.
1. Proof-of-concept videos & screenshots showing researcher account information
1. Tokens, Access Keys, and other secrets
1. Information which our [Data Classification Standard]({{< ref "data-classification-standard" >}}) and [SAFE framework](/handbook/legal/safe-framework/) say to not disclose
1. Information which our [Data Classification Standard](/handbook/security/data-classification-standard/) and [SAFE framework](/handbook/legal/safe-framework/) say to not disclose
1. Issues related to personal data leaks are not disclosed since they are not security issues related to the product. If for some reason it needs to be disclosed then consult with Legal and the Corporate Comms team before disclosing.
1. Identify all issue description changes, click to expand "Compare with previous version" and click the trash icon to "Remove description history"
1. Optionally mention issue participants to notify them you intend to make the issue public
......
......@@ -59,4 +59,4 @@ Exceptions to this procedure will be tracked as per the [Information Security Po
## References
[Security incident communications plan]({{< ref "security-incident-communication-plan" >}})
[Security incident communications plan](/handbook/security/security-operations/sirt/security-incident-communication-plan/)
......@@ -44,7 +44,7 @@ As a general rule, we want to protect our branches in such a way that we [requir
![Example 1 of Protected Branch Settings configured to Require an MR](https://about.gitlab.com/images/protected_branch_settings_example.jpg "Example of Protected Branch Settings")
See [Note on usage of Code Owners]({{< ref "gitlab_projects_baseline_requirements#note-on-usage-of-code-owners" >}})
See [Note on usage of Code Owners](/handbook/security/gitlab_projects_baseline_requirements/#note-on-usage-of-code-owners)
## MR Approval Rule Configurations
......@@ -58,7 +58,7 @@ MRs should be reviewed following GitLab's [Code Review Guidelines](/handbook/eng
![Example 2 of MR Approval Rules configured WITH Code Owners](https://about.gitlab.com/images/MR_approvals_with_code_owners.png "Example 2 of MR Approval Rules configured WITH Code Owners")
See [Note on usage of Code Owners]({{< ref "gitlab_projects_baseline_requirements#note-on-usage-of-code-owners" >}})
See [Note on usage of Code Owners](/handbook/security/gitlab_projects_baseline_requirements/#note-on-usage-of-code-owners)
## Note on usage of Code Owners
......@@ -72,10 +72,10 @@ Please review thoroughly and ask questions in the `#sec-assurance` slack channel
## Ongoing Monitoring
Please note that projects that meet the criteria for requiring these baseline configurations may be selected at any point for testing of configurations by the [GitLab Security Compliance team](security-assurance/security-compliance/) as part of our continuous control monitoring program to make sure we're adhering to the guidance outlined on this page. Please see the [GCF Security Control Lifecycle]({{< ref "security-control-lifecycle" >}}) page for an overview of the program.
Please note that projects that meet the criteria for requiring these baseline configurations may be selected at any point for testing of configurations by the [GitLab Security Compliance team](security-assurance/security-compliance/) as part of our continuous control monitoring program to make sure we're adhering to the guidance outlined on this page. Please see the [GCF Security Control Lifecycle](/handbook/security/security-assurance/security-compliance/security-control-lifecycle/) page for an overview of the program.
## References
- [GitLab Repositories](/handbook/engineering/gitlab-repositories/#creating-a-new-project) (for guidance on creating a new project)
- [Change Management Policy]({{< ref "change-management-policy" >}})
- [GCF Security Control Lifecycle]({{< ref "security-control-lifecycle" >}})
- [Change Management Policy](/handbook/security/security-and-technology-policies/change-management-policy/)
- [GCF Security Control Lifecycle](/handbook/security/security-assurance/security-compliance/security-control-lifecycle/)
......@@ -7,9 +7,9 @@ description: "Provides an aggregated listing of popular and important links and
### Contacting GitLab for reporting security issues
- [Reporting Abuse]({{< ref "abuse-on-gitlab-com" >}})
- [Reporting Abuse](/handbook/security/security-operations/trustandsafety/abuse-on-gitlab-com/)
- [Coordinated Disclosure Process](https://about.gitlab.com/security/disclosure/)
- [HackerOne Reporting Process]({{< ref "hackerone-process" >}})
- [HackerOne Reporting Process](/handbook/security/product-security/application-security/runbooks/hackerone-process/)
### GitLab's Customer Assurance Package (CAP)
......@@ -31,10 +31,10 @@ The following links contain frequently asked security, legal & privacy, and avai
### Table of contents
| [Acceptable use]({{< ref "gitlab_security_resource_center#acceptable-use" >}}) | [Access management]({{< ref "gitlab_security_resource_center#access-management" >}}) | [Business continuity]({{< ref "gitlab_security_resource_center#business-continuity" >}}) | [Cryptography]({{< ref "gitlab_security_resource_center#cryptography" >}}) | [Data classification]({{< ref "gitlab_security_resource_center#data-classification" >}})
| [Disaster recovery]({{< ref "gitlab_security_resource_center#disaster-recovery" >}}) | [Endpoint management]({{< ref "gitlab_security_resource_center#endpoint-management" >}}) | [Hardening]({{< ref "gitlab_security_resource_center#gitlabcom-hardening-techniques" >}}) | [Incident response and communication]({{< ref "gitlab_security_resource_center#incident-response-and-communication" >}}) | [Independent assurance]({{< ref "gitlab_security_resource_center#independent-assurance" >}})
| [Logging and monitoring]({{< ref "gitlab_security_resource_center#logging-and-monitoring" >}}) | [Network security]({{< ref "gitlab_security_resource_center#network-security" >}}) | [Privacy]({{< ref "gitlab_security_resource_center#privacy" >}}) | [Security awareness]({{< ref "gitlab_security_resource_center#security-awareness" >}}) | [Third party risk management]({{< ref "gitlab_security_resource_center#third-party-risk-management" >}})
| [Threat modeling]({{< ref "gitlab_security_resource_center#threat-modeling" >}}) | [Vulnerability management]({{< ref "gitlab_security_resource_center#vulnerability-management" >}}) |
| [Acceptable use](/handbook/security/gitlab_security_resource_center/#acceptable-use) | [Access management](/handbook/security/gitlab_security_resource_center/#access-management) | [Business continuity](/handbook/security/gitlab_security_resource_center/#business-continuity) | [Cryptography](/handbook/security/gitlab_security_resource_center/#cryptography) | [Data classification](/handbook/security/gitlab_security_resource_center/#data-classification)
| [Disaster recovery](/handbook/security/gitlab_security_resource_center/#disaster-recovery) | [Endpoint management](/handbook/security/gitlab_security_resource_center/#endpoint-management) | [Hardening](/handbook/security/gitlab_security_resource_center/#gitlabcom-hardening-techniques) | [Incident response and communication](/handbook/security/gitlab_security_resource_center/#incident-response-and-communication) | [Independent assurance](/handbook/security/gitlab_security_resource_center/#independent-assurance)
| [Logging and monitoring](/handbook/security/gitlab_security_resource_center/#logging-and-monitoring) | [Network security](/handbook/security/gitlab_security_resource_center/#network-security) | [Privacy](/handbook/security/gitlab_security_resource_center/#privacy) | [Security awareness](/handbook/security/gitlab_security_resource_center/#security-awareness) | [Third party risk management](/handbook/security/gitlab_security_resource_center/#third-party-risk-management)
| [Threat modeling](/handbook/security/gitlab_security_resource_center/#threat-modeling) | [Vulnerability management](/handbook/security/gitlab_security_resource_center/#vulnerability-management) |
### Acceptable use
......@@ -43,26 +43,26 @@ The following links contain frequently asked security, legal & privacy, and avai
### Access management
- [Access Management Policy]({{< ref "access-management-policy" >}})
- [Access Management Policy](/handbook/security/security-and-technology-policies/access-management-policy/)
- [Access Review Procedure]({{< ref "security-assurance/security-compliance/access-reviews" >}})
- [Access Request process](/handbook/it/end-user-services/onboarding-access-requests/access-requests/)
### Business continuity
- [Business Continuity Plan](/handbook/business-technology/entapps-documentation/policies/gitlab-business-continuity-plan/)
- [Business Impact Analysis]({{< ref "business-impact-analysis" >}})
- [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis/)
- [Information System Contingency Plan]({{< ref "Information-System-Contingency-Plan-ISCP" >}})
### Cryptography
- [GitLab cryptography standard]({{< ref "cryptographic-standard" >}})
- [Encryption policy]({{< ref "encryption-policy" >}})
- [GitLab cryptography standard](/handbook/security/cryptographic-standard/)
- [Encryption policy](/handbook/security/product-security/vulnerability-management/encryption-policy/)
### Data classification
- [Data classification standard]({{< ref "data-classification-standard" >}})
- [Data classification standard](/handbook/security/data-classification-standard/)
- [Record retention policy](/handbook/legal/record-retention-policy/)
- [Records retention and disposal standard]({{< ref "records-retention-deletion" >}})
- [Records retention and disposal standard](/handbook/security/records-retention-deletion/)
### Disaster recovery
......@@ -75,49 +75,49 @@ The following links contain frequently asked security, legal & privacy, and avai
- [Endpoint management at GitLab](https://internal.gitlab.com/handbook/it/endpoint-tools/)
- [Jamf](https://internal.gitlab.com/handbook/it/endpoint-tools/jamf/)
- [EDR](/handbook/it/end-user-services/onboarding-access-requests/endpoint-management/edr/)
- [Use Gitleaks as a pre-commit git hook on laptops]({{< ref "gitleaks" >}})
- [Use Gitleaks as a pre-commit git hook on laptops](/handbook/security/gitleaks/)
### GitLab.com hardening techniques
- [GitLab projects baseline requirements]({{< ref "gitlab_projects_baseline_requirements" >}})
- [GitLab security requirements for deployment and development]({{< ref "security-development-deployment-requirements" >}})
- [GitLab projects baseline requirements](/handbook/security/gitlab_projects_baseline_requirements/)
- [GitLab security requirements for deployment and development](/handbook/security/planning/security-development-deployment-requirements/)
- [How to harden your self-managed GitLab instance](https://about.gitlab.com/blog/2023/05/23/how-to-harden-your-self-managed-gitlab-instance/)
- [The ultimate guide to securing your code on GitLab.com](https://about.gitlab.com/blog/2023/05/31/securing-your-code-on-gitlab/)
### Incident response and communication
- [Security incident communications plan procedure]({{< ref "security-incident-communication-plan" >}})
- [Security incident response guide]({{< ref "sec-incident-response" >}})
- [Security incident communications plan procedure](/handbook/security/security-operations/sirt/security-incident-communication-plan/)
- [Security incident response guide](/handbook/security/security-operations/sirt/sec-incident-response/)
### Independent assurance
- [Independent Security Assurance]({{< ref "independent_security_assurance" >}})
- [Independent Security Assurance](/handbook/security/security-assurance/field-security/independent_security_assurance/)
### Logging and monitoring
- [Monitoring of gitlab.com](/handbook/engineering/monitoring/)
- [Log management for gitlab.com](/handbook/engineering/monitoring/#logs)
- [Logging and monitoring architecture](/handbook/engineering/infrastructure/production/architecture/#monitoring-and-logging)
- [GitLab audit logging policy]({{< ref "audit-logging-policy" >}})
- [Log and audit requests process]({{< ref "log_requests" >}})
- [GitLab audit logging policy](/handbook/security/security-and-technology-policies/audit-logging-policy/)
- [Log and audit requests process](/handbook/support/workflows/log_requests/)
- [Infrastructure department KPIs](/handbook/engineering/infrastructure/performance-indicators/)
- [Infrastructure production runbooks](https://gitlab.com/gitlab-com/runbooks/)
### Network security
- [Network security management procedure](/handbook/engineering/infrastructure/network-security/)
- [GitLab security requirements for deployment and development]({{< ref "security-development-deployment-requirements" >}})
- [GitLab security requirements for deployment and development](/handbook/security/planning/security-development-deployment-requirements/)
### Privacy
- [GitLab Privacy Statement](/handbook/legal/privacy/)
- [Team Member Privacy Notice](/handbook/legal/privacy/employee-privacy-policy/)
- [U.S. State Privacy Rights and Disclosures](https://about.gitlab.com/privacy/us-state-privacy-rights-and-disclosures/)
- [Account deletion and data access requests workflow]({{< ref "account_deletion_access_request_workflows" >}})
- [Account deletion and data access requests workflow](/handbook/support/workflows/account_deletion_access_request_workflows/)
### Security awareness
- [Security training]({{< ref "security-training" >}})
- [Security training](/handbook/security/security-assurance/governance/security-training/)
- [Security awareness training program](security-assurance/governance/sec-awareness-training/)
- [Security awareness training procedure](security-assurance/governance/sec-training/)
- [Phishing program](security-assurance/governance/phishing/)
......
......@@ -19,7 +19,7 @@ first. In order to facilitate this process, the framework supports the engineeri
the life cycle of the feature, to facilitate the creation of the required documentation and other
artifacts.
The framework relies heavily on the [data classification]({{< ref "data-classification-standard" >}}) of the feature in
The framework relies heavily on the [data classification](/handbook/security/data-classification-standard/) of the feature in
scope. It is not necessary for features managing Green data, and more activities are required as the
level increases, up to Red data.
......@@ -85,7 +85,7 @@ A value among: `Green`, `Yellow`, `Orange`, or `Red`.
##### Resources
1. The [Data Classification Standard]({{< ref "data-classification-standard" >}}) handbook page
1. The [Data Classification Standard](/handbook/security/data-classification-standard/) handbook page
#### Architecture
......
......@@ -5,7 +5,7 @@ description: "Provides procedures and capabilities for recovering an information
## Purpose
An ISCP provides established procedures for the assessment and recovery of a system following a system disruption. The ISCP provides key information needed for system recovery, including roles and responsibilities, inventory information, assessment procedures, detailed recovery procedures, and testing of a system. An ISCP will be created for GitLab.com and [Tier 1 systems]({{< ref "critical-systems" >}}), working in conjunction with the [Business Continuity Plan (BCP)](/handbook/business-technology/entapps-documentation/policies/gitlab-business-continuity-plan/) and [Disaster Recovery Plan (DRP)](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md).
An ISCP provides established procedures for the assessment and recovery of a system following a system disruption. The ISCP provides key information needed for system recovery, including roles and responsibilities, inventory information, assessment procedures, detailed recovery procedures, and testing of a system. An ISCP will be created for GitLab.com and [Tier 1 systems](/handbook/security/security-assurance/security-risk/storm-program/critical-systems/), working in conjunction with the [Business Continuity Plan (BCP)](/handbook/business-technology/entapps-documentation/policies/gitlab-business-continuity-plan/) and [Disaster Recovery Plan (DRP)](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md).
## Difference between ISCP and DRP
......@@ -13,7 +13,7 @@ The ISCP differs from a DRP primarily in that the information system contingency
## Information System Contingency Policy Statement
GitLab will develop contingency plans for GitLab.com and [Tier 1 systems]({{< ref "critical-systems" >}}) to meet the needs of critical system operations in the event of a disruption. The procedures for execution of such a capability shall be documented in a formal contingency plan by the Information Systems Contingency Plan (ISCP) Coordinator and must be reviewed annually and updated as necessary by the ISCP Coordinator. The plan must account for the FIPS 199 security categorization (low, moderate, high) and comply with the appropriate security controls. The plan must assign specific responsibilities to designated staff or positions to facilitate the recovery and/or continuity of essential system functions. Resources necessary to ensure viability of the procedures must be acquired and maintained. Personnel responsible for target systems must be trained to execute contingency procedures. The plan recovery capabilities and personnel shall be tested annually to identify weaknesses of the capability.
GitLab will develop contingency plans for GitLab.com and [Tier 1 systems](/handbook/security/security-assurance/security-risk/storm-program/critical-systems/) to meet the needs of critical system operations in the event of a disruption. The procedures for execution of such a capability shall be documented in a formal contingency plan by the Information Systems Contingency Plan (ISCP) Coordinator and must be reviewed annually and updated as necessary by the ISCP Coordinator. The plan must account for the FIPS 199 security categorization (low, moderate, high) and comply with the appropriate security controls. The plan must assign specific responsibilities to designated staff or positions to facilitate the recovery and/or continuity of essential system functions. Resources necessary to ensure viability of the procedures must be acquired and maintained. Personnel responsible for target systems must be trained to execute contingency procedures. The plan recovery capabilities and personnel shall be tested annually to identify weaknesses of the capability.
## Roles & Responsibilities
......
......@@ -58,7 +58,7 @@ The **Security** internship is the result of [The Engineering Internship Pilot P
## Roles
- [Security Manager]({{< ref "security-leadership" >}}) - Manager
- [Security Manager](/job-families/security/security-leadership/) - Manager
- [Senior Security Engineer(s)](/job-families/security/security-engineer#senior-security-engineer) - Mentor(s)
- Security Intern
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment