Merge branch 'fix-links-10' into 'main'

Fix broken links

See merge request !9575

assets/includes/engineering-allocations.md

 ### Engineering Allocation
 
-While we have moved to the [cross-functional prioritization process](/handbook/product/cross-functional-prioritization/) to empower teams to determine the optimal balance of all types of issues, we will keep Engineering Allocations as a way to allow teams to quickly shift to a critical priority, designating the EM as the DRI to drive the effort.
+While we have moved to the [cross-functional prioritization process](/handbook/product/product-processes/cross-functional-prioritization/) to empower teams to determine the optimal balance of all types of issues, we will keep Engineering Allocations as a way to allow teams to quickly shift to a critical priority, designating the EM as the DRI to drive the effort.
 
 Engineering is the DRI for mid/long term team efficiency, performance, security (incident response and anti-abuse capabilities), availability, and scalability. The expertise to proactively identify and iterate on these is squarely in the Engineering team. Whereas Product can support in performance issues as identified from customers. In some ways these efforts can be viewed as risk-mitigation or revenue protection. They also have the characteristic of being larger than one group at the stage level. Development would like to conduct an experiment to focus on initiatives that should help the organization scale appropriately in the long term.  We are treating these as a percent investment of time associated with a stage or category. The percent of investment time can be viewed as a prioritization budget outside normal Product/Development assignments.
 
@@ -37,7 +37,7 @@ One of the most frequent questions we get as part of this experiment is "How doe
 To help with getting items that on the list for consideration, we will be performing a survey periodically.  The survey will consist of the following questions:
 
 1. If you were given a % of engineering development per release to work on something, what would it be?
-1. How would you justify it?  Have you tried leveraging [cross-functional prioritization process](/handbook/product/cross-functional-prioritization/) before considering an engineering allocation?
+1. How would you justify it?  Have you tried leveraging [cross-functional prioritization process](/handbook/product/product-processes/cross-functional-prioritization/) before considering an engineering allocation?
 
 We will keep the list of questions short to solicit the most input.  The survey will go out to members of the Development, Quality, Security.  After we get the results, we will consider items for potential adding as an Engineering Allocation.
 

assets/includes/engineering/foundations-data-science-shared/career-development.md

@@ -102,7 +102,7 @@ This section lists relevant experience areas for individual contributors interes
 
 #### Trainings offered by GitLab for EMs
 
-* [Elevate Manager Training](/handbook/people-group/learning-and-development/elevate/)
+* [Elevate Manager Training](/handbook/people-group/learning-and-development/elevate-programs/)
 * [Crucial Conversations](/handbook/people-group/learning-and-development/learning-initiatives/crucial-conversations/)
 
 #### Other resources

assets/includes/engineering/master-prioritization-list.md

