Workflows & Automation Guide

Last updated: 2026-04-29
Status: Stable

Purpose

URIP automates the workflow from detected risk to closed ticket. This guide covers the full automation chain: risk discovery → ticket creation → remediation → closure → compliance update.

Workflow Overview

[Connector finds risk]
       │
       ▼
[Risk appears in Risk Register]
       │
       ├──── Manual assignment ──► [Analyst assigns risk + due date]
       │                                    │
       │                                    ▼
       │                          [Jira / ServiceNow ticket auto-created]
       │                                    │
       │                          [Analyst fixes issue in target system]
       │                                    │
       │                          [Ticket closed in Jira/ServiceNow]
       │                                    │
       │                          [HMAC webhook → URIP risk "Pending Retest"]
       │                                    │
       │                          [Next connector poll confirms fix]
       │                                    │
       │                          [Risk closed → Compliance control re-evaluated]
       │
       └──── Auto-remediation ──► [Executor triggered (RTR/Ansible/Fortinet/CyberArk)]
                                           │
                                  [Implication check + approval gate]
                                           │
                                  [Executor runs fix]
                                           │
                                  [Risk status → Pending Retest]
                                           │
                                  [Next connector poll confirms fix]

Workflow 1: Risk → Jira Ticket

Prerequisites

1. Jira connector configured in Tool Catalog (see CONNECTOR_CATALOGUE.md — Jira)
2. Bidirectional sync enabled: Tool Catalog → Jira → Enable auto-ticket on assignment
3. Project key configured (the Jira project where tickets will be created)
4. Issue type mapping configured (URIP Risk Severity → Jira Priority)

Step-by-step

1. Open any risk in the Risk Register
2. Click Assign
3. Select a user from your tenant
4. Set a due date
5. Click Save

Within 30 seconds, URIP creates a Jira ticket with: - Summary: [URIP] {risk title} — {CVE ID if applicable} - Description: full risk detail, URIP score, EPSS, KEV flag, remediation steps - Priority: mapped from URIP severity (Critical → Highest, High → High, Medium → Medium, Low → Low) - Due date: copied from URIP assignment - Custom field: URIP Risk ID (for bi-directional sync)

The Jira ticket URL is linked back in the URIP risk detail.

Closing the Loop

When the Jira ticket is resolved: 1. Jira notifies URIP automatically (via a webhook you configure once) 2. URIP validates the notification and updates the risk status to "Pending Retest" 3. On the next connector poll, if the vulnerability is gone, URIP marks the risk as "Closed" 4. Any compliance controls that were failing due to this risk are re-evaluated automatically

Webhook setup in Jira: 1. In Jira: Project Settings → Automation → Webhooks → Create webhook 2. URL: paste the webhook URL shown in URIP's Jira connector configuration 3. Events: Issue Updated (when status changes to Done/Resolved) 4. Secret: paste the shared secret shown in URIP's Jira connector configuration

Workflow 2: Risk → ServiceNow Incident

Prerequisites

ServiceNow connector configured with incident_manager role and OAuth client credentials.

Behaviour

Identical to the Jira workflow above, but creates a ServiceNow Incident instead of a Jira ticket.

• URIP creates an incident with the full risk detail, priority, due date, and assignment group (if configured)
• When the incident is Resolved in ServiceNow, URIP updates the risk status to "Pending Retest" automatically

Additional feature: CMDB enrichment When the ServiceNow connector is configured, URIP also pulls the CMDB to enrich asset records. If an asset's hostname matches a CMDB CI, the asset record in URIP inherits the CI's business service, owner, and criticality classification.

Workflow 3: Auto-Remediation

Auto-remediation is available for four executor types. Requires explicit approval before execution.

Executors

Trigger auto-remediation

1. Open a risk in Risk Register or Remediation Tracker
2. Click Auto-Remediate
3. Select the executor from the dropdown (only configured executors appear)
4. Review the Implication Check: - What other assets/services might be affected by this action - Estimated blast radius - Reversibility (can the action be undone?)
5. Click Approve if the implications are acceptable
6. The executor runs asynchronously — monitor progress in the remediation job list

Approval gate

Auto-remediation requires an approver (ciso role or above). For high-blast-radius actions (e.g., isolating a production server), a second approver can be configured at Admin → Modules → Auto-Remediation.

The approval request is sent as a notification to the configured approvers. The action does not execute until approved.

Retest

After auto-remediation completes: 1. Risk status moves to "Pending Retest" 2. On the next connector poll, if the vulnerability/finding is gone → risk is marked "Closed" 3. If the finding persists → risk returns to "Open" with a note that auto-remediation ran but did not resolve it

Workflow 4: VAPT Vendor Submission

The VAPT Vendor Portal allows external penetration testing vendors to submit findings directly into URIP without sharing your main login credentials.

For vendors

1. Navigate to the URIP Vendor Portal sign-in page (URL provided by your administrator)
2. Enter vendor credentials (provided by URIP admin via /admin-vapt.html)
3. Navigate to Submit Finding (/vapt-portal-submit.html)
4. Fill in: - Finding title and description - CVE ID (if applicable) - Severity (P1/P2/P3/P4) - Affected URL / IP / asset - Proof of concept (file upload) - Recommended fix
5. Submit

For admins (triage)

1. Navigate to /admin-vapt.html
2. Review incoming submissions
3. Actions: Accept (finding added to Risk Register with auto-enrichment), Reject (with feedback), Request More Info

Auto-enrichment on accept: - CVE lookup in NVD for description and CVSS - EPSS and KEV check - Asset fingerprint lookup (is this asset already in inventory?) - Deduplication check (is this CVE already known from a scanner?) - Composite score computation

Retest workflow

1. Admin marks finding as "Retest Required"
2. Vendor receives notification (if email configured)
3. Vendor submits retest evidence via the portal
4. Admin reviews and accepts/rejects the retest

Workflow 5: Risk Acceptance

See guides/risk-center.md — Risk Acceptance for the full workflow.

Key points: - Formal acceptance with justification, review date, and compensating controls - Accepted risks auto-expire and re-open - Accepted risks still fail compliance controls (acceptance ≠ control pass)

Workflow 6: Trust Center

The Trust Center publishes your compliance posture to external parties (customers, partners, investors) without sharing login access.

Publish the Trust Center

1. Navigate to Admin → Trust Center (super-admin)
2. Enable the Trust Center for your tenant
3. Select which frameworks and which compliance posture data to publish
4. Configure NDA requirement (optional: require e-sign before viewing posture)
5. Copy the public Trust Center URL

Access flow for external parties

1. External party visits your Trust Center URL
2. If NDA required: they enter their name and email, click Accept NDA (logged with timestamp)
3. They see your compliance posture: framework scores, control categories, certification badges
4. They do NOT see: individual CVEs, asset details, raw findings, or connector credentials

Notification Channels

URIP sends notifications for workflow events via:

To customise notification settings: click the notification bell (top right) → Notification Preferences.

Audit Trail

Every workflow action is written to the immutable audit log:

• Risk assignment (who assigned to whom, when)
• Ticket creation (Jira/ServiceNow ticket ID)
• Auto-remediation trigger (who approved, what executor, what target)
• Risk acceptance (who accepted, justification, expiry)
• Compliance control status change (caused by what risk change)

The audit log is accessible at /audit-log.html (ciso+ role) and is included in compliance reports.

See Also

• USER_GUIDE.md — Workflows
• CONNECTOR_CATALOGUE.md — ITSM
• TROUBLESHOOTING.md — Jira Not Creating Tickets