Repository: harness/developer-hub
Pull request #9683: STO: Restructure Issue Exemption Workflow Docs
Author: login: tejakummarikuntla
Created: 2025-03-11T18:49:44Z | Merged: 2025-03-14T02:55:50Z

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.

## Description

* Please describe your changes: \__________________________________
* Jira/GitHub Issue numbers (if any): \______________________________
* Preview links/images (Internal contributors only): \__________________

## PR lifecycle

We aim to merge PRs within one week or less, but delays happen sometimes.

If your PR is open longer than two weeks without any human activity, please tag a [code owner](https://github.com/harness/developer-hub/blob/main/.github/CODEOWNERS) in a comment.

PRs must meet these requirements to be merged:

- [ ] Successful preview build.
- [ ] Code owner review.
- [ ] No merge conflicts.
- [ ] Release notes/new features docs: Feature/version released to at least one prod environment.



Diff:
diff --git a/docs/security-testing-orchestration/exemptions/exemption-workflows.md b/docs/security-testing-orchestration/exemptions/exemption-workflows.md
index 45aa4e306df..301ff6e8710 100644
--- a/docs/security-testing-orchestration/exemptions/exemption-workflows.md
+++ b/docs/security-testing-orchestration/exemptions/exemption-workflows.md
@@ -1,181 +1,88 @@
 ---
-title: Exemptions to override STO failure policies
-description: Procedures and best practices for requesting and approving exemptions.
-sidebar_label: Exemptions to override STO failure policies
+title: Request an issue exemption
+description: Steps to submit an issue exemption request
+sidebar_label: Request issue exemption
 sidebar_position: 60
 redirect_from: 
   - docs/security-testing-orchestration/use-sto/stop-builds-based-on-scan-results/exemption-workflows
 ---
 
-STO’s exemption workflows help developers raise exemption windows with product security teams for shipping software with vulnerabilities. Developers can request exemptions for specific vulnerabilities to allow their build pipelines to proceed even if these vulnerabilities are detected.
-
-:::note 
-[Security Testing Developers](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) and [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) users can request exemptions, but only Security Testing SecOps users can approve them.
-::: 
-
-## When exemptions are useful
-
-Here are some reasons wny your organization might want to exempt an issue:
-
-- Your organization has practices in place to mitigate the security risks of the issue.
-- The issue is in compliance with your organization's acceptable use policies.
-- The security risk is low and remediation would require too much effort or expense.
-- The scanner detects an issue but it is, in fact, a false positive.
-- You need to exempt an issue so you can deploy a hotfix. In this case, you can request a temporary exemption that expires within your organization's SLA for fixing security issues.
-- There are currently no known fixes or remediation steps available for the detected vulnerability. You might want to enable [Harness AI Development Assistant (AIDA™)](/docs/security-testing-orchestration/remediations/ai-based-remediations) to help you remediate your issues using AI.
-
-
 import request_exemption from '../use-sto/static/request-exemption.png'
 import open_exemption_details from '../use-sto/static/open-exemption-details.png'
 import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
 
-## What happens when an STO exemption gets approved
-
-To see the list of pending exemptions, select **Exemptions** in the left menu. Each exemption corresponds to one vulnerability. If a scan detects a vulnerability with an active exemption, the pipeline proceeds even if the vulnerability matches the failure criteria for the step.
-
-## Important notes for exemptions in STO
-
-This topic assumes that you have the following:
-
-* An STO pipeline as described in [Set up Harness for STO](../get-started/onboarding-guide.md).
-* The scan step has failure criteria specified.
-
-  STO supports two methods for specifying failure criteria: 
-
-   - [Fail on Severity](/docs/security-testing-orchestration/get-started/key-concepts/fail-pipelines-by-severity)  Every scan step has a Fail on Severity setting that fails the step if the scan detects any issues with the specified severity or higher. 
-
-   - [OPA policies](/docs/security-testing-orchestration/policies/create-opa-policies) You can use Harness Policy as Code to write and enforce policies based on severity, reference ID, title, CVE age, STO output variables, and number of occurrences.
-
-* At least one successful build with a set of detected security issues. 
-* Security Testing Developer or [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions are required to [request exemptions](#request-an-sto-exemption).
-* Only Security Testing SecOps users can [review, approve, reject,](#review-an-sto-exemption) and [update](#good-practice-review-and-update-sto-exemptions-periodically) exemptions.  
-
-## Request an STO exemption
-
-1. Select **Executions** (left menu) and then go to a successful build.  
-
-2. Select **Security Tests** and then do the following:
-
-   1. Select the issue you want to exempt.  The **Issue Details** pane opens on the right. 
-   2. Select **Request Exemption**.
-
-
-      <img src={request_exemption} alt="Request Exemption button" height="50%" width="50%" />
-
-   3. In **Request Exemption for Issue**, specify:
-      1. **Where do you want this issue to be Exempted?** 
-
-         Select **This Pipeline** unless you know it's safe to exempt the issue everywhere in the project.
-
-      2. **For how long?** 
-
-         In general, you should select the shortest practical time window for your exemption. 
-
-      3. **Reason this issue should be exempted** 
-
-         Select one of the following reasons and provide any additional information for the [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  approver:
-
-         * **Compensating controls** — Your organization has infrastructure and policies in place to mitigate the security risks of this vulnerability. 
-
-           For example, suppose a scan detects a vulnerability with a specific service. This vulnerability might be mitigated because:
-
-           - The service is behind a firewall that requires authorized access, or
-
-           - The network may have host- or network-based intrusion prevention systems in place.
-
-         * **Acceptable use** — The scanner identified this practice as a vulnerability, but this practice is acceptable based on your organization's security guidelines. For example, anonymous FTP access may be a deliberate practice and not a vulnerability.
-
-         * **Acceptable risk** — The security risk of this vulnerability is low and remediation would require too much effort or expense: 
-
-           - Applying a specific patch for a vulnerability might prevent a service from functioning. 
-
-           - The vulnerability is minimal and the remediation would require too much time, money, or resources.
-
-         * **False positives** — The scanner identifies this as a vulnerability but it is, in fact, a false positive. Requesting an exemption based on approval from a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV). 
-
-         * **Fix unavailable** — There are currently no known fixes or remediation steps available for the detected vulnerability. 
-
-         * **Other**
-
-      4. **Further description the reason this issue should be exempted** 
-
-         It is good practice to provide enough information for the reviewer to determine that this exemption is safe.
-
-      4. **URL Reference** 
-
-         Paste the link you copied in the previous request, or add a different link that provides information about the specific issue you want the pipeline to ignore. If your repo already addresses the issue, for example, you can include a link to the relevant code.
-
-   5. Click **Create Request**.
-
-      ![](../use-sto/static/exemption-click-create-request.png)
-
-3. Send an email or Slack to your [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  reviewer with the URL to the Security Tests page with the relevant issue selected.
-
-## Approve, reject, or cancel an STO exemption
+When a security scan detects issues of varying severities and an enforced OPA policy blocks them, it can cause pipeline execution to fail. To prevent the pipeline from being blocked due to specific issues, you can request an exemption. Once approved, these exemptions are applied in subsequent scans, allowing the pipeline to proceed without interruption.
 
 :::note
-
-This workflow requires [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions.
-
+To raise an issue exemption, you must have **Security Testing Developer** or **Security Testing SecOps** user permissions.
 :::
 
-1. You should receive an email or Slack from a developer that includes a URL to the relevant issue. Go to the URL provided.
- 
-   The URL should point to a Security Tests page in Harness with the issue selected in the **Issue Details** pane on the right. If the relevant issue isn't visible, notify the developer. 
-
-2. Select **Exemptions** (left menu) > **Pending** and then select the pending exemption to view the exemption details.
-
-   ![](../use-sto/static/approve-exemption-00.png)
+Follow these steps to request an exemption for a security issue:
 
-3. Review the exemption request. The **Issue Details** pane includes a high-level summary of the issue, links to relevant documentation, and a list of all locations in the scanned object where the issue was detected. 
+### Step 1: Access the build executions
 
-    :::note
+1. From the **left navigation**, select **Executions**.
+2. Locate and click on the build for which you want to request an exemption.
 
-    - The **Issue Details** pane is comprehensive, but might not include all the information you need. You might want to research the issue further before you approve the request.
+### Step 2: Navigate to the issue for exemption
 
-    - Consider the **Requested Duration** for the exemption request. When you approve a request, the exemption remains active only for the specified time window (for example, 7 days from the approval time). 
+1. Within the build execution details, select the **Security Tests** tab.
+2. Find the issue you want to exempt and click on it. The **Issue Details** pane will open on the right side of the screen.
 
-    - It is good practice to [define a baseline for every target](/docs/security-testing-orchestration/get-started/key-concepts/targets-and-baselines#every-target-needs-a-baseline). If the target does not have a baseline defined, you won't see any exemption details. Instead, you will see a link to define the target baseline. 
+### Step 3: Request the exemption
 
-       <img src={baseline_not_defined} alt="Can't view exemption details because the target has no baseline" height="50%" width="50%" />
+In the **Issue Details** pane, click on the **Request Exemption** button.  
+<DocImage path={require('./static/request-exemption.png')} width="60%" height="60%" title="Click to view full size image" />
 
-    :::
+A form will open titled **Request Exemption for Issue**. Complete the following fields:
+<DocImage path={require('./static/request-exemption-form.png')} width="80%" height="80%" title="Click to view full size image" />
 
- 4. Select one of the following:
- 
-    - **Approve** The request is approved. This issue will not block future pipeline executions for the requested duration (see **Time Remaining** in the **Approved** table).
-    - **Reject** The request moves to the **Rejected** table, where a [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user can approve it later if appropriate. 
-    - **Cancel** The request is cancelled and removed from the exemption list. If a user wants an exemption for the issue, they must file a new request. 
+#### Where do you want this issue to be exempted?
+You can select one of the following options to specify the scope of the exemption:
+   - **This Target** – This exemption applies only to the specific target, meaning that the issue will be ignored across all pipelines using that target within the project. However, if the issue is detected in other targets, it will still be reported.
+   - **This Pipeline** – Exempts the issue only for this specific pipeline. Future scans in other pipelines or projects will still report the issue.  
+   - **This Project** – Exempts the issue across all pipelines and targets within the project. Use this option only if you are certain that the issue should be ignored across the entire project.  
 
-     ![](../use-sto/static/exemptions-approved.png)
+#### For how long?
+   - Choose the shortest practical time window for the exemption to limit the exposure to the identified risk.
 
-      You can control whether users can approve or reject their own exemption requests. This setting can be managed by enabling or disabling the **Users can approve their own exemptions** option. Find this setting under **Exemption settings** on the **Default settings** page. This is available in the project, organization and account level settings.
-      :::note
-      This setting is behind the feature flag `STO_EXEMPTION_SETTING`. Contact [Harness Support](mailto:support@harness.io) to enable this setting.
-      :::
+#### Reason
+- Select one of the following reasons for the exemption and provide relevant details:
 
- 
+   **Compensating controls** 
+   Your organization has infrastructure and policies in place to mitigate the security risks of this vulnerability. For example, suppose a scan detects a vulnerability with a specific service. This vulnerability might be mitigated because:
+   - The service is behind a firewall that requires authorized access, or
+   - The network may have host- or network-based intrusion prevention systems in place.
+   
+   **Acceptable use**
+   The scanner identified this practice as a vulnerability, but this practice is acceptable based on your organization's security guidelines. For example, anonymous FTP access may be a deliberate practice and not a vulnerability.
+   
+   **Acceptable risk**
+   The security risk of this vulnerability is low and remediation would require too much effort or expense:
+   - Applying a specific patch for a vulnerability might prevent a service from functioning.
+   - The vulnerability is minimal and the remediation would require too much time, money, or resources.
 
-## Good practice: Review and update STO exemptions periodically
+   **False positives**
+   The scanner identifies this as a vulnerability but it is, in fact, a false positive. Requesting an exemption based on approval from a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV).
 
-:::note
-
-These workflows require [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) user permissions.
+   **Fix unavailable**
+   There are currently no known fixes or remediation steps available for the detected vulnerability.
 
-:::
+   **Other**
+   If none of the above reasons fit, provide a detailed technical explanation of why the issue should be exempted.
 
-It is good practice for a [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) user in your organization to review all exemptions periodically and update the status of individual exemptions as needed. 
+#### Further Description
+   Include any additional context to help the reviewer understand why this exemption is safe. This could include technical details, potential mitigations, or any other relevant information.
 
-To review all exemptions, select **Security Testing Orchestration** > **Exemptions** in the left menu. This page shows the high-level information for all pending, approved, rejected, and expired exemptions. 
+#### URL Reference  
+   Paste any relevant URL (e.g., to a documentation page or a GitHub repository) that provides additional context or information about the issue. For example, if the issue is already addressed in your code, link to the relevant section.
 
-You can view the **Time Remaining** for approved exemptions and **Requested Duration** for pending, rejected, and expired exemptions. 
 
-SecOps users can do the following in this page:
+After filling out the form, click **Create Request** to submit the exemption request.
 
-* Reject pending and approved exemptions
-* Approve pending and rejected exemptions
-* Re-open expired exemptions
-* Cancel (delete) pending, approved, rejected, or expired exemptions
+### Step 4: Notify the Security Testing SecOps reviewer
 
+After creating the exemption request:
 
-   ![](../use-sto/static/exemption-security-review.png)
+1. Manually notify your **Security Testing SecOps** reviewer with the details of the exemption request.
+2. Provide any necessary context and ensure the reviewer has all the information to assess the exemption.
diff --git a/docs/security-testing-orchestration/exemptions/issue-exemption-workflow.md b/docs/security-testing-orchestration/exemptions/issue-exemption-workflow.md
new file mode 100644
index 00000000000..a82ac8fedd4
--- /dev/null
+++ b/docs/security-testing-orchestration/exemptions/issue-exemption-workflow.md
@@ -0,0 +1,57 @@
+---
+title: Issue exemption workflow
+description: Overview of issue exemption process in Harness STO.
+sidebar_label: Issue exemption workflow
+sidebar_position: 59
+redirect_from: 
+---
+
+Issue Exemption workflows in STO enable developers to request exemptions for specific security vulnerabilities when shipping software. If a security scanner in the pipeline detects a vulnerability and an [OPA policy](/docs/security-testing-orchestration/policies/enforce-opa-policies) enforces blocking such vulnerabilities, the pipeline will be failed. In such cases, developers can [submit exemption requests](/docs/security-testing-orchestration/exemptions/exemption-workflows) to the product security team for review. If approved, the pipeline can proceed despite the detected vulnerabilities. These workflows provide a controlled mechanism for managing security exceptions while ensuring visibility and oversight.
+
+:::note 
+[Security Testing Developers](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) and [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) users can request exemptions, but only Security Testing SecOps users can approve them.
+::: 
+
+<DocImage path={require('./static/exemption-pipeline-status.png')} width="100%" height="100%" title="Click to view full size image" />
+
+
+Users with roles *Security Testing Developer* and *Security Testing SecOps* can raise exemptions. An exemption request can be raised for a specific issue. Once submitted, the request can be processed by either approving, rejecting, or canceling it. Refer to [Request Issue Exemption](/docs/security-testing-orchestration/exemptions/exemption-workflows) for details on raising an exemption request, and [Manage Issue Exemption](/docs/security-testing-orchestration/exemptions/manage-exemptions) for handling exemption requests.
+
+<DocImage path={require('./static/exemption-workflow.png')} width="80%" height="80%" title="Click to view full size image" />
+
+## When exemptions are useful
+
+Here are some reasons wny your organization might want to exempt an issue:
+
+- Your organization is aware of this issue and is actively working on a fix. In the meantime, they want to exempt it from blocking the pipeline.
+- The issue is in compliance with your organization's acceptable use policies.
+- The security risk is low and remediation would require too much effort or expense.
+- The scanner detects an issue but it is, in fact, a false positive.
+- You need to exempt an issue so you can deploy a hotfix. In this case, you can request a temporary exemption that expires within your organization's SLA for fixing security issues.
+- There are currently no known fixes or remediation steps available for the detected vulnerability. You might want to enable [Harness AI Development Assistant (AIDA™)](/docs/security-testing-orchestration/remediations/ai-based-remediations) to help you remediate your issues using AI.
+
+
+import request_exemption from '../use-sto/static/request-exemption.png'
+import open_exemption_details from '../use-sto/static/open-exemption-details.png'
+import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
+
+## What happens when an STO exemption gets approved
+
+To see the list of pending exemptions, select **Exemptions** in the left menu. Each exemption corresponds to one vulnerability. If a scan detects a vulnerability with an active exemption, the pipeline proceeds even if the vulnerability matches the failure criteria for the step. Refer to [Manage Issue Exemption](/docs/security-testing-orchestration/exemptions/manage-exemptions) to learn more about handling exemption requests.
+
+<!-- ## Important notes for exemptions in STO
+
+This topic assumes that you have the following:
+
+* An STO pipeline as described in [Set up Harness for STO](../get-started/onboarding-guide.md).
+* The scan step has failure criteria specified.
+
+  STO supports two methods for specifying failure criteria: 
+
+   - [Fail on Severity](/docs/security-testing-orchestration/get-started/key-concepts/fail-pipelines-by-severity)  Every scan step has a Fail on Severity setting that fails the step if the scan detects any issues with the specified severity or higher. 
+
+   - [OPA policies](/docs/security-testing-orchestration/policies/create-opa-policies) You can use Harness Policy as Code to write and enforce policies based on severity, reference ID, title, CVE age, STO output variables, and number of occurrences.
+
+* At least one successful build with a set of detected security issues. 
+* Security Testing Developer or [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions are required to [request exemptions](#request-an-sto-exemption).
+* Only Security Testing SecOps users can [review, approve, reject,](#review-an-sto-exemption) and [update](#good-practice-review-and-update-sto-exemptions-periodically) exemptions.   -->
diff --git a/docs/security-testing-orchestration/exemptions/manage-exemptions.md b/docs/security-testing-orchestration/exemptions/manage-exemptions.md
new file mode 100644
index 00000000000..580f441d9c7
--- /dev/null
+++ b/docs/security-testing-orchestration/exemptions/manage-exemptions.md
@@ -0,0 +1,95 @@
+---
+title: Manage issue exemption requests
+description: Procedures and best practices for handling issue exemption requests.
+sidebar_label: Manage issue exemptions
+sidebar_position: 62
+---
+
+import request_exemption from '../use-sto/static/request-exemption.png'
+import open_exemption_details from '../use-sto/static/open-exemption-details.png'
+import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
+
+When an [issue exemption request](./exemption-workflows) is submitted, it goes through a defined lifecycle. The available actions to address these requests include **Approving**, **Rejecting**, or **Cancelling**. The exemption lifecycle consists of the following stages:
+
+:::note
+Users with role **Security Testing SecOps** can approve or manage the issue exemption requests.
+:::
+
+1. **Pending:** The request is newly created and awaits review. At this stage, users can choose to approve, reject, or cancel the request.
+
+2. **Approved:** The request has been reviewed and accepted. The issue is temporarily or permanently exempt from further action based on the exemption details.
+
+3. **Rejected:** The request has been reviewed and denied. The issue remains active, and the pipeline continues to enforce OPA policies as if no exemption was requested. 
+4. **Expired:** The exemption period has elapsed, or the exemption has been invalidated. Once expired, the issue returns to its original active state unless a new exemption is requested.
+
+<DocImage path={require('./static/exemption-lifecycle.png')} width="50%" height="50%" title="Click to view full size image" />
+
+
+## Approve, reject, or cancel an STO exemption
+
+<DocImage path={require('./static/exemption-workflow.png')} width="80%" height="80%" title="Click to view full size image" />
+
+To respond to an exemption request, navigate to the issue exemption request within the Security Tests tab of a specific pipeline execution. If the requester has not shared a direct link to the issue for exemption, you can request it from them. Alternatively, you can follow the steps below to locate the exemption and respond accordingly.
+
+:::note
+
+This workflow requires [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions.
+
+:::
+
+1. Select **Exemptions** from the left navigation and then select **Pending** to view the pending exemption requests.
+
+   ![](../use-sto/static/approve-exemption-00.png)
+
+3. Review the exemption request. The **Exemption Details** pane includes a high-level summary of the issue, links to relevant documentation, and a list of all locations in the scanned object where the issue was detected. 
+
+    :::note
+
+    - The **Exemption Details** pane is comprehensive, but might not include all the information you need. You might want to research the issue further before you approve the request.
+
+    - Consider the **Requested Duration** for the exemption request. When you approve a request, the exemption remains active only for the specified time window (for example, 7 days from the approval time). 
+
+    - It is good practice to [define a baseline for every target](/docs/security-testing-orchestration/get-started/key-concepts/targets-and-baselines#every-target-needs-a-baseline). If the target does not have a baseline defined, you won't see any exemption details. Instead, you will see a link to define the target baseline. 
+
+       <img src={baseline_not_defined} alt="Can't view exemption details because the target has no baseline" height="50%" width="50%" />
+
+    :::
+
+ 4. Select one of the following:
+ 
+    - **Approve** The request is approved. This issue will not block future pipeline executions for the requested duration (see **Time Remaining** in the **Approved** table).
+    - **Reject** The request moves to the **Rejected** table, where a [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user can approve it later if appropriate. 
+    - **Cancel** The request is cancelled and removed from the exemption list. If a user wants an exemption for the issue, they must file a new request. 
+
+     ![](../use-sto/static/exemptions-approved.png)
+
+      You can control whether users can approve or reject their own exemption requests. This setting can be managed by enabling or disabling the **Users can approve their own exemptions** option. Find this setting under **Exemption settings** on the **Default settings** page. This is available in the project, organization and account level settings.
+      :::note
+      This setting is behind the feature flag `STO_EXEMPTION_SETTING`. Contact [Harness Support](mailto:support@harness.io) to enable this setting.
+      :::
+
+ 
+
+## Good practice: Review and update STO exemptions periodically
+
+:::note
+
+These workflows require [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) user permissions.
+
+:::
+
+It is good practice for a [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) user in your organization to review all exemptions periodically and update the status of individual exemptions as needed. 
+
+To review all exemptions, select **Security Testing Orchestration** > **Exemptions** in the left menu. This page shows the high-level information for all pending, approved, rejected, and expired exemptions. 
+
+You can view the **Time Remaining** for approved exemptions and **Requested Duration** for pending, rejected, and expired exemptions. 
+
+SecOps users can do the following in this page:
+
+* Reject pending and approved exemptions
+* Approve pending and rejected exemptions
+* Re-open expired exemptions
+* Cancel (delete) pending, approved, rejected, or expired exemptions
+
+
+   ![](../use-sto/static/exemption-security-review.png)
diff --git a/docs/security-testing-orchestration/exemptions/static/exemption-lifecycle.png b/docs/security-testing-orchestration/exemptions/static/exemption-lifecycle.png
new file mode 100644
index 00000000000..3c60079e9a7
Binary files /dev/null and b/docs/security-testing-orchestration/exemptions/static/exemption-lifecycle.png differ
diff --git a/docs/security-testing-orchestration/exemptions/static/exemption-pipeline-status.png b/docs/security-testing-orchestration/exemptions/static/exemption-pipeline-status.png
new file mode 100644
index 00000000000..9d6b781d4a0
Binary files /dev/null and b/docs/security-testing-orchestration/exemptions/static/exemption-pipeline-status.png differ
diff --git a/docs/security-testing-orchestration/exemptions/static/exemption-workflow.png b/docs/security-testing-orchestration/exemptions/static/exemption-workflow.png
new file mode 100644
index 00000000000..c3a8cfe030a
Binary files /dev/null and b/docs/security-testing-orchestration/exemptions/static/exemption-workflow.png differ
diff --git a/docs/security-testing-orchestration/exemptions/static/request-exemption-form.png b/docs/security-testing-orchestration/exemptions/static/request-exemption-form.png
new file mode 100644
index 00000000000..57ec5b4e1df
Binary files /dev/null and b/docs/security-testing-orchestration/exemptions/static/request-exemption-form.png differ


Reviews:
user: login: priteshchandaliya
body: ![Screenshot 2025-03-11 at 12 52 45 PM](https://github.com/user-attachments/assets/05b1d969-ab0c-4b41-8c87-ac113af1b638)
The description does not look correct.

request issue exemption - It says procedure for requesting and approving? I think it should be just requesting.

 


state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-11T20:11:39Z
user: login: tejakummarikuntla
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-12T10:15:34Z
user: login: tejakummarikuntla
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-12T10:22:17Z
user: login: tejakummarikuntla
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-12T11:07:28Z
user: login: tejakummarikuntla
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-12T14:22:54Z
user: login: priteshchandaliya
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-14T02:55:40Z

Review comments:
diff_hunk: @@ -0,0 +1,58 @@
+---
+title: Issue Exemption Workflow
+description: Issue exemptions flow for requesting and approving.
+sidebar_label: Issue exemption workflow
+sidebar_position: 59
+redirect_from: 
+---
+
+Issue Exemption workflows in STO enable developers to request exemptions for specific security vulnerabilities when shipping software. If a security scanner in the pipeline detects a vulnerability or an [OPA policy violation](/docs/security-testing-orchestration/policies/enforce-opa-policies), the pipeline may be blocked, halting execution. In such cases, developers can [submit exemption requests](/docs/security-testing-orchestration/exemptions/exemption-workflows) to the product security team for review. If approved, the pipeline can proceed despite the detected vulnerabilities. These workflows provide a controlled mechanism for managing security exceptions while ensuring visibility and oversight.
path: docs/security-testing-orchestration/exemptions/issue-exemption-workflow.md
user: login: priteshchandaliya
body: If a security scanner in the pipeline detects a vulnerability and there is an OPA policy violation for blocking those vulnerabilities, then the pipeline will be blocked.

The essence of your statement is not exactly correct. I mean - the pipeline can only be halted by OPA violation and OPA policy can have any simple/complex rule related to data ingested by the scanner which is vulnerability, external policy failures, code coverage, etc. 
created_at: 2025-03-11T19:57:16Z
author_association: CONTRIBUTOR
path: docs/security-testing-orchestration/exemptions/static/exemption-pipeline-status.png
user: login: priteshchandaliya
body: Apply OOTB or OPA?

Apply OPA is the right step. Your statement feels as if OOB and OPA are 2 different things. 
"OOTB OPA policies" is one thing. 
created_at: 2025-03-11T19:58:57Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,58 @@
+---
+title: Issue Exemption Workflow
+description: Issue exemptions flow for requesting and approving.
+sidebar_label: Issue exemption workflow
+sidebar_position: 59
+redirect_from: 
+---
+
+Issue Exemption workflows in STO enable developers to request exemptions for specific security vulnerabilities when shipping software. If a security scanner in the pipeline detects a vulnerability or an [OPA policy violation](/docs/security-testing-orchestration/policies/enforce-opa-policies), the pipeline may be blocked, halting execution. In such cases, developers can [submit exemption requests](/docs/security-testing-orchestration/exemptions/exemption-workflows) to the product security team for review. If approved, the pipeline can proceed despite the detected vulnerabilities. These workflows provide a controlled mechanism for managing security exceptions while ensuring visibility and oversight.
+
+:::note 
+[Security Testing Developers](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) and [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) users can request exemptions, but only Security Testing SecOps users can approve them.
+::: 
+
+<DocImage path={require('./static/exemption-pipeline-status.png')} width="100%" height="100%" title="Click to view full size image" />
+
+
+Users with roles *Security Testing Developer* and *Security Testing SecOps* can raise exemptions. An exemption request can be raised for a specific issue. Once submitted, the request can be processed by either approving, rejecting, or canceling it. Refer to [Request Issue Exemption](/docs/security-testing-orchestration/exemptions/exemption-workflows) for details on raising an exemption request, and [Manage Issue Exemption](/docs/security-testing-orchestration/exemptions/manage-exemptions) for handling exemption requests.
+
+<DocImage path={require('./static/exemption-workflow.png')} width="80%" height="80%" title="Click to view full size image" />
+
+
+## When exemptions are useful
+
+Here are some reasons wny your organization might want to exempt an issue:
path: docs/security-testing-orchestration/exemptions/issue-exemption-workflow.md
user: login: priteshchandaliya
body: Your organization has practices in place to mitigate the security risks of the issue? I did not understand this point, others make sense. 




created_at: 2025-03-11T20:02:22Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,56 +1,23 @@
 ---
-title: Exemptions to override STO failure policies
+title: Request Issue Exemption
 description: Procedures and best practices for requesting and approving exemptions.
-sidebar_label: Exemptions to override STO failure policies
+sidebar_label: Request issue exemption
 sidebar_position: 60
 redirect_from: 
   - docs/security-testing-orchestration/use-sto/stop-builds-based-on-scan-results/exemption-workflows
 ---
 
-STO’s exemption workflows help developers raise exemption windows with product security teams for shipping software with vulnerabilities. Developers can request exemptions for specific vulnerabilities to allow their build pipelines to proceed even if these vulnerabilities are detected.
-
-:::note 
-[Security Testing Developers](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) and [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) users can request exemptions, but only Security Testing SecOps users can approve them.
-::: 
-
-## When exemptions are useful
-
-Here are some reasons wny your organization might want to exempt an issue:
-
-- Your organization has practices in place to mitigate the security risks of the issue.
-- The issue is in compliance with your organization's acceptable use policies.
-- The security risk is low and remediation would require too much effort or expense.
-- The scanner detects an issue but it is, in fact, a false positive.
-- You need to exempt an issue so you can deploy a hotfix. In this case, you can request a temporary exemption that expires within your organization's SLA for fixing security issues.
-- There are currently no known fixes or remediation steps available for the detected vulnerability. You might want to enable [Harness AI Development Assistant (AIDA™)](/docs/security-testing-orchestration/remediations/ai-based-remediations) to help you remediate your issues using AI.
-
-
 import request_exemption from '../use-sto/static/request-exemption.png'
 import open_exemption_details from '../use-sto/static/open-exemption-details.png'
 import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
 
-## What happens when an STO exemption gets approved
-
-To see the list of pending exemptions, select **Exemptions** in the left menu. Each exemption corresponds to one vulnerability. If a scan detects a vulnerability with an active exemption, the pipeline proceeds even if the vulnerability matches the failure criteria for the step.
-
-## Important notes for exemptions in STO
-
-This topic assumes that you have the following:
-
-* An STO pipeline as described in [Set up Harness for STO](../get-started/onboarding-guide.md).
-* The scan step has failure criteria specified.
-
-  STO supports two methods for specifying failure criteria: 
-
-   - [Fail on Severity](/docs/security-testing-orchestration/get-started/key-concepts/fail-pipelines-by-severity)  Every scan step has a Fail on Severity setting that fails the step if the scan detects any issues with the specified severity or higher. 
+When security scanning results in a list of issues with varying severities that could potentially block your pipelines, you can request an exemption to bypass specific issues. This ensures that approved exemptions are ignored in future scans, allowing your pipelines to continue uninterrupted.
path: docs/security-testing-orchestration/exemptions/exemption-workflows.md
user: login: priteshchandaliya
body: When security scanning results in a list of issues with varying severities and there is an OPA policy to block them, that could potentially block your pipelines
created_at: 2025-03-11T20:03:29Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,56 +1,23 @@
 ---
-title: Exemptions to override STO failure policies
+title: Request Issue Exemption
 description: Procedures and best practices for requesting and approving exemptions.
-sidebar_label: Exemptions to override STO failure policies
+sidebar_label: Request issue exemption
 sidebar_position: 60
 redirect_from: 
   - docs/security-testing-orchestration/use-sto/stop-builds-based-on-scan-results/exemption-workflows
 ---
 
-STO’s exemption workflows help developers raise exemption windows with product security teams for shipping software with vulnerabilities. Developers can request exemptions for specific vulnerabilities to allow their build pipelines to proceed even if these vulnerabilities are detected.
-
-:::note 
-[Security Testing Developers](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) and [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) users can request exemptions, but only Security Testing SecOps users can approve them.
-::: 
-
-## When exemptions are useful
-
-Here are some reasons wny your organization might want to exempt an issue:
-
-- Your organization has practices in place to mitigate the security risks of the issue.
-- The issue is in compliance with your organization's acceptable use policies.
-- The security risk is low and remediation would require too much effort or expense.
-- The scanner detects an issue but it is, in fact, a false positive.
-- You need to exempt an issue so you can deploy a hotfix. In this case, you can request a temporary exemption that expires within your organization's SLA for fixing security issues.
-- There are currently no known fixes or remediation steps available for the detected vulnerability. You might want to enable [Harness AI Development Assistant (AIDA™)](/docs/security-testing-orchestration/remediations/ai-based-remediations) to help you remediate your issues using AI.
-
-
 import request_exemption from '../use-sto/static/request-exemption.png'
 import open_exemption_details from '../use-sto/static/open-exemption-details.png'
 import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
 
-## What happens when an STO exemption gets approved
-
-To see the list of pending exemptions, select **Exemptions** in the left menu. Each exemption corresponds to one vulnerability. If a scan detects a vulnerability with an active exemption, the pipeline proceeds even if the vulnerability matches the failure criteria for the step.
-
-## Important notes for exemptions in STO
-
-This topic assumes that you have the following:
-
-* An STO pipeline as described in [Set up Harness for STO](../get-started/onboarding-guide.md).
-* The scan step has failure criteria specified.
-
-  STO supports two methods for specifying failure criteria: 
-
-   - [Fail on Severity](/docs/security-testing-orchestration/get-started/key-concepts/fail-pipelines-by-severity)  Every scan step has a Fail on Severity setting that fails the step if the scan detects any issues with the specified severity or higher. 
+When security scanning results in a list of issues with varying severities that could potentially block your pipelines, you can request an exemption to bypass specific issues. This ensures that approved exemptions are ignored in future scans, allowing your pipelines to continue uninterrupted.
 
-   - [OPA policies](/docs/security-testing-orchestration/policies/create-opa-policies) You can use Harness Policy as Code to write and enforce policies based on severity, reference ID, title, CVE age, STO output variables, and number of occurrences.
-
-* At least one successful build with a set of detected security issues. 
-* Security Testing Developer or [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions are required to [request exemptions](#request-an-sto-exemption).
-* Only Security Testing SecOps users can [review, approve, reject,](#review-an-sto-exemption) and [update](#good-practice-review-and-update-sto-exemptions-periodically) exemptions.  
+:::note
+To raise an issue exemption, you must have **Security Testing Developer** or **Security Testing SecOps** user permissions.
+:::
 
-## Request an STO exemption
+To request an issue exemption, follow these steps:
 
 1. Select **Executions** (left menu) and then go to a successful build.  
path: docs/security-testing-orchestration/exemptions/exemption-workflows.md
user: login: priteshchandaliya
body: successful or failed build?
created_at: 2025-03-11T20:04:23Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,56 +1,23 @@
 ---
-title: Exemptions to override STO failure policies
+title: Request Issue Exemption
 description: Procedures and best practices for requesting and approving exemptions.
-sidebar_label: Exemptions to override STO failure policies
+sidebar_label: Request issue exemption
 sidebar_position: 60
 redirect_from: 
   - docs/security-testing-orchestration/use-sto/stop-builds-based-on-scan-results/exemption-workflows
 ---
 
-STO’s exemption workflows help developers raise exemption windows with product security teams for shipping software with vulnerabilities. Developers can request exemptions for specific vulnerabilities to allow their build pipelines to proceed even if these vulnerabilities are detected.
-
-:::note 
-[Security Testing Developers](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) and [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) users can request exemptions, but only Security Testing SecOps users can approve them.
-::: 
-
-## When exemptions are useful
-
-Here are some reasons wny your organization might want to exempt an issue:
-
-- Your organization has practices in place to mitigate the security risks of the issue.
-- The issue is in compliance with your organization's acceptable use policies.
-- The security risk is low and remediation would require too much effort or expense.
-- The scanner detects an issue but it is, in fact, a false positive.
-- You need to exempt an issue so you can deploy a hotfix. In this case, you can request a temporary exemption that expires within your organization's SLA for fixing security issues.
-- There are currently no known fixes or remediation steps available for the detected vulnerability. You might want to enable [Harness AI Development Assistant (AIDA™)](/docs/security-testing-orchestration/remediations/ai-based-remediations) to help you remediate your issues using AI.
-
-
 import request_exemption from '../use-sto/static/request-exemption.png'
 import open_exemption_details from '../use-sto/static/open-exemption-details.png'
 import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
 
-## What happens when an STO exemption gets approved
-
-To see the list of pending exemptions, select **Exemptions** in the left menu. Each exemption corresponds to one vulnerability. If a scan detects a vulnerability with an active exemption, the pipeline proceeds even if the vulnerability matches the failure criteria for the step.
-
-## Important notes for exemptions in STO
-
-This topic assumes that you have the following:
-
-* An STO pipeline as described in [Set up Harness for STO](../get-started/onboarding-guide.md).
-* The scan step has failure criteria specified.
-
-  STO supports two methods for specifying failure criteria: 
-
-   - [Fail on Severity](/docs/security-testing-orchestration/get-started/key-concepts/fail-pipelines-by-severity)  Every scan step has a Fail on Severity setting that fails the step if the scan detects any issues with the specified severity or higher. 
+When security scanning results in a list of issues with varying severities that could potentially block your pipelines, you can request an exemption to bypass specific issues. This ensures that approved exemptions are ignored in future scans, allowing your pipelines to continue uninterrupted.
 
-   - [OPA policies](/docs/security-testing-orchestration/policies/create-opa-policies) You can use Harness Policy as Code to write and enforce policies based on severity, reference ID, title, CVE age, STO output variables, and number of occurrences.
-
-* At least one successful build with a set of detected security issues. 
-* Security Testing Developer or [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions are required to [request exemptions](#request-an-sto-exemption).
-* Only Security Testing SecOps users can [review, approve, reject,](#review-an-sto-exemption) and [update](#good-practice-review-and-update-sto-exemptions-periodically) exemptions.  
+:::note
+To raise an issue exemption, you must have **Security Testing Developer** or **Security Testing SecOps** user permissions.
+:::
 
-## Request an STO exemption
+To request an issue exemption, follow these steps:
 
 1. Select **Executions** (left menu) and then go to a successful build.  
path: docs/security-testing-orchestration/exemptions/exemption-workflows.md
user: login: priteshchandaliya
body: Look at point c, the sub-nest bullet is again a,b,c

> Where do you want this issue to be Exempted?
> Select This Pipeline unless you know it's safe to exempt the issue everywhere in the project.

Can we add a section to explain the scope at which we can request fore exemption - Pipeline, project and target
created_at: 2025-03-11T20:07:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -111,71 +78,3 @@ This topic assumes that you have the following:
 
 3. Send an email or Slack to your [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  reviewer with the URL to the Security Tests page with the relevant issue selected.
path: docs/security-testing-orchestration/exemptions/exemption-workflows.md
user: login: priteshchandaliya
body: This instruction should be removed or you should say, "manually" send the notification 
created_at: 2025-03-11T20:08:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,109 @@
+---
+title: Manage Exemptions
+description: Respond to the issue exemptions
+sidebar_label: Manage issue exemptions
+sidebar_position: 62
+---
+
+import request_exemption from '../use-sto/static/request-exemption.png'
+import open_exemption_details from '../use-sto/static/open-exemption-details.png'
+import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
+
+When an [issue exemption request](./exemption-workflows) is submitted, it goes through a defined lifecycle. The available actions to address these requests include **Approving**, **Rejecting**, or **Cancelling**. The exemption lifecycle consists of the following stages:
+
+:::note
+Users with role `Security Testing SecOps` can approve or manage the issue exemption requests.
+:::
+
+1. **Pending:**  
+   - The request is newly created and awaits review.  
+   - At this stage, users can choose to approve, reject, or cancel the request.
+
+2. **Approved:**  
+   - The request has been reviewed and accepted.  
+   - The issue is temporarily or permanently exempt from further action based on the exemption details.
+
+3. **Rejected:**
+   - The request has been reviewed and denied.  
+   - The issue remains active, and the pipeline continues to enforce security policies as if no exemption was requested. 
path: docs/security-testing-orchestration/exemptions/manage-exemptions.md
user: login: priteshchandaliya
body: lets be consistent

Use OPA or security policies. I would prefer OPA word for the policies in our docs
created_at: 2025-03-11T20:10:04Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,109 @@
+---
+title: Manage Exemptions
+description: Respond to the issue exemptions
+sidebar_label: Manage issue exemptions
+sidebar_position: 62
+---
+
+import request_exemption from '../use-sto/static/request-exemption.png'
+import open_exemption_details from '../use-sto/static/open-exemption-details.png'
+import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
+
+When an [issue exemption request](./exemption-workflows) is submitted, it goes through a defined lifecycle. The available actions to address these requests include **Approving**, **Rejecting**, or **Cancelling**. The exemption lifecycle consists of the following stages:
+
+:::note
+Users with role `Security Testing SecOps` can approve or manage the issue exemption requests.
+:::
+
+1. **Pending:**  
+   - The request is newly created and awaits review.  
+   - At this stage, users can choose to approve, reject, or cancel the request.
+
+2. **Approved:**  
+   - The request has been reviewed and accepted.  
+   - The issue is temporarily or permanently exempt from further action based on the exemption details.
+
+3. **Rejected:**
+   - The request has been reviewed and denied.  
+   - The issue remains active, and the pipeline continues to enforce security policies as if no exemption was requested. 
+4. **Expired:**  
+   - The exemption period has elapsed, or the exemption has been invalidated.  
+   - Once expired, the issue returns to its original active state unless a new exemption is requested.
+
+<DocImage path={require('./static/exemption-lifecycle.png')} width="50%" height="50%" title="Click to view full size image" />
+
+### Actions
+Here are the actions that can be performed on an issue exemption request.
+- **Approve:** Accept the request and apply the exemption.  
+- **Reject:** Decline the request and maintain the issue status.  
+- **Cancel:** Close the request before any decision is made.
+
+
+## Approve, reject, or cancel an STO exemption
+
+:::note
+
+This workflow requires [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions.
+
+:::
+
+1. You should receive an email or Slack from a developer that includes a URL to the relevant issue. Go to the URL provided.
path: docs/security-testing-orchestration/exemptions/manage-exemptions.md
user: login: priteshchandaliya
body: Wrong again
created_at: 2025-03-11T20:10:34Z
author_association: CONTRIBUTOR
path: docs/security-testing-orchestration/exemptions/static/exemption-pipeline-status.png
user: login: tejakummarikuntla
body: @priteshchandaliya I meant to refer to OOTB and OPA as
OOTB - a pipeline can be blocked based on the Fail On Severity field in the step configuration. 
OPA -  policies can be enforced from the Advanced Settings of the step to control pipeline execution. 

I can update the text to "Apply OPA Policies" if that's more appropriate.
created_at: 2025-03-12T10:15:34Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,58 @@
+---
+title: Issue Exemption Workflow
+description: Issue exemptions flow for requesting and approving.
+sidebar_label: Issue exemption workflow
+sidebar_position: 59
+redirect_from: 
+---
+
+Issue Exemption workflows in STO enable developers to request exemptions for specific security vulnerabilities when shipping software. If a security scanner in the pipeline detects a vulnerability or an [OPA policy violation](/docs/security-testing-orchestration/policies/enforce-opa-policies), the pipeline may be blocked, halting execution. In such cases, developers can [submit exemption requests](/docs/security-testing-orchestration/exemptions/exemption-workflows) to the product security team for review. If approved, the pipeline can proceed despite the detected vulnerabilities. These workflows provide a controlled mechanism for managing security exceptions while ensuring visibility and oversight.
+
+:::note 
+[Security Testing Developers](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) and [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles) users can request exemptions, but only Security Testing SecOps users can approve them.
+::: 
+
+<DocImage path={require('./static/exemption-pipeline-status.png')} width="100%" height="100%" title="Click to view full size image" />
+
+
+Users with roles *Security Testing Developer* and *Security Testing SecOps* can raise exemptions. An exemption request can be raised for a specific issue. Once submitted, the request can be processed by either approving, rejecting, or canceling it. Refer to [Request Issue Exemption](/docs/security-testing-orchestration/exemptions/exemption-workflows) for details on raising an exemption request, and [Manage Issue Exemption](/docs/security-testing-orchestration/exemptions/manage-exemptions) for handling exemption requests.
+
+<DocImage path={require('./static/exemption-workflow.png')} width="80%" height="80%" title="Click to view full size image" />
+
+
+## When exemptions are useful
+
+Here are some reasons wny your organization might want to exempt an issue:
path: docs/security-testing-orchestration/exemptions/issue-exemption-workflow.md
user: login: tejakummarikuntla
body: > Your organization has practices in place to mitigate the security risks of the issue.

It meant to say that the organization's security team is already aware of the issue and working on a fix. In the meantime, they would like to exempt it.

Can make it more relatable 

> Your organisation is aware of this issue and is actively working on a fix. In the meantime, they want to exempt it from blocking the pipeline.
created_at: 2025-03-12T10:22:17Z
author_association: CONTRIBUTOR
diff_hunk: @@ -111,71 +78,3 @@ This topic assumes that you have the following:
 
 3. Send an email or Slack to your [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  reviewer with the URL to the Security Tests page with the relevant issue selected.
path: docs/security-testing-orchestration/exemptions/exemption-workflows.md
user: login: tejakummarikuntla
body: Understood, made it clear it's a manual process.
created_at: 2025-03-12T11:07:28Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,109 @@
+---
+title: Manage Exemptions
+description: Respond to the issue exemptions
+sidebar_label: Manage issue exemptions
+sidebar_position: 62
+---
+
+import request_exemption from '../use-sto/static/request-exemption.png'
+import open_exemption_details from '../use-sto/static/open-exemption-details.png'
+import baseline_not_defined from '../use-sto/static/exemption-workflows-no-baseline-defined.png'
+
+When an [issue exemption request](./exemption-workflows) is submitted, it goes through a defined lifecycle. The available actions to address these requests include **Approving**, **Rejecting**, or **Cancelling**. The exemption lifecycle consists of the following stages:
+
+:::note
+Users with role `Security Testing SecOps` can approve or manage the issue exemption requests.
+:::
+
+1. **Pending:**  
+   - The request is newly created and awaits review.  
+   - At this stage, users can choose to approve, reject, or cancel the request.
+
+2. **Approved:**  
+   - The request has been reviewed and accepted.  
+   - The issue is temporarily or permanently exempt from further action based on the exemption details.
+
+3. **Rejected:**
+   - The request has been reviewed and denied.  
+   - The issue remains active, and the pipeline continues to enforce security policies as if no exemption was requested. 
+4. **Expired:**  
+   - The exemption period has elapsed, or the exemption has been invalidated.  
+   - Once expired, the issue returns to its original active state unless a new exemption is requested.
+
+<DocImage path={require('./static/exemption-lifecycle.png')} width="50%" height="50%" title="Click to view full size image" />
+
+### Actions
+Here are the actions that can be performed on an issue exemption request.
+- **Approve:** Accept the request and apply the exemption.  
+- **Reject:** Decline the request and maintain the issue status.  
+- **Cancel:** Close the request before any decision is made.
+
+
+## Approve, reject, or cancel an STO exemption
+
+:::note
+
+This workflow requires [Security Testing SecOps](/docs/security-testing-orchestration/get-started/onboarding-guide#add-security-testing-roles)  user permissions.
+
+:::
+
+1. You should receive an email or Slack from a developer that includes a URL to the relevant issue. Go to the URL provided.
path: docs/security-testing-orchestration/exemptions/manage-exemptions.md
user: login: tejakummarikuntla
body: Changed it to
> To respond to an exemption request, navigate to the issue exemption request within the Security Tests tab of a specific pipeline execution. If the requester has not shared a direct link to the issue for exemption, you can request it from them. Alternatively, you can follow the steps below to locate the exemption and respond accordingly.


created_at: 2025-03-12T14:22:54Z
author_association: CONTRIBUTOR

PR comments:
user: login: bot-gitexp-user
created_at: 2025-03-11T19:01:23Z
body: Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://67d087d2d0d6d6d2439e421d--harness-developer.netlify.app
author_association: NONE
user: login: bot-gitexp-user
created_at: 2025-03-11T19:52:02Z
body: Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://67d093b34600fde77c2bba87--harness-developer.netlify.app
author_association: NONE
user: login: bot-gitexp-user
created_at: 2025-03-12T14:45:04Z
body: Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://67d19d35cbbeb214e9dc4661--harness-developer.netlify.app
author_association: NONE
user: login: bot-gitexp-user
created_at: 2025-03-12T15:50:57Z
body: Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://67d1acaf0ed26a0c53d5c212--harness-developer.netlify.app
author_association: NONE