@@ -18,4 +18,4 @@ Any of the items with a "*" are considered issues driven by the attached [SLO or
 1. Security Issues labeled with `bug::vulnerability` must be delivered according to the stated [SLO](/handbook/security/#severity-and-priority-labels-on-security-issues)
 1. Issues supporting our product's scale which include `bug::availability` with [specific SLOs](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#availability) as well as `infradev`, `Corrective Action`, `ci-decomposition::phase*` that follow the stated [`type::bug` SLO](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#severity-slos)
 
-Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.
+Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/product-processes/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.

assets/includes/master-prioritization-list.md

@@ -18,4 +18,4 @@ Any of the items with a "*" are considered issues driven by the attached [SLO or
 1. Security Issues labeled with `bug::vulnerability` must be delivered according to the stated [SLO](/handbook/security/engaging-with-security/#severity-and-priority-labels-on-security-issues)
 1. Issues supporting our product's scale which include `bug::availability` with [specific SLOs](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#availability) as well as `infradev`, `Corrective Action`, `ci-decomposition::phase*` that follow the stated [`type::bug` SLO](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#severity-slos)
 
-Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.
+Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/product-processes/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.

assets/includes/syntax-deprection.md

 Our CI syntax keeps evolving. We cannot support all keywords indefinitely, so deprecating and removing keywords is inevitable.
 
-GitLab does not have a versioning system for CI/CD configuration. Therefore, it is critical to over-communicate our deprecation purposes to our users and take the necessary precautions to reduce the impact on their projects. Deprecating a keyword is risky because it will break all pipelines using it, and in some cases, users are not aware of the keyword they use in their pipeline. The deprecation process described below is similar to the [deprecating and removing features](/handbook/product/gitlab-the-product/#process-for-deprecating-and-removing-a-feature) process, with additional steps to reduce the risks which involved with removing a CI/CD keyword.
+GitLab does not have a versioning system for CI/CD configuration. Therefore, it is critical to over-communicate our deprecation purposes to our users and take the necessary precautions to reduce the impact on their projects. Deprecating a keyword is risky because it will break all pipelines using it, and in some cases, users are not aware of the keyword they use in their pipeline. The deprecation process described below is similar to the [deprecating and removing features](/handbook/product/categories/gitlab-the-product/#process-for-deprecating-and-removing-a-feature) process, with additional steps to reduce the risks which involved with removing a CI/CD keyword.
 
 1. Deprecation notice - Syntax removal introduces a breaking change, as outlined in our deprecation process, we must notify the community and customers, which means including a deprecation notice in the monthly release post.
 

content/handbook/about/_index.md

@@ -71,5 +71,5 @@ We've gathered *some* information about the handbook here, but there's still mor
 
 - [Handbook usage](/handbook/about/handbook-usage/)
 - [Evolution of the handbook](/handbook/ceo/#evolution-of-the-handbook) on the [CEO page](/handbook/ceo/)
-- [Changelog](/handbook/CHANGELOG.html)
+- [Changelog](/handbook/CHANGELOG/)
 - [Handbook editing examples](/handbook/about/editing-handbook/practical-handbook-edits/)

content/handbook/about/editing-handbook/_index.md

@@ -47,7 +47,7 @@ A typical workflow to edit the handbook:
     ![Web IDE overview, handbook page highlighted in the file tree](/images/handbook/about/editing-handbook/practical_handbook_edits_web_ide_vs_code_file_tree_edit_handbook_page.png)
 
 1. Edit the selected file, and try the Markdown preview. `Cmd+Shift+P` on macOS opens the Web IDE command palette to search for commands. For example, type `Markdown`, select `Markdown: Open Preview to the Side` and try the preview.
-    - Note that the [handbook markdown engine](/docs/markdown-guide/) supports more rendering features than the [Web IDE preview based on VS Code](https://code.visualstudio.com/docs/languages/markdown), and some items won't be rendered properly. Commit and create a [draft merge request](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html) to view the handbook [review apps](https://docs.gitlab.com/ee/ci/review_apps/) to preview the page, such as to verify embedded images.
+    - Note that the [handbook markdown engine](https://handbook.gitlab.com/docs/markdown-guide/) supports more rendering features than the [Web IDE preview based on VS Code](https://code.visualstudio.com/docs/languages/markdown), and some items won't be rendered properly. Commit and create a [draft merge request](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html) to view the handbook [review apps](https://docs.gitlab.com/ee/ci/review_apps/) to preview the page, such as to verify embedded images.
 
     ![Web IDE editor, Markdown preview](/images/handbook/about/editing-handbook/practical_handbook_edits_web_ide_vs_code_console_markdown.png)
 

content/handbook/about/handbook-usage.md

@@ -181,7 +181,7 @@ After a heading, leave one blank line; this is [not required in the standard](ht
 
 #### Use contributable diagrams
 
-Preference contributable diagrams over uploading images or other less contributable diagrams. This makes it easier for other people to suggest changes and contribute. Diagram options in Markdown include [Mermaid](/docs/markdown-guide/#mermaid) and [PlantUML](/docs/markdown-guide/#plantuml).
+Preference contributable diagrams over uploading images or other less contributable diagrams. This makes it easier for other people to suggest changes and contribute. Diagram options in Markdown include [Mermaid](https://handbook.gitlab.com/docs/markdown-guide/#mermaid) and [PlantUML](https://handbook.gitlab.com/docs/markdown-guide/#plantuml).
 
 ## Handbook First Competency
 

content/handbook/about/style-guide.md

@@ -5,7 +5,7 @@ title: "Handbook Style Guide"
 GitLab's general communications practices are detailed at [GitLab Communication](/handbook/communication/), but beyond those we do have some channel-specific guidance available.
 See the [list of resources below](#related-resources) for links to other guides.
 
-Handbook style guidance is covered primarily by [the handbook markdown guide](/docs/markdown-guide/),
+Handbook style guidance is covered primarily by [the handbook markdown guide](https://handbook.gitlab.com/docs/markdown-guide/),
 and [the editing handbook page](../editing-handbook/_index.md#naming-pages-and-folder-structure).
 
 In the absence of handbook-specific guidance, follow:
@@ -16,7 +16,7 @@ In the absence of handbook-specific guidance, follow:
 ## Related Resources
 
 - [GitLab Communication](/handbook/communication/)
-- [Markdown guide](/handbook/markdown-guide/)
+- [Markdown guide](https://handbook.gitlab.com/docs/markdown-guide/)
 - [GitLab Documentation guidelines](https://docs.gitlab.com/ee/development/documentation/)
   - [Documentation style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/)
 - [GitLab style guides](https://docs.gitlab.com/ee/development/contributing/style_guides.html)

content/handbook/business-technology/entapps-documentation/policies/gitlab-business-continuity-plan.md

@@ -9,7 +9,7 @@ Business Continuity Plan is the process involved in creating a system of prevent
 
 ## Scope
 
-GitLab, by its remote-only nature, is not easily affected by typical causes of business disruption, such as local failures of equipment, power supplies, telecommunications, social unrest, terrorist attacks, fire, or natural disasters. System data from the [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis.html) may be leveraged as part of business continuity planning and testing. Additionally, the BCP works in conjunction with the [Disaster Recovery Plan (DRP)](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md).
+GitLab, by its remote-only nature, is not easily affected by typical causes of business disruption, such as local failures of equipment, power supplies, telecommunications, social unrest, terrorist attacks, fire, or natural disasters. System data from the [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis/) may be leveraged as part of business continuity planning and testing. Additionally, the BCP works in conjunction with the [Disaster Recovery Plan (DRP)](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md).
 
 ## Roles & Responsibilities
 
@@ -45,8 +45,8 @@ The Recovery Time Objective (RTO) is the duration of time a service level or bus
 For a business continuity plan to be effective, it needs to be triggered as soon as possible; too early or late can reduce its efficacy. Key decision points to consider when a BCP has to be triggered or invoked are given below:
 
 - When an incident turns into an event like a disaster, breach, or something which classifies as a [Severity 1](/handbook/security/engaging-with-security/#severity-and-priority-labels-on-security-issues)
-- When the estimated time of resolution for a potential breach is greater than the normal estimated time for regular [security incidents](/handbook/security/security-operations/sirt/sec-incident-response.html)
-- When the recovery of an incident is uncertain, a decision must be made to invoke the business continuity plan if the disruption cannot be resolved within the specified [incident recovery timelines](/handbook/security/security-operations/sirt/sec-incident-response.html)
+- When the estimated time of resolution for a potential breach is greater than the normal estimated time for regular [security incidents](/handbook/security/security-operations/sirt/sec-incident-response/)
+- When the recovery of an incident is uncertain, a decision must be made to invoke the business continuity plan if the disruption cannot be resolved within the specified [incident recovery timelines](/handbook/security/security-operations/sirt/sec-incident-response/)
 - When resolution of an incident with critical customers, depending on their service-level agreements is delayed, then the BC plan must be triggered
 
 ### Data Continuity System
@@ -179,5 +179,5 @@ Exceptions to this procedure will be tracked as per the [Information Security Po
 ## References
 
 - Parent Policy: [Information Security Policy](/handbook/security/)
-- [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis.html)
+- [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis/)
 - [Disaster Recovery Plan (DRP)](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md)

content/handbook/business-technology/enterprise-applications/entapps-crm/_index.md

@@ -311,7 +311,7 @@ Before a milestone can be closed, the following checks are performed by Sales Sy
 8. Commit your changes with a relevant message: `git commit -m "Fixing Apex CPU Errors"`.
 9. Using the link provided by GitLab, open a merge request, [make it a `Draft:`](/handbook/about/editing-handbook/#marking-a-merge-request-as-draft), and assign it to the Architect on the project.
 10. Comment on the related issue with an @ to the project's Architect for review, providing a link to the merge request. (this automatically links the merge request to the issue)
-11. The Architect (or assigned delegate) will assign the story a Change Management level, based on the scope of the change as defined [here](/handbook/business-technology/change-management/#change-request-types).
+11. The Architect (or assigned delegate) will assign the story a Change Management level, based on the scope of the change as defined [here](https://internal.gitlab.com/handbook/IT/it-change-management/#change-request-types).
 12. You will then need to document that the appropriate approvals (as defined in the [Approval Matrix](/handbook/sales/field-operations/sales-systems/#approval-matrix) section below) have been completed in the issue.
 13. If the Architect calls for a live demo, schedule the meeting and prep your sandbox to do a run through with the end customer.
 14. If the Architect calls for user acceptance testing, make sure the assigned testers have access to the sandbox where the work was done, and schedule testing.
@@ -432,7 +432,7 @@ We have begun the journey of further leveraging our own GitLab tool by creating
 
 Our own pipeline is based on the great work done by @mayanktahil and @francispotter: [the SFDC CI/CD templates](https://gitlab.com/sfdx/sfdx-project-template).  If you are interested in more information about this project and want to see it in action, check out [Salesforce Development with GitLab](https://www.youtube.com/watch?v=Z1JSIFLdIB4) and [Accelerate DevOps with GitLab and Salesforce](https://www.youtube.com/watch?v=tylPp9QlLu4)
 
-With this comes some change, as we are now more stricly enforcing [compliance controls](/handbook/security/security-assurance/security-compliance/guidance/compliance.html) by limiting manual changes into the STAGING org.
+With this comes some change, as we are now more stricly enforcing [compliance controls](/handbook/security/security-assurance/security-compliance/guidance/compliance/) by limiting manual changes into the STAGING org.
 
 Effective 2/16/2022, the following methods are the only approved way to deploy to STAGING.
 

content/handbook/business-technology/enterprise-applications/guides/product-catalog.md

@@ -7,7 +7,7 @@ description: "How to request the creation or modification of a SKU."
 
 ## Change Management and SDLC Process
 
-For SOX/audit purposes, all changes to the Zuora Billing product catalog must be properly tested, adhering to [Business Technology Change Management](/handbook/business-technology/change-management/) policies and the [Software Development Lifecycle Process for Finance Systems](https://gitlab.com/groups/gitlab-com/business-technology/enterprise-apps/financeops/-/wikis/SDLC-for-Finance-Systems).
+For SOX/audit purposes, all changes to the Zuora Billing product catalog must be properly tested, adhering to [Business Technology Change Management](https://internal.gitlab.com/handbook/IT/it-change-management/) policies and the [Software Development Lifecycle Process for Finance Systems](https://gitlab.com/groups/gitlab-com/business-technology/enterprise-apps/financeops/-/wikis/SDLC-for-Finance-Systems).
 
 ## How to request the creation or modification of a SKU
 
@@ -169,7 +169,7 @@ The required approvals will differ depending on whether it is a Professional Ser
 
 {{% panel header="**Next Steps**" header-bg="success" %}}
 
-- After all above steps are complete and required approval have been obtained, remove the ~"SKU - Gathering Requirements" label and tag `@gitlab-com/business-technology/enterprise-apps/financeops` for intake and prioritization of the SKU request so that it can be configured in the Zuora Billing product catalog and made quotable in Salesforce. Please note that all changes must follow the [Business Technology Change Management](/handbook/business-technology/change-management/) for SOX/Audit purposes.
+- After all above steps are complete and required approval have been obtained, remove the ~"SKU - Gathering Requirements" label and tag `@gitlab-com/business-technology/enterprise-apps/financeops` for intake and prioritization of the SKU request so that it can be configured in the Zuora Billing product catalog and made quotable in Salesforce. Please note that all changes must follow the [Business Technology Change Management](https://internal.gitlab.com/handbook/IT/it-change-management/) for SOX/Audit purposes.
 - If the SKU will be sold through the channel, assign the issue to the `Sales Operations Analyst` listed in Step 6 to add the SKU to the quarterly update issue, the upcoming Pricebook and any other necessary information
 - If the SKU requires a service description, it is the Business Sponsor's responsibility to complete step 7
 {{% /panel %}}
@@ -238,7 +238,7 @@ The required approvals will differ depending on whether it is a Professional Ser
 Once all of the above steps are complete and required approval are obtained, please remove the ~"SKU - Gathering Requirements" label and tag `@gitlab-com/business-technology/enterprise-apps/financeops` for intake and prioritization of the SKU retirement request so that it can be deprecated in the Zuora Billing product catalog and no longer quotable in Salesforce.
 
 {{% alert color="warning" %}}
-Please note that all changes must follow the [Business Technology Change Management](/handbook/business-technology/change-management/) for SOX/Audit purposes.
+Please note that all changes must follow the [Business Technology Change Management](https://internal.gitlab.com/handbook/IT/it-change-management/) for SOX/Audit purposes.
 {{% /alert %}}
 
 ## FAQ
@@ -256,6 +256,6 @@ Please note that all changes must follow the [Business Technology Change Managem
 5. **What information can be changed after the SKU goes live?**
     - Please refer to [Post Go Live SKU Modifications](#post-go-live-sku-modifications) section of this handbook page
 6. **Can we just configure the SKU in production and skip the sandbox?**
-    - Unfortunately, no. For SOX/audit purposes, all changes to the Zuora Billing product catalog must be properly tested, adhering to [Business Technology Change Management](/handbook/business-technology/change-management/) policies and the [Software Development Lifecycle Process for Finance Systems](https://gitlab.com/groups/gitlab-com/business-technology/enterprise-apps/financeops/-/wikis/SDLC-for-Finance-Systems).
+    - Unfortunately, no. For SOX/audit purposes, all changes to the Zuora Billing product catalog must be properly tested, adhering to [Business Technology Change Management](https://internal.gitlab.com/handbook/IT/it-change-management/) policies and the [Software Development Lifecycle Process for Finance Systems](https://gitlab.com/groups/gitlab-com/business-technology/enterprise-apps/financeops/-/wikis/SDLC-for-Finance-Systems).
 7. **I only want to update the name/description of an existing SKU, do I need to go through this entire process?**
     - If you are not changing the charge type, unit of measure, charge model, charge timing or list price then you can simply submit an issue in [this directory](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/new#) using the template `CM: Configuration Change [Generic]` and fill out the `Requestor` section.

content/handbook/business-technology/enterprise-applications/it-compliance/_index.md

@@ -48,7 +48,7 @@ Our [IT Compliance](https://gitlab.com/groups/gitlab-com/-/boards/1802558?label_
 
 #### IT General Controls
 
-[IT General Controls](/handbook/business-technology/it-compliance/ITGC.html)
+[IT General Controls](/handbook/business-technology/it-compliance/ITGC/)
 
 **Most Common:**
 
@@ -73,4 +73,4 @@ IT Compliance works closely with our Security Compliance team to ensure that Git
 
 #### Business Technology Change Management
 
-IT Compliance works closely with our internal business partners for all Enterprise Application [Change Management](/handbook/business-technology/change-management/). More information can be found in our [Business Technology Change Management](https://internal.gitlab.com/handbook/it/it-change-management/) handbook page.
+IT Compliance works closely with our internal business partners for all Enterprise Application [Change Management](https://internal.gitlab.com/handbook/IT/it-change-management/). More information can be found in our [Business Technology Change Management](https://internal.gitlab.com/handbook/it/it-change-management/) handbook page.

content/handbook/business-technology/enterprise-applications/pmo/pmo-governance.md

@@ -151,7 +151,7 @@ One of the deliverables of the program beyond a working technical solve is docum
 
 ### Clear documentation for compliance
 
-Additionally, we need clear documentation to meet change management controls and new product introduction controls. These are fully documented [here](/handbook/business-technology/it-compliance/ITGC.html).
+Additionally, we need clear documentation to meet change management controls and new product introduction controls. These are fully documented [here](/handbook/business-technology/it-compliance/ITGC/).
 
 The relevant controls that need to be documented in these programs are these three:
 
@@ -177,7 +177,7 @@ As a result the DRI needs to:
 - Confirm that full scope is documented prior to go-live and reconciled with implemented functionality.
 - Ensure there is documentation that UAT was complete and sign-off on the UAT by business stakeholders established in the core team. This UAT sign-off should be reviewed by the steering committee and signed off as well prior to go-live.
 - Testing over key processes, reports, and ensuring business needs will be met by the system (and how).
-- When known issues are identified during UAT or prior to go-live, they need to be documented and issue resolution/remediation needs to be tracked. All critical and high risk issues that impact security and functionality of the system need to be resolved before go-live. However, if there are exceptional situations, a workaround plan needs to be identified, documented, and approved by the Business, IT leads, and the steering committee before go-live. All open issues before go-live need to be documented, tracked, and resolved post go-live, and resolution documentation needs to be retained. 
+- When known issues are identified during UAT or prior to go-live, they need to be documented and issue resolution/remediation needs to be tracked. All critical and high risk issues that impact security and functionality of the system need to be resolved before go-live. However, if there are exceptional situations, a workaround plan needs to be identified, documented, and approved by the Business, IT leads, and the steering committee before go-live. All open issues before go-live need to be documented, tracked, and resolved post go-live, and resolution documentation needs to be retained.
 - Final approval for business go-live is captured. Approvals from technical owners and business owners at appropriate levels (e.g. does this warrant CFO sign-off vs. Manager sign-off).
 
 ##### SDLC Approvals

content/handbook/business-technology/tech-stack-applications.md

@@ -25,7 +25,7 @@ The historical spreadsheets (deprecated on 2020-10-16 and 2021-03-03) can be fou
 |----------|------------------------------|
 |Business and Technical Owners of Systems|Accountable for completeness and accuracy of Tech Stack data; Process [Tech Stack updates](/handbook/business-technology/tech-stack-applications/#tech-stack-updates); Primary contacts for system-related inquiries and administration.|
 |IT Business Technology| Code Owners of Tech Stack; Advise Business and Technical Owners in supporting systems. |
-|Security Risk|Help facilitate Tech Stack updates, including the [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis.html#business-impact-analysis) for new and existing systems.|
+|Security Risk|Help facilitate Tech Stack updates, including the [Business Impact Analysis](/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis/#business-impact-analysis) for new and existing systems.|
 
 ## Tech Stack Definitions
 
@@ -60,9 +60,9 @@ Please ensure that whenever you update the tech stack, you follow the instructio
 | 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/data-classification-standard.html).| 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/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/prod/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.html). 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.html) (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|
+|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 |
 | employee_or_customer_facing_app | Text (employee, customer) | If access is limited to GitLab team members, then please add the `employee` word. If access can be granted to external parties, then add `customer` | MR Author and contributors |
 | notes | Text or Unknown** | Additional relevant information about the system that is not captured in any other field. Examples include the GitLab Epic for implementation and rollout. | Optional, MR Author and contributors |

content/handbook/ceo/office-of-the-ceo/jihu-support/_index.md

@@ -97,7 +97,7 @@ To notify JiHu of an upcoming security release, please simply post a comment in:
 
 GitLab Inc will follow the [documented vulnerability disclosure process](https://about.gitlab.com/security/disclosure/#vulnerability-disclosure) and will not provide detailed information about vulnerabilities directly to JiHu. No information will be shared prior to or during an in-progress security release.
 
-Only after a GitLab [security release](/handbook/engineering/releases/security-releases/), GitLab Inc may provide JiHu with:
+Only after a GitLab [security release](/handbook/engineering/infrastructure/library/security-releases-development/), GitLab Inc may provide JiHu with:
 
 - A link to the public security release blog post
 - A link to the GitLab issue describing the vulnerability, which will remain confidential until 30 days after the release in which the vulnerability was patched

content/handbook/ceo/office-of-the-ceo/jihu-support/jihu-security-review-process.md

@@ -30,7 +30,7 @@ An automated comment pings the AppSec team after the MR receives its first appro
 ### Determining who will perform a security review of a JiHu contribution
 
 When the AppSec team is pinged on a JiHu contribution, it will typically be first seen by
-the AppSec engineer on [Triage (mentions and issues) Rotation](/handbook/security/product-security/application-security/runbooks/triage-rotation.html). This person should:
+the AppSec engineer on [Triage (mentions and issues) Rotation](/handbook/security/product-security/application-security/runbooks/triage-rotation/). This person should:
 
 1. Ping the stable counterpart for the [relevant part of the codebase](/handbook/product/categories/#devops-stages) and ask them to perform the review
     - If the change is small or easy to review, the AppSec engineer on triage can do the review themselves and `@-mention` the stable counterpart for visibility

content/handbook/ceo/office-of-the-ceo/jihu-support/release-certification.md

@@ -5,7 +5,7 @@ title: Release Certification
 ## Process for Release Certification
 
 Every release with JiHu contributions needs to be certified by a member of the
-[Federal Application Security team](/handbook/security/product-security/application-security/index.html).
+[Federal Application Security team](/handbook/security/product-security/application-security/).
 This is required to satisfy PubSec/FedRamp requirements and
 to handle JiHu's merge request contributions to GitLab Inc repositories.
 
@@ -21,7 +21,7 @@ This means that only members of the Federal AppSec team are eligible to perform
 Note that *any* member of the Application Security team may review and approve a JiHu contribution,
 but only Federal AppSec team members can certify the release.
 
-Members of the Federal AppSec team are responsible for certifying monthly releases. Their assignment is [managed by automation](/handbook/security/product-security/application-security/runbooks/triage-rotation.html). These assignments will also need to be reflected on the
+Members of the Federal AppSec team are responsible for certifying monthly releases. Their assignment is [managed by automation](/handbook/security/product-security/application-security/runbooks/triage-rotation/). These assignments will also need to be reflected on the
 [Release Managers page](https://about.gitlab.com/community/release-managers/), under the AppSec Release Certification column.
 
 ### Certification process

content/handbook/communication/_index.md

@@ -905,8 +905,8 @@ As you're creating external or business content for GitLab, please refer to the
 
 This list offers additional guidance for written communication at GitLab:
 
-1. Do not use rich text, it makes it hard to copy/paste. Use [Markdown](/docs/markdown-guide/) to format text that is stored in a Git repository. In Google Docs, use "Normal text" using the style/heading/formatting dropdown and paste without formatting.
-1. Read our [Markdown Style Guide](/docs/markdown-guide/) for more information when using Markdown.
+1. Do not use rich text, it makes it hard to copy/paste. Use [Markdown](https://handbook.gitlab.com/docs/markdown-guide/) to format text that is stored in a Git repository. In Google Docs, use "Normal text" using the style/heading/formatting dropdown and paste without formatting.
+1. Read our [Markdown Style Guide](https://handbook.gitlab.com/docs/markdown-guide/) for more information when using Markdown.
 1. Do not use ALL CAPS because it [feels like shouting](https://en.wikipedia.org/wiki/All_caps#Association_with_shouting). However, there is the [`#all-caps` Slack channel](https://gitlab.slack.com/archives/C01BC085AVB) for your good-natured shouting needs.
 1. We use Unix style (lf) line endings, not Windows style (crlf), please ensure `*.md text eol=lf` is set in the repository's `.gitattributes` and run `git config --global core.autocrlf input` on your client.
 1. When specifying measurements, please include both Metric and Imperial equivalents.

content/handbook/communication/deep-dives.md

@@ -15,7 +15,7 @@ An example format guideline:
 - Implementation Overview (how is it implemented?)
 - Q&A
 
-**Note:** The support team have documented similar initiatives in the handbook: [Support Deep Dives](/handbook/support/advanced-topics/index.html#deep-dives) and [Support Training Modules](/handbook/support/advanced-topics/index.html#support-training-modules).
+**Note:** The support team have documented similar initiatives in the handbook: [Support Deep Dives](/handbook/support/advanced-topics/#deep-dives) and [Support Training Modules](/handbook/support/advanced-topics/#support-training-modules).
 
 ### Preparation steps